Go篇｜三高指標

這是我參與更文挑戰的第16天，活動詳情查看： 更文挑戰

碎碎言

本項目是重學Go語言後的實戰項目，主要目的是加深Go學習，並經過此學習，對系統的高可用，高併發，高性能可以進一步的學習。

一我的走的很快，一羣人走的更遠，歡迎留言點評提出大家的問題和建議。將來的日子裏，一塊兒成長，加油！！！

時間計劃：6月13日-6月30日

日期：2021年6月16日

今日內容：高可用、高性能、高併發的指標

前面咱們將功能性的需求幾乎都已經都陳列出來，這些幾乎是從外部因素考慮的。但對於運行系統的環境，以及系統的併發能力也是咱們須要考慮的，這部分可稱爲非功能需求。

非功能性需求包括：可用性、併發能力、性能、安全防禦能力、水平擴容縮容能力、運維/運營成本等

好比：一個系統的可用性達到99.99%。併發能力達到100萬QPS，請求延遲低於500ms，能防範跨站腳本攻擊，1分鐘快速擴容，總成本控制在10萬元每個月等等，這些都是非功能需求要知足的。

因此，系統須要知足非功能需求的一些指標，以防止系統在運行時出現重大的故障。

秒殺系統的核心非功能需求主要有：高可用指標、高性能指標、高併發指標

高可用指標

• MTBF(Mean Time Between Failure 平都可用時長) ：系統正常、穩定運行的平均時長
• MTTR（Mean Time to Repair 平均修復時長）：系統從失效後到恢復正常所耗時的平均時間
• SLA（Service-Level Agreement 服務等級協議）：用於評估服務可用性等級，公式是SLA=MTBF/(MTBF+MTTR)。可用性高於99.99%，是指SLA高於99.99%

系統高可用的指標是SLA來判斷

系統P 是由四個子系統a、b、c、d構成。那麼，系統P的SLA是低於其餘四個子系統；下游系統的SLA一般須要高於上游SLA，這樣才能保證上游系統的穩定

高併發指標

QPS（Queries Per Second 每秒查詢率）是衡量系統的承載能力。

不一樣的業務對併發能力要求不一致，用戶量小的系統對併發要求相對比較低，用戶量大的就要求比較高。

評估高併發指標，一般須要從用戶增加、用戶習慣、業務形態、系統承載能力等方面分析。就好比，秒殺系統，用戶量確定遠大於庫存量，庫存一旦爲0則活動就結束。

系統資源在設計上保留10%～20%的餘量，以便應對突發流量

評估用戶增加狀況，須要月/日活用戶的量，再加上因推廣過程帶來的用戶增加來預估一個當日活動可能達到一個用戶量。而後在業務系統設計上保留餘量。

好比評估業務承載最高270萬QPS，底層Redis承載能力1萬QPS。實際設計中，業務承載服務300萬，要高些以防突發突增流量，底層Redis資源8000QPS，低一些，由於底層資源比較固定不容易擴容，須要限制QPS不要超出其最大承載能力

高性能指標

對於電商平臺若是訪問請求超過2s影響用戶體驗，超出5s有可能致使流失用戶，形成損失。如下因素將會影響性能指標：

• 用戶網絡環境
• 請求/返回數據大小
• 業務系統CPU、內存、磁盤等性能
• 下游資源的性能
• 算法實現是否高效
• 請求鏈路長短

爲確保知足性能要求，咱們對這邊流量比較大的系統通常須要作大量的性能測試和性能調優。

場景：用戶請求系統的網絡環境延遲100ms，請求/返回數據處理爲10ms，業務內部磁盤操做30ms，請求下游資源10ms，算法計算5ms。那麼，整個請求共耗時將超過155ms。

若是超過155ms對公司形成必定損失，那麼咱們還須要繼續優化性能。固然，優化過程也須要考慮成本等各類問題，並不是指標越高越好。