前言

實力有限，只能就我知道的寫?？偲粚懘笾路桨浮?/p>

一、分布式高并發(fā)問題

不同于單機環(huán)境，分布式微服務環(huán)境下最大的問題就是會出現(xiàn)不僅是跨線程還會有跨服務的數(shù)據(jù)一致性問題。單機環(huán)境下我們有volatile和synchronized以及JUC下的并發(fā)編程工具等工具實現(xiàn)并發(fā)編程。分布式跨服務環(huán)境下就得使用別的方案支持，例如分布式鎖、分布式事務、分布式ID等方案滿足業(yè)務需求。

1. 分布式鎖

（1）mysql

利用mysql的主鍵或唯一索引。

（2）redis

設置有效時間避免死鎖，看門狗線程自動續(xù)期。
redis集群的紅鎖。

（3）zookeeper+mysql樂觀鎖

解決stw情況下redis鎖失效的問題。

分布式鎖的問題和優(yōu)化

單點問題
使用分段鎖

2. 分布式事務

思路

項目中盡量不要使用分布式事務，一般來說只會將非核心非強一致性的業(yè)務操作例如通知、日志等，核心的操作最好是放在同一個事務處理。
利用mysql本身支持的事務功能，設計一種方案，可以確認在每個服務或數(shù)據(jù)庫上的整段操作是否可行，根據(jù)每段操作的執(zhí)行結果判斷是全部提交還是全部回滾。

（1）2pc

協(xié)調者，事務執(zhí)行者（數(shù)據(jù)庫）
一階段：開啟事務，預執(zhí)行，并返回執(zhí)行結果給協(xié)調者。
二階段：協(xié)調者根據(jù)返回的執(zhí)行結果判斷是全部提交還是全部回滾。

缺點：

1. 不能完全保證數(shù)據(jù)一致性
2. 占用數(shù)據(jù)庫連接

回滾方案

定時任務校驗數(shù)據(jù)并報警

阿里seata工具優(yōu)化兩階段提交（樂觀鎖+undolog）

在一階段就commit釋放資源，但是會記錄操作（類似undolog），在二階段如果成功就不處理失敗就執(zhí)行回滾。

（2）3pc

比起2pc，減少了回滾場景下無用的連接和資源浪費
一階段：can commit
二階段：pre commit
三階段：do commit

（3）tcc方案

場景：數(shù)據(jù)庫與緩存同步方案 try confirm cancel

（4）事務表策略

采用 數(shù)據(jù)庫事件表+消息隊列+定時任務\監(jiān)聽器 實現(xiàn)的異步事務方案。

1. 用戶請求 -> 執(zhí)行業(yè)務 -> 寫數(shù)據(jù)庫事件表 -> 直接放回結果
2. 定時任務查詢事件表 -> 發(fā)送消息隊列 -> 更新事件表狀態(tài)已發(fā)送
3. 接收者接受到消息后消費 -> 保存到另一張待執(zhí)行事件表 -> 發(fā)送消息ack -> 更新事件表狀態(tài)已消費
4. 定時任務查詢待執(zhí)行事件表 -> 執(zhí)行事務 -> 更新待執(zhí)行事件表狀態(tài)已執(zhí)行
   方案中也可以省略定時任務，直接在前一個步驟就執(zhí)行操作。

（5）消息中間件事務

3. 分布式ID

（1）mysql

基于MySQL的原子自增主鍵 auto increment。

Segment優(yōu)化：

批量生成策略，雙重緩存策略。

（2）雪花算法

時間戳+64機器碼+nodeID+areaID+自增
缺點：單點故障、時間回退、NodeID和areaID的分配
優(yōu)化：zookeeper+雪花算法

二、高并發(fā)高性能

1. 客戶端優(yōu)化

（1）瀏覽器緩存

（2）部分計算交由客戶端完成

（3）減少客戶端重復請求

1. 按鈕置灰
2. 重刷校驗
3. 驗證碼校驗

（4）高并發(fā)的業(yè)務中減少非必要的功能和請求

（5）優(yōu)化請求

1. 合并多個請求
2. 只提交必要數(shù)據(jù)

（6）將大數(shù)據(jù)請求拆分為多個請求

2. 網(wǎng)絡層優(yōu)化

（1）NDS+CDN 多地部署

（2）網(wǎng)關層添加黑名單

（3）負載均衡和靜態(tài)服務器

3. 應用層優(yōu)化

思路

