DAY 71 Redis High Availability Persistence

Redis High Availability

What is high availability

In web servers, high availability refers to the time when the server can be accessed normally, and the measure is how long normal services can be provided (99.9%, 99.99%, 99.999%, etc.).

However, in the context of Redis, the meaning of high availability seems to be broader. In addition to ensuring the provision of normal services (such as master-slave separation, fast disaster recovery technology), it is also necessary to consider the expansion of data capacity and data security without loss, etc.

High availability technology of Redis

In Redis, technologies to achieve high availability mainly include persistence, master-slave replication, sentry and cluster clusters. The following describes their functions and what problems they solve.

• Persistence: Persistence is the simplest high-availability method (sometimes not even classified as a high-availability method). Its main function is data backup, that is, storing data on the hard disk to ensure that data will not be lost due to process exit.

• Master-slave replication: Master-slave replication is the basis of highly available Redis. Sentinels and clusters are based on master-slave replication to achieve high availability. Master-slave replication mainly realizes multi-machine backup (and synchronization) of data, as well as load balancing and simple fault recovery for read operations.

  • Defects: Failure recovery cannot be automated; write operations cannot be load-balanced; storage capacity is limited by a single machine.

• Sentinel: Based on master-slave replication, Sentinel implements automatic failure recovery. (The master is down, find a slave to become the new master, and the sentinel node will monitor it)

  • Defects: Write operations cannot be load-balanced; storage capacity is limited by a single machine.

• Cluster cluster: Through the cluster, Redis solves the problem that the write operation cannot be load-balanced and the storage capacity is limited by a single machine, and realizes a relatively complete high-availability solution. (6 sets start, in pairs, 3 masters and 3 slaves)

Redis persistence

persistent function

Persistence function: Redis is an in-memory database, and the data is stored in the memory. In order to avoid the permanent loss of data after the Redis process exits abnormally due to server power failure and other reasons, it is necessary to regularly save the data in Redis in some form (data or command) from the memory to the hard disk; when Redis restarts next time, use the persistent file to achieve data recovery. Additionally, the persistent files can be copied to a remote location for disaster backup purposes.

Disaster backup: generally do off-site backup, and switch nodes after a disaster occurs. For example, the database originally used in Shanghai is now switched to the database in Chongqing

Redis provides two methods for persistence:

• RDB persistence: The principle is to save the database records of Reids in memory to disk regularly. (Regularly generate snapshots of the data in the memory and save them in the hard disk as files)
• AOF persistence (append only file): The principle is to write the operation log of Reids to the file in an appended way, similar to MySQL's binlog. (similar to Mysql's binary log) (write and delete operation commands are recorded in the AOF file in an appended manner)

Because the real-time performance of AOF persistence is better, that is, less data is lost when the process exits unexpectedly, so AOF is currently the mainstream persistence method, but RDB persistence still has its place. (RDBs are smaller and faster to restore. Less impact on performance.)

RDB persistence

RDB persistence refers to saving the snapshot of the data in the current process in memory to the hard disk within a specified time interval (so it is also called snapshot persistence), stored in binary compression, and the saved file suffix is ​​rdb; when Redis restarts , you can read the snapshot file to restore data.

Triggering conditions

The triggering of RDB persistence is divided into manual triggering and automatic triggering.

manual trigger

Both the save command and the bgsave command can generate RDB files.

• The save command will block the Redis server process until the RDB file is created. During the blockage of the Redis server, the server cannot process any command requests.
• The bgsave command creates a child process, which is responsible for creating the RDB file, and the parent process (that is, the Redis main process) continues to process requests.
• During the execution of the bgsave command, only the fork child process will block the server, but for the save command, the entire process will block the server, so save has been basically abandoned, and the use of save must be avoided in the online environment.

automatic trigger

When automatically triggering RDB persistence, Redis will also choose bgsave instead of save for persistence.

The most common case of automatic triggering is to specify in the configuration file  save m n that when n changes occur within m seconds, bgsave will be triggered

 vim /etc/redis/6379.conf      #编辑配置文件
 ​
 ----219行--以下三个save条件满足任意一一个时，都会引起bgsave的调用
 save 900 1      #当时间到900秒时，如果redis数据发生了至少1次变化，则执行bgsave
 save 300 10     #当时间到300秒时，如果redis数据发生了至少10次变化，则执行bgsave
 save 60 10000   #当时间到60秒时，如果redis数据发生了至少10000次变化， 则执行bgsave
 ​
 ----242行--是否开启RDB文件压缩
 rdbcompression yes
 ​
 ----254行--指定RDB文件名
 dbfilename dump.rdb
 ​
 ----264行--指定RDB文件和AOF文件所在目录
 dir /var/lib/redis/6379  

