分享的心得，有什么问题可以留言咨询。思考1、写入量很大，导致redis的RDB持久化异常。刚开始排查，问题是返回访问Redis需要很长时间。然后看到应用服务的报错信息：MISCONFRedisisconfiguredtosaveRDBsnapshots,butiscurrentlynotabletopersistondisk.可能修改数据集的命令被禁用。请检查Redis日志以了解有关错误的详细信息。再次查看redis组件的日志：can'tsaveinbackground:fork:cannotallocatememory说明bgsave出错，无法申请内存。想文章不易，请关注公众号毛毛虫的小蜡笔，谢谢支持。1、bgsavevssavesave直接调用rdbSave函数，阻塞redis主进程，直到save完成。当主进程被阻塞时，服务器无法处理来自客户端的任何请求。如果数据量较小，使用该命令可能感觉不到任何差异，但当数据量较大时，需要谨慎使用该命令。bgsave命令执行后立即返回OK，然后redisfork出一个新的子进程。原来的redis进程（父进程）继续处理客户端请求，子进程负责将数据保存到磁盘，然后退出。二、rdb的缺点1、如果你需要在Redis停止工作时（比如断电后）尽量减少数据丢失的可能性，那么RDB不好。您可以配置生成RDB的不同保存点（例如，您可以在至少5分钟和100次写入数据集后拥有多个保存点）。但是，您通常会每五分钟或更长时间创建一次RDB快照，因此如果Redis由于任何原因在没有正常关闭的情况下停止工作，您应该做好丢失最新一分钟数据的准备。2.RDB需要经常fork()才能使用子进程持久化到磁盘上。如果数据集很大，Fork()可能会很耗时，如果数据集很大且CPU性能不佳，则可能导致Redis停止为客户端提供几毫秒甚至一秒的服务。AOF也需要fork()但频率较低，您可以调整重写日志的频率，而无需在持久性上进行任何权衡。思考2??redis失败的原因是什么？由于显而易见的原因，在故障发生前的头几天，客户来电数量激增，从平均每天100万次增加到每天3-4百万次。调用次数的激增增加了redis的短期写量，触发了RDB持久化。进程阻塞会降低redis服务性能。思考1.异步问题消费完消息后，必须立即弹出消息，否则会出问题。消费消息的代码insertDetail是异步的。一般情况下，数据量比较少的时候应该执行的比较快，这样才能顺利的出栈数据。但是如果数据量很大，就很容易出问题。异步代码正在写入数据，但数据在执行完成之前就被弹出。如果此时写入失败，会导致数据丢失。
