🎆 🛸 👵🏽 स्प्रिंग कैश: कैशिंग कनेक्ट करने से लेकर कैश मैनेजर के लचीले विन्यास तक 🥧 🍫 👨‍🚒

मुझे कैशिंग से डर लगता था। मैं वास्तव में चढ़ना नहीं चाहता था और यह पता लगाना चाहता था कि यह क्या है, मैंने तुरंत कुछ इंजन कम्पार्टमेंट लुट्टो-एंटरप्राइज़ चीजों की कल्पना की, जो केवल गणित के विजेता ओलंपियाड का पता लगा सकते थे। यह पता चला कि ऐसा नहीं है। कैशिंग किसी भी परियोजना में लागू करने के लिए बहुत सरल, समझने योग्य और अविश्वसनीय रूप से आसान निकला।

इस पोस्ट में, मैं सरल के रूप में कैशिंग के बारे में समझाने की कोशिश करूंगा जैसा कि अब मैं समझता हूं। आप 1 मिनट में कैशिंग कैसे लागू करें, कुंजी से कैश कैसे करें, कैश लाइफटाइम सेट करें, और कई अन्य चीजें हैं जिन्हें आपको यह जानना होगा कि क्या आपको अपने कार्यशील प्रोजेक्ट में कुछ कैश करने का निर्देश दिया गया है, और आप नहीं करना चाहते हैं चेहरा।

मैं "सौंपा" क्यों कहता हूं? क्योंकि कैशिंग, एक नियम के रूप में, यह बड़े, अत्यधिक भरी हुई परियोजनाओं में लागू करने के लिए समझ में आता है, प्रति मिनट हजारों अनुरोधों के साथ। ऐसी परियोजनाओं में, डेटाबेस को अधिभार नहीं देने के लिए, वे आम तौर पर रिपॉजिटरी कॉल को कैश करते हैं। विशेष रूप से अगर यह ज्ञात है कि कुछ मास्टर सिस्टम से डेटा एक निश्चित आवृत्ति पर अपडेट किया जाता है। हम खुद इस तरह की परियोजनाओं को नहीं लिखते हैं, हम उन पर काम करते हैं। यदि प्रोजेक्ट छोटा है और ओवरलोड का खतरा नहीं है, तो, निश्चित रूप से, कुछ भी कैश नहीं करना बेहतर है - हमेशा ताजा डेटा हमेशा समय-समय पर अपडेट किए गए लोगों की तुलना में बेहतर होता है।

आमतौर पर, प्रशिक्षण पदों में, स्पीकर पहले हुड के नीचे क्रॉल करता है, तकनीक की हिम्मत में देरी करने लगता है, जो पाठक को बहुत परेशान करता है, और केवल तब, जब वह लेख के एक अच्छे आधे हिस्से के माध्यम से निकलता है और कुछ भी नहीं समझता है, यह बताता है कि यह कैसे काम करता है। हमारे साथ सब कुछ अलग होगा। सबसे पहले, हम इसे काम करते हैं, और अधिमानतः, कम से कम प्रयास के साथ, और फिर, यदि आप रुचि रखते हैं, तो आप कैश हुड के नीचे देख सकते हैं, बिन के अंदर ही देख सकते हैं और फाइन-ट्यूशन कैशिंग कर सकते हैं। लेकिन भले ही आप (और यह बिंदु 6 से शुरू होता है), आपकी कैशिंग उसी तरह काम करेगी।

हम एक परियोजना बनाएंगे जिसमें हम कैशिंग के सभी पहलुओं का विश्लेषण करेंगे जो मैंने वादा किया था। अंत में, हमेशा की तरह, परियोजना के लिए एक लिंक होगा।

0. एक परियोजना बनाना

हम एक बहुत ही सरल परियोजना बनाएंगे जिसमें हम डेटाबेस से इकाई ले सकते हैं। मैंने प्रोजेक्ट में लोम्बोक, स्प्रिंग कैश, स्प्रिंग डेटा जेपीए और एच 2 को जोड़ा। हालांकि, केवल स्प्रिंग कैश के साथ ही खदेड़ दिया जा सकता है।

