redis实战（七）

前言

上篇文章我们讲了redis单点到主从再到哨兵的整个进化过程，哨兵模式已经完美满足高可用性，那么他有什么不足呢？答案就是主节点始终只有一台，压力太大了，而且所有的数据都在一台机器上，无法扩容。当业务需求足够大的时候，我们的哨兵是扛不住的！

正文

那么如何解决呢？ 常见的方式有三种，我们逐一进行讲解！

客户端方式实现

客户端如何实现集群模式呢？我们已经知道了哨兵模式的缺点：单台master、无法扩容。那么只要针对这两点进行处理，我们就可以实现完美的集群模式。首先如何处理这个问题呢？  再搞几套哨兵方案，这样问题迎刃而解！那么就需要客户端去控制访问哪个哨兵了！也就是客户端方式实现集群，简单的说就是客户端进行分片。 

问题

客户端实现集群模式有什么缺点呢？第一：分片规则需要程序员介入，根据业务制定，耦合较大。 第二：无法动态扩容，想要增加redis哨兵模式的机器，需要修改分片逻辑。

代理模式实现

针对客户端实现集群的缺点，我们进行以下假想。如果分片逻辑不放在客户端，而是放在一个中间层（也就是我们说的代理层），客户端连接代理层，做到客户端无感知访问不同redis哨兵模式实例。这样既满足集群，又不需要客户端去实现复杂逻辑，Twitter开源了一个Twemproxy实现了这种方式。

问题

twemproxy可以让用户做到无感知使用（分片逻辑代理实现），但是由于加了一层代理（当然，代理层也是多实例），性能也相对有所影响！而且还是不能实现平滑扩容，扩容问题让人无比头疼，针对此场景，大佬们又搞了一套方案，大家应该很熟悉—codis。codis既完成了分片工作，扩容也进行了优化，下面带大家了解下。

补充

codis有着完整的运维方案，可用通过web页面去修改主从设置，不需要通过采用修改配置文件的方式，让运维变得简单了很多。 并且Codis采用预先分片（Pre-Sharding）机制，事先规定好了，分成1024个slots（也就是说，最多能支持后端1024个Codis Server），这些路由信息保存在ZooKeeper中。这样就可以支持动态扩容了。不止如此，codis在性能方面也是要比twemproxy好的多的，这里不做过多描述。

服务端方式实现

服务端方式实现集群（redis-cluster）如何实现我们说的哨兵的两个痛点呢？首先只有一个master的问题，那就多加几个master，让每个master互相监控，不同的数据通过服务器内部分到不同的master节点。我们发现如果这样做，貌似动态扩容的问题也随之解决了。那么具体要如何实现呢？

上图就是redis cluster的基本架构图，其中每个redis node 都是由1个master以及0个及以上个slave组成。节点之间采用去中心化方式，提供了完整的分片、复制、故障转移的解决方案。

redis的分片由内部自行处理，

结语

redis系列更新完毕，有时间会扩展一些redis使用的案例。以及Redisson分布式锁。敬请期待