Other automatic trigger mechanisms

In addition to savemn, there are some other situations that trigger bgsave:

• In the master-slave replication scenario, if the slave node performs a full copy operation, the master node will execute the bgsave command and send the rdb file to the slave node.
• When the shutdown command is executed, RDB persistence is automatically executed

bgsave execution process

(1) The Redis parent process first judges: whether it is currently executing save, or the child process of bgsave/bgrewriteaof, and if it is executing, the bgsave command will return directly.

• The child processes of bgsave/bgrewriteaof cannot be executed at the same time, mainly based on performance considerations: two concurrent child processes perform a large number of disk write operations at the same time, which may cause serious performance problems.

(2) The parent process executes the fork operation to create a child process. During this process, the parent process is blocked, and Redis cannot execute any commands from the client.

(3) After the parent process forks, the bgsave command returns the message "Background saving started" and no longer blocks the parent process, and can respond to other commands.

(4) The child process creates an RDB file, generates a temporary snapshot file based on the memory snapshot of the parent process, and atomically replaces the original file after completion. (atomic replacement: replace the entire file, either all or none)

(5) The child process sends a signal to the parent process to indicate completion, and the parent process updates the statistics

load at startup

• The loading of the RDB file is automatically executed when the server starts, and there is no special command. However, because AOF has a higher priority, when AOF is enabled, Redis will prioritize loading AOF files to restore data; only when AOF is disabled, RDB files will be detected and automatically loaded when the Redis server starts. The server is blocked while loading the RDB file until the loading is complete.

• When Redis loads the RDB file, it will verify the RDB file. If the file is damaged, an error will be printed in the log, and Redis will fail to start.

AOF persistence (supports second-level writing)

• RDB persistence is to write process data into files, while AOF persistence is to record each write and delete command executed by Redis into a separate log file, and query operations will not be recorded.

• When Redis restarts, execute the commands in the AOF file again to restore the data. (replay command for recovery)

• Compared with RDB, AOF has better real-time performance , so it has become the mainstream persistence solution

Enable AOF

The Redis server enables RDB by default, and disables AOF. To enable AOF, it needs to be /etc/redis/6379.confconfigured in the configuration file

 vim /etc/redis/6379.conf
 ----700行---修改，开启AOF
 appendonly yes
 ----704行---指定AOF文件名称
 appendfilename "appendonly.aof"
 ----796行---是否忽略最后一条可能存在问题的指令
 aof-load-truncated yes   
 #Redis恢复时，发现AOF文件的末尾被截断了，会忽略最后一条可能存在问题的指令。默认值yes。即在aof写入时，可能发生redis机器运行崩溃，AOF文件的末尾被截断了，这种情况下，yes会继续执行并恢复尽量多的数据，而no会直接恢复失败报错退出。
 ​
 ​
 /etc/init.d/redis_6379 restart    #重启redis
 ls /var/lib/redis/6379/      #查看是否生成了aof文件

Implementation process

Since each write command of Redis needs to be recorded, AOF does not need to be triggered. The following describes the execution process of AOF.

The execution process of AOF includes:

• Command append (append) : Append the Redis write command to the buffer aof_ buf;

• File writing (write) and file synchronization (sync) : Synchronize the contents of aof_buf to the hard disk according to different synchronization strategies;

• File rewrite (rewrite) : Periodically rewrite the AOF file to achieve the purpose of compression. (Compress or delete expired data, invalid commands, and multiple commands)

Instruction append (append)

• Redis first appends the write command to the buffer instead of directly writing the file, mainly to avoid writing the command directly to the hard disk every time, causing the hard disk IO to become the bottleneck of Redis load.

• The format of command append is the protocol format of Redis command request. It is a plain text format, which has the advantages of good compatibility, strong readability, easy processing, simple operation and avoiding secondary overhead.

• In the AOF file, except for the select command used to specify the database (such as select 0 to select database 0), which is added by Redis, all others are write commands sent by the client.

File writing (write) and file synchronization (sync)

