redis学习笔记2：其他所有内容

pipline

对于pipeline的理解：针对RTT时间进行优化
https://blog.csdn.net/w1lgy/article/details/84455579

实际上pipeline相当于Java8的stream，将所有命令批量发送给server端去执行而不是一条条执行，同时server端对于批量命令的执行会有一定的优化处理机制

持久化

关于持久化，从redis是什么的概念入手
对比下MySQL日志模块的持久化redo log - RDB与bin log - AOF

所有操作在内存中执行，需要将内存中的数据落盘，从而在下次启动使用时能够恢复数据

redis在启动后会启用一个定时任务去完成持久化过程。
在启动时会首先读取持久化文件，完成磁盘到内存的过程
过程中维护持久化文件

RDB

RDB：是什么、配置、触发机制即可
fork进程临时文件替换，文件可以视为一个快照，物理日志的概念

复制一个一模一样的子进程
因为redis的server端是单线程，如果redis的工作线程去执行持久化，那么客户端在此期间的所有命令将会阻塞

持久化文件：dump.rdb
位置：你在哪里启动redis，就在哪里生成该文件；下次启动的时候就会读取启动目录下的dump.rdb，如果有就加载，如果没有则不进行任何操作。
所以在位置1处启动redis，第二次在位置2启动，那么第一次的内存中数据不会在第二次启动时读取

一般会固定dump.rdb的位置，在配置文件中修改即可：

临时文件也是放置在这个位置

触发时机/情况：4个场景。shutdown、配置、执行命令bgsave/save（bgsave是原理）、flushall命令

1.shutdown；
2.配置文件

主从复制：就是主机将dump.rdb传给从机，完成数据更新，rdb是一种物理机制，记录操作结果
所以持久化机制是根本无法关闭的

优化点：
如果用aof，下面300、60两个配置需要删除，因为会影响性能。不需要频繁的触发。
即便是同时开启，也要删掉

3.手动执行cli命令
自动触发的底层实际上也是调用save（主进程执行，会阻塞IO）/bgsave命令（另起线程）
bgsave实际上就是RDB持久化的原理

在执行持久化期间查看进程信息

4.flushall：清空内存中的所有数据的命令
为了防止执行该命令期间出现意外宕机的情况（此时命令相当于白白执行），更新持久化文件，也将持久化文件清空

数据可以通过持久化文件加载到数据库当中，只需要将过去的dump.rdb文件复制下来，替换到新服务器的rdb文件位置即可。通过DBSIZE来看下导入数据条数。

AOF

为什么会出现AOF持久化？
解决RDB的某些问题：
RDB持久化会出现丢失数据的情况，在突然宕机的场景下，RDB没来得及持久化，即四种触发条件都没有得到机会，此时就会出现数据丢失

AOF即为了解决RDB持久化丢失数据的问题，平常没有子进程，重写会有子进程

RDB-》直接基于内存数据，生成持久化文件

AOF-》逻辑日志（类似git与MySQL中的bin log），记录操作命令字符串，超量重写，everysecond always no

文件位置：也是在dir中进行配置

开启AOF：

改为yes即可

这时候就会出现aof文件：

AOF的触发机制：

一般使用默认配置

开启AOF，redis就会启用一个缓冲区
主进程就会将命令字符串写入到缓冲区，缓冲区内的数据最后放入到aof
如果主进程直接写入到aof文件，即写数据到磁盘，效率太低，就会出现阻塞
而写入到缓冲区，实际上就是写内存，效率会很高

RDB fork了主进程，AOF是没有fork主进程的，aof的记录过程非常快，不需要fork一个子进程

上述的配置实际上影响的就是缓冲区到aof持久化文件的过程
如果配置为no，缓冲区到aof的过程实际上是内核态的，什么时候缓冲进去无法保证，比较危险，效率高但是数据无法保证，可能存在数据丢失的情况
always：有数据来就立即配置进去。效率慢，但是很安全，开销太大。
所以一般用默认配置，每秒记录一次，这里是用一个定时任务去执行的

缓冲区的大小配置如上

jedis底层原理就是aof配置文件，向redis服务端发送存储如aof中的命令格式，交给redis执行

