两阶段提交是否适用于保证邮件发送的原子性？相关问题解析

背景场景 #

用户注册表单需要原子执行两个操作：创建用户和发送欢迎邮件，即要么两者都成功，要么都失败。

最初尝试的事务方案：

begin transaction
create user
if creation failed, rollback transaction, bailout
send email
if email sending failed, rollback transaction, bailout
commit transaction

但PostgreSQL中，commit可能因延迟约束（如DEFERRED约束）等原因失败，因此考虑改用两阶段提交方案：

begin transaction
create user
PREPARE TRANSACTION
if creation failed, rollback transaction, bailout
send email
if email sending failed, rollback transaction, bailout
COMMIT PREPARED -- PostgreSQL保证此操作一定成功

但PostgreSQL官方文档明确指出：长时间让事务处于预备状态是不明智的，且该功能的预期用途是：

一旦外部事务管理器确认其他数据库也已准备提交，预备事务通常应立即提交或回滚。

基于此，针对以下疑问逐一解答：

1. 发送邮件耗时是否过长？ #

发送邮件的耗时波动极大：

• 若邮件服务商响应顺畅，可能仅需几百毫秒；
• 若遇到服务商限流、网络波动、邮件含大附件等情况，耗时可能达到数秒甚至更久。
  这种不可控的耗时，很容易让预备事务的等待时长超出合理范围。

2. 这么做会引发哪些问题？ #

• 资源占用：预备事务会持续占用数据库连接、锁资源，长时间不提交/回滚会导致这些资源无法释放，干扰其他数据库操作；
• 数据一致性风险：如果应用进程崩溃、服务器断电，处于预备状态的事务会残留，需手动清理，否则可能导致数据长期处于不确定状态；
• 性能下降：大量预备事务堆积会拖慢数据库整体性能，增加事务日志的存储压力；
• 死锁风险：预备事务持有的锁不会自动释放，若其他事务需要申请冲突锁，可能引发死锁。

3. 若耗时过长，可接受的超时时间是多少？ #

PostgreSQL官方未给出明确数值，但根据实践经验：

• 尽量控制在1秒以内，最长不要超过5秒；
• 核心原则是：预备事务的持续时间要远短于数据库的连接超时、锁等待超时配置，避免引发资源耗尽问题。

4. 预备状态下的数据库锁与提交前空闲状态的锁是否存在差异？ #

两者没有本质差异：

• 预备状态的事务和提交前空闲的事务，都会持有执行过程中获取的所有锁（如行锁、表锁）；
• 唯一区别是：预备事务已完成所有数据修改的持久化准备，仅等待最终的提交/回滚指令；而提交前的事务还可能继续执行后续SQL。但从锁的持有逻辑来看，两者完全一致，都不会主动释放锁，直到事务结束。

内容的提问来源于stack exchange，提问作者Exifers