Cache Avalanche
The cache avalanche may be because the data is not loaded into the cache, or the cache fails in a large area at the same time, which causes all requests to check the database, resulting in high CPU and memory load of the database, or even downtime.
Solutions:
1. Use lock count, or use a reasonable number of queues to avoid too much pressure on the database when the cache is invalidated. Although this method can relieve the pressure on the database, it also reduces the throughput of the system.
2. Analyze user behavior and try to distribute the failure time points evenly. Avoid cache avalanches.
3. If it is because a cache server is down, you can consider being the master and backup, such as: redis master and backup, but double cache involves the problem of update transactions, update may read dirty data, which needs to be solved.
cache penetration
Cache penetration refers to user query data, which is not available in the database, and naturally not in the cache. In this way, when users query, they cannot find it in the cache, and they have to go to the database to query each time.
Solutions:
1. If the query database is also empty, directly set a default value and store it in the cache, so that the second time you get the value in the buffer, you will not continue to access the database. This method is the most simple and rude.
2. According to the rules of the cached data Key. For example, our company is a set-top box , and the cached data uses Mac as the key. Mac has rules. If it does not meet the rules, it will be filtered out, so that some queries can be filtered. When doing cache planning, if the Key has certain rules, this method can be adopted. This method can only relieve a part of the pressure, filtering out queries that have nothing to do with the system, but it cannot be cured.
3. The Bloom filter is used to hash all possible data into a large enough BitSet, and the data that does not exist will be intercepted, thus avoiding the query pressure on the underlying storage system. About Bloom filter, see for details: BitSet-based Bloom Filter (Bloom Filter)
Large concurrent cache penetration can cause cache avalanches.
cache warm-up
It is relatively simple in the case of a stand-alone web system.
Solutions:
1. Directly write a cache refresh page, and manually operate it when going online.
2. The amount of data is not large and can be loaded when the WEB system is started.
3，搞个定时器定时刷新缓存，或者由用户触发都行。
分布式缓存系统，如Memcached，Redis，比如缓存系统比较大，由十几台甚至几十台机器组成，这样预热会复杂一些。
解决思路：
1，写个程序去跑。
2，单个缓存预热框架。
缓存预热的目标就是在系统上线前，将数据加载到缓存中。
缓存算法
FIFO算法：First in First out，先进先出。原则：一个数据最先进入缓存中，则应该最早淘汰掉。也就是说，当缓存满的时候，应当把最先进入缓存的数据给淘汰掉。
LFU算法：Least Frequently Used，最不经常使用算法。
LRU算法：Least Recently Used，近期最少使用算法。请查看：Memcached之你真正理解LRU吗(4)
LRU和LFU的区别。LFU算法是根据在一段时间里数据项被使用的次数选择出最少使用的数据项，即根据使用次数的差异来决定。而LRU是根据使用时间的差异来决定的
有兴趣的朋友可以加入我的互联网架构群：477819525
内有大量java初级，进阶，高级，架构视频和书籍资料，大家一起交流学习。