Redis strengthening (cache principle, cache elimination, cache penetration, cache breakdown, cache avalanche, Redis persistence)

Redis Hardening

Cache Usage Principles

When and what kind of data can be stored in Redis?

1. The amount of data should not be too large

2. The more frequently used, the more worthwhile Redis saves this data

3. The data stored in Redis is generally not frequently modified in the database

Cache Elimination Policy

Redis stores data in memory, and the capacity of memory is limited. If the memory of the Redis server is full and you need to save new data to Redis now, how to do it is the cache elimination strategy.

• noeviction: returns an error **(default)**

If we don't want it to make mistakes, we can set it to delete the information that meets certain conditions, and then save the new information.

• allkeys-random: Randomly delete data from all data
• volatile-random: Randomly delete data from data with an expiration time
• volatile-ttl: delete the data with the least remaining valid time
• allkeys-lru: Delete the data with the longest last use time from the present among all data
• volatile-lru: delete the data with the longest time since the last use from the data with an expiration time
• allkeys-lfu: Delete the least frequently used data among all data
• volatile-lfu: Delete the least frequently used data with an expiration time

Time To Live (ttl)

Least Recently Used (lru)

Least Frequently Used (lfu)

cache penetration

The so-called cache penetration means that a business request first queries redis, and redis does not have this data, then it goes to query the database, but the database does not have it either.

Under normal business conditions, after a request queries data, we can save the data in Redis, and subsequent requests can be directly queried from Redis without connecting to the database. However, once the above penetration phenomenon occurs, it is still necessary to connect to the database. Once connected to the database, the overall efficiency of the project will be affected. If there are malicious requests and high-concurrency access to data that does not exist in the database, in serious cases, the current server may be down.

The mainstream solution in the industry: Bloom filter.

How to use Bloom filter

1. Generate a Bloom filter for all existing data and save it in Redis;

2. In the business logic layer, check whether the id is in the Bloom filter before judging Redis;

3. If the Bloom filter judges that the id does not exist, return it directly;

4. If the Bloom filter judges that the id exists, perform subsequent business execution.

cache breakdown

A plan to save data in Redis, business query, the queried data does not exist in Redis, but exists in the database. In this case, it needs to be queried from the database and then saved to Redis.

Cache shoot-through itself is not a catastrophic problem, nor is it an unacceptable phenomenon.

cache avalanche

As mentioned above, it is normal for a small amount of breakdown to occur at the same time, but if a large number of breakdowns occur at the same time, it will be as follows:

The so-called cache avalanche refers to the data stored in Redis. A large amount of data expires at the same time in a short period of time. As shown in the figure above, the information that should have been fed back by Redis, because Avalanche has visited Mysql, Mysql cannot bear it, which may cause an exception. To avoid this, you need to avoid a large number of cache invalidations at the same time.

The reason why a large number of caches are invalidated at the same time: it is usually caused by setting the same validity period for the data loaded at the same time

We can prevent a large amount of data from being invalidated at the same time by adding a random number when setting the validity period.

Redis persistence

Redis saves information in memory. The characteristic of memory is that once the power is turned off, all information is lost. For Redis, after all data is lost, and then reloaded, all data needs to be re-queried from the database. This operation is not only time-consuming, but also puts a lot of pressure on the database.

Moreover, for some businesses, the data is first saved in Redis and then synchronized with the database at intervals. If Redis is powered off, the data during this period will be completely lost. In order to prevent the restart of Redis from causing additional pressure on the database and data loss, Redis supports the persistence function.

The so-called persistence is to save the data saved in Redis on the hard disk of the current Redis server in a specified way. If it exists on the hard disk, the data will not be lost when the power is off. When Redis is started again, the information in the hard disk will be used to restore the data.

There are two strategies for Redis to implement persistence:

RDB:(Redis Database Backup)

RDB is essentially a database snapshot (that is, all data in Redis is currently converted into binary objects and stored on the hard disk). By default, each backup will generate a dump.rdb file. When Redis is powered off or down, when it restarts, it will restore the data from this file and get all the contents of dump.rdb. To achieve this effect, we can add the following information to the Redis configuration file:

save 60 5

In the above configuration, 60 means seconds, and 5 means the number of times the Redis key has been modified.

