This is the 12th day of my participation in Gwen Challenge

Usage scenarios

Reduce back-end load: Cache high-consumption SQL results, such as join result set/group statistics

Accelerated request response

The bulk write is merged into the bulk write, such as the counter Redis accumulated before the bulk write DB

Cache update strategy

  • LRU(Least Recently Used), according to the historical access records of data to eliminate data, the core idea is “if the data has been accessed Recently, then the probability of being accessed in the future is higher, then delay its elimination time” – LRU cache update

  • LFU(Least Frequently Used) is Used to eliminate data based on its historical access frequency. If data has been accessed many times in the past, it will be accessed more Frequently in the future. – LFU cache updates

  • FIFO, which updates cached data on a “first in, first out” basis

  • – expire

    • Proactive update – Development control lifecycle

    • Extension: Cache contamination – Cache contamination reduces cache utilization, reads infrequently used data into the cache, and removes frequently used data from the cache, which directly reduces the system’s data hit ratio

Cache penetration problem

Scenario [Key does not exist, high concurrent query database]

Cache penetration refers to that a large number of concurrent queries are executed using non-existent keys. As a result, the cache cannot be hit and each request must be passed to the back-end database, which causes great pressure on the database and even causes the database service to be overwhelmed.

The solution

Distributed queues and distributed locks

At the interface layer, API traffic limiting, DDOS defense, interface frequency limiting, gateway blacklist, user authorization, and ID check are implemented

Cache empty objects:

If a query returns null data (either nonexistent or a system failure), the null result is still cached, but its expiration time is short, no more than five minutes. The default values that are set directly are stored in the cache so that a second fetch in the cache will have a value, without further access to the database. Delete or update the null cache value ** when modifying or adding key data

Existing problems:

  1. More keys are required, so shorter expiration times are usually set

  2. Cache layer and storage layer data “short-term” inconsistent

Borrowing diagram: High availability architecture

Bloom filter:

All possible query parameters are stored in hash format and verified at the control layer. If they do not match, they are discarded, thus avoiding query pressure on the underlying storage system. Redis, for example, can use bitmaps to implement bloom filters.

Borrowing diagram: High availability architecture

Cache breakdown problem

[High concurrent query database when a single hot key fails]

At the moment when the cache expires, a large number of requests are generated for an existing hot key. These requests will penetrate into the database, causing a sudden increase in the instantaneous database request volume.

The solution

Using distributed locks

Ensure that distributed locks are used to ensure that only one thread can query the backend service for each key at the same time. Other threads do not have the permission to obtain the lock and only need to wait. This high concurrent pressure is directly transferred to the distributed lock, and the pressure on the distributed lock is very large. The request that has acquired the lock successfully writes the data to Redis, notifies the request that has not acquired the lock directly to obtain the data from Redis

Using local cache (two-level cache)

Double click caching mechanism

Hotspot does not expire

Set the hotspot data to never expire or asynchronously extend the expiration time.

** life renewal before expiration

(In value, set the expiration time to t1, which is smaller than t0. When T1 expires, extend T1 and update the cache.)

Cache avalanche problem

Cache refers to an avalanche, due to the buffer layer is carrying a large number of requests, effectively protecting the storage layer, but if the caching tier for some reason can not provide the whole service (probably machine downtime or a large amount of cache (key) at the same time the failure – expired), so all the request will reach the storage layer, storage layer will call volumes, The storage tier will also hang.

Scenario [Multiple keys fail simultaneously, high concurrency database query]

Cache avalanche refers to a situation in which a cache server restarts (without persistence) or a large number of caches fail at a certain point in time, suddenly putting too much pressure on the database or even crashing the database.

The solution

  1. Use a random dynamically distributed failure time for unused data

  2. Deploy our key using clustered allocation

  3. Using level 2 Caching

  4. Using distributed locks

  5. Data preheating: You can use the reload mechanism to update the cache in advance, and then manually trigger the loading of different cache keys before large concurrent access, set different expiration times, so that the cache failure time is as uniform as possible

  6. The dependency isolation component limits and degrades the back-end flow by locking or queuing the number of threads that read the database write cache after the cache expires. For example, only one thread is allowed to query data and write to the cache for a key, while the other threads wait.