寻求DynamoDB/MongoDB+Redis替代方案：实时群组活跃人数监控咨询

根据你的场景——需要近乎实时监控群组活跃成员数、扩容后读请求随群组数量线性增长，我推荐用Redis作为实时计算层 + 持久化数据库（比如DynamoDB、PostgreSQL或MongoDB）作为全量数据层的组合方案，既解决高并发低延迟的读需求，又保证数据的完整性和持久性，完全覆盖你的痛点。

1. Redis层：搞定实时活跃数的高并发查询 #

你担心Redis的复杂数据结构存储与检索问题？其实它恰恰是解决你核心需求的最优选择，这里给你一套针对性的结构设计：

核心存储结构设计 #

• 单个成员状态存储：用Redis Hash结构，每个群组对应一个Hash Key，比如group:g01:members，Hash的Field是成员ID（person_id_01），Value是成员参数的JSON字符串（比如{"active": true, "last_login": "2024-05-20T10:00:00"}）。这样更新单个成员状态时，直接用HSET group:g01:members person_id_01 '{"active": false, ...}'，是O(1)操作；查询单个成员详情也能瞬间完成。
• 活跃成员集合存储：为每个群组维护一个Redis Set，Key比如group:g01:active_members。当成员active变为true时，执行SADD group:g01:active_members person_id_01；变为false时执行SREM group:g01:active_members person_id_01。要查询活跃成员数？直接调用SCARD group:g01:active_members，这也是O(1)的操作，毫秒级响应，完全满足每秒查询的要求。

扩容后的多实例适配 #

当应用扩容为多实例、每个实例监控不同群组时，Redis的分片机制（Cluster模式）或者客户端分片可以完美适配：

• 把不同群组的Key分配到不同Redis节点，每个应用实例只负责对应分片的群组查询，避免跨节点开销，保证每个实例的读请求都是低延迟的本地操作。
• 成员状态更新时，直接操作对应Redis Key，Redis的单线程原子性保证了所有实例能实时看到最新状态，不会出现数据不一致。

2. 持久化存储层：负责全量数据的持久化与非实时操作 #

Redis是内存存储，虽然可以开启持久化，但还是需要搭配一个磁盘存储的数据库来保存完整的层级数据，用于成员详情批量查询、历史数据回溯、数据备份等场景：

存储结构选型 #

• 如果用DynamoDB：采用复合主键，分区键设为group_id，排序键设为person_id。这样同一个群组的所有成员数据会被放在同一个分区，查询某个群组的所有成员时效率极高，也符合DynamoDB的最佳实践。
• 如果用MongoDB：直接存储你原本的层级结构，每个文档对应一个群组，成员信息嵌套在文档中，适合需要批量获取群组完整数据的场景。
• 如果用PostgreSQL：可以建两张表，groups表存群组基本信息，group_members表存成员信息，用group_id关联，通过JOIN查询群组的所有成员。

数据同步策略 #

为了平衡实时性和数据一致性，推荐采用异步同步：

• 优先更新Redis（保证活跃数的实时性），然后通过消息队列（比如SQS、RabbitMQ）发送更新消息，异步同步到持久化存储。这样写操作延迟极低，完全满足你的实时场景。
• 极端情况下如果出现Redis和持久化存储的数据不一致，可以通过定期全量同步（比如每天凌晨）或者补偿机制（监听消息队列的死信队列）来修复。

3. 为什么不单独用DynamoDB？ #

你的判断是对的，单独用DynamoDB确实不适合这个场景：

• 当群组数量增长到上千上万时，每秒每个群组一次读请求，会产生极高的读容量单位（RCU）消耗，成本会急剧上升。
• 查询活跃成员数需要扫描整个群组的成员数据并过滤active=true的记录，这是O(n)的操作，当群组成员数较多时，延迟会很高，无法满足近乎实时的监控要求。

4. 额外优化小技巧 #

• 用Redis Lua脚本保证成员状态更新和活跃集合操作的原子性，比如执行HSET的同时自动完成SADD/SREM，避免中间状态不一致。
• 如果需要统计所有群组的活跃成员总数，可以用Redis Stream或者Pub/Sub，当某个群组的活跃数变化时，发送消息到统计服务，实时更新总数，不用遍历所有群组的Set。
• Redis开启RDB+AOF混合持久化，搭配持久化存储的定期备份，双重保证数据安全。

内容的提问来源于stack exchange，提问作者Z T