1. 项目背景与核心挑战一人一单是电商和本地生活服务领域常见的业务模式指每个用户在同一时间段内只能下一个有效订单。这种模式常见于秒杀、限量优惠、新用户专享等营销场景目的是防止黄牛刷单、保证活动公平性。当业务发展到一定规模后单机服务往往无法承受高并发压力这时就需要考虑集群化部署。在集群环境下实现一人一单面临几个技术难点分布式锁的选型与实现Redis/Zookeeper等订单唯一性校验的时效性集群节点间状态同步高并发下的性能与一致性平衡2. 技术方案设计2.1 整体架构设计我们采用分层架构设计接入层Nginx负载均衡 域名解析服务层Spring Cloud微服务集群数据层MySQL分库分表 Redis集群监控层Prometheus Grafana关键组件说明使用Redis的SETNX命令实现分布式锁订单表增加用户ID活动ID的唯一索引本地缓存分布式缓存二级校验2.2 分布式锁实现细节public boolean tryLock(String lockKey, String requestId, int expireTime) { try { String result jedis.set(lockKey, requestId, NX, PX, expireTime); return OK.equals(result); } finally { jedis.close(); } }注意事项必须设置过期时间防止死锁value要使用唯一标识如UUID释放锁时要验证requestId避免误删2.3 订单唯一性校验流程本地缓存校验Guava CacheRedis分布式锁获取数据库唯一索引校验创建订单后更新缓存重要提示必须按照这个顺序执行校验先查缓存再抢锁最后落库否则可能引发性能问题3. 集群部署实践3.1 服务节点配置建议配置每个Pod限制4核8G内存JVM参数-Xms6g -Xmx6g -XX:UseG1GC线程池配置corePoolSize: 50maxPoolSize: 200queueCapacity: 10003.2 流量控制策略Nginx层限流limit_req_zone $binary_remote_addr zoneone:10m rate100r/s;服务层熔断circuitBreaker: requestVolumeThreshold: 20 sleepWindowInMilliseconds: 5000兜底方案活动预热库存分段释放4. 性能优化方案4.1 缓存策略优化采用多级缓存架构本地缓存Caffeine存储热点用户订单状态Redis集群存储全量订单标记布隆过滤器前置过滤无效请求缓存更新策略创建订单后异步更新设置合理的过期时间建议5-10分钟批量查询优化4.2 数据库优化分库分表策略按用户ID哈希分片每个分片32张表索引优化联合索引(user_id, activity_id)覆盖索引包含常用查询字段SQL优化避免SELECT *使用批量插入5. 问题排查与监控5.1 常见问题排查表问题现象可能原因解决方案锁等待超时锁过期时间设置过短适当延长锁时间重复订单校验流程存在漏洞检查校验顺序服务雪崩线程池配置不合理调整线程池参数5.2 监控指标配置核心监控项分布式锁获取成功率订单创建TPS/QPS平均响应时间错误率特别是锁竞争错误告警阈值建议锁竞争失败率 5%平均RT 500ms错误率 1%6. 实战经验分享在实际落地过程中我们总结了几个关键经验锁粒度控制不要用全局锁应该按活动ID用户ID分段加锁失败重试策略采用指数退避算法避免雪崩压测要点模拟真实用户行为不要均匀请求关注长尾请求监控GC情况一个典型的错误配置案例// 错误示范锁时间固定 jedis.setnx(lock, 1); // 正确做法设置合理过期时间 jedis.set(lock, requestId, NX, PX, 3000);集群环境下还需要特别注意网络分区问题我们的解决方案是使用Redlock算法设置锁自动续期增加锁持有心跳检测最后分享一个性能对比数据单机版最高支持500TPS优化后的集群版8节点稳定支持8000TPS99线从2s降低到200ms