一. 大綱
本篇介紹常見數據庫的高可用方案，側重於架構及功能介紹，不涉及詳細原理，主要為了幫助大家對於常見數據庫的高可用方案做個匯總性的了解。
首先我們先了解下高可用方案的常見類型，下面主要從兩個方面來划分。
按底層存儲架構主要划分為兩種：
-
Shared Storage：多個數據庫實例之間共享一份數據存儲，常見分案有Oracle RAC，SQL故障轉移群集 -
Shared Nothing: 每個數據庫實例各自維護一份數據副本，常見分案有MySQL MHA，Oracle ADG，SQL鏡像
按功能實現主要划分為三種：
-
Load balancing(負載均衡)：常見實現方式為讀寫分離，典型方案有讀寫分離中間件，數據源拆分 -
Auto Failover(自動故障轉移)：典型方案有MySQL MHA，SQL鏡像(帶見證服務器)，AlwaysON -
Load balancing & Auto Failover(兩者兼具)：典型方案為Oracle RAC
PS：我目前所在的公司由於項目眾多，環境參差不齊，且性能上基本單實例可以滿足，因此側重於故障轉移，很少有用到負載均衡的方案。
二. MySQL篇
MySQL作為當今最流行的開源數據庫之一，高可用方案可謂五花八門，下面依次介紹！
PS：下述MySQL常見架構中的從庫，一般都可以進行只讀操作，程序上如果進行
數據源拆分基本都可以達到分擔壓力的效果，所以下述中所涉及到的負載更多是意味着該方案能否在不拆分數據源的情況下，依靠方案本身達到負載均衡的目的！同理的話，故障轉移也是，最簡單的主從復制其實就可以實現
手動故障轉移，再配合keepalived(中間件)也可以達到自動故障轉移的功能，所以下述中所涉及到的故障轉移均意味着方案在不借助中間件的情況下可以實現自動故障轉移，且對業務程序透明！
2.1. 主從復制
主從復制是MySQL數據庫使用率非常高的一種技術，它使用某個數據庫服務器為主庫（Master），然后實時在其他數據庫服務器上進行數據復制，后面復制的數據庫也稱從庫（Slave），架構上可以根據業務需求而進行多種變化組合，因此引申出了主主復制，一主多從，多主一從，聯級復制等高可用架構。
主從復制方案主要是通過復制數據達到數據冗余的效果，其本身並不能實現負載，亦或是故障轉移的功能，只能作為最基礎的容災手段！
2.2. MySQL MHA
MHA(Master High Availability)是MySQL高可用方案中是一個相對成熟的解決方案。在主從復制的基礎上，通過Perl腳本實現了一整套MySQL故障切換方案，保障了數據庫的高可用性。
MHA 可以實現故障轉移功能，但並不具備負載的功能。另外需要注意的是，MHA在故障切換后，由於主從架構的變動，需要人工修復確認后，才可再次具備自動故障轉移功能，自身並不具備故障恢復（掛掉的主庫無法自動重新加入集群）功能！
MHA的自動故障轉移主要通過VIP漂浮實現，我們常用的是通過ifconfig命令+腳本實現，當然也可以通過keepalived中間件實現。
2.3. MySQL MGR
MGR(MySQL Group Replication)是MySQL官方於2016年12月（MySQL5.7.17 GA版）推出的一個全新的高可用與高擴展的解決方案。
MGR提供了single-primary和multi-primary兩種模式：
-
single-primary mode(單主模式)即組內只有一個節點負責寫入，讀可以從任意節點讀取，組內數據保持最終一致。
-
multi-primary mode(多主模式)即組內所有節點均可以進行讀寫，同時保證組內數據最終一致性。
MGR方案本身並不具備故障轉移和負載均衡的能力，只有搭配其他第三方中間件后，才可以實現故障轉移及負載均衡。
MGR具有故障恢復的能力，所謂故障恢復指的是主庫掛掉后，擁有重新選舉主庫的能力，並且當老的主庫恢復后，可以自動重新加入集群，而不需要人工修復。
PS：由於MGR目前功能並不完整，主要是官方尚未推出故障轉移和負載均衡的對應解決方案，導致還需要其他第三方中間件配合實現，比較繁瑣且復雜，所以公司目前主要還是采用MHA作為MySQL高可用方案，相信MGR會是今后MySQL最主流的高可用方案！
2.4. MySQL NDB Cluster
MNC(MySQL NDB Cluster)是MySQL官方從5.0 版本開始推出的一個分布式集群方案，主要通過使用NDB存儲引擎實時備份冗余數據，實現數據庫的高可用性和數據一致性。
NDB Cluster僅支持NDB存儲引擎，與MySQL常規引擎(InnoDB)存在一定差異，且配置較復雜，基本很少使用，這里僅作介紹了解。
2.5. MySQL Galera Cluster
這部分主要介紹兩款基於
Galera Cluster的集群方案，其一是MariaDB Galera Cluster，其二是Percona XtraDB Cluster，這2個集群方案均由MySQL分支實現，非官方實現。
Galera Cluster 是Codership公司開發的一套免費開源的MySQL多主同步集群方案，而MariaDB與Percona是MySQL的2個分支。
MGC(MariaDB Galera Cluster)是MariaDB在Galera基礎上推出的高可用集群方案。
PXC(Percona XtraDB Cluster)是Percona在Galera基礎上推出的高可用集群方案。
MGR其實也是MySQL官方借鑒Galera后重新實現的一套集群方案，所以這3個集群方案架構與功能上都比較類似。
由於PXC和MGC均是由MySQL分支實現，與MGR一樣需要配合中間件才可以實現透明切換與負載均衡，並且依賴於其他開源組件版本的穩定性與功能，因此個人不推薦使用，這里僅作介紹了解。
2.6. MySQL InnoDB Cluster
MIC(MySQL InnoDB Cluster) 是MySQL官方在2017年4月推出了一套完整的、高可用的解決方案，。
MIC主要由三部分組成，分別是：MySQL Shell、MySQL Router、MySQL Group Replication(MGR)。
-
MySQL Shell：通過內置的管理API創建及管理Innodb集群。
-
MySQL Router：路由轉發中間件，提供透明切換與讀寫分離能力。
-
MySQL Group Replication：底層的數據同步集群(MGR)，提供容錯、故障恢復與彈性擴展。
這里需要說明的是MySQL Router的讀寫分離並非對應用透明，而是通過划分讀寫端口(6446)與 只讀端口(6447)來轉發不同的請求實現讀寫分離，本質還是需要程序端根據業務類型重新定義數據源才可以實現。
MIC是MySQL官方嘗試在不依賴於第三方中間件的情況下，推出的一個功能比較完整的高可用方案，個人感覺還是不錯的，起碼官方開始嘗試了，期待未來進一步的改進完善！
2.7. MySQL 中間件
除了上述這些常見高可用架構外，MySQL中還存在大量中間件產品，常用於實現
讀寫分離、故障轉移、數據分片等功能，下面簡單介紹下常見的中間件。
常見的MySQL中間件實現讀寫分離的原理如下圖所示，通過在Web與DB之間架設代理，將讀寫流量區分后，路由至不同的后端數據庫處理，以此達到讀寫分離的效果，實現負載均衡。
中間件代理識別讀寫流量的工作原理常分為以下幾類：
-
事務區分：顯式事務（start transaction或autocommit=0）識別為讀寫請求，轉發到主庫；隱式事務識別為只讀請求，轉發到從庫。 -
HINT區分：通過自定義的HINT語法區分SQL類型，代理會根據SQL中是否含有該HINT來進行轉發，如DRDS中的讀寫分離HINT語法為/!TDDL:MASTER|SLAVE*/。 -
端口區分：通過端口定義讀寫請求與只讀請求，需要改造數據源配置，如MySQL Router。 -
賬號區分：讀寫賬號識別為讀寫請求，只讀賬號識別為只讀請求，本質上和端口區別一樣，都需要改造數據源配置。
PS：讀寫分離在實現上很少會以SQL為界限區分讀SQL與寫SQL，更多的是以事務為界限區分讀寫事務與只讀事務！道理很簡單，如果一個事務中的讀寫SQL也進行區分的話，那么就會變成分布式事務，性能上會大打折扣，且需要一系列手段來保證分布式事務的ACID特性！
官方中間件
-
MySQL Proxy (不再維護)
-
MySQL Proxy是官方最早提供的中間件，現已被MySQL Router更迭取代。
-
-
MySQL Router
-
MySQL官方提供的一個輕量級中間件，用於替代MySQL Proxy。
-
第三方開源中間件
-
Atlas (停止更新)
-
Atlas是由Qihoo360 基於
MySQL-Proxy開發維護的一個MySQL開源中間件。
-
-
MyCAT
-
MyCAT是社區基於
阿里Cobar二次開發的開源中間件。
-
-
DBLE-
DBLE是上海愛可生公司在
MyCAT的基礎上進一步優化開發的分布式開源中間件。
-
-
Cetus-
Cetus是網易基於C語言開發的MySQL開源中間件，分為讀寫分離和分庫分表兩個版本。
-
-
MaxScale-
MariaDB官方研發的中間件產品，支持讀寫分離與分庫分表。
-
-
Sharding-Proxy
-
Sharding-Proxy是Apache ShardingSphere的第二個產品， 定位為透明化的數據庫代理端，可以實現讀寫分離與數據分片。
-
-
ProxySQL
-
ProxySQL是一個基於C++開發的高性能輕量級的MySQL中間件。
-
個人比較傾向於MaxScale、Cetus與DBLE三款中間件產品。
2.8. 雲數據庫
所謂雲數據庫就是一種穩定可靠的
在線數據庫服務，常見的公有雲數據庫產品有以下幾種。
-
阿里雲：DRDS
-
DRDS 是一款基於 MySQL 存儲、采用分庫分表技術進行水平擴展的分布式 OLTP 數據庫服務產品，支持
RDS for MySQL以及POLARDB for MySQL。
-
-
騰訊雲：TDSQL
-
TDSQL是部署在騰訊公有雲上的一種支持自動水平拆分的share nothing架構的分布式數據庫。
-
-
華為雲：TaurusDB
-
TaurusDB是華為基於
新一代DFV存儲與計算存儲分離架構自研的新一代企業級高擴展海量存儲分布式數據庫。
-
-
UCloud：UDDB
-
UDDB是基於公有雲構建的新一代分布式數據庫，為用戶提供穩定、可靠、容量和服務能力可彈性伸縮的關系型數據庫服務。
-
上述幾類雲數據庫是不同廠商基於MySQL改造或是自研的分布式數據庫，完全兼容MySQL，並且在架構上實現了故障轉移、讀寫分離、數據分片、水平擴展等配套功能。
雲數據庫優勢：不需要關心后端的數據庫架構及存儲，可以專注於業務開發。
雲數據庫劣勢：隱私安全問題、數據意外丟失風險、定制化服務不足。
2.9. NewSQL
最后
拓展介紹下NewSQL，NewSQL是一種新型的分布式數據庫，其最大的特點就是融合了RDBMS與NoSQL的特長，兼具OLTP與OLAP場景，且擁有高度可擴展性及可用性，但是對硬件與網絡環境要求非常高。
-
TiDB
-
國內 PingCAP 團隊開發的一個分布式 NewSQL 數據庫，PingCAP是國內一家專注於開源NewSQL領域的團隊。
-
-
OceanBase
-
OceanBase 是螞蟻金服自研的金融級分布式關系數據庫。
-
-
SequoiaDB（巨杉數據庫）
-
廣州巨杉軟件開發有限公司開發的新一代分布式NewSQL數據庫 。
-
上述三款是國內比較火的NewSQL開源項目，都是國內團隊開發的，且已在金融級領域應用實踐，效果非常牛。
三. Oracle篇
眾所周知，Oracle是全世界RDBMS數據庫的龍頭老大，長期占據
DB-Engines天梯榜top 1，可見其受歡迎程度。Oracle提供了多種數據庫部署架構，其中RAC以及ADG是OLTP應用廠商使用最廣泛的方案，因為其開發早，軟件成熟、用戶使用廣，文檔資料齊全，深受廣大DBA工程師的青睞。
3.1. Oracle RAC
Oracle RAC全稱Oracle Real Application Cluster，是一種具有共享緩存架構的數據庫集群，它克服了多實例之間同時讀寫共享存儲的限制，為業務應用提供了一種具有高度可擴展性和可用性的數據庫解決方案，常用於Oracle9i、10g、11g，12C及以上。
ORACLE RAC通過在每個節點安裝集群軟件grid infrastructure以及心跳網絡互連之后，可將多台物理服務器組成數據庫集群，多個數據庫實例之間可以同時讀寫數據庫，避免節點單點故障造成業務中斷。
ORACLE RAC的特點：
-
實現自動故障轉移
-
當有故障節點出現時，業務會自動切換到剩余存活節點上，保證業務對外服務不間斷，這對於終端用戶來說是無感知的。
-
-
實現負載均衡
-
RAC集群通常由2到3台甚至多台物理服務器組成，在集群軟件的管理之下，可以自動將客戶端請求平均分擔到各個節點上。
-
-
具有良好的擴展性
-
RAC集群可以通過增加節點個數，提高集群的整體性能，滿足日益增長的數據訪問需求。
-
ORACLE RAC唯一的缺陷就是缺少冗余副本，存在磁盤單點故障的隱患，除此之外，Oracle RAC基本無懈可擊！
3.2. Oracle ADG
ADG(Oracle Active Data Guard)是Oracle下的主從復制，同樣由主庫和備庫組成，兩者通過日志同步機制保證數據同步。
ADG架構上可以實現1：1或是1：N的主備架構，所有備庫均可以是只讀副本，且擁有獨立數據副本。
與RAC相比，ADG自身無法實現自動故障轉移與自動負載均衡，其唯一的優勢就是擁有多個數據副本，可以有效避免磁盤單點故障，並且其副本可讀，也可以配合拆分數據源起到分擔主庫壓力的效果！
3.3. Oracle OGG
OGG(Oracle GoldenGateOGG)是Oracle下一個實現異構 IT 環境間數據實時集成和復制的工具，類似於公司的數據交換平台，主要用於數據實時同步，並且支持各類常見數據庫之間的數據轉換復制。
OGG其實並不算一種HA方案，這里只是正好順帶介紹下，需要注意的是，OGG要在購買Oracle企業版授權后額外付費才可以使用，而RAC與ADG是購買企業版授權后就可以免費使用，這也是OGG正式項目上用的很少的原因。
3.4. Oracle RAC+ADG
RAC+ADG是Oracle下的經典架構，其中RAC提供了高可用，ADG提供了高可靠，兩者結合在一起，取長補短，堅若磐石，適用於對業務需要7x24H不宕機的項目環境。
RAC+ADG兼顧了自動故障轉移與負載均衡，且由於其有多份數據副本，也規避了磁盤單點故障的隱患，堪稱無敵。
這種架構常用於Oracle異地容災的高可用解決方案中，其中Secondary Site可以只是單實例即可，並不需要同樣也是RAC。
3.5. 其他高可用方案
除了上述幾種高可用架構之外，還有其他非常規的架構部署，下面僅做簡單介紹。
-
Oracle HA+Keepalived
使用Keepalived實現集群，正常情況下由主服務器提供服務，備服務器處於待機備用，當主服務器故障時無法對外提供服務，備用服務器會替代主服務器對外繼續提供服務，原本指向主服務器上的服務資源包括網絡、存儲等服務就會轉移到備機接管，從而提供不間斷的服務，通俗來講可視為“低配版RAC”。
-
Oracle MAA
MAA(Oracle Maximum Availability Architecture)是Oracle最高可用的技術集合，是將RAC、DataGuard、flashback、RMAN、ASM、GoldenGate等一系列打包，完全利用Oracle各項”黑科技“，數據庫宕機，數據刪除都不怕，使數據庫無堅不摧，堪稱數據庫的金鍾罩。
四. SQL Server篇
自從SQL Server 2005以來，微軟就提供了多種高可用性技術來減少宕機時間和增加對業務數據的保護，而隨着SQL Server 2008，SQL Server 2008 R2，SQL Server 2012等新版本的不斷發布，SQL Server中已經存在了滿足不同場景的多種高可用性技術，下面依次介紹。
3.1. 鏡像
鏡像(Mirroring)是 SQL Server 下最常用的高可用解決方案，是一種數據庫級的高可用方案。
鏡像中我們將生產庫稱為主體庫(讀寫能力)，而備用庫稱之為鏡像庫(無法打開)，兩者通過日志流保持實時數據同步。
鏡像在配置了見證服務器+failoverPartner的情況下，可以實現自動故障轉移。原理與之前的VIP漂浮不同，而是在驅動層實現故障轉移，當連接數據庫時，會檢測連接是否正常，從而自動切換到鏡像庫IP。
由於鏡像庫默認是無法打開的，除非在故障切換后才可以打開，所以無法通過鏡像庫來實現讀寫分離。
另外鏡像具有故障恢復功能，宕掉的主體庫在起來后，可以自動轉換為鏡像庫，自動故障轉移再次可用！這點在我看來，是非常實用的，和MHA形成了鮮明的對比！
3.2. 復制
復制(Replication)是將一組數據從一個數據源拷貝到多個數據源的技術，提供了數據庫對象級別的保護。
復制使用的是發布-分發-訂閱模式，即由發布服務器向分發服務器發布數據，再由分發服務器向訂閱服務器分發數據完成同步。
復制常用於實現表級的數據同步或數據容災，與其他實例級或數據庫級的高可用方案相比，更加靈活多變！
復制無法實現自動故障轉移，但是其訂閱副本可以進行只讀查詢，因此可以配合拆分數據源達到分擔壓力的效果，或是作為數據副本共享給第三方使用！
3.3. 日志傳送
日志傳送(Log Shipping)與鏡像類似，同樣是一種數據庫級的高可用方案。
日志傳送通過不間斷地備份主數據庫中的事務日志，然后將它們復制並還原到輔助數據庫，使輔助數據庫與主數據庫基本保持同步。
日志傳送無法實現自動故障轉移，只能進行手動故障轉移，而且由於數據同步方式並非完全同步，所以容易出現數據丟失！
日志傳送與復制一樣可以實現多副本且副本可讀(間接性)，卻無法像復制一樣可以具體到表級同步；與鏡像一樣是數據庫級的高可用方案，卻無法實現數據完全同步與自動故障轉移。
日志傳送更像是一種介於復制與鏡像之間的替代方案，目前很少有場景會用到它。
3.4. 快照
快照(snapshot)是SQL Server 2005中發布的一個新技術，可以創建某數據庫在某一時間點的只讀副本，並且源庫可以通過快照快速還原至該時間點，與虛擬機快照的功能類似！
與備份數據庫不同，快照並不需要復制源庫的所有數據頁，僅需要復制在快照建立之后所更新的數據頁，還原數據庫時也僅需要將快照建立之后更新的數據頁恢復至源庫，因此快照的速度會遠快於備份與還原！
快照技術常用於實現維護歷史數據以生成報表，數據比對，數據快速恢復。
快照技術的缺點也非常明顯，由於每次更新原始頁時都會對快照執行寫入復制操作，導致源數據庫上的 I/O 增加，影響數據庫性能！
嚴格來說，快照只能作為一種技術，而非高可用解決方案，仔細想想，這玩意不就是加強版的備份還原么！目前很少有場景會用到它。
3.5. 故障轉移群集
故障轉移群集(FCI)是利用Windows Server故障轉移群集(WSFC)功能實現自動故障轉移的一種實例級高可用方案，其特點是各實例節點之間共享存儲。
WSFC是Windows Server自帶的一種底層的故障轉移方案，包括健康檢查、資源管理、分布式元數據通知維護以及故障轉移，FCI與AlwaysOn都依賴其實現高可用，但是需要額外配置AD(域控)作為基礎。
故障轉移群集是一種配置較為復雜且維護有一定難度的高可用方案，可以實現自動故障轉移，但是無法提供可讀副本。
故障轉移群集更像是AlwaysOn可用組的前身，在過去很長時間都是SQL Server的常用高可用技術，但在AlwaysOn可用組出現后，就基本替代了這種高可用方案！
3.6. AlwaysOn可用組
SQL Server 2012 開始引入了AlwaysOn可用組(AlwaysOn Availability Groups 簡稱AG)作為代替數據庫鏡像的新型高可用方案，其集中了故障轉移群集、數據庫鏡像和日志傳送三者的優點，但又不相同。
AG支持的單位是可用性組，每個組中可以包括一個或者是多個數據庫，一旦發生切換，則可用性組中的所有數據庫會作為一個整體進行故障切換。
AG底層依然采用WSFC進行監測和轉移，從Windows server 2016之后開始支持無域控，因此搭建簡便很多。
vs 故障轉移群集：不再是共享存儲，可以有效防止磁盤單點故障。
vs 鏡像：可以擁有多個副本，且副本可讀。
vs 日志傳送：可以實現自動故障轉移，且可以實現數據完全同步，做到數據0丟失。
AlwaysOn可用組作為SQL Server新一代的高可用方案，各方面都有很大的改進，因此個人還是很推薦使用的！
最后上一張SQL Server 下各官方高可用方案的對比圖，大家可以參考下！
3.7. 第三方雙機熱備軟件
除了上述這些官方發布的高可用方案之外，SQL Server下還存在一些第三方的高可用產品，也就是我們俗稱的雙機熱備軟件！
這些雙機熱備產品大多是山寨了官方的鏡像、故障轉移群集等高可用解決方案，功能都是以實現自動故障轉移為主，而未實現負載均衡，且都是需要收費的，所以個人並不是很推薦。
SQL Server常見雙機熱備軟件如下：
-
RoseHA
美國Rose數據公司的產品，基於共享存儲與RoseHA軟件系統實現了自動故障轉移，與故障轉移群集非常相像！
-
RoseMirrorHA
美國Rose數據公司的另一種產品，基於文件系統，通過數據實時鏡像技術同步主備之間的差異數據，同樣可以實現自動故障轉移，與鏡像非常類似！
-
Lifekeeper
美國SteelEye公司的產品，架構和功能上基本與RoseHA如出一轍，可以當作是RoseHA的翻版。
五. MongoDB篇
MongoDB作為
非關系型數據庫(NoSQL)的典型，廣泛應用於分布式文件存儲，其復制集和分片的功能，可以作為WEB應用提高可擴展性的高性能數據存儲解決方案之一。
5.1. 復制集
復制集是由一組mongod實例組成的集群，其中一個節點為主節點(Primary)，其余節點都是從節點(Secondary)，主從節點之間通過oplog保持數據同步。
復制集可以同時實現自動故障轉移與負載均衡功能。
其自動故障轉移的原理與SQL鏡像類似，都是在驅動層實現，只要保證半數以上節點存活，整個復制集就可以對外提供服務。
負載均衡的原理是實現了讀寫分離，其讀寫分離也是通過驅動層實現，簡而言之，就是在驅動層識別SQL為寫SQL或是讀SQL，然后選擇轉發到主節點或是從節點。
之所以MongoDB選擇在SQL層實現讀寫分離，是因為NoSQL里沒有事務的概念，也就不會有分布式事務的概念。
5.2. 分片
分片(sharding)是MongoDB下通過分片技術從而進行水平擴展，用以支撐海量數據集和高吞吐量的方案。
分片技術指按照某個維度將存放在單一數據庫中的數據分散存放至多個數據庫或數據表中以達到提升性能與可用性的一種優化技術，該技術常應用在分布式數據庫架構中。
5.3. 分片集群
如Oracle下RAC+DG一樣，多個方案之間互補，形成更強的數據庫架構一樣，分片集群即是MongoDB下復制集+分片組合而成的一種高可用方案。
-
mongos：數據庫集群請求的入口，路由轉發的作用。
-
shard：將表數據拆分后形成的分片，同一分片冗余在不同節點中。
-
config server：存儲所有數據庫元信息（路由、分片）的配置。
-
仲裁：充當一個MongoDB實例，但不保存數據，主要用於集群投票。
分片集群同樣可實現透明切換與負載均衡，其中復制集可以提供高可用，而分片可以提供高性能與高吞吐量。
六. Redis篇
Redis是一個開源的高性能key-value數據庫，是NoSQL的典型代表之一。
6.1. Redis 多副本
Redis多副本，采用主從(replication) 部署結構，與MySQL主從復制如出一轍。
Redis多副本不支持自動故障轉移與負載功能，其從庫只讀，可以承擔只讀流量。
RedisHA過程可以自己開發對應的切換功能，或是由keepalived替代實現透明切換。
6.2. Redis Sentinel
Redis Sentinel(哨兵)是Redis官方推出的高可用性解決方案，包含若干個Sentinel節點和Redis數據節點，每個Sentinel節點會對數據節點和其余Sentinel節點進行監控。
Redis Sentinel可以實現自動故障轉移，但不能實現負載，其實現原理類似於MySQL MHA，但是比MHA好的地方在於存在多個監控節點(Sentinel)，可以有效防止單點故障。
6.3. Redis Cluster
Redis Cluster是Redis官方推出的分布式集群解決方案，其主要通過分布式架構解決了單節點Redis性能瓶頸的問題，可以理解為Redis下分片技術的實現。
Redis Cluster中數據以哈希槽(slot)的形式，分布在不同的節點上，每個節點又采用了主從模式，防止單節點故障。
Redis Cluster中的一個重要概念便是去中心化，即每個節點都可以提供讀寫服務，類似於MySQL MGR中的多主模式。
Redis Cluster可以實現自動故障轉移與負載均衡，均是在驅動層實現。
七. 寫在最后
【科普】系列文章目前已發布2篇文章，主要內容為總結整理數據庫方面的常用知識，面向群體為公司開發與實施，希望以此來增加公司人員對於數據庫的知識網絡，更好的在項目上使用與管理好數據庫。
如果你有什么好的課題的話，歡迎留言，我們會考慮加入到此系列中！