分布式系统的事务处理

当我们在生产线上用一台服务器来提供数据服务的时候，我会遇到如下的两个问题：

1）一台服务器的性能不足以提供足够的能力服务于所有的网络请求。

2）我们总是害怕我们的这台服务器停机，造成服务不可用或是数据丢失。

于是我们不得不对我们的服务器进行扩展，加入更多的机器来分担性能上的问题，以及来解决单点故障问题。 通常，我们会通过两种手段来扩展我们的数据服务：

1）数据分区：就是把数据分块放在不同的服务器上（如：uid % 16，一致性哈希等）。

2）数据镜像：让所有的服务器都有相同的数据，提供相当的服务。

对于第一种情况，我们无法解决数据丢失的问题，单台服务器出问题时，会有部分数据丢失。所以，数据服务的高可用性只能通过第二种方法来完成——数据的冗余存储（一般工业界认为比较安全的备份数应该是3份，如：Hadoop和Dynamo）。 但是，加入更多的机器，会让我们的数据服务变得很复杂，尤其是跨服务器的事务处理，也就是跨服务器的数据一致性。这个是一个很难的问题。 让我们用最经典的Use Case：“A帐号向B帐号汇钱”来说明一下，熟悉RDBMS事务的都知道从帐号A到帐号B需要6个操作：

1. 从A帐号中把余额读出来。

2. 对A帐号做减法操作。

3. 把结果写回A帐号中。

4. 从B帐号中把余额读出来。

5. 对B帐号做加法操作。

6. 把结果写回B帐号中。

为了数据的一致性，这6件事，要么都成功做完，要么都不成功，而且这个操作的过程中，对A、B帐号的其它访问必需锁死，所谓锁死就是要排除其它的读写操作，不然会有脏数据的问题，这就是事务。那么，我们在加入了更多的机器后，这个事情会变得复杂起来：

1）在数据分区的方案中：如果A帐号和B帐号的数据不在同一台服务器上怎么办？我们需要一个跨机器的事务处理。也就是说，如果A的扣钱成功了，但B的加钱不成功，我们还要把A的操作给回滚回去。这在跨机器的情况下，就变得比较复杂了。

2）在数据镜像的方案中：A帐号和B帐号间的汇款是可以在一台机器上完成的，但是别忘了我们有多台机器存在A帐号和B帐号的副本。如果对A帐号的汇钱有两个并发操作（要汇给B和C），这两个操作发生在不同的两台服务器上怎么办？也就是说，在数据镜像中，在不同的服务器上对同一个数据的写操作怎么保证其一致性，保证数据不冲突？

同时，我们还要考虑性能的因素，如果不考虑性能的话，事务得到保证并不困难，系统慢一点就行了。除了考虑性能外，我们还要考虑可用性，也就是说，一台机器没了，数据不丢失，服务可由别的机器继续提供。 于是，我们需要重点考虑下面的这么几个情况：

1）容灾：数据不丢、结点的Failover

2）数据的一致性：事务处理

3）性能：吞吐量 、 响应时间

前面说过，要解决数据不丢，只能通过数据冗余的方法，就算是数据分区，每个区也需要进行数据冗余处理。这就是数据副本：当出现某个节点的数据丢失时可以从副本读到，数据副本是分布式系统解决数据丢失异常的唯一手段。所以，在这篇文章中，简单起见，我们只讨论在数据冗余情况下考虑数据的一致性和性能的问题。简单说来：

1）要想让数据有高可用性，就得写多份数据。

2）写多份的问题会导致数据一致性的问题。

3）数据一致性的问题又会引发性能问题

本文适合基础分布式程序员：

1.本文会涉及集群中节点的failover和recover问题.

2.本文会涉及事务及不透明事务的问题.

3.本文会提到微博和tweeter，并引出一个大数据问题.

由于分布式这个话题太大，事务这个话题也太大，我们从一个集群的一个小小节点开始谈起。

集群中存活的节点与同步

分布式系统中，如何判断一个节点（node）是否存活？

kafka这样认为：

1.此节点和zookeeper能喊话.（Keep sessions with zookeeper through heartbeats.）

2.此节点如果是个从节点，必须能够尽可能忠实地反映主节点的数据变化。

也就是说，必须能够在主节点写了新数据后，及时复制这些变化的数据，所谓及时，不能拉下太多哦.

那么，符合上面两个条件的节点就可以认为是存活的，也可以认为是同步的（in-sync）.

关于第1点，大家对心跳都很熟悉，那么我们可以这样认为某个节点不能和zookeeper喊话了：

