AI 助理
备案控制台
开发者社区 数据库 文章 正文

Redis高可用之主从复制实践（四）

2019-01-08 946
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
云数据库 Tair（兼容Redis），内存型 2GB
推荐场景：
通过缓存加速数据库访问
Redis 开源版，标准版 2GB
推荐场景：
搭建游戏排行榜
日志服务 SLS，月写入数据量 50GB 1个月
简介： 0、Redis目录结构      1）Redis介绍及部署在CentOS7上（一）      2）Redis指令与数据结构（二）      3）Redis客户端连接以及持久化数据（三）      4）Redis高可用之主从复制实践（四）      5）Redis高可用之哨兵模式Sentinel配置与启动（五）      6）Redis高可用之集群配置（六） 一、介绍1、Redis的高可用有如下几个部分组成：第一部分：redis主从复制第二部分：Sentinel哨兵模式第三部分：集群部署本篇将介绍第一部分-redis 主从复制。

0、Redis目录结构

      1）Redis介绍及部署在CentOS7上（一）

      2）Redis指令与数据结构（二）

      3）Redis客户端连接以及持久化数据（三）

      4）Redis高可用之主从复制实践（四）

      5）Redis高可用之哨兵模式Sentinel配置与启动（五）

      6）Redis高可用之集群配置（六）

 

一、介绍

1、Redis的高可用有如下几个部分组成：

第一部分：redis主从复制

第二部分：Sentinel哨兵模式

第三部分：集群部署

本篇将介绍第一部分-redis 主从复制。那么问题来了，为什么需要主从复制呢？

 

2、为什么需要主从复制呢？

从以下三点说明：

A、redis单机一旦故障，可用通过从服务器上进行恢复数据；

B、redis要达到高可用、高并发，只有单个redis是不够的，单个redis也就只能支持几万的QPS，所以必须以集群的形式提供服务，而集群中又以多个主从组成。

C、主从是以多个redis集合在一起，以一个master多个slave为模式对外提供服务，master主要以写为主，slave提供读，即是读写分离的情况，以读多写少为准。比如电商网站中的商品，读的多，写的少。

 

如果上面三点还不懂，没关系，我说明一下 单机redis 的问题：

A、机器故障

B、容量瓶颈

C、QPS瓶颈

这个也是我们在互联网产品中经常会遇到的问题。

 

3、那么主从复制的原理是什么呢？

上面已经说明了为什么需要主从复制，那么其内部的原理是什么呢？我在最下面配置的时候也通过了日志来解释这一切

主要分为全量同步和增量同步

A、 全量同步
　　Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份。具体步骤如下： 
　　1）从服务器连接主服务器，发送SYNC命令； 
　　2）主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令； 
　　3）主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令； 
　　4）从服务器收到快照文件后丢弃所有旧数据，载入收到的快照； 
　　5）主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令； 
　　6）从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令； 
 
 
完成上面几个步骤后就完成了从服务器数据初始化的所有操作，从服务器此时可以接收来自用户的读请求。
 
B、增量同步
　　Redis增量复制是指Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。 
增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令。
 
C、Redis主从同步策略
　　主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。当然，如果有需要，slave 在任何时候都可以发起全量同步。redis 策略是，无论如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步。

 

4、主从复制的特性是什么呢？

     1) 一个master可以有多个slave；

     2) 一个slave只能有一个master；

     3) 数据流是单向的,master到slave；

     4) 主从复制底层依赖与RDB方式进行全量复制。

注意说明：

针对与RDB方式保存有分为 save 和 bgsave 命令，两者的区别在于save为同步保存，即存在阻塞；而bgsave为异步保存，非阻塞。

在上面原理中有给出redis主从复制采用的是bgsave的方式，如若不清楚也可以看下面log日志中的内容。

 

二、Redis主从复制

1、环境配置

第一：准备3台服务器，一台master ，两台 slave

主机说明 主机IP 端口
master

192.168.250.132

 

7000
slave　 192.168.250.133 7001
slave　　

192.168.250.134

7002

第二：每台服务器安装redis版本保持一致

安装教程传送门：《Redis介绍及部署在CentOS7上（一）》

环境都准备完毕，现在就可以开始配置啦。

 

2、Redis主从复制配置

