【Redis】集群方案

主从

提高读请求相应，无自动切换机制。

哨兵模式：

sentinel, 哨兵是redis集群中非常重要的一个组件，主要有一下功能：

集群监控：负责监控redis master和slave进程是否正常工作。
消息通知：如果某个redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员。
故障转移：如果master node挂掉了，会自动转移到slave node上。
配置中心：如果故障转移发生了，通知client客户端新的master地址。

哨兵用于实现redis集群的高可用，本身也是分布式的，作为一个哨兵集群去运行，互相协同工作。

故障转移时，判断一个master node是否宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举
即使部分哨兵节点挂掉了，哨兵集群还能正常工作的
哨兵通常需要3个实例，来保证自己的健壮性。
哨兵 + redis主从的部署架构，是不保证数据零丢失的，只能保证redis集群的高可用性。
对于哨兵 + redis主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练。

Redis Cluster 集群

Redis Cluster是一种服务端Sharding技术，3.0版本开始正式提供。采用slot(槽)的概念，一共分成16384个槽。将请求发送到任意节点。接收到请求的节点会将查询请求发送到正确的节点上执行。

方案说明

通过哈希的方式，将数据分片，每个节点均分布存储一定哈希槽（哈希值）区间的数据，默认分配了16384个槽位
每份数据分片会存储在多个互为主从的多节点上
数据写如先写主节点，再同步到从节点（支持配置为阻塞同步）
同一分片多个节点间的数据不保持强一致性
读取数据时，当客户端操作的key没有分配再给节点上时，redis会返回指令，指向正确的节点
扩容时需要把旧节点的数据迁移一部分到新节点

在redis cluster架构下，每个redis要放开两个端口号，比如一个时6379，另外一个就是加1W的端口号，比如16379.
16379端口号是用来进行节点间通信的，也就是cluster bus的通信，用来进行故障检测，配置更新，故障转移授权。cluster bus用了另外一种二进制的协议，gossip协议，用于节点间进行高效的数据交换，占用更少的网络带宽和处理时间。

优点

无中心结构，支持动态扩容，对业务透明
具备Sentine的监控和自动Failover(故障转移)能力
客户端不需要连接集群所有节点，连接集群中任何一个可用节点即可
高性能，客户端直连redis服务，免去了proxy代理的损耗
缺点
运维也很复杂，数据迁移需要人工干预
只能使用0号数据库
不支持批量操作(pipeline管道操作)
分布式逻辑和存储模块耦合等

Redis Shareding 客户端分片

Redis Shareding是Redis Cluster出来之前，业界普遍使用的多Redis实例集群方法。其主要思想是采用哈希算发将Redis数据的key进行散列，通过hash函数，特定的key会映射到特定的Redis节点上。Java redis客户端驱动jedis,支持Redis Sharding功能，即ShardedJedis以及结合缓存池的ShardedJedisPool
优点
优势在于非常简单，服务端的Redis实例彼此独立，相互无关联，每个Redis实例像单服务器一样运行，非常容易线性扩展，系统的灵活性很强
缺点
由于sharding处理放到客户端，规模进一步扩大时给运维带来挑战。
客户端sharding不支持动态增删节点。服务端Redis实例群拓扑结构有变化时，每个客户端都需要更新调整。连接不能共享，当应用规模增大时，资源浪费制约优化。