plugins { id 'org.springframework.boot' version '2.1.7.RELEASE' id 'io.spring.dependency-management' version '1.0.8.RELEASE' id 'java' } group = 'ru.xpendence' version = '0.0.1-SNAPSHOT' sourceCompatibility = '1.8' configurations { compileOnly { extendsFrom annotationProcessor } } repositories { mavenCentral() } dependencies { implementation 'org.springframework.boot:spring-boot-starter-cache' implementation 'org.springframework.boot:spring-boot-starter-data-jpa' compileOnly 'org.projectlombok:lombok' runtimeOnly 'com.h2database:h2' annotationProcessor 'org.projectlombok:lombok' testImplementation 'org.springframework.boot:spring-boot-starter-test' }

हमारे पास केवल एक इकाई होगी, चलो इसे उपयोगकर्ता कहते हैं।

 @Entity @Table(name = "users") @Data @NoArgsConstructor @ToString public class User implements Serializable { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; @Column(name = "name") private String name; @Column(name = "email") private String email; public User(String name, String email) { this.name = name; this.email = email; } }

रिपॉजिटरी और सेवा जोड़ें:

 public interface UserRepository extends JpaRepository<User, Long> { } @Slf4j @Service public class UserServiceImpl implements UserService { private final UserRepository repository; public UserServiceImpl(UserRepository repository) { this.repository = repository; } @Override public User create(User user) { return repository.save(user); } @Override public User get(Long id) { log.info("getting user by id: {}", id); return repository.findById(id) .orElseThrow(() -> new EntityNotFoundException("User not found by id " + id)); } }

जब हम गेट () सेवा पद्धति में प्रवेश करते हैं, तो हम इसके बारे में लॉग में लिखते हैं।

स्प्रिंग कैश प्रोजेक्ट से कनेक्ट करें।

 @SpringBootApplication @EnableCaching // Spring Cache public class CacheApplication { public static void main(String[] args) { SpringApplication.run(CacheApplication.class, args); } }

प्रोजेक्ट तैयार है।

1. रिटर्न परिणाम कैशिंग

स्प्रिंग कैश क्या करता है? स्प्रिंग कैश बस विशिष्ट इनपुट मापदंडों के लिए रिटर्न परिणाम को कैश करता है। आइए इसे देखें। हम लौटाए गए डेटा को कैश करने के लिए () सेवा पद्धति पर @ व्यवहार योग्य एनोटेशन डालेंगे। हम इस एनोटेशन को "उपयोगकर्ता" नाम देते हैं (हम आगे विश्लेषण करेंगे कि यह अलग से क्यों किया जाता है)।

  @Override @Cacheable("users") public User get(Long id) { log.info("getting user by id: {}", id); return repository.findById(id) .orElseThrow(() -> new EntityNotFoundException("User not found by id " + id)); }

यह कैसे काम करता है यह जांचने के लिए, हम एक साधारण परीक्षण लिखेंगे।

 @RunWith(SpringRunner.class) @SpringBootTest public abstract class AbstractTest { }

 @Slf4j public class UserServiceTest extends AbstractTest { @Autowired private UserService service; @Test public void get() { User user1 = service.create(new User("Vasya", "vasya@mail.ru")); User user2 = service.create(new User("Kolya", "kolya@mail.ru")); getAndPrint(user1.getId()); getAndPrint(user2.getId()); getAndPrint(user1.getId()); getAndPrint(user2.getId()); } private void getAndPrint(Long id) { log.info("user found: {}", service.get(id)); } }

एक छोटा विषयांतर, मैं आमतौर पर एब्सट्रैक्ट क्यों लिखता हूं और इससे सभी परीक्षण विरासत में मिलते हैं।