第一：进入132 服务器的redis目录下

新建一个redis配置文件，以下内容大家可自行扩展，这边说明一点就是数据持久化我这边采用AOF，这也是官方推荐的，效率高，而且持久化是必须的，如果没有持久化则数据容易丢失。如果想了解redis的持久化，可以看我另外一篇文章《Redis客户端连接及持久化配置（三）》。

文件名 redis-7000.conf

daemonize yes
port 7000
logfile 7000.log
dir ./
requirepass 123
masterauth 123 # 132服务器配置masterauth作用主要是为了后期sentinel引入后重新选举master并且7000端口redis重新加入主从复制时必备的，否则会出现权限不足
bind 192.168.250.132 127.0.0.1

# AOF 数据持久化
appendonly yes
appendfilename aof-7000.aof
appendfsync everysec
no-appendfsync-on-rewrite yes
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

注意说明：为了安全

A、需要设置密码，密码必须复杂；

B、设置bind 的IP地址，此IP为redis服务器IP以及本地127，如果没有设置 127，会出现无法启动问题，没有设置服务器IP会出现slave服务器无法连接master服务器。 

第二：进入 133和134的服务器的redis目录下

新建redis配置文件, 133服务器为 redis-7001.conf ,134 服务器为redis-7002.conf

 

port 7001
daemonize yes
logfile 7001.log
dir ./
requirepass 123
slaveof 192.168.250.132 7000
masterauth 123
bind 192.168.250.133 127.0.0.1

# AOF 数据持久化
appendonly yes
appendfilename aof-7001.aof
appendfsync everysec
no-appendfsync-on-rewrite yes
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

注意说明：

A、slaveof  后面绑定的是master 服务器IP 和端口

B、需要设置master的密码，否则在连接的时候会报 权限不足

C、设置slave 服务器的密码强烈建议与master服务器上的密码一致，因为这样在后面的哨兵模式自动选出主服务器有很大的帮助，否则会报错。

D、134服务器跟上面的配置一致，只是端口号不一样。

 

配置完毕

 

第三：启动132、133、134的redis

./src/redis-server redis-7000.conf
./src/redis-server redis-7001.conf
./src/redis-server redis-7002.conf

 

我们来通过日志分析一下，redis主从复制启动的过程是怎么样的吧。

我们从132master服务器的 7000.log 日志来进行讲解。

说明：建议大家自行操作然后对照着下面的说明，有助于大家理解。

A、132启动，然后133redis启动会开始请求与133redis进行连接与数据同步，当134启动也会进行数据同步；

B、并且同步的数据会默认保存在 dump.rdb 这个文件中，建议自行配置持久化方式，传送门《Redis客户端连接及持久化配置（三）》此处文章预计本周五之前发布；

C、然后 把134 redis 关闭，又重新启动，然后132master服务器redis 关闭有启动的一系列操作。

==================132redis启动================================================
103398:C 08 Jan 2019 17:42:20.481 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
103398:C 08 Jan 2019 17:42:20.481 # Redis version=5.0.2, bits=64, commit=00000000, modified=0, pid=103398, just started
103398:C 08 Jan 2019 17:42:20.481 # Configuration loaded
103399:M 08 Jan 2019 17:42:20.482 * Increased maximum number of open files to 10032 (it was originally set to 1024).
103399:M 08 Jan 2019 17:42:20.483 * Running mode=standalone, port=7000.
103399:M 08 Jan 2019 17:42:20.483 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
103399:M 08 Jan 2019 17:42:20.483 # Server initialized
103399:M 08 Jan 2019 17:42:20.483 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
103399:M 08 Jan 2019 17:42:20.483 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.
103399:M 08 Jan 2019 17:42:20.483 * Ready to accept connections

==================133redis启动开始请求同步======================================
103399:M 08 Jan 2019 17:44:56.213 * Replica 192.168.250.133:7001 asks for synchronization
103399:M 08 Jan 2019 17:44:56.213 * Full resync requested by replica 192.168.250.133:7001

