怎么理解數(shù)據(jù)庫分布式架構(gòu)的高并發(fā)處理

這篇文章主要介紹“怎么理解數(shù)據(jù)庫分布式架構(gòu)的高并發(fā)處理”，在日常操作中，相信很多人在怎么理解數(shù)據(jù)庫分布式架構(gòu)的高并發(fā)處理問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”怎么理解數(shù)據(jù)庫分布式架構(gòu)的高并發(fā)處理”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

分布式架構(gòu) 高并發(fā)處理

高并發(fā)介紹

• 在同時或者極短時間內(nèi)，有大量請求到達服務(wù)端，每個請求都需要服務(wù)端耗費資源進行處理，并做出相應(yīng)反饋

• 服務(wù)端比如同時開啟進程數(shù)，能同時運行的線程數(shù)、網(wǎng)絡(luò)連接數(shù)、CPU運算、I/O、內(nèi)存都是有限，
  所以服務(wù)端能同時處理請求也是有限的。高并發(fā)本質(zhì)就是資源的有限性
  如：1.系統(tǒng)在線人數(shù)10W，并不意味系統(tǒng)并發(fā)用戶是10W,可能存在10w用戶同時在首頁查看靜態(tài)文章，并未對服務(wù)器進行發(fā)送請求
  那么高并發(fā)數(shù) 是根據(jù)系統(tǒng)真實用戶數(shù)并發(fā)送請求需要服務(wù)端耗費資源進行處理的請求
  2.服務(wù)端只能開啟100個線程，恰好1個線程處理一個請求需要耗時1s，那么服務(wù)端1s只能處理100個請求，多余請求無法處理

經(jīng)典案例

• 商品、活動秒殺下訂單

準備階段

• 系統(tǒng)獨立部署

• 做好系統(tǒng)容量規(guī)劃（7-7.5折計算），系統(tǒng)優(yōu)化、系統(tǒng)容災(zāi)限流等方案

• 做好系統(tǒng)拆分，如：功能模塊、實時/非實時、動態(tài)/靜態(tài)等

• 參加活動商品設(shè)置定時上架時間

• 服務(wù)器時間同步（集群中每臺機器時鐘要保持一致）

• 動態(tài)生成下單頁面的URL

實現(xiàn)階段

客戶端層面：

• 前端頁面采用h6靜態(tài)化，ajax獲取動態(tài)內(nèi)容；如實時庫存、活動狀態(tài)、當前時間等

• 做CDN部署加速

• 靜態(tài)頁面和資源緩存 如：（圖片）

• JS針對請求過濾，減少請求發(fā)送到達服務(wù)端 如：（獲取驗證碼、時間截止或已售空自動結(jié)束等）

Web端層面：

• F5/LVS+Nginx接收高并發(fā)請求、并做負載均衡

• Lua腳本+Redis做請求隊列，針對有效請求用List排隊，并實現(xiàn)一些基本操作（限流、賬號參加次數(shù)檢查、同一IP請求數(shù)檢查）
  Redis單線程高性能，每秒處理100W請求，如果大于100W請求如何處理呢？
  1.可以結(jié)合Lua腳本控制請求數(shù)量并限流，有效減少redis壓力；比如100W請求，過濾20W，還剩80W，無效請求直接返回客戶端不到達服務(wù)端
  2.如果應(yīng)用非常龐大，用戶流量高額，Redis單節(jié)點做成集群模式，請求處理數(shù)量也隨之增加

• Varnish緩存靜態(tài)頁面和靜態(tài)資源

• Tomcat集群，預(yù)處理，通過業(yè)務(wù)場景判斷用戶是具備參加活動資格、賬號是否正常、是否在黑名單等

邏輯層面：

• 按照Redis請求隊列進行先后處理

• 純內(nèi)存操作+異步（通過Redis完成減庫存，1.利用Redis的watch事物 2.利用Redis腳本Lua原子操作減庫存）

高并發(fā)產(chǎn)生問題，分析思考

