LzwGlory的专栏

关键字：事务补偿机制 淘宝梁飞分析分布式 文章：http://javatar.iteye.com/blog/981787 可以设想一个最简单的分布式事务场景，对于跨银行的转账操作，该操作涉及到调用两个异地的Service服务，一个是本地提供的取款服务，一个是目标银行提供的存款服务，该两个服务本身无状态且独立，构成一个完整的事务。对于事务的处理初步分析: 事务补偿机制 

当我们在生产线上用一台服务器来提供数据服务的时候，我会遇到如下的两个问题：1）一台服务器的性能不足以提供足够的能力服务于所有的网络请求。2）我们总是害怕我们的这台服务器停机，造成服务不可用或是数据丢失。于是我们不得不对我们的服务器进行扩展，加入更多的机器来分担性能上的问题，以及来解决单点故障问题。 通常，我们会通过两种手段来扩展我们的数据服务：1）数据分区：就是把数

事务就是一个会话过程中，对上下文的影响是一致的，要么所有的更改都做了，要么所有的更变都撤销掉。就要么生，要么死。没有半死不死的中间不可预期状态。参考下薛定谔的猫。事务是为了保障业务数据的完整性和准确性的。分布式事务，常见的两个处理办法就是两段式提交和补偿。两段式提交典型的就是XA，有个事务协调器，告诉大家，来都准备好提交，大家回复，都准备好了，然后协调器告诉大家，一起提

前言目前的应用系统，不管是企业级应用还是互联网应用，最终数据的一致性是每个应用系统都要面临的问题，随着分布式的逐渐普及，数据一致性更加艰难，但是也很难有银弹的解决方案，也并不是引入特定的中间件或者特定的开源框架能够解决的，更多的还是看业务场景，根据场景来给出解决方案。根据笔者最近几年的了解，总结了几个点，更多的应用系统在编码的时候，更加关注数据的一致性，这样系统才是健壮的。

业务场景：笔者现在碰到一个项目，项目是类似于一卡通的数据模型，就是所有的金额存放在A系统中，A系统负责金额的处理，B系统负责业务处理，并向A系统发送相应的命令以进行数据处理，并返回相应处理的结果。    A和B系统之间的调用，由于项目和技术原因，并没有使用什么高深的调用手段，就是由A系统开放一个http接口，然后B在调用时即通过构建一个http请求向A系统发送一个请求，并对返回

现在先抛出问题，假设有一个主数据中心在北京M，然后有成都A，上海B两个地方数据中心，现在的问题是，假设成都上海各自的数据中心有记录变更，需要先同步到主数据中心，主数据中心更新完成之后，在把最新的数据分发到上海，成都的地方数据中心A，地方数据中心更新数据，保持和主数据中心一致性（数据库结构完全一致）。数据更新的消息是通过一台中心的MQ进行转发。先把问题简单化处理，假设A增加一条记录M

http://www.cnblogs.com/LBSer/p/4715395.html　　前阵子从支付宝转账1万块钱到余额宝，这是日常生活的一件普通小事，但作为互联网研发人员的职业病，我就思考支付宝扣除1万之后，如果系统挂掉怎么办，这时余额宝账户并没有增加1万，数据就会出现不一致状况了。　　上述场景在各个类型的系统中都能找到相似影子，比如在电商系统中，当有用户下单后，除了在订单表插入一条记

说到分布式事务，就会谈到那个经典的”账号转账”问题：2个账号，分布处于2个不同的DB，或者说2个不同的子系统里面，A要扣钱，B要加钱，如何保证原子性？一般的思路都是通过消息中间件来实现“最终一致性”：A系统扣钱，然后发条消息给中间件，B系统接收此消息，进行加钱。但这里面有个问题：A是先update DB，后发送消息呢？ 还是先发送消息，后update DB？假设先updat