Redis provides a variety of synchronization file strategies for the AOF cache area. The strategy involves the write function and fsync function of the operating system, as follows:

• In order to improve file writing efficiency, in modern operating systems, when a user calls the write function to write data into a file, the operating system usually temporarily stores the data in a memory buffer. When the buffer is full or exceeds the specified After the time limit, the data in the buffer is actually written to the hard disk.
• Although such an operation improves efficiency, it also brings security problems: if the computer stops, the data in the memory buffer will be lost. Therefore, the system also provides synchronization functions such as fsync and fdatasync, which can force the operating system to immediately write the data in the buffer to the hard disk, thereby ensuring data security.

There are three synchronization methods for the synchronization file strategy of the AOF cache area, which are:

• appendfsync always: After the command is written to aof_buf, the system fsync operation is called immediately to synchronize to the AOF file. High security, low performance.

• appendfsync no: When the buffer is full or exceeds the specified time limit (30 seconds by default), the data in the buffer will be written to the hard disk. High performance, but low security.

• appendfsync everysec: Synchronize once per second, which is a balance between performance and data security, so it is the default configuration of Redis.

 vim /etc/redis/6379.conf
 ----729行----
  729 # appendfsync always
  730 appendfsync everysec
  731 # appendfsync no
 ​
 ------------------------以下是注释----------------------------------------------------
 ● appendfsync always:
 #命令写入aof_buf后立即调用系统fsync操作同步到AOF文件，fsync完成后线程返回。
 这种情况下，每次有写命令都要同步到AOF文件，硬盘IO成为性能瓶颈，Redis只能支持大约几百TPS写入，严重降低了Redis的性能；
 即便是使用固态硬盘(SSD) ，每秒大约也只能处理几万个命令，而且会大大降低SSD的寿命。
 （安全性高，性能低。）
 ​
 ● appendfsync no:
 #命令写入aof_buf后调用系统write操作，不对AOF文件做fsync同步；
 同步由操作系统负责，通常同步周期为30秒。
 这种情况下，文件同步的时间不可控，且缓冲区中堆积的数据会很多，数据安全性无法保证。
 （当缓冲区被填满或超过了指定时限后，才将缓冲区的数据写入到硬盘里。性能高，但安全性低。）
 ​
 ● appendfsync everysec:
 #命令写入aof_buf后调用系统write操作，write完成后线程返回; fsync同步文件操作由专门的线程每秒调用一次。
 everysec是前述两种策略的折中，是性能和数据安全性的平衡，因此是Redis的默认配置，也是我们推荐的配置。
 （同时保证了数据安全和性能的需求）

 File rewrite (rewrite)

• As time goes by, the Redis server executes more and more write commands, and the AOF file will become larger and larger; too large AOF files will not only affect the normal operation of the server, but also cause data recovery to take too long.
• File rewriting refers to periodically rewriting the AOF file to reduce the size of the AOF file. It should be noted that AOF rewriting is to convert the data in the Redis process into write commands and synchronize to the new AOF file; it will not perform any read or write operations on the old AOF file!
• Another point to note about file rewriting: For AOF persistence, file rewriting is strongly recommended, but not necessary; even without file rewriting, data can be persisted and started in Redis time to import. Therefore, in some realities, automatic file rewriting will be turned off, and then scheduled tasks will be executed at a certain time every day.

Notice:

Rewriting consumes performance and affects business, so rewriting cannot be performed during peak business hours. Therefore, automatic rewriting is generally turned off, and the scheduled task executes the rewriting function at a certain time every day.

The reason why file rewriting can compress AOF files is:

• Expired data is no longer written to the file.
• Invalid commands are no longer written to the file: for example, some data is repeatedly set (set mykey v1, set mykey v2), some data is deleted (set myset vl, del myset), etc.
• Multiple commands can be combined into one: for example, sadd myset v1, sadd myset v2, sadd myset v3 can be combined into sadd myset v1 v2 v3. (sadd add collection)

After rewrite, the aof file will save the final state of the keys, and clear out the previous redundancy to shrink the file.

From the above content, it can be seen that since the commands executed by AOF are reduced after rewriting, file rewriting can not only reduce the space occupied by the file, but also speed up the recovery speed.

The trigger of file rewriting is divided into manual trigger and automatic trigger:

The trigger of file rewriting is divided into manual trigger and automatic trigger:

• Manual trigger: directly call the bgrewriteaof command, the execution of this command is somewhat similar to bgsave: both fork sub-processes perform specific work, and both are blocked only when fork.