# 主从复制 默认 RDB 持久化
103399:M 08 Jan 2019 17:44:56.213 * Starting BGSAVE for SYNC with target: disk
103399:M 08 Jan 2019 17:44:56.214 * Background saving started by pid 103768
103768:C 08 Jan 2019 17:44:56.216 * DB saved on disk
103768:C 08 Jan 2019 17:44:56.216 * RDB: 4 MB of memory used by copy-on-write
103399:M 08 Jan 2019 17:44:56.299 * Background saving terminated with success

# 133 redis 数据同步成功
103399:M 08 Jan 2019 17:44:56.299 * Synchronization with replica 192.168.250.133:7001 succeeded

==================134redis启动开始请求同步=======================================
103399:M 08 Jan 2019 17:45:25.389 * Replica 192.168.250.134:7002 asks for synchronization
103399:M 08 Jan 2019 17:45:25.389 * Full resync requested by replica 192.168.250.134:7002

# 主从复制 默认 RDB 持久化
103399:M 08 Jan 2019 17:45:25.389 * Starting BGSAVE for SYNC with target: disk
103399:M 08 Jan 2019 17:45:25.390 * Background saving started by pid 103858
103858:C 08 Jan 2019 17:45:25.391 * DB saved on disk
103858:C 08 Jan 2019 17:45:25.392 * RDB: 4 MB of memory used by copy-on-write
103399:M 08 Jan 2019 17:45:25.402 * Background saving terminated with success

# 133 redis 数据同步成功
103399:M 08 Jan 2019 17:45:25.402 * Synchronization with replica 192.168.250.134:7002 succeeded

==================134redis关闭日志===============================================
103399:M 08 Jan 2019 17:51:13.850 # Connection with replica 192.168.250.134:7002 lost.

==================134redis重新启动日志============================================
103399:M 08 Jan 2019 17:52:28.885 * Replica 192.168.250.134:7002 asks for synchronization
103399:M 08 Jan 2019 17:52:28.885 * Partial resynchronization request from 192.168.250.134:7002 accepted. Sending 588 bytes of backlog starting from offset 43.


==================132redis强制关闭================================================
103399:M 08 Jan 2019 17:54:06.369 # User requested shutdown...
103399:M 08 Jan 2019 17:54:06.369 * Removing the pid file.
103399:M 08 Jan 2019 17:54:06.369 # Redis is now ready to exit, bye bye...

==================132redis 主服务器再次上线，同步数据以及连接slave服务器===============
105223:M 08 Jan 2019 17:54:47.189 * Background saving terminated with success
105223:M 08 Jan 2019 17:54:47.189 * Synchronization with replica 192.168.250.133:7001 succeeded
105223:M 08 Jan 2019 17:54:47.807 * Replica 192.168.250.134:7002 asks for synchronization
105223:M 08 Jan 2019 17:54:47.807 * Partial resynchronization not accepted: Replication ID mismatch (Replica asked for 'd0ff33789382fccfe621d9ad03c26cc545bda3fa', my replication IDs are '00591a20c6cafe8f906632746d514e99213ee121' and '0000000000000000000000000000000000000000')
105223:M 08 Jan 2019 17:54:47.807 * Starting BGSAVE for SYNC with target: disk
105223:M 08 Jan 2019 17:54:47.808 * Background saving started by pid 105229
105229:C 08 Jan 2019 17:54:47.809 * DB saved on disk
105229:C 08 Jan 2019 17:54:47.809 * RDB: 4 MB of memory used by copy-on-write
105223:M 08 Jan 2019 17:54:47.894 * Background saving terminated with success
105223:M 08 Jan 2019 17:54:47.894 * Synchronization with replica 192.168.250.134:7002 succeeded

 

三、总结

1、slave服务器上面的数据都是从master服务器上同步的，一旦master挂掉，则slave服务器无法进行增量同步，假设某项目使用了slave服务器进行写的操作，当master服务器开启后，slave服务器会进行与master服务器进行

全量同步，这样导致原先保存在slave上的数据丢失，当然这个例子是假设，一般slave只当做读的操作。

2、如果master宕机后，如何保证redis还可以正常使用呢？则我们就需要引入Sentinel进行master的选择啦。

3、通过以上的日志分析，我们基本上已经明白redis的主从复制啦。那么下一篇将会介绍 当redis 挂掉后自动选举 主redis的哨兵模式Sentinel。

 

参考文章：

《Redis主从复制原理总结》：https://www.cnblogs.com/kevingrace/p/5685332.html

