लारवेल कैशिंग: बेसिक्स प्लस टिप्स एंड ट्रिक्स

कैशिंग तकनीक आपको एक तेज-मेमोरी मेमोरी में कुछ प्रश्नों के परिणामों को संग्रहीत करते हुए, और अधिक स्केलेबल एप्लिकेशन बनाने की अनुमति देती है। हालांकि, अनुचित तरीके से लागू किया गया कैशिंग आपके एप्लिकेशन के उपयोगकर्ता की धारणा को बहुत कम कर सकता है। इस लेख में कैशिंग, विभिन्न नियमों और वर्जनाओं के बारे में कुछ बुनियादी अवधारणाएँ हैं जो मैंने कई पिछली परियोजनाओं से सीखी हैं।

कैशिंग का उपयोग न करें।

क्या आपका प्रोजेक्ट तेज़ है और कोई प्रदर्शन समस्याएँ नहीं हैं?
कैशिंग के बारे में भूल जाओ। गंभीरता से :)

यह बिना किसी लाभ के डेटाबेस से रीड ऑपरेशंस को बहुत जटिल करेगा।

सच है, इस लेख की शुरुआत में मोहम्मद ने कहा कि कुछ गणनाएँ और साबित करती हैं कि कुछ मामलों में, मिलीसेकंड के लिए आवेदन का अनुकूलन आपके AWS खाते में एक टन पैसा बचा सकता है। इसलिए यदि आपकी परियोजना पर अनुमानित बचत $ 1.86 से अधिक है, तो शायद कैशिंग एक अच्छा विचार है।

यह कैसे काम करता है?

जब कोई एप्लिकेशन डेटाबेस से कुछ डेटा प्राप्त करना चाहता है, उदाहरण के लिए, अपनी आईडी द्वारा पोस्ट इकाई, यह इस मामले के लिए एक अद्वितीय कैशिंग कुंजी ( 'post_' . $id काफी उपयुक्त है) उत्पन्न करता है और तेजी से कुंजी-मूल्य भंडारण ( 'post_' . $id ) में इस कुंजी द्वारा मूल्य खोजने की कोशिश करता है। रेडिस, या अन्य)। यदि मान है, तो अनुप्रयोग इसका उपयोग करता है। यदि नहीं, तो यह डेटाबेस से लेता है और भविष्य में उपयोग के लिए इस कुंजी द्वारा कैश में संग्रहीत करता है।

इस मूल्य को कैश में रखना हमेशा के लिए एक अच्छा विचार नहीं है, क्योंकि इस पोस्ट इकाई को अपडेट किया जा सकता है, लेकिन एप्लिकेशन को हमेशा पुराना, कैश्ड मान प्राप्त होगा।
इसलिए, कैशिंग फ़ंक्शन आमतौर पर पूछते हैं कि इस मूल्य को किस समय संग्रहीत किया जाना चाहिए।

यह समय समाप्त होने के बाद, मेमेचे या रेडिस इसके बारे में "भूल" जाएगा और आवेदन डेटाबेस से एक नया मूल्य लेगा।

एक उदाहरण:

 public function getPost($id): Post { $key = 'post_' . $id; $post = \Cache::get($key); if($post === null) { $post = Post::findOrFail($id); \Cache::put($key, $post, 900); } return $post; } 

यहां मैंने पोस्ट इकाई को 15 मिनट के लिए कैश में रखा है (संस्करण 5.8 के बाद से, लारवेल इस पैरामीटर में सेकंड का उपयोग करता है, इससे पहले कि मिनट थे)। Cache मुखौटे में इस मामले के लिए एक सुविधाजनक remember विधि भी है। यह कोड पिछले एक के समान ही काम करता है:

 public function getPost($id): Post { return \Cache::remember('post_' . $id, 900, function() use ($id) { return Post::findOrFail($id); }); } 

लारवेल प्रलेखन में एक कैश अध्याय है जो बताता है कि आपके आवेदन और मुख्य कार्यक्षमता के लिए आवश्यक ड्राइवरों को कैसे स्थापित किया जाए।

कैश्ड डेटा

