【問題背景】
某天早上做活動，流量大量增長，導致大量更新庫存操作失敗。
操作mysql返回的錯誤均為“Lost Connection to mysql server”，即mysql服務端主動斷開了連接，導致update操作失敗。
都是在sql執行過程中返回的“Lost”，且都是update操作返回“Lost”，同一時刻的“select”操作並無異常。
都是update執行操過了1s后返回的“Lost”
【原因】
秒殺情景下是大量update同時操作同一表的同一記錄
對同一記錄的寫操作都要加“行鎖”，且有“死鎖檢測”，使得sql操作串行執行，有阻塞
猜測：某些請求由於等到超時了，被mysql服務關了連接
【老流程】
如果需要更新 item1（分庫1）、item2（分庫2）、item3（分庫4）的庫存
- 流程
=>所有分庫，每個分庫上均開啟一個事務
=>查詢。。
=>循環處理3個item
=>=>如果該次操作以前沒做過（沒有對應<seqid,itemid>）繼續；否則處理下一個item
=>=>更新庫存
=>=>更新是否售空
=>=>插入<seqid/item>
=>所有分庫，每個分庫均提交事務
1）如果有一個item更新失敗，回滾所有事務
2）盡量保證要不所有item都更新成功，要不都失敗
- seq表
每次的請求對應一個唯一的seqid，而<seqid,itemid>記錄了這次請求的item是否更新成功。
如果seq表中有這條記錄表示上次請求的item以更新成功。
目的是為了防止由於上次操作成功，而返回結果時出現問題，下次重試導致重復的執行。
- 問題
1）一個事務中，sql操作太多；如果事務中有update操作，則從update操作執行到事務提交將會一直鎖住操作行，因此事務越長，鎖越長，性能損耗越大
2）每個分庫都要等所有item更新完后才提交，增長事務時間（也就是鎖時間）
【優化后】
如果需要更新 item1（分庫1）、item2（分庫2）、item3（分庫4）的庫存
- 流程
=>循環在每個item所在分庫對item進行處理
=>=>在分庫1中開啟事務
=>=>插入seq表<seq,item1>
=>=>更新庫存and是否售空
=>=>分庫1中提交事務
=>=>分庫2。。中操作item2
=>=>分庫4。。中操作item3
- 更改
1）並沒有在所有分庫中新起事務，而是每個事務中只處理自己所包含的item的減庫存操作；當一次請求多個item時，減少每個庫的事務的時間長度
2）先插入seq表，再更新庫存，如果插入失敗直接退出；減少一次讀seq操作，將事務中sql操作減到最少
- 問題
1）一次操作多個item時，不保證要不都成功，要不都失敗
2）只要有sql操作失敗，就返回失敗
【對比】