《Redis主从复制原理》：https://www.cnblogs.com/hepingqingfeng/p/7263782.html

 

asp.net core 交流群：787464275 欢迎加群交流
如果您认为这篇文章还不错或者有所收获，您可以点击右下角的【推荐】按钮精神支持，因为这种支持是我继续写作，分享的最大动力！

作者：LouieGuo
声明：原创博客请在转载时保留原文链接或者在文章开头加上本人博客地址，如发现错误，欢迎批评指正。凡是转载于本人的文章，不能设置打赏功能，如有特殊需求请与本人联系！

微信公众号：欢迎关注                                                 QQ技术交流群： 欢迎加群

                

LouieGuo
文章标签：
云数据库 Tair（兼容 Redis）
日志服务
NoSQL
Redis
数据安全/隐私保护
Sentinel
关键词：
云数据库 Tair（兼容 Redis）实践
云数据库 Tair（兼容 Redis）高可用
云数据库 Tair（兼容 Redis）高可用主从复制
云数据库 Tair（兼容 Redis）主从复制
云数据库 Tair（兼容 Redis）高可用实践
相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务，基于高可靠双机热备架构及可无缝扩展的集群架构，满足高读写性能场景及容量需弹性变配的业务需求。 产品详情：https://www.aliyun.com/product/kvstore     ------------------------------------------------------------------------- 阿里云数据库体验：数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库 ECS 实例和一台目标数据库 RDS实例。跟着指引，您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接，领取免费ECS&RDS资源，30分钟完成数据库上云实战！https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
LouieGuo
目录
相关文章
qa浪涛
|
1月前
|
存储 缓存 NoSQL
深入理解Django与Redis的集成实践
深入理解Django与Redis的集成实践
qa浪涛
53 0
FeelTouchLabs
|
3月前
|
NoSQL Redis
基于Redis的高可用分布式锁——RedLock
这篇文章介绍了基于Redis的高可用分布式锁RedLock的概念、工作流程、获取和释放锁的方法，以及RedLock相比单机锁在高可用性上的优势，同时指出了其在某些特殊场景下的不足，并提到了ZooKeeper作为另一种实现分布式锁的方案。
FeelTouchLabs
106 2
基于Redis的高可用分布式锁——RedLock
qhhf_地道酬勤
|
4月前
|
存储 缓存 NoSQL
Redis常见面试题（二）:redis分布式锁、redisson、主从一致性、Redlock红锁；Redis集群、主从复制，哨兵模式，分片集群；Redis为什么这么快，I/O多路复用模型
redis分布式锁、redisson、可重入、主从一致性、WatchDog、Redlock红锁、zookeeper；Redis集群、主从复制，全量同步、增量同步；哨兵，分片集群，Redis为什么这么快，I/O多路复用模型——用户空间和内核空间、阻塞IO、非阻塞IO、IO多路复用，Redis网络模型
qhhf_地道酬勤
1289 4
Redis常见面试题（二）:redis分布式锁、redisson、主从一致性、Redlock红锁；Redis集群、主从复制，哨兵模式，分片集群；Redis为什么这么快，I/O多路复用模型
香吧香
|
4月前
|
监控 NoSQL Redis
Redis 哨兵模式高可用
Redis 哨兵模式高可用
香吧香
85 4
喵帕斯先生
|
13天前
|
缓存 NoSQL Redis
Redis 缓存使用的实践
《Redis缓存最佳实践指南》涵盖缓存更新策略、缓存击穿防护、大key处理和性能优化。包括Cache Aside Pattern、Write Through、分布式锁、大key拆分和批量操作等技术，帮助你在项目中高效使用Redis缓存。
喵帕斯先生
81 22
最好zzz
|
19天前
|
NoSQL 关系型数据库 MySQL
MySQL与Redis协同作战：百万级数据统计优化实践
【10月更文挑战第21天】 在处理大规模数据集时，传统的单体数据库解决方案往往力不从心。MySQL和Redis的组合提供了一种高效的解决方案，通过将数据库操作与高速缓存相结合，可以显著提升数据处理的性能。本文将分享一次实际的优化案例，探讨如何利用MySQL和Redis共同实现百万级数据统计的优化。
最好zzz
51 9
武子康
|
1月前
|
存储 NoSQL 大数据
大数据-51 Redis 高可用方案CAP-AP 主从复制 一主一从 全量和增量同步 哨兵模式 docker-compose测试
大数据-51 Redis 高可用方案CAP-AP 主从复制 一主一从 全量和增量同步 哨兵模式 docker-compose测试
武子康
32 3
杀死一只知更鸟debug
|
2月前
|
NoSQL 网络协议 Redis
Redis的主从复制和哨兵模式
本文详细介绍了Redis的主从复制配置、原理（包括全量复制和增量复制）以及如何搭建一主二从的Redis集群，同时还探讨了Redis哨兵模式的概念、配置文件、以及如何配置一主二从三哨兵的Redis哨兵模式，以实现高可用性。
杀死一只知更鸟debug
78 0
小王老师呀
|
2月前
|
消息中间件 NoSQL Go
PHP转Go系列 | ThinkPHP与Gin框架之Redis延时消息队列技术实践
【9月更文挑战第7天】在从 PHP 的 ThinkPHP 框架迁移到 Go 的 Gin 框架时，涉及 Redis 延时消息队列的技术实践主要包括：理解延时消息队列概念，其能在特定时间处理消息，适用于定时任务等场景；在 ThinkPHP 中使用 Redis 实现延时队列；在 Gin 中结合 Go 的 Redis 客户端库实现类似功能；Go 具有更高性能和简洁性，适合处理大量消息。迁移过程中需考虑业务需求及系统稳定性。
小王老师呀
57 0
服务端技术栈
|
3月前
|
消息中间件 存储 缓存
深入理解Redis集群主从复制原理
该文章主要探讨了Redis集群中的主从复制原理，包括为何需要主从复制、配置方法、复制流程以及一些高级特性。
服务端技术栈
92 0
深入理解Redis集群主从复制原理

