一、从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)来把数据放到同一个节点上。