यदि क्लास का अपना @SpringBootTest एनोटेशन है, तो हर बार ऐसी क्लास के लिए संदर्भ फिर से उठाया जाता है। चूंकि संदर्भ 5 सेकंड, या शायद 40 सेकंड तक बढ़ सकता है, यह किसी भी मामले में परीक्षण प्रक्रिया को बहुत बाधित करता है। इसी समय, आमतौर पर संदर्भ में कोई अंतर नहीं होता है, और जब आप एक ही कक्षा में प्रत्येक समूह का परीक्षण चलाते हैं, तो संदर्भ को पुनरारंभ करने की कोई आवश्यकता नहीं है। यदि हम केवल एक एनोटेशन कहते हैं, तो एक अमूर्त वर्ग के ऊपर, जैसा कि हमारे मामले में है, यह हमें केवल एक बार संदर्भ बढ़ाने की अनुमति देता है।

इसलिए, यदि संभव हो तो मैं परीक्षण / असेंबली के दौरान उठाए गए संदर्भों की संख्या को कम करना पसंद करता हूं।

हमारा परीक्षण क्या करता है? वह दो उपयोगकर्ता बनाता है और फिर उन्हें डेटाबेस से 2 बार खींचता है। जैसा कि हम याद करते हैं, हम @ अस्वीकार्य एनोटेशन डालते हैं, जो लौटे हुए मूल्यों को कैश करेगा। ऑब्जेक्ट को प्राप्त () विधि से प्राप्त करने के बाद, हम ऑब्जेक्ट को लॉग में आउटपुट करते हैं। साथ ही, हम आवेदन (प्राप्त) विधि द्वारा प्रत्येक यात्रा के बारे में जानकारी लॉग करते हैं।

परीक्षण चलाएं। यह हमें कंसोल में मिलता है।

 getting user by id: 1 user found: User(id=1, name=Vasya, email=vasya@mail.ru) getting user by id: 2 user found: User(id=2, name=Kolya, email=kolya@mail.ru) user found: User(id=1, name=Vasya, email=vasya@mail.ru) user found: User(id=2, name=Kolya, email=kolya@mail.ru)

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

2. कैशिंग कुंजी घोषणा

कई पैरामीटर कैश्ड पद्धति में आते हैं। इस मामले में, पैरामीटर निर्धारित करना आवश्यक हो सकता है जिसके द्वारा कैशिंग होगा। हम एक ऐसी विधि के लिए एक उदाहरण जोड़ते हैं जो डेटाबेस में इकट्ठी हुई इकाई को डेटाबेस में सहेजेगी, लेकिन यदि समान नाम वाली कोई इकाई पहले से मौजूद है, तो हम उसे सहेजेंगे नहीं। ऐसा करने के लिए, हम कैशिंग के लिए नाम पैरामीटर को कुंजी के रूप में परिभाषित करेंगे। यह इस तरह दिखेगा:

  @Override @Cacheable(value = "users", key = "#name") public User create(String name, String email) { log.info("creating user with parameters: {}, {}", name, email); return repository.save(new User(name, email)); }

चलो इसी परीक्षण लिखें:

  @Test public void create() { createAndPrint("Ivan", "ivan@mail.ru"); createAndPrint("Ivan", "ivan1122@mail.ru"); createAndPrint("Sergey", "ivan@mail.ru"); log.info("all entries are below:"); service.getAll().forEach(u -> log.info("{}", u.toString())); } private void createAndPrint(String name, String email) { log.info("created user: {}", service.create(name, email)); }

हम तीन उपयोगकर्ता बनाने की कोशिश करेंगे, जिनमें से दो के लिए नाम समान होगा

  createAndPrint("Ivan", "ivan@mail.ru"); createAndPrint("Ivan", "ivan1122@mail.ru");

और दो में से जो ईमेल से मेल खाएगा

  createAndPrint("Ivan", "ivan@mail.ru"); createAndPrint("Sergey", "ivan@mail.ru");

