问题引入
1~2亿条数据需要缓存，请问如何设计这个存储案例
单台单机无法承受，使用分布式存储
Redis 分布式系统，官方称为 Redis Cluster，Redis 集群，其是 Redis 3.0 开始推出的分布式解决方案。可以很好地解决不同 Redis 节点存放不同数据，并将用户请求方便地路由到不同 Redis 的问题。
6.1 数据分区算法
分布式数据库系统会根据不同的数据分区算法，将数据分散存储到不同的数据库服务器节点上
常见的数据分区规则有两大类：顺序分区、哈希分区
6.1.1 顺序分区
顺序分区规则将数据按照某种顺序平均分配到不同的节点。不同的顺序方式，产生了不同的分区算法。
（1） 轮询分区算法
每产生一个数据，就依次分配到不同的节点。该算法适合于数据问题不确定的场景。其分配的结果是，在数据总量非常庞大的情况下，每个节点中数据是很平均的。但生产者与数据节点间的连接要长时间保持
（2） 时间片轮转分区算法
在固定长度的时间片内的数据都会分配到一个节点。这些节点会被依次轮转分配数据。该算法可能会出现节点数据不平均的情况（因为每个时间片内产生的数据量可能是不同的）。但生产者与节点间的连接只需占用当前正在使用的这个就可以，其它连接使用完毕后就立即释放。
（3） 数据块分区算法
在整体数据总量确定的情况下，根据各个节点的存储能力，可以将连接的某一整块数据分配到某一节点。
（4） 业务主题分区算法
数据可根据不同的业务主题，分配到不同的节点。
6.1.2 哈希分区
哈希分区规则是充分利用数据的哈希值来完成分配，对数据哈希值的不同使用方式产生了不同的哈希分区算法。哈希分区算法相对较复杂。
（1） 节点取模分区算法
该算法的前提是，每个节点都已分配好了一个唯一序号，对于 N 个节点的分布式系统， 其序号范围为[0, N-1]。然后选取数据本身或可以代表数据特征的数据的一部分作为 key，计算 hash(key)与节点数量 N 的模，该计算结果即为该数据的存储节点的序号。
优点： 简单粗暴，直接有效
缺点： 如果分布式系统扩容或缩容，已经存储过的数据需要根据新的节点数量 N 进行数据迁移，否则用户根据 key 是无法再找到原来的数据的。生产中扩容一般采用翻倍扩容方式，以减少扩容时数据迁移的比例。
（2）一致性哈希分区算法
优点：
- 容错性：假如m2宕机，只有o1需要移动。即受影响的数据仅是此服务器到其环空间中前一台服务器
- 扩展性：假如增加节点m3在o3和o2之间，只需把o3到m2的数据重新录入到m3即可。
缺点： 数据倾斜问题：节点太少时因节点分布不均匀导致数据倾斜
(3)虚拟槽分区算法
首先虚拟出一个固定数量的整数集合，该集合中的每个整数称为一个 slot 槽。槽的数量一般远大于节点数量。将所有 slot 槽平均映射到各个节点。例如，Redis 分布式系统中虚拟了 16384 个 slot 槽，其范围为[0, 16383]。假设共有 3 个节点， 那么 slot 槽与节点间的映射关系如下图所示：
数据只与 slot 有关，与节点没有直接关系。数据只通过其 key 的 hash(key)映射到 slot 槽：slot = hash(key) % slotNums。解耦了数据与节点，客户端无需维护节点，只需维护与 slot 槽的关系即可。
Redis 数据分区采用的就是该算法。其计算槽点的公式为：slot = CRC16(key) % 16384。 CRC16()是一种带有校验功能的、具有良好分散功能的、特殊的 hash 算法函数。其实 Redis 中计算槽点的公式不是上面的那个，而是：slot = CRC16(key) &16383。
若要计算 a % b，如果 b 是 2 的整数次幂，那么 a % b = a & (b-1)。
6.2 系统搭建与运行
6.2.1 系统搭建
（1） 系统架构
下面要搭建的 Redis 分布式系统由 6 个节点构成，这 6 个节点的地址及角色分别如下表。一个 master 配备一个 slave，不过 master 与 slave 的配对关系，在系统搭建成功后会自动分配
（2） 创建目录
在 Redis 安装目录中 mkdir 一个新的目录 cluster-dis，用作分布式系统的工作目录。
（3） 复制 2 个配置文件
将 cluster 目录中的 redis.conf 与 redis6380.conf 文件复制到 cluster-dis 目录。
（4） 修改 redis.conf
指定工作目录为 cluster-dis 目录。持久化文件、节点配置文件将来都会在工作目录中自动生成。
开启redis集群模式
该属性用于指定“集群节点”的配置文件。该文件会在第一次节点启动时自动生成，其生成的路径是在 dir 属性指定的工作目录中。在集群节点信息发生变化后（如节点下线、故障转移等），节点会自动将集群状态信息保存到该配置文件中。 不过，该属性在这里仍保持注释状态。在后面的每个节点单独的配置文件中配置它。
（5） 修改 redis6380.conf
添加该属性
（6） 复制 5 个配置文件
使用 redis6380.conf 复制出 5 个配置文件 redis6381.conf、redis6382.conf、redis6383.conf、redis6384.conf、redis6385.conf。
（7） 修改 5 个配置文件
将其中所有涉及的端口号全部替换为当前文件名称中的端口号。
6.2.2 系统启动与关闭
（1） 启动节点
启动所有 Redis 节点。最后有cluster的标志
之前端口用于主从集群的slave节点，如果没关闭的可以用
kill -9 端口号
杀死进程再重开。
此时查看 cluster-dis 目录，可以看到生成了 6 个 nodes 的配置文件。
（2） 创建系统
6 个节点启动后，它们仍是 6 个独立的 Redis，通过 redis-cli --cluster create 命令可使 6 个节点创建为一个分布式系统。(ip写自己的)
redis-cli --cluster create --cluster-replicas 1 192.168.230.101:6380 192.168.230.101:6381 192.168.230.101:6382 192.168.230.101:6383 192.168.230.101:6384 192.168.230.101:6385
--cluster replicas 1 指定每个 master 会带有一个 slave 作为副本。 回车后会立即看到如下日志：
输入 yes 后回车，系统就会将以上显示的动态配置信息真正的应用到节点上，然后就可看到如下日志：
（3） 测试系统
通过 cluster nodes 命令可以查看到系统中各节点的关系及连接情况。只要能看到每个节点给出 connected，就说明分布式系统已经成功搭建。不过，对于客户端连接命令 redis-cli， 需要注意两点：
- redis-cli 带有-c 参数，表示这是要连接一个“集群”，而非是一个节点
- 端口号可以使用 6 个中的任意一个
（4） 关闭系统
对于分布式系统的关闭，只需将各个节点 shutdown 即可。
6.3集群操作
6.3.1 连接集群
无论要怎样操作分布式系统，都需要首先连接上。
与之前单机连接相比的唯一区别就是增加了参数-c。
6.3.2 写入数据
（1） key 单个写入
无论 value 类型为 String 还是 List、Set 等集合类型，只要写入时操作的是一个 key，那么在分布式系统中就没有问题。例如
（2） key 批量操作
一次写入多个 key，由于多个 key 会计算出多个 slot，多个 slot 可能会对应多个节点。而由于一次只能写入一个节点，所以该操作会报错。
不过，系统也提供了一种对批量 key 的操作方案，为这些 key 指定一个统一的 group，让这个 group 作为计算 slot 的唯一值。
6.3.3 集群查询
（1） 查询 key 的 slot
通过 cluster keyslot 可以查询指定 key 的 slot。例如，下面是查询 emp 的 slot。
（2） 查询 slot 中 key 的数量
通过 cluster countkeysinslot 命令可以查看到指定 slot 所包含的 key 的个数。
（3） 查询 slot 中的 key
通过 cluster getkeysinslot 命令可以查看到指定 slot 所包含的 key。
6.3.4 故障转移
分布式系统中的某个 master 如果出现宕机，那么其相应的 slave 就会自动晋升为 master。如果原 master 又重新启动了，那么原 master 会自动变为新 master 的 slave。
（1） 模拟故障
通过 cluster nodes 命令可以查看系统的整体架构及连接情况
当然，也可以通过 info replication 查看当前客户端连接的节点的角色。可以看到，6382 节点是 master，其 slave 为 6383 节点。
为了模拟 6382 宕机，直接将其 shutdown。
通过客户端连接上 6383 节点后可以查看到，其已经自动晋升为了 master。
重启 6382 节点后查看其角色，发现其自动成为了 6383 节点的 slave。
（2） 全覆盖需求
如果某 slot 范围对应节点的 master 与 slave 全部宕机，那么整个分布式系统是否还可以对外提供读服务，就取决于属性 cluster-require-full-coverage 的设置
该属性有两种取值：
- yes：默认值。要求所有 slot 节点必须全覆盖的情况下系统才能运行。
- no：slot 节点不全的情况下系统也可以提供查询服务。
6.3.5 集群扩容
下面要在正在运行的分布式系统中添加两个新的节点：端口号为 6386 的节点为 master 节点，其下会有一个端口号为 6387 的 slave 节点。
（1） 复制并修改 2 个配置文件
使用 redis6380.conf 复制出 2 个配置文件 redis6386.conf 与 redis6387.conf，并修改其中的各处端口号为相应端口号，为集群扩容做前期准备。
（2） 启动系统与 2 个节点
要添加的两个节点是两个 Redis，所以需要先将它们启动。只不过，在没有添加到分布式系统之前，它们两个是孤立节点，与其它任何节点都没有关系。
（3） 添加 master 节点
通过命令 redis-cli --cluster add-node {newHost}:{newPort} {existHost}:{existPort}可以将新的节点添加到系统中。其中{newHost}:{newPort}是新添加节点的地址，{existHost}:{existPort} 是原系统中的任意节点地址。 添加成功后可看到如下日志。
添加成功后，通过 redis-cli -c -p 6386 cluster nodes 命令可以看到其它 master 节点都分配有 slot，只有新添加的 master 还没有相应的 slot。当然，通过该命令也可以看到该新节点的动态 ID。
（4） 分配 slot
为新的 master 分配的 slot 来自于其它节点，总 slot 数量并不会改变。所以 slot 分配过程本质是一个 slot 的移动过程。
通过 redis-cli –c --cluster reshard {existIP}:{existPort}命令可开启 slot 分配流程。其中地址 {existIP}:{existPort}为分布式系统中的任意节点地址。
开始 Q&A 交互。一共询问了四个问题，这里有三个：
- 准备移动多少 slot？
- 准备由谁来接收移动的 slot？
- 选择要移动 slot 的源节点。有两种方案。如果选择键入 all，所有已存在 slot 的节点作为源节点，即该方案将进行一次 slot 全局大分配。也可以选择其它部分节点作为 slot 源节点。此时将源节点的动态 ID 复制到这里，每个 ID 键入完毕后回车，然后再复制下一个 slot 源节点动态 ID，直至最后一个键入完毕回车后再键入 done。
其首先会检测指定的 slot 源节点的数据，然后制定出 reshard 的方案。同意则键入yes
（5） 添加 slave 节点
现要将 6387 节点添加为 6386 节点的 slave。
redis-cli --cluster add-node {newHost}:{newPort} {existHost}:{existPort} --cluster-slave --cluster-master-id masterID
将新添加的节点直接添加为指定 master 的 slave。
6.3.6 集群缩容
下面要将 slave 节点 6387 与 master 节点 6386 从分布式系统中删除。
（1） 删除 slave 节点
对于 slave 节点，可以直接通过 redis-cli --cluster del-node : delNodeID 命令删除
此时再查看集群：
（2） 移出 master 的 slot
删除一个 master 之前，必须要保证该 master 上没有分配有 slot。
把6386的所有slot给6380
此时发现6386已经没有slot了
（3） 删除 master 节点
6.4分布式系统的限制
Redis 的分布式系统存在一些使用限制：
- 仅支持 0 号数据库
- 批量 key 操作支持有限
- 分区仅限于 key
- 事务支持有限
- 不支持分级管理
