招聘系统源码实战：分布式事务与数据一致性的JAVA实现方案

在分布式招聘系统中，多个微服务（如用户服务、职位服务、简历服务等）需要协同完成复杂业务（如用户申请职位并上传简历），此时分布式事务与数据一致性成为核心挑战。以下是基于JAVA的完整实现方案，涵盖技术选型、核心模式、源码示例及最佳实践。

一、分布式事务的核心问题

1.1 典型场景

用户申请职位并上传简历：需同时更新用户申请记录（用户服务）、职位申请状态（职位服务）、简历存储（简历服务）。
企业发布职位并支付费用：需同时创建职位（职位服务）、扣减账户余额（支付服务）、记录日志（审计服务）。

1.2 挑战分析

CAP定理：分布式系统无法同时满足一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance），需在强一致性（CP）与最终一致性（AP）间权衡。
事务模式选择：需根据业务场景选择合适的事务模式（如TCC、SAGA、2PC、本地消息表）。

二、分布式事务实现方案

方案1：TCC（Try-Confirm-Cancel）模式

适用场景：强一致性要求高、允许短时间锁定的业务（如订单支付）。
核心流程：

Try阶段：预留资源（如锁定用户余额、创建临时申请记录）。
Confirm阶段：提交事务（如扣减余额、更新申请状态）。
Cancel阶段：回滚事务（如释放余额、删除临时记录）。

源码示例：

java

// 用户服务：Try阶段
@Transactional
public boolean tryApply(Long userId, Long jobId) {
// 1. 检查用户余额是否充足
User user = userRepository.findById(userId).orElseThrow();
if (user.getBalance() < 100) { // 假设申请需100元
throw new RuntimeException("余额不足");
}
// 2. 锁定余额（预留资源）
user.setLockedBalance(user.getLockedBalance() + 100);
userRepository.save(user);
// 3. 创建临时申请记录
ApplyRecord record = new ApplyRecord(userId, jobId, "TRYING");
applyRecordRepository.save(record);
return true;
}
// 简历服务：Confirm阶段
@Transactional
public boolean confirmApply(Long applyId) {
ApplyRecord record = applyRecordRepository.findById(applyId).orElseThrow();
record.setStatus("CONFIRMED");
// 1. 存储简历（实际业务逻辑）
resumeStorageService.storeResume(record.getUserId(), record.getJobId());
// 2. 更新职位申请状态
jobService.updateApplyCount(record.getJobId());
return true;
}
// 支付服务：Cancel阶段
@Transactional
public boolean cancelApply(Long userId) {
User user = userRepository.findById(userId).orElseThrow();
// 1. 释放锁定余额
user.setLockedBalance(user.getLockedBalance() - 100);
userRepository.save(user);
// 2. 删除临时申请记录
applyRecordRepository.deleteByUserId(userId);
return true;
}

优缺点：

优点：高一致性、低延迟。
缺点：实现复杂、需业务代码侵入。

方案2：SAGA模式（最终一致性）

适用场景：长流程业务（如企业发布职位并支付费用）、允许短时间不一致。
核心流程：

正向操作：按顺序执行子事务（如创建职位、扣减余额）。
补偿操作：按逆序回滚子事务（如删除职位、返还余额）。

源码示例：

java

// SAGA协调器
public class SagaCoordinator {
public void executeSaga(Long jobId, Long userId) {
try {
// 1. 创建职位（正向操作）
jobService.createJob(jobId);
// 2. 扣减余额（正向操作）
paymentService.deductBalance(userId, 1000);
// 3. 记录日志（正向操作）
auditService.log("职位发布成功");
} catch (Exception e) {
// 4. 回滚：返还余额（补偿操作）
paymentService.refundBalance(userId, 1000);
// 5. 回滚：删除职位（补偿操作）
jobService.deleteJob(jobId);
// 6. 回滚：记录失败日志（补偿操作）
auditService.log("职位发布失败，已回滚");
throw e;
}
}
}

优缺点：

优点：实现简单、支持长流程。
缺点：最终一致性、需补偿逻辑。

方案3：本地消息表（异步最终一致性）

适用场景：非核心业务（如用户注册后发送欢迎邮件）、允许延迟一致性。
核心流程：

业务操作：执行主事务（如用户注册）。
记录消息：将待执行操作写入本地消息表。
消息消费：异步任务消费消息并执行（如发送邮件）。

源码示例：

java

// 用户服务：业务操作与消息记录
@Transactional
public void registerUser(User user) {
// 1. 保存用户
userRepository.save(user);
// 2. 记录消息
LocalMessage message = new LocalMessage(
"SEND_WELCOME_EMAIL",
user.getId(),
user.getEmail(),
"PENDING"
);
localMessageRepository.save(message);
}
// 异步任务：消费消息
@Scheduled(fixedRate = 5000)
public void processMessages() {
List<LocalMessage> pendingMessages = localMessageRepository.findByStatus("PENDING");
for (LocalMessage message : pendingMessages) {
try {
// 1. 发送邮件
emailService.sendWelcomeEmail(message.getEmail());
// 2. 更新消息状态
message.setStatus("COMPLETED");
localMessageRepository.save(message);
} catch (Exception e) {
// 3. 失败重试或记录日志
message.setStatus("FAILED");
localMessageRepository.save(message);
}
}
}

优缺点：

优点：实现简单、无业务侵入。
缺点：最终一致性、需处理重复消息。

三、数据一致性保障策略

3.1 幂等性设计

唯一标识：为每个操作生成唯一ID（如申请ID、消息ID），避免重复处理。
状态机：通过状态字段（如PENDING、COMPLETED、FAILED）控制操作流程。

源码示例：

java

// 幂等性检查
public boolean isIdempotent(String operationId) {
return localMessageRepository.existsByOperationIdAndStatus(operationId, "COMPLETED");
}

3.2 分布式锁

Redis分布式锁：在关键操作前加锁，避免并发冲突。

java

public boolean tryLock(String lockKey, long expireTime) {
Boolean success = redisTemplate.opsForValue().setIfAbsent(lockKey, "LOCKED", expireTime, TimeUnit.SECONDS);
return Boolean.TRUE.equals(success);
}

3.3 补偿机制

定时任务：定期扫描失败任务并重试。
人工干预：对无法自动补偿的任务，提供人工处理入口。

四、方案对比与选择

方案	一致性	实现复杂度	适用场景
TCC	强一致性	高	订单支付、资金冻结等核心业务
SAGA	最终一致性	中	长流程业务（如企业发布职位）
本地消息表	最终一致性	低	非核心业务（如发送邮件、日志记录）