中間件

redis

redis經常使用5種基本類型：string,hash.list,set,zset

HypeLoglog：二進制存儲0,1（存在）容許必定的錯誤率，大概8%（不肯定）。

布隆過濾器：經過多個hash函數到bitmap上，通常用瞭解決緩存穿透問題（大量請求緩存中不存在的數據，去請求數據庫）；緩存雪崩（緩存大量同時失效，去請求數據庫）隨機設置過時時間

redis設置過時時間： 按期刪除（redis默認每隔100ms去隨機掃描設置了過時時間的key,若是過時就進行刪除）和惰性刪除（每次使用以前都去查詢下是否過時，過時進行刪除）

持久化： AOF和RDB

事務： MULTI、EXEC、WATCH ；lua腳本；事務不能回滾，redis最終一致性

淘汰機制：

1.設置過時時間內最少使用的數據
2.全部數據最少使用---經常使用
3.設置過時時間隨機淘汰
4.全部數據隨機淘汰
5.快要過時數據進行淘汰
6。不淘汰,寫入數據報錯，幾乎不用

Zookeeper

數據結構：znode樹形結構,數據存放在內存中，zk能夠實現高吞吐量和低延遲,適合讀多寫少

使用場景：

1.分佈式鎖實現：

2.存儲-znode 元數據（version 當前數據的版本，cversion 上個節點的版本，aversion 當前acl版本）

3.集羣中的註冊中心

三種角色：領導者，追隨者，觀察者（不參加選舉，提供讀的能力，提高集羣的讀性能）

zab協議：保證數據一致性的協議/算法，單調一致性，定義三種節點狀態（觀察者，領導者，追隨者（不參與選舉））

zookeeper選舉過程主要通過三個步驟:
1.選舉
經過各個節點比較最大的事務zxid和節點信息選出準leader
2.發現
發現最大事務zxid和事務日誌,根據事務日誌準leader更新日誌
3.同步
最新事務zxid和事務日誌同步到從節點,當一半肯定同步，準leader變成leader
4.廣播  二階段提交
客戶端寫入請求給任意從節點，從節點將寫入請求轉發給主節點
（1）客戶端發送寫請求,主節點接收寫請求,生成單調遞增的事務id和事務日誌,將事務id和事務日誌同步給從節點,從節點寫入日誌成功後，返回ack消息給主節點
（2）當主節點收到從節點一半的ack消息,主節點返回成功給客戶端，而且發送commit請求給從節點
特色：順序一致性,原子性,單一系統映像,可靠性（更改效果持久化）

Znode：元數據data，子節點引用child，訪問權限ACL,事務id和版本號和時間戳stat;

Znode並非用來存儲大規模業務數據，而用於存儲少許狀態和配置信息

分佈式鎖三種實現方式：3種分佈式鎖

1.數據庫創建惟一索引，同時提交到數據庫，數據庫保證只有一個提交成功，鎖表。
缺點：強依賴性，若是單點數據庫掛了，整個業務系統都沒法使用（主從同步）；鎖沒有失效時間，若是解鎖失敗，致使鎖記錄一直在數據庫中，其餘線程沒法獲取鎖（定時清理過時數據）；鎖非重入，同一個線程未釋放鎖以前沒法再次獲取鎖，由於記錄以及存在（while循環，直到成功獲取鎖）；非阻塞，插入失敗會sql報錯，沒有獲取鎖的隊列不能進入排隊隊列，要想獲取鎖只能再次觸發獲取鎖的操做（在數據庫表中加個字段，記錄當前得到鎖的機器的主機信息和線程信息，那麼下次再獲取鎖的時候先查詢數據庫，若是當前機器的主機信息和線程信息在數據庫能夠查到的話，直接把鎖分配給他就能夠了。）

2.redis  setnx 原子性操做，設置過時時間，分佈式下用redlock

3.zookeeper分佈式鎖
實現的複雜性角度（從低到高）: Zookeeper >= 緩存 > 數據庫
性能角度: 數據庫-> Zookeeper ->緩存
可靠性角度: 數據庫> 緩存 > Zookeeper

消息隊列