Redis搭建（四）：Sharding集群模式

一、 方案

1. 介绍
redis集群分为服务端集群（Cluster）和客户端分片（Sharding）
服务端集群：redis3.0以上版本实现，使用哈希槽，计算key的CRC16结果再模16834。此处暂不介绍
客户端分片：3.0以下使用，采用Key的一致性hash算法来区分key存储在哪个Redis实例上。每个Redis实例彼此独立，使用ShardedJedisPool

2. Sharding存在两个问题

• 单点故障问题：当集群中的某一台服务挂掉之后，客户端在根据一致性hash无法从这台服务器获取数据。对于单点故障问题，我们可以使用Redis的HA高可用来实现。利用Redis-Sentinal来通知主从服务的切换。
• 扩容问题：因为使用了一致性哈稀进行分片，那么不同的key分布到不同的Redis-Server上，当我们需要扩容时，需要增加机器到分片列表中，这时候会使得同样的key算出来落到跟原来不同的机器上，这样如果要取某一个值，会出现取不到的情况，之前的缓存相当于全部失效。对于扩容问题，Redis的作者提出了一种名为Pre-Sharding的方式。即事先部署足够多的Redis服务。

3. 一致性hash算法（Consistent hashing）

• 环形hash空间，早在1997年就在论文《Consistent hashing and random trees》提出
• 虚拟节点（解决hash倾斜性，多些虚拟节点）
• 命中率计算公式：(1-n/(n+m)*100% （n：服务器数，m：新增的服务器数）

二、 Sharding解决办法

1. 单点故障问题解决：
　　使用Redis主从复制的功能，两台物理主机上分别都运行有Redis-Server，其中一个Redis-Server是另一个的从库，采用双机热备技术，客户端通过虚拟IP访问主库的物理IP，当主库宕机时，切换到从库的物理IP。只是事后修复主库时，应该将之前的从库改为主库（使用命令slaveof no one），主库变为其从库（使用命令slaveof IP PORT），这样才能保证修复期间新增数据的一致性。

2. 通过pre-sharding进行Redis在线扩容。

　　解决动态扩容和数据分区的问题，实际就是在同一台机器上部署多个Redis实例的方式，当容量不够时将多个实例拆分到不同的机器上，这样实际就达到了扩容的效果。Pre-Sharding方法是将每一个台物理机上，运行多个不同端口的Redis实例，假如有三个物理机，每个物理机运行三个Redis实例，那么我们的分片列表中实际有9个Redis实例，当我们需要扩容时，增加一台物理机来代替9个中的一个redis，有人说，这样不还是9个么，是的，但是以前服务器上面有三个redis，压力很大的，这样做，相当于单独分离出来并且将数据一起copy给新的服务器。值得注意的是，还需要修改客户端被代替的redis的IP和端口为现在新的服务器，只要顺序不变，不会影响一致性哈希分片。
拆分过程如下：

1. 在新机器上启动好对应端口的Redis实例。
2. 配置新端口为待迁移端口的从库。
3. 待复制完成，与主库完成同步后，切换所有客户端配置到新的从库的端口。
4. 配置从库为新的主库。
5. 移除老的端口实例。
6. 重复上述过程迁移好所有的端口到指定服务器上。

以上拆分流程是Redis作者提出的一个平滑迁移的过程，不过该拆分方法还是很依赖Redis本身的复制功能的，如果主库快照数据文件过大，这个复制的过程也会很久，同时会给主库带来压力。所以做这个拆分的过程最好选择为业务访问低峰时段进行。

三、实现

• 打开redis.conf，修改端口号，避免端口冲突
• 启动多个Redis实例，每个Redis彼此独立
• 使用RedisShardedPool增加多个Redis