数据库（7）

目录

31.Redis Stream坏消息问题，死信问题？

32.Redis的持久化机制是什么？各自的优缺点？一般怎么用？

33.RDB触发方式？

 34.RDB由于生产环境中我们为Redis开辟的内存区域都比较大（例如6GB），那么将内存中的数据同步到硬盘的过程可能会持续比较长的时间，而实际情况是这段时间Redis服务一般都会收到数据写操作请求。那么如何保证数据一致性？

35.在进行RDB快照操作的这段时间，如果发生服务崩溃怎么办？

---

31.Redis Stream坏消息问题，死信问题？

正如上面所说，如果某个消息，不能被消费者处理，也就是不能被XACK,这是要长时间处于Pending列表中，即使被反复的转移给各个消费者也是如此。此时该消息的delivery counter就会累加，当累加到某个我们预设的临界值时，我们就认为是坏消息（也叫死信，deadletter,无法投递的 消息），由于有了判定条件，我们将坏消息处理掉即可，删除即可。删除一个消息，使用XDEL语法，演示如下：

注意本例中，并没有删除Pending中的消息因此你查看Pending，消息还会在。可以执行XACK标识其处理完毕。

32.Redis的持久化机制是什么？各自的优缺点？一般怎么用？

1.RDB持久化是把当前进程数据生成快照保存到磁盘上的过程；针对RDB不适合实时持久化的问题，Redis提供了AOF持久化方式来解决。

2.AOF是"写后"日志，Redis先执行命令，把数据写入内存，然后才记录日志。日志里记录的是Redis收到的每一条命令，这些命令时以文本形式保存。

3.Redis 4.0中提供了一个混合使用AOF日志和内存快照的方法。简单来说，内存快照以一定的频率执行，在两次快照之间，使用AOF日志记录这期间的所有命令操作。

这样一来，快照不用很频繁地执行，这就避免了频繁fork对主线程的影响。而且，AOF日志也只用记录两次快照间的操作，也就是说，不需要记录所有操作了，因此，就不会出现文件过大的情况了，也可以避免重写开销。

如下图所示，T1和T2时刻的修改，用AOF日志记录，等到第二次做全量快照时，就可以清空AOF日志，因为此时的修改都已经记录到快照中了，恢复时就不再用日志了。

这个方法既能享