騰訊視頻Node.js服務是如何支撐國慶閱兵直播高併發的？
https://mp.weixin.qq.com/s/WKhALCAarFNOCQylBUryfQ
容錯，高可用和災備
http://www.ruanyifeng.com/blog/2019/11/fault-tolerance.html
．可用性：
進程守護
Node.js主進程守護，騰訊視頻這邊用shell腳本來執行，通過 crontab 命令，定時1min鐘去檢查一次進程(用ps指令)和埠(用nc指令)是否正常， 異常時重啟服務。目前社區有比較多的工具可以實現進程守護，比如pm2。在Nodejs Cluster模組，主進程會把TCP分配給worker進程處理，worker進程主要三個問題，僵屍進程，記憶體洩露和進程異常退出。
1. 僵屍(無回應)進程：當程式運行到閉環，就不再回應任何請求了，需要及時重啟，在Master進程定時向worker進程發心跳包，當worker進程在一段時間多次不回包時，殺死重啟。
2. 記憶體監聽：主要為了兜底記憶體洩露問題，當worker進程達到閾值時， 殺死重啟。
3. 進程退出：進程異常退出時， 需要重啟。
．容災策略：
1. 介面容災
介面容災主要應對依賴的底層介面異常。當後臺介面正常返回時，把資料緩存到redis，異常時，用redis的舊數據兜底。
2. 頁面HTML
兜底思路與口容災差不多，當頁面渲染異常時，中介軟體檢測到返回5xx，同樣用正常的緩存在redis的舊HTML兜底。
3. NodeJS容災
主要應對NodeJS工作異常，當NodeJS進程正常回應時，把靜態的HTML推到CDN作為備份檔案, 如果NodeJS返回5xx時， 在Nginx代理層重定向到靜態備份檔案。
．緩存：
1. CDN 緩存
a. 更新時間
由於CDN一般用於緩存靜態檔或更新細微性比較小的頁面，預設的緩存時間比較長，在介面上使用時需要注意更新時間，同時介面不能帶有隨機參數。
b. 緩存穿透、雪崩
目前自建CDN緩存沒有緩存鎖，當緩存失效到下一次緩存更新這一小段時間(一般在40~500ms)，所有的請求都回源到源站，併發比較高時，會有大量穿透到源站，底層沒有保護的話可能引起雪崩， 所以需要多級緩存。
2. Nginx代理層緩存
Nginx 除了提供基本的緩存能力外，還提供緩存鎖、緩存容錯能力，proxy_cache_use_stale可以配置，錯誤，超時，更新中和其它異常狀態時，使用舊緩存兜底和避免過多的的流量穿透到源站。同時proxy_cache_lock配置，可以防止配置沒有預熱時，緩存的穿透的問題。
3. 頁面緩存
在應用層或框架層，可以用redis實現第三層緩存，這層的redis緩存也是HTML渲染異常時兜底的基礎。實現思路比較簡單，需要關注兩個問題：
a. 頁面緩存版本不同步時，有無適配問題，如果需要識別版本，版本不匹配的緩存直接失效。
b. 是否需要設計緩存鎖來避免穿透問題，如果上層已處理(比如Nginx)，或下層能抗量流量可以忽略不加鎖。
整頁緩存細微性比較大，可以針對業務場景做拆分，比如針對部分推薦資料的頁面拆分頁面片緩存或介面緩存。
．日誌與告警：
告警和日誌，對故障早發現早處理，複盤根本原因至關重要，且每層的監控和日誌可以説明業務快速瞭解業務狀態。主要有：
1. 用戶端：提供了前端監控和告警，提供用戶側的監控，比如頁面品質，CGI品質， 用戶流水及手動上報的能力。
2. 反向代理層：由Nginx上報監控，監控訪問波動，錯誤量占比(4xx， 5xx)時耗時。
3. 請求日誌：主要記錄原站的總請求數，請求失敗資料及平均耗時。
4. Nodejs進程日誌：主要進程異常退出，記憶體洩露，僵屍進程等進程日誌， 對業務穩定運行， 非常重要。
5. Node請求流水日誌：主要記錄請求維度的開發自訂日誌，用於問題的定位複盤， 進程狀態觀測。
6. 模調監控：監控請求方和服務方的錯誤和回應時間的情況，當前模組與底層依賴模組的介面即時介面品質。
#可用性, 容災, 策略, 緩存, 日誌, 告警
https://mp.weixin.qq.com/s/WKhALCAarFNOCQylBUryfQ
容錯，高可用和災備
http://www.ruanyifeng.com/blog/2019/11/fault-tolerance.html
進程守護
Node.js主進程守護，騰訊視頻這邊用shell腳本來執行，通過 crontab 命令，定時1min鐘去檢查一次進程(用ps指令)和埠(用nc指令)是否正常， 異常時重啟服務。目前社區有比較多的工具可以實現進程守護，比如pm2。在Nodejs Cluster模組，主進程會把TCP分配給worker進程處理，worker進程主要三個問題，僵屍進程，記憶體洩露和進程異常退出。
1. 僵屍(無回應)進程：當程式運行到閉環，就不再回應任何請求了，需要及時重啟，在Master進程定時向worker進程發心跳包，當worker進程在一段時間多次不回包時，殺死重啟。
2. 記憶體監聽：主要為了兜底記憶體洩露問題，當worker進程達到閾值時， 殺死重啟。
3. 進程退出：進程異常退出時， 需要重啟。
．容災策略：
1. 介面容災
介面容災主要應對依賴的底層介面異常。當後臺介面正常返回時，把資料緩存到redis，異常時，用redis的舊數據兜底。
2. 頁面HTML
兜底思路與口容災差不多，當頁面渲染異常時，中介軟體檢測到返回5xx，同樣用正常的緩存在redis的舊HTML兜底。
3. NodeJS容災
主要應對NodeJS工作異常，當NodeJS進程正常回應時，把靜態的HTML推到CDN作為備份檔案, 如果NodeJS返回5xx時， 在Nginx代理層重定向到靜態備份檔案。
．緩存：
1. CDN 緩存
a. 更新時間
由於CDN一般用於緩存靜態檔或更新細微性比較小的頁面，預設的緩存時間比較長，在介面上使用時需要注意更新時間，同時介面不能帶有隨機參數。
b. 緩存穿透、雪崩
目前自建CDN緩存沒有緩存鎖，當緩存失效到下一次緩存更新這一小段時間(一般在40~500ms)，所有的請求都回源到源站，併發比較高時，會有大量穿透到源站，底層沒有保護的話可能引起雪崩， 所以需要多級緩存。
2. Nginx代理層緩存
Nginx 除了提供基本的緩存能力外，還提供緩存鎖、緩存容錯能力，proxy_cache_use_stale可以配置，錯誤，超時，更新中和其它異常狀態時，使用舊緩存兜底和避免過多的的流量穿透到源站。同時proxy_cache_lock配置，可以防止配置沒有預熱時，緩存的穿透的問題。
3. 頁面緩存
在應用層或框架層，可以用redis實現第三層緩存，這層的redis緩存也是HTML渲染異常時兜底的基礎。實現思路比較簡單，需要關注兩個問題：
a. 頁面緩存版本不同步時，有無適配問題，如果需要識別版本，版本不匹配的緩存直接失效。
b. 是否需要設計緩存鎖來避免穿透問題，如果上層已處理(比如Nginx)，或下層能抗量流量可以忽略不加鎖。
整頁緩存細微性比較大，可以針對業務場景做拆分，比如針對部分推薦資料的頁面拆分頁面片緩存或介面緩存。
．日誌與告警：
告警和日誌，對故障早發現早處理，複盤根本原因至關重要，且每層的監控和日誌可以説明業務快速瞭解業務狀態。主要有：
1. 用戶端：提供了前端監控和告警，提供用戶側的監控，比如頁面品質，CGI品質， 用戶流水及手動上報的能力。
2. 反向代理層：由Nginx上報監控，監控訪問波動，錯誤量占比(4xx， 5xx)時耗時。
3. 請求日誌：主要記錄原站的總請求數，請求失敗資料及平均耗時。
4. Nodejs進程日誌：主要進程異常退出，記憶體洩露，僵屍進程等進程日誌， 對業務穩定運行， 非常重要。
5. Node請求流水日誌：主要記錄請求維度的開發自訂日誌，用於問題的定位複盤， 進程狀態觀測。
6. 模調監控：監控請求方和服務方的錯誤和回應時間的情況，當前模組與底層依賴模組的介面即時介面品質。
#可用性, 容災, 策略, 緩存, 日誌, 告警
留言
張貼留言