DynamoDB建模房间人数排行榜的最优设计模式咨询

方案1：单表事务+聚合项方案（强一致，无额外表） #

不需要单独建计数表，直接在现有表中新增房间聚合项即可：

• 聚合项结构：PK为ROOM_META#{roomId}，SK为固定值COUNT，新增数值类型属性userCount存储房间当前人数
• 用户进出房间时直接使用DynamoDB事务写，一次请求同时完成两个操作：
  • 新增/删除user#{userId} + room#{roomId}的用户房间关联项
  • 对对应房间的聚合项执行ADD userCount 1/ADD userCount -1的原子计数操作
    该方案天然保证关联关系和计数的强一致性，不存在数据同步问题。

要实现按人数排序的TopN查询，给聚合项建专属GSI即可：

• GSI的PK设为固定值HOT_ROOM_RANK，SK设为userCount
• 直接按SK倒序查询该GSI，单次请求就能拿到人数从高到低的前N个房间，输出结构完全符合topRooms(n) = {room1: 1, room2: 3}的要求
  如果房间总量超过10万，可给GSI的PK加数字后缀拆分分区（比如HOT_ROOM_RANK#0到HOT_ROOM_RANK#9），查询时并行拉取所有分区结果合并排序，避免热分区问题

方案2：DynamoDB Streams异步更新方案（低写延迟，最终一致） #

如果业务写QPS极高，不愿意承担事务写的少量性能开销，用Streams完全可以解决你担心的同步一致性问题：

• 打开现有表的流监听，捕获用户房间关联项的新增、删除事件
• 用Lambda消费流事件，触发对应房间的计数更新，直接用原子ADD/减法操作天然实现幂等，不用担心重复消费导致的计数不准
  该方案仅需一次关联项写入操作，无额外写开销，计数更新延迟在秒级以内，适合对TopN实时性要求不高的场景。

选型建议 #

• 要求计数完全准确、实时的场景选事务写方案，DynamoDB事务性能可满足绝大多数在线业务需求
• 写压力极大、允许计数有秒级延迟的场景选Streams异步方案

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