Redis集群2--如何解决容量有限的问题

一、从client解决

1、数据可以分类：客户端的逻辑根据业务拆分

2、数据不能划分：

（1）modula：hash+取模（弊端：取模的值是固定的，影响分布式的扩展性）

（2）random：随机性，自己都找不到是在哪个节点上。消息队列使用这种方式。kafka就是这种方式（不过kafka是基于磁盘的）

（3）ketama：一致性hash算法。（hash属于映射算法的一种）data和node都会参与计算。用一个环形的哈希环来解决。优点：加节点可以分担其他节点的压力，不会造成全局洗牌；缺点：新增节点会造成一小部分数据不能命中（问题：击穿，把查询压到MySQL；解决：每次取最近的两个物理节点）。此种方案更倾向于作为缓存，而不是数据库。

第2大种所有的3小种都存在一个问题：会对redis server端造成连接成本很高。

二、从代理层解决

不管是从client还是代理层来解决，最终都是使用modula、random、ketama三种方式，还是存在着只能作为缓存，而不能作为数据库的缺点。

三、预分区–Redis cluster模式

解决不能作为数据库的缺点。

四、数据分治的问题

无论是client、代理还是cluster模式，都是通过分治来解决问题的，但是他们都存在的问题是聚合操作很难实现、事务很难实现，但是可以使用hash tag（{oo}k1，{oo}k2）来把数据放到同一个节点上。