共计 1171 个字符，预计需要花费 3 分钟才能阅读完成。
有任何问题都能够留言征询。
思考 1
写入量很大，导致 redis 的 rdb 长久化异样
一开始排查到问题，是拜访 Redis 返回时长较长。
而后看到应用服务的报错信息：
MISCONF Redis is configured to save RDB snapshots, but is currently not able to persist on disk. Commands that may modify the data set are disabled. Please check Redis logs for details about the error.
再查看 redis 组件的日志：
can’t save in background: fork: cannot allocate memory
阐明是 bgsave 出错了，无奈申请到内存。
思考
文章不易，请关注公众号 毛毛虫的小小蜡笔，多多反对，谢谢。
1、bgsave vs save
save 间接调用 rdbSave 函数，阻塞 redis 主过程，直到保留实现为止。在主过程阻塞期间，服务器不能解决客户端的任何申请。
如果数据量小，用此命令可能感觉不出有什么区别，然而当数据量很大的时候，就须要审慎应用这个命令。
bgsave 命令执行之后立刻返回 OK，而后 redis fork 出一个新子过程，原来的 redis 过程 (父过程) 持续解决客户端申请，而子过程则负责将数据保留到磁盘，而后退出。
2、rdb 的毛病
1、如果您须要在 Redis 进行工作时（例如断电后）将数据失落的可能性降到最低，那么 RDB 并不好。您能够配置生成 RDB 的不同保留点（例如，在对数据集至多 5 分钟和 100 次写入之后，您能够有多个保留点）。然而，您通常会每五分钟或更长时间创立一个 RDB 快照，因而，如果 Redis 因为任何起因在没有正确敞开的状况下进行工作，您应该筹备好失落最新分钟的数据。
2、RDB 须要常常 fork() 以便应用子过程在磁盘上长久化。如果数据集很大，fork() 可能会很耗时，并且如果数据集很大并且 CPU 性能不是很好，可能会导致 Redis 进行为客户端服务几毫秒甚至一秒钟。AOF 也须要 fork() 但频率较低，您能够调整要重写日志的频率，而不须要对持久性进行任何衡量。
思考 2
是什么导致了 redis 故障？
不言而喻的起因
故障产生的前几日客户调用量激增，由本来均匀每日 100 万调用量激增至每日 300-400 万调用量。
激增的调用量使得 redis 短时间写入量增大，触发 rdb 长久化。
过程阻塞升高了 redis 服务性能。
思考
1、异步问题
在生产音讯后，必须紧接着把音讯 pop 掉，不然会有问题。
生产音讯的代码 insertDetail 是异步的，个别状况下，应该是数据量比拟少的状况下，执行很快，所以能顺利 pop 掉数据。
但如果数据量很大，那就很容易呈现问题了。异步代码在写入数据，后果还没执行完，就把数据 pop 掉了。
如果此时写入失败，就会导致数据失落。