Configuration effect: If more than 5 keys are modified within 1 minute, the rdb database snapshot program will be started.

advantage:

• Because it is the binary format of the overall Redis data, data recovery is performed as a whole.

shortcoming:

• The generated rdb file is a file on the hard disk, and the read and write efficiency is low;
• If there is a sudden power failure, only the data in the last generated rdb can be restored.

AOF(Append Only File):

The AOF strategy is to back up all the commands (logs) that Redis has run and save them on the hard disk; so that even if Redis is powered off, we can restore it to the state before the power failure based on the logs that have been run. We can add the following configuration information to the Redis configuration file:

appendonly yes

After this setting, the log of the command that has been executed can be saved. In theory, any command that has been run can be restored, but in reality, when Redis is very busy, we will cache the log command and send it to the backup as a whole, reducing the number of io to improve the performance of backup and the impact on Redis performance. In actual development, the configuration generally adopts the strategy of sending log files once per second, and the data will be lost for at most 1 second when the power is off.

advantage:

​ Compared with RDB, less information is lost.

shortcoming:

​ Because the running log is saved, it takes up a lot of space.

In actual development, RDB and AOF can be enabled at the same time or selectively.

Redis' AOF supports AOF rewrite to reduce the size of log files

Simply put, it is to delete invalid statements in the log, which can reduce the occupied space

Redis storage principle

When we write java code business, if we need to find an element from a collection of multiple elements, or check the absence of a key, it is recommended that we use HashMap or HashSet, because this data structure has the highest query efficiency, because it is used internally.

"hash table"

The following figure is the storage principle of the hash table

The more slots, the higher the query performance when there are more elements. HashMap has 16 slots by default.

The bottom layer of Redis also uses such a hash table structure to store data. Redis divides the memory into 16384 areas (similar to hash slots), calculates a value for the key of the data using the CRC16 algorithm, and takes the remainder 16384. The result is 0~16383, so that Redis can search for elements very efficiently.

Redis cluster

The minimum state of Redis is a server. The running state of this server directly determines whether Redis is available. If it is offline, Redis will not be available for the entire project, and the system will face a crash. In order to prevent this from happening, we can prepare a backup machine.

master-slave replication

That is, when the master (master) is working, arrange a backup machine (slave) to synchronize data in real time. In case the master goes down, we can switch to the backup machine to run.

Disadvantages: In such a scheme, the slave node has no real effect. As long as the master does not go down, it is the same as nothing, and it does not reflect the value.

read-write separation

In this way, the slave can also share the work of the master when the master is working normally, but if the master is down, in fact, the switch between the master and standby machines still requires manual intervention, which still takes time. So if you want to achieve automatic switching when a failure occurs, you must have a configured fixed strategy.

Sentinel mode : failover automatic switching

The sentinel node sends requests to all nodes at regular intervals. If the response is normal, the node is considered to be normal. If there is no response, the node is considered to have a problem. The sentinel can automatically switch between the main and standby machines. If the master of the host goes offline, it will automatically switch to the standby machine for operation.

However, if the sentinel makes a misjudgment when judging the status of the node, it will mistakenly take the master offline and reduce the overall operating performance, so the possibility of the sentinel's misjudgment should be reduced.

Sentinel Cluster

We can make sentinel nodes into a cluster, and multiple sentinels vote to decide whether to go offline for a certain node. In the sentinel cluster, each node will send ping requests to the master and slave regularly. If more than two sentinel nodes (half of the nodes in the cluster) do not receive a normal response to the ping request, the node will be considered offline. When the business continues to expand and the concurrency continues to increase.

Sharded cluster

When only one node supports write operations and cannot meet the overall performance requirements, the system performance will reach the bottleneck. At this time, we need to deploy multiple nodes that support write operations for sharding to improve the overall performance of the program.

Fragmentation means that each node is responsible for a different area.

For example, Redis slot 0~16383:

MasterA is responsible for 0~5000

MasterB is responsible for 5001~10000

MasterC is responsible for 10001~16383

A key can only get fixed results according to the CRC16 algorithm, and the data must be found on the specified server.

With this cluster structure, we can process business requests more stably and efficiently.

In order to save the cost of the sentinel server, some companies directly add the sentinel function in the Redis cluster, so that the master/slave nodes can check each other's health status while completing the data reading and writing tasks.