redis cluster
每个集群的槽数是固定的 16384（16 * 1024）个，每个 Key 落在哪个槽中也是固定的，计算方法：
HASH_SLOT = CRC16(key) mod 16384
分槽方法：查表法。
客户端可以连接集群的任意一个节点来访问集群的数据，当客户端请求一个 Key 的时候，被请求的那个 Redis 实例先通过上面的公式，计算出这个 Key 在哪个槽中，然后再查询槽和节点的映射关系，找到数据所在的真正节点，如果这个节点正好是自己，那就直接执行命令返回结果。如果数据不在当前这个节点上，那就给客户端返回一个重定向的命令，告诉客户端，应该去连哪个节点上请求这个 Key 的数据。然后客户端会再连接正确的节点来访问。
高可用：每个分片添加从节点，当主节点故障，其他节点会在这个分片的从节点中选出一个新节点作为主节点。
高并发：默认情况下，集群的读写请求都是由主节点负责的，从节点只是起一个热备的作用。当然了，Redis Cluster 也支持读写分离，在从节点上读取数据。
Redis Cluster 不适合超大规模集群
Redis Cluster 是非常适合构建中小规模 Redis 集群，这里的中小规模指的是，大概几个到几十个节点这样规模的 Redis 集群。
Redis Cluster 采用了一种去中心化的流言 (Gossip) 协议来传播集群配置的变化。在集群规模太大的情况下，数据不同步的问题会被明显放大，还有一定的不确定性，如果出现问题很难排查。
构建大规模集群方法
- 基于代理。客户端和redis节点之间增加一层代理，主要作用：
-
负责在客户端和 Redis 节点之间转发请求和响应。
-
负责监控集群中所有 Redis 节点状态，如果发现有问题节点，及时进行主从切换。
-
维护集群的元数据，这个元数据主要就是集群所有节点的主从信息，以及槽和节点关系映射表。
-
开源方案：twemproxy和Codis
优点：客户端透明，整个集群和一个超大容量的单节点 Redis 是一样的。 缺点：访问链路加长，有性能损耗
- 客户端查询元数据服务寻址，然后直连redis节点。
元数据服务可以用 ZooKeeper、etcd、Mysql。 优点：在性能、弹性、高可用几方面表现都非常好 缺点：架构复杂，客户端不通用，定制化成本高
此文章为3月Day16学习笔记，内容来源于极客时间《后端存储实战课》
