前言
在實(shí)際項(xiàng)目中，曾經(jīng)遭遇過(guò)線上5W+QPS的峰值盔腔，也在壓測(cè)狀態(tài)下經(jīng)歷過(guò)10W+QPS的大流量請(qǐng)求，本篇博客的話題主要就是自己對(duì)高并發(fā)流量控制的一點(diǎn)思考月褥。
應(yīng)對(duì)大流量的一些思路
首先弛随，我們來(lái)說(shuō)一下什么是大流量？
大流量宁赤，我們很可能會(huì)冒出：TPS（每秒事務(wù)量）舀透，QPS（每秒請(qǐng)求量），1W+决左，5W+愕够，10W+，100W+...佛猛。其實(shí)并沒(méi)有一個(gè)絕對(duì)的數(shù)字惑芭，如果這個(gè)量造成了系統(tǒng)的壓力，影響了系統(tǒng)的性能继找，那么這個(gè)量就可以稱之為大流量了遂跟。
其次，應(yīng)對(duì)大流量的一些常見(jiàn)手段是什么婴渡？
緩存：說(shuō)白了幻锁，就是讓數(shù)據(jù)盡早進(jìn)入緩存，離程序近一點(diǎn)边臼，不要大量頻繁的訪問(wèn)DB哄尔。
降級(jí)：如果不是核心鏈路，那么就把這個(gè)服務(wù)降級(jí)掉柠并。打個(gè)比喻岭接，現(xiàn)在的APP都講究千人千面富拗，拿到數(shù)據(jù)后，做個(gè)性化排序展示鸣戴，如果在大流量下啃沪，這個(gè)排序就可以降級(jí)掉！
限流：大家都知道葵擎，北京地鐵早高峰，地鐵站都會(huì)做一件事情半哟，就是限流了酬滤！想法很直接，就是想在一定時(shí)間內(nèi)把請(qǐng)求限制在一定范圍內(nèi)寓涨，保證系統(tǒng)不被沖垮盯串，同時(shí)盡可能提升系統(tǒng)的吞吐量。
注意到戒良，有些時(shí)候体捏，緩存和降級(jí)是解決不了問(wèn)題的，比如糯崎，電商的雙十一几缭，用戶的購(gòu)買(mǎi)，下單等行為沃呢，是涉及到大量寫(xiě)操作年栓，而且是核心鏈路，無(wú)法降級(jí)的薄霜，這個(gè)時(shí)候某抓，限流就比較重要了。
那么接下來(lái)惰瓜，我們重點(diǎn)說(shuō)一下否副，限流。
限流的常用方式
限流的常用處理手段有：計(jì)數(shù)器崎坊、滑動(dòng)窗口备禀、漏桶、令牌奈揍。
計(jì)數(shù)器
計(jì)數(shù)器是一種比較簡(jiǎn)單的限流算法痹届，用途比較廣泛，在接口層面打月，很多地方使用這種方式限流队腐。在一段時(shí)間內(nèi)，進(jìn)行計(jì)數(shù)奏篙，與閥值進(jìn)行比較柴淘，到了時(shí)間臨界點(diǎn)迫淹，將計(jì)數(shù)器清0。
代碼實(shí)例
這里需要注意的是为严，存在一個(gè)時(shí)間臨界點(diǎn)的問(wèn)題敛熬。舉個(gè)栗子，在12:01:00到12:01:58這段時(shí)間內(nèi)沒(méi)有用戶請(qǐng)求第股，然后在12:01:59這一瞬時(shí)發(fā)出100個(gè)請(qǐng)求应民，OK，然后在12:02:00這一瞬時(shí)又發(fā)出了100個(gè)請(qǐng)求夕吻。這里你應(yīng)該能感受到诲锹，在這個(gè)臨界點(diǎn)可能會(huì)承受惡意用戶的大量請(qǐng)求，甚至超出系統(tǒng)預(yù)期的承受涉馅。
滑動(dòng)窗口
由于計(jì)數(shù)器存在臨界點(diǎn)缺陷归园，后來(lái)出現(xiàn)了滑動(dòng)窗口算法來(lái)解決。
滑動(dòng)窗口的意思是說(shuō)把固定時(shí)間片稚矿，進(jìn)行劃分庸诱，并且隨著時(shí)間的流逝，進(jìn)行移動(dòng)晤揣，這樣就巧妙的避開(kāi)了計(jì)數(shù)器的臨界點(diǎn)問(wèn)題桥爽。也就是說(shuō)這些固定數(shù)量的可以移動(dòng)的格子，將會(huì)進(jìn)行計(jì)數(shù)判斷閥值昧识，因此格子的數(shù)量影響著滑動(dòng)窗口算法的精度聚谁。
漏桶
雖然滑動(dòng)窗口有效避免了時(shí)間臨界點(diǎn)的問(wèn)題，但是依然有時(shí)間片的概念滞诺，而漏桶算法在這方面比滑動(dòng)窗口而言形导，更加先進(jìn)。
有一個(gè)固定的桶习霹，進(jìn)水的速率是不確定的朵耕，但是出水的速率是恒定的，當(dāng)水滿的時(shí)候是會(huì)溢出的淋叶。
代碼實(shí)現(xiàn)
令牌桶
注意到阎曹，漏桶的出水速度是恒定的，那么意味著如果瞬時(shí)大流量的話煞檩，將有大部分請(qǐng)求被丟棄掉（也就是所謂的溢出）处嫌。為了解決這個(gè)問(wèn)題，令牌桶進(jìn)行了算法改進(jìn)斟湃。
生成令牌的速度是恒定的熏迹，而請(qǐng)求去拿令牌是沒(méi)有速度限制的。這意味凝赛，面對(duì)瞬時(shí)大流量注暗，該算法可以在短時(shí)間內(nèi)請(qǐng)求拿到大量令牌坛缕，而且拿令牌的過(guò)程并不是消耗很大的事情。（有一點(diǎn)生產(chǎn)令牌捆昏，消費(fèi)令牌的意味）
不論是對(duì)于令牌桶拿不到令牌被拒絕赚楚，還是漏桶的水滿了溢出，都是為了保證大部分流量的正常使用骗卜，而犧牲掉了少部分流量宠页，這是合理的，如果因?yàn)闃O少部分流量需要保證的話寇仓，那么就可能導(dǎo)致系統(tǒng)達(dá)到極限而掛掉举户，得不償失。
代碼實(shí)現(xiàn)
限流神器：Guava RateLimiter
Guava不僅僅在集合焚刺、緩存敛摘、異步回調(diào)等方面功能強(qiáng)大（可以參考博主的《使用Google Guava快樂(lè)編程》）门烂，而且還給我們封裝好了限流的API乳愉！
Guava RateLimiter基于令牌桶算法，我們只需要告訴RateLimiter系統(tǒng)限制的QPS是多少屯远，那么RateLimiter將以這個(gè)速度往桶里面放入令牌蔓姚，然后請(qǐng)求的時(shí)候，通過(guò)tryAcquire()方法向RateLimiter獲取許可（令牌）慨丐。
代碼示例
分布式場(chǎng)景下的限流
上面所說(shuō)的限流的一些方式坡脐，都是針對(duì)單機(jī)而言的，其實(shí)大部分的場(chǎng)景房揭，單機(jī)的限流已經(jīng)足夠了备闲。分布式下限流的手段常常需要多種技術(shù)相結(jié)合，比如Nginx+Lua捅暴，Redis+Lua等去做恬砂。本文主要討論的是單機(jī)的限流，這里就不在詳細(xì)介紹分布式場(chǎng)景下的限流了蓬痒。
一句話泻骤，讓系統(tǒng)的流量，先到隊(duì)列中排隊(duì)梧奢、限流狱掂，不要讓流量直接打到系統(tǒng)上。
好了亲轨，到這里趋惨，本文就結(jié)束了！
早安惦蚊！
美好的一天開(kāi)始了希柿，上班咯诊沪！
