【单机版】
缺点:单机故障、容量瓶颈、qps瓶颈
【主从】
读写分离、容灾备份,
缺点:主机挂了之后是没有办法完成自从主从切换的
【哨兵】
哨兵是在主从的基础上升级的,先搭建主从,再搭建哨兵。哨兵节点监控主机,如果主机挂掉了,那么从从机上选出一个从机替换主机。
sentinel,哨兵是redis集群中非常重要的一个组件,主要功能:(1)集群监控:负责监控redis master和slave进程是否正常工作;(2)消息通知:如果某个redis实例有故障,那么哨兵负责发送消息作为警报发给管理员;(3)故障转移:如果master Node宕机了,会自动转移到slave node节点;(4)配置中心:如果故障发生转移了,通知client客户端新的master
哨兵用于实现redistribution集群的高可用,本身也是分布式的,作为一个哨兵集群去运行,相互协同工作。故障转移时,判断一个master node是否宕机了,需要大部分的哨兵都同意才行(大多数原则)。即使部分哨兵节点挂掉了,哨兵集群还能正常工作的。哨兵通常需要3个实例来保证自己的健壮性。哨兵+redis主从架构是不保证数据零丢失的,只能保证redis集群的高可用。对于哨兵+redis这种复杂的部署架构,尽量在测试环境和生产环境都进行充足的测试和演练。
【redis sharding】
redis cluster出现之前,业界普遍使用的多redis实例集群方式,其主要思想就是采用hash算法将redis数据的key进行散列,通过hash函数,特定的key会映射到特定的redis节点。Java的redis客户端驱动jedis,支持redis sharding功能,即sharding jedis以及结合缓存池的shardingJedisPool,服务端控制则采用sharding proxy
优点:非常简单,服务端的redis实例彼此独立,但无相关关联,每个redis实例像单服务器一样运行,非常容易线性扩展,系统的灵活性很强
缺点:sharding处理放到客户端,操作由客户端控制,服务另起sharding proxy,运维难度加大。客户端的sharding不支持动态增删节点,服务端的redis实例群拓扑结构有变化时,每个客户端都需要更新调整,链接不能共享,应用规模增大时,浪费资源限制优化
【cluster】
在哨兵的基础上升级的,类似于哨兵模式。但是是一个类似哨兵的模式,通过hash算法给出每个是选择哪个服务。每个主从类 哨兵模块之间的数据不是共享的,相互之间没关系。
redis cluster是一种服务端的sharding技术,3.0版本正式提供,采用slot的概念,一共分成16384个槽。将请求发送到任意节点,接收到请求的节点将会查询请求发送到正确的节点进行。
相关方案: 通过哈希的方式,将数据分片,每个节点均分存储一定的hash区间的数据(默认分配了16384个槽位)。 每份数据分片会存储在多个互为主从的多个节点上。 数据写入先写主节点,再从主节点复制到对应的从节点(支持配置为阻塞同步)。 同一分片多个节点之间数据不保持强一致性。 读取数据时,当客户端操作的key没有分配在该节点时,redis会转回反向指令。指向正确的节点。 扩容时需要把旧节点的数据迁移一部分到新节点。
在redis cluster架构下,每个redis要开放两个端口,比如一个是6379,另外一个就是+10000的端口:16379,其中16379是为了进行节点之间的通讯的,也就是cluster bus的通讯,用来进行故障检测,配置更新,故障转移授权的。cluster bus用了另外一种二进制协议,gossip协议,用于节点之间进行高效的数据交换,占用更少的处理时间和网络带宽。
优点:无中心架构,支持动态扩容,对业务透明。具备sentinel的监控和自动failover能力。客户端不需要连接集群所有节点,链接集群中的任意一个节点即可。高性能,客户端直接连接redis服务,免去了proxy代理的损耗。
缺点:运维发杂,数据迁移需要人共干预。只能使用0号数据库。不支持批量操作(pipline操作)。分布式逻辑和存储模块耦合。