3天搞定新参保人员办理流程：面试必问的社保系统实战
昨天帮哥们改简历，他问我一个离谱的问题：“我写的社保参保模块，为什么线上数据对不上，本地测试明明没问题？”
复制来的代码跑不通不知道怎么调，这是90%后端新人的噩梦。
社保业务看着简单，其实全是坑。尤其是新参保人员办理流程，涉及身份核验、险种关联、账户生成，稍微错一个字段，整个事务就回滚了。
更扎心的是，这块逻辑是面试必问的重灾区。面试官不只看你会不会写接口，更看你懂不懂背后的业务闭环。
别慌，今天带你从零搭一个可运行的参保服务。不玩虚的，直接上代码，把那些藏在水面下的坑全挖出来。
项目目标与业务拆解
很多人一上来就建表，这是大忌。
社保系统不是简单的CRUD，它是一套状态机。
我们要实现的核心功能只有两个：
- 参保登记：接收用户信息，生成社保号，关联险种。
- 流程追踪：每一步操作都要有日志，方便审计。
业务难点在于幂等性。
如果用户网络抖动，点了两次“提交”，你的系统能不能只生成一个社保号？
如果直接插入数据库，就会报错；如果做去重，怎么保证并发下的唯一性？
这就是为什么很多外包代码上线后，经常出现“一人多号”或“重复扣款”。
我们的目标很明确：
- 使用 Spring Boot + MyBatis Plus
- 数据库选 MySQL 8.0
- 引入 Redis 做分布式锁
- 日志记录用 SLF4J
别觉得技术栈老套，GitHub 开源仓库里搜 social-security-demo，你会发现90%的企业项目还在用这套组合。稳定，比炫技重要。
目录结构与模块划分
先搭骨架，再填肉。
social-security-service/
├── src
│ ├── main
│ │ ├── java
│ │ │ └── com.example
│ │ │ ├── controller
│ │ │ ├── service
│ │ │ ├── mapper
│ │ │ ├── entity
│ │ │ └── config
│ │ └── resources
│ │ ├── application.yml
│ │ └── mapper
└── pom.xml
重点看 service 包下的 InsureService。
这是核心业务层，所有逻辑都在这里。
mapper 包对应数据库操作，entity 是数据对象。
很多人喜欢把业务逻辑写在 Controller 里，这是新手通病。
Controller 只做参数校验和响应封装，业务逻辑必须下沉到 Service 层。
这样后续如果要加缓存、加消息队列，只需要改 Service，不用动 Controller。
config 包里放 Redis 配置和事务管理器。
注意，事务注解 @Transactional 只能加在 Spring 管理 Bean 的方法上，别加在普通类里，否则不生效。
核心代码实现与避坑
先看实体类。
@Entity
@Data
public class InsureRecord {@Id@GeneratedValue(strategy = GenerationType.IDENTITY)private Long id;private String userId;private String socialNo;private String status; // INIT, PROCESSING, SUCCESS, FAILEDprivate LocalDateTime createTime;private LocalDateTime updateTime;
}
字段不多，但 status 字段是关键。
很多人只用 create_time 判断状态，这是错的。
状态必须显式定义，方便后续查询和统计。
接下来是核心 Service。
@Service
@Slf4j
public class InsureServiceImpl implements InsureService {@Autowiredprivate RedisTemplate<String, String> redisTemplate;@Autowiredprivate InsureMapper insureMapper;@Override@Transactional(rollbackFor = Exception.class)public Result<String> createInsure(InsureDTO dto) {// 1. 幂等性校验String lockKey = "insure:lock:" + dto.getUserId();Boolean locked = redisTemplate.opsForValue().setIfAbsent(lockKey, "1", 10, TimeUnit.SECONDS);if (!Boolean.TRUE.equals(locked)) {log.warn("重复提交: userId={}", dto.getUserId());return Result.fail("请勿重复提交");}try {// 2. 检查是否已参保InsureRecord existing = insureMapper.selectByUserId(dto.getUserId());if (existing != null) {return Result.fail("用户已参保");}// 3. 生成社保号String socialNo = generateSocialNo(dto.getUserId());// 4. 保存记录InsureRecord record = new InsureRecord();record.setUserId(dto.getUserId());record.setSocialNo(socialNo);record.setStatus("PROCESSING");record.setCreateTime(LocalDateTime.now());record.setUpdateTime(LocalDateTime.now());insureMapper.insert(record);// 5. 异步处理后续流程asyncProcess(record.getId());return Result.success(socialNo);} finally {// 6. 释放锁redisTemplate.delete(lockKey);}}private String generateSocialNo(String userId) {// 简单示例，实际应使用雪花算法或号段模式return "SN" + System.currentTimeMillis() + userId.hashCode();}
}
逐行拆解这段代码，全是干货。
第1步：Redis 分布式锁。
setIfAbsent 是原子操作，确保同一时间只有一个请求能进来。
10秒过期时间，防止服务宕机导致死锁。
这里有个坑：如果业务执行超过10秒，锁会自动释放，其他请求就能进来了。
解决方案是引入 Redisson，它支持看门狗机制，自动续期。
第2步：数据库查重。
为什么不用唯一索引？
因为社保号是生成的，用户ID才唯一。
如果用户ID没加唯一索引，这里查出来是 null，但数据库里其实有数据，就会插入重复记录。
所以，用户ID 必须加唯一索引。
第3步：社保号生成。
我用了时间戳+哈希，简单粗暴。
生产环境建议用号段模式，比如每次从数据库取1000个号，缓存在内存里。
这样既快，又保证全局唯一。
第4步：状态设为 PROCESSING。
不是 SUCCESS，因为后续还有险种关联、账户激活等步骤。
如果直接设 SUCCESS，一旦后续步骤失败，状态就错了。
第5步：异步处理。
asyncProcess 是个异步方法，不阻塞主线程。
用户拿到社保号就可以走了，后台慢慢处理。
第6步：释放锁。
finally 块里删除锁，确保无论成功失败，锁都会被释放。
这里有个经典 Bug：如果当前线程持有的锁被其他线程释放了怎么办？
Redis 锁应该存线程ID，释放时校验。
但为了简化，这里先不管，面试时可以提一嘴。
运行与测试实战
代码写完了，怎么测？
别只测 Happy Path（正常流程）。
要测边界情况。
测试场景1：并发提交。
用 JMeter 或 Postman，同时发100个相同用户ID的请求。
预期结果：只有1个成功，99个返回“请勿重复提交”。
如果超过1个成功，说明锁没起作用。
测试场景2：网络超时。
模拟 Redis 连接超时。
预期结果：请求快速失败，而不是卡住。
检查代码里有没有设置合理的超时时间。
测试场景3：数据库故障。
手动断开数据库连接。
预期结果：事务回滚，锁被释放，没有脏数据。
如果锁没释放，其他请求会一直阻塞，直到锁过期。
测试场景4：重复提交不同险种。
用户先买了医保，再想加购养老。
预期结果：不应该报错，而是更新记录，增加险种。
如果直接返回“用户已参保”，就是业务逻辑太死板。
建议在 InsureRecord 里加个 insureTypes 字段，用 JSON 存储。
每次提交时，检查是否已存在，存在则更新，不存在则插入。
这就是 UPSERT 逻辑。
MyBatis Plus 里可以用 saveOrUpdate 方法，但要注意并发。
还是得加锁。
日志怎么看？
打开 logback.xml，配置文件输出。
搜索 userId，能看到完整的调用链路。
如果日志里只有“请求成功”，没有“生成社保号”、“保存记录”等细节，等于白写。
日志是排查问题的眼睛，别偷懒。
优化扩展与进阶技巧
基础功能跑通了，怎么让它更健壮？
1. 引入消息队列。
asyncProcess 方法现在是用线程池执行的，如果服务重启，任务就丢了。
改成发 Kafka 消息，消费者慢慢处理。
这样即使服务重启，消息还在队列里，不会丢。
2. 分库分表。
用户量大了之后，单表性能扛不住。
按用户ID哈希分库，按时间分表。
查询时，必须带用户ID，不能全表扫描。
3. 监控告警。
加 Prometheus + Grafana。
监控指标：
- 参保成功率
- 平均响应时间
- 锁等待时间
如果成功率低于95%，立刻报警。
4. 安全加固。
用户ID 不能明文传输，要加密。
社保号 生成后，不要直接返回给前端，要脱敏。
比如只显示前4位和后4位。
5. 容错设计。
如果 Redis 挂了，怎么办？
降级到本地缓存，或者直接查数据库（加锁）。
别一上来就依赖 Redis，要有 Plan B。
小结与行业思考
这套流程，看着简单，其实涵盖了分布式系统的核心问题：
- 一致性：事务保证
- 可用性：Redis 锁 + 异步
- 幂等性：唯一索引 + 状态机
面试必问的，从来不是“你会不会写”，而是“你为什么这么写”。
如果你能讲清楚：
- 为什么用 Redis 锁而不是数据库锁？
- 为什么状态要分 PROCESSING 和 SUCCESS？
- 如果锁过期了，业务还在执行，怎么办？
面试官会对你刮目相看。
回到开头那个问题：复制来的代码跑不通不知道怎么调。
原因很简单：你只看了代码，没看业务。
社保系统不是技术堆砌，是业务逻辑的数字化。
你要先懂业务，再写代码。
不懂业务，再牛的技术也是空中楼阁。
你公司项目里是怎么处理的？欢迎评论。
特别是关于锁的粒度，你们是用 Redis 锁还是数据库乐观锁？
或者有没有更优雅的幂等方案？
评论区聊聊，咱们一起避坑。
