大流量和高并發(fā)的常規(guī)應(yīng)對(duì)手段

擴(kuò)容、動(dòng)靜分離、緩存、服務(wù)降級(jí)和限流。

限流的常用算法和實(shí)踐思路

1. 目前主流的算法主要有三種：令牌桶算法、漏桶算法和計(jì)數(shù)器算法。
2. 令牌桶算法：主要限制流量的流入速率，允許出現(xiàn)一定程度的突發(fā)流量。Nginx的限流模塊就是使用的這種算法實(shí)現(xiàn)的。
   
   • 每秒會(huì)有r個(gè)令牌按照固定速率放入桶中。
   • 桶的容量是固定不變的，如果桶滿了再放入令牌，則溢出。
   • 若桶中的可用令牌不足，則改請(qǐng)求會(huì)被進(jìn)行限流處理（被拋棄或緩存）。
3. 漏桶算法：主要限制流量的流出速率，并且流出速率是固定不變的
   
   • 可以以任意速率向桶中流入水滴。
   • 桶的容量是固定不變的，如果桶滿了則溢出。
   • 按照固定的速率從桶中流出水滴。
4. Google的Guava也實(shí)現(xiàn)了基于令牌桶算法那樣的平均速率限流，RateLimiter抽象類。
5. Nginx可以使用限流模塊在接入層實(shí)現(xiàn)令桶牌算法限流，
   
   • limit_zone 定義每個(gè)IP的session空間大小。
   • limit_zeq_zone定義每個(gè)IP每秒允許發(fā)起的請(qǐng)求數(shù)。
   • limit_conn 定義每個(gè)IP能夠發(fā)起的并發(fā)連接數(shù)。
   • limit_req 等待處理的請(qǐng)求隊(duì)列數(shù)量。
6. 生產(chǎn)環(huán)境中的商品搶購(gòu)可以使用計(jì)數(shù)器算法，具體不同的sku限流規(guī)則配置在配置中心內(nèi)，支持動(dòng)態(tài)更改�？蓳屬�(gòu)次數(shù)的扣減操作，既可以用redis，也可以用JVM。如果是集群并且選擇用JVM，則要根據(jù)總并發(fā)數(shù)量除以集群數(shù)量，得出單臺(tái)機(jī)器的并發(fā)數(shù)。（比如總并發(fā)數(shù)5000，集群機(jī)器10臺(tái)，則每臺(tái)機(jī)器的并發(fā)為5000/10=500）。

搶購(gòu)商品高并發(fā)讀需求

對(duì)于一件搶購(gòu)商品的流量來(lái)說(shuō)，因?yàn)閗ey是同一個(gè)，所以流量必然會(huì)都引入到同一個(gè)redis緩存節(jié)點(diǎn)中，這時(shí)就容易出現(xiàn)單點(diǎn)故障。因此有下面兩種解決方式：
1. 在每個(gè)master節(jié)點(diǎn)都掛slave從節(jié)點(diǎn)，當(dāng)主節(jié)點(diǎn)掛了可以自動(dòng)頂上。
2. 多級(jí)Cache方案，多用LocalCache來(lái)過(guò)濾掉一部分流量。
- 本地緩存一般只緩存一些熱點(diǎn)商品數(shù)據(jù)，緩存內(nèi)容一般是商品詳情和商品庫(kù)存。
- 本地緩存跟分布式緩存的同步一般有兩種方式：一種是定時(shí)主動(dòng)拉取更新策略。這種會(huì)存在一定時(shí)間的不一致，要視業(yè)務(wù)情況而定，例如庫(kù)存，暫時(shí)的不一致導(dǎo)致超賣，單到真正下單的時(shí)候還會(huì)再進(jìn)行庫(kù)存的判斷，所以影響較小，可以接受。這種方式要注意關(guān)掉緩存的定時(shí)失效，防止當(dāng)用戶流量突然過(guò)大，都到分布式緩存中拉取數(shù)據(jù)；第二種方式是每次商品更新，都發(fā)布一個(gè)消息，訂閱此消息的節(jié)點(diǎn)監(jiān)聽到后再更新本地緩存的內(nèi)容。

實(shí)時(shí)熱點(diǎn)自動(dòng)發(fā)現(xiàn)方案