• Automatic trigger: BGREWRITEAOF is automatically executed by setting the auto-aof-rewrite-min-size option and the auto-aof-rewrite-percentage option.

  • Only when the two options of auto-aof-rewrite-min-size and auto-aof-rewrite-percentage are satisfied at the same time, AOF rewriting will be automatically triggered, that is, the bgrewriteaof operation.

 vim /etc/redis/6379.conf
 ----771行----
  771 auto-aof-rewrite-percentage 100
  772 auto-aof-rewrite-min-size 64mb
 ​
 -----------------------以下是注释--------------------------------
 ● auto-aof-rewrite-percentage 100  
 #文件的大小超过基准百分之多少后触发bgrewriteaof。默认这个值设置为100，意味着当前aof是基准大小的两倍的时候触发bgrewriteaof。把它设置为0可以禁用自动触发的功能。
 #即当前AOF文件大小(即aof_current_size)是上次日志重写时AOF文件大小(aof_base_size)两倍时，发生BGREWRITEAOF操作。
 #注意：例如上次文件达到100M进行重写，那么这次需要达到200M时才进行重写。文件需要越来越大，所以一般不使用自动重写。如果使用自动重写，需要定期手动重写干预一次，让文件要求恢复到100M。
 ​
 ● auto-aof-rewrite-min-size 64mb      #当文件大于64M时才会进行重写
 #当前aof文件大于多少字节后才触发。
 #当前AOF文件执行BGREWRITEAOF命令的最小值，避免刚开始启动Reids时由于文件尺寸较小导致频繁的BGREWRITEAOF

Regarding the process of file rewriting, there are two points that need special attention:

1. Rewriting is performed by the parent process forking the child process.
2. The write command executed by Redis during rewriting needs to be appended to the new AOF file. For this reason, Redis introduces the aof_rewrite_buf cache.

The process of file rewriting is as follows:

(1) The Redis parent process first judges whether there is a child process currently executing bgsave/bgrewriteaof. If it exists, the bgrewriteaof command will return directly. If there is a bgsave command, wait for the bgsave execution to complete before executing it. (Under normal circumstances, when using AOF, AOF will be used for recording, and RDB will not be used. The bgsave command will be automatically triggered during master-slave replication)

(2) The parent process executes the fork operation to create a child process. During this process, the parent process is blocked (unable to accept any client request).

(3.1) After the parent process forks, the bgrewriteaof command returns the message "Background append only file rewrite started" and no longer blocks the parent process, and can respond to other commands. All write commands of Redis are still written into the AOF buffer, and are synchronized to the hard disk according to the appendfsync strategy to ensure the correctness of the original AOF mechanism.

(3.2) Since the fork operation uses the copy-on-write technology, the child process can only share the memory data during the fork operation. Since the parent process is still responding to the command, Redis uses the AOF rewrite buffer (aof_rewrite_buf) to save this part of the data to prevent the loss of this part of the data during the generation of the new AOF file. That is to say, during the execution of bgrewriteaof, Redis write commands are simultaneously appended to two buffers, aof_buf and aof_rewrite_buf. (to ensure that the newly written data will not be lost)

(4) According to the memory snapshot, the child process writes to the new AOF file according to the command merging rules.

(5.1) After the child process writes the new AOF file, it sends a signal to the parent process, and the parent process updates the statistical information, which can be viewed through info persistence.

(5.2) The parent process writes the data in the AOF rewrite buffer to the new AOF file, thus ensuring that the database state saved in the new AOF file is consistent with the current state of the server.

(5.3) Replace the old file with the new AOF file to complete AOF rewriting. (replacement is atomic)

load at startup

• When AOF is turned on, Redis will first load the AOF file to restore data when it starts; only when AOF is turned off, it will load the RDB file to restore data.

• When AOF is enabled but the AOF file does not exist, it will not be loaded even if the RDB file exists.

• When Redis loads the AOF file, it will verify the AOF file. If the file is damaged, an error will be printed in the log, and Redis will fail to start. However, if the end of the AOF file is incomplete (such as a sudden machine shutdown, the end of the file is likely to be incomplete), and the aof-load-truncated parameter is enabled, a warning will be output in the log, and Redis will ignore the end of the AOF file, and the startup is successful. The aof-load-truncated parameter is enabled by default.

Advantages and disadvantages of RDB and AOF

