Re: [請益] rds replication & cache 多問

看板Soft_Job作者 (BOSS)時間7年前 (2018/08/04 01:42), 7年前編輯推噓0(0推 0噓 2→)
留言2則, 1人參與, 7年前最新討論串3/4 (看更多)
※ 引述《life1347 (黑人)》之銘言： : 就問題一的部分 : 從文章中的描述看起來是需要 strong data consistency : 面對這種狀況有種可行的做法是採用 distributed lock : 但負面效益是會降低 throughput : 流程大概是 : 1. user1 搶 write lock : 2. user1 清除 cache & 更新 db : 3. user2 發現 write lock 存在，用 watch 或 polling 方式 : 等待該 lock 消失 (設定 timeout)，若消失就 r/w cache & db : 4. user1 步驟 2 : 成功: db, cache 更新後，撤銷 write lock : 失敗: 撤銷 write lock 或 retry : 由於無法假定步驟 4 一定會成功，因此要看錯誤狀況來決定處理方式 : 目前想到兩種可能作法 : 1. 撤銷 write lock，讓 user2 拿到舊資料。user1 返回錯誤看 application : 怎麼處理。這種狀況以搶票例子來說，就是 user2 買到票而 user1 哭哭 : 2. 持續 retry 但設定 timeout，至少其他使用者不必持續等待 : 3. 若非 db 或 schema 異常，retry 直到成功為止。 : 但通常這種做法蠻糟糕的，會讓多數使用者一直等待導致不耐 : 這邊要看 business 選哪種做法對公司影響較小，沒有絕對優劣 : 但通常在微服務架構(分散式系統)通常會採用 2 : 以上是個人經驗，相信版上有其他更資深的大大有更好的觀點可以討論 user1 read user1 下單搶座位001 and 得到訂單處理中之訊息 (通常是icon轉圈圈之類) *user2 read *user2 下單搶座位001 and 得到訂單處理中 user1 得到交易成功 *user2 得到交易失敗 通常不會用lock, 而是實際上整個流程都是read/write分離,做到transation like async送出動作,callback得到結果 並且at-least-once:確保訊息有送達 量大需要scaling甚至是會有kafka之類的掛在中間 你也可以把上面event放在cache內,這樣user2 read時其實可以顯示位置正在被搶 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.160.59.202 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1533318138.A.AA3.html ※ 編輯: alan3100 (1.160.59.202), 08/04/2018 01:46:07
→
08/04 03:57, 7年前 , 1F
啊 發現沒有表達清楚 文內的 write lock 指的意思
08/04 03:57, 1F
→
08/04 03:58, 7年前 , 2F
正是你文內 "event放在cache內" 的意思，我修正原文一下
08/04 03:58, 2F
原原PO問題比較類似Publishing Events Using Local Transactions 其中如何避免loacl transation 可以嘗試使用transaction log或者乾脆用event sourcing https://www.nginx.com/blog/event-driven-data-management-microservices/ ※ 編輯: alan3100 (118.169.33.21), 08/05/2018 16:13:22
‣ 更多 alan3100 的文章
文章代碼(AID): #1RP9FwgZ (Soft_Job)
‣ 更多 alan3100 的文章
文章代碼(AID): #1RP9FwgZ (Soft_Job)