如何在无状态服务集群中生成不重复伪随机数 现有方案是否可行

现有方案的问题 #

效率问题 #

现有方案整体效率偏低，每一次/token请求都需要触发一次数据库的写+读操作，数据库会成为整个服务的性能瓶颈，高并发场景下很容易被打垮，同时数据库本身存在单点故障风险，一旦数据库不可用，所有服务实例都会完全无法对外提供服务。

竞态条件问题 #

是否出现竞态取决于你更新数据库的实现逻辑：

• 如果你采用先读map值、本地加1再写回的非原子操作逻辑，100%会出现竞态，多个并发请求可能读到同一个map值，最终返回重复的随机数
• 如果你采用数据库自带的原子更新操作（比如MySQL的UPDATE counter SET map = map +1 WHERE id=1 配合后续读操作，或者PostgreSQL的UPDATE ... RETURNING map语法），可以避免竞态，但本质是靠数据库的行锁实现，会进一步放大性能开销。

无需数据库的解决方案 #

方案1：固定实例ID分段（适合实例数固定为3的场景，零外部依赖性能最优） #

这是最适配你当前场景的方案：

• 给3个服务实例分别分配唯一的实例ID，取值为0、1、2，通过环境变量传入实例
• 每个实例本地维护一个线程安全的原子自增计数器，不需要持久化
• 每次收到/token请求时，先将本地计数器加1，再计算全局序列下标：global_idx = (本地计数器值 - 1) * 3 + 实例ID
• 用global_idx % n作为下标取预生成的随机序列对应值返回即可
  该方案完全没有跨实例通信开销，性能比数据库方案高几个数量级，且所有实例生成的下标永远不会重叠，不会出现重复随机数。

方案2：分布式缓存原子计数（适合实例数可能动态调整的场景） #

如果后续实例数会扩容，你可以用Redis替换数据库，用Redis的INCR原子命令实现计数器，性能是关系型数据库的10~100倍，同样可以完全避免竞态问题，架构复杂度远低于数据库方案。

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