可以將交易系統(tǒng)產(chǎn)生的相關(guān)數(shù)據(jù)，以及在上游系統(tǒng)中埋點(diǎn)上報(bào)的相關(guān)數(shù)據(jù)異步寫入日志系統(tǒng)中，然后通過(guò)實(shí)時(shí)熱點(diǎn)自動(dòng)發(fā)現(xiàn)平臺(tái)對(duì)收集到的日志數(shù)據(jù)做調(diào)用次數(shù)統(tǒng)計(jì)和熱點(diǎn)分析。數(shù)據(jù)符合熱點(diǎn)條件后，就立即通知交易系統(tǒng)做好熱點(diǎn)保護(hù)。

redis使用watch命令實(shí)現(xiàn)高并發(fā)搶購(gòu)需求

1. 一般高并發(fā)這里，不用悲觀鎖，會(huì)迅速增加系統(tǒng)資源；而使用隊(duì)列，容易造成請(qǐng)求堆積，內(nèi)存效果過(guò)快。所以一般使用樂(lè)觀鎖，可以用redis的watch命令實(shí)現(xiàn)。
2. watch命令會(huì)監(jiān)視給定的key，當(dāng)exec時(shí)，如果監(jiān)視的key從調(diào)用watch后發(fā)生過(guò)變化，則事務(wù)會(huì)失敗。注意watch的可以是對(duì)整個(gè)連接有效的，事務(wù)也一樣。如果連接斷開，監(jiān)視和事務(wù)都會(huì)被自動(dòng)清除。當(dāng)然exec，discard，unwatch命令都會(huì)清除連接中的所有監(jiān)視。

緩存雪崩，緩存穿透，緩存并發(fā)，緩存預(yù)熱，緩存算法

1. 緩存雪崩：可能是因?yàn)閿?shù)據(jù)未加載到緩存中，或者緩存同一時(shí)間大面積的失效，從而導(dǎo)致所有請(qǐng)求都去查數(shù)據(jù)庫(kù)，導(dǎo)致數(shù)據(jù)庫(kù)CPU和內(nèi)存負(fù)載過(guò)高，甚至宕機(jī)。解決思路：
   
   • 加鎖計(jì)數(shù)（即限制并發(fā)的數(shù)量，可以用semphore）或者起一定數(shù)量的隊(duì)列來(lái)避免緩存失效時(shí)大量請(qǐng)求并發(fā)到數(shù)據(jù)庫(kù)。但這種方式會(huì)降低吞吐量。
   • 分析用戶行為，然后失效時(shí)間均勻分布�；蛘咴谑�效時(shí)間的基礎(chǔ)上再加1~5分鐘的隨機(jī)數(shù)。
   • 如果是某臺(tái)緩存服務(wù)器宕機(jī)，則考慮做主備。
2. 緩存穿透：指用戶查詢數(shù)據(jù)，在數(shù)據(jù)庫(kù)沒(méi)有，自然在緩存中也不會(huì)有。這樣就導(dǎo)致用戶查詢的時(shí)候，在緩存中找不到，每次都要去數(shù)據(jù)庫(kù)中查詢。解決思路：
   
   • 如果查詢數(shù)據(jù)庫(kù)也為空，直接設(shè)置一個(gè)默認(rèn)值存放到緩存，這樣第二次到緩沖中獲取就有值了，而不會(huì)繼續(xù)訪問(wèn)數(shù)據(jù)庫(kù)。設(shè)置一個(gè)過(guò)期時(shí)間或者當(dāng)有值的時(shí)候?qū)⒕彺嬷械闹堤鎿Q掉即可。
   • 可以給key設(shè)置一些格式規(guī)則，然后查詢之前先過(guò)濾掉不符合規(guī)則的Key。
3. 緩存并發(fā)：如果網(wǎng)站并發(fā)訪問(wèn)高，一個(gè)緩存如果失效，可能出現(xiàn)多個(gè)進(jìn)程同時(shí)查詢DB，同時(shí)設(shè)置緩存的情況，如果并發(fā)確實(shí)很大，這也可能造成DB壓力過(guò)大，還有緩存頻繁更新的問(wèn)題。解決思路：
   
   • 對(duì)緩存查詢加鎖，如果KEY不存在，就加鎖，然后查DB入緩存，然后解鎖；其他進(jìn)程如果發(fā)現(xiàn)有鎖就等待，然后等解鎖后返回?cái)?shù)據(jù)或者進(jìn)入DB查詢。
4. 緩存預(yù)熱：目的就是在系統(tǒng)上線前，將數(shù)據(jù)加載到緩存中。解決思路：
   
   • 數(shù)據(jù)量不大的話，在系統(tǒng)啟動(dòng)的時(shí)候直接加載。
   • 自己寫個(gè)簡(jiǎn)單的緩存預(yù)熱程序。
