異步處理陷阱、方法論與設計模式連載開篇這個系列一共七篇講一件事異步處理哪里會出錯怎么系統(tǒng)地做對以及有哪些被打磨過很多年的結構可以直接用。示例代碼用 CC17/20但坑和模式本身跟語言關系不大寫 Java、Go、Rust 的讀者照用。先把立場擺在這里異步不是一個性能開關它是一筆交易。你付出的是復雜度和不確定性換回來的是吞吐和彈性。這筆交易劃不劃算取決于你有沒有把該踩的坑提前想清楚。三條貫穿全系列的結論先劇透三條結論后面六篇都在給它們補證據(jù)。第一異步的失敗可以看起來像成功。任務沒跑、消息處理了、異常進了沒人 get 的 future這些在監(jiān)控上和成功長得一模一樣。所以每個異步邊界都要預先回答失敗會被誰看見怎么結束誰負責恢復。這件事比任何具體的技術選型都優(yōu)先。第二超時、重試、冪等、背壓是四道防線不是四個選項。缺了任何一道另外三道的設計全部失去意義沒有冪等的重試是在制造重復扣款沒有背壓的重試是在制造雪崩。第三先同步跑通再異步化。用度量證據(jù)隊列深度、線程池水位、延遲分布驅動升級而不是感覺卡了就上消息隊列。異步是交易不是信仰。系列目錄第 1 篇應用內(nèi)異步的坑上。數(shù)據(jù)競爭、死鎖、std::async的析構陷阱、回調(diào)里的懸垂指針。第 2 篇應用內(nèi)異步的坑下。異常斷流、取消與超時缺失、事件循環(huán)阻塞、線程池規(guī)模外加 CUDA 流——程序里跑模型是常態(tài)GPU 上的異步錯得更安靜。第 3 篇系統(tǒng)間的坑。消息丟失、重復投遞、亂序、重試風暴、雙寫、最終一致性的認知陷阱。第 4 篇方法論。什么時候該異步的決策框架四道防線錯誤契約可觀測性和并發(fā)測試。第 5 篇設計模式應用內(nèi)篇。有界隊列、線程池與工作竊取、Reactor/Proactor、Actor、協(xié)程與 sender/receiver。第 6 篇設計模式系統(tǒng)間篇 收官。Outbox、Saga、熔斷三件套、冪等消費者、CQRS附全系列坑對模式對照表。前兩篇單進程第 3 篇換尺度到分布式第 4 篇把對策收攏成紀律最后兩篇給可以直接抄的結構。怎么讀正在排查線上異步故障的直接等第 6 篇的對照表按坑找章節(jié)。要做方案設計的重點看第 4 篇的檢查清單。寫 C 的第 1、2 篇里每段觸發(fā)代碼都值得進 code review checklist。每篇獨立成立從任何一篇進來都不需要回去翻前面的涉及前面的概念會在文中就地講掉。完整版含代碼高亮和跳轉引用維護在倉庫倉庫鏈接發(fā)布時替換下一篇先從最熟悉的坑講起兩個線程一起counter為什么結果不是你想的那樣。