其中select 0，是数据库切换命令，默认切换到0号库（redis有16个数据库）
第一个*num是有几组命令，对应$3 $2 $2等
$2代表下一个字符串的长度

重写机制

防止一直append导致文件size越来越大，撑爆磁盘

比如上述，del k2就与set k2 v2抵消

第二次的size就会变为72M
注意第一次的大小要根据服务器配置进行优化，尽量减少重写次数

在重写时会fork子进程，是直接基于内存进行的，这个过程会很慢

混合持久化

混合持久化，主要缺点只是兼容性而已

持久化文件坏了怎么办

自身提供了修复工具

过期key的删除策略与内存淘汰策略

过期key的删除策略：定期抽检删除（配置hz） + 惰性删除（过期不删，使用检测）

内存淘汰策略：

https://www.cnblogs.com/ysocean/p/12422635.html

淘汰算法的具体介绍：
https://stor.51cto.com/art/201904/594773.htm
主要三种：LRU算法、TTL算法、随机淘汰算法
根据LRU、TTL、随机进行选取某些key进行删除，还可以根据是否设置过期时间再进行筛选

主从复制

主从复制（高可用：读写分离。一致性问题）
https://www.cnblogs.com/ysocean/p/9143118.html
目录

1、修改配置文件
主从模式几个节点的配置。
设置守护进程、设置端口号、设置rdb名字等

2、设置主从关系并查询

3、测试主从关系的增量复制、全量复制、主从读写分离以及读写分离的取消

4、哨兵模式：
用途：检测主节点宕机并投票选举某个子节点为新的主节点
哨兵也有集群，防止单哨兵失效后master节点也宕机的场景
配置方法介绍

5、主从复制原理（重点）
6、主从复制的缺点

Redis的复制功能分为同步（sync）和命令传播（command propagate）两个操作。

①、旧版同步/全量复制：RDB文件+缓冲区所有写命令传播。发生在启动时候

当从节点发出 SLAVEOF 命令，要求从服务器复制主服务器时，从服务器通过向主服务器发送 SYNC 命令来完成。该命令执行步骤：

1、从服务器向主服务器发送 SYNC 命令

2、收到 SYNC 命令的主服务器执行 BGSAVE 命令，在后台生成一个 RDB 文件，并使用一个缓冲区记录从开始执行的所有写命令

3、当主服务器的 BGSAVE 命令执行完毕时，主服务器会将 BGSAVE 命令生成的 RDB 文件发送给从服务器，从服务器接收此 RDB 文件，并将服务器状态更新为RDB文件记录的状态。

4、主服务器将缓冲区的所有写命令也发送给从服务器，从服务器执行相应命令。

②、命令传播/增量复制：发生在启动之后

当同步操作完成之后，主服务器会进行相应的修改命令，这时候从服务器和主服务器状态就会不一致。

为了让主服务器和从服务器保持状态一致，主服务器需要对从服务器执行命令传播操作，主服务器会将自己的写命令发送给从服务器执行。从服务器执行相应的命令之后，主从服务器状态继续保持一致。

总结：通过同步操作全量同步以及命令传播增量同步功能，能够很好的保证了主从一致的特性。

断开后要手动处理
　　
但是我们考虑一个问题，如果从服务器在同步主服务器期间，突然断开了连接，而这时候主服务器进行了一些写操作，这时候从服务器恢复连接，如果我们在进行同步，那么就必须将主服务器从新生成一个RDB文件，然后给从服务器加载，这样虽然能够保证一致性，但是其实断开连接之前主从服务器状态是保持一致的，不一致的是从服务器断开连接，而主服务器执行了一些写命令，那么从服务器恢复连接后能不能只要断开连接的哪些写命令，而不是整个RDB快照呢？

同步操作其实是一个非常耗时的操作，主服务器需要先通过 BGSAVE 命令来生成一个 RDB 文件，然后需要将该文件发送给从服务器，从服务器接收该文件之后，接着加载该文件，并且加载期间，从服务器是无法处理其他命令的。

为了解决这个问题，Redis从2.8版本之后，使用了新的同步命令 PSYNC 来代替 SYNC 命令。该命令的部分重同步功能用于处理断线后重复制的效率问题。也就是说当从服务器在断线后重新连接主服务器时，主服务器只将断开连接后执行的写命令发送给从服务器，从服务器只需要接收并执行这些写命令即可保持主从一致。

