Redis实战（七）：redis的集群：主从复制、CAP、PAXOS、cluster分片集群 2

上节回顾

上一节我们讲了AKF拆分原则，讲了Redis主从复制的方式，是X轴方向的拓展，实现了HA，但是没有解决单节点数据的容量有限问题。

如何解决单节点数据容量的问题

如果数据可以分类，交集不多，可以考虑按业务拆分

如果数据没有办法划分拆解：

采用sharding分片
下面这三种方案都发生在客户端

1、Hash+取模（几乎没人用）

2、使用random随机分配节点，适合做消息队列

3、使用kmeta一致性哈希，规划一个环形哈希环
一致性哈希：https://www.jianshu.com/p/735a3d4789fc

物理节点：本来有两个redis的物理节点。
虚拟节点：可以让一个物理设备出现在好几个节点上。环上就有20个物理点。这样解决了数据倾斜的问题。
这种方案更倾向于作为缓存，而不是数据库用。
（拓扑关系图）

redis连接对server端的成本很高，是对server端造成的

解决方式：
类似于nginx反向代理，增加一个接入层
我们增加一个代理层，我们只需要关注代理层性能就可以了。
代理层里面有了逻辑实现，例如modula，random，kemata，这叫无状态的。这样减轻了客户端的代码。
如果请求压力太大，代理层hold不住怎么办？我们看图的下半部分这个模型。
在代理层前面加一个LVS，LVS做一个主备，主备之间通过keepalived，除了监控两个LVS的健康状态之外，也监控proxy的健康状态。

这些内容来自于哪儿？https://github.com/twitter/twemproxy

无论你企业后面技术多么复杂，对于客户端，都是透明的。你要考虑客户端代码逻辑的复杂度成本，

不要因为技术而技术。redis连多线程都没有使用，它并不希望redis被引入那么多的功能。

以上三种模式的弊端是不能做分布式数据库用。一致性哈希增删节点的时候会让一部分数据时间窗不可用。

新增节点会对算法带来挑战，比如rehash等，怎么解决这个问题？
我们引入预分区的概念

预分区

以前我们模3，如果现在我们模10，中间再加一层mapping

新增节点，迁移数据的时候，把槽位中部分数据拿出来，放进新的节点即可

redis cluster模式：无主模型
http://redis.cn/topics/partitioning.html
客户端可以去任意一个redis节点取数据，每一个redis都有所有key的映射关系算法，知道别人持有哪些分片，会给客户端返回应该重定向到的redis，由客户端自己去正确的redis上取。
例如，客户端去redis3上找k1，redis2说，你应该去redis3找。于是客户端就去redis3上取k1

数据分治会带来一个问题：聚合操作很难实现。
事务很难实现
两个set取交集，可以实现但是redis并没有去实现，因为其中有一个数据移动的过程->redis的作者想要计算向数据移动，而不是去移动数据。redis的作者做了取舍，将影响性能的功能都取消掉了。
redis代理关闭了一些操作：

可以由人去实现：hash tag
例如我们将带有相同前缀的key放在一个节点上（我手动把它放到一起去，就能实现事务了）

Predixy

github上有完整的中文安装步骤