如何優(yōu)化商城高并發(fā)服務？對于線上服務會有哪些挑戰(zhàn)？

①無法做離線緩存，所有數(shù)據(jù)都是實時讀取。

②會有大量的請求發(fā)送給在線服務，對服務的響應時間要求較高，一般限制在300ms以內(nèi)。如果超過這個時間，用戶體驗會急劇下降。

③數(shù)據(jù)量大。如果單次qps超過50W，單條1kb,50萬就是5GB了,1分鐘30G，對底層數(shù)據(jù)存儲和訪問壓力很大。本文將討論如何處理這些棘手的問題。

真正大規(guī)模的面向互聯(lián)網(wǎng)C端的服務，是不會直接把數(shù)據(jù)庫作為自己的存儲系統(tǒng)的。無論是使用底層的子數(shù)據(jù)庫和子表，還是各種優(yōu)秀的連接池，mysql/oracle面對大規(guī)模的在線服務都有著天然的劣勢。再怎么優(yōu)化，也難以抵擋qps超過50萬流量的沖擊。所以換個思路，我們必須使用類似nosql的緩存系統(tǒng)，比如redis/mermCache，作為自己的“數(shù)據(jù)庫”，而mysql等關(guān)系型數(shù)據(jù)庫只是異步編寫數(shù)據(jù)查詢的備份系統(tǒng)。

就比如在雙11主會場JD.COM，一些商品被擺上貨架。這些商品在會場上架時直接寫入redis，上架后再通過異步消息寫入mysql。c端查詢總是直接讀取redis，而不是數(shù)據(jù)庫，而B端查詢可以去數(shù)據(jù)庫。這部分流量不是很高，數(shù)據(jù)庫肯定能承受。

最近大家都知道CRMEB PRO商城是專門為高并發(fā)打造的，那么大家也都知道緩存是提高高并發(fā)性能的利器之一。那么如何在CRMEB PRO商城系統(tǒng)上利用好緩存，怎么在CRMEB PRO商城系統(tǒng)上面利用多級緩存，是我們需要思考的問題。Redis是目前緩存的首選。單機可以達到6-8萬qps。面對高并發(fā)，我們可以手動橫向擴展容量，滿足qps可能無線增長的場景。但是這種方式也有缺點，因為redis是單線程的，會有熱點問題。雖然redis內(nèi)部使用crc16算法哈希，但是同樣的密鑰還是會落在單獨的機器上，增加機器的負載。redis典型的有兩個問題:緩存擊穿和緩存穿透，尤其是在秒殺場景下，如果想要解決熱點問題，會變得更加困難。這時候就必須考慮多級緩存了。在典型的峰值場景中，單個sku商品的qps將在銷售開始的那一刻急劇上升。而我們這個時候需要用memeryCache來阻擋一層。memeryCache是多線程的，并發(fā)性比redis好，自然能解決熱點問題。有了memeryCache，我們還需要localCache，這是一種用內(nèi)存換取速度的方式。本地緩存將訪問用戶的一級請求。如果它找不到，就去memeryCache，然后redis。這個過程可以阻止數(shù)百萬個qps。

多線程有這么厲害嗎?干嘛都說多線程,為什么CRMEB PRO商城系統(tǒng)要使用多線程,不用行不行?要講明這個道理,我先來說一個實例.很典型的一個場景。原始的方式是循環(huán)一個30-40萬的list,list執(zhí)行的操作很簡單,就是讀redis中的數(shù)據(jù),讀一次數(shù)據(jù)一般需要3ms左右,這是同步的方式，在預覽環(huán)境測試,是30秒+超時。我們優(yōu)化的方式就是把同步調(diào)用改為線程池調(diào)用,線程池里的線程數(shù)或阻塞隊列大小需要自己調(diào)優(yōu),最后實測接口rt只需要3秒。足以見多線程的強大。在多核服務的今天,如果還不使用多線程那就是對服務器資源浪費。這里需要說一句,使用多線層一定要做好監(jiān)控,你需要隨時知道線程的狀態(tài),如果線程數(shù)和queueSize設置的不恰當,將會嚴重影響業(yè)務，當然多線程也要分場景的,如果為了多線程而多線程反而更是一種資源浪費,因為多線程調(diào)度的時候會造成線程在內(nèi)核態(tài)和用戶態(tài)之間來回切換,如果使用不當反而會有反作用

