Marten项目中的异步守护进程锁丢失处理机制

背景与问题

在分布式系统中，使用PostgreSQL作为事件存储和消息队列时，Marten项目提供了一个异步守护进程(async daemon)来处理事件投影。这个守护进程通过PostgreSQL的咨询锁(advisory lock)机制来确保在集群环境中只有一个节点能够执行投影处理任务。

然而，当PostgreSQL实例重启时，可能会出现一个潜在问题：另一个集群节点可能在恢复过程中获取相同的锁，导致多个异步守护进程并行运行。这种情况会破坏事件处理的幂等性，可能导致数据不一致。

解决方案

Marten项目团队针对这个问题提出了以下技术改进方案：

1. 锁状态检测机制：在守护进程运行期间，定期检查是否仍然持有PostgreSQL的咨询锁。如果发现锁丢失，立即触发异常处理流程。

2. 异常处理改进：将ProjectionProgressException异常移动到JasperFx.Events基础库中，使其可以被更广泛地使用。当守护进程检测到锁丢失时，抛出此异常。

3. 自动关闭机制：SubscriptionAgent(订阅代理)在捕获到ProjectionProgressException异常时，会自动关闭自身，防止继续处理事件。

4. 与Wolverine集成：在文档中建议用户使用Wolverine分发机制，它提供了更健壮的分布式处理能力。

技术实现细节

咨询锁检测

PostgreSQL的咨询锁是一种应用程序级别的锁机制，不绑定到特定表或行。Marten利用这种锁来实现分布式协调：

// 伪代码：检查是否仍然持有锁
bool stillHasLock = CheckAdvisoryLock(lockId);
if (!stillHasLock)
{
    throw new ProjectionProgressException("Lost advisory lock");
}

异常处理流程

当锁丢失时，系统会抛出ProjectionProgressException。订阅代理捕获此异常后的处理逻辑：

try
{
    // 正常处理事件
}
catch (ProjectionProgressException ex)
{
    _logger.LogError(ex, "Lost projection progress lock");
    StopAsync(); // 优雅停止守护进程
}

集群环境下的恢复

在PostgreSQL重启后，集群中的其他节点会尝试获取锁。第一个成功获取锁的节点将成为新的主节点，继续处理事件投影。这种机制确保了高可用性，同时避免了重复处理。

最佳实践

1. 监控与告警：实现监控机制，当守护进程因锁丢失而停止时，触发告警。

2. 自动重启策略：结合容器编排系统(如Kubernete)实现自动重启策略，但需要确保不会导致多个实例同时运行。

3. 日志记录：详细记录锁获取和丢失的事件，便于故障排查。

4. 测试验证：在测试环境中模拟PostgreSQL重启场景，验证守护进程的行为是否符合预期。

总结

Marten通过改进异步守护进程的锁处理机制，有效解决了PostgreSQL重启可能导致的多个守护进程并行运行的问题。这一改进增强了系统的可靠性和一致性，特别是在分布式部署场景下。开发者现在可以更放心地使用Marten的事件投影功能，而不必担心因数据库重启导致的数据一致性问题。