高頻分佈式系統一些關鍵點記錄

1,  任務調度問題問題。

任務調度會遇到下面的坑：

    1.1，任務丟失。

        業務中出現過幾種任務丟失的狀況。第一種，使用不熟悉的隊列rabbitmq，使用不熟悉的鏈接池，沒使用ack，io過高後出現廢棄鏈接，任務丟失。第二種，使用隊列自帶超時，最後由隊列推斷在隊列階段丟棄了任務。

    1.2，任務校驗：入口參數校驗，獲取文件大小校驗，上傳文件大小校驗。分佈式系統都是不可靠的。被坑過幾回。

    1.3，任務狀態的變動。

    1.4，持久化／削峯。對於多階段任務，須要持久化，避開跨部門或者跨小組溝通，同時方便任務從新導入。

    1.5，任務重發。注意去重和哈希。

    1.6，任務優先級問題。

3，批量io。注意io 合併，使用多級buff，儘可能少io。

4，http parse 致使cpu 過高。在高頻請求的時候，解析http 請求時，儘可能使用c 庫封裝的庫。

5，三線機器問題，注意兩個點，一個是出口ip bind，一個是查詢dns 的時候bind ip。

6,  日誌太多，適當控制。分級別log ，能明顯提升性能。

7，高併發的日誌，要帶上階段 和taskid，便於查問題。多線程或者多協程，日誌不帶id，或者日誌位置不對的，都是白打的日誌，你都不知道是哪一個任務生成的。

8，鏈接池的單例共享。

9， 全局catch，防止全局崩潰。

10，優雅退出。通常捕捉信號，循環位標記，而後退出。

11，內存queue的去重問題。定時器從新推任務到隊列前，應該看下set中是否有這個任務了。

12，隊列餓死。重cpu任務，致使cpu打滿，上下文不能切換，隊列之間出現某些隊列始終不消費的狀況。

13，原子計數問題。

14，阻塞仍是非阻塞獲取任務的問題。

15，業務異常的監控。對錯誤日誌，隊列等敏感信息監控。