高性能高併發系統的穩定性保障

做者：肖飛，於2011年8月份加入京東，曾親身參與到京東的應用性能監控、統一日誌、流式計算、內存緩存、四層防攻擊等一些基礎技術平臺的研發和搭建工做，經歷了京東的技術系統從簡單粗放向複雜精細化的演變過程。目前主要工做爲多中心交易項目中的數據複製中間件JingoBUS的研發。平時也會開發一些公共的平臺和工具，關注分佈式系統的實現、程序設計、性能優化、開發語言等。
　　性能、併發、穩定性三者關係

高性能：高吞吐量、低延時

公式：吞吐量（併發）=單位時間/平均延時

N-th% Latency：TP99, TP999

穩定性：低延時的穩定性標準爲TP99/TP999是隱含的必要條件；系統的穩定性標準：高+可用；用戶標準

　　吞吐量：QPS， TPS，OPS等等，併發。並非越高越好，須要考慮TP99。用戶角度：系統是個黑盒，複雜系統中的任何一環到會致使穩定性問題。SLA：在某種吞吐量下能提供TP99爲n毫秒的服務能力。下降延時，會提升吞吐量，可是延時的考覈是TP99這樣的穩定的延時。

　　如何改善延時

　　你應該知道以下表格

　　

　　原文：http://www.eecs.berkeley.edu/~rcs/research/interactive_latency.html

　　JeffDean

　　Disk random read IOPS:

　　IOPS = 1000 / (4 + 60000/7200/2) = 122

　　IOPS = 1000 / (4 + 60000/10000/2) = 142

　　IOPS = 1000 / (4 + 60000/15000/2) = 166

　　SSD random read IOPS:

　　IOPS = 1000000/16=62500

　　數字的啓示

高速緩存的威力；

線程切換代價cache miss

順序寫優於隨機寫

局域網絡快於本地HDD

大塊讀優於小塊讀

SSD解決隨機讀寫

跨地域IDC網絡是最大的延時

　　策略

關鍵路徑：「28原則」（20%的代碼影響了80%的性能問題，抓重點）、「過早優化是萬惡之源」。不一樣解讀；

優化代碼：空間換時間：各級緩存；時間換空間：好比傳輸壓縮，解決網絡傳輸的瓶頸；多核並行：減小鎖競爭；lesscode；各種語言、框架、庫的trick；算法+數據結構，保持代碼的清晰、可讀、可維護和擴展；

經過性能測試和監控找出瓶頸

　　metric

　　

　　原文：http://www.vpsee.com/2014/09/linux-performance-tools/

　　經過性能測試和監控：

單系統operf/jprofiler etc；

Java的一系列工具：jstat, jstack, jmap, jvisualvm,HeapAnalyzer, mat

分佈式跟蹤系統：Dapper，鷹眼等

　　benchmark

　　

　　原文：http://www.vpsee.com/2014/09/linux-performance-tools/

　　微觀

內存分配

　　吞吐量和利用率的權衡

　　顯式分配器：jemalloc/tcmalloc代替默認的ptmalloc

　　隱式分配器：JVM GC的各類調優

　　是否使用hugepagen預分配和重用：Netty的Pooled ByteBuf

　　減小拷貝：new ArrayList(int), new StringBuilder(int)

　　內存分配器利用率：減小內部或外部碎片；Page Table（頁表）， TLB（頁表寄存器緩衝），減小TLB miss,pin cache。增長COW的開銷, 與內存分配器的實現衝突。JVM的GC調優是不少Java應用的關注重點。

減小系統調用

　　批處理: buffer io，pipeline

　　使用用戶態的等價函數: gettimeofday ->clock_gettime

　　減小鎖競爭

　　RWMutex

　　CAS

　　Thread local

　　最小化鎖範圍

　　最小化狀態，不變類

　　批處理增長了內存拷貝的開銷，可是減小了系統調用開銷，減小了上下文切換的影響。bufferio的例子：日誌、網絡讀寫。pipeline的例子：redis。

減小上下文切換

　　觸發：中斷、系統調用、時間片耗盡、IO阻塞等

　　危害：L1/L2 Cache Missing，上下文保存/恢復

　　單線程：基於狀態機redis和Master/Worker的nginx

　　CPU親和性綁定

　　ThreadPool的配置，不一樣任務類型不一樣的ThreadPool

　　幾個例子：一、docker中線程池大小的核數自動設定；二、CPU節能模式；三、CENTOS-7.1內核BUG。

網絡