• 服務(wù)端處理響應(yīng)會逐漸變慢，甚至會丟失部分請求不處理，嚴重會導(dǎo)致服務(wù)器崩潰

• 客戶端（app\h6）、前端請求（nginx/varnish）、web服務(wù)器(webServer)、web應(yīng)用(rmi/dubbo/遠程調(diào)用)、緩存（redis/membercache）、消息隊列（mq）、數(shù)據(jù)庫（db）都會面臨高并發(fā)等問題

高并發(fā)優(yōu)化思路

客戶端層面

• 盡量減少請求數(shù)量，充分利用客戶端、瀏覽器自身緩存，如微服務(wù)前后端交互、網(wǎng)絡(luò)傳輸詳細記載，本文不在詳敘

• 盡量減少對服務(wù)端資源不必要浪費，如重復(fù)請求連接后端打開/關(guān)閉操作連接池

Nginx層面

• 動靜分離，靜態(tài)資源直接返回

• 負載均衡，如F5/LVS分流多個Nginx

• 根據(jù)系統(tǒng)業(yè)務(wù)，單獨拆分訪問（路徑）

Varnish層面

• 動態(tài)內(nèi)容緩存、減少訪問后端服務(wù)

• 使用頁面片段緩存技術(shù)，如ESI

Web服務(wù)器層面

• 針對JVM配置進行合理優(yōu)化

• 服務(wù)器配置進行優(yōu)化，如：調(diào)整內(nèi)存數(shù)量、線程數(shù)量等

• 相同服務(wù)部署多臺機器，實現(xiàn)負載均衡

• 增加資源，如增加網(wǎng)絡(luò)帶寬、高性能服務(wù)器、高性能數(shù)據(jù)庫 （立桿見效，服務(wù)器普通硬盤換SSD,數(shù)據(jù)庫換物理機等）

• 請求分流
  1.使用集群：如之前1臺處理100個請求，增加兩臺后，3臺機器虛擬組成一個集群后，對外處理請求可以提升到300*80%=240
  2.采用微服務(wù)架構(gòu)，后續(xù)微服務(wù)架構(gòu)高可用會詳細描述

Web應(yīng)用層面（優(yōu)化應(yīng)用程序）

• 提高單個請求的處理速度，如上如果處理一個請求消耗從1s降低到0.5秒，并發(fā)就是200

• 耗時業(yè)務(wù)同步根據(jù)業(yè)務(wù)情況 使用mq異步處理

• 比如導(dǎo)入、導(dǎo)出耗時耗力 合理使用多線程批量處理、指向單臺應(yīng)用獨立處理

• 高效使用緩存，減少鎖的使用范圍

• 優(yōu)化訪問數(shù)據(jù)庫SQL

• 盡量避免遠程調(diào)用、大量I/O等耗時操作

• 合理規(guī)劃事物等比較耗資源操作

• 部分業(yè)務(wù)考慮采用預(yù)計算處理，減少實時計算耗資源操作 如：報表

• 不要盲目使用RPC、netty、http遠程網(wǎng)絡(luò)調(diào)用，如需特定調(diào)用注意加上超時時間

數(shù)據(jù)庫層面

• 合理使用數(shù)據(jù)庫引擎 如 mysql的InnoDB和MyISAM引擎

• 數(shù)據(jù)庫系統(tǒng)參數(shù)配置優(yōu)化

• 特殊復(fù)雜計算耗時操作可以考慮使用存儲過程來處理

• 數(shù)據(jù)庫集群，進行讀寫分離

• 合理設(shè)計數(shù)據(jù)庫表結(jié)構(gòu)、索引 如（組合索引）

• 分庫、分區(qū)、分表降到單庫單表并發(fā)量

• 合理使用Nosql，如傳統(tǒng)、分布式數(shù)據(jù)庫共存，根據(jù)數(shù)據(jù)特性合理存放（hbase、hive、mongoDB）

到此，關(guān)于“怎么理解數(shù)據(jù)庫分布式架構(gòu)的高并發(fā)處理”的學習就結(jié)束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關(guān)知識，請繼續(xù)關(guān)注億速云網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>