一、为什么需要分布式事务？
想象一下这样的场景：你在网上购物，点击支付按钮后，系统需要同时完成三个操作——扣减账户余额、生成订单记录、更新库存数量。这三个操作可能分布在不同的服务器上，如果其中某个步骤失败了，而其他步骤已经成功执行，就会导致数据不一致——比如钱扣了但没生成订单，或者库存减少了但支付没成功。
这就是分布式事务要解决的问题：让多个独立服务上的操作，要么全部成功，要么全部失败回滚。Erlang作为一门天生为分布式而生的语言，提供了优雅的解决方案。
二、Erlang的分布式事务基础
Erlang的分布式事务实现依赖于两个核心机制：进程间通信和错误处理。每个Erlang进程都是独立的，它们通过消息传递进行通信。当我们需要协调多个进程完成一个事务时，可以这样设计：
%% 技术栈：Erlang/OTP
%% 定义一个简单的分布式事务协调器
-module(transaction_coordinator).
-export([start/0, commit/2, rollback/2]).
start() ->
spawn(fun() -> coordinator_loop([]) end).
%% 事务协调器主循环
coordinator_loop(Participants) ->
receive
{join, Pid} ->
%% 新参与者加入事务
NewParticipants = [Pid | Participants],
coordinator_loop(NewParticipants);
{commit, From} ->
%% 发起提交请求
Results = [Pid ! {prepare, self()} || Pid <- Participants],
coordinator_loop_wait(Participants, From, []);
{rollback, From} ->
%% 发起回滚请求
[Pid ! {abort, self()} || Pid <- Participants],
From ! {rolled_back, self()}
end.
%% 等待所有参与者响应
coordinator_loop_wait([], From, Responses) ->
case lists:all(fun(R) -> R == prepared end, Responses) of
true ->
%% 所有参与者准备就绪，执行提交
[Pid ! {commit, self()} || Pid <- Participants],
From ! {committed, self()};
false ->
%% 有参与者准备失败，执行回滚
[Pid ! {abort, self()} || Pid <- Participants],
From ! {rolled_back, self()}
end;
coordinator_loop_wait(Participants, From, Responses) ->
receive
{prepared, Pid} ->
coordinator_loop_wait(lists:delete(Pid, Participants), From, [prepared | Responses]);
{failed, Pid} ->
coordinator_loop_wait(lists:delete(Pid, Participants), From, [failed | Responses])
end.
这个示例展示了一个简单的事务协调器实现。它通过消息传递与参与者进程通信，按照两阶段提交协议(2PC)来协调事务。
三、核心算法：两阶段提交
Erlang实现分布式事务最常用的算法是两阶段提交(2PC)，它分为准备阶段和提交阶段：
- 准备阶段：协调者询问所有参与者是否可以提交
- 提交阶段：根据参与者的响应决定提交或回滚
让我们看一个完整的示例：
%% 技术栈：Erlang/OTP
%% 定义一个银行转账的分布式事务示例
-module(bank_transaction).
-export([transfer/3]).
transfer(FromAccount, ToAccount, Amount) ->
%% 启动事务协调器
Coordinator = transaction_coordinator:start(),
%% 注册参与者（这里简化处理，实际应该是不同的节点进程）
FromPid = account_server:start(FromAccount),
ToPid = account_server:start(ToAccount),
Coordinator ! {join, FromPid},
Coordinator ! {join, ToPid},
%% 准备阶段
case do_prepare(Coordinator, FromPid, ToPid, Amount) of
ok ->
%% 提交阶段
Coordinator ! {commit, self()},
receive
{committed, _} ->
{ok, transfer_completed};
{rolled_back, _} ->
{error, commit_failed}
after 5000 ->
{error, timeout}
end;
{error, Reason} ->
%% 准备失败，回滚
Coordinator ! {rollback, self()},
{error, Reason}
end.
do_prepare(Coordinator, FromPid, ToPid, Amount) ->
%% 向转出账户发送准备请求
FromPid ! {prepare, {debit, Amount}, Coordinator},
%% 向转入账户发送准备请求
ToPid ! {prepare, {credit, Amount}, Coordinator},
%% 等待响应
receive
{prepared, FromPid} ->
receive
{prepared, ToPid} -> ok;
{failed, ToPid} -> {error, to_account_failed}
after 1000 -> {error, to_account_timeout}
end;
{failed, FromPid} -> {error, from_account_failed}
after 1000 -> {error, from_account_timeout}
end.
这个示例模拟了一个银行转账场景。关键点在于：
- 先确保两个账户都能完成操作（准备阶段）
- 只有都准备好了才真正执行转账（提交阶段）
- 任一环节失败都会触发回滚
四、实际应用中的优化
原生2PC有一些缺点，比如协调者单点故障、同步阻塞等。Erlang社区发展出了一些优化方案：
- Saga模式：将大事务拆分为多个小事务，每个小事务有对应的补偿操作
- TCC模式：Try-Confirm-Cancel，比2PC更灵活
- 本地消息表：通过可靠消息队列最终实现一致性
看一个Saga模式的示例：
%% 技术栈：Erlang/OTP
%% 使用Saga模式实现订单创建流程
-module(order_saga).
-export([create_order/1]).
create_order(Order) ->
%% 定义Saga步骤
Steps = [
{reserve_inventory, fun() -> inventory_service:reserve(Order#order.items) end},
{process_payment, fun() -> payment_service:charge(Order#order.customer, Order#order.total) end},
{create_order_record, fun() -> order_service:create(Order) end}
],
%% 定义补偿操作
Compensations = [
{reserve_inventory, fun() -> inventory_service:cancel_reservation(Order#order.items) end},
{process_payment, fun() -> payment_service:refund(Order#order.customer, Order#order.total) end},
{create_order_record, fun() -> order_service:cancel(Order#order.id) end}
],
%% 执行Saga
saga_executor:execute(Steps, Compensations).
%% Saga执行器实现（简化版）
execute([], _) -> ok;
execute([{Name, Op} | Rest], Compensations) ->
case Op() of
{ok, _} ->
execute(Rest, Compensations);
{error, Reason} ->
%% 查找补偿操作
Comp = proplists:get_value(Name, Compensations),
Comp(),
{error, {saga_aborted, Name, Reason}}
end.
Saga模式的优点是：
- 没有全局锁，性能更好
- 每个步骤都是独立事务
- 通过补偿操作保证最终一致性
五、技术选型与注意事项
在实际项目中选用Erlang实现分布式事务时，需要考虑：
适用场景：
- 需要高并发的金融交易系统
- 跨多个微服务的业务操作
- 对数据一致性要求较高的场景
优点：
- Erlang的轻量级进程模型非常适合实现协调器
- 内置的分布式通信机制简化了开发
- "Let it crash"哲学配合事务处理很自然
缺点：
- 2PC存在同步阻塞问题
- 协调者单点故障风险
- 网络分区时可能进入阻塞状态
注意事项：
- 一定要实现超时机制，避免无限等待
- 考虑添加重试逻辑处理临时故障
- 记录详细日志以便问题排查
- 对于长时间运行的事务，考虑拆分为小事务
六、总结
Erlang为分布式事务提供了强大的基础能力，从简单的2PC到复杂的Saga模式，开发者可以根据业务需求选择合适的实现方式。关键是要理解不同算法的适用场景和限制，在一致性和性能之间找到平衡点。
在实际应用中，建议从小规模开始，逐步验证事务实现的正确性，再扩展到生产环境。Erlang的热代码加载特性也使得我们可以在不停止系统的情况下更新事务逻辑，这对需要高可用的系统尤为重要。
评论