为什么不建议生产用Redis主从模式？

为什么不建议生产用Redis主从模式？

Redis有三种集群模式，分别是主从、“哨兵”、Cluster集群模式，今天先来聊一下主从模式

Redis主从模式是最简单的一种集群模式，类似于MySQL等数据库的主从同步一样

Redis主从

原理

Redis实现主从复制(Master-Slave Replication)的原理：Slave从节点服务启动并连接到Master之后，它将主动发送一个SYNC命令，Master服务主节点收到同步命令后将启动后台存盘进程，同时收集所有接收到的用于修改数据集的命令，在后台进程执行完毕后，Master将传送整个数据库文件到Slave，以完成一次完全同步。而Slave从节点服务在接收到数据库文件数据之后将其存盘并加载到内存中，此后Master主节点继续将所有已经收集到的修改命令，和新的修改命令一次传送给Slave，Slave将在本地执行这些数据修改命令，从而达到最终的数据同步。

如果Master和Slave之间的链接出现断链现象，Slave可以自动重连Master，但是在链接成功之后，一次完全同步将被自动执行

主从同步特点

一个master可以有多个slave一个slave只能有一个master数据流向是单向的，master到slave

主从优点

读写分离，提高效率数据热备份，提供多个副本slave同样可以接受其他slave的连接和同步请求，有效缓解master的同步压力master是以非阻塞的方式为slave提供同步服务，所以同步期间客户端仍然可以提供查询修改slave同样以非阻塞方式进行数据同步，同步期间，如果客户端发起查询请求，则slave返回同步前的数据

主从缺点

主节点故障后，集群则无法正常工作，无法提供高可用，从节点升主节点需要人工介入主节点单点容易造成性能下降主节点的存储能力受到限制主机宕机后，宕机前有部分数据未能及时同步到从机，会造成数据不一致，降低系统的可用性主从复制采用全量复制，复制的过程中会fork出子进程对内存做快照，并将子进程的内存快照保存为文件发送到从机，所以这个过程需要足够的内存主从复制的过程中，对网络要求很高，网络抖动会造成全量复制，对实际的系统运行造成很大的不稳定性全量同步可能会造成毫秒或者秒级的卡顿现象

主从同步完整执行流程

1.当slave第一次启动连接master，或者是“被认为是第一次连接”(如主从之间断链后重连)，则主从采用全量复制的方式进行数据同步

2.从库定时任务每秒检查是否有新的master需要连接，如果发现就与master建立socket连接

3.从库(slave)发送ping指令到master，master返回pong，则连接正常

4.从库(slave)发送auth认证信息给master，验证requirepass

5.认证通过后，从库(slave)发送sync命令给master请求数据同步

6.master接收到同步请求后向slave发送run_id和offset

7.slave会接收并保存master发过来的信息

8.master执行bgsave命令生成RDB文件，期间会创建复制缓冲区记录从现在开始执行的所有写命令

9.master向slave发送RDB数据，然后发送复制缓冲区记录的数据，slave会将RDB和缓冲区数据存放到磁盘中

10.slave清空原有数据，最后将磁盘中接收到的数据导入内存中

11.后续master收到的写命令都会通过之前建立的主从连接，增量发送给slave端

主从搭建实践

CentOS7默认源是安装Redis3.2版本的，先来看下3.x版本的Redis主从

接着在主库和从库进行set、get测试

# 从库执行set172.22.29.88:6379> set name redis(error) READONLY You can't write against a read only slave.'# 因为从库是只读的，所以无法完成set# 主库执行set、get172.22.29.87:6379> set name redisOK172.22.29.87:6379> get name"redis"# 从库执行get172.22.29.88:6379> get name"redis"

主从搭建完成，测试主库挂掉

