多集群环境下消息队列选型及PostgreSQL并发重复读取问题咨询

1. PostgreSQL存储规避多节点重复读取的方案 #

针对多节点重复读取同一行数据的问题，结合PostgreSQL特性，可通过以下方式解决：

• 批量锁定+跳过已锁行：使用SELECT ... FOR UPDATE SKIP LOCKED语法批量抓取未处理事件，示例：

  SELECT * FROM events 
  WHERE processed = false 
  ORDER BY created_at 
  LIMIT 100 
  FOR UPDATE SKIP LOCKED;
  

  该语法会跳过已被其他节点锁定的行，既避免阻塞，又确保同一行不会被多个节点读取。
• 状态标记+事务控制：给事件表添加status字段（可选值：pending/processing/completed），处理流程包裹在事务中：
  1. 启动事务，将一批pending状态的事件更新为processing
  2. 查询这批processing状态的事件进行处理
  3. 处理完成后将状态改为completed并提交事务
     若节点异常退出，可通过定时任务将超时的processing状态事件重置为pending，避免数据丢失。
• 分区表优化：按日期对事件表做分区，夜间批量处理仅针对当日分区操作，缩小锁的作用范围，提升并发处理效率。

2. 符合需求的队列方案推荐 #

要实现手动逐条拉取、消息被读取后即不被其他节点重复获取的队列，可考虑以下方案：

• Cloud Pub/Sub 拉取订阅：创建拉取类型的订阅（而非推送订阅），节点主动调用拉取接口获取消息，处理完成后发送确认（ACK），消息会被移除；若节点重启未ACK，消息会在超时后重新进入队列（可调整ACK超时时间适配批量处理周期）。该方案天然支持分布式节点，无需自行维护队列存储。
• Memorystore for Redis 列表队列：利用Redis的List结构实现阻塞队列，节点通过BLPOP命令阻塞拉取消息（类似Java的BlockingQueue），消息被拉取后会立即从列表中移除，不会被其他节点读取。需开启Redis持久化（RDB/AOF），避免实例重启导致消息丢失。
• Cloud Firestore 事务队列：将事件存储为Firestore文档，节点通过事务获取并标记第一条未处理文档，处理完成后删除或标记为已处理。事务机制确保同一文档不会被多个节点同时读取，适合数据量不大的场景。

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