5. 緩存算法：
   
   • FIFO算法：First in First out，先進(jìn)先出。原則：一個(gè)數(shù)據(jù)最先進(jìn)入緩存中，則應(yīng)該最早淘汰掉。也就是說(shuō)，當(dāng)緩存滿的時(shí)候，應(yīng)當(dāng)把最先進(jìn)入緩存的數(shù)據(jù)給淘汰掉。
   • LFU算法：Least Frequently Used，最不經(jīng)常使用算法。
   • LRU算法：Least Recently Used，近期最少使用算法。
   • LRU和LFU的區(qū)別。LFU算法是根據(jù)在一段時(shí)間里數(shù)據(jù)項(xiàng)被使用的次數(shù)選擇出最少使用的數(shù)據(jù)項(xiàng)，即根據(jù)使用次數(shù)的差異來(lái)決定。而LRU是根據(jù)使用時(shí)間的差異來(lái)決定的。

協(xié)程（纖程）Fiber

1. 協(xié)程概念：一種用戶態(tài)的輕量級(jí)線程，其實(shí)就是單線程，指定執(zhí)行整個(gè)函數(shù)中到一部分然后就先出去執(zhí)行別的，等條件滿足時(shí)，協(xié)程下次更新幀到了再繼續(xù)往下執(zhí)行。優(yōu)點(diǎn)是無(wú)需線程上下文切換的開銷，充分開發(fā)了單CPU的能力，資源占用低，適合高并發(fā)I/O。缺點(diǎn)也很明顯，就是沒(méi)辦法利用多CPU的優(yōu)勢(shì)。
2. 框架：Quasar，調(diào)度器使用ForkJoinPool來(lái)調(diào)度這些fiber。Fiber調(diào)度器FiberScheduler是一個(gè)高效的、work-stealing、多線程的調(diào)度器。
3. 場(chǎng)景：服務(wù)A平時(shí)需要調(diào)用其他服務(wù)，但其他服務(wù)在并發(fā)高的時(shí)候延遲很嚴(yán)重。
   
   • 一開始可以用httpClient連接池+線程池來(lái)處理，但如果調(diào)用服務(wù)的時(shí)候延遲太高或者超時(shí)，則會(huì)導(dǎo)致服務(wù)A的吞吐量會(huì)特別差。原因主要是一般一個(gè)鏈接由一個(gè)線程來(lái)處理，是阻塞的，所以在線程池?cái)?shù)有限的情況下，吞吐量肯定上不去。并且當(dāng)所有線程都I/O阻塞的時(shí)候，會(huì)很浪費(fèi)CPU資源，并且CPU會(huì)一直做無(wú)用的上下文切換。
   • 這時(shí)候可以考慮協(xié)程來(lái)替換。

ForkJoinPool線程池

1. Fork/Join框架是Java7提供了的一個(gè)用于并行執(zhí)行任務(wù)的框架，是一個(gè)把大任務(wù)分割成若干個(gè)小任務(wù)，最終匯總每個(gè)小任務(wù)結(jié)果后得到大任務(wù)結(jié)果的框架。
2. 工作竊�。╳ork-stealing）算法是Fork/Join框架最重要的特性。一般一個(gè)線程會(huì)對(duì)應(yīng)一個(gè)任務(wù)隊(duì)列，當(dāng)處理較快的線程處理完自己的任務(wù)之后，就會(huì)竊取另外一個(gè)處理比較慢的線程對(duì)應(yīng)的任務(wù)，這時(shí)候會(huì)存在兩個(gè)線程同時(shí)處理一個(gè)隊(duì)列的情況，所以任務(wù)隊(duì)列一般使用雙端隊(duì)列，被竊取任務(wù)線程永遠(yuǎn)從雙端隊(duì)列的頭部拿任務(wù)執(zhí)行，而竊取任務(wù)的線程永遠(yuǎn)從雙端隊(duì)列的尾部拿任務(wù)執(zhí)行。優(yōu)點(diǎn)是充分利用線程進(jìn)行并行計(jì)算，并減少了線程間的競(jìng)爭(zhēng)。

天下數(shù)據(jù)在全球超過(guò)120個(gè)國(guó)家部署數(shù)據(jù)中心,提供海外全球多個(gè)國(guó)家服務(wù)器租用,所有服務(wù)器均可根據(jù)需求配置大帶寬大流量,美國(guó)G口獨(dú)享大帶寬服務(wù)器,從此告別網(wǎng)絡(luò)擁堵;

本文鏈接：http://m.51huadong.com/cloundnews/11002286.html