場景十二：從電商架構演進看互聯網高可用架構設計--數據緩存架構
分佈式數據架構
緩存爲王的世界,流量峯值比較明顯,要考慮系統對峯值流量的承載能力,也就是系統的可伸縮性。如果按照峯值設計，那麼系統在90%的情況下是浪費的，如何設計良好的架構既能滿足峯值需求又不浪費資源，這就是伸縮性，而緩存又是伸縮性中一個重要技能。
緩存類型
CDN：靜態緩存
分佈式緩存：redis等
本地緩存:如JVM
把靜態資源放在離用戶最近的地方，用戶體驗最好。需要進行計算的資源需要放在離cpu最近的地方，性能最好。
分佈式緩存
memcache
以內存作爲緩存區，每個進程最大爲2G
緩存策略：最近最少使用，每條數據必須有過期時間
各個memcache不共享、不通信
內存管理模式，不存硬盤。
性能很高。
可作爲熱點緩存使用。
redis
基於內存、多數據結構存儲系統，可用作數據庫、緩存、消息中間件。
redis複製原理
基於內存快照。
需要謹慎使用，尤其是數據量較大時，複製的性能波動是比較大的。
幾種常見的分片策略
客戶端分片技術。
按照指定維度取模
一致性哈希進行分片
缺點：節點較少時，分佈不均衡。
通過虛節點的機制改進均衡性，一個真實節點對應多個虛節點，虛節點均衡的放到環上。
Redis與Memcache比較
網絡IO模型
memcache多線程、非阻塞IO複用的網絡模型。
Redis單線程IO複用模型。
都是基於事件處理機制的框架。
Redis的性能表現略優於Memcache。
memcache需要同時滿足兩個條件，有峯值流量處理不均勻、並且業務處理流程耗時較大。如果業務處理流程僅僅是單純的io操作時，線程切換會消耗性能成本較高。
內存管理方面
Memcache預分配內存，缺點空間浪費。
Redis現場申請內存的方式來存儲數據，缺點會有內存碎片 。
存儲方式及其他方面
關於不同語言的客戶端支持
總結
購物車使用Redis最佳實踐講解分析
購物車特點：1流量大、2峯值明顯、3數據量大
Redis作爲內存DB使用，無持久化
（購物車數據對數據安全性要求不高，極端情況下購物車丟一條數據相對可以接受的。性能要求比較高，持久化會影響性能。使用用戶維度作爲分片，無主從，全量內存。）
主備（備庫只做熱備）採用雙寫（避免主從複製問題），同步寫主異步寫備（最終一致性），主出問題備頂上（有損設計
（單節點斷點的應對方案，增加1:1的雙主結構同步雙寫，讀的時候只讀內存節點，外層節點作爲備份，外層節點做持久化。內層節點斷點，自動切換到外層節點）
存儲結構，登錄用戶使用cookie+pin作爲key，非登錄用戶使用cookie作爲key
部署結構，雙機房兩套一樣的Redis集羣（雙環）
就近讀寫、異步同步
大數據分析時一定不要讀線上的數據庫、緩存等。
作業：
Body結構應該怎麼去設計？list？set？
本地緩存
應用內部的緩存，不需要走網絡，性能非常快。標準的分佈式系統，一般與多級緩存構成，本地緩存是離應用最近的緩存，一般可以將數據緩存到硬盤活內存。
硬盤：批量
內存：隨機
緩存冗餘如何設計？
系統一般由多級緩存構成，數據多層冗餘
舉例：我的足跡
微服務架構緩存一致性如何保證?
任何一次修改保證數據一致性?最終一致性的保證
分佈式事務(DTS)
主從同步
異步消息通知
定向輪詢更新
多次數據修改的一致性?分佈式鎖服務
常用算法
實現方式
Zookeeper實現分佈式鎖服務
zookeeper 樹形結構,解決分佈式一致性的產品。
臨時順序節點
樂觀鎖實現
微服務架構緩存命中率如何保證
案例一：商家中心
最佳實踐-商家中心(300W/分鐘調用)
場景特點決定架構設計
峯值明顯
核心業務要求TP999,SLA 5ms
雙機房雙活 多級監控 動態降級 三級緩存
Redis集羣全量緩存（20ms）+本地Redis 熱點緩存（1小時有效期）（從20ms降到12ms）+應用內JVM緩存（緩存時間1分鐘）（從12ms降到3ms）
部署情況
案例2
最佳實踐-10億海量商品sku存儲
特點：
數據量大
實時性較高
數據比較頻繁
中心訪問量比較大，日均2億，峯值平穩
雙寫（數據庫+緩存），緩存熱點數據無持久化，全文檢索查詢使用solr實現
練習
