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

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

限流的常用算法和實踐思路

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

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

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

實時熱點自動發(fā)現(xiàn)方案

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

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

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

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

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

協(xié)程（纖程）Fiber

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

ForkJoinPool線程池

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

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

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