開發和運維高併發系統的工程師可能都有過類似經驗，明明系統已經調優完畢，該非同步的非同步，該減少互斥的地方引入無鎖，該減少io的地方更換引擎或者硬體，該調節核心的調節相應引數，然而，如果在系統中引入實時監控，總會有少量響應的延遲高於均值，我們把這些響應稱為尾延遲（tail latency）。對於大規模分布式系統來說，尾延遲的影響尤其嚴重，例如大規模搜尋引擎，單個請求可能就會傳送到上萬台伺服器，系統不得不等待尾延遲響應返回之後才能返回給使用者。
尾延遲可能是程式設計本身導致的毛病，但是，即便程式設計完全無誤，尾延遲依然可能存在。華盛頓大學的jialin li等人經過研究發現，硬體，作業系統本身，都可能導致尾延遲響應，例如：主機系統其他程序的影響，應用程式裡執行緒排程，cpu功耗設計等等。
heracles把資料中心執行的任務分為兩類：be(best effort batch)和lc(latency critical)，lc型任務執行依賴嚴格的slo(service level objectives，包含cpu快取，主存，io，以及網路等主機物理資源)。混排時，由於物理資源的slo衝突導致lc任務會有更多的尾延遲發生。heracles的目標在於提供對這些共享資源更好的隔離機制，盡可能避免slo衝突。下邊分別談談這些引起slo衝突的共享資源：
cpu方面：
作業系統的資源排程，不能簡單地給lc任務分配更高的優先權來達到目標，通常的linux核心排程演算法cfq(公平排程器)在lc和be混跑時，會輕易導致大量slo衝突。實時排程演算法如sched_fifo則會導致很低的資源利用率。cpu設計中的超執行緒機制，也會給問題帶來更多的複雜性，例如：乙個超執行緒在執行be任務時，會從cpu指令頻寬，共享l1/l2快取，tlb等方面影響另乙個超執行緒執行的lc任務。
記憶體方面：
大多數lc型任務都會依賴巨大的記憶體，例如搜尋，記憶體kv等等，因此，這些任務的延遲對於記憶體的頻寬非常敏感。目前並不存在硬體機制來確保記憶體頻寬隔離，而在多cpu機器上簡單地採用numa機制又會導致不能充分使用記憶體，或者訪問遠端cpu socket記憶體區域而帶來更大的延遲。
網路方面：
大多數資料中心都會通過精細設計拓撲圖來確保機器之間雙向通訊的頻寬。在單機情況下，可以通過修正一些協議棧確保lc型的短訊息能夠比be的大型訊息有更高的優先權
功耗是另外乙個不得不考慮的因素：
大多數cpu都有節能設計，系統會根據平均負載來動態調整cpu的主頻，因此混跑時的負載取決於lc和be的平均負載，當cpu主頻降低時，lc型任務的延遲也會受到影響。
heracles在設計上引入多種隔離機制，在確保slo時盡可能提公升資源使用負載：
cpu方面：heracles會借助cpuset和cgroups盡可能讓lc和be型任務不在同乙個core上執行。此外，heracles採用了目前intel cpu上的cat(cache allocation technology)技術，這是個硬體機制。cat可以在共享的l1/l2快取上定義分割槽，確保快取不會相互汙染。
記憶體方面：由於目前並不存在硬體的隔離機制，因此heracles實現了乙個軟體層面的監控機制，定期檢查記憶體頻寬使用情況，並估計lc和be的頻寬使用，如果lc沒有獲得足夠的頻寬，heracles會減少be使用的cpu core數目。
網路方面：heracles使用了linux流量控制機制——qdisc排程器，確保be任務的吞吐量和配額，並頻繁更新排程策略。
功耗方面：heracles基於現有硬體支援的特性實現了主頻監控。
通過這些工作，heracles讓google資料中心的集群資源使用率達到了驚人的90%。在思路上，heracles的實現並不複雜，但它是跟borg一體化的系統，我們不能說實現了這些資源隔離手段就能解決了尾延遲，因為單機的資源管理與隔離跟資料中心作業系統是一體化的。
實時上，除了依賴於複雜的heracles和borg機制，google之前也曾經公開了另一種簡單有效的策略對付尾延遲：在12年左右我們曾經看到過google基礎架構之神jeff dean的一篇slide，裡邊提到了google分布式系統響應的概率延遲分布。在該slide發布的時候，並沒有引起本人的關注，因為當時並沒有猜透這些概率分布的背後代表了什麼意義。結合尾延遲，我們終於可以更好的了解這些意圖：尾延遲的發生可以看作是隨機行為，引入多副本，任何乙個請求，都會多次傳送到多副本之上，系統會選擇延遲最短的響應返回，就可以大大降低尾延遲對於最終響應的影響，十分簡單有效的思路。至於傳送多少次，就是這些概率延遲分布數字本身的意義了。
可能這個思路對於大多數基礎架構開發者來說，是更加簡單有效的策略，與其試圖從作業系統核心和distributed os來解決這個挑戰，不如放到應用層，多副本多次傳送單個請求。在複雜與簡單上，google都是我們重點學習的物件。
高併發系統中的常見問題
本文一共分析了三個案例，分別介紹併發系統中的共享資源併發訪問 計算型密集型任務快取訪問 單一熱點資源峰值流量問題和解決方案。q1 訂票系統，某車次只有一張火車票，假定有1w個人同時開啟12306 來訂票，如何解決併發問題？a1 首先介紹資料庫層面的併發訪問，解決的辦法主要是樂觀鎖和悲觀鎖。樂觀鎖 假...
web中的高併發
併發的問題，我們具體該關心什麼？講真話，高併發是個比較抽象的概念。很難有乙個統一的可衡量的標準。哪麼有一些其它維度的標準指標來衡量系統的效能嗎？搬出以前計算機課程裡邊的一些指標來跟大家聊聊。先宣告幾個概念，別打瞌睡。qps tps 每秒鐘 request 事務 數量，在網際網路領域，指每秒響應請求數...
限流 高併發系統中的流量控制
限流指的是限制系統的併發訪問策略，保證系統能夠接受部分使用者的請求，而對於超過流量控制的請求，系統會拒絕請求。限流是為了保護系統不會被過載的流量打垮，其通常做在服務入口層如閘道器，它可以對整個系統，某個服務，某個介面，某個ip或者某個使用者做限制。常用的限流演算法有固定視窗，滑動視窗，漏桶演算法與令...