एंटीपैटर्न: कैश मेमोरी से जुड़ी गड़बड़ी के जवाब

Apigee Edge दस्तावेज़ देखा जा रहा है.
Apigee X दस्तावेज़ पर जाएं. जानकारी

डेटा को कैश मेमोरी में सेव करने की प्रोसेस को कैश मेमोरी में सेव किया जाता है. इसे आने वाले समय में इस्तेमाल किया जा सकता है. डेटा कैश मेमोरी में सेव करने से, परफ़ॉर्मेंस के लिए अहम फ़ायदे होते हैं, क्योंकि:

  • डेटा को तेज़ी से वापस पाने में मदद मिलती है
  • डेटा को बार-बार जनरेट करने से बचाकर, प्रोसेसिंग में लगने वाला समय कम करता है
  • एपीआई अनुरोधों को बैकएंड सर्वर पर हिट होने से रोकता है. इस तरह, यह बैकएंड सर्वर पर ओवरहेड को कम करता है
  • सिस्टम/ऐप्लिकेशन संसाधनों के बेहतर इस्तेमाल की अनुमति देता है
  • एपीआई के रिस्पॉन्स टाइम में सुधार करता है

अगर हमें कुछ ऐसे डेटा को ऐक्सेस करना हो जो अक्सर बदलता नहीं है, तो इस डेटा को सेव करने के लिए कैश मेमोरी का इस्तेमाल करें.

Apigee Edge, रनटाइम के दौरान कैश मेमोरी में डेटा सेव कर सकता है. इससे, डेटा को लंबे समय तक और तेज़ी से वापस पाया जा सकता है. कैश मेमोरी में सेव करने की सुविधा, Populatecache नीति, lookupकैश नीति, अमान्य कैश नीति, और Responseकैश नीति के ज़रिए उपलब्ध कराई जाती है.

आइए, इस सेक्शन में रिस्पॉन्स कैश मेमोरी से जुड़ी नीति पर नज़र डालते हैं. Apigee Edge प्लैटफ़ॉर्म पर, रिस्पॉन्स कैश मेमोरी की नीति से, आपको बैकएंड सर्वर से मिलने वाले रिस्पॉन्स को कैश मेमोरी में सेव करने की सुविधा मिलती है. अगर क्लाइंट ऐप्लिकेशन, एक ही बैकएंड रिसॉर्स के लिए बार-बार अनुरोध करते हैं और संसाधन समय-समय पर अपडेट होता रहता है, तो हम इस नीति का इस्तेमाल करके इन रिस्पॉन्स को कैश मेमोरी में सेव कर सकते हैं. रिस्पॉन्स कैश नीति से, कैश मेमोरी में सेव किए गए रिस्पॉन्स दिखाने में मदद मिलती है. इस वजह से, अनुरोध को बिना किसी ज़रूरत के बैकएंड सर्वर पर फ़ॉरवर्ड करने से भी रोका जा सकता है.

रिस्पॉन्स कैश मेमोरी से जुड़ी नीति:

  • यह बैकएंड तक पहुंचने वाले अनुरोधों की संख्या कम करता है
  • नेटवर्क बैंडविड्थ को कम करता है
  • एपीआई की परफ़ॉर्मेंस और जवाब देने में लगने वाले समय में सुधार करता है

एंटीपैटर्न

Responsecache नीति की मदद से, एचटीटीपी रिस्पॉन्स को डिफ़ॉल्ट रूप से, किसी भी संभावित स्टेटस कोड के साथ कैश मेमोरी में सेव किया जा सकता है. इसका मतलब है कि कामयाब होने और गड़बड़ी वाले, दोनों तरह के रिस्पॉन्स को कैश मेमोरी में सेव किया जा सकता है.

यहां डिफ़ॉल्ट कॉन्फ़िगरेशन के साथ रिस्पॉन्स कैश मेमोरी से जुड़ी नीति का उदाहरण दिया गया है:

<!-- /antipatterns/examples/1-1.xml -->
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ResponseCache async="false" continueOnError="false" enabled="true" name="TargetServerResponseCache">
  <DisplayName>TargetServer ResponseCache</DisplayName>
  <CacheKey>
    <Key Fragment ref="request.uri" /></CacheKey>
    <Scope>Exclusive</Scope>
    <ExpirySettings>
      <TimeoutInSec ref="flow.variable.here">600</TimeoutInSec>
    </ExpirySettings>
  <CacheResource>targetCache</CacheResource>
</ResponseCache>

रिस्पॉन्स कैश नीति, गड़बड़ी के रिस्पॉन्स को अपने डिफ़ॉल्ट कॉन्फ़िगरेशन में कैश मेमोरी में सेव करती है. हालांकि, गड़बड़ियों के असर के बारे में सोच-विचार किए बिना, गड़बड़ी वाले जवाबों को कैश मेमोरी में सेव करना सही नहीं है, क्योंकि:

  • पहली स्थिति: अस्थायी और अज्ञात अवधि के दौरान गड़बड़ियां होती हैं. समस्या ठीक हो जाने के बाद भी, हम कैश मेमोरी में सेव करने की वजह से गड़बड़ी के जवाब भेजना जारी रख सकते हैं

    OR

  • दूसरी स्थिति: गड़बड़ियां एक तय समय तक दिखेंगी. इसके बाद, समस्या हल हो जाने के बाद, हमें कोड में बदलाव करना होगा, ताकि रिस्पॉन्स को कैश मेमोरी में सेव न किया जा सके

आइए, इन दोनों स्थितियों को ज़्यादा विस्तार से समझाकर इसकी पूरी जानकारी देते हैं.

पहली स्थिति: बैकएंड/संसाधन में अस्थायी तौर पर गड़बड़ी

मान लें कि बैकएंड सर्वर में गड़बड़ी यहां दी गई किसी एक वजह से हो रही है:

  • नेटवर्क में कुछ समय के लिए गड़बड़ी हुई
  • बैकएंड सर्वर बहुत व्यस्त है. इसलिए, यह कुछ समय से किए गए अनुरोधों का जवाब नहीं दे पा रहा है
  • शायद कुछ समय के लिए, अनुरोध किया गया बैकएंड रिसॉर्स हटाया या उपलब्ध न हो
  • बैकएंड सर्वर कुछ समय के लिए प्रोसेस होने में ज़्यादा समय लगने की वजह से धीरे काम कर रहा है, वगैरह

इन सभी मामलों में, अनजान समयावधि तक गड़बड़ियां हो सकती हैं और फिर हमें सही जवाब मिलने शुरू हो सकते हैं. अगर हम गड़बड़ी के रिस्पॉन्स को कैश मेमोरी में सेव करते हैं, तो हो सकता है कि बैकएंड सर्वर की समस्या ठीक हो गई हो. इसके बावजूद, हम उपयोगकर्ताओं को गड़बड़ी वाले रिस्पॉन्स भेजना जारी रख सकते हैं.

दूसरी स्थिति: रुकी हुई या तय की गई बैकएंड/रिसॉर्स में गड़बड़ी

ध्यान दें कि हम जानते हैं कि बैकएंड में गड़बड़ी एक तय समय के लिए होती है. उदाहरण के लिए, आपको पता होगा कि:

  • कोई खास बैकएंड रिसॉर्स एक घंटे के लिए उपलब्ध नहीं रहेगा

    OR

  • साइट के अचानक काम न करने, स्केलिंग में आने वाली समस्याओं, रखरखाव, अपग्रेड वगैरह की वजह से बैकएंड सर्वर 24 घंटे के लिए हटा दिया जाता है या उपलब्ध नहीं होता.