निर्माण विधि में, हम प्रत्येक तथ्य को लॉग करते हैं कि विधि कहा जाता है, और इसके अलावा, हम उन सभी संस्थाओं को लॉग करेंगे जो यह विधि हमारे पास लौटी है। परिणाम इस प्रकार होगा:

 creating user with parameters: Ivan, ivan@mail.ru created user: User(id=1, name=Ivan, email=ivan@mail.ru) created user: User(id=1, name=Ivan, email=ivan@mail.ru) creating user with parameters: Sergey, ivan@mail.ru created user: User(id=2, name=Sergey, email=ivan@mail.ru) all entries are below: User(id=1, name=Ivan, email=ivan@mail.ru) User(id=2, name=Sergey, email=ivan@mail.ru)

हम देखते हैं कि, वास्तव में, एप्लिकेशन ने 3 बार विधि को बुलाया, और केवल दो बार इसमें चला गया। एक बार एक कुंजी एक विधि से मेल खाती है, और यह बस एक कैश्ड मान वापस कर दिया।

3. मजबूर कैशिंग। @CachePut

ऐसी परिस्थितियाँ होती हैं जब हम किसी इकाई के लिए रिटर्न वैल्यू कैश करना चाहते हैं, लेकिन साथ ही हमें कैश को अपडेट करने की आवश्यकता होती है। इस तरह की जरूरतों के लिए, @ कैश एनोटेशन मौजूद है। यह एप्लिकेशन को विधि में पास करता है, जबकि रिटर्न वैल्यू के लिए कैश को अपडेट करते हुए, भले ही यह पहले से ही कैश हो।

कुछ तरीके जोड़ें जिसमें हम उपयोगकर्ता को बचाएंगे। हम उनमें से एक को हमेशा के लिए @Cacheable एनोटेशन के साथ चिह्नित करेंगे, दूसरा @CachePut के साथ।

  @Override @Cacheable(value = "users", key = "#user.name") public User createOrReturnCached(User user) { log.info("creating user: {}", user); return repository.save(user); } @Override @CachePut(value = "users", key = "#user.name") public User createAndRefreshCache(User user) { log.info("creating user: {}", user); return repository.save(user); }

पहली विधि केवल कैश किए गए मानों को वापस करेगी, दूसरा कैश को अपडेट करने के लिए मजबूर करेगा। कैशिंग कुंजी # user.name का उपयोग करके किया जाएगा। हम इसी परीक्षण को लिखेंगे।

  @Test public void createAndRefresh() { User user1 = service.createOrReturnCached(new User("Vasya", "vasya@mail.ru")); log.info("created user1: {}", user1); User user2 = service.createOrReturnCached(new User("Vasya", "misha@mail.ru")); log.info("created user2: {}", user2); User user3 = service.createAndRefreshCache(new User("Vasya", "kolya@mail.ru")); log.info("created user3: {}", user3); User user4 = service.createOrReturnCached(new User("Vasya", "petya@mail.ru")); log.info("created user4: {}", user4); }

पहले से ही वर्णित तर्क के अनुसार, पहली बार "वास्या" नाम वाला एक उपयोगकर्ता createOrReturnCached () विधि के माध्यम से सहेजा जाता है, हम तब एक कैश्ड इकाई प्राप्त करेंगे, और एप्लिकेशन स्वयं विधि में नहीं जाएगा। अगर हम createAndRefreshCache () विधि को कॉल करते हैं, तो कैश "वास्या" नाम की कुंजी के लिए कैश्ड इकाई को कैश में ओवरराइट किया जाएगा। चलो परीक्षण चलाते हैं और देखते हैं कि कंसोल में क्या प्रदर्शित किया जाएगा।

 creating user: User(id=null, name=Vasya, email=vasya@mail.ru) created user1: User(id=1, name=Vasya, email=vasya@mail.ru) created user2: User(id=1, name=Vasya, email=vasya@mail.ru) creating user: User(id=null, name=Vasya, email=kolya@mail.ru) created user3: User(id=2, name=Vasya, email=kolya@mail.ru) created user4: User(id=2, name=Vasya, email=kolya@mail.ru)

