高并發(fā)是指在同一個時間點，有很多用戶同時的訪問URL地址，比如：淘寶的雙11，雙12，就會產生高并發(fā),如貼吧的爆吧，就是惡意的高并發(fā)請求，也就是DDOS攻擊，再屌絲點的說法就像玩擼啊擼被ADC暴擊了一樣,那傷害你懂得(如果你看懂了，這個說法說明是正在奔向人生巔峰的屌絲。
高并發(fā)會來帶的后果
服務端：導致站點服務器/DB服務器資源被占滿崩潰，數據的存儲和更新結果和理想的設計是不一樣的，比如：出現(xiàn)重復的數據記錄，多次添加了用戶積分等。
用戶角度：尼瑪，這么卡，老子來參加活動的，刷新了還是這樣，垃圾網站，再也不來了。
我的經歷：在做公司產品網站的過程中，經常會有這樣的需求，比如什么搞個活動專題，抽獎，簽到，搞個積分競拍等等，如果沒有考慮到高并發(fā)下的數據處理，那就Game Over了，很容易導致抽獎被多抽走，簽到會發(fā)現(xiàn)一個用戶有多條記錄，簽到一次獲得了獲得了多積分，等等，各種超出正常邏輯的現(xiàn)象，這就是做產品網站必須考慮的問題，因為這些都是面向大量用戶的，而不是像做ERP管理系統(tǒng)，OA系統(tǒng)那樣，只是面向員工。
下面我進行實例分析，簡單粗暴，動態(tài)分析，純屬本人個人經驗分享，如有說錯，或者有更好的建議或者意見的請留言，大家一起成長。
并發(fā)下的數據處理：
通過表設計,如：記錄表添加唯一約束，數據處理邏輯使用事物防止并發(fā)下的數據錯亂問題通過服務端鎖進程防止包并發(fā)下的數據錯亂問題
這里主要講述的是在并發(fā)請求下的數據邏輯處理的接口,如何保證數據的一致性和完整性，這里的并發(fā)可能是大量用戶發(fā)起的，也可能攻擊者通過并發(fā)工具發(fā)起的并發(fā)請求
如例子：通過表設計防止并發(fā)導致數據錯亂
需求點【簽到功能】 一天一個用戶只能簽到一次，簽到成功后用戶獲取到一個積分
已知表用戶表，包含積分字段高并發(fā)意淫分析(屬于開發(fā)前的猜測)：在高并發(fā)的情況下，會導致，一個用戶簽到記錄會有多條，或者用戶簽到后不止加一積分。
我的設計首先根據需求我會添加一張簽到記錄表，重點來了，這張表需要把用戶唯一標識字段(ID,Token)和簽到日期字段添加為唯一約束，或者唯一索引，這樣就可以防止并發(fā)的時候插入重復用戶的簽到記錄。然后再程序代碼邏輯里，先執(zhí)行簽到數據的添加(這里可以防止并發(fā)，添加成功后再進行積分的添加，這樣就可以防止重復的添加積分了。最后我還是建議所有的數據操作都寫在一個sql事務里面， 這樣在添加失敗，或者編輯用戶積分失敗的時候可以回滾數據。
如例子2（事務+通過更新鎖 防止并發(fā)導致數據錯亂 或者事物+Update的鎖表機制）
需求點：【抽獎功能】抽獎一次消耗一個積分抽獎中獎后編輯剩余獎品總數剩余獎品總數為0，或者用戶積分為0的時候無法進行抽獎
已知表:用戶表，包含積分字段獎品表，包含獎品剩余數量字段
高并發(fā)意淫分析(屬于開發(fā)前的猜測):在高并發(fā)的情況下，會導致用戶參與抽獎的時候積分被扣除，而獎品實際上已經被抽完了
我的設計:在事物里，通過WITH (UPDLOCK) 鎖住商品表，或者Update 表的獎品剩余數量和最后編輯時間字段，來把數據行鎖住，然后進行用戶積分的消耗，都完成后提交事物，失敗就回滾。這樣就可以保證，只有可能存在一個操作在操作這件商品的數量，只有等到這個操作事物提交后，其他的操作這個商品行的事物才會繼續(xù)執(zhí)行。
如例子3（通過程序代碼防止包并發(fā)下的數據錯亂問題）
需求點：【緩存數據到cache里】，當緩存不存在的時候，從數據庫中獲取并保存在cache里，如果存在從cache里獲取，每天10點必須更新一次，其他時間點緩存兩個小時更新一次到10點的時候，凡是打開頁面的用戶會自動刷新頁面
問題點：這里有個邏輯用戶觸發(fā)緩存的更新，用戶刷新頁面，當緩存存在的時候，會取到最后一次緩存更新時間，如果當前時間大于十點，并且最后緩存時間是10點前，則會從數據庫中重新獲取數據保存到cache中。還有客戶端頁面會在10點時候用js發(fā)起頁面的刷新，就是因為有這樣的邏輯，導致10點的時候有很多并發(fā)請求同時過來，然后就會導致很多的sql查詢操作，理想的邏輯是，只有一個請求會去數據庫獲取，其他都是從緩存中獲取數據。(因為這個sql查詢很耗服務器性能，所以導致在10點的時候，突然間數據庫服務器壓力暴增)
解決問題：C#通過 （鎖）lock，在從數據讀取到緩存的那段代碼前面加上鎖，這樣在并發(fā)的情況下只會有一個請求是從數據庫里獲取數據，其他都是從緩存中獲取。
訪問量大的數據統(tǒng)計接口
需求： 用戶行為數據統(tǒng)計接口，用來記錄商品展示次數，用戶通過點擊圖片，或者鏈接，或者其他方式進入到商品詳情的行為次數
問題點：這接口是給前端ajax使用，訪問量會很大，一頁面展示的時候就會有幾十件商品的展示，滾動條滾到到頁面顯示商品的時候就會請求接口進行展示數據的統(tǒng)計，每次翻頁又會加載幾十件
意淫分析：設想如果同時有1W個用戶同時在線訪問頁面，一個次拉動滾動條屏幕頁面展示10件商品，這樣就會有10W個請求過來，服務端需要把請求數據入庫。在實際線上環(huán)境可能還會超過這個請求量，如果不經過進行高并發(fā)設計處理，服務器分分鐘給跪了。
解決問題：我們通過nodejs寫了一個數據處理接口，把統(tǒng)計數據先存到redis的list里。(使用nodejs寫接口的好處是，nodejs使用單線程異步事件機制，高并發(fā)處理能力強，不會因為數據邏輯處理問題導致服務器資源被占用而導致服務器宕機)然后再使用nodejs寫了一個腳本，腳本功能就是從redis里出列數據保存到mysql數據庫中。這個腳本會一直運行，當redis沒有數據需要同步到數據庫中的時候，sleep，讓在進行數據同步操作
高并發(fā)的下的服務器壓力均衡，合理站點架設，DB部署
以下我所知道的：
服務器代理nginx，做服務器的均衡負載，把壓力均衡到多臺服務器
部署集群 mysql數據庫， redis服務器，或者mongodb服務器，把一些常用的查詢數據，并且不會經常的變化的數據保存到其他nosql DB服務器中，來減少數據庫服務器的壓力，加快數據的響應速度。
數據緩存，Cache
在高并發(fā)接口的設計中可以使用具有高并發(fā)能力的編程語言去開發(fā)，如：nodejs 做web接口
服務器部署，圖片服務器分離，靜態(tài)文件走CDN
DBA數據庫的優(yōu)化查詢條件，索引優(yōu)化
消息存儲機制，將數據添加到信息隊列中(redis list)，然后再寫工具去入庫
腳本合理控制請求，如，防止用戶重復點擊導致的ajax多余的請求，等等。
并發(fā)測試神器推薦
Apache JMeter
Microsoft Web Application Stress Tool
Visual Studio 性能負載
感謝大家的支持，領取天貓雙12紅包，獲得推廣費用來維持網站的運行，謝謝理解。 [去領取] 轉載請申明原文地址，謝謝合作如有任何想說的請留言哦，我會根據大家的建議修改有疑義的內容歡迎大家關注我的 Github
