我正在嘗試實(shí)現(xiàn)某種同步服務(wù)。具有不同用戶代理的兩個客戶端可以POST/PATCH同時(shí)/sync/user/{user_id}/resource使用相同的 user_id. sync應(yīng)該更新數(shù)據(jù)庫中用戶id={user_id}的數(shù)據(jù)。func (syncServer *SyncServer) Upload(w http.ResponseWriter, r *http.Request, ps httprouter.Params) { userID := ps.ByName("user_id")) if isAlreadyProcessedForUser(userID) { w.WriteHeader(http.StatusConflict) return } ... syncServer.db.Update(userID, data) ...}Upload問題是當(dāng)另一個仍在處理相同請求時(shí)，我不知道如何正確拒絕一個user_id。我認(rèn)為使用這個想法mutex.Lock()是不好的，因?yàn)槲視檫@個處理程序使用很多 pod，如果Upload在不同的 pod 上調(diào)用，它無論如何也幫不了我。我可以使用什么同步方法來解決這個問題？我應(yīng)該在數(shù)據(jù)庫中使用一些額外的字段嗎？我要求給我任何想法！
1 回答
慕運(yùn)維8079593
TA貢獻(xiàn)1876條經(jīng)驗(yàn) 獲得超5個贊
在分布式系統(tǒng)中有很多方法可以做到這一點(diǎn)（分布式鎖定），目前我可以想出一些方法：
使用
redis（或任何其他類似服務(wù)）鎖。然后您可以user_id在收到第一個請求時(shí)鎖定每個請求并拒絕其他請求，user_id因?yàn)槟鸁o法鎖定它。Redis的鎖一般都有過期時(shí)間所以不會死鎖。參考：https ://redis.io/docs/reference/patterns/distributed-locks/使用數(shù)據(jù)庫鎖。你應(yīng)該小心使用數(shù)據(jù)庫鎖，但一個簡單的方法是使用唯一索引：上傳前創(chuàng)建一個
uploading帶有約束的記錄，unique(user_id)上傳后刪除它。有可能忘記/未能刪除記錄并導(dǎo)致死鎖，因此您可能希望向expired_at記錄添加另一個字段，在上傳前檢查并刪除它。（特定于問題的場景）使用唯一約束
(user_id, upload_status)。這稱為部分索引，您只會在 時(shí)檢查此唯一索引upload_stats = 'uploading'。然后您可以為每個請求創(chuàng)建一條uploading記錄，并拒絕另一個請求。過期也需要，所以你需要跟蹤start_time上傳和清理長時(shí)間上傳記錄。如果您不需要重新申請磁盤空間，您可以簡單地將記錄標(biāo)記為failed，這樣您還可以跟蹤這些上傳在數(shù)據(jù)庫中失敗的時(shí)間和方式。
警告：
看來您正在使用 Kubernetes，因此應(yīng)謹(jǐn)慎使用任何非分布式鎖，具體取決于您想要獲得的一致性級別。Pod 是易變的，很難依賴本地信息并實(shí)現(xiàn)一致性，因?yàn)樗鼈兛赡鼙粡?fù)制/殺死/重新安排到另一臺機(jī)器。這也適用于具有自動縮放或調(diào)度機(jī)制的任何其他平臺。
一個用戶擁有的多個客戶端與服務(wù)器之間的同步過程至少需要處理請求排序、請求去重和最終一致性問題（例如，Google Doc 可以支持多人同時(shí)編輯）。有一些通用算法（如操作轉(zhuǎn)換），但這取決于您的具體用例。
- 1 回答
- 0 關(guān)注
- 100 瀏覽
添加回答
舉報(bào)
0/150
提交
取消