主从复制是什么
主从复制，就是主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主
作用
读写分离，性能扩展 容灾快速恢复
当一个从数据库启动后，会向主数据库发送SYNC命令。同时主数据库接收到SYNC命令后会开始在后台保存快照（即RDB持久化的过程)，并将保存快照期间接收到的命令缓存 起來当快照完成后，Redis会将快照文件和所有缓存的命令发送给从数据库。从数据库收到后， 会载入快照文件并执行收到的缓存的命令。以上过程称为复制初始化。复制初始化结束后， 主数据库每当收到写命令时就会将命令同步给从数据库，从而保证主从数据库数据一致。
当主从数据库之间的连接断开重连后，Redis 2.6以及之前的版本会重新进行复制初始化（即主数据库重新保存快照并传送给从数据库)，即使从数据库可以仅有几条命令没有收到，主数据库也必须要将数据库里的所有数据重新传送给从数据库。这使得主从数据库断 线重连后的数据恢复过程效率很低下，在网络环境不好的时候这一问题尤其明显。Redis2.8 版的一个重要改进就是断线重连能够支持有条件的增量数据传输，当从数据库重新连接上主数据库后，主数据库只需要将断线期间执行的命令传送给从数据库从而大大提高Redis 复制的实用性。
复制同步阶段会贯穿整个主从同步过程的始终，直到主从关系终止为止。在复制的过程中，快照无论在主数据库还是从数据库中都起了很大的作用，只要执行 复制就会进行快服即使我们关闭了 RDB方式的持久化（通过删除所有save参数)。
乐观复制Redis采用了乐观复制（optimistic replication)的复制策略，容忍在一定时 间内主从数据库的内容是不同的，但是两者的数据会最终同步。具体来说，Redis在主 从数据库之间复制数据的过程本身是异步的，这意味着，主数据库执行完客户端请求的命令后会立即将命令在主数据库的执行结果返回给客户端，并异步地将命令同步给 从数据库，而不会等待从数据库接收到该命令后再返回给客户端。这一特性保证了启 用复制后主数据库的性能不会受到影响，但另一方面也会产生一个主从数据库数据不 一致的时间窗口，当主数据库执行了一条写命令后，主数据库的数据已经发生的变动，然而在主数据库将该命令传送给从数据库之前，如果两个数据库之间的网络连接断开 了，此时二者之间的数据就会是不一致的。从这个角度来看，主数据库是无法得知某 个命令最终同步给了多少个从数据库的，不过Redis提供了两个配置选项来限制只有 当数据至少同步给指定数量的从数据库时，主数据库才是可写的.
一主二仆
数据库不仅可以接收主数据库的同步数据，自己也可以同时作为主数据库存在，形成类似图的结构，
通过复制可以实现读写分离，以提高服务器的负载能力。在常见的场景中（如电子商务网站)，读的频率大于写，当单机的Redis无法应付大量的读请求时（尤其是较耗资源的 请求，如SORT命令等）可以通过复制功能建立多个从数据库节点，主数据库只进行写操作，而从数据库负责读操作。这种一主多从的结构很适合读多写少的场景，而当单个的主数据库不能够满足需求时，就需要使用Redis 3.0推出的集群功能，
另一个相对耗时的操作是持久化，为了提高性能，可以通过复制功能建立一个（或若干个）从数据库，并在从数据库中启用持久化，同时在主数据库禁用持久化。当从数据库崩溃重启后主数据库会自动将数据同步过来，所以无需担心数据丢失。
然而当主数据库崩溃时，情况就稍显复杂了。手工通过从数据库数据恢复主数据库数据时，需要严格按照以下两步进行。
在从数据库中使用SLAVEOF NO ONE命令将从数据库提升成主数据库继续服务。启动之前崩溃的主数据库，然后使用SLAVEOF命令将其设置成新的主数据库的从 数据库，即可将数据同步回来。
注意当开启复制且主数据库关闭持久化功能时，一定不要使用Supervisor以及类似 的进程管理工具令主数据库崩溃后自动重启。同样当主数据库所在的服务器因故关闭 时，也要避免直接重新启动。这是因为当主数据库重新启动后，因为没有开启持久化功能，所以数据库中所有数据都被清空，这时从数据库依然会从主数据库中接收数据， 使得所有从数据库也被清空，导致从数据库的持久化失去意义。
无论哪种情况，手工维护从数据库或主数据库的重启以及数据恢复都相对麻烦，好在 Redis提供了一种自动化方案哨兵来实现这一过程，避免了手工维护的麻烦和容易出错的问题，
实现配置
主机配置
从机配置
启动主机
启动从机
缺点
这种情况下一旦主机宕机,整个写服务都会瘫痪,因此为了避免群龙无首的局面,我们可以对配置进行优化 这里我们先采用薪火相传的模式.
一脉相传
上一个slave可以是下一个slave的Master，slave同样可以接收其他slaves的连接和同步请求，那么该slave作为了链条中下一个的master, 可以有效减轻master的写压力,去中心化降低风险。中途变更转向:会清除之前的数据，重新建立拷贝最新的
风险:一旦某个slave宕机，后面的slave都没法备份.
主机配置
从机配置
主机启动
从机启动
反客为主
当一个master宕机后，后面的slave可以立刻升为master，其后面的slave不用做任何修改。
主机宕机
新主登基
用 slaveof no one 将从机变为主机。
当原来的master又复活之后，后面的slave和原来的mamaster就没关系了
当原来的master又复活之后，后面的slave和原来的master就没关系了
哨兵模式
Redis中复制的原理和使用方式，在一个典型的一主多从的Redis系统中， 从数据库在整个系统中起到了数据冗余备份和读写分离的作用。当主数据库遇到异常中断服务后，开发者可以通过手动的方式选择一个从数据库来升格为主数据库，以使得系统能够继续提供服务。然而整个过程相对麻烦且需要人工介入，难以实现自动化。为此Redis 2.8中提供了哨兵工具来实现自动化的系统监控和故障恢复功能。
2
3
4
2在任何情况下都不应该使用这个版本的哨兵。这里说的哨兵都是Redis2.8之后的
3
4
功能
顾名思义，哨兵的作用就是监控Redis系统的运行状况。它的功能包括以下两个。
(1) 监控主数据库和从数据库是否正常运行。
(2) 主数据库出现故障时自动将从数据库转换为主数据库。
2
3
2
3
主机配置
从机配置
哨兵配置
自定义的/myredis目录下新建sentinel.conf文件
启动主机
启动从机
启动哨兵
主机宕机
新主登基
其中— sdown表示哨兵主观认为主数据库停止服务了，而+odown则表示哨兵客观认为主数据库停止服务了，关于主观和客观的区别后文会详细介绍。此时哨兵开始执行故障恢复， 即挑选一个从数据库，将其升格为主数据库。+try -faiover 表示哨兵开始进行故障恢复，+failover -end 表示哨兵完成故障恢复，期间涉及的内容比较复杂，包括领头哨兵的选举、备选从数据库的选择等，放到后面介绍，此处只需要关注最后3条输出。+switch-master表示主数据库从6379端口迁移 到6381端口，即6381端口的从数据库被升格为主数据库，同时两个+slave则列出了新的主数据库的两个从数据库，端口分别为6380和6379。其中6379就是之前停止服务的主数据库，可见哨兵并没有彻底清除停止服务的实例的信息，这是因为停止服务的实例有 能会在之后的某个时间恢复服务，这时哨兵会让其重新加入进来，所以当实例停止服务后， 哨兵会更新该实例的信息，使得当其重新加入后可以按照当前信息继续对外提供服务。此例中6379端口的主数据库实例停止服务了，而6381端口的从数据库已经升格为主数据库， 当6379端口的实例恢复服务后，会转变为6380端口实例的从数据库来运行，所以哨兵将6379端口实例的信息修改成了6381端口实例的从数据库。 故障恢复完成后，可以使用Redis命令行客户端重新检查6379和6381两个端口上的 实例的复制信息：
-sdown表示实例6379已经恢复服务了（与+sdown相反i同时+convert-to-slave 表示将6379端口的实例设置为6381端口实例的从数据库。
实现原理
一个哨兵进程启动时会读取配置文件的内容，通过如下的配置找出需要监控的主数据库:
2
3
2
3
其中master-name是一个由大小写字母、数字和组成的主数据库的名字，因为考虑到故障恢复后当前监控的系统的主数据库的地址和端口会产生变化，所以哨兵提供了命令可以通过主数据库的名字获取当前系统的主数据库的地址和端口号.ip表示当前系统中主数据库的地址，而redis-port则表示端口号。
quorum用来表示执行故障恢复操作前至少需要几个哨兵节点同意，后文会详细介绍。 一个哨兵节点可以同时监控多个Redis主从系统，只需要提供多个sentinel monitor
配置即可，例如：
2
3
4
2sentinel monitor othermaster 192.168.1.3 6380 4
3
4
同时多个哨兵节点也可以同时监控同一个Redis主从系统，从而形成网状结构。
配置文件中还可以定义其他监控相关的参数，每个配置选项都包含主数据库的名字使 得监控不同主数据库时可以使用不同的配置参数。例如：
2
3
4
2sentinel down-after-milliseconds othermaster 10000
3
4
上面的两行配置分别配置了 mymaster 和othermaster 的 down-after-milliseconds 选项分别为60000和10000。
哨兵启动后，会与要监控的主数据库建立两条连接，这两个连接的建立方式与普通的Redis客户端无异。其中一条连接用来订阅该主数据的_Sentinel_:hello频道以获取
其他同样监控该数据库的哨兵节点的信息，另外哨兵也需要定期向主数据库发送INFO等 命令来获取主数据库本身的信息，客户端的连接进入订阅模式时就不 能再执行其他命令了，所以这时哨兵会使用另外一条连接来发送这些命令和主数据库的连接建立完成后，哨兵会定时执行下面3个操作。
(1) 每10秒哨兵会向主数据库和从数据库发送INFO命令。
(2) 每2秒哨兵会向主数据库和从数据库的_sentinel_:hello频道发送自己的 信息。
(3) 每1秒哨兵会向主数据库、从数据库和其他哨兵节点发送PING命令。
这3个操作贯穿哨兵进程的整个生命周期中，非常重要，可以说了解了这3个操作的 意义就能够了解哨兵工作原理的一半内容了。下面分别详细介绍。
首先，发送INFO命令使得哨兵可以获得当前数据库的相关信息包括运行ID、复制 信息等）从而实现新节点的自动发现。前面说配置哨兵监控Redis主从系统时只需要指定主数据库的信息即可，因为哨兵正是借助INFO命令来获取所有复制该主数据库的从数据库信息的。启动后，哨兵向主数据库发送INFO命令，通过解析返回结果来得知从数据库列表，而后对每个从数据库同样建立两个连接，两个连接的作用和前文介绍的与主数据库 建立的两个连接完全一致。在此之后，哨兵会每10秒定时向己知的所有主从数据库发送INFO命令来获取信息更新并进行相应操作，比如对新增的从数据库建立连接并加入监控列表，对主从数据库的角色变化（由故障恢复操作引起）进行信息更新等。接下来哨兵向主从数据库的_Sentinel_:hello 频道发送信息来与同样监控该数 据库的哨兵分享自己的信息。发送的消息内容为：
<哨兵的地址 >,<哨兵的端口 >, <哨兵的运行ID>,<哨兵的配置版本>,<主数据库的名字>,<主数据库的地址>, <主数据库的端口>, <主数据库的配置版本>
可以看到消息包括的哨兵的基本信息，以及其监控的主数据库的信息。
哨兵会订阅每个其监控的数据库的_Sentinel_:hell0频道，所以当其他哨兵收到消息 后，会判断发消息的哨兵是不是新发现的哨兵。如果是则将其加入已发现的哨兵列表中并 创建一个到其的连接（与数据库不同，哨兵与哨兵之间只会创建一条连接用来发送PING 命令，而不需要创建另外一条连接来订阅频道，因为哨兵只需要订阅数据库的频道即可实 现自动发现其他哨兵）。同时哨兵会判断信息中主数据库的配置版本，如果该版本比当前记 录的主数据库的版本高，则更新主数据库的数据。配置版本的作用会在后面详细介绍。 实现了自动发现从数据库和其他哨兵节点后，哨兵要做的就是定时监控这些数据库 和节点有没有停止服务。这是通过每隔一定时间向这些节点发送PING命令实现的。时间 间隔与 down-after-milliseconds 选项有关当down-after-milliseconds 的值 小于1秒时哨兵会每隔down-after-milliseconds指定的时间发送一次PING命令，当down-after-milliseconds的值大于1秒时，哨兵会每隔1秒发送一次PING命令。 例如：
2
3
4
5
6
2sentinel down-after-milliseconds mymaster 60000
3//每隔600毫秒发送一次PING命令
4sentinel down-after-milliseconds othermaster 600
5
6
当超过down-after-mill seconds选项指定时间后，如果被PING的数据库或节点仍然未进行回复，则哨兵认为其主观下线（ subjectively down)。主观下线表示从当前的哨兵进程看来，该节点已经下线。如果该节点是主数据库，则哨兵会进一步判断是否需要对其进行故障恢复：哨兵发送SENTINEL is-master-down-by-addr命令询问其他哨兵节点以了解他们是否也认为该主数据库主观下线，如果达到指定数量时，哨兵会认为其客观 下线(objectively down),并选举领头的哨兵节点对主从系统发起故障恢复。这个指定数量 即为前文介绍的quorum参数。例如，下面的配置：
sentinel monitor mymaster 127.0.0.1 6379 2
该配置表示只有当至少两个Sentinel节点（包括当前节点）认为该主数据库主观下线时，当前哨兵节点才会认为该主数据库客观下线。进行接下来的选举领头哨兵步骤。
虽然当前哨兵节点发现了主数据库客观下线，需要故障恢复，但是故障恢复需要由领头的哨兵来完成，这样可以保证同一时间只有一个哨兵节点来执行故障恢复。选举领头哨兵的过程使用了Raft算法，具体过程如下。
(1)发现主数据库客观下线的哨兵节点（下面称作A)向每个哨兵节点发送命令，要 求对方选自己成为领头哨兵。
(2)如果目标哨兵节点没有选过其他人，则会同意将A设置成领头哨兵。
(3)如果A发现有超过半数且超过quorum参数值的哨兵节点同意选自己成为领头哨兵，则A成功成为领头哨兵。
(4)当有多个哨兵节点同时参选领头哨兵，则会出现没有任何节点当选的可能。此时 每个参选节点将等待一个随机时间重新发起参选请求，进行下一轮选举，直到选举成功。 具体过程可以参考Raft算法的过程http://raftconsensus.github.io/。因为要成为领头哨兵 必须有超过半数的哨兵节点支持，所以每次选举最多只会选出一个领头哨兵。
选出领头哨兵后，领头哨兵将会开始对主数据库进行故障恢复。故障恢复的过程相对 简单，具体如下。 首先领头哨兵将从停止服务的主数据库的从数据库中挑选一个来充当新的主数据库。 挑选的依据如下。
(1) 所有在线的从数据库中，选择优先级最高的从数据库。优先级可以通过 slave-priority选项来设置。
(2) 如果有多个最高优先级的从数据库，则复制的命令偏移量（见8.1.7节）越大（即 复制越完整）越优先。
(3) 如果以上条件都一样，则选择运行ID较小的从数据库。 选出一个从数据库后，领头哨兵将向从数据库发送SLAVEOF NO ONE命令使其升格为主数据库。而后领头哨兵向其他从数据库发送SLAVEOF命令来使其成为新主数据库的从数据库。最后一步则是更新内部的记录，将已经停止服务的旧的主数据库更新为新的主数据库的从数据库，使得当其恢复服务时自动以从数据库的身份继续服务。
部署原则
哨兵以独立进程的方式对一个主从系统进行监控，监控的效果好坏与否取决于哨兵的 视角是否有代表性。如果一个主从系统中配置的哨兵较少，哨兵对整个系统的判断的可靠 性就会降低。极端情况下，当只有一个哨兵时，哨兵本身就可能会发生单点故障。整体来 讲，相对稳妥的哨兵部署方案是使得哨兵的视角尽可能地与每个节点的视角一致，即：
(1)为每个节点（无论是主数据库还是从数据库）部署一个哨兵；
(2)使每个哨兵与其对应的节点的网络环境相同或相近。
这样的部署方案可以保证哨兵的视角拥有较高的代表性和可靠性。举例一个例子. 当网络分区后，如果哨兵认为某个分区是主要分区即意味着从每个节点观察，该分区均为主分区。
同时设置quorum的值为N/2+1 (其中N为哨兵节点数量），这样使得只有当大部分哨兵节点同意后才会进行故障恢复。
当系统中的节点较多时，考虑到每个哨兵都会和系统中的所有节点建立连接，为每个 节点分配一个哨兵会产生较多连接，尤其是当进行客户端分片时使用多个哨兵节点监控多 个主数据库会因为Redis不支持连接复用而产生大量冗余连接，具体可以见此issue： https://github.com/antirez/redis/issues/2257 ； 同时如果 Redis 节点负载较高，会在一定程度上影响其对哨兵的回复以及与其同机的哨兵与其他节点的通信。所以配置哨兵时还需要根据 实际的生产环境情况进行选择。
转载于:https://www.cnblogs.com/fmgao-technology/p/10411163.html
