共计 1447 个字符，预计需要花费 4 分钟才能阅读完成。
自动写代码机器人，免费开通
了解 redis 性能常见问题有哪些？这个问题可能是我们日常学习或工作经常见到的。希望通过这个问题能让你收获颇深。下面是丸趣 TV 小编给大家带来的参考内容，让我们一起来看看吧！
Master 写内存快照，save 命令调度 rdbSave 函数，会阻塞主线程的工作，当快照比较大时对性能影响是非常大的，会间断性暂停服务，所以 Master 最好不要写内存快照。
Master AOF 持久化，如果不重写 AOF 文件，这个持久化方式对性能的影响是最小的，但是 AOF 文件会不断增大，AOF 文件过大会影响 Master 重启的恢复速度。
Master 调用 BGREWRITEAOF 重写 AOF 文件，AOF 在重写的时候会占大量的 CPU 和内存资源，导致服务 load 过高，出现短暂服务暂停现象。
下面是我的一个实际项目的情况，大概情况是这样的：
一个 Master，4 个 Slave，没有 Sharding 机制，仅是读写分离，Master 负责写入操作和 AOF 日志备份，AOF 文件大概 5G，Slave 负责读操作，当 Master 调用 BGREWRITEAOF 时，Master 和 Slave 负载会突然陡增，Master 的写入请求基本上都不响应了，持续了大概 5 分钟，Slave 的读请求过半也无法及时响应，上面的情况本来不会也不应该发生的，是因为以前 Master 的这个机器是 Slave，在上面有一个 shell 定时任务在每天的上午 10 点调用 BGREWRITEAOF 重写 AOF 文件，后来由于 Master 机器 down 了，就把备份的这个 Slave 切成 Master 了，但是这个定时任务忘记删除了，就导致了上面悲剧情况的发生，原因还是找了几天才找到的。
将 no-appendfsync-on-rewrite 的配置设为 yes 可以缓解这个问题，设置为 yes 表示 rewrite 期间对新写操作不 fsync，暂时存在内存中，等 rewrite 完成后再写入。最好是不开启 Master 的 AOF 备份功能。
Redis 主从复制的性能问题，第一次 Slave 向 Master 同步的实现是：Slave 向 Master 发出同步请求，Master 先 dump 出 rdb 文件，然后将 rdb 文件全量传输给 slave，然后 Master 把缓存的命令转发给 Slave，初次同步完成。第二次以及以后的同步实现是：Master 将变量的快照直接实时依次发送给各个 Slave。不管什么原因导致 Slave 和 Master 断开重连都会重复以上过程。Redis 的主从复制是建立在内存快照的持久化基础上，只要有 Slave 就一定会有内存快照发生。虽然 Redis 宣称主从复制无阻塞，但由于磁盘 io 的限制，如果 Master 快照文件比较大，那么 dump 会耗费比较长的时间，这个过程中 Master 可能无法响应请求，也就是说服务会中断，对于关键服务，这个后果也是很可怕的。
以上 1.2.3.4 根本问题的原因都离不开系统 io 瓶颈问题，也就是硬盘读写速度不够快，主进程 fsync()/write() 操作被阻塞。
单点故障问题，由于目前 Redis 的主从复制还不够成熟，所以存在明显的单点故障问题，这个目前只能自己做方案解决，如：主动复制，Proxy 实现 Slave 对 Master 的替换等，这个也是 Redis 作者目前比较优先的任务之一。
感谢各位的阅读！看完上述内容，你们对 redis 性能常见问题有哪些大概了解了吗？希望文章内容对大家有所帮助。如果想了解更多相关文章内容，欢迎关注丸趣 TV 行业资讯频道。
向 AI 问一下细节
丸趣 TV 网 – 提供最优质的资源集合！
