緩存、異步、集羣和分佈式等架構模式的實踐

緩存,極大提高數據讀寫能力,實現系統性能、可用性、併發能力提升,同時也節約了計算、網絡資源。異步,解決同步處理帶來一系列問題,實現並行方式處理、系統解耦、流量削峯填谷,實現高性能、高可用、可伸縮、最終一致性的架構。負載均衡(Load Balance),將流量負載分佈到多個服務器來提升服務、應用、數據庫等的性能和可靠性,是實現服務器集羣和分佈式高可用架構的關鍵組件。前端

緩存架構模式(分佈式緩存)

1. Cache 定義redis

存儲在計算機上的一個原始數據複製集,以便於訪問 。-- Wikipedia算法

  • Cache:緩存,加快取用的速度,偏重於讀。爲了彌補高速設備和低速設備的鴻溝而引入的中間層,最終起到加快訪問速度的做用。
  • Buffer:緩衝,緩和衝擊,偏重於寫。把突發打數量較小規模I/O整理成平穩的小數量較大規模I/O, 實現流量整形。

2. 緩存分類數據庫

  • 硬件和基礎系統

    i) CPU緩存瀏覽器

    ii) 操做系統緩存緩存

    iii) 數據庫緩存安全

    iv) JVM編譯緩存服務器

  • 應用層

attachments-2020-12-xE2PZYO75fe3f3ff92d24.jpg

i) 客戶端/瀏覽器緩存cookie

ii) CDN緩存網絡

iii) 代理與反向代理緩存

iv) 應用程序本地對象緩存

存儲在共享內存,同一臺機器的多個進程可訪問,做爲獨立應用和應用程序部署在同一個服務器上。需考慮分佈式集羣中緩存的數據同步問題,由於每個應用服務器有本身獨立的緩存服務器。

attachments-2020-12-pnONowfn5fe3f40a5a154.jpg

v) 分佈式對象緩存

可以使用緩存客戶端,經過協議訪問緩存服務集羣。集羣中緩存映射服務節點,通常使用「帶虛擬節點一致性哈希算法」來實現。

attachments-2020-12-g0nhIk0p5fe3f4140f61a.jpg

attachments-2020-12-ehLGff7F5fe3f41af181b.jpg

3. 緩存關鍵指標

緩存命中率:能多少次重用同一個緩存響應業務請求

影響因素:

  • 緩存鍵集合大小:鍵數量越少,緩存的效率越高
  • 緩存可以使用內存空間:物理上能緩存的對象越多,緩存命中率就越高
  • 緩存對象生存時間:TTL, 對象緩存的時間越長,緩存對象被重用的可能性就越高

4. 緩存策略

  • Read-through 通讀緩存

客戶端鏈接緩存,若是緩存存在就返回,沒命中代理鏈接到實際數據。

好比:代理緩存,反向代理緩存,CDN緩存

  • Cache-aside 旁路緩存

客戶端訪問緩存,如存在就返回,如不存在或已過時客戶端會鏈接數據源,緩存起來並返回。緩存一般是key-value存儲。

5. 爲何能提高和優化性能

  • 緩存數據來自內存,比磁盤上速度更快
  • 緩存是最終結果,無需計算,減小CPU資源消耗
  • 下降數據庫、磁盤、網絡的負載壓力,減小I/O資源
  • 技術簡單、性能提高顯著、應用場景多

6. 合理使用緩存

  • 頻繁修改數據:陡增系統負擔
  • 沒有熱點的訪問:不遵循二八定律,大部分數據訪問不是集中在小部分的數據上
  • 不能容忍數據不一致與髒讀
  • 緩存雪崩:數據庫不能承受較大的壓力而宕機,致使整個網站不可用。發生故障,甚至不能簡單的重啓緩存服務器和數據庫服務器來恢復服務
  • 緩存預熱:緩存預加載warm up, 對於一些元數據信息,能夠啓動時加載數據庫中的數據到緩存進行預熱
  • 緩存穿透:若是不誇當的業務或惡意攻擊持續高併發的請求某個不存在的緩存數據,全部請求會落在數據庫上,形成很大壓力,甚至崩潰。通常是將不存在的數據緩存起來value值爲null,並設置一個較短的失效時間。

7. Redis

  • Redis支持複雜的數據結構,支付多路複用異步I/O高性能,支持主從複製高可用,原生集羣與share nothing集羣模式
  • Redis集羣預分好16384個桶,放一個key-value時,根據CRC16(key) mod 16384, 決定key放到哪一個桶中
  • redis-cluster把全部的物理節點映射到[0-16383]slot上,cluster負責維護slot與服務器的映射關係
  • 客戶端與redis節點直連,全部redis節點彼此互聯

異步架構模式(消息隊列)

1. 同步調用 VS 異步調用

attachments-2020-12-SHgkrwth5fe3f42dedeed.jpg

2. 消息隊列

attachments-2020-12-rPFvJWUm5fe3f435791cf.jpg

兩個模式

  • 點對點模型:生產者生產一個消息只能被一個消費者消費
  • 發佈訂閱模式:生產者生產一個消息可被多個消費者進行訂閱消費

優勢

  • 實現異步處理,提高性能
  • 有更好的伸縮性
  • 流量的削峯填谷
  • 失敗隔離和自我修復
  • 解耦

    3. 事件驅動架構 EDA

attachments-2020-12-w5UP5Jb65fe3f446c31d8.jpgattachments-2020-12-51WJnNeu5fe3f44d23384.jpg

4. MQ產品

  • RabbitMQ:Erlang語言開發,性能好,社區活躍
  • ActiveMQ:Java語言開發,跨平臺
  • RocketMQ:阿里出品,Java開發,性能好,可靠性高
  • Kafka:LinkedIn出品,Scala開發,分佈式伸縮性會比較好

集羣和分佈式架構模式(負載均衡)

負載均衡有兩個重要的需關注點:如何選擇哪一個服務節點,就是路由算法;選擇好的節點如何鏈接進行服務分發,就是服務分發。

1. 服務分發

  • HTTP重定向負載均衡:性能和安全性差,已淘汰
  • DNS負載均衡:7層負載,結合其餘方式組合多層負載
  • 反向代理負載均衡:7層負載,可以使用軟件實現。如Ngnix
  • IP負載均衡:4層負載,IP數據包進行修改源和目標IP,請求和響應的流量都需通過負載服務器
  • 數據鏈路層負載均衡:4層負載,響應的流量無需通過負載服務器

2. 算法

  • 輪詢:依次分發
  • 加權輪詢:可配置權重
  • 隨機:隨機分配
  • 最少鏈接:記錄鏈接數,分發到最少的鏈接服務器
  • 源地址散列:源IP進行Hash,實現會話粘滯

    3. session管理

服務器高可用架構設計基於無狀態的特性,但業務老是有狀態,好比用戶登陸狀態。在分佈式集羣環境中,session管理有以下幾種:

  • session複製:節點多時,複製成本太高,性能較差
  • session綁定:業務迭代快時,可用性不夠
  • cookie記錄session:經過前端的cookie與服務器認證系統
  • session服務器:經過共享的sesion服務器集羣進行管理,把有狀態的服務與無狀態服務進行分離

 

相關文章
相關標籤/搜索