從上圖可以看到批量消耗平均耗時在100ms以上，有時候甚至超過500ms，這是在1分鐘內的平均耗時，我看過請求日誌有些甚至在1000ms以上。
對於乙個有著4億請求量的服務來說，為了保證服務的質量與效能，該介面必定在優化名單之內的。
先從**看起
整體**梳理了一遍，沒有什麼太大的問題，不存在一些常識性的問題。
紅框圈出來的部分是單次消耗的邏輯。需要進行必要的複雜的有db互動邏輯。然後我觀察了一下請求日誌，單個消耗時間大概在10ms左右，但是架不住批量消耗的使用者多，有的甚至超過100個。所以疊加起來的時間久長了。
問題已經描述清楚了，大家有什麼好的思路嗎？
我看到此類問題第一反應就是按使用者維度用執行緒池開多執行緒。因為使用者與使用者之間是隔離的，開多執行緒完全不用擔心併發問題。
首先看了一下伺服器的負載，開多執行緒沒啥問題。
但是，統計了一下請求日誌，發現大部分批量消耗只是乙個使用者。這時候開多執行緒就沒有意義了。
這時我們的終極方案該上場了，就是乙個字「合」，簡而言之就是多筆消耗業務合併成一筆消耗業務，減少與db互動的次數。
方案再細化就是：
1、按照資源消耗可拆分的最小粒度進行分組，換句話說就是將將相互不影響的單次消耗拆分到各個組裡面去，多執行緒各個分組批量消耗。目前拆分完了只會有乙個分組，開多執行緒是為了以後擴充套件需要。
2、具體的批量消耗為，將資源由原來的每筆消耗扣減一次合併成一次彙總扣減，然後在這個過程中記憶體構建消耗明細，非同步批量插入到資料庫中去。
到此批量消耗優化結束，理論上和單筆消耗的效能差距不大，甚至效能會更好，因為少了插入消耗明細與db的互動時間
億級流量架構之服務降級思路與方法
如果看過我前面對服務限流的分析,理解服務降級就很容易了,對於乙個景區,平時隨便進出,但是一到春節或者十一國慶這種情況客流量激增,那麼景區會限制同時進去的人數,這叫限流,那麼什麼是服務降級呢?簡單來說就是,將一些不太重要的景區專案砍掉,平時就那麼三五八個人,景區可以開放湖中游泳啦,摸魚啦,捉蝦啦,有情...
億級流量系統多級快取架構8 服務降級
在高併發場景下，當系統中的一些功能元件出現異常，無法繼續提供伺服器的時候，為了保證整體系統可用性，可以犧牲一部分功能依舊提供有損服務 服務等級定義 sla service level agreement 是判定壓測是否異常的重要依據。壓測過程中，通過監控核心服務狀態的 sla 指標資料，您可以更直觀...
億級日誌log4j2接入Kafka方案
bigdata001.dns.org 9092,bigdata002.dns.org 9092 2000 4level d m n 日誌接入必須非同步，絕對不能影響服務效能，這裡有個比較大的坑是max.block.ms property，kafkaclient包裡預設值是60000ms，當kafka...