如何解決 I/O 快取問題以及其他問題 Race Condition 最近它一直讓我很惱火
如何解決 I/O 快取問題以及其他問題 “Race Condition” 最近它一直讓我很惱火 How to solve I/O caching problems and other issues? “Race Condition” has been really bothering me lately.
not very formal. hope you understand. 最近在魚市場系統，我遇到很多 problem，特別是 I/O cache 同 race condition，一直搞到我很頭痛。
recently i’m encountered many problems in the fish market (兰迪斯社区鱼市) system.
first talk about io 快取問題。魚市場系統有很多 data，例如價格、庫存、重量。如果 cache 沒有 update fast enough，就會出現錯誤。cache updates slow enough, errors will occur. for example a customer see outdated plice, but the price at checkout is different which is bad 例如客人看到價格是舊的，結果結帳時不一樣，💣 這個很不好，客人會生氣。customer angry.
我發現問題通常是 cache 沒有 properly invalidation。當資料改變，但是 cache 還在用舊資料。解決方法我試幾個：I FOUND THE PROBLEM USUALLY DUE IMPROPER CACHE INVALIDATION when data changes the cache is still using the old data. they dont like me. but still i try, .
用 shorter cache time（TTL），不要讓 cache 活太久 有 update 時，主動清 cache，不要等它自己過期 有些重要 data，乾脆不用 cache，直接讀 database
這樣改善很多，但還不是全部。This is a significant improvement!!!, but this is never my whole story.
troublesome issue 再來就是更麻煩的：race condition。這個真的讓我很惱火。當兩個 process 同時操作同一個資料，就會出錯。例如兩個人同時買同一條魚，庫存可能變成負數，或者 double sell。
這就是 race condition。This is race condition. 我試幾個方法解決：
Lock 機制 在 update 前加 lock，確保同一時間只有一個 process 改資料 但 lock 太多會變慢，系統會卡 ATOMIC OPERATION 用 database 的 atomic update，例如 UPDATE … WHERE stock > 0
這個方法比較好，不容易出錯 Queue 系統 把所有訂單放進 queue，一個一個處理 雖然慢一點，但很安全 Retry 機制 如果失敗就 retry，但要小心不要無限 loop
最後我發現，沒有一個 in the end, we are not perfect in solution. so goodbye to us. it is only possible to balance performance and correctness.
I/O cache 要小心 invalidation.不然資料會錯 BE CAREFUL OF I/O CACHE INVALIDATION OTHERWISE DATA WILL BE CORRUPT. Race condition 一定要處理，不然會出現很奇怪 bug 系統設計要簡單，越複雜越容易出問題
現在還是有一點惱火，但比之前好很多。寫這篇希望幫到一樣在魚市場系統奮鬥的人。
