由于数据量的巨大,大部分Web应用都需要部署很多个数据库实例。这样,有些用户操作就可能需要去修改多个数据库实例中的数据。传统的解决方法是使用分布式事务保证数据的全局一致性,经典的方法是使用两阶段提交协议。
长期以来,分布式事务提供的优雅的全局ACID保证麻醉了应用开发者的心灵,很多人都不敢越雷池一步,想像没有分布式事务的世界会是怎样。如今就如MySQL和PostgreSQL这类面向低端用户的开源数据库都支持分布式事务了,开发者更是沉醉其中,不去考虑分布式事务是否给系统带来了伤害。
事实上,有所得必有所失,分布式事务提供的ACID保证是以损害系统的可用性、性能与可伸缩性为代价的。只有在参与分布式事务的各个数据库实例都能够正常工作的前提下,分布式事务才能够顺利完成,只要有一个工作不正常,整个事务就不能完成。这样,系统的可用性就相当于参加分布式事务的各实例的可用性之积,实例越多,可用性下降越明显。从性能和可伸缩性角度看,首先是事务的总持续时间通常是各实例操作时间之和,因为一个事务中的各个操作通常是顺序执行的,这样事务的响应时间就会增加很多;其次是一般Web应用的事务都不大,单机操作时间也就几毫秒甚至不到1毫秒,一但涉及到分布式事务,提交时节点间的网络通信往返过程也为毫秒级别,对事务响应时间的影响也不可忽视。由于事务持续时间延长,事务对相关资源的锁定时间也相应增加,从而可能严重增加了并发冲突,影响到系统吞吐率和可伸缩性。
正是由于分布式事务有以上问题,eBay在设计上就不采用分布式事务,而是通过其它途径来解决数据一致性问题。其中使用的最重要的技术就是消息队列和消息应用状态表。
举个例子。假设系统中有以下两个表
user(id, name, amt_sold, amt_bought)
transaction(xid, seller_id, buyer_id, amount)
其中user表记录用户交易汇总信息,transaction表记录每个交易的详细信息。
这样,在进行一笔交易时,若使用事务,就需要对数据库进行以下操作:
begin;
INSERT INTO transaction VALUES(xid, $seller_id, $buyer_id, $amount);
UPDATE user SET amt_sold = amt_sold + $amount WHERE id = $seller_id;
UPDATE user SET amt_bought = amt_bought + $amount WHERE id = $buyer_id;
commit;
即在transaction表中记录交易信息,然后更新卖家和买家的状态。
假设transaction表和user表存储在不同的节点上,那么上述事务就是一个分布式事务。要消除这一分布式事务,将它拆分成两个子事务,一个更新transaction表,一个更新user表是不行的,因为有可能transaction表更新成功后,更新user失败,系统将不能恢复到一致状态。
解决方案是使用消息队列。如下所示,先启动一个事务,更新transaction表后,并不直接去更新user表,而是将要对user表进行的更新插入到消息队列中。另外有一个异步任务轮询队列内容进行处理。
begin;
INSERT INTO transaction VALUES(xid, $seller_id, $buyer_id, $amount);
put_to_queue “update user(“seller”, $seller_id, amount);
put_to_queue “update user(“buyer”, $buyer_id, amount);
commit;
for each message in queue
begin;
dequeue message;
if message.type = “seller” then
UPDATE user SET amt_sold = amt_sold + message.amount WHERE id = message.user_id;
else
UPDATE user SET amt_bought = amt_bought + message.amount WHERE id = message.user_id;
end
commit;
end
上述解决方案看似完美,实际上还没有解决分布式问题。为了使第一个事务不涉及分布式操作,消息队列必须与transaction表使用同一套存储资源,但为了使第二个事务是本地的,消息队列存储又必须与user表在一起。这两者是不可能同时满足的。
如果消息具有操作幂等性,也就是一个消息被应用多次与应用一次产生的效果是一样的话,上述问题是很好解决的,只要将消息队列放到transaction表一起,然后在第二个事务中,先应用消息,再从消息队列中删除。由于消息队列存储与user表不在一起,应用消息后,可能还没来得及将应用过的消息从队列中删除时系统就出故障了。这时系统恢复后会重新应用一次这一消息,由于幂等性,应用多次也能产生正确的结果。
但实际情况下,消息很难具有幂等性,比如上述的UPDATE操作,执行一次和执行多次的结束显然是不一样的。解决这一问题的方法是使用另一个表记录已经被成功应用的消息,并且这个表使用与user表相同的存储。假设增加以下表 message_applied(msg_id)记录被成功应用的消息,则产生最终的解决方案如下:
begin;
INSERT INTO transaction VALUES(xid, $seller_id, $buyer_id, $amount);
put_to_queue “update user(“seller”, $seller_id, amount);
put_to_queue “update user(“buyer”, $buyer_id, amount);
commit;
for each message in queue
begin;
SELECT count(*) as cnt FROM message_applied WHERE msg_id = message.id;
if cnt = 0 then
if message.type = “seller” then
UPDATE user SET amt_sold = amt_sold + message.amount WHERE id = message.user_id;
else
UPDATE user SET amt_bought = amt_bought + message.amount WHERE id = message.user_id;
end
INSERT INTO message_applied VALUES(message.id);
end
commit;
if 上述事务成功
dequeue message
DELETE FROM message_applied WHERE msg_id = message.id;
end
end
我们来仔细分析一下:
1、消息队列与transaction使用同一实例,因此第一个事务不涉及分布式操作;
2、message_applied与user表在同一个实例中,也能保证一致性;
3、第二个事务结束后,dequeue message之前系统可能出故障,出故障后系统会重新从消息队列中取出这一消息,但通过message_applied表可以检查出来这一消息已经被应用过,跳过这一消息实现正确的行为;
4、最后将已经成功应用,且已经从消息队列中删除的消息从message_applied表中删除,可以将message_applied表保证在很小的状态(不清除也是可以的,不影响系统正确性)。由于消息队列与message_applied在不同实例上,dequeue message之后,将对应message_applied记录删除之前可能出故障。一但这时出现故障,message_applied表中会留下一些垃圾内容,但不影响系统正确性,另外这些垃圾内容也是可以正确清理的。
虽然由于没有分布式事务的强一致性保证,使用上述方案在系统发生故障时,系统将短时间内处于不一致状态。但基于消息队列和消息应用状态表,最终可以将系统恢复到一致。使用消息队列方案,解除了两个数据库实例之间的紧密耦合,其性能和可伸缩性是分布式事务不可比拟的。
当然,使用分布式事务有助于简化应用开发,使用消息队列明显需要更多的工作量,两者各有优缺点。个人观点是,对于时间紧迫或者对性能要求不高的系统,应采用分布式事务加快开发效率,对于时间需求不是很紧,对性能要求很高的系统,应考虑使用消息队列方案。对于原使用分布式事务,且系统已趋于稳定,性能要求高的系统,则可以使用消息队列方案进行重构来优化性能。
相关推荐
互联网领域中的分布式事务解决方案多样化,包括业务接口整合,即将相关业务接口封装成单一服务以避免分布式事务。另一种流行方案是采用服务最终一致性,比如eBay提出的BASE原则,通过消息队列实现异步处理和人工重试...
在工程领域,分布式事务的讨论主要聚焦于强一致性和最终一致性的解决方案。典型方案包括:两阶段提交(2PC,Two-phaseCommit)方案。eBay事件队列方案。TCC补偿模式。缓存数据最终一致性。分布式事务的目的是保障分库...
3. 避免分布式事务:eBay尽量减少对分布式事务的依赖,因为它们会严重影响伸缩性、性能和响应时间。实际操作中,采用放宽对跨系统事务一致性的要求,以提高系统的可伸缩性和可用性。 详细分析: 可伸缩性是eBay...
经过多年的发展,各数据库厂商提出了多种分布式事务解决方案,例如两阶段提交(2PC)/三阶段提交(3PC)、TCC方案、可靠消息最终一致性(本地消息表方案-eBay、RocketMQ 事务消息方案-阿里/Apache)、最大努力通知...
通过对CAP定理和BASE理论的理解,结合eBay模式、去哪儿网分布式事务方案以及蘑菇街自身的分布式一致性方案,我们可以看到不同场景下解决数据一致性问题的具体方法。在实际应用中,根据具体的业务需求和技术约束,...
NewSQL数据库,如TiDB、Spanner等,旨在提供分布式事务、强一致性和高并发性能。在这种实践中,eBay面临的挑战包括每天上亿次的更新事件,10,000到80,000 QPS的查询压力,以及保持低延迟和高可用性。系统采用了6个...
- 介绍了分布式事务处理、分布式搜索和智能物流系统的实现。 5. **豆瓣架构** (douban_qcon2009_beijing.pdf): - 豆瓣的架构侧重于社区和内容分享功能,涉及用户行为分析和推荐系统。 - 探讨了如何利用缓存技术...
- **事务性**:Delta 使用分布式事务日志确保数据的一致性,即使在大规模并发操作下也能保证数据完整性。 - **时间旅行**:通过记录每次更改,Delta 允许用户回溯到历史数据的任何版本,这对于数据分析和错误修复...
在分布式事务方面,微店采用了tcc分布式事务框架,通过Ebay两阶段提交同步、支付宝异步Try同步、淘宝TXC同步等机制,确保事务的强一致性。微店的技术演进之路通过不断的技术创新和架构优化,有效应对了电商平台所...
J2EE是一个由Sun Microsystems开发的企业级应用平台,它提供了一套标准化的组件模型和APIs,用于构建高度可伸缩、可移植、可重用和可管理的多层分布式企业应用。 ### 重要知识点解析: #### J2EE的核心模式 J2EE...
因此,企业通常采用数据分发技术,将业务数据实时同步到其他服务,以实现高可用、数据库解耦、CQRS(命令查询职责分离)、分布式事务处理等目标。 数据分发的常见场景包括数据复制以实现高可用性,数据库解耦以支持...
在eBay这样的大型系统中,数据量巨大,查询需求频繁,MySQL的InnoDB存储引擎提供了行级锁定和事务处理能力,确保了数据的一致性和完整性。此外,通过主从复制和分片技术,可以实现数据的分布式存储和负载均衡,从而...
两阶段提交协议是分布式事务的一种解决方案,包括 prepare 和 commit 两个阶段。 时间戳是分布式系统中的一种版本控制机制,每个节点可以为每一份或一组数据附加一个时间戳标记。向量时钟是分布式系统中的一种 ...
Vitess虽然不支持原生的分布式事务,但它通过"Best Effort"的一致性模型,实现了最终一致性,对于大多数业务场景来说,这种模式已经足够。 性能方面,两者都有各自的优化策略。TiDB在设计时就考虑了大数据量的处理...
- 避免分布式事务。 - 通过状态机和仔细的操作排序来最小化不一致性。 - 通过异步恢复或对账来实现最终一致性。 6. **预期变化** - 变化是唯一不变的常量。 - 新实体和数据元素不断出现。 - 基础设施持续...
- **PNUTS**:Yahoo的分布式数据存储系统,支持大规模在线事务处理。 - **CouchDB**:JSON文档存储数据库,支持分布式和版本控制。 - **MongoDB**:流行的文档型数据库,适合处理半结构化数据。 - **SimpleDB**...
- **Riak**:一个高度可用且分布式的数据存储解决方案。 - **Terrastore**:基于HBase的分布式键值存储系统。 - **ThruDB**:一种基于HBase的键值存储系统。 - **键值/元组存储** - **Amazon之SimpleDB**:一种...