一般情况下，是先全量复制在增量复制。即在slave启动的时候进行全量复制，在启动完成后在进行增量复制

主从复制优点
支持主从复制，主机会自动将数据同步到从机，可以进行读写分离；
分载 Master 的读操作压力，Slave 服务器可以为客户端提供只读操作的服务，写服务仍然必须由Master来完成；
Slave 同样可以接受其它 Slaves 的连接和同步请求，这样可以有效的分载 Master 的同步压力；
Master Server 是以非阻塞的方式为 Slaves 提供服务。所以在 Master-Slave 同步期间，客户端仍然可以提交查询或修改请求；
Slave Server 同样是以非阻塞的方式完成数据同步。在同步期间，如果有客户端提交查询请求，Redis则返回同步之前的数据；

redis主从复制缺点/问题：
Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复（也就是要人工介入）；
主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性；
如果多个 Slave 断线了，需要重启的时候，尽量不要在同一时间段进行重启。因为只要 Slave 启动，就会发送sync 请求和主机全量同步，当多个 Slave 重启的时候，可能会导致 Master IO 剧增从而宕机。
Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂；

哨兵模式

https://www.cnblogs.com/ysocean/p/12290364.html

目录

1、架构图

2、服务器列表
3、搭建主从模式
主从搭建配置

4、搭建哨兵模式
配置
#监控的IP 端口号 名称 sentinel通过投票后认为mater宕机的数量，此处为至少2个
sentinel monitor mymaster 192.168.14.101 6379 2
#30秒ping不通主节点的信息，主观认为master宕机
sentinel down-after-milliseconds mymaster 30000
#故障转移后重新主从复制，1表示串行，>1并行
sentinel parallel-syncs mymaster 1
#故障转移开始，三分钟内没有完成，则认为转移失败
sentinel failover-timeout mymaster 180000

验证哨兵模式生效：日志查看方法
可以从 sentinel 日志中出现的几个消息来进行查看故障转移:

1.+switch-master:表示切换主节点(从节点晋升为主节点)

2.+sdown:主观下线

3.+odown:客观下线

4.+convert-to-slave:切换从节点(原主节点降为从节点)

5、Java客户端连接哨兵集群
SpringBoot RedisTemplate连接哨兵集群

6、Java客户端连接原理

客户端是和Sentinel来进行交互的,通过Sentinel来获取真正的Redis节点信息,然后来操作.实际工作时,Sentinel 内部维护了一个主题队列,用来保存Redis的节点信息,并实时更新,客户端订阅了这个主题,然后实时的去获取这个队列的Redis节点信息.

7、哨兵模式工作原理
三个定时任务
　　一.每10秒每个 sentinel 对master 和 slave 执行info 命令:该命令第一个是用来发现slave节点,第二个是确定主从关系.
　　二.每2秒每个 sentinel 通过 master 节点的 channel(名称为_sentinel_:hello) 交换信息(pub/sub):用来交互对节点的看法(后面会介绍的节点主观下线和客观下线)以及自身信息.
　　三.每1秒每个 sentinel 对其他 sentinel 和 redis 执行 ping 命令,用于心跳检测,作为节点存活的判断依据.

主观下线和客观下线
　　一.主观下线
　　SDOWN:subjectively down,直接翻译的为”主观”失效,即当前sentinel实例认为某个redis服务为”不可用”状态.
　　二.客观下线
　　ODOWN:objectively down,直接翻译为”客观”失效,即多个sentinel实例都认为master处于”SDOWN”状态,那么此时master将处于ODOWN,ODOWN可以简单理解为master已经被集群确定为”不可用”,将会开启故障转移机制.
当一台 sentinel 发现一个 Redis 服务无法 ping 通时,就标记为 主观下线 sdown;同时另外的 sentinel 服务也发现该 Redis 服务宕机,也标记为 主观下线,当多台 sentinel (大于等于2,上面配置的最后一个)时,都标记该Redis服务宕机,这时候就变为客观下线了,然后进行故障转移.

