php处理分布式事务的思考(转)
来源:互联网 发布:苹果笔记本设计软件 编辑:程序博客网 时间:2024/06/06 01:29
以下文章来源其他博客
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
一次面试时,被一个CTO鄙视了,他问我PHP有什么做不了的。 我答:只要是Web程序,大部分都没啥问题。 他说:分布式事务,PHP无能为力。 我无言以对(因为我不懂a)
从此,我就经常会想起这个问题,分布式事务实现真的有语言限制吗? 为此我小小地分析了一下跨数据库事务的方方面面。
Mysql完成一个完整xa事务的典型过程。
- XA START 'xatest';
- INSERT INTO user VALUES(1,'Colin');
- INSERT INTO user VALUES(2,'Colin');
- XA END 'xatest';
- XA PREPARE 'xatest';
- XA COMMIT 'xatest';
要想了解跨数据库事务处理,必须彻底清楚两阶段提交协议(2PC),请参考http://jroller.com/pyrasun/category/XA。
根据2PC,PHP如果想实现跨数据库事务处理,那么他担当的角色相当于事务管理器(TM), PHP实现事务管理器几乎从没人提及。在此抛砖引玉。
根据2PC,事务过程可细分为3个阶段:
引用
1pc
2pc-prepare阶段
2pc-committ阶段
2pc-prepare阶段
2pc-committ阶段
1pc,2pc-prepare阶段每个分支事务执行失败应该都不是问题,因为只要在2pc-committ阶段之前,都可以用rollback方法。问题就在于commit阶段,假设第一个分支事务已经执行成功,但是第二个事务执行失败,那么如何保持两个数据库数据一致。事务管理器的作用就是要保证两个数据库的提交都回滚、要么保证数据库的提交都成功。
主流2pc的做法是设法让失败的事务提交成功,而不是让成功的事务回滚。如果非要让成功的事务回滚,那么只能是数据库库管理员根据服务器Log手动回滚了(或者有个补偿式参考http://www.atomikos.com/Publications/TryCancelConfirm)
下面就php如何实现2pc-commit阶段关键问题探讨
问题1: 假设有两个分支事务,第一个提交成功了,第二个由于数据库服务器突然宕机导致失败,怎么保证一致性?
问题2: 同样假设有两个分支事务,第一个提交成功了,实际第二个也提交成功了,只是在返回成功消息给PHP端事务管理器(TM)的时候,网络中断,但是TM此时认为第二个事务是失败的,如何处理一致性?
- function xa_transaction() {
- // 假设有两个数据库$db1,$db2
- $dbs = {$db1, $db2};
- /** 1pc: 忽略 */
- /** 2pc - prepare 忽略 */
- /** 2pc - committ */
- // 首先得记录那些失败的分支事务
- $errs = array();
- foreach($dbs AS $db) {
- //记录失败的db
- if(!$db->commit()) {
- $errs[] = $db;
- } else {
- tm_log('committed') // 事务管理器日志记录committed.
- }
- }
- // 反复执行那些失败的事务,直到成功(不回滚成功的分支事务,而是提交失败的分支事务)
- foreach($errs AS $db) {
- $prepared_tranaction = $db->recover();
- if(prepared_tranaction is null) { // 针对问题2,更新事务管理器日志记录为committed.
- tm_log('committed') // 事务管理器日志记录committed.
- } else { // 针对问题1,重新提交
- $db->commit();
- }
- }
- }
有必要说明的是这里的关键代码:$db->recover();
其对应着mysql的sql命令xa recover, 该SQL可以查询处当前处于prepared状态还没有committ的事务, 从而可以判定是否要重新提交该分支事务还是简单记录tm端log状态
问题3: 同样假设有两个分支事务,第一个提交成功了,但当刚准备执行第二个事务时,客户端垮掉了。如何保证一致性?
此时,是一个重要的考验TM的地方,它必须有个机制保证客户端重启时,能够重新构造这个全局事务,正确判定其中哪个分支事务没有成功。保证这个机制的实现就是LOG,这个Log在TM端保存,在全局事务的每个关键步骤,TM都应该记录分支事务执行状态,对于该情况导致的问题,当客户端恢复的时候,它分析Log找出失败的事务重新执行其面的提到的xa_transaction().
以下是一个TM/RM的网络结构,仅供参考。
看英文真的头大,此文一半分析一半猜想,恳请懂行的给出正确指导和纠正。
0 0
- php处理分布式事务的思考(转)
- 分布式事务的处理
- 分布式事务两阶段提交(2PC)的思考
- 生产分布式事务的处理
- 分布式事务:总结与思考
- com+分布式事务故障的处理
- 分布式服务的事务如何处理
- 分布式服务的事务如何处理
- 处理分布式事务一致性的方法
- 事务模型与分布式事务总结思考
- 分布式事务故障处理
- 分布式事务故障处理
- 分布式事务故障处理
- php + mysql 分布式事务(xa)
- php + mysql 分布式事务
- jdbc 分布式事务(转)
- PHP处理日志的一点思考
- PHP字符串处理的思考与记录
- jeecms导入myeclipse
- Digit Generator
- 防SQL注入
- 持久化API(JPA)系列(六)实体关系映射(ORM)之映射类型
- JSONObject与JSONArray的使用
- php处理分布式事务的思考(转)
- 使用Node.js+Socket.IO搭建WebSocket实时应用
- poj 2236 Wireless Network
- 第七天Object类和异常
- Linux配置防火墙,开启80端口、3306端口 可能会遇到的小问题
- CSS中背景图片定位
- VC6.0 CXX0017:Error:symbol "xxx" not found问题解决方法
- ios基础入门——malloc方法
- java中的反射 2.3——类:发现类成员@译自Oracle官方文档