你真的很熟分布式和事务吗？

看到满世界的架构图，心都碎了。

咱什么时候才能有架构的本事啊？

如果某招聘负责人给你推了个架构师，你一投，其立马给又你推了一个高级XXX的职位让你看，这不是玩我呢吗...

简历上项目经历写一句hello world真的不行嘛？

本文略长，读者需要有一定耐心，如果你是高级码农或者架构师级别，你可以跳过。

本文注重实战或者实现，不设计CAP，略提ACID。

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

怎么解决呢？手段：

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

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

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

/** ---------------------------------  * 3. 求出Reach  * __________________________________*/    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);   });  });    //Reach  return result.size(); 

顶呱呱，无论如何，求出了Reach啊！

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

1. 数据量有多大？
   在上面的数据库设计中避免了JOIN，为了提高求大V粉丝的性能，可以将一批大V作为batch/bulk，然后多个batch并发读，誓死搞死数据库。
   这里将微博到转发者表所在的库，与粉丝库分离，如果数据更大怎么办？
   库再分表...好吧。本文不从性能展开。
2. 微博这种应用，人与人之间的关系成图状（网），你怎么建模存储？而不仅仅对应这个问题，比如：
   某人的好友的好友可能和某人有几分相熟？
3. 你选择MySQL分库、表、区，还是选择Redis，MongoDB作sharding？还是你直接就上HBase了？
4. 二级索引在哪里？

其实很佩服一篇文章，几个图表，看起来很cool的架构图就把这些问题说得一清二楚，架构嘛。

看看storm的解决方案：

// url到大V  TridentState urlToTweeters =   topology.newStaticState(getUrlToTweetersState());  // 大V到粉丝  TridentState 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）

回到主题，引出上面的例子，一是为了引出一个可以分布式的话题，二是透漏这么点意思：很大、很空的东西谁都会说，谁都能聊，问题是写的这个人真的懂不懂呢？有木有实现能力呢？

咱来务点实吧，前面我们说到 recover ，节点恢复的问题，那么我们恢复几个东西？

• 节点状态
• 节点数据

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

1. 主节点有新数据写入.
2. 从节点追log,准备复制这批新数据。从节点做两件事：
   (1). 把数据的id偏移写入log;
   (2). 正要处理数据本身，从节点挂了。

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

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

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

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

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

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

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

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