故障转移是由 sentinel 领导者节点来完成的(只需要一个sentinel节点),关于 sentinel 领导者节点的选取也是每个 sentinel 向其他 sentinel 节点发送我要成为领导者的命令,超过半数sentinel 节点同意,并且也大于quorum ,那么他将成为领导者,如果有多个sentinel都成为了领导者,则会过段时间在进行选举.

sentinel 领导者节点选举出来后,会通过如下几步进行故障转移:

一.从 slave 节点中选出一个合适的 节点作为新的master节点.这里的合适包括如下几点:

1.选择 slave-priority(slave节点优先级)最高的slave节点,如果存在则返回,不存在则继续下一步判断.

2.选择复制偏移量最大的 slave 节点(复制的最完整),如果存在则返回,不存在则继续.

3.选择runId最小的slave节点(启动最早的节点)

二.对上面选出来的 slave 节点执行 slaveof no one 命令让其成为新的 master 节点.

三.向剩余的 slave 节点发送命令,让他们成为新master 节点的 slave 节点,复制规则和前面设置的 parallel-syncs 参数有关.

四.更新原来master 节点配置为 slave 节点,并保持对其进行关注,一旦这个节点重新恢复正常后,会命令它去复制新的master节点信息.(注意:原来的master节点恢复后是作为slave的角色)

事务

https://www.cnblogs.com/DeepInThought/p/10720132.html

redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。
在事务执行过程，会按照顺序串行化执行队列中的命令，其他客户端提交的命令请求不会插入到事务执行命令序列中。本质可以理解为无回退的命令集合，单条执行有原子性，整体事务不保证且无回滚
2种错误：编译错误（事务执行失败）与运行时错误（出错语句不执行，其余执行）
三个阶段：
开始事务MULTI
命令入队直到EXEC、DISCARD
执行事务

watch发现改变时，整个事务执行失败，放弃
watch指令类似于乐观锁，在事务提交时，如果watch监控的多个KEY中任何KEY的值已经被其他客户端更改，则使用EXEC执行事务时，事务队列将不会被执行，同时返回Nullmulti-bulk应答以通知调用者事务执行失败。

事务与pipeline的区别：
pipeline是客户端的行为，对于服务器来说是透明的，可以认为服务器无法区分客户端发送来的查询命令是以普通命令的形式还是以pipeline的形式发送到服务器的，每一条是一个事务；
而事务则是实现在服务器端的行为，用户执行MULTI命令时，服务器会将对应这个用户的客户端对象设置为一个特殊的状态，在这个状态下后续用户执行的查询命令不会被真的执行，而是被服务器缓存起来，直到用户执行EXEC命令为止，服务器会将这个用户对应的客户端对象中缓存的命令按照提交的顺序依次执行。

NIO的一部分体现：
1，Redis服务器处理客户端的查询命令：
2，用户的命令通过TCP连接发送给Redis服务器。
3，Redis服务器接收到数据时，在该连接上触发可读事件，并从事件循环之中跳出。服务器通过read系统调用将内核缓冲区之中的数据一次性地读入到该连接所对应的客户端对象的应用层缓冲区之中。
4，Redis服务器会循环解析并处理应用层缓冲区之中的数据，将其解析成Redis命令，并执行查询逻辑，直到缓冲区中剩余的数据无法被解析成完整的Redis命令或者缓冲区之中的数据已被全部解析完成。,
完成一个客户端对象数据的处理，Redis会继续应用步骤3、4中的逻辑处理其他客户端之中的内容。

如果用户一次性地将多条查询命令发送到网络上，而不是收到一条的返回之后再发送第二条数据；那么在步骤4之中，服务器将一次性的处理这些命令，并且不会被其他用户的命令所打断。这种方式其实就是pipeline的机制，应用pipeline可以提服务器的吞吐能力，并提高Redis处理查询请求的能力。
当通过pipeline提交的查询命令数据较少，可以被内核缓冲区所容纳时，Redis可以保证这些命令执行的原子性。然而一旦数据量过大，超过了内核缓冲区的接收大小，那么命令的执行将会被打断，原子性也就无法得到保证。

Redis集群：集群模式详解

https://www.cnblogs.com/ysocean/p/12328088.html

目录

1、为什么需要集群?
并发量（计算能力）与数据量（内存）的扩展

