大話程序猿眼裏的高併發（上）

大話程序猿眼裏的高併發（上）

2016/12/01 | 分類： 技術架構 | 0 條評論 | 標籤： 架構, 高併發

分享到： 21

原文出處： thankbabe

高併發是指在同一個時間點，有不少用戶同時的訪問URL地址，好比：淘寶的雙11，雙12，就會產生高併發,如貼吧的爆吧，就是惡意的高併發請求，也就是DDOS攻擊，再屌絲點的說法就像玩擼啊擼被ADC暴擊了同樣,那傷害你懂得(若是你看懂了，這個說法說明是正在奔向人生巔峯的屌絲。

高併發會來帶的後果

• 服務端：
  致使站點服務器/DB服務器資源被佔滿崩潰，數據的存儲和更新結果和理想的設計是不同的，好比：出現重複的數據記錄，屢次添加了用戶積分等。
• 用戶角度：
  尼瑪，這麼卡，老子來參加活動的，刷新了仍是這樣，垃圾網站，不再來了。
• 個人經歷：
  在作公司產品網站的過程當中，常常會有這樣的需求，好比什麼搞個活動專題，抽獎，簽到，搞個積分競拍等等，若是沒有考慮到高併發下的數據處理，那就Game Over了，很容易致使抽獎被多抽走，簽到會發現一個用戶有多條記錄，簽到一次得到了得到了多積分，等等，各類超出正常邏輯的現象，這就是作產品網站必須考慮的問題，由於這些都是面向大量用戶的，而不是像作ERP管理系統，OA系統那樣，只是面向員工。

下面我進行實例分析，簡單粗暴，動態分析，純屬本人我的經驗分享，若有說錯，或者有更好的建議或者意見的請留言，你們一塊兒成長。

併發下的數據處理：

經過表設計,如：記錄表添加惟一約束，數據處理邏輯使用事物防止併發下的數據錯亂問題
經過服務端鎖進程防止包併發下的數據錯亂問題

這裏主要講述的是在併發請求下的數據邏輯處理的接口,如何保證數據的一致性和完整性，這裏的併發多是大量用戶發起的，也可能攻擊者經過併發工具發起的併發請求

如例子：經過表設計防止併發致使數據錯亂

• 需求點
  【簽到功能】 一天一個用戶只能簽到一次，
  簽到成功後用戶獲取到一個積分
• 已知表
  用戶表，包含積分字段
  高併發意淫分析(屬於開發前的猜想)：
  在高併發的狀況下，會致使，一個用戶簽到記錄會有多條，或者用戶簽到後不止加一積分。
• 個人設計
  首先根據需求我會添加一張簽到記錄表，重點來了，這張表須要把用戶惟一標識字段(ID,Token)和簽到日期字段添加爲惟一約束，或者惟一索引，這樣就能夠防止併發的時候插入重複用戶的簽到記錄。而後再程序代碼邏輯裏，先執行簽到數據的添加(這裏能夠防止併發，添加成功後再進行積分的添加，這樣就能夠防止重複的添加積分了。最後我仍是建議全部的數據操做都寫在一個sql事務裏面， 這樣在添加失敗，或者編輯用戶積分失敗的時候能夠回滾數據。

如例子2（事務+經過更新鎖 防止併發致使數據錯亂 或者事物+Update的鎖表機制）

• 需求點：
  【抽獎功能】 抽獎一次消耗一個積分 抽獎中獎後編輯剩餘獎品總數 剩餘獎品總數爲0，或者用戶積分爲0的時候沒法進行抽獎
• 已知表:
  用戶表，包含積分字段 獎品表，包含獎品剩餘數量字段
• 高併發意淫分析(屬於開發前的猜想):
  在高併發的狀況下，會致使用戶參與抽獎的時候積分被扣除，而獎品實際上已經被抽完了
• 個人設計:
  在事物裏，經過WITH (UPDLOCK) 鎖住商品表，或者Update 表的獎品剩餘數量和最後編輯時間字段，來把數據行鎖住，而後進行用戶積分的消耗，都完成後提交事物，失敗就回滾。 這樣就能夠保證，只有可能存在一個操做在操做這件商品的數量，只有等到這個操做事物提交後，其餘的操做這個商品行的事物纔會繼續執行。

如例子3（經過程序代碼防止包併發下的數據錯亂問題）

• 需求點：
  【緩存數據到cache裏】， 當緩存不存在的時候，從數據庫中獲取並保存在cache裏，若是存在從cache裏獲取，天天10點必須更新一次，其餘時間點緩存兩個小時更新一次 到10點的時候，凡是打開頁面的用戶會自動刷新頁面
• 問題點：
  這裏有個邏輯用戶觸發緩存的更新，用戶刷新頁面，當緩存存在的時候，會取到最後一次緩存更新時間，若是當前時間大於十點，而且最後緩存時間是10點前，則會從數據庫中從新獲取數據保存到cache中。 還有客戶端頁面會在10點時候用js發起頁面的刷新，就是由於有這樣的邏輯，致使10點的時候有不少併發請求同時過來，而後就會致使不少的sql查詢操做，理想的邏輯是，只有一個請求會去數據庫獲取，其餘都是從緩存中獲取數據。(由於這個sql查詢很耗服務器性能，因此致使在10點的時候，忽然間數據庫服務器壓力暴增)
• 解決問題：
  C#經過 （鎖）lock，在從數據讀取到緩存的那段代碼前面加上鎖，這樣在併發的狀況下只會有一個請求是從數據庫裏獲取數據，其餘都是從緩存中獲取。

訪問量大的數據統計接口

• 需求： 用戶行爲數據統計接口，用來記錄商品展現次數，用戶經過點擊圖片，或者連接，或者其餘方式進入到商品詳情的行爲次數
• 問題點：
  這接口是給前端ajax使用，訪問量會很大，一頁面展現的時候就會有幾十件商品的展現，滾動條滾到到頁面顯示商品的時候就會請求接口進行展現數據的統計，每次翻頁又會加載幾十件
• 意淫分析：
  設想若是同時有1W個用戶同時在線訪問頁面，一個次拉動滾動條屏幕頁面展現10件商品，這樣就會有10W個請求過來，服務端須要把請求數據入庫。在實際線上環境可能還會超過這個請求量，若是不通過進行高併發設計處理，服務器分分鐘給跪了。
• 解決問題：
  咱們經過nodejs寫了一個數據處理接口，把統計數據先存到redis的list裏。(使用nodejs寫接口的好處是，nodejs使用單線程異步事件機制，高併發處理能力強，不會由於數據邏輯處理問題致使服務器資源被佔用而致使服務器宕機) 而後再使用nodejs寫了一個腳本，腳本功能就是從redis裏出列數據保存到mysql數據庫中。這個腳本會一直運行，當redis沒有數據須要同步到數據庫中的時候，sleep，讓在進行數據同步操做

高併發的下的服務器壓力均衡，合理站點架設，DB部署

如下我所知道的：

1. 服務器代理nginx，作服務器的均衡負載，把壓力均衡到多臺服務器
2. 部署集羣 mysql數據庫， redis服務器，或者mongodb服務器，把一些經常使用的查詢數據，而且不會常常的變化的數據保存到其餘NoSQL DB服務器中，來減小數據庫服務器的壓力，加快數據的響應速度。
3. 數據緩存，Cache
4. 在高併發接口的設計中可使用具備高併發能力的編程語言去開發，如：nodejs 作web接口
5. 服務器部署，圖片服務器分離，靜態文件走CDN
6. DBA數據庫的優化查詢條件，索引優化
7. 消息存儲機制，將數據添加到信息隊列中(redis list)，而後再寫工具去入庫
8. 腳本合理控制請求，如，防止用戶重複點擊致使的ajax多餘的請求，等等。

併發測試神器推薦

1. Apache JMeter
2. Microsoft Web Application Stress Tool
3. Visual Studio 性能負載