主从式结构的特点

1、可以有效地利用各工作站的资源。

2、可以减少服务器上的工作量。

3、网络的工作效率较高。

4、对工作站的管理较为困难。

5、数据的安全性低于专用服务器结构。

6、网络处理效率低下。

主从式架构简介

主从式架构或客户端－服务器（Client/Server）结构简称C/S结构，是一种网络架构，它把客户端（Client)（通常是一个采用图形用户界面的程序）与服务器（Server)区分开来。每一个客户端软件的实例都可以向一个服务器或应用程序服务器发出请求。有很多不同类型的服务器，例如文件服务器、游戏服务器等。

主从式架构通过不同的途径应用于很多不同类型的应用程序，最常见就是目前在因特网上用的网页。例如，当你在维基百科阅读文章时，你的电脑和网页浏览器就被当做一个客户端，同时，组成维基百科的电脑、数据库和应用程序就被当做服务器。

一． 准备服务器

准备两台主机，分别安装好Mysql （要相同版本），确定版本无误，确保mysql服务正常启动，确保两台主机处于同一个局域网中，确定好哪台做为主、备机器，假设A为主机，B为备机，假设：

A主机IP地址为：172161690 端口3306

B主机IP地址为: 172169998 端口3306

二． Mysql建立主-从服务器热备配置步骤

1 创建同步用户

进入MySql操作界面，在主服务器上为从服务器建立一个连接帐户，该帐户必须授予REPLICATION SLAVE权限。

操作指令如下：

1) grant select,replication slave on to 'replicate'@'172169998' identified by '1234567';

2) flush privileges;

2 修改Mysql配置

如果上面的准备工作做好，就可以进行对Mysql配置文件进行修改了，首先找到主服务器Mysql安装文件所有在目录，找到myini文件用记事本打开。在[mysqld]下增加如下内容：

server-id = 1 

log-bin=mysql-bin  

binlog-do-db =test   #需要备份的数据库，多个写多行

binlog-ignore-db = mysql      #不需要备份的数据库，多个写多行

3 重启mysql服务

修改完配置文件保存后，重启一下mysql服务。

4 查看主服务器状态

进入A服务器Mysql 客户端输入命令

1）Show master STATUS;

2）返回结果如下：

 

注意看里面的参数，特别前面两个File和Position，在从服务器（Slave）配置主从关系会有用到的。

5 从服务器Slave配置修改配置文件

因为这里面是以主－从方式实现mysql双机热备的，所以在从服务器就不用在建立同步帐户了，直接打开配置文件myini进行修改即可，道理还是同修改主服务器上的一样，只不过需要修改的参数不一样。

如下：

[mysqld] 

server-id = 2 

log-bin=mysql-bin 

replicate-do-db = test 

replicate-ignore-db =mysql

 

6 重启mysql服务

修改完配置文件保存后，重启一下mysql服务。

7 配置从服务器

先停止slave服务线程，这个是很重要的，如果不这样做会造成下面操作不成功，再用change mster 语句指定同步位置，操作如下：

   1) stop slave;

2) change master to master_host='172161690',

master_user='replicate',master_password='1234567',master_port=3306,

master_log_file='mysql-bin000001',master_log_pos=98;

  3) start slave

4) show slave status

 

查看下面两项值均为Yes，即表示设置从服务器成功。

Slave_IO_Running: Yes 

Slave_SQL_Running: Yes 

主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。 这不是一种推荐的方式，更多时候，我们优先考虑 哨兵模式 。

哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是 哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

这里的哨兵有两个作用

然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

用文字描述一下 故障切换（failover） 的过程。假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为 主观下线 。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为 客观下线 。这样对于客户端而言，一切都是透明的。

配置3个哨兵和1主2从的Redis服务器来演示这个过程。

首先配置Redis的主从服务器，修改redisconf文件如下

上述内容主要是配置Redis服务器，从服务器比主服务器多一个slaveof的配置和密码。

配置3个哨兵，每个哨兵的配置都是一样的。在Redis安装目录下有一个sentinelconf文件，copy一份进行修改

上述关闭了保护模式，便于测试。

有了上述的修改，我们可以进入Redis的安装目录的src目录，通过下面的命令启动服务器和哨兵

注意启动的顺序。 首先是主机（19216811128）的Redis服务进程，然后启动从机的服务进程，最后启动3个哨兵的服务进程。

上面是通过Jedis进行使用的，同样也可以使用Spring进行配置RedisTemplate使用。

sentinel down-after-milliseconds配置项只是一个哨兵在超过规定时间依旧没有得到响应后，会自己认为主机不可用。对于其他哨兵而言，并不是这样认为。哨兵会记录这个消息，当拥有认为主观下线的哨兵达到sentinel monitor所配置的数量时，就会发起一次投票，进行failover，此时哨兵会重写Redis的哨兵配置文件，以适应新场景的需要。

导读：Redis是被广泛使用的基础软件之一。对于工程师和,架构师，运维人员来说，了解Redis的高可用方案和背后的原理，是必备的基础知识。本文作者深入分析了Redis高可用的方方面面，并且做了有效总结，相信对广大读者可以起到很好的领路作用。

作者 codedump codedumpinfo 博主，多年从事互联网服务器后台开发工作。可访问作者博客阅读 codedump 更多文章。