सभी मानक Laravel ड्राइवर स्ट्रिंग्स के रूप में डेटा संग्रहीत करते हैं। जब हम आपको एलोक्वेंट मॉडल का एक उदाहरण कैश करने के लिए कहते हैं, तो यह ऑब्जेक्ट से स्ट्रिंग प्राप्त करने के लिए क्रमबद्ध फ़ंक्शन का उपयोग करता है। जब हम कैश से प्राप्त करते हैं, तो अनसेरिज़ल फ़ंक्शन किसी ऑब्जेक्ट की स्थिति को पुनर्स्थापित करता है।

लगभग किसी भी डेटा को कैश किया जा सकता है। संख्या, तार, सरणियाँ, ऑब्जेक्ट (यदि वे सही ढंग से क्रमबद्ध हो सकते हैं, तो पहले लिंक से कार्यों का विवरण देखें)।

सुव्यवस्थित निकाय और संग्रह आसानी से कैश किए जा सकते हैं और लारवेल एप्लिकेशन कैश में सबसे लोकप्रिय मूल्य हैं। हालांकि, अन्य प्रकार के उपयोग का भी काफी व्यापक रूप से अभ्यास किया जाता है। Cache::increment विधि विभिन्न काउंटरों को लागू करने के लिए लोकप्रिय है। इसके अलावा, परमाणु ताले काफी उपयोगी होते हैं जब डेवलपर्स दौड़ की स्थिति से लड़ रहे होते हैं ।

क्या करें कैश?

कैशिंग के लिए पहले उम्मीदवार अनुरोध हैं जिन्हें बहुत बार निष्पादित किया जाता है, लेकिन उनकी निष्पादन योजना सबसे आसान नहीं है। सबसे अच्छा उदाहरण मुख्य पृष्ठ या नवीनतम समाचार पर शीर्ष 5 लेख हैं। ऐसे मूल्यों को कैशिंग करने से मुख्य पृष्ठ का प्रदर्शन बेहतर हो सकता है।

आमतौर पर, Model::find($id) का उपयोग करके आईडी प्राप्त करना बहुत तेज़ है, लेकिन यदि यह तालिका कई अपडेट्स से भरी हुई है, तो क्वेरीज़ डालें, और हटाएं, चुनिंदा क्वेरीज़ की संख्या को कम करने से डेटाबेस को एक अच्छी राहत मिलेगी। hasMany संबंधों के साथ hasMany जो हर बार लोड होंगी, कैशिंग के लिए भी अच्छे उम्मीदवार हैं। जब मैंने एक दिन में 10+ मिलियन आगंतुकों के साथ एक परियोजना पर काम किया, तो हमने लगभग किसी भी अनुरोध का अनुरोध किया।

कैशे अमान्य

निर्दिष्ट समय के बाद मुख्य क्षय कैश में डेटा को अपडेट करने में मदद करता है, लेकिन यह तुरंत नहीं होता है। उपयोगकर्ता डेटा को बदल सकता है, लेकिन कुछ समय तक वह एप्लिकेशन में उनके पुराने संस्करण को देखता रहेगा। मेरी पिछली परियोजनाओं में से एक पर सामान्य बातचीत:

 :   ,     ! : ,  15 ( ,  )... 

यह व्यवहार उपयोगकर्ताओं के लिए बहुत असुविधाजनक है, और पुराने डेटा को कैश से हटाने का स्पष्ट निर्णय जब हमने अपडेट किया तो यह जल्दी से समझ में आता है। इस प्रक्रिया को विकलांगता कहा जाता है। "post_%id%" जैसी सरल कुंजियों के लिए, "post_%id%" बहुत मुश्किल नहीं है।

सुव्‍यवस्थित घटनाएँ मदद कर सकती हैं, या यदि आपका एप्लिकेशन PostPublished या UserBanned जैसी विशेष ईवेंट UserBanned यह और भी सरल हो सकता है। उदात्त घटनाओं के साथ उदाहरण। सबसे पहले आपको ईवेंट क्लासेस बनाने की आवश्यकता है। सुविधा के लिए, मैं उनके लिए एक सार वर्ग का उपयोग करूंगा:

 abstract class PostEvent { /** @var Post */ private $post; public function __construct(Post $post) { $this->post = $post; } public function getPost(): Post { return $this->post; } } final class PostSaved extends PostEvent{} final class PostDeleted extends PostEvent{} 

