स्प्रिंग में एक सरल कैश आधारित सर्किट ब्रेकर बनाना

यह लेख उन लोगों के लिए है जो अपने आवेदन में एक प्रभावी कैश का उपयोग करते हैं और न केवल आवेदन में स्थिरता को जोड़ना चाहते हैं, बल्कि परियोजना के लिए केवल 1 वर्ग जोड़कर पूरे वातावरण में।

यदि आप खुद को पहचानते हैं, तो पढ़ें।

सर्किट ब्रेकर क्या है?

विषय दुनिया की तरह काट दिया जाता है और मैं आपको बोर नहीं करूंगा, एंट्रोपी बढ़ाता हूं और एक ही चीज दोहराता हूं। मेरे दृष्टिकोण से, मार्टिन फाउलर ने यहां सबसे अच्छी बात की, लेकिन मैं परिभाषा को एक वाक्य में फिट करने की कोशिश करूंगा:
कार्यक्षमता जो एक अनुपलब्ध सेवा के लिए जानबूझकर बर्बाद अनुरोधों को रोकती है, जिससे यह "अपने घुटनों से ऊपर उठने" की अनुमति देता है और सामान्य ऑपरेशन जारी रखता है ।

आदर्श रूप से, बर्बाद अनुरोधों को रोकने के लिए, सर्किट ब्रेकर (इसके बाद सीबी) आपके आवेदन को नहीं तोड़ना चाहिए। इसके बजाय, यदि वर्तमान डेटा, लेकिन अभी भी प्रासंगिक ("गलत नहीं"), या, यदि यह संभव नहीं है, तो कुछ डिफ़ॉल्ट मान, वापसी के लिए अच्छा अभ्यास है।

लक्ष्यों

हम मुख्य चीज को सिंगल करते हैं:

1. थोड़ी देर के लिए प्रश्नों को रोककर डेटा स्रोत को पुनर्प्राप्त करने की अनुमति देना आवश्यक है
2. लक्ष्य सेवा के लिए अनुरोधों को रोकने के मामले में, आपको नवीनतम, लेकिन अभी भी प्रासंगिक डेटा नहीं देने की आवश्यकता है
3. यदि लक्ष्य सेवा अनुपलब्ध है और कोई प्रासंगिक डेटा नहीं है, तो व्यवहार रणनीति प्रदान करें (डिफ़ॉल्ट मान या किसी विशेष मामले के लिए उपयुक्त अन्य रणनीति लौटाएं)

कार्यान्वयन तंत्र

मामला: सेवा उपलब्ध है (पहला अनुरोध)

1. चलिए कैश पर चलते हैं। कुंजी द्वारा (CRT नीचे देखें)। हम देखते हैं कि कैश में कुछ भी नहीं है
2. हम लक्ष्य सेवा में जाते हैं। हमें मूल्य मिलता है
3. हम कैश में मूल्य को संग्रहीत करते हैं, इसे ऐसे टीटीएल पर सेट करते हैं जो अधिकतम संभव समय को कवर करेगा, जो लक्ष्य सेवा अनुपलब्ध है, लेकिन साथ ही यह उस डेटा की वैधता अवधि से अधिक नहीं होनी चाहिए, जो आप लक्ष्य सेवा से कनेक्शन के नुकसान के मामले में क्लाइंट को देने के लिए तैयार हैं।
4. कैश रीफ़्रेश टाइम (CRT) को क्लॉज़ 3 से मान के लिए कैश में संग्रहीत किया जाता है - वह समय जिसके बाद आपको लक्ष्य सेवा में जाने और मूल्य को अपडेट करने की कोशिश करने की आवश्यकता होती है
5. उपयोगकर्ता के लिए आइटम 2 से मान लौटाएं

मामला: CRT की समय सीमा समाप्त नहीं हुई

1. चलिए कैश पर चलते हैं। कुंजी से हम सीआरटी पाते हैं। हम देखते हैं कि यह प्रासंगिक है
2. इसके लिए मूल्य को कैश से प्राप्त करें।
3. उपयोगकर्ता को मान लौटाएं।

मामला: CRT की समय सीमा समाप्त हो गई है, लक्ष्य सेवा उपलब्ध है

