Redis 的主从同步，及两种高可用方式_白小黑..的博客-CSDN博客_redis的主从
Redis 的主从同步，及两种高可用方式
白小黑..
于 2018-10-15 19:22:03 发布
214644
收藏
348
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_42711549/article/details/83061052
版权
一、Redis 介绍
Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。
与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。
Redis 是一个高性能的key-value数据库。 redis的出现，很大程度补偿了memcached这类key/value存储的不足，在部 分场合可以对关系数据库起到很好的补充作用。
二、Redis 主从同步
Redis主从同步。数据可以从主服务器向任意数量的从服务器上同步，从服务器可以是关联其他从服务器的主服务器。这使得Redis可执行单层树复制。存盘可以有意无意的对数据进行写操作。由于完全实现了发布/订阅机制，使得从数据库在任何地方同步树时，可订阅一个频道并接收主服务器完整的消息发布 记录。同步对读取操作的可扩展性和数据冗余很有帮助。
工作原理：
Redis的主从结构可以采用一主多从或者级联结构，Redis主从复制可以根据是否是全量分为全量同步和增量同步。
全量同步
Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份。具体步骤如下：
1）从服务器连接主服务器，发送SYNC命令；
2）主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令；
3）主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；
4）从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；
5）主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；
6）从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；
完成上面几个步骤后就完成了从服务器数据初始化的所有操作，从服务器此时可以接收来自用户的读请求。
增量同步
Redis增量复制是指Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。
增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令。
Redis主从同步策略
主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。当然，如果有需要，slave 在任何时候都可以发起全量同步。redis 策略是，无论如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步。
注意点
如果多个Slave断线了，需要重启的时候，因为只要Slave启动，就会发送sync请求和主机全量同步，当多个同时出现的时候，可能会导致Master IO剧增宕机。
实验环境：
server3:172.25.254.103 redis-slave
server4:172.25.254.104 redis-slave
server2:172.25.254.101 redis-master
1.redis 环境搭建
1）在所有实验主机上安装 Redis
先下载安装包 redis-4.0.8.tar.gz 并做以下操作
tar zxf redis-4.0.8.tar.gz ##解压安装包
cd redis-4.0.8
yum install gcc -y
make && make install ###安装
cd redis-4.0.8/utils/
./install_server.sh 执行这个脚本
2）编辑配置文件
vim /etc/redis/6379.conf
找到第70行的bind 后面写0.0.0.0
/etc/init.d/redis_6379 stop
/etc/init.d/redis_6379 start
2.配置redis-slave
[root@server3 ~]# vim /etc/redis/6379.conf slaveof 172.25.254.101 6379 # redis-master 的ip
[root@server3 ~]# /etc/init.d/redis_6379 restart Stopping ... Redis stopped Starting Redis server...
[root@server4 ~]# vim /etc/redis/6379.conf slaveof 172.25.254.101 6379 [root@server4 ~]# /etc/init.d/redis_6379 restart Stopping ... Redis stopped Starting Redis server...
如上操作所示，已经完成redis的主从复制3.测试
在master端server2:操作，在slave端server3查看执行redis-cli,登陆 若数据一致，则同步成功
1）在master 端操作
2）在selave 端查看
三、Redis Sentinel（哨兵）架构下的高可用
Redis的主从复制下，一旦主节点由于故障不能提供服务，需要人工将从节点晋升为主节点，同时还要通知应用方更新主节点地址，对于很多应用场景这种故障处理的方法是无法接受的。但是Redis从2.8开始正式提供了Redis Sentinel（哨兵）架构来解决这个问题。
Redis Sentinel是一个分布式架构，其中包含若干个Sentinel节点和Redis数据节点，每个Sentinel节点会对数据节点和其余Sentinel节点进行监控，当它发现节点不可达时，会对节点做下线标识。如果被标识的是主节点，它还会和其他Sentinel节点进行“协商”，当大多数Sentinel节点都认为主节点不可达时，它们会选举出一个Sentinel节点来完成自动故障转移的工作，同时会将这个变化通知给Redis应用方。整个过程完全是自动的，不需要人工来介入，所以这套方案很有效地解决了Redis的高可用问题。
实现原理：
三个定时监控任务
1）每隔10秒，每个Sentinel节点会向主节点和从节点发送info命令获取最新的拓扑结构。
2）每隔2秒，每个Sentinel节点会向Redis数据节点的__sentinel__:hello频道上发送该Sentinel节点对于主节点的判断以及当前Sentinel节点的信息，同时每个Sentinel节点也会订阅该频道，来了解其他Sentinel节点以及它们对主节点的判断。
3）每隔一秒，每个Sentinel节点会向主节点、从节点、其余Sentinel节点发送一条ping命令做一次心跳检测，来确认这些节点当前是否可达。
主观下线
因为每隔一秒，每个Sentinel节点会向主节点、从节点、其余Sentinel节点发送一条ping命令做一次心跳检测，当这些节点超过down-after-milliseconds没有进行有效回复，Sentinel节点就会对该节点做失败判定，这个行为叫做主观下线。
客观下线
当Sentinel主观下线的节点是主节点时，该Sentinel节点会向其他Sentinel节点询问对主节点的判断，当超过<quorum>个数，那么意味着大部分的Sentinel节点都对这个主节点的下线做了同意的判定，于是该Sentinel节点认为主节点确实有问题，这时该Sentinel节点会做出客观下线的决定。
领导者Sentinel节点选举
Raft算法：假设s1(sentinel-1)最先完成客观下线，它会向其余Sentinel节点发送命令，请求成为领导者；收到命令的Sentinel节点如果没有同意过其他Sentinel节点的请求，那么就会同意s1的请求，否则拒绝；如果s1发现自己的票数已经大于等于某个值，那么它将成为领导者。
故障转移
1）领导者Sentinel节点在从节点列表中选出一个节点作为新的主节点
2）上一步的选取规则是与主节点复制相似度最高的从节点
3）领导者Sentinel节点让剩余的从节点成为新的主节点的从节点
4）Sentinel节点集合会将原来的主节点更新为从节点，并保持着对其关注，当其恢复后命令它去复制新的主节点
1.实验环境 （首先搭建好Redis环境并可以进行主从同步）
系统版本：rhel6.5
server3:172.25.254.103 redis-slave
server4:172.25.254.104 redis-slave
server2:172.25.254.101 redis-master
2.主节点操作
1）在安装包中将 sentinel 文件复制到/etc/redis/下
[root@server2 ~]# cd redis-4.0.1 [root@server2 redis-4.0.1]# cp sentinel.conf /etc/redis/ [root@server2 redis-4.0.1]# cd /etc/redis/
2)修改配置文件 [root@server2 redis]# vim sentinel.conf
关闭保护模式
第98 行 Sentinel 去监视一个名为 mymaster 的主服务器, 这个主服务器的IP 地址为 172.25.154.101,端口号为 6379 ,而将这个主服务器判断为失效至少需要 2 个 Sentinel 同意 (只要同意 Sentinel 的数量不达标,自动故障迁移就不会执行) 如：
sentinel monitor mymaster 172.25.254.101 6379 2
3）将配置好的文件发送给所有从节点
[root@server2 redis]# scp sentinel.conf root@172.25.254.102:/etc/redis/ sentinel.conf 100% 7609 7.4KB/s 00:00 [root@server2 redis]# scp sentinel.conf root@172.25.254.104:/etc/redis/ sentinel.conf 100% 7609 7.4KB/s 00:00
4）三台redis 开启 sentinel 服务
[root@server2 redis]# redis-sentinel /etc/redis/sentinel.conf
两台slave [root@server3 ~]# redis-sentinel /etc/redis/sentinel.conf
[root@server4 ~]# redis-sentinel /etc/redis/sentinel.conf
+slave 表示 :一个新的从服务器已经被 Sentinel 识别并关联 可以看到片此时 master 是 server2;server3和 server4 是 slave。
3.测试
1)停掉现在的Redis-master info 查看 replication 信息
[root@server2 ~]# redis-cli -p 26379 127.0.0.1:26379> info master0:name=mymaster,status=ok,address=172.25.254.101:6379,slaves=2,sentinels=3[root@server2 ~]# redis-cli 127.0.0.1:6379> SHUTDOWN not connected> [root@server2 ~]# redis-cli Could not connect to Redis at 127.0.0.1:6379: Connection refused Could not connect to Redis at 127.0.0.1:6379: Connection refused not connected> [root@server2 ~]# redis-cli -p 26379 127.0.0.1:26379> info master0:name=mymaster,status=ok,address=172.25.254.102:6379,slaves=2,sentinels=3 127.0.0.1:26379>
2)查看任意一台redis主机的监控日志
[root@server4 ~]# redis-sentinel /etc/redis/sentinel.conf
+switch-master :配置变更,主服务器的 IP 和地址已经改变 由之前的172.25.254.101 更改为172.25.254.102。+sdown :给定的实例 server2现在处于主观下线状态。 在原先的master被停掉后，通过选举产生新的master 172.25.254.102 6379
实际现在只有一个slave 可以使用
四、Redis Cluster（集群）下的高可用
实现原理：
主观下线
集群中每个节点都会定期向其他节点发送ping消息，接受节点回复ping消息作为响应。如果在cluster-node-timeout时间内通信一直失败，则发送节点会认为接收节点存在故障，把接受节点标记为主观下线(pfail)状态。
客观下线
1)当某个节点判断另一个节点主观下线后，相应的节点状态会跟随消息在集群内传播。
2)假设节点a标记节点b为主观下线，一段时间后节点a通过消息把节点b的状态发送到其他节点，当其他节点收到消息并解析出消息体中含有b的pfail状态，把节点b加入下线报告链表；
3)当某一节点c收到节点b的pfail状态时，此时有超过一半的槽主节点都标记了节点b为pfail状态时，则标记故障节点b为客观下线；
4)向集群广播一条pfail消息，通知集群内的所有节点标记故障节点b为客观下线状态并立刻生效，同时通知故障节点b的从节点触发故障转移流程。
故障恢复
1)资格检查
若从节点与主节点断线时间超过一定时间，则不具备资格 2)准备选举时间
当从节点符合故障转移资格后，要等待一段选举时间后才开始选举
在故障节点的所有从节点中，复制偏移量最大的那个从节点最先开始（与主节点的数据最一致）进行选举，然后是次大的节点开始选举.....剩下其余的从节点等待到它们的选举时间到达后再进行选举 3)发起选举 4)选举投票
只有持有槽的主节点才具有一张唯一的选票，从从节点收集到N/2 + 1个持有槽的主节点投票时，从节点可以执行替换主节点操作 5)替换主节点
当从节点收集到足够的选票之后，触发替换主节点操作
当前从节点取消复制变为主节点撤销故障主节点负责的槽，并把这些槽委派给自己向集群广播自己的pong消息，通知集群内所有的节点当前从节点变为主节点并接管了故障主节点的槽信息
1.实验环境：
使用任意一台redis 主机
2.部署高可用
1）搭建环境
[root@server2 redis]# /etc/init.d/redis_6379 stop
cd /usr/local/ mkdir cluster ##建立集群目录
[root@server2 local]# cd cluster/ [root@server2 cluster]# pwd /usr/local/cluster [root@server2 cluster]# mkdir 700{1..6} [root@server2 cluster]# ll total 24 drwxr-xr-x 2 root root 4096 Oct 9 11:02 7001 drwxr-xr-x 2 root root 4096 Oct 9 11:02 7002 drwxr-xr-x 2 root root 4096 Oct 9 11:02 7003 drwxr-xr-x 2 root root 4096 Oct 9 11:02 7004 drwxr-xr-x 2 root root 4096 Oct 9 11:02 7005 drwxr-xr-x 2 root root 4096 Oct 9 11:02 7006 [root@server2 cluster]# cd 7001/
[root@server2 7001]# vim redis.conf [root@server2 ~]# cat /usr/local/cluster/7001/redis.conf port 7001 cluster-enabled yes #打开集群设备
cluster-config-file nodes.conf cluster-node-timeout 5000 #延时时间 appendonly yes daemonize yes
pidfile /usr/local/cluster/7001/redis.pid ##pid文件存放目录
logfile /usr/local/cluster/7001/redis.log ##日志存放目录
[root@server2 7001]# redis-server redis.conf ###打开集群服务
[root@server2 cluster]# cp 7001/redis.conf 7002/ [root@server2 cluster]# cp 7001/redis.conf 7003/ [root@server2 cluster]# cp 7001/redis.conf 7004/ [root@server2 cluster]# cp 7001/redis.conf 7005/ [root@server2 cluster]# cp 7001/redis.conf 7006/
[root@server2 cluster]# cd 7002/
[root@server2 7002]# vim redis.conf ###将文件中的端口号改为7002和存放目录的更改
redis-server redis.conf ###打开集群的redis
cd ..
cd 7003/ vim redis.conf ###将文件中的端口号改为7003和存放目录的更改
redis-server redis.conf ###打开集群的redis
cd ..
cd 7004/ vim redis.conf ###将文件中的端口号改为7004和存放目录的更改
redis-server redis.conf ###打开集群的redis
cd ..
cd 7005/
vim redis.conf ###将文件中的端口号改为7005和存放目录的更改
redis-server redis.conf ###打开集群的redis
cd ..
cd 7006/ vim redis.conf ###将文件中的端口号改为7006和存放目录的更改
redis-server redis.conf ###打开集群的redisps ax ##查看进程是否都打开了netstat -antlp ##查看端口号是否开启
[root@server2 ~]# cd redis-4.0.1 [root@server2 redis-4.0.1]# cd src/ [root@server2 src]# cp redis-trib.rb /usr/local/bin/ [root@server2 src]# yum install -y ruby [root@server2 ~]# yum install -y rubygems-1.3.7-5.el6.noarch.rpm
[root@server2 ~]# rpm -Uvh ruby-2.2.3-1.el6.x86_64.rpm [root@server2 ~]# yum install -y ruby-2.2.3-1.el6.x86_64.rpm libyaml-0.1.3-4.el6_6.x86_64.rpm [root@server2 ~]# gem install --local redis-4.0.1.gem
2）创建集群
[root@server2 ~]# redis-trib.rb create --replicas 1 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 127.0.0.1:7006
[root@server2 ~]# redis-cli -c -p 7001 127.0.0.1:7001> set name linux -> Redirected to slot [5798] located at 127.0.0.1:7002 OK 127.0.0.1:7002>
[root@server2 ~]# redis-cli -c -p 7006 127.0.0.1:7006> set name kb -> Redirected to slot [5798] located at 127.0.0.1:7002 OK 127.0.0.1:7002> get name "kb" 127.0.0.1:7002>
redis-cli -c -p 7001登录，set name linux 写入内容，会提示写入内容传到2上redis-cli -c -p 7002
输入info，发现2是master,他的slave是6
3）测试
停掉master 2
[root@server2 ~]# redis-cli -c -p 7002 127.0.0.1:7002> SHUTDOWN not connected>
redis-trib.rb check 127.0.0.1:7001 ##查看集群的状态
可以查看之前的内容
[root@server2 ~]# redis-cli -c -p 7001 127.0.0.1:7001> get name -> Redirected to slot [5798] located at 127.0.0.1:7005 "kb" 127.0.0.1:7005>
再关掉一个master
[root@server2 ~]# redis-cli -c -p 7005 127.0.0.1:7005> SHUTDOWN not connected>
查看信息
关闭掉两个master后,集群的功能会破坏
[root@server2 ~]# redis-cli -c -p 7001 127.0.0.1:7001> get name (error) CLUSTERDOWN The cluster is down 127.0.0.1:7001>
4）恢复关闭的两个节点
[root@server2 ~]# cd /usr/local/cluster/ [root@server2 cluster]# ls 7001 7002 7003 7004 7005 7006 [root@server2 cluster]# cd 7002 [root@server2 7002]# redis-server redis.conf 1292:C 09 Oct 11:40:46.513 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo 1292:C 09 Oct 11:40:46.513 # Redis version=4.0.1, bits=64, commit=00000000, modified=0, pid=1292, just started 1292:C 09 Oct 11:40:46.513 # Configuration loaded [root@server2 7002]# cd .. [root@server2 cluster]# cd 7005 [root@server2 7005]# redis-server redis.conf 1298:C 09 Oct 11:41:15.609 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo 1298:C 09 Oct 11:41:15.609 # Redis version=4.0.1, bits=64, commit=00000000, modified=0, pid=1298, just started 1298:C 09 Oct 11:41:15.609 # Configuration loaded
高可用搭建成功
白小黑..
关注
关注
59
点赞
348
收藏
打赏
10
评论
Redis 的主从同步，及两种高可用方式
一、Redis 介绍Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。Redis 是一个高性能的k...
复制链接
扫一扫
10步实现Redis主从复制（Redis）
weixin_48629371的博客
02-18
1140
一、Redis实现主从复制
概念（了解才能方便实操）：
主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master)，后者称为从节点(slave)；数据的复制是单向的，只能由主节点到从节点。
主从复制的作用主要包括：
数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务.
Redis的主从复制与故障切换
luxunlx123的博客
11-08
82
redis简介：
redis是一个key-value存储系统。和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash（哈希类型）。
这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，redis支持...
评论 10
您还未登录，请先
登录
后发表或查看评论
redis主从配置以及哨兵模式配置
03-30
详细的描述了redis的配置，以及哨兵sentinel模式的配置以及使用，很实用！
Redis 主从同步实现过程
最新发布
流楚丶格念的博客
10-26
69
与MySQL主从复制的原因一样，Redis虽然读写的速度非常快，但是当读请求较多时也会产生较大的压力，为了分担读Redis的压力，Redis支持了主从复制的架构，从节点可以分担主节点的读压力。Redis的主从复制可以根据是否是全量，分为全量同步和增量同步（也叫全量复制和部分复制）。全量复制一般用于初次复制的场景部分复制则用于处理因网络中断等原因造成数据丢失的场景。
Redis：主从同步保持数据一致
ghw15221836342的博客
06-01
1174
Redis：主从同步保持数据一致CAP原理Redis主从同步主从库的第一次同步主从全量复制时主库的压力主从库间网络断开连接？参考文献
在实际的业务开发中，很多公司都没有使用集群，但是都采用了主从同步，当master 挂掉的时候，运维让从库过来接管，服务就可以继续，否则 master 需要经过数据恢复和重启的过程，这就可能会拖很长的时间，影响线上业务的持续服务。
Redis如果发生了宕机，我们可以通过AOF日志和RDB文件的形式恢复数据，从而保证尽量少丢失数据来提升可靠性。但是如果服务本身不可用，在其恢复期间
Redis主从同步（详解+图）
qq_45748269的博客
11-29
3322
目录
redis主从同步（解决并发能力问题）
全量同步
master如何判断一个slave是否是第一次同步？
全量同步过程
增量同步
增量同步过程
repl_baklog原理
可以从以下几个方面来优化Redis主从就集群：
全量同步和增量同步区别？
什么时候执行全量同步？
什么时候执行增量同步？
redis主从同步（解决并发能力问题）
假设有A、B两个实例，如何让B作为A的slave节点？
在B节点执行命令：slaveof A的IP A的端口
全量同步
主...
差点崩溃了，还好有主从复制！
公众号：该用户快成仙了
10-14
174
我已经给大家图解了 AOF 和 RDB，这两个持久化技术保证了即使在服务器重启的情况下也不会丢失数据（或少量损失）。
不过，由于数据都是存储在一台服务器上，如果出事就完犊子了，比如：
如果服务器发生了宕机，由于数据恢复是需要点时间，那么这个期间是无法服务新的请求的；
如果这台服务器的硬盘出现了故障，可能数据就都丢失了。
要避免这种单点故障，最好的办法是将数据备份到其他服务器上，让这些服务器也可以对外提供服务，这样即使有一台服务器出现了故障，其他服务器依然可以继续提供服务。
多台服务器要保存同
Redis原理剖析视频
黎程雨的博客
02-21
621
互联网高并发系列：教你实现Redis高可用和剖析原理
1.Redis Sentinel（哨兵）架构下的高可用
Redis的主从复制下，一旦主节点由于故障不能提供服务，需要人工将从节点晋升为主节点，同时还要通知应用方更新主节点地址，对于很多应用场景这种故障处理的方法是无法接受的。可喜的是Redis从2.8开始正式提供了Redis Sentinel（哨兵）架构来解决这个问题。
Redis Sentin...
Redis搭建主从复制实现高可用
A-乐
11-27
507
高可用 HA（High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。
假设系统一直能够提供服务，我们说系统的可用性是 100%。如果系统每运行 100 个时间单位，会有 1 个时间单位无法提供服务，我们说系统的可用性是 99%。很多公司的高可用目标是 4 个 9，也就是 99.99%，这就意味着，系统的年停机时间为 8.76 个小时。
那么如何保证系统的高可用呢
首先，在整个架构的每个节点中，不允许存在单点问题，因为单点一定是高可用最大
Redis（主从、哨兵、集群）
weixin_49051298的博客
04-25
2957
一、Redis集群介绍
1.主从复制：
是高可用Redis的基础，哨兵和集群都是在主从复制基础上实现高可用的。主从复制主要实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复。缺陷：故障恢复无法自动化；写操作无法负载均衡；存储能力受到单机的限制。
2.哨兵：
在主从复制的基础上，哨兵实现了自动化的故障恢复。缺陷：写操作无法负载均衡；存储能力受到单机的限制；哨兵无法对从节点进行自动故障转移，在读写分离场景下，从节点故障会导致读服务不可用，需要对从节点做额外的监控、切换操作。
3.集群：
通过集群，R
Redis之主从同步
cainiao1412的博客
12-25
3070
为什么需要主从同步
生产环境中，如果redis只有一台机器是一件很危险的事情，如果出现机器宕机服务将处于不可用状态，此时需要对挂掉的节点进行重启和等待数据恢复后，服务方可继续对外使用，
如果有了主从以后，当主节点挂掉后，运维将从节点升级为主节点即可继续对外提供服务，可以省去中间的恢复原本主节点的时间，提高了可用性。
CAP 与 最终一致
CAP是分布式系统的理论基石，C 代表 一致性 (Consistent)、A 代表 可用性 (Availability) 、P (Partition toleran
Redis 主从同步
Chlapis的博客
08-18
380
单点部署的服务无论服务本身设计的多完美，只要服务所在的机器宕掉了，都是白扯。
在要求高可用性的系统设计上，都会遵守一个核心准则：冗余。
也就是说某个节点挂掉后，还有其他节点可以继续提供服务。
对 存储系统 设计冗余要考虑如何保证 数据的一致性（所有节点的数据要一致）。...
Redis-主从同步详解
qq_46127735的博客
03-01
1827
Redis-主从复制详解
尽管Redis服务器性能很好，但是对于一些热门网站（比如淘宝双十一的时候），就会有成千上万的用户进入主页，同时也伴随着大量的读操作到达Redis服务器，触发一系列操作，每当这个时候，单靠一台Redis服务器，显示是满足不了需求的。
而我们Redis主从复制就很好的解决了这个问题
1、概念
主从复制，主机数据更新后根据配置和策略，
自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主。数据的复制是单向的，只能由主服务器到从服务器。
（个人练
Redis的主从架构
weixin_56503821的博客
08-08
246
这里写自定义目录标题欢迎使用Markdown编辑器新的改变功能快捷键合理的创建标题，有助于目录的生成如何改变文本的样式插入链接与图片如何插入一段漂亮的代码片生成一个适合你的列表创建一个表格设定内容居中、居左、居右SmartyPants创建一个自定义列表如何创建一个注脚注释也是必不可少的KaTeX数学公式新的甘特图功能，丰富你的文章UML 图表FLowchart流程图导出与导入导出导入
欢迎使用Markdown编辑器
你好！ 这是你第一次使用 Markdown编辑器 所展示的欢迎页。如果你想学习如何使用Mar
redis的主从同步原理及其配置
weixin_41763922的博客
07-20
465
主从同步的原理
Redis——Redis主从复制（工作流程详解）
热门推荐
Cantevenl的博客
04-19
2万+
Redis主从复制主从复制简介主从复制的概念主从复制的作用主从复制工作流程阶段一：建立连接阶段主从连接（slave连接master）第一种方式第二种方式第三种方式授权访问阶段二：数据同步阶段工作流程数据同步阶段master说明数据同步阶段slave说明阶段三：命令传播阶段命令传播阶段的部分复制服务器的运行 id复制缓冲区复制缓冲区内部工作原理复制缓冲区主从服务器复制偏移量（offset）数据同步+命令传播阶段工作流程心跳机制心跳阶段注意事项主从复制常见问题引发频繁的全量复制1引发频繁的全量复制2频繁的网络中
分布式缓存-Redis 主从
dingd1234的博客
05-15
292
一、搭建主从架构
单节点 Redis 的并发能力是有上限的，要进一步提高 Redis 的并发能力，就需要搭建主从集群，实现读写分离。
在 Redis 应用当中，大多数情况下，都是读多写少，因此，更多情况下，需要应对的是读的压力，那么在主从的基础上可进一步实现读写分离：在执行写操作时，访问 master 节点，如果是读操作，那么就分发到 slave 节点。这种一主多从的集群设计，可让多个从节点共同承担读的请求，从而使得读的并发能力就会有极大地提升。
...
Redis 主从数据同步
skystep的博客
07-01
1357
redis 从节点第一次连接主节点采用的是全量同步，包括两个阶段：
第一阶段：第二阶段：全量同步过程有一个问题：主节点如何判断一个从节点是第一次同步数据？实际上每一个 redis 节点都会有一个 replication id ，称为数据集ID。从节点第一次请求主节点，会带上 replication id，主节点收到从节点 replication id，和自己的 replication id 对比，如果不相同说明是第一次请求同步数据，主节点将自己的 replication id 发送给从节点，从节点存储主节点
Redis学习笔记---Redis的主从复制
qq_39314972的博客
01-31
483
Redis学习笔记—Redis的主从复制
1.Redis的高可用性
高可用性（High Availability）通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。
Reids保证的是分布式理论中CAP的A，并且Redis是AP模型
但是单机的Redis是无法保证高可用性的，当Redis服务器宕机后，即使在有持久化的机制下也无法保证不丢失数据，所以我们采用Redis多机和集群的方式来保证Redis的高可用性。
单进程+单线程 + 多机 （集群）
2.Redis主从复制介绍
Redis数据同步机制
iflink
01-11
3158
Redis的主从同步机制可以确保redis的master和slave之间的数据同步。按照同步内容的多少可以分为全同步和部分同步；按照同步的时机可以分为slave刚启动时的初始化同步和正常运行过程中的数据修改同步。...
Redis主从模式
FYHannnnnn的博客
11-20
785
一，Redis主从配置
Redis高可用集群中，主节点的无需做什么集群配置，只需在从节点中开启主节点配置
replicaof ip port
如同传统的数据库集群一样，Redis集群一样采用了主写从读的结构，从而达到读写分离的作用
<一主多从，主从同步，主负责写，从负责读，提升Redis的性能和吞吐量，主从的数据一致性问题>
因为Redis是内存数据库，主从架构还能有效的防止容灾的发生：从机是主机的备份，主机宕机，从机可读不可写，默认情况下主机宕机后，从机不可为主机，利用哨兵可以实现
“相关推荐”对你有帮助么？
非常没帮助
没帮助
一般
有帮助
非常有帮助
提交
©️2022 CSDN
皮肤主题：创作都市
设计师：CSDN官方博客
返回首页
白小黑..
CSDN认证博客专家
CSDN认证企业博客
码龄4年
暂无认证
54
原创
61万+
周排名
30万+
总排名
49万+
访问
等级
1555
积分
120
粉丝
201
获赞
25
评论
1088
收藏
私信
关注
热门文章
Redis 的主从同步，及两种高可用方式
214636
python中变量的命名以及使用
117251
linux中用户对文件的权限
61013
python 的基本语句
52893
系统的日志管理
14526
分类专栏
数据库
oracle
1篇
zabbix
python
9篇
liunx基础
2篇
liunx相关服务部署
最新评论
python中变量的命名以及使用
小号@wx:
python 的基本语句
keshfe:
python的累加和VBA有很大的不同
Linux 中的 iptables 配置
阿莫惜霖:
iptables -F 是刷新吗？？？？？
Redis 的主从同步，及两种高可用方式
我叫城北徐公:
我感觉master异步同步到slave
python中变量的命名以及使用
博学载医:
有错的哦
您愿意向朋友推荐“博客详情页”吗？
强烈不推荐
不推荐
一般般
推荐
强烈推荐
提交
最新文章
Orace 监听异常处理
MHA+mysql实现高可用
SaltStack自动化部署keepalived实现haproxy高可用
2020年1篇
2018年53篇
目录
目录
分类专栏
数据库
oracle
1篇
zabbix
python
9篇
liunx基础
2篇
liunx相关服务部署
目录
评论 10
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
查看更多评论
打赏作者
白小黑..
你的鼓励将是我创作的最大动力
¥2
¥4
¥6
¥10
¥20
输入1-500的整数
余额支付
(余额：-- )
扫码支付
扫码支付：¥2
获取中
扫码支付
您的余额不足，请更换扫码支付或充值
打赏作者
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额
抵扣说明：
1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。 2.余额无法直接购买下载，可以购买VIP、C币套餐、付费专栏及课程。
余额充值