【問題背景】

某天早上做活動(dòng)，流量大量增長(zhǎng)，導(dǎo)致大量更新庫(kù)存操作失敗。

操作mysql返回的錯(cuò)誤均為“Lost Connection to mysql server”，即mysql服務(wù)端主動(dòng)斷開了連接，導(dǎo)致update操作失敗。

都是在sql執(zhí)行過程中返回的“Lost”，且都是update操作返回“Lost”，同一時(shí)刻的“select”操作并無異常。

都是update執(zhí)行操過了1s后返回的“Lost”

【原因】

秒殺情景下是大量update同時(shí)操作同一表的同一記錄

對(duì)同一記錄的寫操作都要加“行鎖”，且有“死鎖檢測(cè)”，使得sql操作串行執(zhí)行，有阻塞

猜測(cè)：某些請(qǐng)求由于等到超時(shí)了，被mysql服務(wù)關(guān)了連接

【老流程】

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

流程

=>所有分庫(kù)，每個(gè)分庫(kù)上均開啟一個(gè)事務(wù)

=>查詢。。

=>循環(huán)處理3個(gè)item

=>=>如果該次操作以前沒做過(沒有seqid)繼續(xù)；否則處理下一個(gè)item

=>=>更新庫(kù)存

=>=>更新是否售空

=>=>插入

=>所有分庫(kù)，每個(gè)分庫(kù)均提交事務(wù)

1)如果有一個(gè)item更新失敗，回滾所有事務(wù)

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

問題

1)一個(gè)事務(wù)中，sql操作太多；如果事務(wù)中有update操作，則從update操作執(zhí)行到事務(wù)提交將會(huì)一直鎖住操作行，因此事務(wù)越長(zhǎng)，鎖越長(zhǎng)，性能損耗越大

2)每個(gè)分庫(kù)都要等所有item更新完后才提交，增長(zhǎng)事務(wù)時(shí)間(也就是鎖時(shí)間)

【優(yōu)化后】

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

流程

=>循環(huán)在每個(gè)item所在分庫(kù)對(duì)item進(jìn)行處理

=>=>在分庫(kù)1中開啟事務(wù)

=>=>插入seq表

=>=>更新庫(kù)存and是否售空

=>=>提交事務(wù)

問題

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

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

【對(duì)比】

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。