Redis架构设计
- 目前流行的四种模式
- 一、一致性Hash
- 二、Redis哨兵模式
- 三、Codis
- 四、Redis_cluster
- 五、Codis集群和Redis_cluster的优劣对比
目前流行的四种模式
读者们，你们好！目前流行的Redis架构主要有四种，分别为：一致性Hash、Redis哨兵模式、Codis、Redis_cluster。
一、一致性Hash
普通的Hash算法：对应于不同的数据，会精确的哈希到对应的Redis服务器上，但是一旦某台redis服务器宕机，所有的索引都将失效，需要重新全部Hash一遍。
一致性Hash算法：简单说Hash算法是将对应的key哈希到一个具有232次方个桶的空间中，即0~(232)-1的数字空间中。现在我们可以将这些数字头尾相连，想象成一个闭合的环形。将多台redis服务器或者实例映射到环中，将对象的key进行hash后按照顺时针方向存储到离自己最近的机器中。【对于服务器的增减，key的存储位置发生了变化，但是数据不会全乱。】另外为了平衡性追加对应的虚节点。
优点：
1、解决了普通hash算法遇到服务器宕机后所有数据重新哈希的问题
2、增加虚节点可以提高一定的平衡性
缺点：
1、客户端代码复杂（需要运用一致性hash算法、动态增减节点算法、节点监控算法等等）
2、增减节点会导致一部分缓存不可用
总结：在系统设计中，一般不会考虑该方案。
参考博客：
【http://blog.csdn.net/u014490157/article/details/52244378】
【http://blog.csdn.net/cywosp/article/details/23397179】
二、Redis哨兵模式
单个哨兵：
多个哨兵：
主要功能如下：
1、不时地监控redis是否按照预期良好地运行;
2、如果发现某个redis节点运行出现状况，能够通知另外一个进程(例如它的客户端);
3、能够进行自动切换。当一个master节点不可用时，能够选举出master的多个slave(如果有超过一个slave的话)中的一个来作为新的master,其它的slave节点会将它所追随的master的地址改为被提升为master的slave的新地址。
4、哨兵为客户端提供服务发现，客户端链接哨兵，哨兵提供当前master的地址然后提供服务，如果出现切换，也就是master挂了，哨兵会提供客户端一个新地址。
优点：
1、可监控redis是否正常运行
2、出现状况时，会发出通知
3、自动切换
缺点：
1、需要多个哨兵【防止单个哨兵宕机】
2、单机只支持垂直扩展
总结：数据量未来可估计，结构简单，运维难度低，可根据业务选择使用。
参考博客：
【http://www.cnblogs.com/kerwinC/p/6069864.html】
【http://blog.csdn.net/a67474506/article/details/50435498】
三、Codis
codis-proxy 提供连接集群redis服务的入口
codis-redis-group 实现redis读写的水平扩展，高性能
codis-redis 实现redis实例服务，通过codis-ha实现服务的高可用
zookeeper 配置管理，名字服务，提供分布式同步以及集群管理
Codis 是一个分布式 Redis 解决方案, 对于上层的应用来说, 连接到 Codis Proxy 和连接原生的 Redis Server 没有明显的区别 (有一些命令不支持), 上层应用可以像使用单机的 Redis 一样使用, Codis 底层会处理请求的转发, 不停机的数据迁移等工作, 所有后边的一切事情, 对于前面的客户端来说是透明的, 可以简单的认为后边连接的是一个内存无限大的 Redis 服务。
优点：
1、支持水平扩展和垂直扩展
2、可以实现监控
3、数据的分布式存储（pre-sharding）
4、每个group的主从选举机制。（集成了redis-sentinel）
缺点：结构复杂，运维难度大
总结：数据量未来不可估计，且redis仅仅用于缓存的情况下，建议使用。
参考博客：
【http://www.cnblogs.com/xuanzhi201111/p/4425194.html】
【http://www.cnblogs.com/cjing2011/p/9bafc11fc32e37d2ba29a8758f4b16ff.html】
【zookeeper】【http://www.cnblogs.com/yuyijq/p/3424473.html】
四、Redis_cluster
redis_cluster是一种分布式Redis集群策略，具有一定的容错性和线性可扩展性。
Redis_cluster功能特性：
1、高可用性与可线性扩张到1000个节点
2、数据自动路由到多个节点
3、 节点间数据共享
4、可动态添加或者删除节点
5、部分节点不可达时，集群仍可用
6、数据通过异步复制,不保证数据的强一致性
7、可动态调整数据分布
优点：
1、分片实现扩容
2、节点高可用
3、节点之间可以通信
4、不需要proxy层
5、容错性好
缺点：
1、客户端要求比较高，很多语言的客户端不能很好的支持Cluster。
2、Hash Solt这种方式消耗计算资源，客户端压力大
总结：数据量未来不可估计，除了缓存外还希望利用到redis的消息队列等功能，建议使用。
参考博客：
【http://blog.chinaunix.net/uid-28396214-id-4981572.html】
【http://hot66hot.iteye.com/blog/2050676】
五、Codis集群和Redis_cluster的优劣对比
1、codis架构如下：
（1）Codis是一整套缓存解决方案，包含高可用、数据分片、监控、动态扩态 etc.。走的是 Apps->代理->redis cluster，一定规模后基本都采用这种方式。
（2）Codis引入了Group的概念，每个Group包括1个Redis Master及至少1个Redis Slave，这是和Twemproxy的区别之一。这样做的好处是，如果当前Master有问题，则运维人员可通过Dashboard“自助式”切换到Slave，而不需要小心翼翼地修改程序配置文件。
为支持数据热迁移（Auto Rebalance），出品方修改了Redis Server源码，并称之为Codis Server。
Codis采用预先分片（Pre-Sharding）机制，事先规定好了，分成1024个slots（也就是说，最多能支持后端1024个Codis Server），这些路由信息保存在ZooKeeper中。
（3）Codis仅负责维护当前Redis Server列表，由运维人员自己去保证主从数据的一致性。
2、redis cluster集群架构如下：
（1）Redis Cluster将所有Key映射到16384个Slot中，集群中每个Redis实例负责一部分，业务程序通过集成的Redis Cluster客户端进行操作。客户端可以向任一实例发出请求，如果所需数据不在该实例中，则该实例引导客户端自动去对应实例读写数据。
Redis Cluster的成员管理（节点名称、IP、端口、状态、角色）等，都通过节点之间两两通讯，定期交换并更新。
参考博客：
【http://www.cnblogs.com/cjing2011/p/9bafc11fc32e37d2ba29a8758f4b16ff.html】
谢谢客官打赏！您的支持是我前进最大的动力~