बेशक, PSR-4 के अनुसार, प्रत्येक वर्ग को अपनी फ़ाइल में होना चाहिए। पोस्ट एलोकेंट क्लास ( प्रलेखन का उपयोग करके) सेट करें:

 class Post extends Model { protected $dispatchesEvents = [ 'saved' => PostSaved::class, 'deleted' => PostDeleted::class, ]; } 

इन घटनाओं के लिए एक श्रोता बनाएँ:

 class EventServiceProvider extends ServiceProvider { protected $listen = [ PostSaved::class => [ ClearPostCache::class, ], PostDeleted::class => [ ClearPostCache::class, ], ]; } class ClearPostCache { public function handle(PostEvent $event) { \Cache::forget('post_' . $event->getPost()->id); } } 

यह कोड पोस्ट संस्थाओं के प्रत्येक अद्यतन या हटाने के बाद कैश किए गए मानों को हटा देगा। शीर्ष -5 लेखों या ब्रेकिंग न्यूज़ जैसी अमान्य सूचीबद्धता सूची थोड़ी अधिक जटिल होगी। मैंने तीन रणनीतियाँ देखीं:

रणनीति को अक्षम न करें

बस इन मूल्यों को मत छुओ। आमतौर पर, यह कोई समस्या नहीं लाता है। यह ठीक है कि नई खबर बाद की सूची में थोड़ी देर बाद दिखाई देगी (बेशक, अगर यह एक बड़ा समाचार पोर्टल नहीं है)। लेकिन कुछ परियोजनाओं के लिए, इन सूचियों में ताजा डेटा होना वास्तव में महत्वपूर्ण है।

ढूँढें और रणनीति को परिभाषित करें

हर बार जब आप किसी प्रकाशन को अपडेट करते हैं, तो आप इसे कैश्ड सूचियों में खोजने का प्रयास कर सकते हैं, और यदि यह वहां है, तो इस कैश्ड मान को हटा दें।

 public function getTopPosts() { return \Cache::remember('top_posts', 900, function() { return Post::/*   top-5*/()->get(); }); } class CheckAndClearTopPostsCache { public function handle(PostEvent $event) { $updatedPost = $event->getPost(); $posts = \Cache::get('top_posts', []); foreach($posts as $post) { if($updatedPost->id == $post->id) { \Cache::forget('top_posts'); return; } } } } 

यह बदसूरत दिखता है, लेकिन यह काम करता है।

रणनीति "स्टोर आईडी"

यदि सूची में वस्तुओं का क्रम महत्वहीन है, तो कैश में आप केवल आईडी प्रविष्टियां संग्रहीत कर सकते हैं। आईडी प्राप्त करने के बाद, आप फॉर्म 'post_'.$id की चाबियों की एक सूची बना सकते हैं और Cache::many विधि का उपयोग करके सभी मान प्राप्त कर Cache::many , जो एक अनुरोध में कैश से बहुत सारे मान प्राप्त करता है (इसे मल्टी गेट भी कहा जाता है)।

कैश का अमान्य होना प्रोग्रामिंग में दो कठिनाइयों में से एक कहा जाता है और कुछ मामलों में बहुत मुश्किल है।

संबंध कैशिंग

रिश्तों के साथ कैशिंग संस्थाओं पर ध्यान देने की आवश्यकता है।

 $post = Post::findOrFail($id); foreach($post->comments...) 

यह कोड दो SELECT क्वेरी करता है। id द्वारा इकाई प्राप्त करना और post_id द्वारा टिप्पणी करना। हम कैशिंग लागू करते हैं:

 public function getPost($id): Post { return \Cache::remember('post_' . $id, 900, function() use ($id) { return Post::findOrFail($id); }); } $post = getPost($id); foreach($post->comments...) 

पहला अनुरोध कैश किया गया था, और दूसरा नहीं था। जब कैश ड्राइवर कैश पर पोस्ट लिखता है, तो comments अभी लोड नहीं होती हैं। यदि हम उन्हें भी कैश करना चाहते हैं, तो हमें उन्हें मैन्युअल रूप से लोड करना होगा:

 public function getPost($id): Post { return \Cache::remember('post_' . $id, 900, function() use ($id) { $post = Post::findOrFail($id); $post->load('comments'); return $post; }); } 

