【問題背景】
某天早上做活動，流量大量增長，導致大量更新庫存操作失敗。
操作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
=>=>如果該次操作以前沒做過（沒有對應）繼續；否則處理下乙個item
=>=>更新庫存
=>=>更新是否售空
=>=>插入
=>所有分庫，每個分庫均提交事務
1）如果有乙個item更新失敗，回滾所有事務
2）盡量保證要不所有item都更新成功，要不都失敗
每次的請求對應乙個唯一的seqid，而記錄了這次請求的item是否更新成功。
如果seq表中有這條記錄表示上次請求的item以更新成功。
目的是為了防止由於上次操作成功，而返回結果時出現問題，下次重試導致重複的執行。
1）乙個事務中，sql操作太多；如果事務中有update操作，則從update操作執行到事務提交將會一直鎖住操作行，因此事務越長，鎖越長，效能損耗越大
2）每個分庫都要等所有item更新完後才提交，增長事務時間（也就是鎖時間）
【優化後】
如果需要更新 item1（分庫1）、item2（分庫2）、item3（分庫4）的庫存
=>迴圈在每個item所在分庫對item進行處理
=>=>在分庫1中開啟事務
=>=>插入seq表
=>=>更新庫存and是否售空
=>=>分庫1中提交事務
=>=>分庫2。。中操作item2
=>=>分庫4。。中操作item3
1）並沒有在所有分庫中新起事務，而是每個事務中只處理自己所包含的item的減庫存操作；當一次請求多個item時，減少每個庫的事務的時間長度
2）先插入seq表，再更新庫存，如果插入失敗直接退出；減少一次讀seq操作，將事務中sql操作減到最少
1）一次操作多個item時，不保證要不都成功，要不都失敗
2）只要有sql操作失敗，就返回失敗
【對比】
秒殺場景下MySQL的低效
最近業務試水電商，接了乙個秒殺的活。之前經常看到 的同行們討論秒殺，討論電商，這次終於輪到我們自己理論結合實際一次了。ps 進入正文前先說一點個人感受，之前看 的ppt感覺都懂了，等到自己出解決方案的時候發現還是有很多想不到的地方其實都沒懂，再次驗證了 細節是魔鬼 的理論。並且乙個人的能力有限，只有...
對秒殺場景的學習（3）
當併發量很大時，秒殺的商品的庫存已經為零，這個時候如果再去redis裡面查庫存，這樣就會影響效率 1.可以在 的邏輯上面加乙個concurrenthashmap的值，這樣就可以對其裡面的值做乙個判斷。2.如果是集群部署，當乙個伺服器發現庫存為零，往這個concurrenthashmap裡面存 乙個庫...
RabbitMQ在秒殺場景中的簡單應用
秒殺業務的核心是庫存處理，使用者購買成功後會進行減庫存操作，並記錄購買明細。當秒殺開始時，大量使用者同時發起請求，這是乙個並行操作，多條更新庫存數量的sql語句會同時競爭秒殺商品所處資料庫表裡的那行資料，導致庫存的減少數量與購買明細的增加數量不一致，因此，我們使用rabbitmq進行削峰限流並且將請...