2、数据分区方式
顺序分布、哈希分布

特点：键值业务相关；数据分散，但是容易造成访问倾斜；支持顺序访问；支持批量操作

特点：数据分散度高；键值分布与业务无关；不支持顺序访问；支持批量操作。

3、一致性哈希分布
解决哈希分布中新增节点或者节点宕机时的数据转移量大的问题，但是redis中无这种机制，采用了4的虚拟槽机制

4、Redis Cluster虚拟槽分区
槽道原理：
https://blog.csdn.net/f919976711/article/details/85864540?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.control&dist_request_id=e56ff649-5c64-4cf0-9401-5e4affb3714a&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.control
每一个节点都有一个属于自己的16384位的二进制位序列，每一位对应一个槽道号，当该二进制序列的某一位为1时，代表当前结点对该槽道号具有管理权。
set key value 时，该结点就会通过hash取模算法将key值计算成某一个在[0,16383]区间内的值，这个值就是槽道号，这个时候当前结点拿着这个槽道号去自己的二进制序列中去比对，如果该槽道号对应的二进制序列中的那一位为1，则直接将该键值对存储到当前节点中，如果对应的二进制为0，存储到槽的属主。
每一个节点不仅拥有一个属于自己的二进制位序列用来表示槽道号，而且还有一个公有的大家都一样的由16384个元素组成的索引数组，跟上面的字符数组一样，还是每一位对应一个槽道号，但是数组中存储的信息是该槽道号的实际管理者。

对插槽以及分片详细的说明;
https://blog.csdn.net/u010800970/article/details/81512201

5、原生搭建 Redis Cluster
①、服务器列表
②、配置各个节点参数
③、建立各个节点通信
④、分配槽位
⑤、主从配置
⑥、测试

6、脚本搭建Redis Cluster
①、Redis5之前使用redis-trib.rb脚本搭建
②、Redis5版本集群搭建

7、集群扩容
①、配置新增节点文件
②、将新增主节点加入到集群中
③、为新增主节点分配槽位
④、将新增的从节点添加到集群中
⑤、建立新增节点的主从关系
⑥、测试

8、集群收缩
①、迁移待移除节点的槽位
②、移除待删除主从节点

三种集群模式：
https://segmentfault.com/a/1190000022808576

主从：读写分离
哨兵：自动解决主从切换
集群：不同redis存储不同的内容

三种缓存问题

缓存穿透（根本不存在的内容）、缓存击穿（缓存中热点数据失效的瞬间，全部去数据库查询）、缓存雪崩（缓存同时失效导致redis缓存几乎无数据）:
https://www.cnblogs.com/ysocean/p/12452023.html

缓存穿透;

业务层校验 + 限流 + 布隆过滤器

击穿：

避免同时去访问数据库
互斥锁 + 热点数据防止过期

雪崩：

Redis大key问题

大key场景
Redis使用者应该都遇到过大key相关的场景，比如：
1、热门话题下评论、答案排序场景。
2、大V的粉丝列表。
3、使用不恰当，或者对业务预估不准确、不及时进行处理垃圾数据等。

主要包括：
1、单个简单的key存储的value很大
2、hash， set，zset，list 中存储过多的元素
3、一个集群存储了上亿的key

大key问题
由于Redis主线程为单线程模型，大key也会带来一些问题，如：
1、集群模式在slot分片均匀情况下，会出现数据和查询倾斜情况，部分有大key的Redis节点占用内存多，QPS高。
2、读写bigkey会导致超时严重，甚至阻塞服务。大key相关的删除或者自动过期时，会出现qps突降或者突升的情况，极端情况下，会造成主从复制异常，Redis服务阻塞无法响应请求。
3，最主要实际上是对网络性能的影响，严重阻塞了网络IO传输。

三、对于bigkey常用的解决办法
1、单个简单的key存储的value很大

（1）对象需要每次都整存整取

    可以尝试将对象分拆成几个key-value， 使用multiGet获取值，这样分拆的意义在于分拆单次操作的压力，将操作压力平摊到多个redis实例中，降低对单个redis的IO影响；