दोनों अनुरोधों को अब कैश कर दिया गया है, लेकिन हमें 'post_'.$id के मूल्यों को अमान्य करना चाहिए 'post_'.$id हर बार जब कोई टिप्पणी जोड़ी जाती है। यह बहुत कुशल नहीं है, इसलिए टिप्पणी कैश को अलग से संग्रहीत करना बेहतर है:

 public function getPostComments(Post $post) { return \Cache::remember('post_comments_' . $post->id, 900, function() use ($post) { return $post->comments; }); } $post = getPost($id); $comments = getPostComments($post); foreach($comments...) 

कभी-कभी सार और दृष्टिकोण एक-दूसरे के साथ दृढ़ता से जुड़े होते हैं और हमेशा एक साथ उपयोग किए जाते हैं (विवरण के साथ क्रम, वांछित भाषा में अनुवाद के साथ प्रकाशन)। इस मामले में, उन्हें एक कैश में संग्रहीत करना काफी सामान्य है।

कैश कीज़ के लिए सत्य का एकल स्रोत

यदि प्रोजेक्ट अमान्य हो जाता है, तो कैश कुंजियाँ कम से कम दो स्थानों पर उत्पन्न होती हैं: Cache::get कॉल करने के लिए Cache::get / Cache::remember और Cache::forget कॉल करने के लिए Cache::forget । मैंने पहले ही स्थितियों का सामना किया है जब यह कुंजी एक स्थान पर बदल गई थी, लेकिन दूसरे में नहीं थी, और विकलांगता टूट गई। ऐसे मामलों के लिए सामान्य सलाह निरंतर है, लेकिन कैशे कीज़ गतिशील रूप से उत्पन्न होती हैं, इसलिए मैं विशेष वर्गों का उपयोग करता हूं जो किज़ उत्पन्न करते हैं:

 final class CacheKeys { public static function postById($postId): string { return 'post_' . $postId; } public static function postComments($postId): string { return 'post_comments' . $postId; } } \Cache::remember(CacheKeys::postById($id), 900, function() use ($id) { $post = Post::findOrFail($id); }); // .... \Cache::forget(CacheKeys::postById($id)); 

बेहतर पठनीयता के लिए स्थिरांक में प्रमुख जीवन काल का भी प्रतिपादन किया जा सकता है। कोड पढ़ते समय ये 900 या 15 * 60 संज्ञानात्मक भार बढ़ाते हैं।

लेखन कार्यों में कैश का उपयोग न करें

लेखन कार्य को कार्यान्वित करते समय, जैसे किसी प्रकाशन का शीर्षक या पाठ बदलना, यह पहले लिखे गए getPost विधि का उपयोग करने के लिए आकर्षक है:

 $post = getPost($id); $post->title = $newTitle; $post->save(); 

कृपया ऐसा न करें। कैश में मान पुराना हो सकता है, भले ही अमान्य तरीके से किया गया हो। एक छोटी दौड़ की स्थिति और प्रकाशन किसी अन्य उपयोगकर्ता द्वारा किए गए परिवर्तनों को खो देगा। आशावादी ताले कम से कम परिवर्तनों को नहीं खोने में मदद करेंगे, लेकिन गलत अनुरोधों की संख्या बहुत बढ़ सकती है।

सबसे अच्छा समाधान पढ़ने और लिखने के संचालन (हैलो, सीक्यूआरएस) के लिए पूरी तरह से अलग इकाई चयन तर्क का उपयोग करना है। लिखने के संचालन में, आपको हमेशा डेटाबेस से नवीनतम मान का चयन करना होगा। और महत्वपूर्ण डेटा के लिए ताले (आशावादी या निराशावादी) के बारे में मत भूलना।

मुझे लगता है कि यह एक परिचयात्मक लेख के लिए पर्याप्त है। डेवलपर्स के लिए जाल के साथ, कैशिंग एक बहुत ही जटिल और लंबा विषय है, लेकिन प्रदर्शन लाभ कभी-कभी सभी कठिनाइयों को दूर करता है।