電商的秒殺和搶購，對我們來說，都不是一個陌生的東西。然而，從技術的角度來說，這對於系統是一個巨大的考驗。當一個網站系統，在一秒鐘內收到數以萬計甚至更多請求時，系統的優化和穩定至關重要，這就造成了系統的高併發。
1.關於高併發
高併發是指在同一個時間點，有很多用戶同時訪問URL地址，比如：淘寶、京東等商城的雙11，就會產生高併發。
高併發情景
那麼，高併發會帶來什麼後果呢？
服務端：導致站點服務器/DB服務器資源被佔滿崩潰，數據的存儲和更新結果和理想的設計是不一樣的，比如：出現重複的數據記錄，用戶抽獎提交了多次等；
用戶角度：購買商品操作卡頓、無響應，用戶體驗非常差。
2.併發下的數據處理
數據庫的連接池的參數設置的合理性，直接影響到應用實例和數據庫交互。設置過小會造成連接不可用，設置過大浪費太多的資源，因此數據庫連接池參數的重要性是不可忽視的。
通過表設計，如：記錄表添加唯一約束，數據處理邏輯使用事物防止併發下的數據錯亂問題。通過服務端鎖進程防止包併發下的數據錯亂問題。這裡主要講述的是在併發請求下的數據邏輯處理的接口，如何保證數據的一致性和完整性，這裡的併發可能是大量用戶發起的，也可能攻擊者通過併發工具發起的併發請求。
比如：事務+通過更新鎖，防止併發導致數據錯亂；或者事物+Update的鎖表機制
需求點：【抽獎功能】抽獎一次消耗一個積分，抽獎中獎後編輯剩餘獎品總數，剩餘獎品總數為0，或者用戶積分為0的時候無法進行抽獎。
已知表：用戶表，包含積分字段 獎品表，包含獎品剩餘數量字段。
高併發意淫分析(屬於開發前的猜測)：在高併發的情況下，會導致用戶參與抽獎的時候積分被扣除，而獎品實際上已經被抽完了。
我的設計：在事物裡，通過WITH(UPDLOCK)鎖住商品表，或者Update 表的獎品剩餘數量和最後編輯時間字段，來把數據行鎖住，然後進行用戶積分的消耗，都完成後提交事物，失敗就回滾。 這樣就可以保證，只有可能存在一個操作在操作這件商品的數量，只有等到這個操作事物提交後，其他的操作這個商品行的事物才會繼續執行。還可以調整超時時間：比如數據庫url超時配置(單位ms)、batis配置超時時間(單位s)和spring配置事務的超時時間(單位s)。
3.訪問量大的數據統計接口
需求： 用戶行為數據統計接口，用來記錄商品展示次數，用戶通過點擊圖片，或者鏈接，或者其他方式進入到商品詳情的行為次數。
問題點：這接口是給前端ajax使用，訪問量會很大，一頁面展示的時候就會有幾十件商品的展示，滾動條滾到到頁面顯示商品的時候就會請求接口進行展示數據的統計，每次翻頁又會加載幾十件。
解決問題：我們通過nodejs寫了一個數據處理接口，把統計數據先存到redis的list裡。(使用nodejs寫接口的好處是，nodejs使用單線程異步事件機制，高併發處理能力強，不會因為數據邏輯處理問題導致服務器資源被佔用而導致服務器宕機) 然後再使用nodejs寫了一個腳本，腳本功能就是從redis裡出列數據保存到mysql數據庫中。這個腳本會一直運行，當redis沒有數據需要同步到數據庫中的時候，sleep，讓在進行數據同步操作。
4.併發測試神器推薦
Apache JMeter
Microsoft Web Application Stress Tool
Visual Studio 性能負載
5.架構優化
對於業務系統而言，每次的大促都是一個鬥智鬥勇、架構迭代升級的過程。下面我們來看下如何保證服務的持續可用。
應用層，基於RPC框架發佈服務，多機房部署，異地多活，全局動態分配流量。當服務故障時，可按機房或應用或接口實現自動切換。
存儲層，對於金融產品而言，數據庫作為交易數據落地的介質，屬於整個鏈路強依賴的部分，不容有失。白條的數據庫模型採用DB+的模式，即mysql+分佈式+nosql。數據散列分佈在多庫多表，且多個集群防災互備。熱點數據異步複製到nosql，對於618、雙十一大促期間，性能的消耗主要來源於驟增的查詢量，可適情況將高併發的查詢量轉移到nosql，保證交易數據正常落地。
業務從發展的初期到逐漸成熟，服務器架構也是從相對單一到集群，再到分佈式服務。
一個可以支持高併發的服務少不了好的服務器架構，需要有均衡負載，數據庫需要主從集群，NoSQL緩存需要主從集群，靜態文件需要上傳CDN，這些都是能讓業務程序流暢運行的強大後盾。
高併發相關的業務，需要進行併發的測試，通過大量的數據分析評估出整個架構可以支撐的併發量。
測試高併發可以使用第三方服務器或者自己測試服務器，利用測試工具進行併發請求測試，分析測試數據得到可以支撐併發數量的評估。
6.一級緩存
一級緩存就是使用站點服務器緩存去存儲數據，注意只存儲部分請求量大的數據，並且緩存的數據量要控制，不能過分的使用站點服務器的內存而影響了站點應用程序的正常運行，一級緩存需要設置秒單位的過期時間，具體時間根據業務場景設定，目的是當有高併發請求的時候可以讓數據的獲取命中到一級緩存，而不用連接緩存NoSQL數據服務器，減少NoSQL數據服務器的壓力。
7.切換演練
為了保證服務的穩定性，切換演練是每年大促前必做的一件事情，切換演練具體包括許多方面，如數據庫、VIP、JMQ、接口降級等。
降級開關演練
為了保證大促，針對系統接口的劃分也是不一樣的：一些0級系統不能降級，而一些展示類、流量類入口是可以降級的。當流量異常爆發時，通過開關的降級，保證最核心的業務不受到影響。
隨著用戶體量的不斷攀升，流量峰值的翻倍增長，以及人事的變動，相對於技術保障和架構優化，一套完善的高併發備戰機制甚至更加重要。我們要時刻走在技術的前沿，為自己的電商系統呵護揚帆。我們還要必須保障系統穩定，理論上你只要定義容量和流量就可以。但實際遠遠不行，為什麼？有技術的因素，有人為的因素，因為不同的開發定義的流量和容量指標有主觀性，很難全局量化標準，所以真正流量來了以後，你預先評估的系統瓶頸往往不正確。以下是我們經過實踐後基本總結出來一套備戰機制：
1.最簡單的就是有降 級 的 預 案，流量超過系統容量後，先把哪些功能砍掉，需要有明確的優先級；
2. 線上全鏈路壓測，就是把現在的流量放大到我們平常流量的五倍甚至十倍（比如下線一半的服務器，縮容而不是擴容），看看系統瓶頸最先發生在哪裡。我們之前有一些例子，推測系統數據庫會先出現瓶頸，但是實測發現是前端的程序先遇到瓶頸；
3.需要各個業務線按照各自的業務特點做不同的策略，例如公網可能考慮更多的是流量緯度的限流，而API服務更多是做用戶緯度的規則處置；
4.業務應用、數據庫存儲、服務器等多方面監控，及時發現解決問題；
5.搭建在線 Docker 集群 ， 所有業務共享備用的 Docker集群資源，這樣可以極大的避免每個業務都預留資源的。
閱讀更多 中傑科技 的文章
