高并发架构与分布式技术NoSQL -- Redis主从模式

首先奉献出微信 java后端技术 公众号里的学习脑图，接下来的内容将会按照该图进行自学梳理。

redis主从模式

配置过程参见 https://blog.csdn.net/a67474506/article/details/50435206

主从复制(读写分离)

Redis的主从复制功能非常强大，一个master可以拥有多个slave,而一个slave又可以拥有多个slave,如此下去,形成了强大的多级服务器集群架构.可以避免Redis单点故障,构建读写分离架构,满足读多写少的应用场景.

Redis复制功能的几个重要方面


1. 一个Master可以有多个Slave；
2. Redis使用异步复制。从2.8开始，Slave会周期性（每秒一次）发起一个Ack确认复制流（replication stream）被处理进度；
3. 不仅主服务器可以有从服务器，从服务器也可以有自己的从服务器，多个从服务器之间可以构成一个图状结构；
4. 复制在Master端是非阻塞模式的，这意味着即便是多个Slave执行首次同步时，Master依然可以提供查询服务；
5. 复制在Slave端也是非阻塞模式的：如果你在redis.conf做了设置，Slave在执行首次同步的时候仍可以使用旧数据集提供查询；你也可以配置为当Master与Slave失去联系时，让Slave返回客户端一个错误提示；
6. 当Slave要删掉旧的数据集，并重新加载新版数据时，Slave会阻塞连接请求（一般发生在与Master断开重连后的恢复阶段）；
7. 复制功能可以单纯地用于数据冗余（dataredundancy），也可以通过让多个从服务器处理只读命令请求来提升扩展性（scalability）：比如说，繁重的 SORT 命令可以交给附属节点去运行。
8. 可以通过修改Master端的redis.config来避免在Master端执行持久化操作（Save），由Slave端来执行持久化。

数据同步的过程
①  当从库和主库建立MS关系后，会向主数据库发送SYNC命令(同步命令);
②  主库接收到SYNC命令后会开始在后台保存快照（RDB持久化过程），并将期间接收到的写命令缓存起来;所以就算关掉了RDB持久化方式,在他们同步的时候也会产生RDB
以上主库只做了2件事情
           将接收的命令进行RDB持久化
           在RDB持久化中,将接收的命令缓存起来
①  当快照完成后，主Redis会将快照文件和所有缓存的写命令发送给从Redis;
②  从Redis接收到后，会载入快照文件并且执行收到的缓存的命令;
③  之后，主Redis每当接收到写命令时就会将命令发送从Redis，从而保证数据的一致;
在这个过程中主从同步是通过RDB来同步数据, 即使禁用了RDB也没有用,那么就会产生IO问题,在这个复制过程可能就会出现瓶颈. Redis在2.8.18版本开始实现了无磁盘复制功能
Redis在与从库进行复制初始化时将不会吧快照储存到磁盘,而是直接通过网络发送给从库,避免了IO性能问题.

宕机处理

在主从架构中出现了宕机的情况
①  Slave 宕机
在Redis中,从库重新启动会自动加入到主从架构中,自动完成同步数据
Redis 2.8之后,在从库有做持久化的前提下,如果从库在断开的期间,主库的变化不大,从库再次启动后,主库不会将或有的数据进行RDB操作,而是进行增量复制
②  Master 宕机
一 : 在Slave中执行SLAVEOF NO ONE 命令,断开主从关系并且提升为主库继续服务;
二 : 将主库重新启动后,执行 SLAVEOF命令,将其设置为其他Redis的从库,这个时候数据就同步回来了;

这样通过人工的方式来处理Redis的宕机情况步骤虽然少,但是还是容易出现异常的,下面我们通过Redis的哨兵(sentinel)功能来实现高可用的架构

以下内容转自：https://blog.csdn.net/a67474506/article/details/50435498

Redis的哨兵(sentinel) 系统用于管理多个 Redis 服务器,该系统执行以下三个任务:
          监控(Monitoring): 哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常。
         提醒(Notification):当被监控的某个 Redis出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。

         自动故障迁移(Automatic failover):当一个Master不能正常工作时，哨兵(sentinel) 会开始一次自动故障迁移操作,它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master; 当客户端试图连接失效的Master时,集群也会向客户端返回新Master的地址,使得集群可以使用Master代替失效Master。

哨兵(sentinel) 是一个分布式系统,你可以在一个架构中运行多个哨兵(sentinel) 进程,这些进程使用流言协议(gossipprotocols)来接收关于Master是否下线的信息,并使用投票协议(agreement protocols)来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master.
每个哨兵(sentinel) 会向其它哨兵(sentinel)、master、slave定时发送消息,以确认对方是否”活”着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂(所谓的”主观认为宕机” Subjective Down,简称sdown).
若“哨兵群”中的多数sentinel,都报告某一master没响应,系统才认为该master"彻底死亡"(即:客观上的真正down机,Objective Down,简称odown),通过一定的vote算法,从剩下的slave节点中,选一台提升为master,然后自动修改相关配置.
虽然哨兵(sentinel) 释出为一个单独的可执行文件 redis-sentinel ,但实际上它只是一个运行在特殊模式下的 Redis 服务器，你可以在启动一个普通 Redis 服务器时通过给定 --sentinel 选项来启动哨兵(sentinel).

