前言
高并發(fā)經(jīng)常會發(fā)生在有大活躍用戶量隶债，用戶高聚集的業(yè)務場景中秉溉，如：秒殺活動力惯，定時領取紅包等。
為了讓業(yè)務可以流暢的運行并且給用戶一個好的交互體驗召嘶，我們需要根據(jù)業(yè)務場景預估達到的并發(fā)量等因素父晶，來設計適合自己業(yè)務場景的高并發(fā)處理方案。
在電商相關產(chǎn)品開發(fā)的這些年弄跌，我有幸的遇到了并發(fā)下的各種坑甲喝，這一路摸爬滾打過來有著不少的血淚史，這里進行的總結(jié)铛只，作為自己的歸檔記錄埠胖，同時分享給大家。
服務器架構(gòu)
業(yè)務從發(fā)展的初期到逐漸成熟淳玩，服務器架構(gòu)也是從相對單一到集群直撤，再到分布式服務。
一個可以支持高并發(fā)的服務少不了好的服務器架構(gòu)蜕着，需要有均衡負載谋竖，數(shù)據(jù)庫需要主從集群，nosql緩存需要主從集群承匣，靜態(tài)文件需要上傳cdn蓖乘，這些都是能讓業(yè)務程序流暢運行的強大后盾。
服務器這塊多是需要運維人員來配合搭建韧骗，具體我就不多說了嘉抒，點到為止。
大致需要用到的服務器架構(gòu)如下：
服務器
均衡負載(如：nginx宽闲，阿里云SLB)
資源監(jiān)控
分布式
數(shù)據(jù)庫
主從分離众眨，集群
DBA 表優(yōu)化，索引優(yōu)化容诬，等
分布式
nosql
主從分離娩梨，集群
redis
mongodb
memcache
cdn
html
css
js
image
并發(fā)測試
高并發(fā)相關的業(yè)務，需要進行并發(fā)的測試览徒，通過大量的數(shù)據(jù)分析評估出整個架構(gòu)可以支撐的并發(fā)量狈定。
測試高并發(fā)可以使用第三方服務器或者自己測試服務器，利用測試工具進行并發(fā)請求測試，分析測試數(shù)據(jù)得到可以支撐并發(fā)數(shù)量的評估纽什，這個可以作為一個預警參考措嵌，俗話說知己自彼百戰(zhàn)不殆。
第三方服務:
阿里云性能測試?
并發(fā)測試工具：
Apache JMeter
Visual Studio性能負載測試 Microsoft Web A
pplication Stress Tool
實戰(zhàn)方案
通用方案
日用戶流量大芦缰，但是比較分散企巢，偶爾會有用戶高聚的情況；?
場景： 用戶簽到让蕾，用戶中心浪规，用戶訂單，等
服務器架構(gòu)圖：?
說明：
場景中的這些業(yè)務基本是用戶進入APP后會操作到的探孝，除了活動日(618,雙11笋婿，等)，這些業(yè)務的用戶量都不會高聚集顿颅，同時這些業(yè)務相關的表都是大數(shù)據(jù)表缸濒，業(yè)務多是查詢操作，所以我們需要減少用戶直接命中DB的查詢粱腻；優(yōu)先查詢緩存庇配，如果緩存不存在，再進行DB查詢绍些，將查詢結(jié)果緩存起來讨永。
更新用戶相關緩存需要分布式存儲，比如使用用戶ID進行hash分組遇革，把用戶分布到不同的緩存中，這樣一個緩存集合的總量不會很大揭糕，不會影響查詢效率萝快。
方案如：
用戶簽到獲取積分?
計算出用戶分布的key,redis hash中查找用戶今日簽到信息?
如果查詢到簽到信息，返回簽到信息?
如果沒有查詢到著角，DB查詢今日是否簽到過揪漩，如果有簽到過，就把簽到信息同步redis緩存吏口。?
如果DB中也沒有查詢到今日的簽到記錄奄容，就進行簽到邏輯，操作DB添加今日簽到記錄产徊，添加簽到積分(這整個DB操作是一個事務)?
緩存簽到信息到redis昂勒，返回簽到信息?
注意這里會有并發(fā)情況下的邏輯問題，如：一天簽到多次舟铜，發(fā)放多次積分給用戶戈盈。?
用戶訂單?
這里我們只緩存用戶第一頁的訂單信息，一頁40條數(shù)據(jù)，用戶一般也只會看第一頁的訂單數(shù)據(jù)?
用戶訪問訂單列表塘娶，如果是第一頁讀緩存归斤，如果不是讀DB?
計算出用戶分布的key,redis hash中查找用戶訂單信息?
如果查詢到用戶訂單信息，返回訂單信息?
如果不存在就進行DB查詢第一頁的訂單數(shù)據(jù)刁岸，然后緩存redis脏里，返回訂單信息
用戶中心?
計算出用戶分布的key,redis hash中查找用戶訂單信息?
如果查詢到用戶信息，返回用戶信息?
如果不存在進行用戶DB查詢虹曙，然后緩存redis迫横，返回用戶信息
其他業(yè)務?
上面例子多是針對用戶存儲緩存，如果是公用的緩存數(shù)據(jù)需要注意一些問題根吁，如下?
注意公用的緩存數(shù)據(jù)需要考慮并發(fā)下的可能會導致大量命中DB查詢员淫，可以使用管理后臺更新緩存，或者DB查詢的鎖住操作击敌。?
以上例子是一個相對簡單的高并發(fā)架構(gòu)介返，并發(fā)量不是很高的情況可以很好的支撐，但是隨著業(yè)務的壯大沃斤，用戶并發(fā)量增加圣蝎，我們的架構(gòu)也會進行不斷的優(yōu)化和演變，比如對業(yè)務進行服務化衡瓶，每個服務有自己的并發(fā)架構(gòu)徘公，自己的均衡服務器，分布式數(shù)據(jù)庫哮针，nosql主從集群关面，如：用戶服務、訂單服務十厢；
消息隊列?
秒殺等太、秒搶等活動業(yè)務，用戶在瞬間涌入產(chǎn)生高并發(fā)請求?
場景：定時領取紅包蛮放，等
服務器架構(gòu)圖：?
說明：
場景中的定時領取是一個高并發(fā)的業(yè)務缩抡，像秒殺活動用戶會在到點的時間涌入，DB瞬間就接受到一記暴擊包颁，hold不住就會宕機瞻想，然后影響整個業(yè)務；
像這種不是只有查詢的操作并且會有高并發(fā)的插入或者更新數(shù)據(jù)的業(yè)務娩嚼，前面提到的通用方案就無法支撐蘑险，并發(fā)的時候都是直接命中DB；
設計這塊業(yè)務的時候就會使用消息隊列的待锈，可以將參與用戶的信息添加到消息隊列中漠其，然后再寫個多線程程序去消耗隊列，給隊列中的用戶發(fā)放紅包；
方案如：
定時領取紅包?
一般習慣使用 redis的 list?
當用戶參與活動和屎，將用戶參與信息push到隊列中?
然后寫個多線程程序去pop數(shù)據(jù)拴驮，進行發(fā)放紅包的業(yè)務?
這樣可以支持高并發(fā)下的用戶可以正常的參與活動，并且避免數(shù)據(jù)庫服務器宕機的危險
附加：?
通過消息隊列可以做很多的服務柴信。
如：定時短信發(fā)送服務套啤，使用sset(sorted set)，發(fā)送時間戳作為排序依據(jù)随常，短信數(shù)據(jù)隊列根據(jù)時間升序潜沦，然后寫個程序定時循環(huán)去讀取sset隊列中的第一條，當前時間是否超過發(fā)送時間绪氛，如果超過就進行短信發(fā)送唆鸡。
一級緩存
高并發(fā)請求連接緩存服務器超出服務器能夠接收的請求連接量，部分用戶出現(xiàn)建立連接超時無法讀取到數(shù)據(jù)的問題枣察；
因此需要有個方案當高并發(fā)時候時候可以減少命中緩存服務器争占；
這時候就出現(xiàn)了一級緩存的方案，一級緩存就是使用站點服務器緩存去存儲數(shù)據(jù)序目，注意只存儲部分請求量大的數(shù)據(jù)臂痕，并且緩存的數(shù)據(jù)量要控制，不能過分的使用站點服務器的內(nèi)存而影響了站點應用程序的正常運行猿涨，一級緩存需要設置秒單位的過期時間握童，具體時間根據(jù)業(yè)務場景設定，目的是當有高并發(fā)請求的時候可以讓數(shù)據(jù)的獲取命中到一級緩存叛赚，而不用連接緩存nosql數(shù)據(jù)服務器澡绩，減少nosql數(shù)據(jù)服務器的壓力
比如APP首屏商品數(shù)據(jù)接口，這些數(shù)據(jù)是公共的不會針對用戶自定義俺附，而且這些數(shù)據(jù)不會頻繁的更新英古，像這種接口的請求量比較大就可以加入一級緩存；
服務器架構(gòu)圖：?
支付寶架構(gòu)師眼里的高并發(fā)架構(gòu)
合理的規(guī)范和使用nosql緩存數(shù)據(jù)庫昙读，根據(jù)業(yè)務拆分緩存數(shù)據(jù)庫的集群，這樣基本可以很好支持業(yè)務膨桥，一級緩存畢竟是使用站點服務器緩存所以還是要善用蛮浑。
靜態(tài)化數(shù)據(jù)
高并發(fā)請求數(shù)據(jù)不變化的情況下如果可以不請求自己的服務器獲取數(shù)據(jù)那就可以減少服務器的資源壓力。
對于更新頻繁度不高只嚣，并且數(shù)據(jù)允許短時間內(nèi)的延遲沮稚，可以通過數(shù)據(jù)靜態(tài)化成JSON，XML,HTML等數(shù)據(jù)文件上傳CDN册舞，在拉取數(shù)據(jù)的時候優(yōu)先到CDN拉取蕴掏，如果沒有獲取到數(shù)據(jù)再從緩存，數(shù)據(jù)庫中獲取，當管理人員操作后臺編輯數(shù)據(jù)再重新生成靜態(tài)文件上傳同步到CDN盛杰，這樣在高并發(fā)的時候可以使數(shù)據(jù)的獲取命中在CDN服務器上挽荡。
CDN節(jié)點同步有一定的延遲性，所以找一個靠譜的CDN服務器商也很重要
其他方案
對于更新頻繁度不高的數(shù)據(jù)即供，APP,PC瀏覽器定拟，可以緩存數(shù)據(jù)到本地，然后每次請求接口的時候上傳當前緩存數(shù)據(jù)的版本號逗嫡，服務端接收到版本號判斷版本號與最新數(shù)據(jù)版本號是否一致青自，如果不一樣就進行最新數(shù)據(jù)的查詢并返回最新數(shù)據(jù)和最新版本號，如果一樣就返回狀態(tài)碼告知數(shù)據(jù)已經(jīng)是最新驱证。
減少服務器壓力：資源延窜、帶寬
針對上面的技術我特意整理了一下，有很多技術不是靠幾句話能講清楚抹锄，所以干脆找朋友錄制了一些視頻逆瑞，很多問題其實答案很簡單，但是背后的思考和邏輯不簡單祈远，要做到知其然還要知其所以然呆万。如果想學習Java工程化、高性能及分布式车份、深入淺出谋减。微服務、Spring扫沼，MyBatis出爹，Netty源碼分析的朋友可以加我的Java進階群：680130298，群里有阿里大牛直播講解技術缎除，以及Java大型互聯(lián)網(wǎng)技術的視頻免費分享給大家严就。?
