虽然单机版的redis拥有较高的稳定性，但是在面对服务器宕机、网络中断、操作系统崩溃等问题时，该如何保证它的高可用？面对海量的业务数据，redis又该如何存储呢？为了解决上述问题，redis集群应运而生。本文不涉及具体的redis集群实现，而是从如何保证高可用和提供海量存储两个方面讲解构建redis集群依赖的基础分布式原理。
集群的几大要素
High Availablity
为了保证高可用，一种朴素的思想就是将数据复制到多个实例中，当一个实例出现问题不能对外服务时，则快速将其切换到另一个实例，由新的实例提供服务。本节主要讲如何复制和切换。
复制
典型的复制方式有主从复制（mysql）、多主复制（海外双机房）、无主复制（cassandra）。其中主从复制最简单，redis采用主从复制的方式。
redis主从复制的原理：
https://blog.csdn.net/fuyuwei2015/article/details/70922729
https://blog.csdn.net/sk199048/article/details/50725369
https://blog.csdn.net/sk199048/article/details/77922589
这里需要注意：redis存在弱网复制的情况
Failover
当我们有了主从节点后，就需要通过外部服务（比如ping以下，如果超时则认为断开）去监听当前的redis实例是否存活，一旦检测到它不再存活时，则将从节点切换至主节点。
这里需要注意：如果一个服务检测到redis不再存活，即认为该实例挂了，容易因为网络文档导致误判。所以需要他的小伙伴们帮他确认一下，所以也就有了主观下线和客观下线。
这个外部服务可以是sentinel，也可是实现了这种协议的任意服务。
参考：http://redisdoc.com/topic/sentinel.html
分区
当我们的数据量非常大以后，单机是无法保存这么多数据的。所以我们可以将整个数据集按照某种规则分成若干个小的数据集，也就是数据分片。
分区策略：一致性hash vs 分布式hash
当然我们可以简单的用一个hash算法将不同的key hash到不同的redis实例中。但是随着业务的发展，我们的数据量又上了一个数量级，很快我们的分片又到了容量上限。于是，我们需要为这个redis集群增加更多分配。这时我们发现基于hash的分片方式几乎需要将原本集群中的所有数据都重新写一遍。所以缩扩容时的关键指标是如何降低迁移的key的数量
- 一致性hash（https://blog.csdn.net/cywosp/article/details/23397179）：简单讲就是将redis实例通过某个属性（比如ip）映射到一个环上，每个实例就是环上的一个点。key也映射到这个环上，key在环上顺时针走，碰到的第一个点就是它从属的redis实例。redis映射到环上以后，各自分配的圆周长不一定是均匀的，所以通常会增加虚拟节点，让其变得更加均匀。如果扩容了，将对应的节点后面一个节点的部分key分配给它即可，不会影响到其他节点的key的分布，从而影响的key的数量也就减少了。
- 分布式hash: redis-cluster将所有key空间分成16384个slot，通过hash(key)%16383将key路由到指定slot。每个redis实例会记录自己保持了哪些slot，并记录该slot中保存了哪些key。则迁移时仅需要将相关的slot对应的key迁移到新的实例中即可。
一致性hash vs 分布式hash：从需要解决的问题来看，两者都是为了减少迁移时涉及的key的数量。而一致性hash没有保存key和节点的映射关系，没法在缩扩容时提前将涉及的key迁移到新的实例中，所以缓存性redis集群可以采用一致性hash的方式（因为允许cache miss），而存储型redis集群不允许cache miss，所以使用了采用slot机制的redis集群。
路由组件的选择
一般来说，分布式存储路由的方式有两个种：1.基于中心化的proxy；2.非中心化的smart client
- proxy
redis 常用的proxy是twemproxy
https://github.com/twitter/twemproxy
优点：路由逻辑对客户端透明，能够统一注入逻辑
缺点：1. 增加一次网络调用；2. 集群配置不允许热加载，集群拓扑变更时需要重启 - smartclient(redis-cluster)
即client可以获知集群的拓扑，将请求直接发往对应的redis实例
优点：直接调用redis，性能更高
缺点：客户端实现复杂，需要升级客户端
迁移
todo
4691
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
