Redis集群的两种实现方式之Redis Sharding和Redis Cluster

  在当前互联网的背景下，企业的业务需求越来越大，所以一般的业务+数据库已经不能满足需求了，所以大批的内存式数据库应运而生，Redis是一个应用比较广泛的数据库。用它来实现分布式的操作得心应手。目前有两种实现分布式的方式，基于Redisx2的Redis Sharding，还有基于Redisx3的Redis Cluster。

我阅读了一些大牛的文章，做了一些总结:

因为Redis Cluster是基于Redis Shadring的，所以先看一下Redis Sharding

 

    1：Redis Sharding

这是客户端sharding分片技术的体现，它是一主多备的实现方式。采用一致性Hash算法来实现数据的分片。采用普通的Hash算法来实现分片不是不行，但是当我们增加一个服务器或者一个服务器突然宕机的时候，我们便要在列表中增加一个编号或者删除一个编号，那么普通的在普通hash算法的情况下，按照h = Hash(key) % (N+1)重新计算哈希值，这种情况下系统中一旦有服务器变更，大量的key会被重定位到不同的服务器从而造成大量的缓存不命中。而这种情况在分布式系统中是非常糟糕的。所以我们采用一致性Hash算法，关于这个算法更详细的地方可以参考：

https://www.cnblogs.com/moonandstar08/p/5405991.html

即使采用一致性Hash算法，但是在服务器很少的情况下，有可能发生Hash倾斜的问题，这个时候就需要引入虚拟节点来解决问题，即比如当前只有两个节点A和B，在0~2^32-1中，会发生很多数据只是存在其中一个中(A或B)，这个时候，我们可以为每个服务器配置3个虚拟节点，于是可以分别计算 “Node A#1”、“Node A#2”、“Node A#3”、“Node B#1”、“Node B#2”、“Node B#3”的哈希值，于是形成六个虚拟节点：随后进行虚拟节点和实际节点的映射，这样就可以比较好的解决问题，详细可以参考下面博文：

https://blog.csdn.net/codertnt/article/details/80005005

那么Redis Sharding作为客户端分片，服务端还是一个个Redis实例节点，我们也不需要增加额外的中间组件，所以它是十分灵活的。但是相应的，它也要在一些方面做出妥协，比如集群扩容方面，当我们想要增加或者删除一个节点的时候，就需要进行键值迁移(尽管我们采用了一致性Hash算法，还是会发生key匹配不到的情况，所以就需要进行键值迁移)。

但是对于客户端进行键值迁移比较不现实，这就需要我们从后端，数据库去读数据，但是跨过缓存区访问数据库对系统会造成很 大的压力，所以它就采用一种取巧的方法，即一主多从的方式来实现。即一个主Master和多个从slave，即使这样，一个Redis节点有可能还是要承受很多访问，所以可以采用读写分离，即主master进行读操作，从slave进行写操作，因为一般读操作往往是写操作的很多倍。

关于主从备份的一些图片以及更多详细知识，可以参考下面链接

https://blog.csdn.net/upxiaofeng/article/details/51577727

    1：Redis Cluster

相较于单机版的Redis，Redis Cluster保证了CAP理论中的C(Consistency一致性)和A(Availability 可用性)，Redis Cluster的诞生是基于Redis Sharding的，因为对于Redis Sharding的数据迁移一直是比较麻烦的，它一方面要保证业务的可用性，一方面又要保证数据不会发生丢失，所以能够数据不迁移就不迁移，所以就诞生了Redis Cluster。