Redis5.0 主从模式和高可用 搭建和测试报告

Redis 单机模式很简单，相关测试水文看这里

Redis5 压力测试结果反馈报告

必须的，今天接着写水文，写一写现在redis 支持的三种集群，主从模式，哨兵模式，Cluster模式，今天先搞主从模式

主从模式

主从模式是最简单的集群模式，其实就是复制基本只能解决读写分离问题，主机服务器一旦宕机基本完蛋，不具备高可用。

基本上redis的性能瓶劲主要在于网络IO和内存主频上面，单机版Redis在不考虑高可用的情况下基本满足80%的项目需要，因为单机版Redis可以实现10W/S的请求，除非缓存K-V值过大，通过读写分离缓存网卡的压力，否则这个并发处理能力可以应对大部分项目。

几乎所有的主从模式都是从服务器只提供只读不写的功能，否则会出现数据不一致的情况，现在无论那种数据库都不支持双向同步。

屁话少说，上配置代码，主服务器不需要配置，只需简单一句代码配置从服务器即可，声明主服务器是谁，余下的redis会自行交流。

slaveof 192.168.3.143 6379

一主多从

主服务器：192.168.3.143
从服务器：192.168.3.144
从服务器：192.168.3.145

从服务器 redis.conf 配置文件加入
slaveof 192.168.3.143 6379

  

一主多从（链式结构），所谓链式结构就是可以从服务器同步从服务器

主服务器：192.168.3.143
从服务器：192.168.3.144
从服务器：192.168.3.145

从服务器 redis.conf 配置文件加入
slaveof 192.168.3.143 6379

从服务器：192.168.3.147 
从服务器 redis.conf 配置文件加入 
slaveof 192.168.3.144 6379

尝试一下程序上来实现读写分离，Net Core 使用StackExchange.Redis 进行访问Redis集群，其它组件自己研究吧

//声明服务器地址，StackExchange会自己认别那个是主从关系
ConfigurationOptions option = new ConfigurationOptions();
option.EndPoints.Add("192.168.3.143", 6379);
option.EndPoints.Add("192.168.3.144", 6379);
option.EndPoints.Add("192.168.3.145", 6379);
option.EndPoints.Add("192.168.3.147", 6379);
ConnectionMultiplexer redis = ConnectionMultiplexer.Connect(option);

IDatabase db = redis.GetDatabase();
db.StringSet("test", "testvalue", flags: CommandFlags.DemandMaster);//CommandFlags.DemandMaster 标明主服务器写入
string value = db.StringGet("test", flags: CommandFlags.DemandReplica);//CommandFlags.DemandReplica 标明从服务器读取
Console.WriteLine(value);

代码行得通，己经分别从主/从服务器读取到数据，接下来将是要测试，主服务器倒下来了，会是怎么样？如图：成功报错，恭喜某程序猿喜提系统异常一次

 

接下三张图片将展示依次关闭从服务器：192.168.3.147，192.168.3.145 ，192.168.3.144  最后一张图将意味着己关闭所有从服务器，所有从服务器己关闭，程序运行成功报错

  

接着测试一下，StackExchange.Redis 框架问题，而对三个从服务器是否能分流从不同的从服务器取值，从而减轻从服务器的压力

  

从监控的图片来，三张从服务器的图标显示，StackExchange.Redis的确平均的分流的请求的流量。

哨兵模式

哨兵模式基本就是主从模式的升级版，主要解决高可用问题，实现自动容错和恢复。

简单理解就是主从模式一旦主机服务器宕机需要人工处理，这样一来你或者运维，得有一个睡不着，Redis引进哨兵模式的作用就是监控Redis服务是否正常运作，主服务器出现故障将自动将从服务器转换为主服务器。

理想状态下的配置架构如下：哨兵监控主从服务器，哨兵之间相互监控，组成哨兵组推荐三个哨兵以上并且最好独立部署，唯一能节省成本的好消息就是他们可以监控多个主服务器。

工作原理：

1. 每个哨兵都会监控主/从服务器及其它哨兵。
2. 当有一个哨兵检查主服务器下线（没有规定时间回复ping请求）,会将主服务器标识为主观下线
3. 当主服务器被标为主观下线，其它哨兵会马上检查主服务在线状态。
4. 当足够的哨兵（超过配置数量）将它标识为主观下线，主服务器会变成客观下线，如果数量不够则主观下线状态会除移。
5. 主服务器客观下线之后哨兵会从“从服务器”中选中一台服务器当主服务器。
6. 哨兵将修改其它从服务器以及被修复旧主服务器的配置，将统一修改为从服务器并且修改它们的主服务器地址。

注意：每个哨兵配置不一样，每个哨兵根据自己的配置超时时间来判断主服务器是否主观下线只有符合就标为主观下线，每个哨兵根据自己设定的“肯定数量”来判断主服务器是否客观下线，只要有一个哨兵的配置达到客观下线该哨兵就会执行故障迁移操作。

从服务器选举原理：

