Shulou(Shulou.com)06/01 Report--

This article is about solving the problem of redis downtime. The editor thought it was very practical, so I shared it with you as a reference. Let's follow the editor and have a look.

We all know that the data of Redis is all in memory. If there is a sudden downtime, all the data will be lost. What should we do about it?

Therefore, there must be a mechanism to ensure that the data of Redis will not be lost due to failure, which is the persistence mechanism of Redis.

There are two persistence mechanisms for Redis, the first is snapshots, and the second is AOF logs. A snapshot is a full backup, and the AOF log is a continuous incremental backup. Snapshots are binary serialized forms of memory data and are very compact in storage, while the AOF log records the instruction recording text of memory data modifications. The AOF log will become extremely large in the long run. When the database is restarted, the AOF log needs to be loaded for instruction replay, and this time will be extremely long. Therefore, it is necessary to rewrite the AOF log regularly to reduce the size of the AOF log.

Snapshot principle

We know that Redis is a single-threaded program, which is responsible for the concurrent read and write operations of multiple client sockets and the logical read and write of in-memory data structures.

At the same time of the request on the service line, Redis also needs to take a memory snapshot. Memory snapshot requires Redis to perform file IO operation, but file IO operation cannot use multiplexed API.

This means that when a single thread requests on the service line, it has to perform file IO operations, and file IO operations will seriously slow down the performance of server requests.

Another important issue is that in order not to block online business, Redis needs to persist while responding to client requests. At the same time of persistence, the in-memory data structure is still changing. for example, a large hash dictionary is being persisted, and a request comes and deletes it, but it hasn't been persisted yet. what should I do?

Redis uses the operating system's multi-process COW (Copy On Write) mechanism for snapshot persistence, which is interesting and little known.

AOF principle

The AOF log stores the sequence of instructions of the Redis server, and the AOF log records only the instructions that make changes to memory.

Assuming that the AOF log records all the modification instruction sequences since the creation of the Redis instance, you can restore the state of the in-memory data structure of the current Redis instance by sequentially executing all the instructions-- that is, "replay"-- on an empty Redis instance.

After receiving the client modification instruction, Redis will perform parameter verification and logical processing. If there is no problem, it will immediately store the instruction text in the AOF log, that is, execute the instruction before saving the log. This is different from storage engines such as leveldb and hbase, which store logs first and then do logical processing.

During the long run of Redis, the log of AOF will become longer and longer. If the instance is down and restarted, it will be very time-consuming to replay the entire AOF log, resulting in Redis being unable to provide services for a long time. So you need to lose weight with AOF logs.

Thank you for reading! So much for solving the problem of redis downtime. I hope the above content can be helpful to you, so that you can learn more knowledge. If you think the article is good, you can share it and let more people see it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.