持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第9天，点击查看活动详情

引言

Redis作为重要的消息中间件，需要处理大量的数据吞吐量，如何提升并发下的性能成为了工程师需要重点解决的问题，并且，单节点Redis的并发能力是有上限的，要进一步提高Redis的并发能力，就需要搭建主从集群，实现读写分离。下面跟随b站黑马的视频学习redis配置主从架构。

概况

redis主要基于单线程，在同一个节点下的读和写可能会阻塞其他命令，造成性能上的影响。下面我们可以通过配置主从复制，让master结点实现写，并将数据同步到slave分节点中，在分节点实现读。

在本机的测试中，我们需要复制一份新的redis.conf并更改端口号实现模拟主从复制的效果。我们使用7001端口实现master节点，7002和7003端口为slave节点。

具体操作

查看添加完的效果 info replication 使用redis-server 7002/redis.conf后使用Ctrl+C退出连接

使用SLAVEOF 119.29.79.55 7001（REPLICAOF 119.29.79.55 7001

）添加主从关系

查看添加完的效果 info replication

就可以实现主从复制，在主从复制中，从节点只能读，不能写，主节点可写可读

浅析内部原理：

master如何判断slave是不是第一次来同步数据？这里会用到两个很重要的概念：

Replication Id：简称replid，是数据集的标记，id一致则说明是同一数据集。每一个master都有唯一的replid，slave则会继承master节点的replid
offset：偏移量，随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset，说明slave数据落后于master，需要更新。因此slave做数据同步，必须向master声明自己的replication id 和offset，master才可以判断到底需要同步哪些数据

全量同步耗时长，只会在主从第一次同步使用，如果是slave重启后同步，则执行增量同步同时，master将RDB期间的命令记录在repl_baklog的文件大小有上限，写满后会覆盖最早的数据。如果slave断开时间过久，导致尚未备份的数据被覆盖，则无法基于log做增量同步，只能再次全量同步。

如果是slave节点断开又恢复，并且在repl_baklog中能找到offset时，执行增量同步。

如何优化Redis主从集群：

首先，Redis单节点上的内存占用不要太大，减少RDB导致的过多磁盘IO
适当提高repl_baklog的大小，发现slave宕机时尽快实现故障恢复，尽可能避免全量同步
限制一个master上的slave节点数量，如果实在是太多slave，则可以采用主-从-从链式结构，减少master压力（即在slave节点下再有slave节点，变成链式结构，应避免太多slave节点连接在一个master）
在master中配置repl-diskless-sync yes启用无磁盘复制，避免全量同步时的磁盘IO。