"可以采用開源的MyCat解決方案，優(yōu)點(diǎn)是免費(fèi)，缺點(diǎn)是出現(xiàn)問題可能要自己解決或者去社區(qū)尋找解決方案；
創(chuàng)新互聯(lián)是一家專業(yè)提供壽縣企業(yè)網(wǎng)站建設(shè),專注與成都做網(wǎng)站、網(wǎng)站設(shè)計(jì)、HTML5、小程序制作等業(yè)務(wù)。10年已為壽縣眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)站建設(shè)公司優(yōu)惠進(jìn)行中。
也可以采用北京萬里開源軟件有限公司的集群解決方案，后端使用開源的MySQL存儲數(shù)據(jù)，優(yōu)點(diǎn)是有任何問題他們都可以幫忙解決，而且不用擔(dān)心系統(tǒng)后續(xù)的擴(kuò)展、集群高可用等情況，他們的工程師還開發(fā)過MySQL核心代碼，找他們可以睡個安穩(wěn)覺，缺點(diǎn)是不免費(fèi)，他們還有自己的國產(chǎn)數(shù)據(jù)庫GreatDB，100%兼容MySQL。
對于初創(chuàng)企業(yè)，可以考慮選擇免費(fèi)的開源解決方案，畢竟遇到的問題可能有限，如果要想長期穩(wěn)定發(fā)展，還是選擇萬里開源這樣的公司比較靠譜一些。"
1. 概述
我們在考慮MySQL數(shù)據(jù)庫的高可用的架構(gòu)時，主要要考慮如下幾方面：
如果數(shù)據(jù)庫發(fā)生了宕機(jī)或者意外中斷等故障，能盡快恢復(fù)數(shù)據(jù)庫的可用性，盡可能的減少停機(jī)時間，保證業(yè)務(wù)不會因?yàn)閿?shù)據(jù)庫的故障而中斷。
用作備份、只讀副本等功能的非主節(jié)點(diǎn)的數(shù)據(jù)應(yīng)該和主節(jié)點(diǎn)的數(shù)據(jù)實(shí)時或者最終保持一致。
當(dāng)業(yè)務(wù)發(fā)生數(shù)據(jù)庫切換時，切換前后的數(shù)據(jù)庫內(nèi)容應(yīng)當(dāng)一致，不會因?yàn)閿?shù)據(jù)缺失或者數(shù)據(jù)不一致而影響業(yè)務(wù)。
關(guān)于對高可用的分級在這里我們不做詳細(xì)的討論，這里只討論常用高可用方案的優(yōu)缺點(diǎn)以及高可用方案的選型。
2. 高可用方案
2.1. 主從或主主半同步復(fù)制
使用雙節(jié)點(diǎn)數(shù)據(jù)庫，搭建單向或者雙向的半同步復(fù)制。在5.7以后的版本中，由于lossless replication、logical多線程復(fù)制等一些列新特性的引入，使得MySQL原生半同步復(fù)制更加可靠。
常見架構(gòu)如下：
通常會和proxy、keepalived等第三方軟件同時使用，即可以用來監(jiān)控?cái)?shù)據(jù)庫的 健康 ，又可以執(zhí)行一系列管理命令。如果主庫發(fā)生故障，切換到備庫后仍然可以繼續(xù)使用數(shù)據(jù)庫。
優(yōu)點(diǎn)：
架構(gòu)比較簡單，使用原生半同步復(fù)制作為數(shù)據(jù)同步的依據(jù)；
雙節(jié)點(diǎn)，沒有主機(jī)宕機(jī)后的選主問題，直接切換即可；
雙節(jié)點(diǎn)，需求資源少，部署簡單；
缺點(diǎn)：
完全依賴于半同步復(fù)制，如果半同步復(fù)制退化為異步復(fù)制，數(shù)據(jù)一致性無法得到保證；
需要額外考慮haproxy、keepalived的高可用機(jī)制。
2.2. 半同步復(fù)制優(yōu)化
半同步復(fù)制機(jī)制是可靠的。如果半同步復(fù)制一直是生效的，那么便可以認(rèn)為數(shù)據(jù)是一致的。但是由于網(wǎng)絡(luò)波動等一些客觀原因，導(dǎo)致半同步復(fù)制發(fā)生超時而切換為異步復(fù)制，那么這時便不能保證數(shù)據(jù)的一致性。所以盡可能的保證半同步復(fù)制，便可提高數(shù)據(jù)的一致性。
該方案同樣使用雙節(jié)點(diǎn)架構(gòu)，但是在原有半同復(fù)制的基礎(chǔ)上做了功能上的優(yōu)化，使半同步復(fù)制的機(jī)制變得更加可靠。
可參考的優(yōu)化方案如下：
2.2.1. 雙通道復(fù)制
半同步復(fù)制由于發(fā)生超時后，復(fù)制斷開，當(dāng)再次建立起復(fù)制時，同時建立兩條通道，其中一條半同步復(fù)制通道從當(dāng)前位置開始復(fù)制，保證從機(jī)知道當(dāng)前主機(jī)執(zhí)行的進(jìn)度。另外一條異步復(fù)制通道開始追補(bǔ)從機(jī)落后的數(shù)據(jù)。當(dāng)異步復(fù)制通道追趕到半同步復(fù)制的起始位置時，恢復(fù)半同步復(fù)制。
2.2.2. binlog文件服務(wù)器
搭建兩條半同步復(fù)制通道，其中連接文件服務(wù)器的半同步通道正常情況下不啟用，當(dāng)主從的半同步復(fù)制發(fā)生網(wǎng)絡(luò)問題退化后，啟動與文件服務(wù)器的半同步復(fù)制通道。當(dāng)主從半同步復(fù)制恢復(fù)后，關(guān)閉與文件服務(wù)器的半同步復(fù)制通道。
優(yōu)點(diǎn)：
雙節(jié)點(diǎn)，需求資源少，部署簡單；
架構(gòu)簡單，沒有選主的問題，直接切換即可;
相比于原生復(fù)制，優(yōu)化后的半同步復(fù)制更能保證數(shù)據(jù)的一致性。
缺點(diǎn)：
需要修改內(nèi)核源碼或者使用mysql通信協(xié)議。需要對源碼有一定的了解，并能做一定程度的二次開發(fā)。
依舊依賴于半同步復(fù)制，沒有從根本上解決數(shù)據(jù)一致性問題。
2.3. 高可用架構(gòu)優(yōu)化
將雙節(jié)點(diǎn)數(shù)據(jù)庫擴(kuò)展到多節(jié)點(diǎn)數(shù)據(jù)庫，或者多節(jié)點(diǎn)數(shù)據(jù)庫集群?？梢愿鶕?jù)自己的需要選擇一主兩從、一主多從或者多主多從的集群。
由于半同步復(fù)制，存在接收到一個從機(jī)的成功應(yīng)答即認(rèn)為半同步復(fù)制成功的特性，所以多從半同步復(fù)制的可靠性要優(yōu)于單從半同步復(fù)制的可靠性。并且多節(jié)點(diǎn)同時宕機(jī)的幾率也要小于單節(jié)點(diǎn)宕機(jī)的幾率，所以多節(jié)點(diǎn)架構(gòu)在一定程度上可以認(rèn)為高可用性是好于雙節(jié)點(diǎn)架構(gòu)。
但是由于數(shù)據(jù)庫數(shù)量較多，所以需要數(shù)據(jù)庫管理軟件來保證數(shù)據(jù)庫的可維護(hù)性?？梢赃x擇MMM、MHA或者各個版本的proxy等等。常見方案如下：
2.3.1. MHA+多節(jié)點(diǎn)集群
MHA Manager會定時探測集群中的master節(jié)點(diǎn)，當(dāng)master出現(xiàn)故障時，它可以自動將最新數(shù)據(jù)的slave提升為新的master，然后將所有其他的slave重新指向新的master，整個故障轉(zhuǎn)移過程對應(yīng)用程序完全透明。
MHA Node運(yùn)行在每臺MySQL服務(wù)器上，主要作用是切換時處理二進(jìn)制日志，確保切換盡量少丟數(shù)據(jù)。
MHA也可以擴(kuò)展到如下的多節(jié)點(diǎn)集群：
優(yōu)點(diǎn)：
可以進(jìn)行故障的自動檢測和轉(zhuǎn)移;
可擴(kuò)展性較好，可以根據(jù)需要擴(kuò)展MySQL的節(jié)點(diǎn)數(shù)量和結(jié)構(gòu);
相比于雙節(jié)點(diǎn)的MySQL復(fù)制，三節(jié)點(diǎn)/多節(jié)點(diǎn)的MySQL發(fā)生不可用的概率更低
缺點(diǎn)：
至少需要三節(jié)點(diǎn)，相對于雙節(jié)點(diǎn)需要更多的資源;
邏輯較為復(fù)雜，發(fā)生故障后排查問題，定位問題更加困難;
數(shù)據(jù)一致性仍然靠原生半同步復(fù)制保證，仍然存在數(shù)據(jù)不一致的風(fēng)險;
可能因?yàn)榫W(wǎng)絡(luò)分區(qū)發(fā)生腦裂現(xiàn)象;
2.3.2. zookeeper+proxy
Zookeeper使用分布式算法保證集群數(shù)據(jù)的一致性，使用zookeeper可以有效的保證proxy的高可用性，可以較好的避免網(wǎng)絡(luò)分區(qū)現(xiàn)象的產(chǎn)生。
優(yōu)點(diǎn)：
較好的保證了整個系統(tǒng)的高可用性，包括proxy、MySQL;
擴(kuò)展性較好，可以擴(kuò)展為大規(guī)模集群;
缺點(diǎn)：
數(shù)據(jù)一致性仍然依賴于原生的mysql半同步復(fù)制;
引入zk，整個系統(tǒng)的邏輯變得更加復(fù)雜;
2.4. 共享存儲
共享存儲實(shí)現(xiàn)了數(shù)據(jù)庫服務(wù)器和存儲設(shè)備的解耦，不同數(shù)據(jù)庫之間的數(shù)據(jù)同步不再依賴于MySQL的原生復(fù)制功能，而是通過磁盤數(shù)據(jù)同步的手段，來保證數(shù)據(jù)的一致性。
2.4.1. SAN共享儲存
SAN的概念是允許存儲設(shè)備和處理器（服務(wù)器）之間建立直接的高速網(wǎng)絡(luò)（與LAN相比）連接，通過這種連接實(shí)現(xiàn)數(shù)據(jù)的集中式存儲。常用架構(gòu)如下：
使用共享存儲時，MySQL服務(wù)器能夠正常掛載文件系統(tǒng)并操作，如果主庫發(fā)生宕機(jī)，備庫可以掛載相同的文件系統(tǒng)，保證主庫和備庫使用相同的數(shù)據(jù)。
優(yōu)點(diǎn)：
兩節(jié)點(diǎn)即可，部署簡單，切換邏輯簡單；
很好的保證數(shù)據(jù)的強(qiáng)一致性；
不會因?yàn)镸ySQL的邏輯錯誤發(fā)生數(shù)據(jù)不一致的情況；
缺點(diǎn)：
需要考慮共享存儲的高可用；
價格昂貴；
2.4.2. DRBD磁盤復(fù)制
DRBD是一種基于軟件、基于網(wǎng)絡(luò)的塊復(fù)制存儲解決方案，主要用于對服務(wù)器之間的磁盤、分區(qū)、邏輯卷等進(jìn)行數(shù)據(jù)鏡像，當(dāng)用戶將數(shù)據(jù)寫入本地磁盤時，還會將數(shù)據(jù)發(fā)送到網(wǎng)絡(luò)中另一臺主機(jī)的磁盤上，這樣的本地主機(jī)(主節(jié)點(diǎn))與遠(yuǎn)程主機(jī)(備節(jié)點(diǎn))的數(shù)據(jù)就可以保證實(shí)時同步。常用架構(gòu)如下：
當(dāng)本地主機(jī)出現(xiàn)問題，遠(yuǎn)程主機(jī)上還保留著一份相同的數(shù)據(jù)，可以繼續(xù)使用，保證了數(shù)據(jù)的安全。
DRBD是linux內(nèi)核模塊實(shí)現(xiàn)的快級別的同步復(fù)制技術(shù)，可以與SAN達(dá)到相同的共享存儲效果。
優(yōu)點(diǎn)：
兩節(jié)點(diǎn)即可，部署簡單，切換邏輯簡單；
相比于SAN儲存網(wǎng)絡(luò)，價格低廉；
保證數(shù)據(jù)的強(qiáng)一致性；
缺點(diǎn)：
對io性能影響較大；
從庫不提供讀操作；
2.5. 分布式協(xié)議
分布式協(xié)議可以很好解決數(shù)據(jù)一致性問題。比較常見的方案如下：
2.5.1. MySQL cluster
MySQL cluster是官方集群的部署方案，通過使用NDB存儲引擎實(shí)時備份冗余數(shù)據(jù)，實(shí)現(xiàn)數(shù)據(jù)庫的高可用性和數(shù)據(jù)一致性。
優(yōu)點(diǎn)：
全部使用官方組件，不依賴于第三方軟件；
可以實(shí)現(xiàn)數(shù)據(jù)的強(qiáng)一致性；
缺點(diǎn)：
國內(nèi)使用的較少；
配置較復(fù)雜，需要使用NDB儲存引擎，與MySQL常規(guī)引擎存在一定差異；
至少三節(jié)點(diǎn)；
2.5.2. Galera
基于Galera的MySQL高可用集群， 是多主數(shù)據(jù)同步的MySQL集群解決方案，使用簡單，沒有單點(diǎn)故障，可用性高。常見架構(gòu)如下：
優(yōu)點(diǎn)：
多主寫入，無延遲復(fù)制，能保證數(shù)據(jù)強(qiáng)一致性；
有成熟的社區(qū)，有互聯(lián)網(wǎng)公司在大規(guī)模的使用；
自動故障轉(zhuǎn)移，自動添加、剔除節(jié)點(diǎn)；
缺點(diǎn)：
需要為原生MySQL節(jié)點(diǎn)打wsrep補(bǔ)丁
只支持innodb儲存引擎
至少三節(jié)點(diǎn)；
2.5.3. POAXS
Paxos 算法解決的問題是一個分布式系統(tǒng)如何就某個值（決議）達(dá)成一致。這個算法被認(rèn)為是同類算法中最有效的。Paxos與MySQL相結(jié)合可以實(shí)現(xiàn)在分布式的MySQL數(shù)據(jù)的強(qiáng)一致性。常見架構(gòu)如下：
優(yōu)點(diǎn)：
多主寫入，無延遲復(fù)制，能保證數(shù)據(jù)強(qiáng)一致性；
有成熟理論基礎(chǔ)；
自動故障轉(zhuǎn)移，自動添加、剔除節(jié)點(diǎn)；
缺點(diǎn)：
只支持innodb儲存引擎
至少三節(jié)點(diǎn)；
3. 總結(jié)
隨著人們對數(shù)據(jù)一致性的要求不斷的提高，越來越多的方法被嘗試用來解決分布式數(shù)據(jù)一致性的問題，如MySQL自身的優(yōu)化、MySQL集群架構(gòu)的優(yōu)化、Paxos、Raft、2PC算法的引入等等。
而使用分布式算法用來解決MySQL數(shù)據(jù)庫數(shù)據(jù)一致性的問題的方法，也越來越被人們所接受，一系列成熟的產(chǎn)品如PhxSQL、MariaDB Galera Cluster、Percona XtraDB Cluster等越來越多的被大規(guī)模使用。
隨著官方MySQL Group Replication的GA，使用分布式協(xié)議來解決數(shù)據(jù)一致性問題已經(jīng)成為了主流的方向。期望越來越多優(yōu)秀的解決方案被提出，MySQL高可用問題可以被更好的解決。
MySQL做分布式需要通過ndb的Cluster來實(shí)現(xiàn)。MySQLCluster是MySQL適合于分布式計(jì)算環(huán)境的高實(shí)用、高冗余版本。 實(shí)現(xiàn)的步驟比較復(fù)雜，百度云案例:《MySQLCluster(MySQL集群)分布式》 下載地址:
以前參加過一個庫存系統(tǒng)，由于其業(yè)務(wù)復(fù)雜性，搞了很多個應(yīng)用來支撐。這樣的話一份庫存數(shù)據(jù)就有可能同時有多個應(yīng)用來修改庫存數(shù)據(jù)。
比如說，有定時任務(wù)域xx.cron，和SystemA域和SystemB域這幾個JAVA應(yīng)用，可能同時修改同一份庫存數(shù)據(jù)。如果不做協(xié)調(diào)的話，就會有臟數(shù)據(jù)出現(xiàn)。
對于跨JAVA進(jìn)程的線程協(xié)調(diào)，可以借助外部環(huán)境，例如DB或者Redis。下文介紹一下如何使用DB來實(shí)現(xiàn)分布式鎖。
本文設(shè)計(jì)的分布式鎖的交互方式如下：
在使用synchronized關(guān)鍵字的時候，必須指定一個鎖對象。
進(jìn)程內(nèi)的線程可以基于obj來實(shí)現(xiàn)同步。obj在這里可以理解為一個鎖對象。如果線程要進(jìn)入synchronized代碼塊里，必須先持有obj對象上的鎖。這種鎖是JAVA里面的內(nèi)置鎖，創(chuàng)建的過程是線程安全的。那么借助DB，如何保證創(chuàng)建鎖的過程是線程安全的呢？
可以利用DB中的UNIQUE KEY特性，一旦出現(xiàn)了重復(fù)的key，由于UNIQUE KEY的唯一性，會拋出異常的。在JAVA里面，是 SQLIntegrityConstraintViolationException 異常。
transaction_id是事務(wù)Id，比如說，可以用
來組裝一個transaction_id，表示某倉庫某銷售模式下的某個條碼資源。不同條碼，當(dāng)然就有不同的transaction_id。如果有兩個應(yīng)用，拿著相同的transaction_id來創(chuàng)建鎖資源的時候，只能有一個應(yīng)用創(chuàng)建成功。
在寫操作頻繁的業(yè)務(wù)系統(tǒng)中，通常會進(jìn)行分庫，以降低單數(shù)據(jù)庫寫入的壓力，并提高寫操作的吞吐量。如果使用了分庫，那么業(yè)務(wù)數(shù)據(jù)自然也都分配到各個數(shù)據(jù)庫上了。
在這種水平切分的多數(shù)據(jù)庫上使用DB分布式鎖，可以自定義一個DataSouce列表。并暴露一個 getConnection(String transactionId) 方法，按照transactionId找到對應(yīng)的Connection。
實(shí)現(xiàn)代碼如下：
首先編寫一個initDataSourceList方法，并利用Spring的PostConstruct注解初始化一個DataSource 列表。相關(guān)的DB配置從db.properties讀取。
DataSource使用阿里的DruidDataSource。
接著最重要的一個實(shí)現(xiàn)getConnection(String transactionId)方法。實(shí)現(xiàn)原理很簡單，獲取transactionId的hashcode，并對DataSource的長度取模即可。
連接池列表設(shè)計(jì)好后，就可以實(shí)現(xiàn)往distributed_lock表插入數(shù)據(jù)了。
接下來利用DB的 select for update 特性來鎖住線程。當(dāng)多個線程根據(jù)相同的transactionId并發(fā)同時操作 select for update 的時候，只有一個線程能成功，其他線程都block住，直到 select for update 成功的線程使用commit操作后，block住的所有線程的其中一個線程才能開始干活。
我們在上面的DistributedLock類中創(chuàng)建一個lock方法。
當(dāng)線程執(zhí)行完任務(wù)后，必須手動的執(zhí)行解鎖操作，之前被鎖住的線程才能繼續(xù)干活。在我們上面的實(shí)現(xiàn)中，其實(shí)就是獲取到當(dāng)時 select for update 成功的線程對應(yīng)的Connection，并實(shí)行commit操作即可。
那么如何獲取到呢？我們可以利用ThreadLocal。首先在DistributedLock類中定義
每次調(diào)用lock方法的時候，把Connection放置到ThreadLocal里面。我們修改lock方法。
這樣子，當(dāng)獲取到Connection后，將其設(shè)置到ThreadLocal中，如果lock方法出現(xiàn)異常，則將其從ThreadLocal中移除掉。
有了這幾步后，我們可以來實(shí)現(xiàn)解鎖操作了。我們在DistributedLock添加一個unlock方法。
畢竟是利用DB來實(shí)現(xiàn)分布式鎖，對DB還是造成一定的壓力。當(dāng)時考慮使用DB做分布式的一個重要原因是，我們的應(yīng)用是后端應(yīng)用，平時流量不大的，反而關(guān)鍵的是要保證庫存數(shù)據(jù)的正確性。對于像前端庫存系統(tǒng)，比如添加購物車占用庫存等操作，最好別使用DB來實(shí)現(xiàn)分布式鎖了。
如果想鎖住多份數(shù)據(jù)該怎么實(shí)現(xiàn)？比如說，某個庫存操作，既要修改物理庫存，又要修改虛擬庫存，想鎖住物理庫存的同時，又鎖住虛擬庫存。其實(shí)也不是很難，參考lock方法，寫一個multiLock方法，提供多個transactionId的入?yún)?，for循環(huán)處理就可以了。這個后續(xù)有時間再補(bǔ)上。
應(yīng)該是通過ndb的cluster來實(shí)現(xiàn)啊，你只需在網(wǎng)上找mysql cluster的資料就可以知道了。在mysql官方網(wǎng)站上可以下載到，如《mysql cluster維護(hù)手冊.docx》等
重慶分公司
重慶分公司