इस जानकारी की मदद से, हम रिस्पॉन्स कैश मेमोरी से जुड़ी नीति में सही तरीके से कैश मेमोरी के खत्म होने की अवधि सेट कर सकते हैं. इससे हम गड़बड़ी के रिस्पॉन्स को लंबे समय तक कैश मेमोरी में सेव नहीं कर पाएंगे. हालांकि, जब बैकएंड सर्वर/संसाधन फिर से उपलब्ध हो जाएगा, तब हमें नीति में बदलाव करना होगा. ऐसा करके, कैश मेमोरी में सेव होने वाली गड़बड़ी के रिस्पॉन्स से बचा जा सकेगा. ऐसा इसलिए होता है, क्योंकि अगर बैकएंड सर्वर कोई अस्थायी/एक बार काम नहीं कर पाता है, तो हम रिस्पॉन्स को कैश मेमोरी में सेव कर देंगे और हम ऊपर स्थिति 1 में बताई गई समस्या को हल करेंगे.

असर

  • कैश मेमोरी में सेव की गई गड़बड़ी के रिस्पॉन्स की वजह से, बैकएंड सर्वर में समस्या हल होने के बाद भी गड़बड़ी के रिस्पॉन्स भेजे जा सकते हैं
  • उपयोगकर्ता को गड़बड़ी की वजह पता लगाने में बहुत मेहनत करनी पड़ती है. हालांकि, उन्हें यह पता नहीं चलता कि गड़बड़ी, बैकएंड सर्वर से गड़बड़ी के रिस्पॉन्स को कैश मेमोरी में सेव करने की वजह से हो रही है.

सबसे सही तरीका

  • गड़बड़ी के जवाबों को रिस्पॉन्स कैश मेमोरी में सेव न करें. यह पक्का करें कि Responseकैश नीति में <ExcludeErrorResponse> एलिमेंट, true पर सेट हो, ताकि गड़बड़ी वाले रिस्पॉन्स को कैश मेमोरी में सेव होने से रोका जा सके, जैसा कि नीचे दिए गए कोड स्निपेट में दिखाया गया है. इस कॉन्फ़िगरेशन के साथ, सिर्फ़ डिफ़ॉल्ट तौर पर काम करने वाले कोड 200 से 205 के रिस्पॉन्स को कैश मेमोरी में सेव किया जाएगा. हालांकि, अगर सफलता के कोड में बदलाव नहीं किया गया है, तो उन्हें कैश मेमोरी में सेव किया जाएगा. 
    <!-- /antipatterns/examples/1-2.xml -->
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ResponseCache async="false" continueOnError="false" enabled="true" name="TargetServerResponseCache">
  <DisplayName>TargetServerResponseCache</DisplayName>
  <CacheKey>
    <KeyFragment ref="request.uri" />
  </CacheKey>
  <Scope>Exclusive</Scope>
  <ExpirySettings>
    <TimeoutinSec ref="flow.variable.here">600</TimeoutinSec>
  </ExpirySettings>
  <CacheResource>targetCache</CacheResource>
  <ExcludeErrorResponse>true</ExcludeErrorResponse>
</ResponseCache>
  • अगर आपको किसी खास वजह से गड़बड़ी के जवाबों को कैश मेमोरी में सेव करना ज़रूरी है, तो आप गड़बड़ी के दिखने का ज़्यादा से ज़्यादा/सटीक समय (अगर मुमकिन हो) तय कर सकते हैं:
    • खत्म होने का समय सही तरीके से सेट करें, ताकि गड़बड़ी के रिस्पॉन्स, उस समय से ज़्यादा समय तक कैश मेमोरी में सेव न हों जब गड़बड़ी दिखती है.
    • <ExcludeErrorResponse> एलिमेंट के बिना, गड़बड़ी के रिस्पॉन्स को कैश मेमोरी में सेव करने के लिए, Responsecache नीति का इस्तेमाल करें.

    ऐसा सिर्फ़ तब करें, जब आपको पक्का पता हो कि बैकएंड सर्वर सिर्फ़ कुछ समय या कुछ समय के लिए काम नहीं कर रहा है.

  • Apigee, बैकएंड सर्वर से 5xx रिस्पॉन्स को कैश करने का सुझाव नहीं देता.