Summary of cache-related issues-1

1. Cache, more to solve the pressure of db 2 points

a, repeated requests within the time window

b, absolute concurrent data access scenario

The cache-misses faced by the cache bypass cache-aside
is the solution under concurrency:

1. distributed lock,
2. Bloom filter,
3. Expires must be appended,
4. hotspot identification

2. Double writing scheme:

1. Write the cache first, then write the database

1. The write cache is successful, the database write fails, and the cache consistency problem;
2. A bit violates the meaning of cache, the principle of data proximity. * , do not use redis as a cache, but as a store. 1. Too much data in the cache causes the cache to be crowded. 2. For example, the items that have not been reviewed or sorted are placed at the front of the cache.

2. Write to the database first, then write to the cache

1. The database is stored successfully, but the write cache order is easy to be disordered, and data inconsistency may easily occur in concurrent scenarios;
2. A bit violates the meaning of cache, the principle of data proximity.

3. Write the database first, delete the cache, take the expiration time and then write the result

question:

1. Used to delete, similar to the I state of MESI, the system cache is not updated.
2. The second step will fail to delete, redis is used as a cache, there is no such data, so it does not matter whether the deletion fails
3. Cache and db are not mandatory, depending on the tolerance, they also conform to CAP, P must exist, and cache-aside belongs to AP.

Solution: Because in the cache-aside model, the above problems are remedied by the read mode (because the data has an expiration time), note: the expiration time must be added -> trigger cache-messed (cached data cannot be found, it must be triggered, cache penetration , cache puncture, cache avalanche, warm-up, etc. will also be triggered).

4. Write database first, canal synchronization (synchronization tool heterogeneous synchronization, monitor database binlog)

Concept: The cache must store hot data, and the amount of read request data directly reflects the hot data, and the data system needs to bury the statistics of the hot data.
Problem: It is impossible to judge whether the data is hot data, resulting in a full amount of
solution 1: canal -> mq (sequential consumption, no batch processing) -> redis

java_cache_and_cpu_mesi (knowledge supplement) :

volatile visibility (non-caching) directly writes to the main memory without going through the cache; so it can go directly to the memory.
Advantages of cpu MESI (cache consistency) tuning:

References: The cache-aside
system does not enable EMSI by default, and the cache will store a large amount of data cache_line reaches a certain amount, and then give it to the main memory.
1.1 volatile When there is no MESI, the full read scene will trigger the main memory read.
1.2 volatile When there is MESI, in the full-read scenario, go to the cache buffer first to get it and then read it from the main memory. The main memory will synchronize the data in the cache within a certain period of time, and the query speed will be greatly improved.

3. Redis data security and consistency issues

Redis builds an entity model model, which can be backed up using db. Even if redis hangs, the backup can be restored in time.

> Solution 1: Distributed database, instant storage of redis content. There is a problem that the pressure on the database is high, and the data is relatively fragmented.

redis -> (N) DB

> Scheme 2: rides use MQ, different tasks use different senders, and the consumer consumes the data that can directly calculate the results in the order of Queue. Reduce the amount of database, order, reduce fragmented data, data security.

redis -> (N) mq -> (N) DB

4. What does reids store, based on cache

1. Static dictionary class, latitude class data

> a Do not set an expiration time

> b The elimination strategy is set to LRU/LFU based on expired data (AKF principle: isolation is required)

2. Preheating, storing hot data, and identifying hot data is very important.

> a Reading and writing diffusion, selection

>> Write diffusion. After writing the database, it is necessary to write redis. Scenario: There must be concurrency in the future, and the static dictionary data is modified. (Platform tenant existence level)

>> Read diffusion. In the cache-aside model, cache-misses occur during the read process. Note: It is also necessary to identify that redis stores hot data, and hot data is the frequency of read requests.

Extension: If a single cache is used:

read->def->LocalCache has oom problems

read->def- > Redis Although there is an LRU (elimination mechanism), it will cause redis performance to decline