简单聊聊实现redis分布式的两种方式--ShardedJedis和redis cluster

首先要说下哈：这篇文章是由自己的理解整理而成，由于自己的理解有限，难免会有疏忽之处，若有不对的地方，还望大神指点一二。

若要实现redis分布式，在我看来，有常用的两种方式：a. 使用ShardedJedis--客户端分片；b. 使用redis cluster--服务端分片。下面简单说下，这两种实现方式的优缺点：

1. 使用ShardedJedis：
2. 使用redis cluster：

	ShardedJedis	redis cluster
分片方式	客户端分片	服务器端使用分片
使用的协议	哈希一致性协议，解决节点倾斜的方式：每个实体结点引入160个虚拟节点	槽
扩容与收缩对客户端的影响	需要在客户端增加或减少redis节点的配置信息，然后重启涉及到的服务器	对客户端透明
每个主节点都有一个对应的从节点，当主节点宕机后，对客户端的影响	在服务端，需要手动将宕机的主节点移除，将对应的从节点升级为主节点，然后为新的主节点配置一个从节点； 在客户端，更新新的主节点的地址，然后重启涉及到的服务器；	对客户端透明，redis cluster会把宕机的主节点的从节点升级为主节点，这个新的主节点继续对外服务；
如何扩容	redis的作者提出了一种叫做预分片-presharding的方案来解决动态扩容的问题。即在业务刚开始开展时，我们能够预估在未来一段时间内，业务量有多大，根据这个评估值，我们可以在一台或多台物理服务器上部署多个redis实例；当业务量大到一定程度了，现有的redis集群不能满足需要时，我们可以其中一个redis实例迁移到另一台物理服务器上，以达到动态扩容的效果；例如：根据项目的规模，我们需要用到3个redis实例（都是主节点--能读能写，每个主节点配一个从节点--不能读写，只做备份用，即当主节点不能读写时，从节点顶上去），我们申请3台物理服务器，在每一个物理服务器上都部署2个redis实例（一主一从，交叉部署），那么此时就有6个redis实例；当这3台物理服务器上的内存不满足需要或redis的读写速度变慢时，需要扩容：这时候的做法是：再申请一台物理服务器，把现有的3个redis实例（主节点）中的1个迁移到新的物理服务器上，虽然redis的实例的个数没变，但增加了一台新的物理服务器，意味着增加了很多的内存和CPU； 具体的拆分过程如下： a. 在新的物理服务器上新建一个redis实例； b. 将新的redis实例配置成要迁移的redis实例的从节点，其目的是要复制数据； c. 当这两个实例的数据同步后，将所有客户端中对要迁移的redis实例的配置信息改成新的redis的信息； d. 将新的redis实例改为主节点，再为这个主节点配置一个从节点，以防该主节点宕机后，从节点能够顶上； 注：缺点是： a. 由于更改了redis的配置信息，要么重新部署服务器，要么通过热部署来完成更改；无论哪种方式，都会造成服务器暂时不能访问； b. 该拆分方法还是依赖redis本身的复制功能，如果主节点中的数据量过大，这个复制过程可能会很久，同时会给主库带来压力；	首先，启动一个新的redis； 然后，将该redis加入集群； 最后，把现有redis中的一部分槽和对应的数据迁移到新的redis中；
如何收缩	首先，把将要删除的redis中的数据加载到其他的redis中，不至于在该redis被删除后，出现大部分缓存不命中的问题；然后， 在客户端配置文件中删除该reidis的地址信息；最后，重启涉及到的服务器；	首先，把将要下线的redis中的槽和对应的数据迁移到其他的redis中； 然后，将该redis的信息从集群中去除；

 

待续......