分佈式系統

分佈式系統

分佈式事務

分佈式事務實現方案

• 最大努力通知

  • 基於BASE理論作的保證數據最終一致性方案，基本可用，軟狀態，最終一致性
  • 具體實現爲，寫本地事務，同步寫一張事務消息表，發送事務消息，消息異步通知關聯繫統，處理失敗則利用MQ的重試功能作自動重試，超太重試次數記錄失敗狀態，定時任務掃描手動處理

• TCC事務補償方案

  • 須要一個事務處理器
  • 每一個事務必須實現try、confirm、cancel三個方法，開發維護成本高
  • 阿里開源框架實現seata

• 基於可靠消息的最終一致性方案

  • RocketMQ有事務消息的實現
  • 具體原理爲，業務方發送一個事務消息，MQ將消息落表，此時消息對消費方不可見
  • 發起方執行本地事務，通知MQ提交或回滾
  • MQ會定時查詢發起方的事務執行狀態，決定提交或回滾

TCC的優缺點

* 每一個事務必須實現try、confirm、cancel三個方法，開發維護成本高
* 事務管理器也存在單點問題
* 事務管理器事務活動日誌的存儲成本

兩階段提交與三階段提交的區別

* 三階段提交相比兩階段提交多了第 0 步檢查是否可提交，下降了反覆的「鎖定-釋放」的可能

SpringCloud

• 微服務服務發現與調用流程
  服務提供者啓動將本身的註冊到eureka
  服務消費者經過serviceId到eureka拉取服務提供者的實例IP
  服務消費者經過Ribbon，默認採用輪詢的方式調用消費者IP列表中實例

• ribbon的重試機制

  • 默認超時後重試原實例一次
  • 可配置重試其餘實例的次數
  • 實際配置關閉了重試，由於超時失敗下次請求大機率也會失敗，重試容易放大故障，增長壓力
• ribbon屢次調用一個實例失敗會將其剔除嗎？
• eureka服務下線感知
  有至少30秒延時（認爲延時可接受，用無損發佈可解決，無損發佈使用兩個池，一個起來以後將流量切過去）

微服務架構

• 系統設計的分層思想
  *各層獨立

  *只需瞭解當前層的使用，不須要關心其餘層的實現細節
    *組件之間獨立實現、獨立部署
    *可使用不一樣技術棧，實現多語言開發
    *各個服務可根據自身業務負載狀況進行實例和數據等資源擴展

  *職責專注，業務邊界清晰

  *能夠按業務組織團隊
    *服務按業務線劃分，可減小業務變化時的影響面，減小服務內部修改產生的內耗

  *變化和資源隔離

  *不一樣層之間的代碼或實現方式修改，不影響其餘層
    *組件之間調用線程隔離，並引入熔斷機制，能夠防止服務一掛全掛的狀況

  *高內聚

  *將大問題分解成小問題，有利於下降實現難度
    *代碼容易理解，開發效率高
    *有利於代碼功能複用

iso協議分層，應用分層等爲何分層

*各層獨立
    *只需瞭解當前層的使用，不須要關心其餘層的實現細節
*變化隔離
    *不一樣層之間的代碼或實現方式修改，不影響其餘層
*高內聚
    *將大問題分解成小問題，有利於下降實現難度

• 微服務的缺點
  *數據一致性，分佈式事務問題。因爲分佈式部署不能使用數據庫的事務機制，分佈式事務實現複雜。
  *網絡、容錯問題。各服務間經過網絡協議通訊，須要考慮服務間調用的負載均衡、限流、熔斷等問題。
  *分佈式資源管理的問題。組件與服務實例管理，鏈接池等公共資源分配。
  *運維難度加大。運維需管理的服務組件變多
  *涉及多個服務間互相調用使自動化測試難度加大
  *可能增長溝通成本

• 微服務架構使用時機
  *業務已經成型，能夠抽象定義出各種獨立的功能模塊進行開發管理
  *已經有比較大業務數據基礎，系統功能變得龐大複雜，能夠按照微服務進行組件拆分

  *業務尚未理清楚，處於快速開發、快速試錯、快速迭代階段
  *業務數據少，還未完成爆炸式增加
  *系統功能少

設計高併發、高可用系統用到的方法

高併發

高併發性，是系統從上到下優化改造的結果，從系統架構到業務處理都要注意處理

• 架構層面

  • 系統集羣化

    • 反向代理lvs、網關Nginx、微服務組件、redis都是集羣化部署
    • 多機同時對外提供服務
    • 服務無狀態，可無限水平擴容
  • 先後端分離，靜態頁面服務使用CDN加速
  • 數據庫分庫分表、讀寫分離

• 業務層面

  • 加緩存

    • 加redis緩存，redis熱key打散
    • Google Guava本地緩存

  • 代碼優化，流程優化

    • 性能低的代碼，如集合類的容量設置，多餘的循環，多查的數據，多餘的外部請求

  • 異步處理

    • 一些非關鍵業務的落庫操做改成異步。如大數據業務染色的token，異步保存，超線程池後，mq延遲消費

  • 並行處理

    • future加線程池並行處理

  • MQ削峯

    • mq消費速率固定，可防止峯值請求沖垮系統
    • mq延遲消費
    • 設置開關，開啓則暫時不消費，應對衝擊高峯
  • 版本探測機制
  • 數據增量返回
• 壓測，性能摸底

• 限流降級

  • 網關對接口直接限流，令牌桶算法對佔資源的接口限流，以下單、支付等
  • 應用層對業務限流，如優惠券使用令牌桶算法，超閾值就異步處理
  • 非關鍵業務直接降級，返回固定值，或服務不可用，關閉風控

高可用

高可用經過集羣冗餘，加故障自動轉移實現

• 系統集羣化，多機同時提供服務

  • 入口層：DNS輪詢
  • 反向代理層：lvs的keeplived+虛ip
  • 網關層：nginx的upstream屢次請求一臺實例失敗，會將這臺實例剔除
  • 微服務組件層：服務註冊與發現，心跳機制

• 故障自動轉移

  • 心跳機制，按期續約
  • 故障自動剔除
  • 主從切換
• 數據冗餘，主從切換機制
  redis緩存：主從複製，故障轉移（線上redis一主一從，16臺16G）
  數據庫：主從同步

• 流量分配，過載保護

  • 負載均衡：輪詢、哈希、隨機、固定比例、動態比例

  • 限流

    • 限流算法

      • 令牌桶：固定速率往桶中放令牌，可應對突發流量
      • 漏桶：固定速率從桶中流出請求，適應調下游服務承載能力固定的場景
      • 信號量限流：比較暴力，超過閾值直接丟棄請求

    • 分佈式限流算法

      • Nginx加lua實現令牌桶算法對接口進行限流

• 防故障蔓延

  • 降級
  • 隔離
  • 超時
• 容災：多機房、多活
• 快速回滾
• 性能指標監控