业务序列号怎么生成更合理？单体架构也能搞定吗？

在系统开发中，业务序列号的生成逻辑直接影响着交易追溯、数据分析等核心功能。开发团队常面临三大挑战：如何避免重复、保证高并发性能、实现业务可读性。在架构选择上，单体架构是否能够满足现代业务系统的序列号生成需求，成为众多技术决策者关注的焦点。

时间戳+随机数组合方案适用于低频场景，通过精确到毫秒的时间戳（如yyyyMMddHHmmssSSS）配合3位随机数，理论碰撞概率可控制在0.1%以下。但需要注意的是，当QPS超过100时需要引入更复杂的防碰撞机制。

步长预分配机制通过设置合理的步长值（如step=1000），各服务节点在DB中获取初始值后自主递增，可显著降低数据库访问压力。配合Redis集群时，推荐使用Lua脚本保证原子性操作。

典型的业务编码结构示例：
区域代码(2位)+业务类型(1位)+日期(6位)+流水号(6位)
这种结构在保证可读性的同时，需要特别注意日期部分与流水号的联动重置逻辑。

基于Spring Boot的单体架构实现示例：
“`java
@Transactional
public synchronized String generateSN() {
Sequence sequence = sequenceDao.selectForUpdate();
long current = sequence.getCurrentValue();
sequence.setCurrentValue(current + sequence.getStep());
sequenceDao.update(sequence);
return businessPrefix + String.format(“%08d”, current);
}
“`

关键技术点：
采用SELECT … FOR UPDATE实现行级锁
步长值根据预估业务量动态配置
事务边界控制在10ms以内

通过本地缓存实现二级缓冲：
1. 预加载1000个序列号到内存
2. 异步线程在库存低于20%时自动续充
3. 异常时降级为实时生成模式

建议采用双写机制：
主库采用MySQL集群
备用序列存储在Redis有序集合
每日执行数据一致性校验

推荐使用场景：
日均交易量＜50万笔
业务增长预期平缓
团队规模＜10人

当出现以下任一情况时建议升级：
单日峰值超过100万笔
需要跨地域部署
业务编码规则频繁变更

可采用分而治之策略：
核心业务使用分布式方案
边缘业务保持单体实现
通过API网关统一出口

1. 需求分析阶段：明确编码规则、预估业务量峰值、确定容灾等级
2. 技术验证阶段：压力测试需覆盖120%预估峰值、验证锁机制有效性
3. 监控体系搭建：设置序列号生成耗时、碰撞告警、容量预警等监控项
4. 灰度发布策略：按业务模块逐步上线，保留旧版生成器作为fallback

完整的单体架构实现代码已发布于GitHub（github.com/nowtostudey…），建议结合具体业务需求调整步长设置和锁机制。对于日均百万级以上的业务场景，建议在系统设计初期就采用分布式方案，但需注意引入分布式锁带来的性能损耗需要控制在合理范围内。