各位观众老爷们，大家好！我是你们的老朋友，代码界的段子手——码农张三。今天咱们不聊妹子，也不聊房价，来聊聊Redis Streams这个神奇的小东西。
说起Redis，大家肯定不陌生，缓存界的扛把子嘛！速度快得像闪电，数据结构丰富得像满汉全席。但是，传统的Redis就像个记忆力不太好的老头，来了新的数据，就把旧的给忘了。这在有些场景下可不行啊，比如消息队列，你得保证消息不丢，还得能追溯历史。
这时候，Redis Streams就闪亮登场了！它就像给Redis装上了一个“时光机”，让它可以记住过去，展望未来，而且还能像小溪一样，潺潺不断地流动数据。今天，我们就来好好扒一扒Redis Streams的消息保留策略和持久化，看看它是如何做到“忆往昔峥嵘岁月，保消息万无一失”的。
一、Redis Streams：你的消息，我来守护！
首先，我们得先了解一下Redis Streams是个什么玩意儿。简单来说，它就是一个持久化的消息队列，可以让你像使用Kafka一样，发布和订阅消息。但是，它又比Kafka轻量级，配置简单，上手容易，简直是居家旅行、杀人越货……哦不，是开发应用的必备良药！
你可以把Streams想象成一条河流，消息就像水滴，源源不断地汇入河流。每个消息都有一个唯一的ID，就像身份证一样，保证了消息的唯一性。消费者可以从河流的任意位置开始读取消息，就像渔夫可以选择在河流的任何地方下网捕鱼。
二、消息保留策略：时间与空间的博弈
既然是消息队列，那消息总得有个保留期限吧？不然，时间长了，内存不就爆了吗？Redis Streams提供了两种消息保留策略：
-
基于长度的保留策略（Maxlen）：
这种策略就像一个“限高杆”，超过这个长度的消息，就会被无情地“截肢”。你可以设置Streams中消息的最大数量，当消息数量超过这个值时，Redis会自动删除最早的消息，保证Streams不会无限增长。
举个例子，你想保留最近1000条消息，就可以这样设置：
XADD mystream MAXLEN 1000 * message1这里的
MAXLEN 1000就是告诉Redis，最多保留1000条消息。如果Streams中已经有1000条消息了，再添加新的消息，最早的消息就会被删除。注意： 这里的
MAXLEN只是一个近似值，Redis并不会严格保证Streams中消息的数量一定小于等于MAXLEN。它会尽量接近这个值，但可能会因为一些内部机制，导致实际数量略微超过MAXLEN。你可以理解为，这是一个“弹性”的限高杆，稍微有点松动，但大方向是没问题的。修饰符：
~（近似） 和=（精确）~是默认的修饰符，它允许Redis根据其内部优化来删除消息，以提高性能。这意味着实际保留的消息数量可能会略高于你设置的MAXLEN值。=修饰符则强制 Redis 精确地删除消息，以确保保留的消息数量绝对不超过MAXLEN值。但使用=会降低性能，因为它需要进行更精确的计算和删除操作。例如：
XADD mystream MAXLEN ~1000 * message1 # 使用近似修饰符（默认） XADD mystream mystream MAXLEN =1000 * message1 # 使用精确修饰符表格总结：基于长度的保留策略
特性 描述 策略类型 基于Streams中消息的最大数量 工作方式 当消息数量超过最大值时，删除最早的消息 优点 简单易用，控制消息数量 缺点 不能根据时间保留消息，可能丢失重要消息 修饰符 ~(近似，默认),=(精确)适用场景 对消息数量有严格限制，不需要长期保存消息的场景 -
基于时间的保留策略（TTL）：
这种策略就像一个“保质期”，超过这个时间的消息，就会被自动“过期”。你可以设置Streams中消息的生存时间，当消息的年龄超过这个时间时，Redis会自动删除它。
Redis Streams本身并没有直接提供基于时间的TTL策略。但是，我们可以通过一些技巧来实现类似的效果。例如，可以使用Redis的Sorted Set，将消息的ID和时间戳存储在一起，然后定期扫描Sorted Set，删除过期消息。
当然，这种方法比较麻烦，需要自己编写代码来实现。不过，社区里有很多开源的解决方案，可以帮你轻松实现基于时间的保留策略。
一种实现方法（伪代码）：
-
添加消息时，同时添加到Sorted Set:
# 假设 stream_key 是 stream 的名称，ttl 是消息的生存时间（秒） def add_message_with_ttl(stream_key, message, ttl): message_id = redis_client.xadd(stream_key, {"message": message}) expire_time = time.time() + ttl redis_client.zadd(stream_key + ":ttl", {message_id: expire_time}) return message_id -
定期清理过期消息:
def cleanup_expired_messages(stream_key): now = time.time() expired_messages = redis_client.zrangebyscore(stream_key + ":ttl", "-inf", now) if expired_messages: redis_client.xdel(stream_key, *expired_messages) redis_client.zrem(stream_key + ":ttl", *expired_messages)
注意： 这种方法需要定期执行清理操作，可以使用定时任务或者后台线程来实现。
表格总结：基于时间的保留策略
特性 描述 策略类型 基于消息的生存时间 工作方式 当消息的年龄超过生存时间时，删除消息 优点 可以根据时间保留消息，避免长期保存无用消息 缺点 需要自己实现，比较复杂，性能可能受到影响 适用场景 需要长期保存消息，但又不想保存过久的场景 -
三、持久化：让你的消息永不丢失！
光有消息保留策略还不够，万一Redis服务器挂了，内存里的数据岂不是全没了？这可不行！Redis提供了两种持久化方式：
-
RDB（快照）：
RDB就像给Streams拍了一张照片，定期将Streams的数据保存到磁盘上。当Redis服务器重启时，可以从RDB文件中恢复数据。
RDB的优点是速度快，恢复速度也快，适合做冷备份。缺点是可能会丢失一部分数据，因为RDB是定期保存的，如果在两次保存之间服务器挂了，这段时间的数据就没了。
配置RDB：
可以在Redis的配置文件中设置RDB的保存频率和保存策略。例如：
save 900 1 # 900秒内，至少有1个key被修改，就保存一次 save 300 10 # 300秒内，至少有10个key被修改，就保存一次 save 60 10000 # 60秒内，至少有10000个key被修改，就保存一次你可以根据自己的需求，调整这些参数。
-
AOF（Append Only File）：
AOF就像给Streams写日记，记录了Streams的每一次操作。当Redis服务器重启时，可以重放AOF文件中的操作，恢复数据。
AOF的优点是可以保证数据的完整性，即使服务器挂了，也可以恢复到最近的状态。缺点是速度慢，恢复速度也慢，文件体积也比较大。
配置AOF：
可以在Redis的配置文件中开启AOF：
appendonly yes还可以设置AOF的同步策略：
# appendfsync always # 每次有新的命令就同步写入磁盘，最安全，但性能最差 appendfsync everysec # 每秒同步写入磁盘，安全性和性能之间取得平衡（推荐） # appendfsync no # 由操作系统决定何时同步写入磁盘，最快，但最不安全同样，你可以根据自己的需求，调整这些参数。
AOF重写：
随着时间的推移，AOF文件会越来越大，影响性能。Redis提供了AOF重写机制，可以定期重写AOF文件，删除冗余的操作，减小文件体积。
AOF重写不会阻塞Redis服务器，它会在后台进行。
表格总结：RDB vs AOF
特性 RDB AOF 策略类型 快照 日志 工作方式 定期将数据保存到磁盘 记录每次操作，重启时重放操作 优点 速度快，恢复速度快，适合做冷备份 保证数据完整性，可以恢复到最近的状态 缺点 可能会丢失一部分数据 速度慢，恢复速度慢，文件体积大 适用场景 对数据完整性要求不高，需要快速备份和恢复的场景 对数据完整性要求高，可以容忍较慢的备份和恢复速度的场景 配置参数 save(RDB保存频率和策略)appendonly(是否开启AOF),appendfsync(AOF同步策略)
四、最佳实践：打造坚不可摧的消息队列
说了这么多，我们来总结一下，如何打造一个坚不可摧的Redis Streams消息队列：
-
选择合适的消息保留策略：
根据你的业务需求，选择合适的保留策略。如果只需要保留最近的消息，可以使用基于长度的保留策略。如果需要长期保存消息，可以使用基于时间的保留策略。
-
开启持久化：
务必开启RDB和AOF持久化，保证消息不会丢失。推荐使用AOF持久化，并选择
appendfsync everysec同步策略，在安全性和性能之间取得平衡。 -
定期监控：
定期监控Redis服务器的性能，包括CPU、内存、磁盘IO等。如果发现性能瓶颈，及时进行优化。
-
备份：
定期备份RDB和AOF文件，以防万一。可以将备份文件存储到云端，提高数据的安全性。
-
集群：
如果你的业务规模很大，单台Redis服务器无法满足需求，可以考虑使用Redis集群。Redis集群可以将数据分散到多台服务器上，提高可用性和性能。
五、总结：Redis Streams，你的消息好伙伴！
好了，各位观众老爷们，今天的Redis Streams的消息保留策略和持久化就讲到这里。希望通过今天的讲解，大家对Redis Streams有了更深入的了解。
记住，Redis Streams就像你的消息好伙伴，它会尽心尽力地守护你的消息，让你的消息永不丢失！ 只要你掌握了正确的使用姿势，就能打造一个坚不可摧的消息队列，为你的应用保驾护航！
最后，祝大家编码愉快， Bug 远离！ 😎