一、MySQL集群

1、集群原理

????????MySQL-MMM 是 Master-Master Replication Manager for MySQL（mysql 主主復制管理器）的簡稱。腳本）。MMM 基于 MySQL Replication 做的擴展架構，主要用來監控 mysql 主主復制并做失敗轉移。其原理是將真實數據庫節點的 IP（RIP）映射為虛擬 IP（VIP）集。 mysql-mmm 的監管端會提供多個 虛擬 IP（VIP），包括一個可寫 VIP， 多個可讀 VIP，通過監管的管理，這些 IP 會綁定在可用 mysql 之上，當 某一臺 mysql 宕機時，監管會將 VIP 遷移至其他 mysql。在整個監管過 程中，需要在 mysql 中添加相關授權用戶，以便讓 mysql 可以支持監理機的維護。授權的用戶包括一個 mmm_monitor 用戶和一個 mmm_agent 用戶，如果想使用 mmm 的備份工具則還要添加一個 mmm_tools 用戶。

二、Redis集群

1、集群形式

1.1客戶端分區

????????

????????客戶端分區方案的代表為 Redis Sharding，Redis Sharding 是 Redis Cluster 出來之前，業 界普遍使用的 Redis 多實例集群方法。Java 的 Redis 客戶端驅動庫 Jedis，支持 Redis Sharding 功能，即 ShardedJedis 以及結合緩存池的 ShardedJedisPool。

????????優點

????????不使用第三方中間件，分區邏輯可控，配置簡單，節點之間無關聯，容易線性擴展，靈活性強。

????????缺點

????????客戶端無法動態增刪服務節點，客戶端需要自行維護分發邏輯，客戶端之間無連接共享， 會造成連接浪費。

1.2代理分區

2、高可用方式?

2.1、Sentinel（ 哨兵機制）支持高可用

????????哨兵的作用就是監控 Redis 系統的運行狀況，哨兵機制可解決主從復制的主節點出問題后更新繁瑣的問題，使用集群可解決主節點讀寫能力有限的問題。其功能主要是包括以下三個：

????????監控(Monitoring): 哨兵(sentinel) 會不斷地檢查你的 Master 和 Slave 是否運作正常。

????????提醒(Notification): 當被監控的某個 Redis 出現問題時, 哨兵(sentinel) 可以通過 API 向管理員或者其他應用程序發送通知。

????????自動故障遷移(Automatic failover): 當主數據庫出現故障時自動將從數據庫轉換為主數據庫。

哨兵的原理

????????Redis 哨兵的三個定時任務，Redis 哨兵判定一個 Redis 節點故障不可達主要就是通過三個定 時監控任務來完成的：

? ? ? ? 1、每隔 10 秒每個哨兵節點會向主節點和從節點發送"info replication" 命令來獲取最新的拓撲結構。

? ? ? ? 2、每隔 2 秒每個哨兵節點會向 Redis 節點的_sentinel_:hello 頻道發送自己對主節點是否故 障的判斷以及自身的節點信息，并且其他的哨兵節點也會訂閱這個頻道來了解其他哨兵節點的信息以及對主節點的判斷。

? ? ? ? 3、每隔 1 秒每個哨兵會向主節點、從節點、其他的哨兵節點發送一個 “ping” 命令來做心 跳檢測。

? ? ? ? 如果定時任務3監測不到節點的心跳，會判斷“主觀下線”，如果該節點是主節點那么會通知其他哨兵對該主節點進行心跳檢測，如果主觀下線的票數大于設置值，則認為此主節點故障，成為客觀下線。

????????故障轉移和 Leader 選舉

????????如果主節點被判定為客觀下線之后，就要選取一個哨兵節點來完成后面的故障轉移工作，選 舉出一個 leader，這里面采用的選舉算法為 Raft。選舉出來的哨兵 leader 就要來完成故障轉移工作，也就是在從節點中選出一個節點來當新的主節點。

3、Redis-Cluster

? ? ? ? 官方多機部署方案，。一組 Redis Cluster 是由多個 Redis 實例組成，推薦使用 6 實例，其中 3 個為主節點，3 個為從結點。一旦有主節點發生故障的時候， Redis Cluster 可以選舉出對應的從結點成為新的主節點，繼續對外服務，從而保證服務的高可用性。Redis Cluster 把所有的數據劃分為 16384 個不同的槽位，可以根據機器的性能把不同的槽位分配給不同的 Redis 實例，對于 Redis 實例來說，他們只會存儲部分的 Redis 數據，槽的數據是可以遷移的，不同的實例之間，可以通過一定的協議進行數據遷移。

????????一致性哈希可以很好的解決穩定性問題，可以將所有的存儲節點排列在收尾相接的 Hash 環上，每個 key 在計算 Hash 后會順時針找到臨接的存儲節點存放。而當有節點加入或退出時，僅影響該節點在 Hash 環上順時針相鄰的后續節點。

????????Hash傾斜：如果節點很少，容易出現傾斜，負載不均衡問題。一致性哈希算法，引入了虛擬節點，在整個環上，均衡增加若干個節點。

三、RabbitMQ集群

????????RabbitMQ 集群中節點包括內存節點(RAM)、磁盤節點(Disk，消息持久化)，集群中至少有 一個 Disk 節點。

普通模式(默認)

????????對于普通模式，集群中各節點有相同的隊列結構，但消息只會存在于集群中的一個節點。對于消費者來說，若消息進入 A 節點的 Queue 中，當從 B 節點拉取時，RabbitMQ 會將消息從 A 中取出，并經過 B 發送給消費者。 應用場景：該模式各適合于消息無需持久化的場合，如日志隊列。當隊列非持久化，且 創建該隊列的節點宕機，客戶端才可以重連集群其他節點，并重新創建隊列。若為持久化， 只能等故障節點恢復。

鏡像模式

????????與普通模式不同之處是消息實體會主動在鏡像節點間同步，而不是在取數據時臨時拉取，高可用；該模式下，mirror queue 有一套選舉算法，即 1 個 master、n 個 slaver，生產者、消費者的請求都會轉至 master。