降級熔斷是一種自我保護措施，這和電路上熔斷的基本原理是一樣的。可以防止電流過大引起火災等。面對不可控的巨大流量請求，很可能會破壞服務器的數(shù)據(jù)庫或redis，導致服務器宕機或癱瘓，造成無法挽回的損失。因為我們的服務本身需要有一個防御機制來抵御外部服務對自身的入侵，造成服務的破壞和聯(lián)合反應。降級不同于熔斷。兩者的區(qū)別在于降級是在不影響主鏈接的情況下，關(guān)閉一些網(wǎng)上主鏈接的功能。如果熔斷，意味著A請求B，B檢測到業(yè)務流量有多大，開始熔斷，那么請求會直接進入熔斷池，直接返回失敗。如何選擇使用哪一種，需要在實踐中結(jié)合業(yè)務場景來考慮。

很多人都會忽視IO這個問題,頻繁的建聯(lián)和斷聯(lián)都是對系統(tǒng)的重負。在并發(fā)請求中,如果存在單個請求的放大效那么將會使io呈指數(shù)倍增加。比如主會場的商品信息,如果需要商品的某個具體的詳情,而這個詳情需要調(diào)用下游來單個獲取.隨著主會場商品的熱賣,商品越來越多,一次就要經(jīng)過商品數(shù)X下游請求的數(shù)量,在海量的qps請求下,IO數(shù)被占據(jù),大量的請求被阻塞,接口的響應速度就會呈指數(shù)級下降。所以需要批量的請求接口,所有的優(yōu)化為一次IO

重試是處理臨時異常的常用方法。常見的處理方法是請求服務失敗或?qū)懭霐?shù)據(jù)庫并重試。使用重試時，必須注意以下幾點:①控制重試次數(shù)；②測量重試間隔；③是否重試做到配置化。之前我們線路上有個bug。kafka的消費有嚴重的滯后性，一個詞的消耗時間在10秒以上。看了代碼后發(fā)現(xiàn)是重試次數(shù)太多導致的，次數(shù)多不支持配置修改，所以當時的做法只能是臨時改代碼再上線。重試作為一個業(yè)務的第二次嘗試，大大提高了程序的請求成功，但也要注意以上幾點。

作為互聯(lián)網(wǎng)老手，很多人寫出了不錯的代碼，但是經(jīng)過幾輪故障審查，發(fā)現(xiàn)很多造成重大事故的代碼背后都是對一些邊界問題的處理不足。他們犯的錯誤非常簡單，但往往是這些小問題導致了重大事故。一次重大事故回顧，后來發(fā)現(xiàn)最終原因是沒有判斷空數(shù)組，導致傳入的下游rpc為空，下游直接返回了全量業(yè)務數(shù)據(jù)，影響了上百萬用戶。這段代碼修改起來很簡單，但是需要自省，小的不足導致大的災難。

作為跟蹤在線問題的最佳工具，日志是保留bug場景的唯一來源。雖然有arthas這樣的工具幫助我們排查問題，但是對于一些復雜的場景，還是需要日志來記錄程序的數(shù)據(jù)。但在高流量場景下，如果打印全部日志對于online來說是一場災難，有以下幾個缺點:①磁盤占用嚴重。據(jù)估計，如果接口的qps在200000左右，則日志將為每秒幾千兆字節(jié)，一天就有幾千GB。②需要輸出大量日志。占用了程序IO，增加了接口的RT(響應時間)。如果需要解決這個問題，①可以利用限流元件實現(xiàn)一個基于限流的對數(shù)元件。令牌桶算法可以限制打印日志的流量，比如一秒鐘只能打印一個日志。②基于白名單的日志打印只有在線白名單用戶才能打印，節(jié)省了大量無效日志輸出。

總結(jié):

本文討論了CRMEB PRO商城系統(tǒng)高并發(fā)服務在面對大流量時的一些技術(shù)手段和應對要點。當然，實際的在線服務要比現(xiàn)在的復雜。這里只是一些建議。希望能保持敬畏之心，在高并發(fā)的道路上繼續(xù)探索。更好的培養(yǎng)C端服務，做出更好的互聯(lián)網(wǎng)商城應用。