當乙個服務已經負載不了當前的請求壓力的時候，應該主動暫停或者拒絕新到來的服務請求，以保證自身存活，以及防止雪崩效應。
我們舉乙個例子來說明雪崩效應。
比如說有乙個erlang的程序：
突然收到大量請求，請求數遠大於該程序的處理能力。
如果這個時候這個程序決定服務所有請求，就需要將所有請求buffer在記憶體中，然後乙個個處理（或者好幾個並行處理）。
這個時候，由於大量請求占用了大量的記憶體，erlang的gc開始顯得吃力。
為了服務其中的某個請求，需要申請新的記憶體。
但是由於buffer住了大量請求，不夠記憶體分配給請求處理。
這個時候erlang就陷入了乙個gc與記憶體申請的死迴圈：要處理完這個請求就得申請記憶體，要申請記憶體就得gc，要gc就得處理完這個請求（否則都是有用的記憶體），loop forever，然後因為oom crash。
以前我對服務降級的認識停留在該節點壓力過大不可用，需要減少請求以保證服務不會出現crash，而沒有想過這個降級會給集群提供乙個更加優越的效能表現。這裡分享下我遇到的乙個涉及服務降級的坑。
先簡單介紹下公司的集群架構。我們的集群大概就是乙個接入集群，後接乙個rabbitmq集群，通過rabbitmq，與後端的邏輯伺服器實現非同步請求。大概如下所示：
front < ——— > rabbit mq < ———> logic cluster < ———> storage
為了方便測試效能瓶頸，我們測試的時候，每個點都是只有乙個程序，並且在同一臺機器上執行。照說在乙個機器上，cpu分配如果均勻的話，邏輯伺服器應該是可以hold住所有從front過來的請求，哪怕再多也沒關係。另外邏輯伺服器由於從mq拿訊息來處理，理論來說應該是有多少處理多少，不存在壓力過大的問題，但是實際測試發現，邏輯處理伺服器不斷oom。
仔細分析了**後，我們發現邏輯服務處理mq過來的資料有問題，邏輯伺服器拿mq資料並且分發的邏輯如下
mq -> mq client -> mq proxy -> mq receiver -> [workers]
通過erlang的線上分析工具，我們最後定位到大量記憶體被使用到了mq proxy 和 mq receiver上，他們的的erlang msgq堆積大量資料，而上層又處理不過來，出現雪崩，於是導致了oom。
進一步檢查，發現是 mq proxy上對記憶體檢測的速度過慢，檢測之後還要上傳訊息給mq client，告知其停止訂閱，這個過程過於緩慢，導致了訊息堆積。
知道了oom的問題出在這裡，就有思路了，我們主動將過多的請求直接丟棄，然後停止消費mq，主動降級服務，並且降低proxy發現訊息堆積的閥值，oom就不再出現了。當然這個不是最好的辦法，但是是最快處理的辦法。最好的方法是通過服務發現，將伺服器壓力實時廣播出去。
事實上，在我們做了服務降級之後，我們的服務不再oom了，愉快做了大量的效能優化。直到前兩天，又一次效能測試，發現由於服務降級的壓力閥值設定過低，導致突然有壓力的時候，集群又進入了另乙個死迴圈：
壓力突增 -> 乙個節點服務降級，拒絕服務 -> 其他節點也因為壓力增加，而拒絕服務 ->訊息堆積到mq -> 服務恢復，重新訂閱mq -> 積壓的訊息一下湧入新啟動的服務 -> 服務又一次進入降級處理
這裡的問題就是，服務降級的閥值過低，導致本來可以服務的節點，以為自己應該拒絕服務了，最後導致了後續的雪崩。
所以，服務降級具體應該以乙個什麼閥值來降，並不是乙個隨便定的事情，需要乙個經驗值，也需要結合具體環境進行適配。
如何讓效能提公升10萬倍以上
從100萬個數字中找最大的10個數 提前是元素都是int 思路演化闡述 1 從10個數中找出最大的數？思路1 先排序啊。這也是我的第一思路，用冒泡呢？還是 直接插入 還希爾呢？我在腦子轉了一圈，在比較那個排序更優。其實你做了之後發現，這些排序都的迴圈套迴圈，時間複雜度o nxn 下面給的氣泡排序 p...
阿里天蠍計畫 伺服器部署效率提公升10倍
本文講的是阿里天蠍計畫 伺服器部署效率提公升10倍7月16日，由阿里巴巴自主研發的整機櫃伺服器解決方案 alirack 在中國可信雲大會上首次亮相。基於天蠍技術規範的alirack產品已規模化應用於阿里巴巴的資料中心，對比傳統方式，伺服器部署效率提公升10倍，總體擁有成本 tco 降低5 預計進一步...
伺服器主動推送
1.客戶端輪詢 ajax定時拉取 2.服務端主動推送 websocket 全雙工的，本質是乙個額外的tcp連線，建立和關閉時握手使用的http協議，其他資料傳輸不使用 http協議更加複雜一些，適用於需要進行複雜雙向資料通訊的場景 3.服務端主動推送 sse server send event ht...