Cache changes (JVM local cache->Redis distributed cache)

In a requirement modification, the downstream service additionally put forward requirements for the effective time of a certain business data cache.

Original JVM design plan:

Using jvm local caching mechanism, scheduled tasks are refreshed every 30 seconds

Now redis solution:

1. Because this business data cache is used in many places, the usage cannot be changed too much.
2. Because it is a distributed deployment, if you only use the jvm cache, you cannot update the cached data in other servers, and it cannot take effect immediately.
3. The reason for not using the second-level cache: The reason is the same as the second one. If jvm is used first, even if redis is updated, other servers will use the jvm cache first (also why is the second-level cache used?: Because the jvm local cache is faster That’s it, it has to increase the burden on the architecture, just for a requirement)

So: directly change the maintenance of jvm business cache to redis for maintenance

Then you need to consider the effective time of active refresh and passive refresh, etc.

1. Passive refresh: Still using the scheduled task mechanism of jvm cache, updated every 30 seconds (no changes, using the original mechanism)
2. Active refresh: Since the effective time is one second, the cache needs to be actively refreshed immediately after modifications and updates (there are few changes, maintenance is all in one project, and there is no need to use anything to monitor the mysql table)

Gains from modification:

1. Problems with obtaining injection in tool classes BeanUtil.getBean(RedisTemplate.class);
2. redis Pipeline pipeline speed up redisTemplate.STRINGS.setEx(redisCacheList,refreshTime);
3. Segmentation idea: smaller granularity, such as: redis. The data stored in one table by one key is too large, so it is divided according to the key key in the table.