REDIS集群实现方案

1.客户端分片

　　客户端分片是把分片的逻辑放在Redis客户端实现，通过Redis客户端预先定义好的路由规则，把对Key的访问转发到不同的Redis实例中，最后把返回结果汇集。这种方案的模式如图1所示。

客户端分片的好处是所有的逻辑都是可控的，不依赖于第三方分布式中间件。开发人员清楚怎么实现分片、路由的规则，不用担心踩坑。

　　客户端分片方案有下面这些缺点。

• 这是一种静态的分片方案，需要增加或者减少Redis实例的数量，需要手工调整分片的程序。

• 可运维性差，集群的数据出了任何问题都需要运维人员和开发人员一起合作，减缓了解决问题的速度，增加了跨部门沟通的成本。

• 在不同的客户端程序中，维护相同的分片逻辑成本巨大。例如，系统中有两套业务系统共用一套Redis集群，一套业务系统用Java实现，另一套业务系统用PHP实现。为了保证分片逻辑的一致性，在Java客户端中实现的分片逻辑也需要在PHP客户端实现一次。相同的逻辑在不同的系统中分别实现，这种设计本来就非常糟糕，而且需要耗费巨大的开发成本保证两套业务系统分片逻辑的一致性。

• 
  

2.Twemproxy

Twemproxy是由Twitter开源的Redis代理，其基本原理是：Redis客户端把请求发送到Twemproxy，Twemproxy根据路由规则发送到正确的Redis实例，最后Twemproxy把结果汇集返回给客户端。

　　Twemproxy通过引入一个代理层，将多个Redis实例进行统一管理，使Redis客户端只需要在Twemproxy上进行操作，而不需要关心后面有多少个Redis实例，从而实现了Redis集群。

　　Twemproxy集群架构如图2所示。

　　

图2Twemproxy集群架构

　　Twemproxy的优点如下。

• 客户端像连接Redis实例一样连接Twemproxy，不需要改任何的代码逻辑。

• 支持无效Redis实例的自动删除。

• Twemproxy与Redis实例保持连接，减少了客户端与Redis实例的连接数。

　　Twemproxy有如下不足。

• 由于Redis客户端的每个请求都经过Twemproxy代理才能到达Redis服务器，这个过程中会产生性能损失。

• 没有友好的监控管理后台界面，不利于运维监控。

• 最大的问题是Twemproxy无法平滑地增加Redis实例。对于运维人员来说，当因为业务需要增加Redis实例时工作量非常大。

　　Twemproxy作为最被广泛使用、最久经考验、稳定性最高的Redis代理，在业界被广泛使用。

　3.Codis

　　Twemproxy不能平滑增加Redis实例的问题带来了很大的不便，于是豌豆荚自主研发了Codis，一个支持平滑增加Redis实例的Redis代理软件，其基于Go和C语言开发，并于2014年11月在GitHub上开源。

　　Codis包含下面4个部分。

• Codis Proxy：Redis客户端连接到Redis实例的代理，实现了Redis的协议，Redis客户端连接到Codis Proxy进行各种操作。Codis Proxy是无状态的，可以用Keepalived等负载均衡软件部署多个Codis Proxy实现高可用。

• CodisRedis：Codis项目维护的Redis分支，添加了slot和原子的数据迁移命令。Codis上层的 Codis Proxy和Codisconfig只有与这个版本的Redis通信才能正常运行。

• Codisconfig：Codis管理工具。可以执行添加删除CodisRedis节点、添加删除Codis Proxy、数据迁移等操作。另外，Codisconfig自带了HTTP server，里面集成了一个管理界面，方便运维人员观察Codis集群的状态和进行相关的操作，极大提高了运维的方便性，弥补了Twemproxy的缺点。

• ZooKeeper：分布式的、开源的应用程序协调服务，是Hadoop和Hbase的重要组件，其为分布式应用提供一致性服务，提供的功能包括：配置维护、名字服务、分布式同步、组服务等。Codis依赖于ZooKeeper存储数据路由表的信息和Codis Proxy节点的元信息。另外，Codisconfig发起的命令都会通过ZooKeeper同步到CodisProxy的节点。

　　Codis的架构如图3所示。

　　

图3Codis的架构图

　　在图3的Codis的架构图中，Codis引入了Redis Server Group，其通过指定一个主CodisRedis和一个或多个从CodisRedis，实现了Redis集群的高可用。当一个主CodisRedis挂掉时，Codis不会自动把一个从CodisRedis提升为主CodisRedis，这涉及数据的一致性问题（Redis本身的数据同步是采用主从异步复制，当数据在主CodisRedis写入成功时，从CodisRedis是否已读入这个数据是没法保证的），需要管理员在管理界面上手动把从CodisRedis提升为主CodisRedis。

