[[351519]]

本文轉載自微信公眾號「虞大膽的嘰嘰喳喳」，作者虞大膽。轉載本文請聯系虞大膽的嘰嘰喳喳公眾號。  

最近我們直播可能要邀請一個明星，據說帶來的在線人數比較高。

聽到這個事情，我的第一反應不是直播系統本身的壓力，反而是整個系統的壓力，因為有人看直播，必須注冊、登陸、進入直播間，這些流量帶來的壓力不是很好評估。

解決復雜問題的第一步就是分解問題，所以可以先專注直播系統本身，至少要讓它健壯的運行。

對于直播，分為兩部分，核心推拉流用的第三方的，暫時忽略;第二部分就是一些輔助API接口(比如進入房間，在線用戶列表)，這些是需要重點衡量的。

直播系統API本身相對容易做容量評估，為什么呢?你把它當作一個封閉的系統單元，比如開一場直播，調用了那些接口，接口調用量都可以直接grep統計出來，也能找到峰值，注意這個峰值可以是單接口的峰值，也可以是匯總接口的峰值，第二個指標更有意義，可以統計出峰值對應的在線用戶數，資源消耗量(流量，redis，mysql)，從而進行容量預估。

各個接口之間的調用比例是多少呢?可以取平均值(這是我這次學習到的)，比如在線用戶接口平均每秒是10次，進入房間接口平均每秒1次，通過這種關系，大概明確了什么接口對系統的影響更大，什么接口響應時間較慢。

這種接口調用比例實際上對真實的壓測非常有意義。

那為什么現在沒有統計出呢?核心原因在于資源使用目前是耦合的，所以暫且拋開系統壓測和容量預估部署，解決復雜問題最好的方法就是隔離、隔離。

隔離的好處是什么?互不影響;更方便的統計;進一步衡量系統的健壯性。

首先考慮web服務器，就是阿里云ECS，直播系統的高峰是可控的，比如知道那個明顯要來了，也許高峰期可能就2小時，所以采用按量付費的ECS非常合適，1小時不到2元。

乘著這次機會重新安裝了一臺web服務器(包括所需要的軟件)，然后做了個鏡像，再申請ECS的時候就可以直接選擇這個現成的鏡像，非常方便，如果不考慮現在更流行的docker&k8s，這種云服務的可擴展性也是讓人很驚嘆的。

當然這種方式不是說秒級就能擴容，還是有很多細節的問題，比如預先并不知道新申請服務器的ip地址，掛載到slb的時候，也要手動配置。

雖然阿里云也有云服務API(不用登陸控制臺)，可以通過程序控制ECS的啟動，配置，但目前至少我們可以不采用，畢竟前提是我們知道直播高峰期什么時候來，可以提前做準備。

其次考慮SLB，這次把直播SLB也剝離出來了，原來我傾向購買包年包月的實例，有兩點原因。

1：官方說包年包月峰值帶寬更有保障。2：如果一個業務平時訪問畢竟均勻，使用包年包月成本更低。

但我們業務突飛猛進，動不動就能一個峰值，而為了這個峰值，需要購買更高流量包(包年包月)，確實比較耗費成本。

最終選擇直播SLB購買按量付費，成本可控，而且非高峰期也可以回收，使用原有SLB，這個過程能夠自動化就更好了。

然后是數據庫，直播系統本身使用的數據存儲量并不高，所以暫時沒有使用阿里云RDS，使用自建且獨立的mysql 5.7，不知道其他公司是如何的，從成本角度考慮，自建mysql和阿里云RDS可以并行存在。

最后就是Redis，隔離Redis也很簡單，如果直播業務是將redis當緩存使用，或者redis數據也會同步到mysql，那么購買按量付費的redis也是比較合適的。

選擇何種規格的redis，建議關注連接數，只是目前還沒有找到峰值和redis連接數之間的關系。

對于高峰，首先要做壓測，其次要做容量評估，接著是隔離，最后是應用層優化。

對于應用層優化要持續做，原因很簡單，優化一小步，成本就會減少很多，系統的支撐能力就會變大。

遇到一個問題，我的第一反映就是先優化，本質上是沒有錯誤的，但是優化的成本要小于優化的效果，至少別影響業務開發，經驗告訴我們，在初期，優化的效果是很明顯的。

三板斧：減少接口調用，數據緩存化，策略優化(結合需求)。

后面還會再寫兩篇，理理思路。