हम देखते हैं कि user1 ने डेटाबेस और कैश पर सफलतापूर्वक लिखा है। जब हम उपयोगकर्ता को फिर से उसी नाम से रिकॉर्ड करने की कोशिश करते हैं, तो हमें पहले कॉल (user2) का कैशेड परिणाम मिलता है, जिसके लिए id user1 जैसी ही होती है, जो हमें बताती है कि उपयोगकर्ता लिखित नहीं था, और यह सिर्फ एक कैश है)। अगला, हम तीसरे उपयोगकर्ता को दूसरी विधि के माध्यम से लिखते हैं, जो कि कैश्ड परिणाम के साथ भी, फिर भी विधि को बुलाता है और कैश के लिए एक नया परिणाम लिखता है। यह user3 है। जैसा कि हम देख सकते हैं, उसके पास पहले से ही एक नई आईडी है। जिसके बाद, हम पहली विधि कहते हैं, जो उपयोगकर्ता 3 द्वारा जोड़ा गया नया कैश लेता है।

4. कैश से हटाना। @CacheEvict

कभी-कभी कैश में कुछ डेटा को अपडेट करना कठिन हो जाता है। उदाहरण के लिए, एक इकाई पहले ही डेटाबेस से हटा दी गई है, लेकिन यह अभी भी कैश से सुलभ है। डेटा स्थिरता बनाए रखने के लिए, हमें कम से कम हटाए गए डेटा को कैश में संग्रहीत करने की आवश्यकता नहीं है।

सेवा के लिए कुछ और विधियाँ जोड़ें।

  @Override public void delete(Long id) { log.info("deleting user by id: {}", id); repository.deleteById(id); } @Override @CacheEvict("users") public void deleteAndEvict(Long id) { log.info("deleting user by id: {}", id); repository.deleteById(id); }

पहला केवल उपयोगकर्ता को हटा देगा, दूसरा भी इसे हटा देगा, लेकिन हम इसे @CacheEvict एनोटेशन के साथ चिह्नित करेंगे। एक परीक्षण जोड़ें जो दो उपयोगकर्ताओं को बनाएगा, जिसके बाद एक को एक सरल विधि के माध्यम से हटा दिया जाएगा, और दूसरा एक एनोटेट विधि के माध्यम से। उसके बाद, हम इन उपयोगकर्ताओं को प्राप्त () विधि के माध्यम से प्राप्त करेंगे।

  @Test public void delete() { User user1 = service.create(new User("Vasya", "vasya@mail.ru")); log.info("{}", service.get(user1.getId())); User user2 = service.create(new User("Vasya", "vasya@mail.ru")); log.info("{}", service.get(user2.getId())); service.delete(user1.getId()); service.deleteAndEvict(user2.getId()); log.info("{}", service.get(user1.getId())); log.info("{}", service.get(user2.getId())); }

यह तर्कसंगत है कि चूंकि हमारा उपयोगकर्ता पहले से ही कैश है, इसलिए निष्कासन हमें इसे प्राप्त करने से नहीं रोकेगा, क्योंकि यह कैश है। आइए देखते हैं लॉग्स।

 getting user by id: 1 User(id=1, name=Vasya, email=vasya@mail.ru) getting user by id: 2 User(id=2, name=Vasya, email=vasya@mail.ru) deleting user by id: 1 deleting user by id: 2 User(id=1, name=Vasya, email=vasya@mail.ru) getting user by id: 2 javax.persistence.EntityNotFoundException: User not found by id 2

हम देखते हैं कि आवेदन सुरक्षित रूप से दोनों बार () विधि से गया और स्प्रिंग ने इन संस्थाओं को कैश कर दिया। इसके बाद, हमने उन्हें विभिन्न तरीकों से हटा दिया। हमने पहले वाले को सामान्य तरीके से हटा दिया, और कैश्ड मान बना रहा, इसलिए जब हमने id 1 के तहत उपयोगकर्ता प्राप्त करने का प्रयास किया, तो हम सफल हुए। जब हमने उपयोगकर्ता 2 प्राप्त करने का प्रयास किया, तो विधि ने EntityNotFoundException लौटा दी - कैश में ऐसा कोई उपयोगकर्ता नहीं था।

5. समूह बनाना सेटिंग्स। @Caching

