如何優化商城高并發服務？對于線上服務會有哪些挑戰？

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

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

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

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

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

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

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

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

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

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

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

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

總結:

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