最近有個專案,拼團的業務,但區別於一般的拼團完成就發貨,我們的業務時拼團完成後,有乙個**活動,從參加活動的成員中抽出一名幸運兒。
拼團下單的業務如下:
//拼團下單 邏輯
func paymoney()
//2、建立支付訂單
funcb()
;funcb2()
;db::commit;
//提交事務
}}
活動流程為:
a使用者(uid=220)開團;這時奇怪的事情就產生了,在funcb方法中 b、c兩使用者在b2方法中先後統計到的b1的參團人數始終為2人,如下然後b使用者(uid=222) 和 c(uid=217)使用者同時參團;
//b使用者在b2方法中的列印:,]
,"redis"
:"2"
}
//c使用者在b2方法中的列印:,]
,"redis"
:"3"
}
為方便對比,我們在funcb1方法中對參團人數用redis做了統計:b使用者在funb2統計到的實際參團人數為2,c使用者在funb2統計到的實際參團人數為3。
結果:導致如果在事務中通過mysql的count()統計參團人數,會出現偏差,即兩使用者同時參團是無法統計到對方的;
方案一:
在funcb2前進行事務提交,然後再重新開啟乙個事務。
可能存在的問題:
方案二:
方案2,把所有funcb1()的由mq來處理,這樣就能順序處理資料,在消費的時候處理funcb2()
方案三:
歡迎討論……
訊息佇列處理秒殺 拼團活動的高併發問題
人工智慧,零基礎入門!1 訊息佇列 以下簡稱mq 天生就是處理高併發的有力工具,因為他可以把乙個完整的流程拆為多部分,併發進行,或者不是很重要的步驟模組延遲進行。大家所熟悉的是訊息佇列在大基數使用者專案的註冊模組和電商專案的訂單模組運用的比較多,就是最好的案例。但是這裡並不是想要介紹這個,而是想簡談...
ArrayList併發問題分析
1.問題描述 for迴圈執行緒池中啟10個任務進行list.add 加完後,發現第乙個值為空,而且list的size也不是10 2.分析 執行緒問題比較不好分析,主要是太抽象,都隱藏在後台,不能直觀的觀察到,而且時有時無,所以比較難分析 1.第一步,出這種問題,首先確定,肯定是共享變數,非原子化操作...
事物的併發問題
事物的併發問題 髒讀 例如事物沒有執行完,就讀。比如 轉賬一半,讀,rollback 最可怕 重複讀 兩次讀取的不一致。即讀取第二次,事物更新 幻讀 虛讀 對同一張表兩次查詢不一致,因為另一事物插入記錄 四大隔離級別 serializable 序列化 不會出現任何併發問題,因為就是序列。效能最差 r...