　　如果觉得麻烦，豌豆荚也提供了一个工具Codis-ha，这个工具会在检测到主CodisRedis挂掉的时候将其下线并提升一个从CodisRedis为主CodisRedis。

　　Codis中采用预分片的形式，启动的时候就创建了1024个slot，1个slot相当于1个箱子，每个箱子有固定的编号，范围是1~1024。slot这个箱子用作存放Key，至于Key存放到哪个箱子，可以通过算法“crc32(key)%1024”获得一个数字，这个数字的范围一定是1~1024之间，Key就放到这个数字对应的slot。例如，如果某个Key通过算法“crc32(key)%1024”得到的数字是5，就放到编码为5的slot（箱子）。1个slot只能放1个Redis Server Group，不能把1个slot放到多个Redis Server Group中。1个Redis Server Group最少可以存放1个slot，最大可以存放1024个slot。因此，Codis中最多可以指定1024个Redis Server Group。

　　Codis最大的优势在于支持平滑增加（减少）Redis Server Group（Redis实例），能安全、透明地迁移数据，这也是Codis 有别于Twemproxy等静态分布式 Redis 解决方案的地方。Codis增加了Redis Server Group后，就牵涉到slot的迁移问题。例如，系统有两个Redis Server Group，Redis Server Group和slot的对应关系如下。

Redis Server Group	slot
1	1~500
2	501~1024

　　当增加了一个Redis Server Group，slot就要重新分配了。Codis分配slot有两种方法。

　　第一种：通过Codis管理工具Codisconfig手动重新分配，指定每个Redis Server Group所对应的slot的范围，例如可以指定Redis Server Group和slot的新的对应关系如下。

Redis Server Group	slot
1	1~500
2	501~700
3	701~1024

　　第二种：通过Codis管理工具Codisconfig的rebalance功能，会自动根据每个Redis Server Group的内存对slot进行迁移，以实现数据的均衡。

　　4.Redis 3.0集群

　　Redis 3.0集群采用了P2P的模式，完全去中心化。Redis把所有的Key分成了16384个slot，每个Redis实例负责其中一部分slot。集群中的所有信息（节点、端口、slot等），都通过节点之间定期的数据交换而更新。

　　Redis客户端在任意一个Redis实例发出请求，如果所需数据不在该实例中，通过重定向命令引导客户端访问所需的实例。

　　Redis 3.0集群的工作流程如图4所示。

　　

图4Redis 3.0集群的工作流程图

　　如图4所示Redis集群内的机器定期交换数据，工作流程如下。

　　（1） Redis客户端在Redis2实例上访问某个数据。

　　（2） 在Redis2内发现这个数据是在Redis3这个实例中，给Redis客户端发送一个重定向的命令。

　　（3） Redis客户端收到重定向命令后，访问Redis3实例获取所需的数据。

　　Redis 3.0的集群方案有以下两个问题。

• 一个Redis实例具备了“数据存储”和“路由重定向”，完全去中心化的设计。这带来的好处是部署非常简单，直接部署Redis就行，不像Codis有那么多的组件和依赖。但带来的问题是很难对业务进行无痛的升级，如果哪天Redis集群出了什么严重的Bug，就只能回滚整个Redis集群。

• 对协议进行了较大的修改，对应的Redis客户端也需要升级。升级Redis客户端后谁能确保没有Bug？而且对于线上已经大规模运行的业务，升级代码中的Redis客户端也是一个很麻烦的事情。

　　综合上面所述的两个问题，Redis 3.0集群在业界并没有被大规模使用。

　　5.云服务器上的集群服务

　　国内的云服务器提供商阿里云、UCloud等均推出了基于Redis的云存储服务。

　　这个服务的特性如下。

　　（1）动态扩容

　　用户可以通过控制面板升级所需的Redis存储空间，扩容的过程中服务部不需要中断或停止，整个扩容过程对用户透明、无感知，这点是非常实用的，在前面介绍的方案中，解决Redis平滑扩容是个很烦琐的任务，现在按几下鼠标就能搞定，大大减少了运维的负担。

　　（2）数据多备

　　数据保存在一主一备两台机器中，其中一台机器宕机了，数据还在另外一台机器上有备份。

　　（3）自动容灾

　　主机宕机后系统能自动检测并切换到备机上，实现服务的高可用。

　　（4）实惠

　　很多情况下为了使Redis的性能更高，需要购买一台专门的服务器用于Redis的存储服务，但这样子CPU、内存等资源就浪费了，购买Redis云存储服务就很好地解决了这个问题。

　　有了Redis云存储服务，能使App后台开发人员从烦琐运维中解放出来。App后台要搭建一个高可用、高性能的Redis服务，需要投入相当的运维成本和精力。如果使用云存储服务，就没必要投入这些成本和精力，可以让App后台开发人员更专注于业务。