कभी-कभी एक एकल विधि के लिए कई कैशिंग सेटिंग्स की आवश्यकता होती है। इन उद्देश्यों के लिए @ कोचिंग एनोटेशन का उपयोग किया जाता है। यह कुछ इस तरह दिख सकता है:

  @Caching( cacheable = { @Cacheable("users"), @Cacheable("contacts") }, put = { @CachePut("tables"), @CachePut("chairs"), @CachePut(value = "meals", key = "#user.email") }, evict = { @CacheEvict(value = "services", key = "#user.name") } ) void cacheExample(User user) { }

यह समूह एनोटेशन का एकमात्र तरीका है। अगर आप किसी चीज़ को ढेर करने की कोशिश करते हैं

  @CacheEvict("users") @CacheEvict("meals") @CacheEvict("contacts") @CacheEvict("tables") void cacheExample(User user) { }

तब IDEA आपको बताएगा कि ऐसा नहीं है।

6. लचीला विन्यास। CacheManager

अंत में, हमने कैश निकाला, और यह हमारे लिए कुछ समझ से परे और डरावना था। अब चलो हुड के नीचे देखें और देखें कि हम कैशिंग को सामान्य रूप से कैसे कॉन्फ़िगर कर सकते हैं।

ऐसे कार्यों के लिए, एक CacheManager है। यह जहाँ भी स्प्रिंग कैश है वहाँ मौजूद है। जब हमने @EnableCache एनोटेशन जोड़ा, तो इस तरह के कैश मैनेजर को स्प्रिंग द्वारा स्वचालित रूप से बनाया जाएगा। हम इसे सत्यापित कर सकते हैं यदि हम ApplicationContext को ऑटो-रैप करते हैं और इसे ब्रेकपॉइंट पर खोलते हैं। अन्य डिब्बे में, कैशमैनेजर बीन होगा।

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

हम, बदले में, हैबर और प्रोग्रामर के साथ अपना कैश मैनेजर बना सकते हैं, और फिर इसे हमारे स्वाद के लिए ठीक कर सकते हैं।

  @Bean("habrCacheManager") public CacheManager cacheManager() { return null; }

यह केवल यह चुनना है कि हम किस कैश मैनेजर का उपयोग करेंगे, क्योंकि उनमें से बहुत सारे हैं। मैं सभी कैश प्रबंधकों को सूचीबद्ध नहीं करूंगा, यह जानना पर्याप्त होगा कि ऐसे हैं:

SimpleCacheManager सबसे सरल कैश प्रबंधक है, जो सीखने और परीक्षण के लिए सुविधाजनक है।
ConcurrentMapCacheManager - Lazily प्रत्येक अनुरोध के लिए दिए गए इंस्टेंस को इनिशियलाइज़ करता है। यह परीक्षण और सीखने के लिए भी सिफारिश की जाती है कि कैश के साथ कैसे काम किया जाए, साथ ही हमारे जैसे कुछ सरल कार्यों के लिए भी। कैश के साथ गंभीर काम के लिए, नीचे कार्यान्वयन की सिफारिश की गई है।
JCacheCacheManager , EhCacheCacheManager , CaffeineCacheManager गंभीर "पार्टनर पार्टनर" कैश मैनेजर हैं, जो लचीले रूप से अनुकूलन योग्य हैं और बहुत विस्तृत कार्यों के कार्य करते हैं।

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

तो, चलो हमारे कैश प्रबंधक को फिर से बनाएँ।

  @Bean("habrCacheManager") public CacheManager cacheManager() { return new ConcurrentMapCacheManager(); }

हमारा कैश मैनेजर तैयार है।

7. कैश सेटअप। जीवन समय, अधिकतम आकार और इतने पर।

ऐसा करने के लिए, हमें एक काफी लोकप्रिय Google अमरूद पुस्तकालय की आवश्यकता है। मैंने सबसे आखिरी लिया।

 compile group: 'com.google.guava', name: 'guava', version: '28.1-jre'

