问题：酒店预订中的分布式事务

让我们将酒店预订系统分解为其核心组件：

  • 预订服务：处理房间可用性和预订
  • 支付服务：处理付款
  • 通知服务：发送确认邮件
  • 忠诚度服务：更新客户积分

现在，想象一个客户预订房间的场景。我们需要：

  1. 检查房间可用性并进行预订
  2. 处理付款
  3. 发送确认邮件
  4. 更新客户的忠诚度积分

听起来很简单，对吧？没那么快。如果付款在我们预订房间后失败怎么办？或者如果通知服务宕机了呢？欢迎来到分布式事务的世界，在这里墨菲定律总是有效的。

引入Sagas：分布式事务中的无名英雄

Saga是一系列本地事务，其中每个事务更新单个服务中的数据。如果某个步骤失败，Saga会执行补偿事务以撤销前面步骤所做的更改。

以下是我们的酒店预订Saga可能的样子：


def book_hotel_room(customer_id, room_id, payment_info):
    try:
        # 步骤1：预订房间
        reservation_id = reservation_service.reserve_room(room_id)
        
        # 步骤2：处理付款
        payment_id = payment_service.process_payment(payment_info)
        
        # 步骤3：发送确认
        notification_service.send_confirmation(customer_id, reservation_id)
        
        # 步骤4：更新忠诚度积分
        loyalty_service.update_points(customer_id, calculate_points(room_id))
        
        return "预订成功！"
    except Exception as e:
        # 如果任何步骤失败，执行补偿操作
        compensate_booking(reservation_id, payment_id, customer_id)
        raise e

def compensate_booking(reservation_id, payment_id, customer_id):
    if reservation_id:
        reservation_service.cancel_reservation(reservation_id)
    if payment_id:
        payment_service.refund_payment(payment_id)
    notification_service.send_cancellation(customer_id)
    # 无需补偿忠诚度积分，因为它们尚未添加

实现幂等性：因为一次并不总是足够

在分布式系统中，网络故障可能导致重复请求。为了解决这个问题，我们需要使操作具有幂等性。引入幂等性键：


def reserve_room(room_id, idempotency_key):
    if reservation_exists(idempotency_key):
        return get_existing_reservation(idempotency_key)
    
    # 执行实际的预订逻辑
    reservation = create_reservation(room_id)
    store_reservation(idempotency_key, reservation)
    return reservation

通过使用幂等性键（通常是客户端生成的UUID），我们确保即使同一请求被多次发送，我们也只创建一个预订。

异步回滚：因为时间不等人

有时，补偿操作无法立即执行。例如，如果支付服务暂时宕机，我们无法立即发起退款。这就是异步回滚的用武之地：


def compensate_booking_async(reservation_id, payment_id, customer_id):
    compensation_tasks = [
        {'service': 'reservation', 'action': 'cancel', 'id': reservation_id},
        {'service': 'payment', 'action': 'refund', 'id': payment_id},
        {'service': 'notification', 'action': 'send_cancellation', 'id': customer_id}
    ]
    
    for task in compensation_tasks:
        compensation_queue.enqueue(task)

# 在一个独立的工作进程中
def process_compensation_queue():
    while True:
        task = compensation_queue.dequeue()
        try:
            execute_compensation(task)
        except Exception:
            # 如果补偿失败，使用指数退避重新入队
            compensation_queue.requeue(task, delay=calculate_backoff(task))

这种方法使我们能够可靠地处理补偿，即使服务暂时不可用。

陷阱：可能出错的地方

虽然Sagas很强大，但它们也有挑战：

  • 复杂性：为每个步骤实现补偿操作可能很棘手。
  • 最终一致性：系统可能在不一致状态下存在一段时间。
  • 缺乏隔离：其他事务可能会看到中间状态。

为减轻这些问题：

  • 使用Saga协调器来管理工作流和补偿。
  • 实现强大的错误处理和日志记录。
  • 考虑对关键资源使用悲观锁定。

回报：为什么要费心做这一切？

你可能会想，“这似乎是很多工作。为什么不直接使用2PC？”原因如下：

  • 可扩展性：Sagas不需要长时间锁定，从而允许更好的可扩展性。
  • 灵活性：服务可以独立更新而不会破坏整个事务。
  • 弹性：即使某些服务暂时宕机，系统也能继续运行。
  • 性能：无需分布式锁意味着更快的整体事务处理。

总结：关键要点

通过使用补偿工作流和Sagas实现没有2PC的分布式事务，为像酒店预订平台这样的复杂系统提供了一个强大且可扩展的解决方案。通过利用幂等性键和异步回滚，我们可以构建能够优雅地处理故障并确保微服务间数据一致性的弹性系统。

记住，目标不是避免故障（在分布式系统中它们是不可避免的），而是优雅地处理它们。通过Sagas，我们不仅仅是在预订酒店房间；我们正在进入一个更可靠和可扩展的分布式事务世界。

“在分布式系统中，故障不仅可能发生，而且是不可避免的。为故障设计，你将为成功而构建。”

现在，继续前进，愿你的事务永远顺利！

进一步阅读

编码愉快，愿你的分布式事务永远顺利和补偿！