1. 首先发现客观下线的哨兵会发起一个选举请求，根据Raft算法，一般会成为领头哨头。
2. 根据与主服务器的断开的时间判断
3. 根据从服务器配置文件的权重（slave-priority）选举为主服务器
4. 复制偏移，从主节点收到更多的新数据的节点会被选择
5. 在所有条件相同的情况，选择runid最小的为主服务器

配置：只需要配置主数据库即可，哨兵会自动发现所有从数据库并进行监控，哨兵之间可以相互发现，只要确保端口放行就可以了，简单版配置简单到只有一句话

sentinel monitor <master-group-name> <ip> <port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2 //示例
//监控一个叫做mymaster的主节点，地址是 127.0.0.1 端口号是6379，判断客观下线需要2个哨兵“肯定”
//当然还有一些其它较为重要的配置，可以手动设定
sentinel down-after-milliseconds mymaster 60000 //设定检查超时时间，超过这个时间将认定为主观下线，默认30秒

下面进一些场景测试以验证观点，虽然支持采用默认配置的方式来进行启动，我们还是使用配置文件的方式进行启动

//主服务器
bind 0.0.0.0
port 6379
daemonize yes

//从服务器
bind 0.0.0.0
port 6379
daemonize yes
slaveof 192.168.3.40 6379

测试场景一：简单版测试，一主一从一哨兵，主服务器故障，能否自动将从服务器转换为主服务器

sentinel monitor mymaster 192.168.3.40 6379 1
sentinel down-after-milliseconds mymaster 5000//内网配置五秒就足够了
daemonize yes

成功运行

编写检查代码

    class Program
    {
        static void Main(string[] args)
        {
            //声明服务器地址，StackExchange会自己认别那个是主从关系
            ConfigurationOptions option = new ConfigurationOptions();
            option.EndPoints.Add("192.168.3.40", 6379);
            option.EndPoints.Add("192.168.3.167", 6379);
            ConnectionMultiplexer redis = ConnectionMultiplexer.Connect(option);

            IDatabase db = redis.GetDatabase();
            db.StringSet("test", "testvalue");
            DateTime exStartTime = DateTime.Now;
            DateTime exEndTime;
            bool isEX = false;
            while (true)
            {
                try
                {
                    var value = db.StringGet("test");
                    Console.WriteLine(value);
                    if (!value.HasValue && isEX!)
                        Console.WriteLine(value);
                    if (isEX && value.HasValue == true)
                    {
                        exEndTime = DateTime.Now;
                        Console.WriteLine($"连接成功，获取的值是：{value}");
                        break;
                    }
                }
                catch (Exception e)
                {
                    if (isEX == false)
                    {
                        Console.WriteLine($"连接失败!{e.Message}");
                        exStartTime = DateTime.Now;
                        isEX = true;
                    }
                }
            }
            Console.WriteLine($"连接异常时间{exStartTime},故障迁移成功时间{exEndTime}，花费{(exEndTime - exStartTime).TotalSeconds}秒");
        }
    }

悄悄打开ESXI 把虚拟机的网线拔掉

果然成功报错，并且进行故障转移

这个时候，重新把网络设置回来，并且查看两个redis.conf的配置文件内容，发现配置己被改动，192.168.3.40 己由主服务器转变成从服务器，哨兵的配置也相应作了改变

  

测试场景二：一主三从一哨兵

//主服务器（192.168.3.40）
bind 0.0.0.0
port 6379
daemonize yes

//从服务器（192.168.3.167）
bind 0.0.0.0
port 6379
daemonize yes
slaveof 192.168.3.40 6379

//从服务器（192.168.3.168）
bind 0.0.0.0
port 6379
daemonize yes
slaveof 192.168.3.40 6379

//从服务器（192.168.3.169）
bind 0.0.0.0
port 6379
daemonize yes
slaveof 192.168.3.40 6379

哨兵的配置依旧不变

//哨兵服务器(192.168.3.171)
sentinel monitor mymaster 192.168.3.40 6379 1
sentinel down-after-milliseconds mymaster 5000//内网配置五秒就足够了
daemonize yes

一顿操作猛如虎，断掉网络

成功切换，看看这四台服务器的配置都发现了什么变化吧

   

测试场景三：一主三从三哨兵

主从服务器的配置不变，哨兵的配置稍有变化，哨兵的服务器由一台增加到三台，分别是192.168.3.171，192.168.3.172，192.168.3.170，哨兵能相互发现和相互监控

sentinel monitor mymaster 192.168.3.40 6379 2 //裁仲服务器由1台变成2台
sentinel down-after-milliseconds mymaster 5000//内网配置五秒就足够了
daemonize yes

好了，准备就绪，故技重演，断网

查看一下四台Redis服务器配置发生什么变化

   

查看一下，三台哨兵的配置发生什么变化

  

就测到这里吧，下班了，明天大伙要是有兴趣，再捣鼓一下，Cluster模式，就是分布式集群，不知道有没有人看这些水文