Redis中为了实现高可用（High Availability，简称HA），采用了如下两个方式：

Redis中主从节点复制数据有全量复制和部分复制之分。

全量复制使用snyc命令来实现，其流程是：

旧版本全量复制功能，其最大的问题是从服务器断线重连时，即便在从服务器上已经有一部分数据了，也需要进行全量复制，这样做的效率很低，于是新版本的Redis在这部分做了改进。

新版本Redis使用psync命令来代替sync命令，该命令既可以实现完整全同步也可以实现部分同步。

执行复制的双方，主从服务器，分别会维护一个复制偏移量：

主服务器内部维护了一个固定长度的先进先出队列做为复制积压缓冲区，其默认大小为1MB。

在主服务器进行命令传播时，不仅会将写命令同步到从服务器，还会将写命令写入复制积压缓冲区。

每个Redis服务器，都有其运行ID，运行ID由服务器在启动时自动生成，主服务器会将自己的运行ID发送给从服务器，而从服务器会将主服务器的运行ID保存起来。

从服务器Redis断线重连之后进行同步时，就是根据运行ID来判断同步的进度：

有了前面的准备，下面开始分析psync命令的流程：

前面两种情况主服务器收到psync命令之后，会出现以下三种可能：

Redis使用哨兵机制来实现高可用(HA)，其大概工作原理是：

以上将Redis节点分为两类：

以上是大体的流程，这个流程需要解决以下几个问题：

以下来逐个回答这些问题。

哨兵节点通过三个定时监控任务监控Redis数据节点的服务可用性。

每隔10秒，每个哨兵节点都会向主、从Redis数据节点发送info命令，获取新的拓扑结构信息。

Redis拓扑结构信息包括了：

这样，哨兵节点就能从info命令中自动获取到从节点信息，因此那些后续才加入的从节点信息不需要显式配置就能自动感知。

这一操作实际上完成了两件事情： 发现新的哨兵节点：如果有新的哨兵节点加入，此时保存下来这个新哨兵节点的信息，后续与该哨兵节点建立连接。 交换主节点的状态信息，作为后续客观判断主节点下线的依据。

每隔1秒，每个哨兵节点向主、从数据节点以及其他sentinel节点发送ping命令做心跳探测，这个心跳探测是后续主观判断数据节点下线的依据。

上面三个监控任务中的第三个探测心跳任务，如果在配置的down-after-milliseconds之后没有收到有效回复，那么就认为该数据节点“主观下线（sdown）”。

为什么称为“主观下线”？因为在一个分布式系统中，有多个机器在一起联动工作，网络可能出现各种状况，仅凭一个节点的判断还不足以认为一个数据节点下线了，这就需要后面的“客观下线”。

当一个哨兵节点认为主节点主观下线时，该哨兵节点需要通过”sentinel is-master-down-by addr”命令向其他哨兵节点咨询该主节点是否下线了，如果有超过半数的哨兵节点都回答了下线，此时认为主节点“客观下线”。

当主节点客观下线时，需要选举出一个哨兵节点做为哨兵领导者，以完成后续选出新的主节点的工作。

这个选举的大体思路是：

可以看到，这个选举领导者的流程很像raft中选举leader的流程。

在剩下的Redis从节点中，按照以下顺序来选择新的主节点：

选择了新的主节点之后，还需要最后的流程让该节点成为新的主节点：

原文地址：

https://wwwcodedumpinfo/post/20190409-redis-sentinel/

参考阅读：

GIAC全球互联网架构大会深圳站将于2019年6月举行，掌阅资深架构师，畅销图书《Redis 深度历险：核心原理与应用实践》作者钱文品将作为数据库专场的讲师出席2019年GIAC深圳站，并做关于Redis高性能，高可用方面的的演讲。本届GIAC数据库专场邀请阿里云前数据库总负责人余峰作为出品人，议题如下。

参加 GIAC，盘点2019年最新技术，目前 购买75折优惠 ，多人购买有更多优惠。识别二维码 了解大会更多详情。

在主服务器与从服务器之间进行数据复制，分为两种方式：完整的重同步(full resynchronization)和部分的重同步(partial resynchronization)。

主服务器 创建 并 发送RDB文件 ，以及向从服务器发送保存在 缓冲区 里面的写命令来进行同步。

完整的重同步创建RDB文件、发送RDB文件会消耗主服务器的CPU、内存和磁盘IO等资源，同时也会占用大量的网络带宽和流量。在实际中，有时完整的重同步是没有必要的，例如当从服务器与主服务器网络连接断开时间很短，数据的不一致可能就是为数不多的几条写命令，这时却要进行全量数据的复制，显然是资源的浪费。其实只需要将断开连接期间的数据进行同步就可以完成数据的一致性。

完整的重同步只应该用于首次复制，或者万不得已需要全量复制时才执行。

针对完整的重同步的缺陷，Redis提供了部分的重同步功能。

部分的重同步功能涉及到三个部分：

部分的重同步过程：

主服务器通过向从服务器传播命令来更新从服务器的状态，保持主从服务器一致，而从服务器通过向主服务器发送命令来进行心跳检测，以及命令丢失检测。

在命令传播阶段，从服务器默认会以每秒一次的频率，向主服务器发送命令心跳。用于检测主从之间的网络连接状态，以及检测传播的命令是否丢失等。