什么是主从同步（复制）
主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master)，后者称为从节点(slave),数据的复制是单向的，只能由主节点到从节点。
默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。
主从复制的作用
- 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
- 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
- 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
- 读写分离：可以用于实现读写分离，主库写、从库读，读写分离不仅可以提高服务器的负载能力，同时可根据需求的变化，改变从库的数量；
- 高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。
Redis之主从同步的实现原理
1.当从库和主库建立ms（master和slave）关系后，会向主库发送sync命令。
2.收到SYNC命令的主服务器执行BGSAVE命令，在后台生成一个RDB文件，并使用一个缓冲区记录从现在开始执行的所有写命令。
3.当主服务器的BGSAVE命令执行完毕，主服务器将生成的RDB文件发送给从服务器，从服务器接收并加载这个RDB文件，将自己的数据库状态更新至主服务器执行BGSAVE命令时的数据库状态。
4.主服务器将记录在缓冲区里面的所有命令发送给从服务器，从服务器执行这些写命令，将自己的数据库状态更新至主服务器当前所处的状态。
命令传播
在同步操作完毕后，主从服务器两者的数据库状态达到一致，但是如果客户端发送写命令给主服务器时，将导致主从服务器状态不一致。
为了让主从服务器数据一致，主服务器需要对从服务器执行命令传播操作：主服务器会将自己执行的那条写命令，发送给从服务器执行，当从服务器执行了该写命令后，主从服务器将再次回到一致状态。
主从同步配置
1.环境准备,运行3个redis数据库,达到 1主 2从的配置
主库 6379.conf
port 6379
daemonize yes
pidfile /data/6379/redis.pid
loglevel notice
logfile "/data/6379/redis.log"
dbfilename dump.rdb
dir /data/6379
从库 6380
port 6380
daemonize yes
pidfile /data/6380/redis.pid
loglevel notice
logfile "/data/6380/redis.log"
dbfilename dump.rdb
dir /data/6380
slaveof 127.0.0.1 6379 # 表示从库，主库为6379
从库 6381
port 6381
daemonize yes
pidfile /data/6381/redis.pid
loglevel notice
logfile "/data/6381/redis.log"
dbfilename dump.rdb
dir /data/6381
slaveof 127.0.0.1 6379 # 将这个写入才行
2.开启主从复制功能
redis-cli info #查看数据库信息 redis-cli info replication # 查看redis的复制授权信息 在6380 和6381数据库上 ,配置主从信息,通过参数形式修改配置,临时生效,注意要写入配置文件 redis-cli -p 6380 slaveof 127.0.0.1 6379 redis-cli -p 6381 slaveof 127.0.0.1 6379 此时检查6379的复制信息,以及6380 6381的复制信息 redis-cli -p 6380 info replication # 查看redis的复制授权信息 redis-cli -p 6381 info replication 主从复制是 读写分离的,master可写, slave只读
3.模拟主从复制故障,手动切换master-slave身份,low
1.杀死6379进程 ,干掉主库
2.手动切换 6381为新的主库,需要先关闭它的从库身份
redis-cli -p 6381 slaveof no one
3.修改6380的新主库是 6381
redis-cli -p 6380 slaveof 127.0.0.1 6381
2.8版本后的复制功能
为了解决旧版的问题，Redis2.8以后引入了PSYNC代替SYNC命令执行复制时的同步操作。
PSYNC命令具有完全同步和部分重同步功能。
完全同步和旧版的同步是一样的。
部分重同步主要是用于断线后的重复制情况：当从服务器断开重新连接后，如果条件允许，主服务器将断开期间的写命令发给从服务器，从服务器执行断开期间的写命令完成同步，将数据库更新到和主服务器一致。
部分重同步的实现
部分重同步的必备条件
- 主服务器的复制偏移量和从服务器的复制偏移量。
- 主服务器的复制积压缓冲区（队列，默认1MB）。
- 服务器的允许ID。
主服务器和从服务器都会维护一个复制偏移量，主要是用户对比复制的执行结果。例如主从服务器的复制偏移量均为1000，当主服务器完成了3个写命令后，主服务器偏移量为1003，这时候将3个命令给从服务器执行，从服务器执行完毕，复制偏移量也为1003。
如果主从服务器的数据是一致的，那么他们的偏移量也是一致的。
复制积压缓冲区，在主服务器将写命令给从服务器后，还会写入到复制积压缓冲区，如果执行到了偏移量为1003的时候，从服务器A断开，主服务器继续执行了7个写入命令，这时候主服务器的偏移量为1010，A服务器连接上，请求复制主服务器，这时候主服务器会分情况处理。
1）主服务器不是A从服务器之前复制的主服务器（根据服务器ID判断），执行完全同步。
2）发现A从服务器之前复制的是自己。根据A从服务器的偏移量去复制积压缓冲区中看1004-1010命令是否依然存在，如果存在将1004-1010偏移量的命令返回给A从服务器执行。如果不存在，只能执行完全同步恢复数据一致了。
Redis哨兵
哨兵的原理
哨兵(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-sentinel主从复制高可用
环境准备
三个redis数据库实例 ,配置好 1主 2从的配置
6379.conf
port 6379
daemonize yes
logfile "6379.log"
dbfilename "dump-6379.rdb"
dir "/var/redis/data/"
6380.conf
port 6380
daemonize yes
logfile "6380.log"
dbfilename "dump-6380.rdb"
dir "/var/redis/data/"
slaveof 127.0.0.1 6379
6381.conf
port 6381
daemonize yes
logfile "6381.log"
dbfilename "dump-6381.rdb"
dir "/var/redis/data/"
slaveof 127.0.0.1 6379
三个redis哨兵进程,指定好检测着谁，这里只列出一个
# 对哨兵进行配置，每个哨兵都要有一个配置
port 26379 # 端口
dir /var/redis/data/ # 日志存储位置
logfile "26379.log" # 日志文件
# 当前Sentinel节点监控 192.168.182.130:6379 这个主节点
# 2代表判断主节点失败至少需要2个Sentinel节点同意
# mymaster是主节点的别名
sentinel monitor mymaster 0.0.0.0 6379 2
# 每个Sentinel节点都要定期PING命令来判断Redis数据节点和其余Sentinel节点是否可达，如果超过30000毫秒30s且没有回复，则判定不可达
sentinel down-after-milliseconds mymaster 20000
# 当Sentinel节点集合对主节点故障判定达成一致时，Sentinel领导者节点会做故障转移操作，选出新的主节点，原来的从节点会向新的主节点发起复制操作，限制每次向新的主节点发起复制操作的从节点个数为1
sentinel parallel-syncs mymaster 1
# 故障转移超时时间为180000毫秒
sentinel failover-timeout mymaster 180000
分别启动 三个redis数据库, 以及三个 哨兵进程 ，注意 ：哨兵第一次启动后,会修改配置文件,如果错了,得删除配置文件,重新写。
redis-server xxx.conf # 启动数据库 redis-sentinel sentinel-26379.conf # 启动哨兵
验证哨兵是否正常
redis-cli -p 26379 info sentinel # 验证哨兵是否正常 master0:name=s21ms,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=3 # 正常
现在如果主库挂掉，会自动切换设置其他的从库为主库。
redis-cluster集群搭建
并发问题，数据量太大，单个redis内存不足，使用cluster进行分片存储。
redis集群采用P2P模式，是完全去中心化的，不存在中心节点或者代理节点；
redis集群是没有统一的入口的，客户端（client）连接集群的时候连接集群中的任意节点（node）即可，集群内部的节点是相互通信的（PING-PONG机制），每个节点都是一个redis实例；
为了实现集群的高可用，即判断节点是否健康（能否正常使用），redis-cluster有这么一个投票容错机制：如果集群中超过半数的节点投票认为某个节点挂了，那么这个节点就挂了（fail）。这是判断节点是否挂了的方法；
那么如何判断集群是否挂了呢? -> 如果集群中任意一个节点挂了，而且该节点没有从节点（备份节点），那么这个集群就挂了。这是判断集群是否挂了的方法；
那么为什么任意一个节点挂了（没有从节点）这个集群就挂了呢？ -> 因为集群内置了16384个slot（哈希槽），并且把所有的物理节点映射到了这16384[0-16383]个slot上，或者说把这些slot均等的分配给了各个节点。当需要在Redis集群存放一个数据（key-value）时，redis会先对这个key进行crc16算法，然后得到一个结果。再把这个结果对16384进行求余，这个余数会对应[0-16383]其中一个槽，进而决定key-value存储到哪个节点中。所以一旦某个节点挂了，该节点对应的slot就无法使用，那么就会导致集群无法正常工作。
因为集群至少有一半以上判定某个节点挂掉，所以节点数至少有三个。
1.通过配置，开启redis-cluster
# redis-7000.conf
port 7000
daemonize yes
dir "/opt/redis/data"
logfile "7000.log"
dbfilename "dump-7000.rdb
cluster-enabled yes # 开启集群模式
cluster-config-file nodes-7000.conf # 集群内部的配置文件
cluster-require-full-coverage no
#redis cluster需要16384个slot都正常的时候才能对外提供服务，换句话说，只要任何一个slot异常那么整个cluster不对外提供服务。 因此生产环境一般为no
# 6个实例，三个是主节点，三个是从节点，数量为6个节点才能保证高可用的集群。
2.创建6个配置文件,即6各节点，仅仅是端口的区别，内容均如上
[root@yugo /opt/redis/config 17:12:30]#ls redis-7000.conf redis-7002.conf redis-7004.conf redis-7001.conf redis-7003.conf redis-7005.conf
3.启动6个节点，ps查看进程ps -ef|grep redis
1855 2018-10-24 15:46:01 redis-server redis-7000.conf 1856 2018-10-24 15:46:13 redis-server redis-7001.conf 1857 2018-10-24 15:46:16 redis-server redis-7002.conf 1858 2018-10-24 15:46:18 redis-server redis-7003.conf 1859 2018-10-24 15:46:20 redis-server redis-7004.conf 1860 2018-10-24 15:46:23 redis-server redis-7005.conf
4.分配redis slot 槽位
- 手动写c语言 分配
- 使用ruby大神 写的一个redis模块,自动分配
5.配置ruby脚本环境
1.yum安装最简单
yum install ruby
2.自动配置好 PATH环境变量
ruby和gem的环境变量
3.下载ruby操作redis的模块
wget http://rubygems.org/downloads/redis-3.3.0.gem
4.用ruby的包管理工具 gem 安装这个模块
gem install -l redis-3.3.0.gem
5.通过ruby一键分配redis-cluster集群的槽位 找到机器上的redis-trib.rb命令,用绝对命令创建，如下所示：
6.开启集群,分配槽位
/opt/redis-4.0.10/src/redis-trib.rb create --replicas 1 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 # 1表示1个主库带1个从库
7.启动集群，连接集群节点，连接任意一个即可
redis-cli -p 7001 -c
注意：一定要加上-c，不然节点之间是无法自动跳转的！
8.登录redis并写入数据,发现槽位分配,且重定向之后,集群搭建成功
查看集群信息简单命令
1.查看当前集群信息
cluster info # 集群主节点状态 redis-cli -p 7000 cluster nodes | grep master # 集群从节点状态 redis-cli -p 7000 cluster nodes | grep slave
2.查看集群里有多少个节点
cluster nodes redis-cli -p 7000 cluster nodes # 等同于查看nodes-7000.conf文件节点信息
主从、哨兵、集群作用
redis主从：是备份关系， 我们操作主库，数据也会同步到从库。 如果主库机器坏了，从库可以上。就好比你 D盘的片丢了，但是你移动硬盘里边备份有。
redis哨兵：哨兵保证的是HA，即保证特殊情况故障自动切换，哨兵盯着你的“redis主从集群”，如果主库死了，它会告诉你新的主库是谁。
redis集群：集群保证的是高并发，因为多了一些兄弟帮忙一起扛。同时集群会导致数据的分散，整个redis集群会分成一堆数据槽，即不同的key会放到不不同的槽中。
主从保证了数据备份，哨兵保证了HA 即故障时切换，集群保证了高并发性。
来源：https://www.cnblogs.com/liuweida/p/11817081.html