The Ehcache distributed cache used in the original project has the disadvantage of wasting memory and Ehcache using the memory of the JVM process, so memory usage is restricted.
There is a scenario in the business where you sometimes want to update a business entity to invalidate the corresponding cache, in which case the update cache can only be one of the updated entities if the corresponding business entity cache has multiple machines.
Based on the above points, the project wants to switch to a centralized cache.
Centralized cache service-side architecture is: NetEase lbs+twemproxy+redis cluster.
The cache client is using spring Data Redis.
Because the Twemproxy agent itself does not support multi operations, the Rediscache put method is covered in the project.
Our side of the project with the Dubbo Shard governance Service, you want the cache defined between each service to be separate. So here we introduce the concept of group groups by covering the GetCache method of Rediscachemanager.
Each specific service module has a group name, such as the Commodity Module group name: Itemcenter.
This guarantees the independence of each inter-service cache, and different modules can use the same cache name.
Monitoring section, one is to monitor the REDIS layer and business-independent, there is a specific business party-related data monitoring.
We have developed a business layer of monitoring to list all cache blocks, listing the name of each business cache block and the number of corresponding element objects.
and provides a button to clear the cache block, when the program has a bug in time to clear the recovery.
Spring context 4.0.8.RELEASE version of spring data Redis has a bug, when the Redis cache hangs, normal business access to a caching method, because rediscache in the access operation when the exception was thrown, but not captured, As a result, the entire business access is then hung up.
The latest version of 4.1.3.RELEASE has been fixed.
Production environment Ehcache migration to centralized Redis clusters