Redis 的高可用集群
前言
这里来了解一下，Redis 中常见的集群方案
几种常用的集群方案
-
主从集群模式
-
哨兵机制
-
切片集群(分片集群)
主从集群模式
主从集群，主从库之间采用的是读写分离
-
主库：所有的写操作都在主库发生，然后主库同步数据到从库，同时也可以进行读操作；
-
从库：只负责读操作；
主库需要复制数据到从库，主从双方的数据库需要保存相同的数据，将这种情况称为”数据库状态一致”
来看下如何同步之前先来了解下几个概念
- 1、服务器的运行ID(run ID)：每个 Redis 服务器在运行期间都有自己的
run ID，run ID在服务器启动的时候自动生成。
从服务器会记录主服务器的run ID，这样如果发生断网重连，就能判断新连接上的主服务器是不是上次的那一个，这样来决定是否进行数据部分重传还是完整重新同步。
- 2、复制偏移量 offset：主服务器和从服务器都会维护一个复制偏移量
主服务器每次向从服务器中传递 N 个字节的时候，会将自己的复制偏移量加上 N。
从服务器中收到主服务器的 N 个字节的数据，就会将自己额复制偏移量加上 N。
通过主从服务器的偏移量对比可以很清楚的知道主从服务器的数据是否处于一致。
如果不一致就需要进行增量同步了，具体参加下文的增量同步
全量同步
从服务器首次加入主服务器中发生的是全量同步
如何进行第一次同步？
1、从服务器连接到主服务器，然后发送 psync 到主服务器，因为第一次复制，不知道主库run ID,所以run ID为？；
2、主服务器接收到同步的响应，回复从服务器自己的run ID和复制进行进度 offset；
3、主服务器开始同步所有数据到从库中，同步依赖 RDB 文件，主库会通过 bgsave 命令，生成 RDB 文件，然后将 RDB 文件传送到从库中；
4、从库收到 RDB 文件,清除自己的数据，然后载入 RDB 文件；
5、主库在同步的过程中不会被阻塞，仍然能接收到命令，但是新的命令是不能同步到从库的，所以主库会在内存中用专门的 replication buffer，记录 RDB 文件生成后收到的所有写操作，然后在 RDB 文件，同步完成之后，再将replication buffer中的命令发送到从库中，这样就保证了从库的数据同步。
增量同步
如果主从服务器之间发生了网络闪断，从从服务将会丢失一部分同步的命令。
在旧版本，Redis 2.8之前，如果发生了网络闪断，就会进行一次全量复制。
在 2.8 版本之后，引入了增量同步的技术，这里主要是用到了 repl_backlog_buffer
Redis 主库接收到写操作的命令，首先会写入replication buffer(主要用于主从数据传输的数据缓冲)，同时也会把这些操作命令也写入repl_backlog_buffer这个缓冲区。
这里可能有点疑惑，已经有了replication buffer为什么还多余引入一个repl_backlog_buffer呢？
-
repl_backlog_buffer一个主库对应一个repl_backlog_buffer，也就是所有从库对应一个repl_backlog_buffer，从库自己记录自己的slave_repl_offset。 -
replication buffer用于主节点与各个从节点间，数据的批量交互。主节点为各个从节点分别创建一个缓冲区，由于各个从节点的处理能力差异，各个缓冲区数据可能不同。
如何主从断开了，当然对应的replication buffer也就没有了。这时候就依赖repl_backlog_buffer进行数据的增量同步了。
repl_backlog_buffer是一个环形缓冲区，主库会记录自己写到的位置，从库则会记录自己已经读到的位置。
刚开始主服务器的 master_repl_offset 和从服务器 slave_repl_offset 的位置是一样的，在从库因为网络原因断连之后，随着主库写操作的进行，主从偏移量会出现偏移距离。
当从服务器连上主服务器之后，从服务把自己当前的 slave_repl_offset 告诉主服务器，然后主服务器根据自己的 master_repl_offset 计算出和从服务器之间的差距，然后把两者之间相差的命令操作同步给从服务器。
举个栗子
比如这里从服务器1，刚刚由于网络原因断连了一会，然后又恢复了连接，这时候，可能缺失了一段时间的命令同步，repl_backlog_buffer的增量同步机制就登场了。
repl_backlog_buffer会根据主服务器的master_repl_offset和从服务器slave_repl_offset，计算出两者命令之间的差距，之后把差距同步给replication buffer，然后发送到从服务器中。
repl_backlog_buffer中的缓冲空间要设置的大一点，如果从库读的过慢，因为是环形缓冲区，可能出现命令覆盖的情况，如果出现命令被覆盖了，从库的增量同步就无法进行了，这时候会进行一次全量的复制。
缓冲空间的计算公式是：缓冲空间大小 = 主库写入命令速度 * 操作大小 - 主从库间网络传输命令速度 * 操作大小。在实际应用中，考虑到可能存在一些突发的请求压力，我们通常需要把这个缓冲空间扩大一倍，即 repl_backlog_size = 缓冲空间大小 * 2，这也就是 repl_backlog_size 的最终值。
哨兵机制
对于主从集群模式，如果从库发生了故障，还有主库和其它的从库可以接收请求，但是如果主库挂了，就不能进行正常的数据写入，同时数据同步也不能正常的进行了，当然这种情况，我们需要想办法避免，于是就引入了下面的哨兵机制。
什么是哨兵机制
sentinel(哨兵机制)：是 Redis 中集群的高可用方式，哨兵节点是特殊的 Redis 服务，不提供读写，主要来监控 Redis 中的实例节点，如果监控服务的主服务器下线了，会从所属的从服务器中重新选出一个主服务器，代替原来的主服务器提供服务。
核心功能就是:监控，选主，通知。
监控：哨兵机制，会周期性的给所有主服务器发出 PING 命令，检测它们是否仍然在线运行，如果在规定的时间内响应了 PING 通知则认为，仍在线运行；如果没有及时回复，则认为服务已经下线了，就会进行切换主库的动作。
选主：当主库挂掉的时候，会从从库中按照既定的规则选出一个新的的主库，
通知：当一个主库被新选出来，会通知其他从库，进行连接，然后进行数据的复制。当客户端试图连接失效的主库时，集群也会向客户端返回新主库的地址，使得集群可以使用新的主库。
如何保证选主的准确性
哨兵会通过 PING 命令检测它和从库，主库之间的连接情况，如果发现响应超时就会认为给服务已经下线了。
当然这会存在误判的情况，如果集群的网络压力比较大，网路堵塞，这时候会存在误判的情况。
如果误判的节点是从节点，影响不会很大，拿掉一个从节点，对整体的服务，影响不大，还是会不间断的对外提供服务。
如果误判的节点是主节点，影响就很大了，主节点被标注下线了，就会触发后续的选主，数据同步，等一连串的动作，这一连串的动作很很消耗性能的。所以对于误判，应该去规避。
如何减少误判呢？
引入哨兵集群，一个哨兵节点可能会进行误判，引入多个少哨兵节点一起做决策，就能减少误判了。
当有多个哨兵节点的时候，大多数哨兵节点认为主库下线了，主库才会真正的被标记为下线了，一般来讲当有 N 个哨兵实例时，最好要有N/2 + 1个实例判断主库下线了，才能最终判定主库的下线状态。当然这个数值在 Redis 中是可以配置的。
如何选主
选举主节点的规则
1、过滤掉已经下线的服务器；
2、过滤掉最近5秒钟没有回复过主节点的 INFO(用于观察服务器的角色) 命令的服务器，保证选中的服务器都是最近成功通过信的；
3、过滤掉和下线主服务器连接超过down-after-milliseconds*10毫秒的从服务器，down-after-milliseconds是主服务器下线的时间，这一操作避免从服务器与主服务器过早的断开，影响到从库中数据同步，因为断开时间越久，从库里面的数据就越老旧过时。
然后对这些服务器根据slave-priority优先级(这个优先级是手动设置的，比如希望那个从服务器优先变成主服务器，优先级就设置的高一点) 进行排序。
如果几台从服务器优先级相同，然后根据复制偏移量从大到小进行排序，如果还有相同偏移量的从服务器，然后按照 runID 从小到大进行排序，直到选出一台从服务器。
哨兵进行主节点切换
当根据选举规则，选出了可以成为主节点的从节点，如何进行切换呢？
在哨兵中也是有一个 Leader 节点的，当一个从库被选举出来，从库的切换是由 Leader 节点完成的。
Leader 节点的选举用的是 Raft 算法，关于什么是 Raft 算法可参考Raft一致性算法原理
在raft算法中，在任何时刻，每一个服务器节点都处于这三个状态之一：
-
Follower:追随者，跟随者都是被动的：他们不会发送任何请求，只是简单的响应来自领导者或者候选人的请求；
-
Candidate:候选人，如果跟随者接收不到消息，那么他就会变成候选人并发起一次选举，获得集群中大多数选票的候选人将成为领导者。
-
Leader:领导者，系统中只有一个领导人并且其他的节点全部都是跟随者，领导人处理所有的客户端请求（如果一个客户端和跟随者联系，那么跟随者会把请求重定向给领导人）
哨兵节点的选举总结起来就是：
1、每个做主观下线的sentinel节点向其他sentinel节点发送命令，要求将自己设置为领导者；
2、接收到的sentinel可以同意或者拒绝；
3、如果该sentinel节点发现自己的票数已经超过半数并且超过了 quorum，quorum 用来配置判断主节点宕机的哨兵节点数。简单点讲就是：如果 Sentinel 集群有 quorum 个哨兵认为 master 宕机了，就「客观」的认为 master 宕机了；
4、如果此过程选举出了多个领导者，那么将等待一段时重新进行选举；
故障转移
-
sentinel的领导者从从机中选举出合适的丛机进行故障转移；
-
对选取的从节点进行
slave of no one命令，（这个命令用来让从机关闭复制功能，并从从机变为主机）； -
更新应用程序端的链接到新的主节点；
-
对其他从节点变更 master 为新的节点；
-
修复原来的 master 并将其设置为新的 master 的从机。
消息通知
哨兵和哨兵之前，哨兵和从库之间，哨兵和客户端是如何相互发现，进行消息传递？
哨兵和哨兵之间的相互发现，通过 Redis 提供的pub/sub机制实现，因为每个哨兵节点都会和主库进行连接，通过在主库中发布信息，订阅信息，就能找到其他实例的连接信息。
哨兵节点和从库，通过哨兵向主库发送 INFO 命令来完成，哨兵给主库发送 INFO 命令，主库接受到这个命令后，就会把从库列表返回给哨兵。接着，哨兵就可以根据从库列表中的连接信息，和每个从库建立连接，并在这个连接上持续地对从库进行监控。
哨兵和客户端之间：每个哨兵实例也提供pub/sub机制，客户端可以从哨兵订阅消息，来获知主从库切换过程中的不同关键事件。
哨兵提升一个从库为新主库后，哨兵会把新主库的地址写入自己实例的 pubsub（switch-master） 中。客户端需要订阅这 个pubsub，当这个 pubsub 有数据时，客户端就能感知到主库发生变更，同时可以拿到最新的主库地址，然后把写请求写到这个新主库即可，这种机制属于哨兵主动通知客户端。
如果客户端因为某些原因错过了哨兵的通知，或者哨兵通知后客户端处理失败了，安全起见，客户端也需要支持主动去获取最新主从的地址进行访问。
切片集群
对于数据库我们知道，如果数据量大会进行分库分表，一般有两种方案纵向拆分和横向拆分。这在 Redis 中，同样适用。
Redis 中的扩展
-
纵向扩展：更改节点类型以调整集群大小，升级单个Redis实例的资源配置，包括增加内存容量、增加磁盘容量、使用更高配置的CPU。
-
横向扩展：通过添加或删除节点组（分片）来更改复制组中的节点组（分片）数量。
简单点讲就是：垂直扩容就是增加自身的容量，横向扩容就是加机器。
缺点对比
纵向扩容：
1、如果一味的增加自身的容量，意味着自身存储的数据将会越来越大，过大的数据，持久化时间将会变得很长，影响自身的响应速度；
2、同样堆硬件总归是有上线，达到一定量之后，还是要考虑进行横向扩容；
横向扩容：
横向扩容要面临的问题，如果发生了分片的扩容，就需要考虑数据的迁移，同时数据切片后，在多个实例之间如何分布？，客户端如何知道访问的数据在哪个实例中。。。
虽然有这些问题的存在，好在已经有一些成熟的方案来处理横向扩容所遇到的问题了
官方的集群解决方案就是Redis Cluster；社区的解决方案有 Codis 和 Twemproxy，Codis 是由我国的豌豆荚团队开源的，Twemproxy 是 Twitter 团队的开源的。
这里主要看下Redis Cluster是如何进行处理的
Redis Cluster方案
1、Redis Cluster方案采用哈希槽来处理 KEY 在不同实例中的分布，一个切片集群共有16384个哈希槽，这些哈希槽类似于数据分区，每个键值对都会根据它的key，被映射到一个哈希槽中。
2、一个 KEY ，首先会根据CRC16算法计算一个16 bit的值；然后，再用这个 16bit 值对 16384 取模，得到0~16383范围内的模数，每个模数代表一个相应编号的哈希槽。
3、然后把哈希槽分配到所有的实例中，例如，如果集群中有N个实例，那么，每个实例上的槽个数为16384/N个。
当然这是平均分配的，如果平均分配额哈希槽中，某一个实例中 KEY，存储的数据比较大，造成某一个实例的内存过大，这时候可以通过cluster addslots手动调节哈希槽的分配。
当手动分配哈希槽时，需要把16384个槽都分配完，否则Redis集群无法正常工作。
客户端中的 KEY 如何找到对应的实例
在集群刚刚创建的时候，每个实例只知道自己被分配了哪些哈希槽，是不知道其他实例拥有的哈希槽信息的。但是，Redis 实例会把自己的哈希槽信息发给和它相连接的其它实例，来完成哈希槽分配信息的扩散。
所以当客户端和集群实例连接后，就可以知道所有的哈希槽的映射，客户端会把哈希槽的映射保存在本地，这样如果客户端响应一个 KEY ，计算出哈希槽，然后就可以向对应的实例发送请求了。
哈希槽重新分配
数据在可能发生迁移，这时候哈希槽就会重新分配了
栗如：
1、集群中的实例，有增加或减少；
2、引入了负载均衡，需要重新分配哈希槽；
因为重新分配了哈希槽，所以原来的映射关系可能发生了改变，实例之间可以通过相互通知，快速的感知到映射关系的变化。但是，客户端无法主动感知这些变化，客户端对 KEY 的响应，可能依旧映射到了之前的实例节点，面对这种情况，如何处理呢？
1、如果数据已经迁移完了
Redis Cluster中提供重定向机制，如果一个实例接收到客户端的请求，但是对应的 KEY 已经转移到别的实例节点中了，这时候会计算出 KEY 当前所处实例的地址，然后返回给客户端，客户端拿到最新的实例地址，重新发送请求就可以了。
$ GET hello
(error) MOVED 12320 172.168.56.111:6379
2、数据迁移了一半
如果在迁移的过程中，只迁移了一半的数据，这时候服务器端就会返回 ASK 告知客户端
GET hello
(error) ASK 1332 012320 172.168.56.111:6379
ASK 就表示当前正在迁移中，客户端需要访问数据，就还需要向返回的地址信息，发送一条 ASKING 命令，让这个实例允许客户端的访问请求，然后客户端再发送具体的业务操作命令。
Redis Cluster 的规模是越大越好吗
Redis Cluster 能保存的数据量以及支撑的吞吐量，跟集群的实例规模密切相关，原则上如果实例越多，能够承担的吞吐量和就越大，不过真的是这样吗？
Redis 官方给出了 Redis Cluster 规模上限，就是一个集群运行1000个实例。那么为什么要来限制集群的规模呢，这里分析下：
Redis Cluster 在运行时，每个实例上都会保存 Slot 和实例的对应关系（也就是Slot映射表），以及自身的状态信息。
为了让集群中的每个实例都知道其它所有实例的状态信息，实例之间会按照一定的规则进行通信。这个规则就是 Gossip 协议。
Gossip 协议的工作原理可以概括成两点。
1、每个实例之间会按照一定的频率，从集群中随机挑选一些实例，把 PING 消息发送给挑选出来的实例，用来检测这些实例是否在线，并交换彼此的状态信息。PING消息中封装了发送消息的实例自身的状态信息、部分其它实例的状态信息，以及 Slot 映射表。
2、一个实例在接收到 PING 消息后，会给发送PING消息的实例，发送一个 PONG 消息。PONG 消息包含的内容和 PING 消息一样。
通信的开销受通信消息大小和通信频率的影响
Gossip消息大小
Redis实例发送的PING消息的消息体是由clusterMsgDataGossip结构体组成的，这个结构体的定义如下所示：
typedef struct {
char nodename[CLUSTER_NAMELEN]; //40字节
uint32_t ping_sent; //4字节
uint32_t pong_received; //4字节
char ip[NET_IP_STR_LEN]; //46字节
uint16_t port; //2字节
uint16_t cport; //2字节
uint16_t flags; //2字节
uint32_t notused1; //4字节
} clusterMsgDataGossip;
这样看下来一个 Gossip 消息大小在 104 字节。
每个实例在发送一个Gossip消息时，除了会传递自身的状态信息，默认还会传递集群十分之一实例的状态信息。
所以，对于一个包含了1000个实例的集群来说，每个实例发送一个PING消息时，会包含100个实例的状态信息，总的数据量是 10400字节，再加上发送实例自身的信息，一个Gossip消息大约是10KB。
此外，为了让Slot映射表能够在不同实例间传播，PING消息中还带有一个长度为 16,384 bit 的 Bitmap，这个Bitmap的每一位对应了一个Slot，如果某一位为1，就表示这个Slot属于当前实例。这个Bitmap大小换算成字节后，是2KB。我们把实例状态信息和Slot分配信息相加，就可以得到一个PING消息的大小了，大约是12KB。
PONG消息和PING消息的内容一样，所以，它的大小大约是12KB。每个实例发送了PING消息后，还会收到返回的PONG消息，两个消息加起来有24KB。
这样看下来如果集群数量的增加，消息的大小就会增加。越大的消息传输，对性能影响就越大。
消息传递的频率
Redis Cluster的实例启动后，默认会每秒从本地的实例列表中随机选出5个实例，再从这5个实例中找出一个最久没有通信的实例，把 PING 消息发送给该实例。这是实例周期性发送 PING 消息的基本做法。
但是，这里有一个问题：实例选出来的这个最久没有通信的实例，毕竟是从随机选出的5个实例中挑选的，这并不能保证这个实例就一定是整个集群中最久没有通信的实例。
所以 Redis Cluster 的实例会按照每 100ms 一次的频率，扫描本地的实例列表，如果发现有实例最近一次接收 PONG消息的时间，已经大于配置项 cluster-node-timeout 的一半了（cluster-node-timeout/2），就会立刻给该实例发送 PING 消息，更新这个实例上的集群状态信息。
所以每秒单实例发送的 PING 数量就是
PING消息发送数量 = 1 + 10 * 实例数（最近一次接收PONG消息的时间超出cluster-node-timeout/2）
1 是指单实例常规按照每 1 秒发送一个PING消息，10 是指每 1 秒内实例会执行 10 次检查。
假设单个实例检测发现，每100毫秒有10个实例的PONG消息接收超时，那么，这个实例每秒就会发送101个PING消息，约占1.2MB/s带宽。如果集群中有30个实例按照这种频率发送消息，就会占用36MB/s带宽，这就会挤占集群中用于服务正常请求的带宽。
所以整体看下来如果 Redis Cluster 集群的规模越大，网络拥塞的概率就越高，相应的，PONG消息超时的发生概率就越高，这就会导致集群中有大量的心跳消息，影响集群服务正常请求。
虽然我们可以通过调整cluster-node-timeout配置项减少心跳消息的占用带宽情况，但是，在实际应用中，如果不是特别需要大容量集群，我建议你把 Redis Cluster 的规模控制在400~500个实例。
避免 Hot Key
Hot Key就是采用切片集群部署的 Redis ,出现的集群访问倾斜。
切片集群中的 Key 最终会存储到集群中的一个固定的 Redis 实例中。某一个 Key 在一段时间内访问远高于其它的 Key,也就是该 Key 对应的 Redis 实例,会收到过大的流量请求，该实例容易出现过载和卡顿现象，甚至还会被打挂掉。
常见引发热点 Key 的情况：
1、新闻中的热点事件；
2、秒杀活动中的，性价比高的商品；
如何发现 Hot Key
- 1、提现预判；
根据业务经验进行提前预判；
- 2、在客户端进行收集；
通过在客户端增加命令的采集，来统计发现热点 Key;
- 3、使用 Redis 自带的命令排查；
使用monitor命令统计热点key（不推荐，高并发条件下会有造成redis 内存爆掉的隐患）；
hotkeys参数，redis 4.0.3提供了redis-cli的热点key发现功能，执行redis-cli时加上–hotkeys选项即可。但是该参数在执行的时候，如果key比较多，执行起来比较慢。
- 4、在Proxy层做收集
如果集群架构引入了 proxy，可以在 proxy 中做统计
- 5、自己抓包评估
Redis客户端使用TCP协议与服务端进行交互，通信协议采用的是RESP。自己写程序监听端口，按照RESP协议规则解析数据，进行分析。缺点就是开发成本高，维护困难，有丢包可能性。
Hot Key 如何解决
知道了Hot Key如何来应对呢
1、对 Key 进行分散处理
举个栗子
有一个热 Key 名字为Hot-key-test,可以将其分散为Hot-key-test1，Hot-key-test2…然后将这些 Key 分散到多个实例节点中，当客户端进行访问的时候，随机一个下标的 Key 进行访问，这样就能将流量分散到不同的实例中了，避免了一个缓存节点的过载。
一般来讲，可以通过添加后缀或者前缀，把一个 hotkey 的数量变成 redis 实例个数 N 的倍数 M，从而由访问一个redis key变成访问N * M个redis key。 N*M个redis key经过分片分布到不同的实例上，将访问量均摊到所有实例。
const M = N * 2
//生成随机数
random = GenRandom(0, M)
//构造备份新key
bakHotKey = hotKey + “_” + random
data = redis.GET(bakHotKey)
if data == NULL {
data = GetFromDB()
redis.SET(bakHotKey, expireTime + GenRandom(0,5))
}
2、使用本地缓存
业务端还可以使用本地缓存，将这些热 key 记录在本地缓存，来减少对远程缓存的冲击。
避免 Big Key
什么是 Big Key：我们将含有较大数据或含有大量成员、列表数的Key称之为大Key。
-
一个 STRING 类型的 Key，它的值为 5MB（数据过大）
-
一个 LIST 类型的 Key，它的列表数量为 20000 个（列表数量过多）
-
一个 ZSET 类型的 Key，它的成员数量为 10000 个（成员数量过多）
-
一个 HASH 格式的 Key，它的成员数量虽然只有 1000 个但这些成员的 value 总大小为 100MB（成员体积过大）
Big Key 存在问题
-
内存空间不均匀：如果采用切片集群的部署方案，容易造成某些实例节点的内存分配不均匀；
-
造成网络拥塞：读取 bigkey 意味着需要消耗更多的网络流量，可能会对 Redis 服务器造成影响；
-
过期删除：big key 不单读写慢，删除也慢，删除过期 big key 也比较耗时；
-
迁移困难：由于数据庞大，备份和还原也容易造成阻塞，操作失败；
如何发现 Big Key
-
使用 redis-cli 客户端的命令 –bigkeys;
-
生成 rdb 文件，离线分析 rdb 文件。比如：redis-rdb-cli，rdbtools;
-
通过 scan 命令，对扫描出来的key进行类型判断，例如：string长度大于10K，list长度大于10240认为是big bigkeys;
Big Key 如何避免
对于Big Key可以从以下两个方面进行处理
合理优化数据结构：
-
1、对较大的数据进行压缩处理；
-
2、拆分集合：将大的集合拆分成小集合（如以时间进行分片）或者单个的数据。
选择其他的技术来存储 big key：
- 使用其他的存储形式，考虑使用 cdn 或者文档性数据库 MongoDB。
Big Key 如何删除
直接使用 DEL 命令会发生什么？危险：同步删除 bigkey 会阻塞 Redis 其他命令，造成 Redis 阻塞。
推荐使用 UNLINK 命令，异步删除 bigkey，不影响主线程执行其他命令。
在业务的低峰期使用 scan 命令查找 big key，对于类型为集合的key，可以使用脚本逐一删除里面的元素。
参考
【Redis核心技术与实战】https://time.geekbang.org/column/intro/100056701
【Redis设计与实现】https://book.douban.com/subject/25900156/
【估算两台服务器同时故障的概率】https://disksing.com/failure-probability-analysis/
【Redis中哨兵选举算法】https://blog.csdn.net/weixin_44324174/article/details/108939199
【如何处理redis集群中hot key和big key】https://juejin.cn/post/6844903743083773959
【谈谈redis的热key问题如何解决】https://www.cnblogs.com/rjzheng/p/10874537.html