Advantages and disadvantages of RDB persistence

advantage:

RDB files are compact, small in size, fast in network transmission, and suitable for full copy; recovery speed is much faster than AOF. Of course, one of the most important advantages of RDB compared to AOF is the relatively small impact on performance.

(Small size, faster recovery, less impact on performance.)

shortcoming:

• The fatal shortcoming of RDB files is that the persistence method of its data snapshots determines that it cannot achieve real-time persistence. Today, when data is becoming more and more important, a large amount of data loss is often unacceptable, so AOF persistence has become the mainstream. .
• In addition, RDB files need to meet a specific format and have poor compatibility (for example, old versions of Redis are not compatible with new versions of RDB files).
• For RDB persistence, on the one hand, the Redis main process will be blocked when bgsave performs the fork operation; on the other hand, writing data to the hard disk by the child process will also bring IO pressure.

(Poor real-time performance, poor compatibility, and will block the parent process when forking the child process.)

Advantages and disadvantages of AOF persistence

• Corresponding to RDB persistence, the advantage of AOF is that it supports second-level persistence, good real-time performance, and good compatibility. The disadvantages are large files, slow recovery speed, and great impact on performance.
• For AOF persistence, the frequency of writing data to the hard disk is greatly increased (second level under the everysec strategy), the IO pressure is greater, and it may even cause AOF additional blocking problems.
• The rewriting of the AOF file is similar to the bgsave of the RDB, and there will be blocking during fork and IO pressure of the child process. Relatively speaking, since AOF writes data to the hard disk more frequently, it will have a greater impact on the performance of the Redis main process.

Redis performance management

View Redis memory usage

 方法一：进入redis数据库查看
 redis-cli
 127.0.0.1:6379> info memory
 ​
 方法二：命令行查看
 redis-cli info memory

memory fragmentation

How to calculate the memory fragmentation rate:

Memory fragmentation rate = memory requested by Redis from the operating system / memory occupied by data in Redis

mem_fragmentation_ratio = used_memory_rss / used_memory

• mem_fragmentation_ratio: memory fragmentation rate.

• used_memory_rss: It is the memory requested by Redis from the operating system.

• used_memory: is the memory occupied by the data in Redis.

• used_memory_peak: The peak value of redis memory usage.

How does memory fragmentation occur?

• Redis has its own internal memory manager to manage the application and release of memory in order to improve the efficiency of memory usage.

• When the value in Redis is deleted, the memory is not directly released and returned to the operating system, but to the internal memory manager of Redis.

• When applying for memory in Redis, first check whether there is enough memory available in your own memory manager.

• This mechanism of Redis improves the memory utilization rate, but it will cause some memory in Redis that is not used by itself but not released, resulting in memory fragmentation.

track memory fragmentation

Tracking the memory fragmentation rate is very important for understanding the resource performance of a Redis instance:

• It is normal for the memory fragmentation rate to be between 1 and 1.5. This value indicates that the memory fragmentation rate is relatively low, and it also indicates that Redis does not exchange memory.

• If the memory fragmentation rate exceeds 1.5, it means that Redis consumes 150% of the actual physical memory required, of which 50% is the memory fragmentation rate.

• If the memory fragmentation rate is lower than 1, it means that the Redis memory allocation exceeds the physical memory, and the operating system is exchanging memory (using virtual memory, which will reduce performance). Need to increase available physical memory or reduce Redis memory usage.

To solve the problem of high fragmentation rate:

• If your Redis version is below 4.0, you need to enter the shutdown save command on the redis-cli tool to let the Redis database execute the save operation and close the Redis service, and then restart the server. After the Redis server is restarted, Redis will return the useless memory to the operating system, and the fragmentation rate will drop.

• Starting from version 4.0 of Redis, you can defragment memory online without restarting, and return unused memory to the operating system

 config set activedefrag yes    #自动碎片清理
 memory purge                   #手动碎片清理

memory usage

If the memory usage of the redis instance exceeds the maximum available memory, the operating system will start exchanging memory and swap space.

Ways to avoid memory swapping:

• Choose to install the Redis instance for the size of the cached data
• Use Hash data structure storage as much as possible
• Set the expiration time of the key

recycle key

The memory cleaning strategy ensures reasonable allocation of redis limited memory resources.

When the memory usage reaches the set maximum threshold, a key recycling strategy needs to be selected. By default, the recycling strategy is no deletion (noenviction).

