22年22篇 redis高可用之集群
在整个架构的每个节点中，不允许存在单点问题，因为单点一定是高可用最大的风险点，我们应该在系统设计过程中去避免单点问题。
在实现方法上，一般采用的就是集群部署、或者冗余部署来实现。这样的设计使得如果某个节点出现故障，其他的节点还可以继续使用。
Redis中高可用设计的必要性
Redis作为一个高性能Nosq中间件，会有很多热点数据存放在Redis中，一旦Redis-server出现故障，会导致所有相关业务访问都出现问题。另外，即便是设计了数据库兜底的方案，大量请求对数据库的访问也很容易导致数据库出现瓶颈，造成更大的灾难。
除此之外，Redis的集群部署还可以带来额外的收益：
负载（性能），Redis本身的QPS已经很高了，但是如果在一些并发量非常高的情况下，性能还是会受到影响。这个时候我们希望有更多的Redis服务来完成工作
扩容（水平扩展），第二个是出于存储的考虑。因为Redis所有的数据都放在内存中，如果数据量大，很容易受到硬件的限制。升级硬件收效和成本比太低，所以我们需要有一种横向扩展的方法
在Redis中，提供了高可用方案包含以下几种：
主从复制（用来实现读写分离）
哨兵机制（实现master选举）
集群机制（实现数据的分片）
Redis的Master-Slave方法
主从复制模式，简单来说就是把一台Redis服务器的数据，复制到其他Redis服务器中。其中负责复制数据的来源称为master，被动接收数据并同步的节点称为slave，数据的复制是单向的，如图5-1所示，对于主从模式，其实有很多的变体。
在很多组件中都有使用这种思想，比如mysql的主从复制、redis的主从复制、activemq的主从复制、kafka里面的数据副本机制等等，所以大家需要举一反三，融会贯通。
主从复制的好处
数据冗余，主从复制实现了数据的热备，是除了持久化机制之外的另外一种数据冗余方式。
读写分离，使数据库能支撑更大的并发。在报表中尤其重要。由于部分报表sql语句非常的慢，导致锁表，影响前台服务。如果前台使用master，报表使用slave，那么报表sql将不会造成前台锁，保证了前台速度。
负载均衡，在主从复制的基础上，配合读写分离机制，可以由主节点提供写服务，从节点提供服务。在读多写少的场景中，可以增加从节点来分担redis-server读操作的负载能力，从而大大提高redis-server的并发量
保证高可用，作为后备数据库，如果主节点出现故障后，可以切换到从节点继续工作，保证redis-server的高可用。
Master自动选举之Sentinel哨兵机制
在前面讲的master/slave模式，在一个典型的一主多从的系统中，slave在整个体系中起到了数据冗余备份和读写分离的作用。当master遇到异常终端后，开发者可以通过手动方式选择一个slave数据库来升级到master，使得系统能够继续提供服务。然后这个过程需要人工干预，比较麻烦；redis并没有提供自动master选举功能，而是需要借助一个哨兵来进行监控。
什么是哨兵
顾名思义，哨兵的作用就是监控Redis系统的运行状况，它的功能包括两个
监控master和slave是否正常运行
master出现故障时自动将slave数据库升级为master
哨兵是一个独立的进程，使用哨兵后的架构如图5-3所示，同时为了保证哨兵的高可用，我们会对Sentinel做集群部署，因此Sentinel不仅仅监控Redis所有的主从节点，Sentinel也会实现相互监控。
Redis Cluster架构
一个Redis Cluster由多个Redis节点构成，不同节点组服务的数据没有交集，也就是每个一节点组对应数据sharding的一个分片。
节点组内部分为主备两类节点，对应master和slave节点。两者数据准实时一致，通过异步化订的主备复制机制来保证。
一个节点组有且只有一个master节点，同时可以有0到多个slave节点，在这个节点组中只有master节点对用户提供些服务，读服务可以由master或者slave提供。如图5-4中，包含三个master节点以及三个master对应的slave节点，一般一组集群至少要6个节点才能保证完整的高可用。
其中三个master会分配不同的slot（表示数据分片区间），当master出现故障时，slave会自动选举成为master顶替主节点继续提供服务。