Redis 的集群 --- 数据分开扛
序言
上一章内容中我们介绍到了 哨兵 来保证我们主机在发生故障时能够及时地选出一个新的主机，但是哨兵地加入只是提供了 高可用性 和 故障转移，并没有真正的提升架构的性能。如果不断地加入新的数据的话，主机的压力会很大，一方面是内存占用，一方面是同步数据到从机。
现有的架构可能不是很好解决现在的问题，集群 来咯，数据分开存，大大减轻每一个主机的压力。具体怎么实现的呢？让我们开始吧。
一、集群的架构
集群会存在多个主机，每一个主机存储整体数据的一部分，每一个主机都会存在从机以防主机故障替换，整体的结构如下：
现在问题来了，怎么确定每一台主机存储了哪一些键呢？新加入的键加入到哪一个主机呢？咋们马上说到。
二、集群的工作原理
1. 集群的分片
现在笔者所知道的分片方式有三种：哈希取余，一致性哈希，哈希槽，相较最为全面的，也是现在所使用的是 哈希槽，我们来看看各自的优劣吧：
哈希取余法
首先获取一个键所对应的分区非常简单，就需要使用公式：
SLOT = hash(key) % N
在这里的 N 是我们的分区个数，非常简单吧，这是他最大的优势😙。但是当我们的分区个数发生变化时，需要将我们的整体数据重新映射到对应的分区，这个时候就涉及到大量的数据迁移的过程，代价非常高。
一致性哈希法
这个算法的提出就是解决了 哈希取余法 在增删分区时会涉及到大量的数据移动的问题。首先我们需要知道问题的起因是因为 N （分区个数）发生了变化，所以为了解决这个问题，直接将 N 的大小固定为 2^32，这样我们的 hash(key) % 2^32 的范围一定在 [0, 2^32 - 1] ，形成一个哈希环：
然后我们将分区提供某种方式也映射到哈希环上，现在我们插入或者是查找一个键的时候，我们先通过计算获知在哈希环上的位置，然后 顺时针 查找到第一个分区。
现在我们尝试加入一个新的分区，判断带来的影响：
我们在 A B 之间新加入了一个分区 C，可以得到如下结论：
- 原来属于 B 的部分数据（A->C） 需要迁移到 C 中
- 其他位置的数据不受影响，不需要迁移
这大大降低了我们的开销，因为只需要迁移整体的部分数据，但是这个方法会存在 数据倾斜 的问题，谁占有的弧长越长就代表着我们的数据越有可能分配到该分区上。
哈希槽法
这个方法其实和 一致性哈希法 非常类似，每一个分区管理一个区间。但是它解决了数据倾斜的问题，当加入新的分区的时候，每个分区的大小都会得到相应的调整，保证平衡负载。
哈希槽共有 16384 个，每个节点负责一部分槽：
如上图，比如需要新加入一个分区，我们只需要每一个分区各自迁移约 1365 槽到新的分区中管理即可。既兼顾了数据迁移带来的开销，又兼顾了数据倾斜带来的问题。
2. 加入新的结点
现在需要在现有的集群当中加入一个新的结点，首先我需要一个介绍人，这个介绍人是现在集群当中的任意一个结点，之后通过 CLUSTER MEET 协议和这个中间人握手。握手成功之后，介绍人需要通告其他主机点我的存在。
可能这个集群中存在较多的主机点，如果介绍人挨个介绍我的话肯定成本非常大。所以使用了一个较为灵活的协议 Gossip(翻译过来是流言蜚语，还挺贴切的)，具体思想是每个节点定期与集群中的其他节点交换状态信息。当一个节点知道了某些新的信息（如集群中某个节点的故障信息，新的结点加入），它会将这些信息传播给它所连接的其他节点，这些节点再继续将信息传播给它们各自的邻居。这样，集群中所有节点最终都能知道每个节点的状态。
现在大家都知道新节点的存在了，但是新的结点具有以下特征：
- 由于没有分配哈希槽，因此它不保存任何数据
- 因为它是一个没有分配槽的主服务器，所以当副本想要成为主服务器时，它不会参与选举过程
所以我们需要手动的给新的哈希槽，也就是管理数据的权限：
CLUSTER SETSLOT [<node_id>]
三、总结
感觉现在查到的资料都没有很详细的介绍一个结点故障转移的过程，容我再看看。