先介绍几个概念知识，为整体架构作铺垫
Codis
分布式服务框架
Twemproxy
代理服务器
首先，最简单的Redis应用称为单点模式：即只有一台Redis服务器与客户端直连。
当QPS不断增加，单点Redis不足以支撑业务的时候，就是最应该优化的时候，毕竟业务驱动技术改进，脱离业务的技术改造都是耍流氓，这话出自业内某位大神，但是真不是鲁迅先生，哈哈。
此时，我们想到的是加一台服务器作为从库，实现读写分离。
但是如果业务场景出现频繁读数据或频繁写数据，那么此时和单点模式基本相同，此时我们有两种方式可以优化系统：
- 我们可以充分利用两台服务器实现双写双读模式，此时需要开发进行大量的编码工作，以保障双写双读的可靠性。
- 如果想对服务器内存有更大的需求，可以考虑分片，具体实现何种分片还要具体问题具体分析。
对于上面的方案，我们基本完成了一次系统优化迭代。优势显而易见：代码独立，不依赖于第三方中间件等，但是更明显的应该是缺点：
- 系统整体升级困难
- 扩缩容非常复杂
- 突发性故障屏蔽转移需要很大的人力成本
坦白的说，只要你稍微思考的远一些，站的角度高一些，你会发现上面的系统是最初级的，有很大的优化空间，而且现在的技术发展可以很好的解决以上问题，那就是代理模式。
Redis代理方案
说到代理中间件，就用到了一开始简单的介绍的Codis和Twemproxy。 但是代理也不是完美无缺，比如多多少少会影响一些性能，需要购买多余的机器等问题。
Redis Cluster
这是Redis.io官方推荐的高可用Redis集群解决方案，采用去中心化思想，这点估计是借鉴了区块链技术中的无中心化思想吧（在下YY的，忽略），方便管理增删服务节点，很重要的一点是文档丰富、生态良好~