對應用的優(yōu)化，主要就兩條：最大程度壓榨系統(tǒng)性能以及怎么避免系統(tǒng)超過極限。
壓榨系統(tǒng)性能本質上其實就是盡可能壓榨系統(tǒng)CUP和IO的性能。對CUP的利用率，可以從并發(fā)編程入手，對IO的利用率，主要是對緩存的應用。
超過系統(tǒng)壓力的情況下處理方案：分壓和限流。分系統(tǒng)分業(yè)務分緩存，阻塞緩存。

（1）緩存使用和優(yōu)化

1. 增：緩存預熱（熱點數(shù)據(jù)分析）

通過跟蹤埋點、日志和數(shù)據(jù)庫，分析高頻查詢、收藏、購物車、訂單這類數(shù)據(jù)，以及活動等確定熱點數(shù)據(jù)預熱。

2. 刪：緩存清除策略

基于時效清除、LRU算法、靈活分配策略（使用GC+SoftRefrence<>）
由于GC+軟引用的不確定性（不直接受業(yè)務控制），一般是用來作為LRU算法的補充優(yōu)化。

3. 改：緩存數(shù)據(jù)刷新和一致性問題

1. 定時更新、時效更新（被動更新，需要允許數(shù)據(jù)延遲，例如個人信息、收藏、點贊、評論、排名）
2. 主動更新：（cache aside 鴕鳥算法，允許一定容忍度）
   1.先更新緩存后更新數(shù)據(jù)庫（可能出現(xiàn)數(shù)據(jù)庫更新失敗問題）
   2.更新數(shù)據(jù)庫順便更新緩存（可能出現(xiàn)先后更新緩存問題）
   3.刪除緩存，更新數(shù)據(jù)庫，后面查詢的時候再更新緩存（可能出現(xiàn)在更新數(shù)據(jù)庫過程中又查詢了一次緩存）
   4.更新數(shù)據(jù)庫，刪除緩存，后面查詢的時候再更新緩存

4. 怎么用：緩存優(yōu)化

根據(jù)業(yè)務靈活使用緩存清除策略。
緩存分段提高緩存利用率。

5. 緩存擊穿、緩存穿透、雪崩問題解決方案

布隆過濾器、自動續(xù)期、分時段、隊列緩沖

（2）高并發(fā)下系統(tǒng)優(yōu)化

1. 分系統(tǒng)分業(yè)務分緩存
2. 分段分流：活動采用分時間段拆分多個活動 和 預付定金活動
3. 消息隊列： 異步 和 削峰

（3）分布式鎖優(yōu)化

使用讀寫鎖方式 和 分段鎖

4. 數(shù)據(jù)庫層

按影響范圍：索引優(yōu)化、分區(qū)、分庫分表（歷史表-歸檔、水平分表、垂直分表）、讀寫分離（主從一致性問題）
主從一致性問題：

1. 從庫禁止寫操作
2. binlog+IO thread+replaylog+SQL thread 實現(xiàn)主從復制（日志類型需要使用混合模式）
3. 對強一致性數(shù)據(jù)使用讀寫鎖或者放棄使用讀寫分離和緩存

三、高可用

思路

除了使用主備或集群方式解決單點故障問題。
還可以從整體和局部上分析，通過減少環(huán)節(jié)和隔離方式避免單個或局部服務出錯導致整個系統(tǒng)受影響。（隔離、限流、熔斷、降級、恢復）

1. 服務主備、集群配置

2. 隔離、限流、熔斷、降級、恢復

1. 隔離：服務間盡量保證業(yè)務隔離、系統(tǒng)隔離、數(shù)據(jù)隔離
2. 限流：不局限于隊列限流、令牌桶、輸入驗證碼等都算，核心就是不要讓請求一次請打到服務器上
3. 熔斷：由于服務器的不確定性，在出現(xiàn)多次請求失敗/超時下熔斷，不在請求后面服務，一段時間后嘗試恢復
4. 降級：由于業(yè)務的不確定性，在出現(xiàn)高峰期的時候主動舍棄非核心功能，保證核心功能正常使用
5. 恢復分批少量開放，逐級恢復

3. 提供補償（兜底）方案

在開發(fā)過程中，分析功能可能出現(xiàn)的問題（超時、異步請求失敗、分布式事務失敗等），設計補償方案。
根據(jù)具體業(yè)務實現(xiàn)（優(yōu)惠券補發(fā)、退款、定時數(shù)據(jù)核驗、等待頁面等）文章來源地址http://www.zghlxwxcb.cn/news/detail-634550.html

到了這里，關于分布式微服務項目實現(xiàn)高并發(fā)高可用高性能可以使用到的方案的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！