《Go 語言併發之道》讀後感-第五章

大規模併發

這一章我或許沒有辦法寫出一些實例代碼，由於經驗有限。我會結合以往運維的一些系統舉出部分例子共讀者參考，詳情力薦閱讀原文。

異常傳遞

異常時什麼，何時發生，提供哪些好處？咱們須要明確如下信息：

• 發生了什麼，例如：磁盤已滿，證書過時，連接超時，不存在的路徑
• 發生在什麼時間，什麼位置，優秀的 Golang 第三方日誌庫能夠幫助到咱們
• 對用於友好的信息，例如：給與相似的提示信息，參考 linux 命令行提示
• 告訴用戶如何得到更多的信息，例如：man 手冊

異常一般被咱們分爲兩類：

• Bug 未知，未發現的錯誤
• 已知信息。例如：用戶傳入錯誤參數，網絡斷開，證書過時

正如上一章錯誤處理中所說咱們須要將錯誤視爲一等公民存在，我的認爲 Golang 錯誤處理機制的特立獨行，讓我從新審視系統中可能存在的錯誤。

超時和取消

超時：對於建立一個已於理解的系統是相當重要的，例如：TCP 連接中，咱們能夠利用超時避免連接佔用太久；etcd 中利用超時，規避全局時鐘一致性問題

咱們爲何但願併發程序支持超時呢？這裏有幾個緣由：

• 系統飽和
  • 請求在超時時不太可能重複
  • 沒有資源來存儲請求，例如：內存隊列的內存；持久隊列的磁盤空間；消息隊列阻塞
  • 若是對系統響應或請求發送數據有時效性要求，例如：訪問網頁
• 陳舊數據
  • Kafka log 清理機制，默認2小時前的數據被清理
  • Redis 中的緩存
• 試圖防止死鎖
  • 在關鍵的併發操做中增長超時處理

併發進程可能被取消的緣由有不少：

• 超時，隱式取消
• 用戶干預，例如：正在執行某個命令，等了過久，你按了 Ctr + c
• 父進程取消，例如：ppid 被 kill ,那麼所屬 pid 也會被 kill
• 複製請求，例如：同時有多個請求，哪一個最早返回用哪一個的

心跳

在分佈式系統中很是常見的，心跳是併發進程向外界發出信號的一種方式。書中討論了兩種心跳：

• 在一段時間間隔內發出的心跳，例如：Server 和 Agent 之間的通訊；分佈式系統中個節點的心跳，確保領導者存活的心跳；
• 在工做單元開始時發出的心跳，例如：分佈式計算任務，確認計算單元是否完成任務，或宕機

複製請求

當一個請求到達咱們的服務，咱們可使用 Nginx ，HAproxy 等分發到多個節點上，但這會消耗過多的計算資源，空間資源(服務器機櫃)，維護成本。若是咱們都在進程內，或進程間通訊，咱們僅僅多消耗了一部份內存資源。最爲典型的案例就是利用 Golang 重寫了負載層的中間件，例如：

• 百度 BFE
• CNCF traefik

速率限制

筆者最近剛剛到一家網絡安全公司就任運維工程師，瞭解到不少關於網絡攻擊的信息，最爲明顯的就是 DDoS，CC攻擊。DDoS 的攻擊多是利用 udp服務反射, 或殘缺報文形成流量洪峯，可能比較已於識別。可是 CC 攻擊，就是正常的訪問，大量的正常訪問，致使網站不可用。對於這樣的場景咱們不僅僅須要在負載層添加速率限制，在後臺內部調用層也須要添加。

特別是在容器化的環境中，彈性擴縮雖然美好。可是有一句至理名言，同樣東西有多光鮮，背後就有多陰暗。我曾經經歷過，服務瘋狂擴容致使運行在小機上的 Oracle 數據庫不堪重負的場景。在訪問 Oracke 也須要速率限制。

治癒異常的 goroutine

做者最後又再次強調了，治癒異常的 goroutine ，看來併發安全一直是一個很是值得關注的問題。

結束語

本次連載到此就要畫上句號了。至於原書的最後一章 goroutine 和 Go 語言進行時，我相信中文集裏面沒有人比劉丹冰講的更加透徹，但願各位給與做者三連支持。附上 B 站連接 GPM 模型

2021 讓咱們共同啓航，在十四五開局之年，金牛聚福，身體健康，驅疫避害。