啊 ... 大概想到解法了，所以那個白癡專案在開單時用了 DB tansaction ... 乾 ... 這真的超白癡的，所以當自己無法接到 response 或是 fail 時會直接 rollback ... 而對方訂單已成立還是會發送

洗單囉www

乾，難怪我 ACL 的 recheck 時沒有該單，因為該單 transaction 還沒完成，別的 process 也不應該看到該單才是

灌水啦！

這種情境要怎麼比較正確解啊好奇

北歐冷冷松鼠亞所 : 就直接先塞，然後跑 task 去 resend 然後更新是否成功和錯誤狀態就好了，事情很簡單不要弄得很複雜，transaction 不是在跨主機的時候用的

懂了w感謝

這題我可以用另外一個比方，你有 1000 筆要 call API，結果 transaction 花 1sec 對方處理要 4sec，結果只有兩種，一種是 DB 卡死 server 回 503，另外一種就是 N 筆成功但 N 筆 rollback，所以全部都塞然後 task 逐筆慢慢做就好了，還能 single thread 能免 race condition，免自己擔心受怕唄

我以為這是常識
直到我看到同事都在 transaction 裡面塞 grpc call 導致 db 塞車才發現原來不是大家都知道這件事……

我在我看過的一些 code 裡面，上面說的兩種做法都有看過qq

偷懶靠 db transaction 讓他炸到天邊去的不少...

北歐冷冷松鼠亞所 : 以 pgsql 為例
你 transaction 拉越長 他有一個 lock 的成本就會越高
最後你的 db 就會炸掉 無法處理其他請求

l• ܫ•) Davyキュルッ : 原來還有這個問題

遇到問題 用 pub/sub pattern 就對ㄌ

debɐnchery : microservice 射後不理很好用，可惜這公司很多成品無法那樣玩 Orz

QQ