（2）该对象每次只需要存取部分数据

    可以像第一种做法一样，分拆成几个key-value， 也可以将这个存储在一个hash中，每个field代表一个具体的属性，使用hget,hmget来获取部分的value，使用hset，hmset来更新部分属性

2、 hash， set，zset，list 中存储过多的元素

     可以对存储元素按一定规则进行分类，分散存储到多个redis实例中。

    对于一些榜单类的场景，用户一般只会访问前几百及后几百条数据，可以只缓存前几百条以及后几百条，即对用户经常访问的数据做缓存（正序倒序的前几页），而不是全部都做，对于获取中间的数据则可以直接从数据库获取

3、一个集群存储了上亿的key

如果key的个数过多会带来更多的内存空间占用，

1.key本身的占用。

2.集群模式中，服务端有时需要建立一些slot2key的映射关系，这其中的指针占用在key多的情况下也是浪费巨大空间。
所以减少key的个数可以减少内存消耗，可以参考的方案是转Hash结构存储，即原先是直接使用Redis String 的结构存储，现在将多个key存储在一个Hash结构中

对缓存操作的改善可以利用pipeline管道

拆分之后可以考虑采用pipeline去取，由于redis是单线程的，一次只能执行一个命令，这里采用Pipeline模式，一次发送多个命令，无需等待服务端返回。这样就大大的减少了网络往返时间，提高了系统性能。

Redis 4.0之前的大key的发现与删除方法
https://blog.csdn.net/Androilly/article/details/101624196?utm_medium=distribute.pc_relevant.none-task-blog-baidujs_baidulandingword-0&spm=1001.2101.3001.4242

1、redis-rdb-tools工具。redis实例上执行bgsave，然后对dump出来的rdb文件进行分析，找到其中的大KEY。

2、redis-cli --bigkeys命令。可以找到某个实例5种数据类型(String、hash、list、set、zset)的最大key。是redis-cli自带的一个命令。它对整个redis进行扫描，寻找较大的key，并打印统计结果。redis-cli --bigkeys的优点是可以在线扫描，不阻塞服务；缺点是信息较少，内容不够精确。扫描结果中只有string类型是以字节长度为衡量标准的。List、set、zset等都是以元素个数作为衡量标准，元素个数多不能说明占用内存就一定多。

3、自定义的扫描脚本，以Python脚本居多，方法与redis-cli --bigkeys类似。

4、debug object key命令。可以查看某个key序列化后的长度，每次只能查找单个key的信息。官方不推荐。

之前的方法要么是用时较长离线解析，或者是不够详细的抽样扫描，离理想的以内存为维度的在线扫描获取详细信息有一定距离。由于在redis4.0前,没有lazy free机制;针对扫描出来的大key，DBA只能通过hscan、sscan、zscan方式渐进删除若干个元素;但面对过期删除键的场景,这种取巧的删除就无能为力。我们只能祈祷自动清理过期key刚好在系统低峰时，降低对业务的影响。

Redis 4.0之后的大key的发现与删除方法

Redis 4.0引入了memory usage命令和lazyfree机制，不管是对大key的发现，还是解决大key删除或者过期造成的阻塞问题都有明显的提升。
memory usage默认抽样5个field来循环累加计算整个key的内存大小，样本的数量决定了key的内存大小的准确性和计算成本，样本越大，循环次数越多，计算结果更精确，性能消耗也越多。

我们可以通过Python脚本在集群低峰时扫描Redis，用较小的代价去获取所有key的内存大小。

Lazyfree的原理是在删除的时候只进行逻辑删除，把key释放操作放在bio(Background I/O)单独的子线程处理中，减少删除大key对redis主线程的阻塞，有效地避免因删除大key带来的性能问题。很多人把Redis通常理解为单线程内存数据库, 其实不然。Redis将最主要的网络收发和执行命令等操作都放在了主工作线程，然而除此之外还有几个bio后台线程，从源码中可以看到有处理关闭文件和刷盘的后台线程，以及Redis4.0新增加的lazyfree线程。

在某些业务场景下，Redis大key的问题是难以避免的，但是，memory usage命令和lazyfree机制分别提供了内存维度的抽样算法和异步删除优化功能，这些特性有助于我们在实际业务中更好的预防大key的产生和解决大key造成的阻塞。