目前公司幾乎所有的項目都使用Spanner，在我們部署的項目中發現偶爾會有Transaction was aborted的情況，報錯如下：
很多同學可能以為是死鎖才會導致Transaction被中止，其實并不是，是一個比死鎖更寬泛的情況——事務讀寫沖突，讀鎖被aborted，因此事務被aborted。
下面解釋讀鎖為什么會被aborted。
閱讀本文之前最好能夠理解事務隔離級別，下面不會詳細講解隔離級別的知識。
Spanner事務隔離
Spanner的事務是可串行化的（Serializable），可串行化是最高隔離級別，每個事務看起來像是串行執行的，也就是每個事務從外部看起來是有順序的，這就是可串行化。并且外部觀察到的執行順序與每個事務的commit timestamp順序相同，這就是Spanner所說的外部一致性(External Consistency)。
如何保證外部一致性
外部一致性 = 可串行化 + commit timestamp決定事務順序
先說說可串行化，大家熟悉的InnoDB是使用加悲觀鎖的方式實現可串行化，讀操作加讀鎖，寫操作加寫鎖，事務A如果要寫已經被事務B加上鎖的數據，則需要等待事務B釋放鎖，MySQL對鎖100%是采取等待的方式，這也是為什么會出現死鎖，因為雙方互相等待，InnoDB中事務的讀寫沖突本身不會導致事務被中止。
那么Spanner有什么不同呢？
Spanner不是100%采取等待的方式，它可能會abort別的事務的鎖，鎖被aborted的事務就會中止。這就是Spanner文檔中所說的傷停等待(wound-wait)，abort鎖導致事務中止就是傷停。我們知道讀鎖和讀鎖是不沖突的，因此只有讀鎖和寫鎖才是沖突的，那么說明是一方讀另一方寫時可能會造成某一方被aborted。
是哪一方會被aborted呢？
是年輕的事務。
怎么區分年輕和年老？
越早啟動的事務越年老，越晚啟動的事務越年輕，什么叫啟動？每個事務第一次進行讀寫操作時，Spanner會為其生成一個start timestamp，即為啟動時間。這里注意，是進行第一次讀寫時的，而不是begin一個Transaction時。
在Spanner中，只有Read操作會被馬上執行并獲取鎖，Write操作都會被緩存在client本地，并沒有真的Write，也不會獲取鎖，只有commit被調用后才會一次性發送到server，嘗試執行并獲取鎖，因此一個pending的事務是沒有寫鎖的，只有讀鎖。那么讀寫沖突的產生就一定是在一個事務pending另一個事務commit時，pending的事務持有讀鎖，而commit的事務想要獲取寫鎖，此時：
- 如果commit事務比pending事務年輕，那么它需要等待pending事務主動釋放讀鎖，才能獲取寫鎖，此時采用等待策略。
- 如果commit事務比pending事務年老，那么它會直接abort掉pending事務的讀鎖，成功獲取寫鎖并提交， 此時采用傷停策略，pending事務被aborted。
舉個栗子
等待策略（年輕事務等待年老事務釋放鎖）
先說一下我們最熟悉的等待策略，也是InnoDB的鎖策略。
- 首先我們begin兩個事務，注意：此時并不會給事務生成start timestamp，因此begin的順序是不影響結果的。
- 在左邊的事務（下稱事務A）中select * from ID為0的數據，此時事務A進行了第一個讀操作，Spanner為其生成start timestamp。
- 緊接著在右邊的事務（下稱事務B）中select * from 同一行數據，此時事務B進行了第一個讀操作，生成start timestamp，那么這個timestamp一定是晚于事務A的，因此事務A更年老、事務B更年輕。
- 然后事務B立即更新同一行數據的LastName列，并且commit。
-
由于事務B更年輕，因此其commit將不會返回成功，而是一直等待，需要等待年老的事務A釋放鎖。
年輕事務等待年老事務釋放鎖
傷停策略（年輕事務被aborted）
- 首先我們begin兩個事務，注意：此時并不會給事務生成start timestamp，因此begin的順序是不影響結果的。
- 在左邊的事務（下稱事務A）中select * from ID為0的數據，此時事務A進行了第一個讀操作，Spanner為其生成start timestamp
- 緊接著在右邊的事務（下稱事務B）中select * from 同一行數據，此時事務B進行了第一個讀操作，生成start timestamp，那么這個timestamp一定是晚于事務A的，因此事務A更年老、事務B更年輕。
- 事務A更新這一行的LastName
- 事務A commit，此時A會獲取LastName列的寫鎖，而發現B已經占有讀鎖，對比timestamp發現B更年輕，因此直接abrot B事務的讀鎖，最后成功提交
-
事務B在A提交后也進行update，發現自己已被aborted，結束。
年輕事務被aborted
需要注意的是，Spanner獲取鎖的粒度是列，不是行，因此沖突是在列上，報錯將會是
conflict on keys in range (xxx), column LastName in table Singers
總結
可以看出，如果同一個包含讀寫沖突的事務代碼在短時間內被執行兩次，且先執行的先commit了，就會出現后執行的那個事務被aborted的情況，這也是開頭講到的，我們會收到Transaction was aborted的原因。
或者是，有兩個不同的事務代碼，緊接著被執行，且它們有讀寫沖突，年老的事務先commit，就會造成年輕事務aborted。
Spanner的SDK都有提供事務重試，根據Spanner文檔，重試的事務將會以舊的timestamp重啟，因此事務不會出現餓死的現象，最終一定有機會被執行成功。
更佳實踐
但是我們還是應該思考，這些沖突的事務是真的需要每一個都得到執行，還是只是不小心被重復調用，只執行其中一個就能滿足業務？如果執行一次就能滿足業務，那么其他的重復事務會造成Spanner的資源浪費，因此被aborted的事務會重試，如果多個事務一起重試，還是可能會出現aborted，然后再次重試，因此需要盡量避免短時間內的無意義的重復調用。
