依赖注入服务生命周期与并发场景下唯一账号生成方案咨询

核心结论 #

单实例部署场景下优先选择方案3（Singleton服务+lock锁），该方案可以100%满足10分钟6000-8000次的并发诉求，且实现成本极低；多实例分布式部署场景下需要在该方案基础上补充数据库层的锁逻辑兜底。

原逻辑的核心问题 #

现有生成逻辑是典型的读-改-写竞态场景，无并发控制时，多个线程可以同时读取到相同的计数器值，最终生成重复账号，这是需要解决的核心问题。

三个方案的原理分析 #

方案1：仅注册Singleton生命周期的IAccountNumberManager服务 #

• 仅注册Singleton生命周期完全不起作用：Singleton仅保证整个应用进程内只有一个服务实例，本身不提供任何并发控制能力。即使是单例服务，多个线程仍可同时进入GenerateUniqueAccountNumber方法，还是会触发读改写竞态，无法避免账号重复。

方案2：仅在IAccountService代码块应用lock锁 #

• 仅加lock锁无法稳定生效：lock是进程内线程互斥锁，同一时间仅允许一个线程进入锁定代码块，本身可以解决读改写竞态，但如果IAccountService的生命周期是Scoped/Transient（业务服务的默认配置），每个请求会创建新的服务实例，如果lock使用实例级锁对象，等于每个实例持有独立的锁，完全起不到全局互斥作用；如果使用静态锁对象虽然可以生效，但静态锁在业务服务中容易引发不可预期的死锁问题，也不符合依赖注入的生命周期管理规范。

方案3：同时使用Singleton服务+lock锁 #

该方案是单实例部署场景下的最优解，原理如下：

• IAccountNumberManager注册为Singleton，整个进程只有一个实例，锁对象定义为该单例服务的实例字段，所有请求线程共享同一个锁，不存在多锁失效的问题
• lock锁保证同一时间只有一个线程执行「读计数器→加1→更新数据库」的完整逻辑，彻底消除进程内的读改写竞态
• 目标并发量平均每秒不到14次，lock的性能损耗完全可以忽略，没有性能瓶颈

如果是多实例分布式部署场景，需要额外补充数据库层的锁逻辑做跨进程的并发控制：

• 悲观锁实现：读取计数器时加行锁，SQL示例：SELECT counter FROM account_sequence FOR UPDATE，事务提交前其他实例无法读取该计数行
• 乐观锁实现：更新计数器时增加版本校验，SQL示例：UPDATE account_sequence SET counter = @newCounter WHERE counter = @oldCounter，更新失败自动重试即可

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