# 停掉主库systemctl stop redis# 主库查询172.22.29.87:6379> get nameCould not connect to Redis at 172.22.29.87:6379: Connection refused# 从库查询172.22.29.88:6379> get name"redis"# 查看从库日志1758:S 03 Feb 12:17:59.848 * Connecting to MASTER 172.22.29.87:63791758:S 03 Feb 12:17:59.848 * MASTER <-> SLAVE sync started1758:S 03 Feb 12:17:59.849 # Error condition on socket for SYNC: Connection refused# 接着启动主库systemctl start redis# 查看从库日志1758:S 03 Feb 12:18:49.918 * MASTER <-> SLAVE sync started1758:S 03 Feb 12:18:49.918 * Non blocking connect for SYNC fired the event.1758:S 03 Feb 12:18:49.918 * Master replied to PING, replication can continue...1758:S 03 Feb 12:18:49.919 * Trying a partial resynchronization (request 4cd802976b4c445f06389c15bb7720effab38107:773).1758:S 03 Feb 12:18:49.920 * Full resync from master: 438afef01ffe3e55a681d89dfd699c1a6eb25e5b:11758:S 03 Feb 12:18:49.920 * Discarding previously cached master state.1758:S 03 Feb 12:18:49.928 * MASTER <-> SLAVE sync: receiving 94 bytes from master1758:S 03 Feb 12:18:49.928 * MASTER <-> SLAVE sync: Flushing old data1758:S 03 Feb 12:18:49.928 * MASTER <-> SLAVE sync: Loading DB in memory1758:S 03 Feb 12:18:49.928 * MASTER <-> SLAVE sync: Finished with success1758:S 03 Feb 12:18:49.930 * Background append only file rewriting started by pid 115231758:S 03 Feb 12:18:49.952 * AOF rewrite child asks to stop sending diffs.11523:C 03 Feb 12:18:49.952 * Parent agreed to stop sending diffs. Finalizing AOF...11523:C 03 Feb 12:18:49.953 * Concatenating 0.00 MB of AOF diff received from parent.11523:C 03 Feb 12:18:49.953 * SYNC append only file rewrite performed11523:C 03 Feb 12:18:49.953 * AOF rewrite: 4 MB of memory used by copy-on-write1758:S 03 Feb 12:18:50.019 * Background AOF rewrite terminated with success1758:S 03 Feb 12:18:50.019 * Residual parent diff successfully flushed to the rewritten AOF (0.00 MB)1758:S 03 Feb 12:18:50.019 * Background AOF rewrite finished successfully# 查看主库日志1869:M 03 Feb 12:18:49.526 * DB loaded from append only file: 0.000 seconds1869:M 03 Feb 12:18:49.526 * The server is now ready to accept connections on port 63791869:M 03 Feb 12:18:49.919 * Slave 172.22.29.88:6379 asks for synchronization1869:M 03 Feb 12:18:49.919 * Partial resynchronization not accepted: Runid mismatch (Client asked for runid '4cd802976b4c445f06389c15bb7720effab38107', my runid is '438afef01ffe3e55a681d89dfd699c1a6eb25e5b')1869:M 03 Feb 12:18:49.919 * Starting BGSAVE for SYNC with target: disk1869:M 03 Feb 12:18:49.920 * Background saving started by pid 18721872:C 03 Feb 12:18:49.922 * DB saved on disk1872:C 03 Feb 12:18:49.922 * RDB: 2 MB of memory used by copy-on-write1869:M 03 Feb 12:18:49.928 * Background saving terminated with success1869:M 03 Feb 12:18:49.928 * Synchronization with slave 172.22.29.88:6379 succeeded

主从搭建及测试完成

CentOS7要安装Redis最新版本，需要安装remi软件源

Redis6.x版本的主从配置和3.x版本的区别，主要是将slaveof指令变为replicaof

主从可优化的一些点

slave同样可以做为其他slave的master，可以有效分担master的同步压力master可以将数据保存操作交给slave完成，从而避免master需要独立进程来完成数据保存操作的压力repl-disable-tcp-nodelay应对网络延迟，默认关闭状态，关闭时，无论主节点产生的命令数据多大，都会及时发送给从节点，减少网络延迟，但是同时会增加网络开销，开启后，主节点会合并较小的TCP数据包，从而节省网络开销，发送给从节点的时间间隔取决于Linux内核配置，一般默认40ms，开启后节省了网络开销，但是增加了主从数据延迟缓存区大小调节，repl-backlog-size用于设置缓冲区大小，缓冲区大小影响写命令的数量，当主从节点offset的差距超过缓冲区长度时，将无法执行部分复制，只能执行全量复制，所以为了减少全量复制，可以增大缓冲区大小

总结

Redis主从可以看到，搭建很简单，但是实际在生产环境中，很少使用，也不建议在生产环境中使用Redis主从模式来提供服务，从前面的缺点部分可以看出来，在数据量达到一定量级后，主从模式的不稳定性会极具增加，但是主从原理是其他集群模式的基础，所以原理要了解，后面接着介绍另外两种集群模式

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。