一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第12天，点击查看活动详情。

1 根据业务拆分

将不同的业务数据发送到不同的redis

2 数据已经没法继续拆解了

比如同一个订单数据非常庞大，无法拆分

取模的时候，有几台redis就模几

弊端：取模数值是固定的，影响分布式下的扩展性

取随机数，将数据随机放在几台redis服务上，缺点是取数据比较难，不知道自己放在了哪里。

映射算法，没有取模的过程

一般规划成一个环形，哈希环,计算自己的hash值，向下取redis的物理节点，存取数据。当有新的server加入的时候，直接设置自己的物理节点即可，对应的数据会存放在新的server上。

优点：加节点可以分担其他节点压力。不会造成全局洗牌。

缺点：新增节点会造成一小部分数据不能命中

问题：没有命中，就击穿了，压到mysql

解决方案：每次取最近的两个物理节点

更倾向于作为缓存用，而不是数据库。

需要关注代理层的性能，此时还需对代理层进行高可用设计

client/proxy的算法中

假如取模为10，则将0，1，2，3，4通过映射关系放到一个redis上。

将5，6，7，8，9放到另一个redis上

在需要加redis服务时：

直接更改映射关系，将3，4，8，9映射到新的redis server上即可，再将原来的redis服务上将3，4，8，9的数据导入到新的redis服务上。

导入的过程，先将数据落盘，将RDB文件导入新的redis，再将增量数据同步到新的redis，当数据追平的时候，再将3，4，8，9的数据发送或从新的redis获取。

这个集群内没有主从概念，客户端可以访问任何一个redis获取数据。

每个redis都会维护一个集群内其他redis的映射关系表，

当一个请求到达随机一个redis的时候，redis服务会根据算法：hash%10计算这个key在哪个redis上，若是在自己服务上，直接返回，若是在其他redis上，则返回重定向命令，让客户端重新访问指定的redis获取数据。