本文注重實戰或者實現，不涉及CAP，略提ACID。
本文適合基礎分散式程式設計師：
本文會涉及叢集中節點的failover和recover問題.
本文會涉及事務及不透明事務的問題.
本文會提到微博和tweeter，並引出一個大資料問題.
由於分散式這個話題太大，事務這個話題也太大，我們從一個叢集的一個小小節點開始談起。
叢集中存活的節點與同步
分散式系統中，如何判斷一個節點（node）是否存活？
kafka這樣認為：
此節點和zookeeper能喊話.（Keep sessions with zookeeper through heartbeats.）
此節點如果是個從節點，必須能夠儘可能忠實地反映主節點的資料變化。
也就是說，必須能夠在主節點寫了新資料後，及時複製這些變化的資料，所謂及時，不能拉下太多哦.
那麼，符合上面兩個條件的節點就可以認為是存活的，也可以認為是同步的（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)
}
}else
node.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節點在，不影響資料讀取。
同時多個slave節點失敗了？
沒有100%的可用性.資料中心和機房癱瘓、網路電纜切斷、hacker入侵刪了你的根，總之你rp爆表了.如果主節點失敗了，那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_id
FROM url_user
WHERE url_user.url_id = ${url_id}
返回 ：[user_1,...,user_m]
複製程式碼/** ---------------------------------
* 2. 求出大V的粉絲
* __________________________________*/
方法 : getFollowers(String tweeter_id);
SQL : /* 資料庫B */
SELECT users.id as user_id
FROM users
WHERE 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);
});
});
//Reach
return result.size();
複製程式碼頂呱呱，無論如何，求出了Reach啊！
其實這又引出了一個很重要的問題，也是很多大談框架、設計、模式卻往往忽視的問題：效能和資料庫建模的關係。
資料量有多大？
不知道讀者有木有對這個問題的資料庫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的橫向擴充套件能力並有一致性策略來解決其二級索引問題.
總之，儲存和讀取的問題假設你已經解決了，那麼分散式計算呢？微博這種應用，人與人之間的關係成圖狀（網），你怎麼建模儲存？而不僅僅對應這個問題，比如：
某人的好友的好友可能和某人有幾分相熟？
看看用storm怎麼來解決分散式計算，並提供流式計算的能力：
// url到大V -> 資料庫1
TridentState urlToTweeters =
topology.newStaticState(getUrlToTweetersState());
// 大V到粉絲 -> 資料庫2
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）
回到主題，引出上面的例子，一是為了引出一個有關分散式（儲存+計算）的問題，二是透漏這麼點意思：
碼農，就應該關注設計和實現的東西，比如Jay Kreps是如何發明Kafka這個輪子的 : ]
如果你還是碼農級別，我們來務點實吧，前面我們說到recover，節點恢復的問題，那麼我們恢復幾個東西？
基本的：
節點狀態
節點資料
本篇從資料上來討論下這個問題，為使問題再簡單點，我們考慮寫資料的場景，如果我們用write-ahead-log的方式來保證資料複製和一致性，那麼我們會怎麼處理一致性問題呢？
主節點有新資料寫入.
從節點追log,準備複製這批新資料。從節點做兩件事：
(1). 把資料的id偏移寫入log;
(2). 正要處理資料本身，從節點掛了。
那麼根據上文的節點存活條件，這個從節點掛了這件事被探測到了，從節點由維護人員手動或者其自己恢復了，那麼在加入叢集和小夥伴們繼續玩耍之前，它要同步自己的狀態和資料。
問題來了：
如果根據log內的資料偏移來同步資料，那麼，因為這個節點在處理資料之前就把偏移寫好了，可是那批資料lost-datas沒有得到處理，如果追log之後的資料來同步，那麼那批資料lost-datas就丟了。
在這種情況下，就叫作資料最多處理一次，也就是說資料會丟失。
最少處理一次（At least once）
好吧，丟失資料不能容忍，那麼我們換種方式來處理：
主節點有新資料寫入.
從節點追log,準備複製這批新資料。從節點做兩件事：
(1). 先處理資料；
(2). 正要把資料的id偏移寫入log，從節點掛了。
問題又來了：
如果從節點追log來同步資料，那麼因為那批資料duplicated-datas被處理過了，而資料偏移沒有反映到log中，如果這樣追，會導致這批資料重複。
這種場景，從語義上來講，就是資料最少處理一次，意味著資料處理會重複。
僅處理一次（Exactly once）
Transaction
好吧，資料重複也不能容忍？要求挺高啊。
大家都追求的強一致性保證（這裡是最終一致性），怎麼來搞呢？
換句話說，在更新資料的時候，事務能力如何保障呢？
假設一批資料如下：
// 新到資料
{
transactionId:4
urlId:99
reach:5
}
複製程式碼現在要更新這批資料到庫裡或者log裡，那麼原來的情況是：
// 老資料
{
transactionId：3
urlId:99
reach:3
}
複製程式碼如果說可以保證如下三點：
事務ID的生成是強有序的.（隔離性，序列）
同一個事務ID對應的一批資料相同.（冪等性，多次操作一個結果）
單條資料會且僅會出現在某批資料中.（一致性，無遺漏無重複）
那麼，放心大膽的更新好了：
// 更新後資料
{
transactionId：4
urlId:99
//3 + 5 = 8
reach:8
}
複製程式碼注意到這個更新是ID偏移和資料一起更新的，那麼這個操作靠什麼來保證：原子性。
你的資料庫不提供原子性？後文略有提及。
這裡是更新成功了。如果更新的時候，節點掛了，那麼庫裡或者log裡的id偏移不寫，資料也不處理，等節點恢復，就可以放心去同步，然後加入叢集玩耍了。
所以說，要保證資料僅處理一次，還是挺困難的吧？
上面的保障“僅處理一次”這個語義的實現有什麼問題呢？
效能問題。
這裡已經使用了batch策略來減少到庫或磁碟的Round-Trip Time，那麼這裡的效能問題是什麼呢？
考慮一下，採用master-master架構來保證主節點的可用性，但是一個主節點失敗了，到另一個主節點主持工作，是需要時間的。
假設從節點正在同步，啪！主節點掛了！因為要保證僅處理一次的語義，所以原子性發揮作用，失敗，回滾，然後從主節點拉失敗的資料（你不能就近更新，因為這批資料可能已經變化了，或者你根本沒快取本批資料），結果是什麼呢？
老主節點掛了， 新的主節點還沒啟動，所以這次事務就卡在這裡，直到資料同步的源——主節點可以響應請求。
如果不考慮效能，就此作罷，這也不是什麼大事。
你似乎意猶未盡？來吧，看看“銀彈”是什麼？
Opaque-Transaction
現在，我們來追求這樣一種效果：
某條資料在一批資料中（這批資料對應著一個事務），很可能會失敗，但是它會在另一批資料中成功。
換句話說，一批資料的事務ID一定相同。
來看看例子吧，老資料不變，只是多了個欄位：prevReach。
// 老資料
{
transactionId：3
urlId:99
//注意這裡多了個欄位，表示之前的reach的值
prevReach:2
reach:3
}
// 新到資料
{
transactionId:4
urlId:99
reach:5
}
複製程式碼這種情況，新事務的ID更大、更靠後，表明新事務可以執行，還等什麼，直接更新，更新後資料如下：
// 新到資料
{
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
}
複製程式碼這種情況怎麼處理？是跳過嗎？因為新資料的事務ID和庫裡或者log裡的事務ID相同，按事務要求這次資料應該已經處理過了，跳過？
不，這種事不能靠猜的，想想我們有的幾個性質，其中關鍵一點就是：
給定一批資料，它們所屬的事務ID相同。
仔細體會下，上面那句話和下面這句話的差別：
給定一個事務ID，任何時候，其所關聯的那批資料相同。
我們應該這麼做，考慮到新到資料的事務ID和儲存中的事務ID一致，所以這批資料可能被分別或者非同步處理了，但是，這批資料對應的事務ID永遠是同一個，那麼，即使這批資料中的A部分先處理了，由於大家都是一個事務ID，那麼A部分的前值是可靠的。
所以，我們將依靠prevReach而不是Reach的值來更新：
// 更新後資料
{
transactionId:3
urlId:99
//這個值不變
prevReach:2
//2 + 5 = 7
reach:7
}
複製程式碼你發現了什麼呢？
不同的事務ID，導致了不同的值：
當事務ID為4，大於儲存中的事務ID3，Reach更新為3+5 = 8.
當事務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來做兩階段提交已經是入門級技術，所以也不展開了。
如果你的資料庫不支援原子操作，那麼考慮兩階段提交吧。
如果想免費學習Java工程化、高效能及分散式、深入淺出。微服務、Spring，MyBatis，Netty原始碼分析的朋友可以加我的Java進階群：478030634，群裡有阿里大牛直播講解技術，以及Java大型網際網路技術的視訊免費分享給大家。
結語
To be continued.