कैश मैनेजर बनाते समय, हम createConcurrentMapCache विधि को फिर से परिभाषित करते हैं, जिसमें हम अमरूद से CacheBuilder को कॉल करेंगे। इस प्रक्रिया में, हमें निम्नलिखित तरीकों को शुरू करके कैश मैनेजर को कॉन्फ़िगर करने के लिए कहा जाएगा:

maxSize - उन मानों का अधिकतम आकार जो कैश हो सकते हैं। इस पैरामीटर का उपयोग करके, आप डेटाबेस और जेवीएम रैम पर लोड के बीच एक समझौता खोजने का प्रयास कर सकते हैं।
refreshAfterWrite - कैश में मूल्य लिखने के बाद का समय, जिसके बाद यह स्वचालित रूप से अपडेट हो जाएगा।
expireAfterAccess - अंतिम कॉल के बाद मूल्य का जीवनकाल।
expireAfterWrite - कैश में लिखने के बाद मूल्य का जीवनकाल। यह वह पैरामीटर है जिसे हम परिभाषित करेंगे।

और अन्य।

हम प्रबंधक को रिकॉर्ड के जीवनकाल में परिभाषित करते हैं। लंबे समय तक इंतजार न करने के लिए, 1 सेकंड सेट करें।

  @Bean("habrCacheManager") public CacheManager cacheManager() { return new ConcurrentMapCacheManager() { @Override protected Cache createConcurrentMapCache(String name) { return new ConcurrentMapCache( name, CacheBuilder.newBuilder() .expireAfterWrite(1, TimeUnit.SECONDS) .build().asMap(), false); } }; }

हम इस मामले के लिए एक परीक्षण लिखते हैं।

  @Test public void checkSettings() throws InterruptedException { User user1 = service.createOrReturnCached(new User("Vasya", "vasya@mail.ru")); log.info("{}", service.get(user1.getId())); User user2 = service.createOrReturnCached(new User("Vasya", "vasya@mail.ru")); log.info("{}", service.get(user2.getId())); Thread.sleep(1000L); User user3 = service.createOrReturnCached(new User("Vasya", "vasya@mail.ru")); log.info("{}", service.get(user3.getId())); }

हम डेटाबेस के लिए कई मान सहेजते हैं, और यदि डेटा कैश है, तो हम कुछ भी नहीं बचाते हैं। सबसे पहले, हम दो मूल्यों को बचाते हैं, फिर हम 1 सेकंड इंतजार करते हैं जब तक कि कैश मृत नहीं हो जाता है, जिसके बाद हम एक और मूल्य बचाते हैं।

 creating user: User(id=null, name=Vasya, email=vasya@mail.ru) getting user by id: 1 User(id=1, name=Vasya, email=vasya@mail.ru) User(id=1, name=Vasya, email=vasya@mail.ru) creating user: User(id=null, name=Vasya, email=vasya@mail.ru) getting user by id: 2 User(id=2, name=Vasya, email=vasya@mail.ru)

लॉग दिखाते हैं कि हमने पहले एक उपयोगकर्ता बनाया था, फिर हमने एक और कोशिश की, लेकिन चूंकि डेटा कैश था, इसलिए हमने इसे कैश से प्राप्त किया (दोनों मामलों में, जब बचत और डेटाबेस से प्राप्त हो रहा है)। फिर कैश खराब हो गया, क्योंकि एक रिकॉर्ड हमें उपयोगकर्ता की वास्तविक बचत और वास्तविक प्राप्ति के बारे में बताता है।

8. संक्षेप करने के लिए

जल्दी या बाद में, डेवलपर को परियोजना में कैशिंग को लागू करने की आवश्यकता का सामना करना पड़ता है। मुझे उम्मीद है कि यह लेख आपको विषय को समझने और कैशिंग मुद्दों को अधिक साहसपूर्वक देखने में मदद करता है।

यहाँ परियोजना का गित्बम: https://github.com/promoscow/cache

स्प्रिंग कैश: कैशिंग कनेक्ट करने से लेकर कैश मैनेजर के लचीले विन्यास तक