【問題背景】

某天早上做活動，流量大量增長，導致大量更新庫存操作失敗。

操作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)繼續；否則處理下一個item

=>=>更新庫存

=>=>更新是否售空

=>=>插入

=>所有分庫，每個分庫均提交事務

1)如果有一個item更新失敗，回滾所有事務

2)盡量保證要不所有item都更新成功，要不都失敗

問題

1)一個事務中，sql操作太多；如果事務中有update操作，則從update操作執行到事務提交將會一直鎖住操作行，因此事務越長，鎖越長，性能損耗越大

2)每個分庫都要等所有item更新完后才提交，增長事務時間(也就是鎖時間)

【優化后】

如果需要更新 item1(分庫1)、item2(分庫2)、item3(分庫4)的庫存

流程

=>循環在每個item所在分庫對item進行處理

=>=>在分庫1中開啟事務

=>=>插入seq表

=>=>更新庫存and是否售空

=>=>提交事務

問題

1)一次操作多個item時，不保證要不都成功，要不都失敗

2)只要有sql操作失敗，就返回失敗

【對比】

原文：http://www.cnblogs.com/taoxinrui/p/6399691.html

總結

以上是生活随笔為你收集整理的mysql去掉秒杀场景_秒杀场景下mysql减库存逻辑优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。