【Redis】| 总结/Edison Zhou
1Redis的纵向扩展与横向扩展
对于Redis来说，其扩展性也可以分为两类：纵向扩展（scalce up） 与 横向扩展（scale out）。
纵向扩展
所谓纵向扩展，就是给单台Redis实例升级资源配置，如CPU、内存、磁盘等。 其优点在于简单+直接，但缺点也很明显：
首先，单台Redis实例的数据量增大后，如果使用RDB持久化，在fork子进程时可能会导致主线程的阻塞（因为数据量很大）。 其次，纵向扩展也会受到硬件和成本的限制，你没办法扩展到无穷大吧？
横向扩展
所想横向扩展，就是增加Redis实例的个数，如原来使用一个Redis实例，现在使用三个。
其优点刚好就破解了纵向扩展的缺点，不用担心硬件和成本的限制，只需要增加实例个数就可以了。 在面向百万、千万级别的用户规模时，横向扩展的 Redis 切片集群会是一个好的选择。
2Redis Cluster切片集群机制
在 Redis 3.0 之前，Redis 官方并没有提供切片集群方案，但是，其实当时业界已经有了一些切片集群的方案。从 Redis 3.0 开始，官方提供了一个名为 Redis Cluster 的方案，用于实现切片集群，进而帮助我们实现横向扩展。
使用Redis Cluster不难，我们需要了解其实现机制，帮助我们理解其思想。总体来说，它主要解决了引入切片之后的两个核心问题：
（1）数据切片后，在多个实例之间如何分布？
（2）客户端怎么确定想要访问的数据在哪个实例上？
下面一个一个来看Redis Cluster是怎么解决的。
数据分片和实例的对应分布关系
Redis Cluster 方案采用哈希槽（Hash Slot），来处理数据和实例之间的映射关系。
在 Redis Cluster 方案中，一个切片集群共有 16384 个哈希槽，这些哈希槽类似于数据分区，每个键值对都会根据它的 key，被映射到一个哈希槽中。
可以看出，哈希槽其实就是一个抽象层，将key的分布与具体的Redis实例解耦，有利于Redis数据的均衡分布。
Step1.根据键值对的 key，按照CRC16 算法计算一个 16 bit 的值；
Step2.再用这个 16bit 值对 16384 取模，得到 0~16383 范围内的模数，每个模数代表一个相应编号的哈希槽。
那么问题来了，哈希槽又是如何与实例对应上的呢？
Redis Cluster提供了两种，一种是由Redis自动平均分配（使用cluster create命令创建集群），即每个实例可以分配到16384/N个哈希槽（N为实例个数），另一种是由管理员手动分配（使用cluster meet命令创建集群）。
需要注意的是：如果是手动分配，需要需要把 16384 个槽都分配完，否则 Redis 集群无法正常工作。
# 手动分配哈希槽示例> redis-cli -h 172.16.19.3 –p 6379 cluster addslots 0,1> redis-cli -h 172.16.19.4 –p 6379 cluster addslots 2,3> redis-cli -h 172.16.19.5 –p 6379 cluster addslots 4
最后，数据、哈希槽、Redis实例三者之间的关系可以用下图表示： 客户端定位数据所在的实例
Redis 实例会把自己的哈希槽信息发给和它相连接的其它实例，来完成哈希槽分配信息的扩散。当实例之间相互连接后，每个实例就有所有哈希槽的映射关系了。
客户端收到哈希槽信息后，把哈希槽信息在本地缓存。当客户端请求键值对时，会先计算键所对应的哈希槽，然后再给相应的实例发送请求。
不过，实际场景中，Redis实例 和 哈希槽 的对应关系并不是一成不变的，而是会随着实例个数的增减而变化，比如Redis Cluster会重新分配哈希槽以确保负载均衡。
因此，Redis Cluster 方案提供了一种重定向机制，它提供了两个核心命令 MOVED 和 ASK。
（1）MOVED命令
当客户端把一个键值对的操作请求发给一个实例时，如果这个实例上并没有这个键值对映射的哈希槽，那么，这个实例就会给客户端返回下面的 MOVED 命令响应结果，这个结果中就包含了新实例的访问地址。
GET hello:key(error) MOVED 13320 172.16.19.5:6379
它表示客户端请求的key在另外一台实例172.16.19.5的哈希槽13320上，换句话说，原来的13320已经挪到172.16.19.5上了。于是，客户端就会向172.16.19.5发起键值对请求，然后更新本地缓存的哈希槽分配。
MOVED命令是针对某个哈希槽数据已经完全转移到新实例的情况，但如果是部分数据完成了转移，其他数据仍然在迁移中，这时Redis还不能直接返回MOVED命令进行客户端重定向，它选择的是返回ASK命令，如下代码所示： GET hello:key(error) ASK 13320 172.16.19.5:6379
它表示的是客户端需要先给172.16.19.5发送一个 ASKING 命令。这个命令的意思是，让这个实例允许执行客户端接下来发送的命令。然后，客户端再向这个实例发送 GET 命令，以读取数据。
和 MOVED 命令不同，ASK 命令并不会更新客户端本地缓存的哈希槽分配信息。换句话说，ASK命令只是让客户端给新实例发一次数据请求，ASK 命令并不会让客户端后续所有命令都发到新实例，当然，它更不能更新客户端本地缓存。
对比总结：
MOVE命令是在数据迁移完毕后被响应，客户端会更新本地缓存。
ASK命令是在数据迁移中被响应，不会让客户端更新缓存。
3Redis Cluster配置说明
Redis Cluster配置说明如下：
# 是否开启 cluster，yes 表示开启，no 表示普通的 redis 实例cluster-enabled yes# 该文件列出了集群中的其他节点，它们的状态、持久变量等内容。由于某些消息接收，此文件通常会被重写并刷新到磁盘上。# 保存集群中其他节点信息的文件，默认为 nodes.conf ，需要为每个节点设置单独的文件名。# 该文件无需手动配置，Redis Cluster 自动维护cluster-config-file nodes.conf# 节点互连超时时间，毫秒为单位。如果超时，则认为此节点不可用，将由其从节点进行故障转移，也就是由其从节点成为主节点。# 这个参数控制 Redis Cluster 中的其他重要内容。# 如果主节点超时，则主节点对查询服务也不再响应。cluster-node-timeout 5000# 当前节点是从节点且在故障转移时使用# 如果设置为零，则副本将始终认为自己有效，因此将始终尝试对主节点进行故障转移，无论主节点和副本节点之间断开连接有多久。# 如果设置为正数，Redis 会计算当前从节点是否可以进行故障转移。计算公式为：(cluster-node-timeout 配置的毫秒数 * cluster-slave-validity-factor)# 例如 cluster-node-timeout 配置为 5000，cluster-slave-validity-factor 配置为 10，如果当前从节点和主节点断开时间超过 50 秒，则不可用于故障转移。# 请注意，如果没有能够对主节点进行故障转移的从节点，则任何非零值都可能导致当前 Redis Cluster 示例不可用。# 在这种情况下，只有当原始主节点重新加入集群时，集群才会恢复可用。cluster-slave-validity-factor 10# 从节点自动迁移时使用# 当一个主节点有多个从节点，而另外一个主节点没有从节点时，Cluster 会自动进行从节点迁移。# 这个配置就是用来设置当一个主节点最少有多少个从节点时，其余的从节点可以迁移到别的主节点。cluster-migration-barrier 1# 设置为 yes 表示有一个主节点不可用且没有对应的从节点进行故障转移时，则整个集群不可用。# 设置为 no 表示有一个主节点不可用且没有对应的从节点进行故障转移时，整个集群仍然可用，此时由其他主节点提供服务，当然下线主节点对应的哈希槽是不可用的# 默认为 yes，建议设置为 nocluster-require-full-coverage yes# 默认是no，当集群认为有节点出现故障时，该故障可能是因为网络分区导致该节点与集群隔离开，或者该节点无法得到集群大多数节点的认同时，# 此时该故障节点将会拒绝任何读写请求，这样的好处是将阻止客户端从该节点读取到不一致的数据。# 该参数也可以被配置为yes，即使该节点故障也允许读操作，这在应用要求优先进行读取操作但是可以阻止不一致性写入的情况下比较有用，# 当Redis集群仅有少量切片情况下且没有从节点执行故障转移时可以考虑使用。cluster-allow-reads-when-down no
本文介绍了Redis纵向扩展与横向扩展的基本概念，总结了Redis Cluster切片集群的实现机制，聚焦了两个核心问题背后的解决方法，有助于我们更好地使用Redis Cluster切片集群以满足大用户量的业务场景。
参考资料
极客时间，蒋德钧《Redis核心技术与实战》
黄建宏，《Redis设计与实现》
拉钩教育，刘海丰《架构设计面试精讲》
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！
下一主题