　　內核TCP Tuning參數和SocketOption：net.ipv4.tcp_*

　　TCP Socket鏈接池

　　網絡I/O模型

　　傳輸壓縮

　　編解碼效率

　　超時、心跳和重試機制

　　網卡：多隊列中斷CPU綁定；增長帶寬：萬兆、Bonding；Offload特性：ethtool -k eth0；UIO Driver: DPDK

　　鏈接池：減小握手、減小服務端session建立消耗。網絡I/O模型：BIO、Non-Blocking IO、AIO；select/poll、epoll/kqueue、aio；netty使用nativetransport。Offload特性：ethtool-k eth0。 將數據包分組、重組、chksum等從內核層放到硬件層作。

　　如何提升吞吐量

　　改善和下降單機的延時，通常就能提升咱們的吞吐量。從集羣化上講，因素就比較多。

　　宏觀

提高系統擴展能力

應用的無狀態架構

緩存/存儲的集羣架構：冗餘複製（負載均衡、異構解除系統依賴）；分佈式（數據sharding , 副本，路由，數據一致性）；切換

微服務/SOA

擴容

異步化

緩存

複製
經過複製提升讀吞吐量、容災、異構

經過數據分片，提升寫吞吐量

程序雙寫：一致性難以控制，邏輯複雜，冪等性要求。徹底把控複製和切換時機。異構系統惟一選擇。 同步雙寫（數據一致性高，影響性能，不適合多個複製集）；異步雙寫（數據一致性差，性能高，適合多個複製集）；CDC[Change Data Capture]（canal,databus等）

底層存儲複製機制：一致性由底層控制，對應用端透明。程序和底層存儲配合切換

擴容
每一年大促前的核心工做：該擴容了嗎？現狀分析；擴容規劃（關鍵系統峯值20倍吞吐量）；擴容依據（架構梳理、線上壓測）；

擴容checklist：前（部署、DB受權....）；後（配置更新、LB更新、接入日誌、接入監控....）

應用擴容、數據擴容、寫擴容、讀擴容

垂直擴容：加內存、升級SSD、更換硬件。數據複製、切換

水平擴容：數據遷移或初始化

　　現狀分析：去年雙十一到目前，峯值時的性能數據；軟硬件性能指標；數據存儲容量。

　　擴容規劃；流量規劃：核心系統20倍吞吐量；數據增加量規劃；擴容依據；架構梳理；線上壓測。

　　讀擴容比寫擴容難；讀寫分離。

　　異步化

解耦利器

削峯填谷

頁面異步化

系統異步化

JMQ

狀態機（worker）+DB

本地隊列

集中式緩存隊列

　　本地內存隊列：實時價格回源服務響應以後，經過BlockingQueue異步更新前端緩存。本地日誌隊列：庫存預佔。集中式緩存隊列：商品變動任務下發系統。

　　異步化的一些例子：

　　一、操做系統內核的高速緩存隊列，磁盤延遲刷盤；

　　二、mysql數據庫複製、redis複製；

　　異步化須要注意的是：

　　一、任務要落地；

　　二、不可避免的重複執行，須要冪等；

　　三、是否須要保證順序、如何保證順序。

　　緩存

久經考驗的局部性原理

多級緩存：瀏覽器browser cache、cdn、nginx本地redis緩存、本地JVM緩存、集中式緩存...

緩存前置：2/8原則、單品頁、實時價格、庫存狀態

一致性、延遲權衡

緩存主節點負責寫，和最重要的校驗

經過CDC監聽數據庫binlog主動更新緩存

CPU不是瓶頸，網絡纔是

優化編碼，減小尺寸

優化操做

優化拓撲

　　如何保障穩定性

　　宏觀

提升可用性

分組和隔離

限流

降級

監控和故障切換

　　可用性

可用性衡量指標：幾個9

可用性度量：A = MTBF / (MTBF + MTTR)

減小故障、加長可用時間

減小故障修復時間（發現、定位、解決）

冗餘複製、災備切換，高可用的不二法門

如何快速切換？

切換的影響

監控、ThoubleShooting、軟件質量的影響

　　可行性指標：999,一週10分鐘；9999，一週1分鐘不可用。可用性：從客戶角度。可用性度量：A = MTBF / (MTBF + MTTR) ，其中MTBF表示mean time betweenfailures，而MTTR表示maximum time to repair or resolve。

　　高可用行性的成本和收益，好鋼用在刀刃上。

　　如何快速切換：有能夠切換的？能夠不重啓應用麼？ 操做快捷麼？演練過麼？

