十来天前写过一篇 Redis 之前如何曲线的方式用作消息队列 使用 Redis 作为消息队列 - Pub/Sub, List, SortedSet. 只能说简单的使用方式勉强还行，离真正意义上的消息队列有些距离。而自 Redis 5.0 加入了 Stream 就更进一步，可望朝着作为正规消息队列的 At most once, At least once, 和 Exactly once 方向迈进。
如果以 Serverless 方式使用 AWS 的 Redis, 那么既然用到高级消息队列的功能，还能省去使用 AmazonMQ(ActiveMQ 或 RabbitMQ) 或 MSK(Kafka) 的高成本。
Redis stream 数据结构像是一个 append-only 日志，但又添加了 O(1) 的随机访问和复杂的消费策略，如消息分组。
Redis Stream 的每条消息会有一个唯一 ID, 支持消费组, Redis 用以支持 Stream 的一系列命令是 X 为前缀的, 完整的 Stream 命令列表。 阅读全文 >>
有好长一段时间没使用 Redis 了，之前用的都是 AWS 上的 Elastic Cache 的 Redis, 那时候还是用的版本还是 4 和 5。在新的项目由于觉得 Elastic Cache Redis 太贵而未曾使用，在去年的 AWS re:Invent 2023 上发布了 Elastic Cache Serverless，对于非长时间大数据的缓存可以考虑使用。而且还可以使用 Redis 的功能对服务进行解耦合，或作为一致性的协调中心。
此文是作为正式研究使用 Redis Stream (Redis 5.0 新特性) 的一个铺垫，探索在 Redis Stream 之前，可以何种方式把 Redis 当成一个消息队列，后面将会具体讲到如何用 Redis Stream 作为一个支持消费者组，能确认消息的更为完备的消息队列。
如以下几种方式
它就像 AWS 的 SNS 一样，只有在线的订阅者才能收到消息，每个消费者会收到相同的消息。相关的 Redis 命令是 *sub*, *pub*, 参考 Redis Command group Pub/Sub。订阅的时候可以直接指定 Channel 名称，或用模式匹配，还可关注某些 Key 的事件。 阅读全文 >>
在步入到 AWS 后，设计一个典型的分布式计算任务模式是
用 ECS 的好处是可以基于 SQS 的消息数进行 AutoScaling 配置，决定 Worker 的规模; 用 Lambda 适当的用 Concurrency 数来限定 Lambda 的实例数。
而 Python 的 Celery 让这一切变得更简单，它其实就是以上设计的一个集成方案。它以配置的方式选择使用任务队列(Broker), 结果存储方式(Backend), 让任务提交与 Worker 的代码实现简单化。 阅读全文 >>
以下内容完全毫无章序，是阅读 《redis设计与实现(第二版)》一书所划的一些自己助记用的重点。本不访放到博客上来，只称放在个人 Evernote 当中，于此纯粹为了自己往后查阅，所以请不要读它。
Redis 自 2.6 版本起加入了服务端的 Lua 脚本支持，即增添了 EVAL, EVALSHA, SCRIPT 相关命令。Lua 为何物，Lua 是一个非常轻量级，强大，高效，可内嵌的脚本语言; 产自于巴西，源码和二进制包都只有 200 多 KB。当前版本的 Redis 5.0.5 中 Lua 引擎版本是 Lua 5.1(自 Redis 2.6 起就没变，当前 Lua 为 5.3.5)，可用 Redis 命令 eval "return _VERSION" 0 查看到。
本文就要探究一下如何在 Redis 中使用 Lua 脚本，以及如何简化与 Redis 的交互。比如说在 Redis 中要先获一个值，然后根据这个值再去 Redis 中获得另一个相关联的值，如果不使用 Lua 脚本就会有两次与 Redis 交互，引入 Lua 脚本可以只用一次操作。
本文不具体讲述 Lua 语言本身，只涉及到与 Redis 相关的 Lua 特性。现在来体验下 Lua 中嵌入 Lua 脚本的基本操作。 阅读全文 >>