仿银行网站 asp推广文章的步骤
Redis Replication
1、前言
在单节点搞事情, 存在的问题包括存量问题和增量问题两类, 解决方案就是1个不行上N个, 做到单机维度宕机但服务维度是可用的。
1.1 存量问题
如果目前的单节点QPS满足(也就是综合瓶颈还没达到), 那么只有宕机能影响到。如果业务量不大, 又是出于成本考虑, 做好宕机自动重启, 就是可用性差点其他没毛病。
1.2 增量问题
- 内存资源瓶颈, 单节点的Redis宕机时，会导致缓存不可用。比如原来4G, 后来有钱要升级到16G, 因为不能停没法升级;
- CPU资源瓶颈, CPU的利用率上，单台Redis实例只能利用单个核心。
- 综合瓶颈(CPU+内存+网络带宽), 单节点的Redis能够支撑QPS大概在5W左右，超过之后就成为高并发的瓶颈, 然而在单节点上这些都无法升级;
2 复制的作用
2.1 数据冗余
主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
2.2 故障恢复
当主节点出现了问题，可以由从节点提供服务，实现快速的故障恢复, 算是一种服务级别的冗余。
2.3 负载均衡
在主从复制的基础上, 配合读写分离, 分担数据读取负载。尤其是在写少读多的情况下，通过多个从节点分担读负载，可以大大提高redis服务器的并发量。
2.4 高可用基础
除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。
3. 复制的实现
Redis的复制包括两个阶段, 全量同步和增量同步;
3.1 角色说明
- 复制包含两个角色, master和slave, 其中slave复制master中的数据;
- 一个master实例可以有多个slave实例;
- 一个slave实例则只能有一个master实例;
- 一个slave实例可以从任何角色的实例上复制数据, 这意味着replication支持级联;
3.2 全量同步
使用场景
slave节点首次同步master数据, 同步内容包含RDB快照, 以及在RDB快照同步期间缓存的数据更新命令(存储在ReplicationBuffer中)。
具体流程
3.3 增量同步
使用场景
slave节点临时与master节点断开, 后续又建立连接。此时slave节点的offset依然可以在master的ReplicationBacklogBuffer中找到。
具体流程
4. 配置参数
| 参数 | 说明 |
|---|---|
| replica-ignore-maxmemory | 在slave节点对带有TTL key的删除依赖于master节点生成的del命令, 因此可能会使用更多的内存。在完全一致的配置参数下可能会有问题, 因此在slave节点建议设置为yes |
| replica-read-only | slave节点是否只读 |
| replica-lazy-flush | slave节点进行全量同步时flush本地DB的过程是同步还是异步 |
| repl-ping-replica-period | slave节点与master节点之间的心跳间隔, 保持master和slave的链接有效性 |
| replica-serve-stale-data | 在slave节点与master节点做全量同步过程中, 是否响应client请求 |
| repl-backlog-size | 复制积压缓冲区大小, 每秒产生的命令 *（master执行rdb bgsave的时间）+ (master发送rdb到slave的时间) + (slave load rdb文件的时间) ，来估算积压缓冲区的大小，repl-backlog-size 值不小于这两者的乘积。 例如，如果主服务器平均每秒产生1 MB的写数据，而从服务器断线之后平均要5秒才能重新连接上主服务器，那么复制积压缓冲区的大小就不能低于5MB。为了安全起见，可以将复制积压缓冲区的大小设为2*5=10M，这样可以保证绝大部分断线情况都能用增量从而避免全量同步数据。 |
| repl-backlog-ttl | 复制积压缓冲区中命令保持的最长时间 |
| repl-timeout | 全量复制的超时时间, 如果RDB文件比较大, 可能需要调大该数值 |
| client-output-buffer-limit | 不同客户端使用的buffer限制(hard/soft/time),影响全量同步过程中可 normal 0 0 0 slave 268435456 67108864 60 pubsub 33554432 8388608 60。参数值设置太小，就会导致replication_buffer不够用，新增的数据也就无法存入该缓冲区。在Redis 7.0下, master会提示由于overcoming of output buffer limits而停止数据发送, slave则持续在全量同步阶段等待。 待超时之后, slave重新发起同步, 最终slave永远都无法全量同步成功, 从而影响到整个服务的性能和质量。 |
5. 极限测试
5.1 slave复制自己
- 配置操作可以成功;
- 日志显示开启成功连接并响应PING, 然后开始尝试部分复制, 但是没有什么数据可以复制, client断开链接;
Master is currently unable to PSYNC but should be in the future: -NOMASTERLINK Can't SYNC while not connected with my master
- 循环1,2直到timeout, slave认为master无法复制停止;
6. 总结
本文介绍了Redis Replication的作用，以及相关的阶段和具体实现，希望能帮助你更好地理解Redis Replication的实现，感谢您的阅读。