由於系統都是連線資料庫的，但是一般最多資料庫每秒只能支撐幾千的並非，如果業務量激增，會導致系統宕機；因此需要從一下幾點入手設計
· 系統拆分
· 快取
· mq
· 分庫分表
· 讀寫分離
· 搜尋
將乙個系統進行功能拆分，如現在流行的微服務，每個服務連線的資料庫分開，分開部署。這樣可以將壓力進行拆分，緩解因為網路和資料庫導致的高併發
大部分場景下，都是查詢多餘插入更新，也就是讀多寫少。因此設計時對常用的查詢內容必須進行快取，查詢時先查快取，再查資料庫；更新時也要更新快取；
redis 單機支援幾萬的併發。專案設計時針對那些承載主要請求的讀場景，怎麼用快取來抗高併發。
再考慮高併發寫的場景，比如乙個業務操作要資料庫操作幾十次，增刪改增刪改，在普通環境下不會有問題，但是如果高併發絕對會出現問題；
如通訊分析專案，話單匯入時多執行緒同時匯入。如果多個使用者都同時匯入，會有多個匯入任務，幾十幾百甚至啟動上千的執行緒跑。也會導致系統出現問題；
可以將大量的寫請求灌入 mq 裡，進行排隊，後邊系統慢慢寫，控制在資料庫承載範圍之內。mq 單機支援幾萬併發，所以設計系統時，對應承載複雜寫業務邏輯的場景裡，如何用 mq 來非同步寫，提公升併發性。
缺點：· 系統可用性降低-外部依賴越多，越容易出現問題
· 系統複雜度提高-需要處理重複消費和丟失的問題
· 一致性問題-由於是非同步需要保證資料的完整
kafka、activemq、rabbitmq、rocketmq 優缺點
單個資料庫無法支援，可以考慮多個資料庫；如果單個表內容太多可以考慮把錶分開儲存；單錶資料量太大也可以表拆分或者類似分割槽表的形式處理，每個表的資料量保持少一點，提高 sql 跑的效能
讀寫分離，就是大部分時候資料庫可能是讀多寫少，沒必要所有請求都集中在乙個庫上，可以搞個主從架構，主庫寫入，從庫讀取，讀寫分離。讀流量太多的時候，還可以加更多的從庫
如elasticsearch，簡稱 es。es 是分布式的，可以隨便擴容，分布式天然就可以支撐高併發，因為可以擴容加機器來扛更高的併發。一些比較簡單的查詢、統計類的操作，可以考慮用 es 來承載，還有一些全文搜尋類的操作，也可以用 es 來承載
在實際設計專案中，做高併發要遠比上面提到的點要複雜的多。需要考慮：
哪些需要分庫分表，哪些不需要分庫分表，單庫單錶跟分庫分表如何 join，哪些資料要放到快取裡去，放哪些資料才可以扛住高併發的請求
需要完成對乙個複雜業務系統的分析之後，然後逐步逐步的加入高併發的系統架構的改造
kafka在高併發場景下的解決方案
在我們現在開發的專案中，經常會用到kafka訊息中介軟體。一般情況下，單執行緒 單分割槽 的配置已經可以滿足需求，但是在某些大資料和資料併發量要求較高的應用場景下經常會遇到訊息來不及處理，出現訊息積壓的情況。因此，該文章主要針對這種應用場景提供了乙個多執行緒消費的解決方案 自己在平時使用kafka訊...
高併發解決方案
時常看到高併發的問題，但高併發其實是最不需要考慮的東西。為何，他虛無縹緲，很少有 真的需要這些東西，而且其中很多技術，其實你已經在用了。有這個意識就夠了，不需要時刻盯著這個問題。只有很少的 真的能達到高併發。簡單做乙個歸納，從低成本 高效能和高擴張性的角度來說有如下處理方案 1 html靜態化 2 ...
高併發解決方案
將靜態資源分離到靜態站，對靜態資源的請求打到靜態站，增加動態站的請求處理量 頁面靜態化是將程式生成的頁面儲存起來，使用模板技術如freemarker和velocity生成靜態頁面 nginx快取頁面資訊，再次請求時直接從快取中獲取，不需要重新生成，頁面快取記憶體中，提高訪問速度 具有相同處理功能的伺...