分布式缓存--系列2 -- Redis Cluster

说到Memcached和Redis的区别，我想很多人都会想到下面3点：

但这都是从“单机角度“来比较。可以说，在redis cluster出来之前，memcached 和 redis 的差别还不算大。(关于Memcached为什么是多线程，而Redis为什么是单线程，这个在后续序列会来探讨）

但从Redis 3.0开始，引入了Redis Cluster，从此Redis进入了真正的“分布式集群“时代。而在“集群角度“，可以说Redis已经和Memcached有了很多重大的区别。下面这个表，从“集群角度“比较了2者的重大区别：

P2P架构

下面这张图展示了redis-cluster的结点之间的拓扑关系，可以看出它是完全的P2P模式，无中央结点，结点之间通过一个称之为Gossip的协议进行通信。

16384个hash槽

不同于Memcached的一致性Hash，Redis准备了16384个hash槽，类似于Memcached Hash环上的一个个位置。
这16384个hash槽被分配给不同节点，存放数据时，根据数据的key计算出所在的槽，再根据槽找到对应的机器。hash函数为：CRC16(key) % 16384。

为什么是16384？

很显然，我们需要维护节点和槽之间的映射关系，每个节点需要知道自己有哪些槽，并且需要在结点之间传递这个消息。

为了节省存储空间，每个节点用一个Bitmap来存放其对应的槽:
2k = 2*1024*8 = 16384，也就是说，每个结点用2k的内存空间，总共16384个比特位，就可以存储该结点对应了哪些槽。然后这2k的信息，通过Gossip协议，在结点之间传递。

客户端存储路由信息

对于客户端来说，维护了一个路由表：每个槽在哪台机器上。这样存储(key, value)时，根据key计算出槽，再根据槽找到机器。

无损扩容

虽然Hash环可以减少扩容时失效的key的数量，但毕竟有丢失。而在redis-cluster中，当新增机器之后，槽会在机器之间重新分配，同时被影响的数据会自动迁移，从而做到无损扩容。

主从复制

redis-cluster也引入了master-slave机制，从而提供了fail-over机制，这很大程度上解决了“缓存雪崩“的问题。关于这个，后面有机会再详细阐述。