目前公司幾乎所有的項目都使用Spanner疹吃，在我們部署的項目中發(fā)現(xiàn)偶爾會有Transaction was aborted的情況，報錯如下：
很多同學(xué)可能以為是死鎖才會導(dǎo)致Transaction被中止呆万，其實并不是，是一個比死鎖更寬泛的情況——事務(wù)讀寫沖突车份，讀鎖被aborted谋减，因此事務(wù)被aborted。
下面解釋讀鎖為什么會被aborted扫沼。
閱讀本文之前最好能夠理解事務(wù)隔離級別出爹，下面不會詳細講解隔離級別的知識庄吼。
Spanner事務(wù)隔離
Spanner的事務(wù)是可串行化的（Serializable），可串行化是最高隔離級別严就，每個事務(wù)看起來像是串行執(zhí)行的总寻，也就是每個事務(wù)從外部看起來是有順序的，這就是可串行化梢为。并且外部觀察到的執(zhí)行順序與每個事務(wù)的commit timestamp順序相同渐行，這就是Spanner所說的外部一致性(External Consistency)。
如何保證外部一致性
外部一致性 = 可串行化 + commit timestamp決定事務(wù)順序
先說說可串行化铸董，大家熟悉的InnoDB是使用加悲觀鎖的方式實現(xiàn)可串行化祟印，讀操作加讀鎖，寫操作加寫鎖粟害，事務(wù)A如果要寫已經(jīng)被事務(wù)B加上鎖的數(shù)據(jù)蕴忆，則需要等待事務(wù)B釋放鎖，MySQL對鎖100%是采取等待的方式悲幅，這也是為什么會出現(xiàn)死鎖套鹅，因為雙方互相等待，InnoDB中事務(wù)的讀寫沖突本身不會導(dǎo)致事務(wù)被中止汰具。
那么Spanner有什么不同呢芋哭？
Spanner不是100%采取等待的方式，它可能會abort別的事務(wù)的鎖郁副，鎖被aborted的事務(wù)就會中止减牺。這就是Spanner文檔中所說的傷停等待(wound-wait)，abort鎖導(dǎo)致事務(wù)中止就是傷停存谎。我們知道讀鎖和讀鎖是不沖突的拔疚，因此只有讀鎖和寫鎖才是沖突的，那么說明是一方讀另一方寫時可能會造成某一方被aborted既荚。
是哪一方會被aborted呢稚失？
是年輕的事務(wù)。
怎么區(qū)分年輕和年老恰聘？
越早啟動的事務(wù)越年老句各，越晚啟動的事務(wù)越年輕，什么叫啟動晴叨？每個事務(wù)第一次進行讀寫操作時凿宾，Spanner會為其生成一個start timestamp，即為啟動時間兼蕊。這里注意初厚，是進行第一次讀寫時的，而不是begin一個Transaction時孙技。
在Spanner中产禾，只有Read操作會被馬上執(zhí)行并獲取鎖排作，Write操作都會被緩存在client本地，并沒有真的Write亚情，也不會獲取鎖妄痪，只有commit被調(diào)用后才會一次性發(fā)送到server，嘗試執(zhí)行并獲取鎖楞件，因此一個pending的事務(wù)是沒有寫鎖的拌夏，只有讀鎖。那么讀寫沖突的產(chǎn)生就一定是在一個事務(wù)pending另一個事務(wù)commit時履因，pending的事務(wù)持有讀鎖障簿，而commit的事務(wù)想要獲取寫鎖，此時：
- 如果commit事務(wù)比pending事務(wù)年輕栅迄，那么它需要等待pending事務(wù)主動釋放讀鎖站故，才能獲取寫鎖，此時采用等待策略毅舆。
- 如果commit事務(wù)比pending事務(wù)年老西篓，那么它會直接abort掉pending事務(wù)的讀鎖，成功獲取寫鎖并提交憋活， 此時采用傷停策略岂津，pending事務(wù)被aborted。
舉個栗子
等待策略（年輕事務(wù)等待年老事務(wù)釋放鎖）
先說一下我們最熟悉的等待策略悦即，也是InnoDB的鎖策略吮成。
- 首先我們begin兩個事務(wù)，注意：此時并不會給事務(wù)生成start timestamp辜梳，因此begin的順序是不影響結(jié)果的粱甫。
- 在左邊的事務(wù)（下稱事務(wù)A）中select * from ID為0的數(shù)據(jù)，此時事務(wù)A進行了第一個讀操作作瞄，Spanner為其生成start timestamp茶宵。
- 緊接著在右邊的事務(wù)（下稱事務(wù)B）中select * from 同一行數(shù)據(jù)，此時事務(wù)B進行了第一個讀操作宗挥，生成start timestamp乌庶，那么這個timestamp一定是晚于事務(wù)A的，因此事務(wù)A更年老契耿、事務(wù)B更年輕瞒大。
- 然后事務(wù)B立即更新同一行數(shù)據(jù)的LastName列，并且commit宵喂。
-
由于事務(wù)B更年輕糠赦，因此其commit將不會返回成功，而是一直等待锅棕，需要等待年老的事務(wù)A釋放鎖拙泽。
年輕事務(wù)等待年老事務(wù)釋放鎖
傷停策略（年輕事務(wù)被aborted）
- 首先我們begin兩個事務(wù)，注意：此時并不會給事務(wù)生成start timestamp裸燎，因此begin的順序是不影響結(jié)果的顾瞻。
- 在左邊的事務(wù)（下稱事務(wù)A）中select * from ID為0的數(shù)據(jù)，此時事務(wù)A進行了第一個讀操作德绿，Spanner為其生成start timestamp
- 緊接著在右邊的事務(wù)（下稱事務(wù)B）中select * from 同一行數(shù)據(jù)荷荤，此時事務(wù)B進行了第一個讀操作，生成start timestamp移稳，那么這個timestamp一定是晚于事務(wù)A的蕴纳，因此事務(wù)A更年老、事務(wù)B更年輕个粱。
- 事務(wù)A更新這一行的LastName
- 事務(wù)A commit古毛，此時A會獲取LastName列的寫鎖，而發(fā)現(xiàn)B已經(jīng)占有讀鎖都许，對比timestamp發(fā)現(xiàn)B更年輕稻薇，因此直接abrot B事務(wù)的讀鎖，最后成功提交
-
事務(wù)B在A提交后也進行update胶征，發(fā)現(xiàn)自己已被aborted塞椎，結(jié)束。
年輕事務(wù)被aborted
需要注意的是睛低，Spanner獲取鎖的粒度是列案狠，不是行，因此沖突是在列上钱雷，報錯將會是
conflict on keys in range (xxx), column LastName in table Singers
總結(jié)
可以看出莺戒，如果同一個包含讀寫沖突的事務(wù)代碼在短時間內(nèi)被執(zhí)行兩次，且先執(zhí)行的先commit了急波，就會出現(xiàn)后執(zhí)行的那個事務(wù)被aborted的情況从铲，這也是開頭講到的，我們會收到Transaction was aborted的原因澄暮。
或者是名段，有兩個不同的事務(wù)代碼，緊接著被執(zhí)行泣懊，且它們有讀寫沖突伸辟，年老的事務(wù)先commit，就會造成年輕事務(wù)aborted馍刮。
Spanner的SDK都有提供事務(wù)重試信夫，根據(jù)Spanner文檔，重試的事務(wù)將會以舊的timestamp重啟，因此事務(wù)不會出現(xiàn)餓死的現(xiàn)象静稻，最終一定有機會被執(zhí)行成功警没。
更佳實踐
但是我們還是應(yīng)該思考，這些沖突的事務(wù)是真的需要每一個都得到執(zhí)行振湾，還是只是不小心被重復(fù)調(diào)用杀迹，只執(zhí)行其中一個就能滿足業(yè)務(wù)？如果執(zhí)行一次就能滿足業(yè)務(wù)押搪，那么其他的重復(fù)事務(wù)會造成Spanner的資源浪費树酪，因此被aborted的事務(wù)會重試，如果多個事務(wù)一起重試大州，還是可能會出現(xiàn)aborted续语，然后再次重試，因此需要盡量避免短時間內(nèi)的無意義的重復(fù)調(diào)用厦画。