1. चलिए कैश पर चलते हैं। कुंजी से हम सीआरटी पाते हैं। हम देखते हैं कि यह अप्रासंगिक है
2. हम लक्ष्य सेवा में जाते हैं। हमें मूल्य मिलता है
3. कैश और उसके टीटीएल में मूल्य को अद्यतन करना
4. कैश रीफ़्रेश अवधि (CRP) जोड़कर इसके लिए CRT अपडेट करें - यह वह मान है जिसे अगले CRT प्राप्त करने के लिए CRT में जोड़ने की आवश्यकता है
5. उपयोगकर्ता को मान लौटाएं।

केस: CRT की समय सीमा समाप्त, लक्ष्य सेवा अनुपलब्ध

1. चलिए कैश पर चलते हैं। कुंजी से हम सीआरटी पाते हैं। हम देखते हैं कि यह अप्रासंगिक है
2. हम लक्ष्य सेवा में जाते हैं। वह अनुपलब्ध है
3. कैश से मूल्य प्राप्त करें। सबसे ताज़ा (सड़े हुए CRT के साथ) नहीं, लेकिन फिर भी प्रासंगिक है, क्योंकि इसका TTL अभी तक समाप्त नहीं हुआ है
4. हम इसे उपयोगकर्ता को वापस कर देते हैं

मामला: CRT की समय सीमा समाप्त, लक्ष्य सेवा अनुपलब्ध, कैश में कुछ भी नहीं

1. चलिए कैश पर चलते हैं। कुंजी से हम सीआरटी पाते हैं। हम देखते हैं कि यह अप्रासंगिक है
2. हम लक्ष्य सेवा में जाते हैं। वह अनुपलब्ध है
3. कैश से मूल्य प्राप्त करें। वह नहीं है
4. हम ऐसे मामलों के लिए एक विशेष रणनीति लागू करने की कोशिश कर रहे हैं। उदाहरण के लिए, किसी निर्दिष्ट फ़ील्ड के लिए एक डिफ़ॉल्ट मान, या "यह जानकारी वर्तमान में उपलब्ध नहीं है" प्रकार का एक विशेष मान लौटाता है। सामान्य तौर पर, यदि यह संभव है, तो बेहतर है कि कुछ वापस करें और एप्लिकेशन को न तोड़ें। यदि यह संभव नहीं है, तो आपको अपवाद फेंकने की रणनीति को लागू करने और अपवाद उपयोगकर्ता को त्वरित प्रतिक्रिया देने की आवश्यकता है।

हम क्या उपयोग करेंगे

मैं अपनी परियोजना में स्प्रिंग बूट 1.5 का उपयोग करता हूं, फिर भी दूसरे संस्करण में अपग्रेड करने का समय नहीं मिला है।

यह लेख 2 बार लंबा नहीं निकला, मैं लोम्बोक का उपयोग करूंगा।

की-वैल्यू स्टोरेज के रूप में (इसके बाद केवी के रूप में संदर्भित) मैं Redis 5.0.3 का उपयोग करता हूं, लेकिन मुझे यकीन है कि हेज़ेलकास्ट या एक एनालॉग करेगा। मुख्य बात यह है कि कैशमैनेजर इंटरफ़ेस का कार्यान्वयन है। मेरे मामले में, यह स्प्रिंग-बूट-स्टार्टर-डेटा-रेडिस से RedisCacheManager है।

कार्यान्वयन

ऊपर, "कार्यान्वयन तंत्र" अनुभाग में, दो महत्वपूर्ण परिभाषाएं बनाई गई थीं: सीआरटी और सीआरपी। मैं उन्हें और अधिक विस्तार से लिखूंगा, क्योंकि कोड को समझने के लिए वे बहुत महत्वपूर्ण हैं:

कैश रीफ़्रेश टाइम ( CRT ) KV (की + पोस्टफ़िक्स "_crt") में एक अलग प्रविष्टि है, जो ताज़ा डेटा के लिए लक्ष्य सेवा में जाने का समय दिखाता है। टीटीएल के विपरीत, सीआरटी की शुरुआत का मतलब यह नहीं है कि आपका डेटा "सड़ा हुआ" है, लेकिन केवल यह कि लक्ष्य सेवा में अधिक हाल ही में प्राप्त होने की संभावना है। ताजा हो गया - ठीक है, यदि नहीं, और वर्तमान नीचे आ जाएगा।