Modify the maxmemory-policy attribute value in the configuration file:

 vim /etc/redis/6379.conf
 ---598行----
 maxmemory-policy noenviction   #修改max-memory-policy属性值
 ​
 ##回收策略有以下几种：##
 ●volatile-lru
 #使用LRU算法从已设置过期时间的数据集合中淘汰数据
 （移除最近最少使用的key，针对设置了TTL的key）
 ​
 ●volatile-ttl
 #从已设置过期时间的数据集合中挑选即将过期的数据淘汰
 （移除最近过期的key）
 ​
 ●volatile-random
 #从已设置过期时间的数据集合中随机挑选数据淘汰
 （在设置了TTL的key里随机移除）
 ​
 ●allkeys-lru
 #使用LRU算法 从所有数据集合中淘汰数据
 （移除最少使用的key，针对所有的key）
 ​
 ●allkeys-random
 #从数据集合中任意选择数据淘汰（随机移除key）
 ​
 ●noenviction
 #禁止淘汰数据（不删除直到写满时报错）

What are the optimizations of Redis

Set the client connection timeout, the maximum number of client connections, automatic debris cleaning, the maximum memory threshold, and the key recovery strategy.

Set the timeout period of Redis client connection

 vim /etc/redis/6379.conf
 -----114行------
 114 timeout 0     
 #单位为秒（s），取值范围为0~100000。默认值为0，表示无限制，即Redis不会主动断开连接，即使这个客户端已经空闲了很长时间。
 #例如可设置为600，则客户端空闲10分钟后，Redis会主动断开连接。
 ​
 #注意：在实际运行中，为了提高性能，Redis不一定会精确地按照timeout的值规定的时间来断开符合条件的空闲连接，例如设置timeout为10s，但空闲连接可能在12s后，服务器中新增很多连接时才会被断开。

Set the maximum number of connections for the redis client

The maximum number of connections of the redis client is 10000 by default.

 vim /etc/redis/6379.conf
 -----540行------
 540 # maxclients 10000     #若不设置，默认是10000

View the current number of redis connections:

 [root@yuji ~]# redis-cli
 127.0.0.1:6379> info clients       #查看redis当前连接数
 # Clients
 connected_clients:1                 #redis当前连接数的为1   
 client_recent_max_input_buffer:2
 client_recent_max_output_buffer:0
 blocked_clients:0

View the maximum number of connections allowed by redis:

 127.0.0.1:6379> config get maxclients
 1) "maxclients"     
 2) "10000"              #redis允许的最大连接数默认为10000

Set redis automatic defragmentation

 config set activedefrag yes    #自动碎片清理
 memory purge                   #手动碎片清理

Set redis maximum memory threshold

If the memory threshold is not set, there is no limit until the server's memory is full, and then the swap partition will be used.

After setting the memory threshold, the swap partition will not be used. And if the key recovery policy is set, when the memory usage reaches the set maximum threshold, the system will perform key recovery.

 vim /etc/redis/6379.conf
 -----567行------
 567 # maxmemory <bytes>
 568 maxmemory 1gb           #例如设置最大内存阈值为1gb

Set the key recycling policy

When the memory usage reaches the set maximum threshold, a key recycling strategy needs to be selected. By default, the recycling strategy is no deletion (noenviction).

After the key recovery policy is set, when the redis memory usage reaches the set maximum threshold, the system will perform key recovery and release part of the memory.

 vim /etc/redis/6379.conf
 ---598行----
 maxmemory-policy noenviction   #需要修改max-memory-policy属性值
 ​
 ##回收策略有以下几种：##
 ●volatile-lru
 #使用LRU算法从已设置过期时间的数据集合中淘汰数据（移除最近最少使用的key，针对设置了TTL的key）
 ​
 ●volatile-ttl
 #从已设置过期时间的数据集合中挑选即将过期的数据淘汰（移除最近过期的key）
 ​
 ●volatile-random
 #从已设置过期时间的数据集合中随机挑选数据淘汰（在设置了TTL的key里随机移除）
 ​
 ●allkeys-lru
 #使用LRU算法 从所有数据集合中淘汰数据（移除最少使用的key，针对所有的key）
 ​
 ●allkeys-random
 #从数据集合中任意选择数据淘汰（随机移除key）
 ​
 ●noenviction
 #禁止淘汰数据（不删除直到写满时报错）