redis集群模式

redis集群模式主要分为服务端集群和客户端分片及代理分片几种

客户端分片

这实际上是一种静态分片技术。Redis实例的增减，都得手工调整分片程序。基于此分片机制的开源产品，现在仍不多见。这种方式下，可运维性较差。出现故障，定位和解决都得研发和运维配合着解决，故障时间变长。

目前有的实现是Jedis的Redis Sharding，参考:https://blog.csdn.net/java20150326/article/details/70945732

优缺点

• 客户端sharding技术其优势在于服务端的Redis实例彼此独立，相互无关联，每个Redis实例像单服务器一样运行，非常容易线性扩展，系统的灵活性很强。
• 其不足之处在于由于sharding处理放到客户端，规模进步扩大时给运维带来挑战。服务端Redis实例群拓扑结构有变化时，每个客户端都需要更新调整。连接不能共享，当应用规模增大时，资源浪费制约优化。

基于服务端sharding

官方新推出的Redis Cluster。服务端sharding的Redis Cluster其优势在于服务端Redis集群拓扑结构变化时，客户端不需要感知，客户端像使用单Redis服务器一样使用Redis集群，运维管理也比较方便。正式版推出时间不长，系统稳定性、性能等都需要时间检验，尤其在大规模使用场合。

代理分片

twemproxy就是这样一种利用中间件做sharding的技术。twemproxy后端不仅支持redis，同时也支持memcached，这是twitter系统具体环境造成的。

优缺点:

• 由于使用了中间件，twemproxy可以通过共享与后端系统的连接，降低客户端直接连接后端服务器的连接数量。同时，它也提供sharding功能，支持后端服务器集群水平扩展。统一运维管理也带来了方便。
• twitter 在2015年就不再贡献Twemproxy代码，它最大的缺点是一个静态的Sharding 策略，随着业务的增长也几乎没有办法进行动态的扩缩容。Twemproxy更加像服务器端静态sharding。有时为了规避业务量突增导致的扩容需求，甚至被迫新开一个基于Twemproxy的Redis集群。
• 业务量突增，需增加Redis服务器；业务量萎缩，需要减少Redis服务器。但对Twemproxy而言，基本上都很难操作。
• Twemproxy另一个痛点是，运维不友好，甚至没有控制面板。

codis

Codis 是一个分布式 Redis 解决方案, 对于上层的应用来说, 连接到 Codis Proxy 和连接原生的 Redis Server 没有显著区别 (不支持的命令列表), 上层应用可以像使用单机的 Redis 一样使用, Codis 底层会处理请求的转发, 不停机的数据迁移等工作, 所有后边的一切事情, 对于前面的客户端来说是透明的, 可以简单的认为后边连接的是一个内存无限大的 Redis 服务。

codis官方地址：https://github.com/wandoulabs/codis

架构:

特点:

1. Codis引入了Group的概念，每个Group包括1个Redis Master及至少1个Redis Slave，这是和Twemproxy的区别之一。这样做的好处是，如果当前Master有问题，则运维人员可通过Dashboard“自助式”切换到Slave，而不需要小心翼翼地修改程序配置文件。
2. 为支持数据热迁移（Auto Rebalance），出品方修改了Redis Server源码，并称之为Codis Server。
3. Codis采用预先分片（Pre-Sharding）机制，事先规定好了，分成1024个slots（也就是说，最多能支持后端1024个Codis Server），这些路由信息保存在ZooKeeper中。
4. Codis仅负责维护当前Redis Server列表，由运维人员自己去保证主从数据的一致性。
5. 无缝迁移Twemproxy。
6. 兼容所有语言的客户端，支持Java程序的HA即Jodis。
7. 支持Pipeline。
8. 能支持GB到TB级别的水平扩展能力。
9. 也能提供Redis同样的高吞吐和低延迟的优势。
10. 更多数据结构的支持。

与Redis Cluster的比较

与Redis Cluster和Twemproxy的比较