कैश रीफ़्रेश अवधि ( सीआरपी ) एक मूल्य है जिसे लक्ष्य सेवा को मतदान के बाद सीआरटी में जोड़ा जाता है (यह सफल है या नहीं, इससे कोई फर्क नहीं पड़ता)। उसके लिए धन्यवाद, एक दूरस्थ सेवा में "अपनी सांस पकड़ने" और गिरने की स्थिति में अपना काम बहाल करने की क्षमता है।

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

public interface CircuitBreakerService { <T> T getStableValue(StableValueParameter parameter); void evictValue(EvictValueParameter parameter); } 

इंटरफ़ेस पैरामीटर:

 @Getter @AllArgsConstructor public class StableValueParameter<T> { private String cachePrefix; //    private String objectCacheKey; private long crpInSeconds; // Cache Refresh Period private Supplier<T> targetServiceAction; //      private DisasterStrategy disasterStrategy; //   : CRT ,   ,     public StableValueParameter( String cachePrefix, String objectCacheKey, long crpInSeconds, Supplier<T> targetServiceAction ) { this.cachePrefix = cachePrefix; this.objectCacheKey = objectCacheKey; this.crpInSeconds = crpInSeconds; this.targetServiceAction = targetServiceAction; this.disasterStrategy = new ThrowExceptionDisasterStrategy(); } } 

 @Getter @AllArgsConstructor public class EvictValueParameter { private String cachePrefix; private String objectCacheKey; } 

इस तरह हम इसका उपयोग करेंगे:

 public AccountDataResponse findAccount(String accountId) { final StableValueParameter<?> parameter = new StableValueParameter<>( ACCOUNT_CACHE_PREFIX, accountId, properties.getCrpInSeconds(), () -> bankClient.findById(accountId) ); return circuitBreakerService.getStableValue(parameter); } 

यदि आपको कैश साफ़ करने की आवश्यकता है, तो:

 public void evictAccount(String accountId) { final EvictValueParameter parameter = new EvictValueParameter( ACCOUNT_CACHE_PREFIX, accountId ); circuitBreakerService.evictValue(parameter); } 

अब सबसे दिलचस्प बात कार्यान्वयन है (कोड में टिप्पणियों में समझाया गया है):

 @Override public <T> T getStableValue(StableValueParameter parameter) { final Cache cache = cacheManager.getCache(parameter.getCachePrefix()); if (cache == null) { return logAndThrowUnexpectedCacheMissing(parameter.getCachePrefix(), parameter.getObjectCacheKey()); } //   .   CRT final String crtKey = parameter.getObjectCacheKey() + CRT_CACHE_POSTFIX; //  CRT  ,    final LocalDateTime crt = Optional.ofNullable(cache.get(crtKey, LocalDateTime.class)) .orElseGet(() -> DateTimeUtils.now().minusSeconds(1)); if (DateTimeUtils.now().isBefore(crt)) { //  CRT   ,     final Optional<T> valueFromCache = getFromCache(parameter, cache); if (valueFromCache.isPresent()) { return valueFromCache.get(); } } //  CRT  ,        return getFromTargetServiceAndUpdateCache(parameter, cache, crtKey, crt); } private static <T> Optional<T> getFromCache(StableValueParameter parameter, Cache cache) { return (Optional<T>) Optional.ofNullable(cache.get(parameter.getObjectCacheKey())) .map(Cache.ValueWrapper::get); } 

यदि लक्ष्य सेवा अनुपलब्ध है, तो कैश से अभी भी प्रासंगिक डेटा प्राप्त करने का प्रयास करें:

 private <T> T getFromTargetServiceAndUpdateCache( StableValueParameter parameter, Cache cache, String crtKey, LocalDateTime crt ) { T result; try { result = getFromTargetService(parameter); } /* Circuit breaker exceptions */ catch (WebServiceIOException ex) { log.warn( "[CircuitBreaker] Service responded with error: {}. Try get from cache {}: {}", ex.getMessage(), parameter.getCachePrefix(), parameter.getObjectCacheKey()); result = getFromCacheOrDisasterStrategy(parameter, cache); } cache.put(parameter.getObjectCacheKey(), result); cache.put(crtKey, crt.plusSeconds(parameter.getCrpInSeconds())); return result; } private static <T> T getFromTargetService(StableValueParameter parameter) { return (T) parameter.getTargetServiceAction().get(); } 

यदि कैश में कोई वास्तविक डेटा नहीं था (वे TTL द्वारा हटाए गए थे, और लक्ष्य सेवा अभी भी अनुपलब्ध है), तो हम DisasterStrategy का उपयोग करते हैं:

 private <T> T getFromCacheOrDisasterStrategy(StableValueParameter parameter, Cache cache) { return (T) getFromCache(parameter, cache).orElseGet(() -> parameter.getDisasterStrategy().getValue()); } 

कैश से निकालना कुछ भी दिलचस्प नहीं है, मैं इसे पूरी तरह से यहां दे दूंगा:

 private <T> T getFromCacheOrDisasterStrategy(StableValueParameter parameter, Cache cache) { return (T) getFromCache(parameter, cache).orElseGet(() -> parameter.getDisasterStrategy().getValue()); } 

कैश से निकालना कुछ भी दिलचस्प नहीं है, मैं इसे पूरी तरह से यहां दे दूंगा:

 @Override public void evictValue(EvictValueParameter parameter) { final Cache cache = cacheManager.getCache(parameter.getCachePrefix()); if (cache == null) { logAndThrowUnexpectedCacheMissing(parameter.getCachePrefix(), parameter.getObjectCacheKey()); return; } final String crtKey = parameter.getObjectCacheKey() + CRT_CACHE_POSTFIX; cache.evict(crtKey); } 

आपदा की रणनीति

यह, वास्तव में, तर्क है जो तब होता है यदि CRT समाप्त हो जाता है, लक्ष्य सेवा अनुपलब्ध है, और कैश में कुछ भी नहीं है।

मैं इस तर्क का अलग से वर्णन करना चाहता था, क्योंकि कई लोगों को यह सोचने के लिए हाथ नहीं मिलता है कि इसे कैसे लागू किया जाए। लेकिन यह, वास्तव में, हमारी प्रणाली को वास्तव में स्थिर बनाता है।

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

गेय विषयांतर को समाप्त करना। तो, रणनीति इंटरफ़ेस निम्नानुसार होगा:

 public interface DisasterStrategy<T> { T getValue(); } 

आपको विशिष्ट मामले के आधार पर कार्यान्वयन का चयन करना चाहिए। उदाहरण के लिए, यदि आप कुछ डिफ़ॉल्ट मान वापस कर सकते हैं, तो आप ऐसा कुछ कर सकते हैं:

 public class DefaultValueDisasterStrategy implements DisasterStrategy<String> { @Override public String getValue() { return "   "; } } 

या, यदि किसी विशेष मामले में आपको कुछ भी वापस नहीं करना है, तो आप एक अपवाद फेंक सकते हैं:

 public class ThrowExceptionDisasterStrategy implements DisasterStrategy<Object> { @Override public Object getValue() { throw new CircuitBreakerNullValueException("Ops! Service is down and there's null value in cache"); } } 

इस स्थिति में, CRT को बढ़ाया नहीं जाएगा और अगला अनुरोध फिर से लक्ष्य सेवा का पालन करेगा।

निष्कर्ष

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

बहुत सारे तैयार समाधान हैं, खासकर यदि आप स्प्रिंग बूट 2 का उपयोग कर रहे हैं, जैसे कि हिस्ट्रिक्स।

समझने की सबसे महत्वपूर्ण बात यह है कि यह समाधान कैश पर आधारित है और इसकी प्रभावशीलता कैश की प्रभावशीलता के बराबर है। यदि कैश अप्रभावी है (कुछ हिट, कई मिस), तो यह सर्किट ब्रेकर समान रूप से अप्रभावी होगा: प्रत्येक कैश मिस लक्ष्य सेवा की यात्रा के साथ होगा, जो, शायद इस समय पीड़ा और पीड़ा में है, उठने की कोशिश कर रहा है।

इस दृष्टिकोण को लागू करने से पहले अपने कैश की प्रभावशीलता को मापना सुनिश्चित करें। यह "कैश हिट रेट" = हिट्स (हिट्स + मिसेस) द्वारा किया जा सकता है, यह 1 से होना चाहिए, न कि 0।

और हां, कोई भी आपके प्रोजेक्ट में सीबी की कई किस्मों को एक साथ रखने के लिए परेशान नहीं करता है, एक का उपयोग करके जो विशिष्ट समस्या को हल करता है।