首頁(yè) 猿問(wèn) ef框架下怎么處理高并發(fā)的庫(kù)存數(shù)量

ef框架下怎么處理高并發(fā)的庫(kù)存數(shù)量

MySQL

夢(mèng)里花落0921 2018-07-30 17:10:16

某一商品庫(kù)存數(shù)為100 兩個(gè)人同時(shí)讀取到了數(shù)量 A添加10 為110 B減20 應(yīng)為90數(shù)據(jù)上下文中A的Quantity+=10(110); B的Quantity-=20(80)在ef框架下提交的后臺(tái)的sql語(yǔ)句 update quantity=A的Quantity(110) update Quantity=B的Quantity(80) 導(dǎo)致庫(kù)存不準(zhǔn)確如果在讀取商品庫(kù)存數(shù)時(shí)加鎖 A讀取完后并沒(méi)有提交操作(或者提交后延遲很大) 其他用戶讀取這個(gè)商品或者操作其他數(shù)據(jù)時(shí) 會(huì)等待時(shí)間較長(zhǎng) 有可能出現(xiàn)超時(shí)查了許多資料樂(lè)觀鎖悲觀鎖滿足不了要求有沒(méi)有大神給解答下給個(gè)其他的思路

查看完整描述

1 回答

搖曳的薔薇

TA貢獻(xiàn)1793條經(jīng)驗(yàn) 獲得超6個(gè)贊

樂(lè)觀鎖可以解決這種問(wèn)題，B提交時(shí)會(huì)拋出錯(cuò)誤，catch 住重試，但是在高并發(fā)下并不是好的解決方案。在高并發(fā)下一種是直接用sql 語(yǔ)句去 update ,這樣就不存在使用 ef 更新實(shí)體（分為兩步，先獲取，在修改）這種情況了，在更高的并發(fā)下可以考慮緩存庫(kù)存數(shù)據(jù)，并保證更新操作的順序是對(duì)的就可以了

反對(duì) 回復(fù) 2018-08-18