热门文章

最新文章

  • 1
    为什么redis是单线程的以及为什么这么快？
  • 2
    java Redis工具类
  • 3
    php-redis扩展模块安装记录
  • 4
    Redis从入门到精通之底层数据类型Stream详解和使用示例
  • 5
    为什么Redis不推荐使用Lettuce
  • 6
    fpm 打包redis3.0.7
  • 7
    Redis入门实战（四）Redis 配置文件redis.conf详解
  • 8
    Oracle查询结果集无法被redis缓存序列化问题
  • 9
    redis 配置文件翻译
  • 10
    第九章：Redis replication 主从复制
  • 1
    中间件Redis性能瓶颈
    102
  • 2
    Redis数据结构—跳跃表 skiplist 实现源码分析
    60
  • 3
    中间件键值存储模型Redis
    48
  • 4
    技术好文：Redis分布式锁的正确实现方式
    51
  • 5
    RDS（Relational Database Service）和Redis
    481
  • 6
    Redis 和 数据库区别
    55
  • 7
    搭建高可用及负载均衡的Redis
    133
  • 8
    【Azure Developer】一个复制Redis Key到另一个Redis服务的工具(redis_copy_net8)
    49
  • 9
    Redis数据结构—跳跃表 skiplist
    40
  • 10
    JSON 存入 Redis
    119

    • 相关课程

    更多
  • 大数据实战项目：反爬虫系统（Lua+Spark+Redis+Hadoop框架搭建）第二阶段
  • 大数据实战项目：反爬虫系统（Lua+Spark+Redis+Hadoop框架搭建）第四阶段
  • 大数据实战项目：反爬虫系统（Lua+Spark+Redis+Hadoop框架搭建）第五阶段
  • Redis入门实战演练
  • 云数据库 Redis 版使用教程
  • Redis数据库入门

    • 相关电子书

    更多
  • Redis集群演化的心路历程——从2.x到3.0时代
  • 微博的Redis定制之路
  • 云数据库Redis版的开源之路

    • 相关实验场景

    更多
  • 体验PolarDB MySQL多主集群
  • 如何通过数据库Redis内网访问
  • 搭建PostgreSQL主从架构
  • Tair for Redis数据闪回：任意时间点数据恢复
  • 如何开通Redis的专属集群
  • 快速搭建高可用网站服务
    • 下一篇
    阿里云OSS设置跨域访问