同房間玩家操作的并發(fā)問題
現(xiàn)有問題（丟失更新/不可重復(fù)讀）
- 現(xiàn)象： 玩家并發(fā)加入/離開時，前端顯示玩家沒有加入/離開。數(shù)據(jù)庫中Game->Players沒有被更新
- 現(xiàn)象： 玩家并發(fā)投票時赛惩，有的投票操作失敗或投票結(jié)果沒有出現(xiàn)。數(shù)據(jù)庫中的voteHistory沒有更新。
- 原因： GameService沒有做并發(fā)處理局蚀。服務(wù)處理每個用戶請求都會從數(shù)據(jù)庫讀取完整的Game+Players+votes，處理完后再寫回數(shù)據(jù)恕稠。發(fā)生并發(fā)處理時琅绅，服務(wù)可能同時操作Game對象，回寫時只有最后一個操作會生效鹅巍，前面的回寫會被覆蓋千扶。
并發(fā)處理的方法
- 線程鎖
- 方法鎖：@Syncronized
- 必須一個方法一個方法的加鎖，且無法適用于響應(yīng)式調(diào)用
- 對象鎖：ReentrantLock
- 引入緩存骆捧，同一個Game share同一個對象澎羞，為這個對象加鎖
- 無緩存的情況下，每個請求處理的Game都不是同一個對象敛苇，需要針對GameId設(shè)計鎖
- 方法鎖：@Syncronized
- 單線程
- 所有Game command都使用單線程處理妆绞，每個處理都要排隊
- 為每個Game分配一個線程，同一GameId的command處理要排隊
- 數(shù)據(jù)庫鎖
- 表鎖? vs 條目鎖? vs 字段鎖?
- 悲觀鎖 vs 樂觀鎖（失敗需要retry機(jī)制）
- All about lock
- kotlinx-coroutines-reactor 枫攀？括饶？？ coroutines掛起避免線程阻塞
- 性能分析以及測試
有鎖方案分析
目前的應(yīng)用中脓豪，對Game數(shù)據(jù)的操作主要由玩家加入(Join)巷帝，離開(Leave)和游戲命令(Command)引發(fā)。這些操作都由讀數(shù)據(jù)庫開始扫夜，寫數(shù)據(jù)庫結(jié)束楞泼，如果操作失敗則不會寫數(shù)據(jù)庫驰徊，讀寫操作數(shù)量基本持平。此外堕阔，由于只有同房間的游戲操作才會出現(xiàn)數(shù)據(jù)問題棍厂，所以頻度較低。
綜上超陆，我們可以采用樂觀鎖牺弹。
- MongoDB樂觀鎖: 在Game中加入versionId并在寫入數(shù)據(jù)時使用原子操作findAndModify。
- java方法鎖/對象鎖 (syncronized): 響應(yīng)式調(diào)用中難以使用
- 對象鎖+緩存: 實(shí)現(xiàn)比較復(fù)雜
在加鎖以后如果發(fā)生并發(fā)修改的時候时呀，只有第一個寫入操作會成功张漂，后續(xù)寫入都會失敗。所以需要為整個游戲操作加入重試機(jī)制谨娜。此邏輯可以用Reactive的retry機(jī)制方便的實(shí)現(xiàn)航攒。但重試會帶來多次數(shù)據(jù)庫讀寫增加的問題。如并發(fā)數(shù)為n趴梢，則最高重試次數(shù)為(1+n)*n/2(例：12個玩家同時加入游戲漠畜，最多可能發(fā)生78次加入游戲處理)。
ReactiveMongoRepository的save方法實(shí)現(xiàn)自帶樂觀鎖坞靶。只要實(shí)體定義了帶有@Version注解的字段憔狞，在調(diào)用save時就會自動用version進(jìn)行樂觀鎖校驗(yàn)，并在發(fā)現(xiàn)版本錯誤時拋出OptimisticLockingFailureException彰阴。同時也會在save時自增version瘾敢。
無鎖方案分析
在Game操作中按照GameId分配線程，同一個GameId的操作都使用同一個線程硝枉。
此實(shí)現(xiàn)的難點(diǎn)主要在于根據(jù)GameId創(chuàng)建線程廉丽，以及將MongoDB的讀寫切換到GameId對應(yīng)的線程上。
PublisherMapping的問題
我們在PublisherMapping中使用了mutableMapOf()生成了一個用來存儲游戲房間廣播器(WebSocketPublisher)的map妻味。玩家加入房間時，會調(diào)用createPublisherIfNotExist()來創(chuàng)建或獲取本房間的廣播器欣福。當(dāng)所有玩家離開房間時责球，會調(diào)用removePublisher()來釋放廣播器。然而拓劝，當(dāng)玩家并發(fā)加入或離開房間時雏逾，廣播器的管理可能會有問題，因?yàn)檫@兩個方法都不是線程安全的郑临。
改造方案：
- (有鎖方案)將PublisherMapping中對map進(jìn)行讀寫的方法都加上鎖-
syncronized(msgPublisherMap) - (無鎖方案)將PublisherMapping中對map進(jìn)行讀寫的方法改造成支持響應(yīng)式調(diào)用栖博，并限制在固定線程執(zhí)行。
