redis-cluster

1.1 设计原则和初衷

• 在官方文档Cluster Spec中，作者详细介绍了Redis集群为什么要设计成现在的样子。最核心的目标有三个：
  
  • 性能：这是Redis赖以生存的看家本领，增加集群功能后当然不能对性能产生太大影响，所以Redis采取了P2P而非Proxy方式、异步复制、客户端重定向等设计，而牺牲了部分的一致性、使用性。
  • 水平扩展：集群的最重要能力当然是扩展，文档中称可以线性扩展到1000结点。
  • 可用性：在Cluster推出之前，可用性要靠Sentinel保证。有了集群之后也自动具有了Sentinel的监控和自动Failover能力。

1.2 架构变化与CAP理论

• Redis Cluster集群功能推出已经有一段时间了。在单机版的Redis中，每个Master之间是没有任何通信的，所以我们一般在Jedis客户端或者Codis这样的代理中做Pre-sharding。按照CAP理论来说，单机版的Redis属于保证CP(Consistency & Partition-Tolerancy)而牺牲A(Availability)，也就说Redis能够保证所有用户看到相同的数据（一致性，因为Redis不自动冗余数据）和网络通信出问题时，暂时隔离开的子系统能继续运行（分区容忍性，因为Master之间没有直接关系，不需要通信），但是不保证某些结点故障时，所有请求都能被响应（可用性，某个Master结点挂了的话，那么它上面分片的数据就无法访问了）。
  有了Cluster功能后，Redis从一个单纯的NoSQL内存数据库变成了分布式NoSQL数据库，CAP模型也从CP变成了AP。也就是说，通过自动分片和冗余数据，Redis具有了真正的分布式能力，某个结点挂了的话，因为数据在其他结点上有备份，所以其他结点顶上来就可以继续提供服务，保证了Availability。然而，也正因为这一点，Redis无法保证曾经的强一致性了。这也是CAP理论要求的，三者只能取其二。
  关于CAP理论的通俗讲解，请参考我的译文《可能是CAP理论的最好解释 》。简单分析了Redis在架构上的变化后，咱们就一起来体验一下Redis Cluster功能吧！

1.3 端口监听

• 每个在cluster中的redis节点都会监听两个端口，一个是和客户端通讯的TCP端口(6379)，一个是用作cluster内部数据传输的，比如错误检测、cluster配置更新、故障转移等等(16379)。这样cluster的通讯问题就解决了，但数据是怎么在cluster中存放的？redis cluster没有采用一致性哈希，而是采用hash slot。一个redis cluster有固定的16384个hash slot，这么多slot被均匀的分配到cluster中的master节点上，而一个key具体的存储在哪个slot上，则是通过key的CRC16编码对16384取模得出的。上面提到了cluster中的master节点，估计很多人就迷糊了，为了当部分节点失效时，cluster仍能保持可用，Redis 集群采用每个节点拥有 1（主服务自身）到 N 个副本（N-1 个附加的从服务器）的主从模型。是不是和master/slave很像。但是redis cluster却不是强一致性的，在一定的条件下，cluster可能会丢失一些写入的请求命令，因为cluster内部master和slave之间的数据是异步复制的，比如你给master中写入数据，返回ok，但是这时候该数据并不一定就完全的同步到slave上了(采用异步主要是提高性能，主要是在性能和一致性间的一个平衡)，如果这时候master宕机了，这部分没有写入slave的数据就丢失了，不过这种可能性还是很小的。上面这些信息都来自官方解释，只是大概的描述了redis cluster的一些基本信息。

• Redis Cluster

• redis-cluster和redis是一个东西么
• Redis Cluster 迁移遇到的各种坑及解决方案