大話程序猿眼裏的高並發（上）
大話程序猿眼裏的高並發（上）
高並發是指在同一個時間點，有很多用戶同時的訪問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部署
以下我所知道的：
-
服務器代理nginx，做服務器的均衡負載，把壓力均衡到多臺服務器
-
部署集群 mysql數據庫， redis服務器，或者mongodb服務器，把一些常用的查詢數據，並且不會經常的變化的數據保存到其他NoSQL DB服務器中，來減少數據庫服務器的壓力，加快數據的響應速度。
-
數據緩存，Cache
-
在高並發接口的設計中可以使用具有高並發能力的編程語言去開發，如：nodejs 做web接口
-
服務器部署，圖片服務器分離，靜態文件走CDN
-
DBA數據庫的優化查詢條件，索引優化
-
消息存儲機制，將數據添加到信息隊列中(redis list)，然後再寫工具去入庫
-
腳本合理控制請求，如，防止用戶重復點擊導致的ajax多余的請求，等等。
並發測試神器推薦
-
Apache JMeter
-
Microsoft Web Application Stress Tool
-
Visual Studio 性能負載
大話程序猿眼裏的高並發（上）