Reprinted from https://blog.csdn.net/wang0112233/article/details/79558612
https://www.sohu.com/a/230787856_231667
Today they learned a lot, I feel avalanche and penetration is very interesting to understand is relatively clear, and then I searched for some information, give myself a universal
We usually use the cache expiration time + strategies to help us accelerate the access speed of the interface, reducing the back-end load, while ensuring the update function
Cache penetration
Caching system, according to the KEY to query VALUE, VALUE when KEY corresponding non-existent and certainly a lot of time, it will cause a lot of pressure on the back end KEY amount of concurrent requests.
(An inevitable query data does not exist, such as paper table, query id does not exist, every time access to DB, if someone malicious damage, is likely to impact directly on the DB.)
Since the cache miss, every time the query persistence layer. And thus lose the meaning of the cache.
Solution:
1, the buffer layer buffer null.
- Cache too many null values, take up more space. (Optimization: expiration time to a null value)
- the update code memory layer, the buffer layer, or a null value. (Optimization: null automatically deleted when the background is set, and the value into the cache)
2, all of the database query, put the bloom filter. When a query request comes, through the first Bloom filter checks if this condition request is present, then continue, if not, discards.
Remarks:
For example the database of 10,000 condition, to a little more than the capacity of the Bloom filter size is set larger 10,000, such as 12,000.
For setting the rate of false positives, according to the actual project, and hardware facilities to specific decisions. But it must not be set to 0, and the smaller the rate of false set, with the hash function with a longer length of the array are more, then the hardware requirements, the intermediate memory are correspondingly high.
private static BloomFilter<Integer> bloomFilter = BloomFilter.create(Funnels.integerFunnel(), size, 0.0001);
With size with false positives, then the Bloom filter will produce a corresponding hash function with an array.
In summary: We can use the Bloom filter, the breakdown redis cache control within a tolerable range.
Avalanche cache (cache miss)
If the cache is concentrated over a period of time has expired, a lot of cache penetration occurs, all queries fall on the database, resulting in a cache avalanche.
After the buffer layer dawdle away, fled the traffic will be like bison, like, playing to the back-end storage
Solution:
- After a cache miss, by locking to control the number of threads or queue database read write cache. For example, a key for allowing only one thread to query the data and write cache, other threads wait.
- By caching mechanism can reload advance to update the cache, and then before the big concurrent access manually trigger an impending load the cache
- Different key, to set different expiry time for the cache invalidation point in time as uniform as possible
- Do secondary cache, or double caching policy. A1 is the original cache, A2 copy is cached, when A1 fails, access to A2, A1 cache expiration time is set short-term, A2 to long-term.
Hot key
(1) This key is a hot key (for example, an important news, a hot gossip, etc.), so this key traffic can be very large.
(2) Construction of cache will take some time. (It may be a complex calculation, such as complex sql, the IO times, a plurality of dependent (various interface) and the like)
So there will be a fatal problem: a cache miss at the moment, a large number of threads to build the cache (see below), resulting in back-end load increase, and may even make the system crash.
Solution:
1. Use the mutex (mutex key): This solution is relatively simple idea is to only allow one thread to build the cache, other threads waiting for Threading Building cached executed, retrieve data from the cache on it
2. "early" exclusive locks (mutex key): setting a timeout value (TIMEOUT1) within the value, timeout1 smaller than the actual memcache timeout (timeout2). When reading from cache to timeout1 find that it has expired when extended timeout1 immediately and reset the cache. And then loads the data from the database and provided to the cache.
3. "never expires":
Here the "never expires," contains two meanings:
(1) from redis point of view, it does not set an expiration time, which ensures that the hot key expired without problems, or "physical" But of.
(2) From a functional point of view, if not expired, that does not become static yet? So we expiration time there is a corresponding value in the key, if it is found to be expired, to build the cache through a background asynchronous thread, which is the "logical" Expired
4. Resource Protection: Isolation can be done to protect the main thread pool resources, if the application to build the cache is also not a bad idea.
Four scenarios comparison:
As a large amount of concurrent Internet applications, we have three goals:
1. speed up user access speed, improve the user experience.
2. Lower the back-end load, to ensure a smooth system.
3. ensure that the data "as" timely update (or not exactly the same, depending on the business, not the technology.)
So the four methods mentioned in Section II, the following comparison can be done, or if it is: There is no best, only the most suitable.
| solution | advantage | Shortcoming |
| Simple Distributed Lock (Tim yang) | 1. Simple ideas 2. ensure consistency |
1. The increase in code complexity 2. there is a risk of deadlock 3. there is a risk of blocking the thread pool |
| Another plus expiration time (Tim yang) | 1. To ensure consistency | Ditto |
| But on the (paper) | 1. asynchronous build the cache, do not block the thread pool |
1. does not guarantee consistency. 2. The code complexity increases (each value must maintain a timekey). 3. take up some memory space (each value must maintain a timekey). |
| Resource isolation component hystrix (paper) | 1. hystrix technology is mature, effectively guarantee the back-end. 2. hystrix monitoring stronger.
|
1. partial access existence downgrade policies. |
to sum up
1. Hot Key + expires + complex build process buffer => mutex key problem
2. Construction of a cache thread to do it.
3. The four solutions: There is no best only the most suitable.
references:
Breakdown / penetration: http: //blog.csdn.net/kl1106/article/details/79478901
Avalanche: http: //blog.csdn.net/qq_36858183/article/details/78424690
热点key:http://carlosfu.iteye.com/blog/2269678‘