　　切換的影響：切換目標資源可否承受新增的壓力；切換是否影響狀態（數據的一致性、丟失問題）。

　　監控到位、即時，減小故障發現時間；監控全面，增長故障分析時能夠參考的數據。

　　troubleshooting的能力，踩坑的精力， COE，問題本質、根源的追查。

　　軟件質量：編碼是否健壯、（異常處理、防護性、2/8原則）超時處理、日誌是否全面合理、線程名稱等等。

　　測試：case是否全面、自動迴歸。

　　上線：是否灰度：N+1, N+2；回滾方案、數據回滾。

　　分組和隔離

網絡流量隔離：大數據單獨部署，QOS；

業務系統隔離：秒殺系統獨立出主交易；

流量分組：對使用者按照重要程度、請求量、SLA要求等因素分級

存儲的分組：按照使用者重要程度、實時性要求等因素，將數據庫的複製集分組

　　傳統世界的例子：道路被劃分爲高速道路、自行道、人行道等，各行其道。

　　流量分組

　　舉例：商品基礎信息讀服務。對使用者按照重要程度、請求量、SLA要求等因素分級，將服務實例和存儲分組：交易、生產、網站、移動、promise、ERP...

　　讀寫分離

　　舉例：商品主數據服務。按照使用者重要程度、實時性要求等因素，將數據庫分組：ERP、POP、網站、大數據平臺...

　　限流

限流原則：影響到用戶體驗，謹慎使用

區分正常流量和超預期流量：限流標準來自壓力測試、折算

讀少限，寫多限

客戶端配合限流

不一樣分組的限流閾值

各層限流手段

　　前置限流，快速失敗：好比經過提供給調用方的JSF客戶端，封裝限流邏輯。

　　Nginx層限流：自主研發的模塊；幾個規則：帳戶，IP，系統調用流程。

　　應用限流：減小併發數線程數；讀少限，寫多限；DB限流；鏈接數。

　　降級

保證用戶的核心需求

降級須要有預案和開關：肯定系統和功能級別，是否可降，影響如何；降級須要有開關

非關鍵業務屏蔽：購物車的庫存狀態

業務功能模塊降級：實時價格更新不及時；peking庫，保訂單管道、生產，暫停統計相關

數據降級：動態降級到靜態；遠程服務降級到本地緩存：採銷崗服務

　　監控和切換

無所不在的監控：網絡流量；操做系統指標；服務接口調用量、TP9九、錯誤率...；日誌；業務量變化；太多監控了，如何提升監控的質量

切換：切換開關；成熟的流程可自動化；數據的重要性、一致性，要求強一致的，能夠人工介入；系統的指標無法判斷、監控點不全的，需人工判斷決定

　　review

　　

　　Nginx層限流：自主研發的模塊；幾個規則：帳戶，IP，系統調用流程。

　　應用限流：減小併發數線程數；讀少限，寫多限；DB限流；鏈接數。

　　如何驗證性能和穩定性

線上壓測：兩類壓力測試場景（讀業務壓測、寫業務壓測）；壓力測試方案（從集羣中縮減服務器、複製流量、模擬流量、憋單）

全流程演練：降級、切換等

　　讀業務壓力測試：是將線上業務隔離後,壓測至系統臨界點,經過分析系統在臨界點時軟硬件指標定位系統短板並優化。

　　寫邏輯壓力測試,若是數據具備不可恢復性,必定要提早作好數據隔離保護,如訂單號壓測,爲避免影響線上業務,壓測先後都要作好「跳號」以隔離線上數據。

　　從集羣中縮減服務器。加大單臺服務器的壓力。大概估算出正常的集羣規模可以承載的流量。

　　複製流量。主要經過 Tcpcopy 複製端口流量,多層翻倍放大流。

　　模擬流量。模擬流量主要腳本攻擊工具和壓測工具結合,主要用ab,siege,webbench,loadruner經過多臺機器壓測。分機房,按分支進行壓測。

　　憋單。主要針對後續的訂單生產系統壓測。經過在管道積壓一批訂單,而後快速釋放,造成對後續生產系統持續快速的衝擊,達到壓測的目的。

【擴展閱讀】千萬級規模高性能、高併發的網絡架構經驗分享 - 張善友 - 博客園 http://www.cnblogs.com/shanyou/p/5048099.html————————————————版權聲明：本文爲CSDN博主「天府雲創」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處連接及本聲明。原文連接：https://blog.csdn.net/enweitech/article/details/53785923