zookeeper-node:var timer =new timer().setInterval(10sec).onTime(slave-nodes,function(slave-nodes){slave-nodes.forEach( node -> {boolean isAlive = node.heartbeatACK(15sec);if(!isAlive) {node.numNotAlive += 1;if(node.numNotAlive >= 3) {node.declareDeadOrFailed();slave-nodes.remove(node);//回调也可 leader-node-app.notifyNodeDeadOrFailed(node)}}elsenode.numNotAlive = 0;});});timer.run();//你可以回调也可以像下面这样简单的计时判断leader-node-app:var timer =new timer().setInterval(10sec).onTime(slave-nodes,function(slave-nodes){slave-nodes.forEach(node -> {if(node.isDeadOrFailed) {//node不能和zookeeper喊话了}});});timer.run();

关于第二点，要稍微复杂点了，怎么搞呢？

来这么分析：

• 数据 messages.

• 操作 op-log.

• 偏移 position/offset.

// 1. 先考虑messages// 2. 再考虑log的postion或者offset// 3. 考虑msg和off都记录在同源数据库或者存储设备上.(database or storage-device.)var timer =new timer().setInterval(10sec).onTime(slave-nodes,function(nodes){var core-of-cpu = 8;//嫌慢就并发呗 mod hash go!nodes.groupParallel(core-of-cpu).forEach(node -> {boolean nodeSucked = false;if(node.ackTimeDiff > 30sec) {//30秒内没有回复，node卡住了nodeSucked = true;}if(node.logOffsetDiff > 100) {//node复制跟不上了，差距超过100条数据nodeSucked = true;}if(nodeSucked) {//总之node“死”掉了，其实到底死没死，谁知道呢？network-error在分布式系统中或者节点失败这个事情是正常现象.node.declareDeadOrFailed();//不和你玩啦，集群不要你了nodes.remove(node);//该怎么处理呢，抛个事件吧.fire-event-NodeDeadOrFailed(node);}});});timer.run();

上面的节点的状态管理一般由zookeeper来做，leader或者master节点也会维护那么点状态。

那么应用中的leader或者master节点，只需要从zookeeper拉状态就可以，同时，上面的实现是不是一定最佳呢？不是的，而且多数操作可以合起来，但为了描述节点是否存活这个事儿，咱们这么写没啥问题。

节点死掉、失败、不同步了，咋处理呢？

好嘛，终于说到failover和recover了，那failover比较简单，因为还有其它的slave节点在，不影响数据读取。

1.同时多个slave节点失败了？

没有100%的可用性.数据中心和机房瘫痪、网络电缆切断、hacker入侵删了你的根，总之你rp爆表了.

2.如果主节点失败了，那master-master不行嘛？

keep-alived或者LVS或者你自己写failover吧.

高可用架构（HA）又是个大件儿了，此文不展开了。

我们来关注下recover方面的东西，这里把视野打开点，不仅关注slave节点重启后追log来同步数据，我们看下在实际应用中，数据请求（包括读、写、更新）失败怎么办？

大家可能都会说，重试（retry）呗、重放（replay）呗或者干脆不管了呗！

行，都行，这些都是策略，但具体怎么个搞法，你真的清楚了？

一个bigdata问题

我们先摆个探讨的背景：

问题：消息流，比如微博的微博（真绕），源源不断地流进我们的应用中，要处理这些消息，有个需求是这样的：

Reach is the number of unique people exposed to a URL on Twitter.

那么，统计一下3小时内的本条微博（url）的reach总数。

怎么解决呢？

把某时间段内转发过某条微博（url）的人拉出来，把这些人的粉丝拉出来，去掉重复的人，然后求总数，就是要求的reach.

为了简单，我们忽略掉日期，先看看这个方法行不行：

/** ---------------------------------* 1. 求出转发微博(url)的大V.* __________________________________*/方法 ：getUrlToTweetersMap(String url_id)SQL ： /* 数据库A，表url_user存储了转发某url的user */SELECT url_user.user_id as tweeter_idFROM url_userWHERE url_user.url_id = ${url_id}返回 ：[user_1,...,user_m]

/** ---------------------------------* 2. 求出大V的粉丝* __________________________________*/方法 : getFollowers(String tweeter_id);SQL : /* 数据库B */SELECT users.id as user_idFROM usersWHERE users.followee_id = ${tweeter_id}返回：tweeter的粉丝

/** ---------------------------------* 3. 求出Reach* __________________________________*/var url = queryArgs.getUrl();var tweeters = getUrlToTweetersMap();var result = new HashMap<String,Integer>();tweeters.forEach(t -> {// 你可以批量in + 并发读来优化下面方法的性能var followers = getFollowers(t.tweeter_id);followers.forEach(f -> {//hash去重result.put(f.user_id,1);});});//Reachreturn result.size();

其实这又引出了一个很重要的问题，也是很多大谈框架、设计、模式却往往忽视的问题：性能和数据库建模的关系。

1.数据量有多大？

不知道读者有木有对这个问题的数据库I/O有点想法呢？

Computing reach is too intense for a single machine – it can require thousands of database calls and tens of millions of tuples.

在上面的数据库设计中避免了JOIN，为了提高求大V粉丝的性能，可以将一批大V作为batch/bulk，然后多个batch并发读，誓死搞死数据库。

这里将微博到转发者表所在的库，与粉丝库分离，如果数据更大怎么办？

库再分表...

OK，假设你已经非常熟悉传统关系型数据库的分库分表及数据路由（读路径的聚合、写路径的分发）、或者你对于sharding技术也很熟悉、或者你良好的结合了HBase的横向扩展能力并有一致性策略来解决其二级索引问题.

总之，存储和读取的问题假设你已经解决了，那么分布式计算呢？

2.微博这种应用，人与人之间的关系成图状（网），你怎么建模存储？而不仅仅对应这个问题，比如：

某人的好友的好友可能和某人有几分相熟？

看看用storm怎么来解决分布式计算，并提供流式计算的能力？

// url到大V -> 数据库1TridentState urlToTweeters =topology.newStaticState(getUrlToTweetersState());// 大V到粉丝 -> 数据库2TridentState tweetersToFollowers =topology.newStaticState(getTweeterToFollowersState());topology.newDRPCStream("reach").stateQuery(urlToTweeters, new Fields("args"), new MapGet(), new Fields("tweeters")).each(new Fields("tweeters"), new ExpandList(), new Fields("tweeter")).shuffle() /* 大V的粉丝很多，所以需要分布式处理*/.stateQuery(tweetersToFollowers, new Fields("tweeter"), new MapGet(), new Fields("followers")).parallelismHint(200) /* 粉丝很多，所以需要高并发 */.each(new Fields("followers"), new ExpandList(), new Fields("follower")).groupBy(new Fields("follower")).aggregate(new One(), new Fields("one")) /* 去重 */.parallelismHint(20).aggregate(new Count(), new Fields("reach")); /* 计算reach数 */

最多处理一次（At most once）

回到主题，引出上面的例子，一是为了引出一个有关分布式（存储+计算）的问题，二是透漏这么点意思：

码农，就应该关注设计和实现的东西，比如Jay Kreps是如何发明Kafka这个轮子的 : ]

如果你还是码农级别，咱来务点实吧，前面我们说到recover，节点恢复的问题，那么我们恢复几个东西？

基本的：

• 节点状态

• 节点数据

本篇从数据上来讨论下这个问题，为使问题再简单点，我们考虑写数据的场景，如果我们用write-ahead-log的方式来保证数据复制和一致性，那么我们会怎么处理一致性问题呢？

1.主节点有新数据写入.

2.从节点追log,准备复制这批新数据。从节点做两件事：

(1). 把数据的id偏移写入log;

(2). 正要处理数据本身，从节点挂了。

那么根据上文的节点存活条件，这个从节点挂了这件事被探测到了，从节点由维护人员手动或者其自己恢复了，那么在加入集群和小伙伴们继续玩耍之前，它要同步自己的状态和数据。

问题来了：

如果根据log内的数据偏移来同步数据，那么，因为这个节点在处理数据之前就把偏移写好了，可是那批数据lost-datas没有得到处理，如果追log之后的数据来同步，那么那批数据lost-datas就丢了。

在这种情况下，就叫作数据最多处理一次，也就是说数据会丢失。

最少处理一次（At least once）

好吧，丢失数据不能容忍，那么我们换种方式来处理：

1.主节点有新数据写入.

2.从节点追log,准备复制这批新数据。从节点做两件事：

(1). 先处理数据；

(2). 正要把数据的id偏移写入log，从节点挂了。

问题又来了：

如果从节点追log来同步数据，那么因为那批数据duplicated-datas被处理过了，而数据偏移没有反映到log中，如果这样追，会导致这批数据重复。

这种场景，从语义上来讲，就是数据最少处理一次，意味着数据处理会重复。

仅处理一次（Exactly once）

Transaction

好吧，数据重复也不能容忍？要求挺高啊。

大家都追求的强一致性保证（这里是最终一致性），怎么来搞呢？

换句话说，在更新数据的时候，事务能力如何保障呢？

假设一批数据如下：

// 新到数据{transactionId:4urlId:99reach:5}

现在要更新这批数据到库里或者log里，那么原来的情况是：

// 老数据{transactionId：3urlId:99reach:3}

如果说可以保证如下三点：

1.事务ID的生成是强有序的.（隔离性，串行）

2.同一个事务ID对应的一批数据相同.（幂等性，多次操作一个结果）

3.单条数据会且仅会出现在某批数据中.（一致性，无遗漏无重复）

那么，放心大胆的更新好了：

// 更新后数据{transactionId：4urlId:99//3 + 5 = 8reach:8}

注意到这个更新是ID偏移和数据一起更新的，那么这个操作靠什么来保证：原子性。

你的数据库不提供原子性？后文略有提及。

这里是更新成功了。如果更新的时候，节点挂了，那么库里或者log里的id偏移不写，数据也不处理，等节点恢复，就可以放心去同步，然后加入集群玩耍了。

所以说，要保证数据仅处理一次，还是挺困难的吧？

上面的保障“仅处理一次”这个语义的实现有什么问题呢？

性能问题!

这里已经使用了batch策略来减少到库或磁盘的Round-Trip Time，那么这里的性能问题是什么呢？

考虑一下，采用master-master架构来保证主节点的可用性，但是一个主节点失败了，到另一个主节点主持工作，是需要时间的。
假设从节点正在同步，啪！主节点挂了！因为要保证仅处理一次的语义，所以原子性发挥作用，失败，回滚，然后从主节点拉失败的数据（你不能就近更新，因为这批数据可能已经变化了，或者你根本没缓存本批数据），结果是什么呢？

老主节点挂了， 新的主节点还没启动，所以这次事务就卡在这里，直到数据同步的源——主节点可以响应请求。

如果不考虑性能，就此作罢，这也不是什么大事。

你似乎意犹未尽？来吧，看看“银弹”是什么？

Opaque-Transaction

现在，我们来追求这样一种效果：

某条数据在一批数据中（这批数据对应着一个事务），很可能会失败，但是它会在另一批数据中成功。
换句话说，一批数据的事务ID一定相同。

来看看例子吧，老数据不变，只是多了个字段：prevReach

// 老数据{transactionId：3urlId:99//注意这里多了个字段，表示之前的reach的值prevReach:2reach:3}// 新到数据{transactionId:4urlId:99reach:5}

这种情况，新事务的ID更大、更靠后，表明新事务可以执行，还等什么，直接更新，更新后数据如下：

// 新到数据{transactionId:4urlId:99//注意这里更新为之前的值prevReach:3//3 + 5 = 8reach:8}

现在来看下另外的情况：

// 老数据{transactionId：3urlId:99prevReach:2reach:3}// 新到数据{//注意事务ID为3，和老数据中的事务ID相同transactionId:3urlId:99reach:5}

这种情况怎么处理？是跳过吗？因为新数据的事务ID和库里或者log里的事务ID相同，按事务要求这次数据应该已经处理过了，跳过？

不，这种事不能靠猜的，想想我们有的几个性质，其中关键一点就是：

给定一批数据，它们所属的事务ID相同。
仔细体会下，上面那句话和下面这句话的差别：
给定一个事务ID，任何时候，其所关联的那批数据相同。

我们应该这么做，考虑到新到数据的事务ID和存储中的事务ID一致，所以这批数据可能被分别或者异步处理了，但是，这批数据对应的事务ID永远是同一个，那么，即使这批数据中的A部分先处理了，由于大家都是一个事务ID，那么A部分的前值是可靠的。

所以，我们将依靠prevReach而不是Reach的值来更新：

// 更新后数据{transactionId:3urlId:99//这个值不变prevReach:2//2 + 5 = 7reach:7}

你发现了什么呢？

不同的事务ID，导致了不同的值：

1.当事务ID为4，大于存储中的事务ID3，Reach更新为3+5 = 8.

2.当事务ID为3，等于存储中的事务ID3，Reach更新为2+5 = 7.

这就是Opaque Transaction.

这种事务能力是最强的了，可以保证事务异步提交。所以不用担心被卡住了，如果说集群中：

Transaction：

• 数据是分批处理的，每个事务ID对应一批确定、相同的数据.

• 保证事务ID的产生是强有序的.

• 保证分批的数据不重复、不遗漏.

• 如果事务失败，数据源丢失，那么后续事务就卡住直到数据源恢复.

Opaque-Transaction：

数据是分批处理的，每批数据有确定而唯一的事务ID.

保证事务ID的产生是强有序的.

保证分批的数据不重复、不遗漏.

如果事务失败，数据源丢失，不影响后续事务，除非后续事务的数据源也丢了.

其实这个全局ID的设计也是门艺术：

• 冗余关联表的ID，以减少join，做到O(1)取ID.

• 冗余日期（long型）字段，以避免order by.

• 冗余过滤字段，以避免无二级索引（HBase）的尴尬.

• 存储mod-hash的值，以方便分库、分表后，应用层的数据路由书写.

你现在知道twitter的snowflake生成全局唯一且有序的ID的重要性了

两阶段提交

现在用zookeeper来做两阶段提交已经是入门级技术，所以也不展开了。

如果你的数据库不支持原子操作，那么考虑两阶段提交吧。