mysql主从数据一致性问题及MHA和MGR的架构及底层原理
MySQL的傳統(tǒng)主從復(fù)制機制
MySQL傳統(tǒng)的高可用解決方案是通過binlog復(fù)制來搭建主從或一主多從的數(shù)據(jù)庫集群。主從之間的復(fù)制模式支持異步模式(async replication)和半同步模式(semi-sync replication)。無論哪種模式下，都是主庫master提供讀寫事務(wù)的能力，而slave只能提供只讀事務(wù)的能力。在master上執(zhí)行的更新事務(wù)通過binlog復(fù)制的方式傳送給slave，slave收到后將事務(wù)先寫入relay log，然后重放事務(wù)，即在slave上重新執(zhí)行一次事務(wù)，從而達到主從機事務(wù)一致的效果。
異步復(fù)制(Async replication)：在master將事務(wù)寫入binlog后，將新寫入的binlog事務(wù)日志傳送給slave節(jié)點，但并不等待傳送的結(jié)果，就會在存儲引擎中提交事務(wù)。
數(shù)據(jù)丟失的原因：當master將事務(wù)寫入binlog，然后復(fù)制給slave后并不等待slave返回結(jié)果即進行提交，若slave因網(wǎng)絡(luò)延遲或其它問題尚未收到binlog日志，而此時master故障，應(yīng)用切換到slave時，本來在master上已經(jīng)提交的事務(wù)就會丟失，因其尚未傳送到slave，從而導(dǎo)致主從之間事務(wù)不一致。
半同步復(fù)制(Semi-sync replication)：在master將事務(wù)寫入binlog后，將新寫入的binlog事務(wù)日志傳送給slave節(jié)點，但需要等待slave返回傳送的結(jié)果；slave收到binlog事務(wù)后，將其寫入relay log中，然后向master返回傳送成功ACK；master收到ACK后，再在存儲引擎中提交事務(wù)。 MySQL基于兩種復(fù)制模式都可以搭建高可用數(shù)據(jù)庫集群，也能滿足大部分高可用系統(tǒng)的要求，但在對事務(wù)一致性要求很高的系統(tǒng)中，還是存在一些不足，主要的不足就是主從之間的事務(wù)不能保證時刻完全一致。
數(shù)據(jù)丟失的原因：當master將事務(wù)寫入binlog，尚未傳送給slave時master故障，此時應(yīng)用切換到slave，雖然此時slave的事務(wù)與master故障前是一致的，但當主機恢復(fù)后，因最后的事務(wù)已經(jīng)寫入到binlog，所以在master上會恢復(fù)成已提交狀態(tài)，從而導(dǎo)致主從之間的事務(wù)不一致。
MHA工作組件
MHA(Master High Availability)是一種MySQL高可用解決方案，主要用于在故障切換和主從提升時進行快速切換，并最大程度保證數(shù)據(jù)一致性。
MHA主要由兩部分組成：
1、MHA Manager(管理節(jié)點)，可以單獨部署在一臺獨立的機器上管理多個master-slave集群，也可以部署在一臺slave節(jié)點上。
MHA Manager會定時探測集群中的node節(jié)點，當發(fā)現(xiàn)master出現(xiàn)故障的時候，它可以自動將具有最新數(shù)據(jù)的slave提升為新的master，然后將所有其它的slave導(dǎo)向新的master上，整個故障轉(zhuǎn)移過程對應(yīng)用程序是透明的。
2、MHA Node(數(shù)據(jù)節(jié)點)，數(shù)據(jù)節(jié)點部署在每個集群節(jié)點上，負責在主從切換時對比和應(yīng)用差異日志。
MHA主要特性
MHA切換不依賴實例使用存儲引擎和BINLOG格式；
MHA不會增加MySQL服務(wù)器性能開銷，除MHA管理節(jié)點外無需增加額外服務(wù)器；
在MySQL服務(wù)器上部署MHA數(shù)據(jù)節(jié)點不會影響當前實例運行；
MHA實現(xiàn)自動故障切換，也可以手動觸發(fā)在線切換；
MHA可以實現(xiàn)秒級的故障切換；
MHA可以將任意slave提升master，也可以在切換時指定master候選節(jié)點；
MHA提供擴展接口，允許在MHA切換過程中的特定時間點執(zhí)行用戶自定義腳本。
MHA可擴展性：
A)seconary_check_script
當檢測到master節(jié)點連接失敗時調(diào)用，從多個網(wǎng)絡(luò)路徑判斷master是否發(fā)生宕機。
B)shutdown_script
在故障轉(zhuǎn)移前調(diào)用，可以通過SSH登錄到master節(jié)點進行數(shù)據(jù)庫關(guān)閉和服務(wù)器關(guān)機等操作。
C)master_ip_failover_script
在故障轉(zhuǎn)移前和轉(zhuǎn)移到新master節(jié)點后調(diào)用，用于切換群集使用的VIP或域名或其他操作。
D)report_script
在故障切換完成后被調(diào)用，用于通知故障切換的執(zhí)行結(jié)果。
MHA支持與限制
1、只支持BINLOG V4版本，要求MySQL 5.0或更高版本。
2、候選master節(jié)點必須開啟log-bin參數(shù)，如果所有從節(jié)點都為開啟，則不進行故障轉(zhuǎn)移。
3、在MHA 0.52版本前不支持多master模式
4、MHA默認不支持多級主從復(fù)制，通過修改配置文件和設(shè)置multi_tier_slave參數(shù)
（參考文章：https://www.cnblogs.com/gaogao67/p/11105996.html）
在MHA自動故障切換過程中，MHA試圖從宕機的主服務(wù)器上保存二進制日志，最大程度的保證數(shù)據(jù)的不丟失，但這并不總是可行的。
例如，如果主服務(wù)器硬件故障或無法通過ssh訪問，MHA沒法保存二進制日志，只進行故障轉(zhuǎn)移而丟失了最新的數(shù)據(jù)。
如果master宕機，如何保證主從庫的一致？
使用MySQL 5.5或者以后的版本的半同步復(fù)制，可以大大降低數(shù)據(jù)丟失的風險。MHA可以與半同步復(fù)制結(jié)合起來。
如果只有一個slave已經(jīng)收到了最新的二進制日志，MHA可以將最新的二進制日志應(yīng)用于其他所有的slave服務(wù)器上，因此可以保證所有節(jié)點的數(shù)據(jù)一致性。
具體的工作原理如下:
相較于其它HA軟件，MHA的目的在于維持MySQL Replication中Master庫的高可用性，其最大特點是可以修復(fù)多個Slave之間的差異日志，最終使所有Slave保持數(shù)據(jù)一致，然后從中選擇一個充當新的Master，并將其它Slave指向它。
MHA插件負責監(jiān)控mysql主節(jié)點的健康情況。在主節(jié)點宕機后，MHA把binlog通過ssh傳到從節(jié)點進行重做補齊。并提升其中一個從節(jié)點為主節(jié)點。如：A>B ,A>C 。A宕機后。B，C補齊日志。并將故障轉(zhuǎn)移后的架構(gòu)變?yōu)锽>C。
工作流程主要如下：
1、從出現(xiàn)故障的主節(jié)點A拉取binlog日志到B、C節(jié)點。
2、識別有最近Relay_Master_Log_File,Exec_Master_Log_Pos 更新的slave節(jié)點。假設(shè)是B
3、應(yīng)用差異的中繼日志（relay log）到其他slave節(jié)點。如C
4、提升slave （B）為新的主節(jié)點。
5、其他的節(jié)點（C）連接到新的主節(jié)點。
MHA 切換完了之后并沒有其他的操作了。如服務(wù)發(fā)現(xiàn)，重新注冊。但是MHA提供了腳本接口。可以手動指定切換完了MHA執(zhí)行指定的腳本。如注冊虛擬ip到新的主節(jié)點。或者調(diào)用接口注冊新的服務(wù)域名。發(fā)告警郵件 等。
mha的架構(gòu)如下：
當master出現(xiàn)故障時，通過對比slave之間I/O線程讀取master binlog的位置，選取最接近的slave做為latest slave。其它slave通過與latest slave對比生成差異中繼日志。
在latest slave上應(yīng)用從master保存的binlog，同時將latest slave提升為master。最后在其它slave上應(yīng)用相應(yīng)的差異中繼日志并開始從新的master開始復(fù)制。
在MHA實現(xiàn)Master故障切換過程中，MHA Node會試圖訪問故障的master（通過SSH），如果可以訪問（不是硬件故障，比如InnoDB數(shù)據(jù)文件損壞等），會保存二進制文件，以最大程度保證數(shù)據(jù)不丟失。
MHA和半同步復(fù)制一起使用會大大降低數(shù)據(jù)丟失的危險。
優(yōu)勢
1）故障切換快
在主從復(fù)制集群中，只要從庫在復(fù)制上沒有延遲，MHA通常可以在數(shù)秒內(nèi)實現(xiàn)故障切換。9-10秒內(nèi)檢查到master故障，可以選擇在7-10秒關(guān)閉master以避免出現(xiàn)裂腦，幾秒鐘內(nèi)，將差異中繼日志（relay log）應(yīng)用到新的master上，因此總的宕機時間通常為10-30秒。恢復(fù)新的master后，MHA并行的恢復(fù)其余的slave。即使在有數(shù)萬臺slave，也不會影響master的恢復(fù)時間。
DeNA在超過150個MySQL（主要5.0/5.1版本）主從環(huán)境下使用了MHA。當mater故障后，MHA在4秒內(nèi)就完成了故障切換。在傳統(tǒng)的主動/被動集群解決方案中，4秒內(nèi)完成故障切換是不可能的。
2）master故障不會導(dǎo)致數(shù)據(jù)不一致
當目前的master出現(xiàn)故障時，MHA自動識別slave之間中繼日志（relay log）的不同，并應(yīng)用到所有的slave中。這樣所有的salve能夠保持同步，只要所有的slave處于存活狀態(tài)。和半同步復(fù)制一起使用，（幾乎）可以保證沒有數(shù)據(jù)丟失。
3）無需修改當前的MySQL設(shè)置
MHA并不需要改變MySQL的部署環(huán)境，MHA適用于異步和半同步的主從復(fù)制。
啟動/停止/升級/降級/安裝/卸載MHA不需要改變（包擴啟動/停止）MySQL復(fù)制。當需要升級MHA到新的版本，不需要停止MySQL，僅僅替換到新版本的MHA，然后重啟MHA Manager就好了。
4）無需增加大量的服務(wù)器
MHA由MHA Manager和MHA Node組成。MHA Node運行在需要故障切換/恢復(fù)的MySQL服務(wù)器上，因此并不需要額外增加服務(wù)器。MHA Manager運行在特定的服務(wù)器上，因此需要增加一臺（實現(xiàn)高可用需要2臺），但是MHA Manager可以監(jiān)控大量（甚至上百臺）單獨的master，因此，并不需要增加大量的服務(wù)器。即使在一臺slave上運行MHA Manager也是可以的。
5）無性能下降
MHA適用與異步或半同步的MySQL復(fù)制。監(jiān)控master時，MHA僅僅是每隔幾秒（默認是3秒）發(fā)送一個ping包，并不發(fā)送重查詢。可以得到像原生MySQL復(fù)制一樣快的性能。
6）適用于任何存儲引擎
MHA可以運行在只要MySQL復(fù)制運行的存儲引擎上，并不僅限制于InnoDB，即使在不易遷移的傳統(tǒng)的MyISAM引擎環(huán)境，一樣可以使用MHA。
MHA如何保持數(shù)據(jù)的一致性呢？
主要通過MHA node的以下幾個工具實現(xiàn)，但是這些工具由MHA manager觸發(fā)：
save_binary_logs ：如果master的二進制日志可以存取的話，保存復(fù)制master的二進制日志，最大程度保證數(shù)據(jù)不丟失。
apply_diff_relay_logs：相對于最新的slave，生成差異的中繼日志并將所有差異事件應(yīng)用到其他所有的slave。
對比的是relay log，relay log越新就越接近于master，才能保證數(shù)據(jù)是最新的。
purge_relay_logs：刪除中繼日志而不阻塞sql線程
MGR架構(gòu)原理簡介：（全稱：MySQL Group Replication），Mysql組復(fù)制
1.狀態(tài)機復(fù)制
MGR本質(zhì)上一個狀態(tài)機復(fù)制的集群。在狀態(tài)機復(fù)制的架構(gòu)中，數(shù)據(jù)庫被當做一個狀態(tài)機。每一次寫操作都會導(dǎo)致數(shù)據(jù)庫的狀態(tài)變化。為了創(chuàng)建一個高可用的數(shù)據(jù)庫集群，有一個組件，即事務(wù)分發(fā)器，將這些操作按照同樣的順序發(fā)送到多個初始狀態(tài)一致的數(shù)據(jù)庫上，讓這些數(shù)據(jù)庫執(zhí)行同樣的操作。因為初始狀態(tài)相同，每次執(zhí)行的操作也相同，所以每次狀態(tài)變化后各個數(shù)據(jù)庫上的數(shù)據(jù)保持一致。
2.分布式的狀態(tài)機復(fù)制
事務(wù)分發(fā)器是一個單點，為了避免單點故障，可以采用分布式的狀態(tài)機復(fù)制。在分布式的狀態(tài)機復(fù)制中，有多個事務(wù)分發(fā)器，它們彼此互相通信。事務(wù)分發(fā)器可以同時接收事務(wù)請求，就像單個事務(wù)分發(fā)器同時接收事務(wù)請求一樣。從應(yīng)用層來說，并發(fā)的事務(wù)發(fā)到同一個事務(wù)分發(fā)器和發(fā)到不同的事務(wù)分發(fā)器上效果是一樣的。事務(wù)分發(fā)器之間會互相通信，把所有的事務(wù)匯總、排序。最終，每個事務(wù)分發(fā)器上都有一份完整的排好序的事務(wù)請求。每個事務(wù)分發(fā)器只連接到一個數(shù)據(jù)庫上，并負責把事務(wù)請求依次發(fā)送到相連的數(shù)據(jù)庫上去執(zhí)行，其就是一個分布式狀態(tài)機復(fù)制的模型了。
3.分布式的高可用數(shù)據(jù)庫
將分布式的事務(wù)分發(fā)模塊集成到數(shù)據(jù)庫系統(tǒng)中，就變成了一個分布式的高可用數(shù)據(jù)庫系統(tǒng)。用戶通過數(shù)據(jù)庫的用戶接口執(zhí)行事務(wù)。數(shù)據(jù)庫收到事務(wù)請求后，首先交由事務(wù)分發(fā)模塊處理。事務(wù)分發(fā)模塊將事務(wù)匯總排序，然后依次交由數(shù)據(jù)處理模塊去執(zhí)行這些事務(wù)。
用戶——>請求數(shù)據(jù)庫用戶接口——>數(shù)據(jù)庫——>事務(wù)分發(fā)器——>將事務(wù)匯總排序——>執(zhí)行
Group Replication的實現(xiàn)原理
Group Replication由至少3個或更多個節(jié)點共同組成一個數(shù)據(jù)庫集群，事務(wù)的提交必須經(jīng)過半數(shù)以上節(jié)點同意方可提交，在集群中每個節(jié)點上都維護一個數(shù)據(jù)庫狀態(tài)機，保證節(jié)點間事務(wù)的一致性。Group Replication基于分布式一致性算法Paxos實現(xiàn)，允許部分節(jié)點故障，只要保證半數(shù)以上節(jié)點存活，就不影響對外提供數(shù)據(jù)庫服務(wù)，是一個真正可用的高可用數(shù)據(jù)庫集群技術(shù)。 Group Replication支持兩種模式，單主模式和多主模式。在同一個group內(nèi)，不允許兩種模式同時存在，并且若要切換到不同模式，必須修改配置后重新啟動集群。 在單主模式下，只有一個節(jié)點可以對外提供讀寫事務(wù)的服務(wù)，而其它所有節(jié)點只能提供只讀事務(wù)的服務(wù)。
MySQL Group Replication是建立在已有MySQL復(fù)制框架的基礎(chǔ)之上，通過新增Group Replication Protocol協(xié)議及Paxos協(xié)議的實現(xiàn)，形成的整體高可用解決方案。與原有復(fù)制方式相比，主要增加了certify的概念，如下圖所示：
certify模塊主要負責檢查事務(wù)是否允許提交，是否與其它事務(wù)存在沖突，如兩個事務(wù)可能修改同一行數(shù)據(jù)。在單機系統(tǒng)中，兩個事務(wù)的沖突可以通過封鎖來避免，但在多主模式下，不同節(jié)點間沒有分布式鎖，所以無法使用封鎖來避免。為提高性能，Group Replication樂觀地來對待不同事務(wù)間的沖突，樂觀的認為多數(shù)事務(wù)在執(zhí)行時是沒有并發(fā)沖突的。事務(wù)分別在不同節(jié)點上執(zhí)行，直到準備提交時才去判斷事務(wù)之間是否存在沖突。
核心組件XCOM的特性
MySQL Group Replication是建立在基于Paxos的XCom之上的，正因為有了XCom基礎(chǔ)設(shè)施，保證數(shù)據(jù)庫狀態(tài)機在節(jié)點間的事務(wù)一致性，才能在理論和實踐中保證數(shù)據(jù)庫系統(tǒng)在不同節(jié)點間的事務(wù)一致性。 Group Replication在通訊層曾經(jīng)歷過一次比較大的變動，早期通訊層采用是的Corosync，而后來才改為XCom。
xcom特性：
閉環(huán)(closed group)：只有組內(nèi)成員才能給組成員發(fā)送消息，不接受組外成員的消息。
消息全局有序(total order)：所有XCOM傳遞的消息是全局有序(在多主集群中或是偏序)，這是構(gòu)建MySQL 一致性狀態(tài)機的基礎(chǔ)。
消息的安全送達(Safe Delivery)：發(fā)送的消息必須傳送給所有非故障節(jié)點，必須在多數(shù)節(jié)點確認收到后方可通知上層應(yīng)用。
視圖同步(View Synchrony)：在成員視圖變化之前，每個節(jié)點都以相同的順序傳遞消息，這保證在節(jié)點恢復(fù)時有一個同步點。實際上，組復(fù)制并不強制要求消息傳遞必須在同一個節(jié)點視圖中。
（參考文章：https://blog.csdn.net/weixin_32175667/article/details/113330358）
MGR 適用的場景包括：
彈性復(fù)制：復(fù)制架構(gòu)下，服務(wù)器的數(shù)量動態(tài)增加或縮減時，使影響降到最低。
分片的高可用：用戶可以利用MGR實現(xiàn)單一分片的高可用，每個分片都具有一個復(fù)制組。
主從復(fù)制的替代選擇：可以使用單主模式避免發(fā)生沖突檢測，以替代傳統(tǒng)的主從復(fù)制。
MGR使用上的限制
盡量使用單主模式，表必須有主鍵，必須啟用GTID，必須使用InnoDB引擎，在多主模式下DML和DDL對同一個表的操作，必須在同一個節(jié)點進行，否則會導(dǎo)致集群會crash。使用奇數(shù)個節(jié)點:3,5,7,9 最多9個成員。
網(wǎng)絡(luò)穩(wěn)定，延遲低，盡量避免WAN部署；禁止使用外鍵；不支持GAP LOCK ，MGR工作在RC模式；不支持serializable事務(wù)模式；MGR成員間不支持復(fù)制過濾規(guī)則。
BINLOG_FORMAT=ROW。
在多主模式使用select for update可能會導(dǎo)致整個集群死鎖。
如果配合mysqlshell使用MySQL版本需要8.0.20及以上。
從MySQL 5.6.5 開始新增了一種基于 GTID 的復(fù)制方式。通過 GTID 保證了每個在主庫上提交的事務(wù)在集群中有一個唯一的ID。這種方式強化了數(shù)據(jù)庫的主備一致性，故障恢復(fù)以及容錯能力。GTID (Global Transaction ID)是全局事務(wù)ID,當在主庫上提交事務(wù)或者被從庫應(yīng)用時，可以定位和追蹤每一個事務(wù)。
從架構(gòu)設(shè)計的角度，GTID是一種很好的分布式ID實踐方式，通常來說，分布式ID有兩個基本要求：
1）全局唯一性
2）趨勢遞增
這個ID因為是全局唯一，所以在分布式環(huán)境中很容易識別，因為趨勢遞增，所以ID是具有相應(yīng)的趨勢規(guī)律，在必要的時候方便進行順序提取，行業(yè)內(nèi)適用較多的是基于Twitter的ID生成算法snowflake,所以換一個角度來理解GTID，其實是一種優(yōu)雅的分布式設(shè)計。
分布式ID使用背景：
業(yè)務(wù)數(shù)據(jù)量不大的時候，單庫單表完全可以支撐現(xiàn)有業(yè)務(wù)，數(shù)據(jù)再大一點搞個MySQL主從同步讀寫分離也能對付。
但隨著數(shù)據(jù)日漸增長，主從同步也扛不住了，就需要對數(shù)據(jù)庫進行分庫分表，但分庫分表后需要有一個唯一ID來標識一條數(shù)據(jù)，數(shù)據(jù)庫的自增ID顯然不能滿足需求；特別一點的如訂單、優(yōu)惠券也都需要有唯一ID做標識。此時一個能夠生成全局唯一ID的系統(tǒng)是非常必要的。那么這個全局唯一ID就叫分布式ID。
項目中一個表中的數(shù)據(jù)主鍵id都是自增的，解決分布式id的方案有哪些？
1、數(shù)據(jù)庫自增ID
可以在某個庫中專門維護一張表，然后每次無論哪個表需要自增id的時候都去查這個表的記錄，然后用for update鎖表，然后取到的值加一，然后返回以后把再把值記錄到表中，但是這個方法適合并發(fā)量比較小的項目，因此每次都得鎖表。
優(yōu)點：實現(xiàn)簡單，ID單調(diào)自增，數(shù)值類型查詢速度快
缺點：DB單點存在宕機風險，無法扛住高并發(fā)場景
2、基于數(shù)據(jù)庫集群模式
單點數(shù)據(jù)庫方式不可取，換成主從模式集群。害怕一個主節(jié)點掛掉沒法用，那就做雙主模式集群，也就是兩個Mysql實例都能單獨的生產(chǎn)自增ID。兩個MySQL實例的自增ID都從1開始，會生成重復(fù)的ID怎么辦？設(shè)置起始值和自增步長
優(yōu)點：解決數(shù)據(jù)庫單點問題
缺點：不利于后續(xù)擴容，而且實際上單個數(shù)據(jù)庫自身壓力還是大，依舊無法滿足高并發(fā)場景。
3、基于數(shù)據(jù)庫的號段模式
號段模式是當下分布式ID生成器的主流實現(xiàn)方式之一，號段模式可以理解為**從數(shù)據(jù)庫批量的獲取自增ID，每次從數(shù)據(jù)庫取出一個號段范圍，**例如 (1,1000] 代表1000個ID，具體的業(yè)務(wù)服務(wù)將本號段，生成1~1000的自增ID并加載到內(nèi)存。等這批號段ID用完，再次向數(shù)據(jù)庫申請新號段，由于多業(yè)務(wù)端可能同時操作，所以采用版本號version樂觀鎖方式更新，這種分布式ID生成方式不強依賴于數(shù)據(jù)庫，不會頻繁的訪問數(shù)據(jù)庫，對數(shù)據(jù)庫的壓力小很多。
4、redis
因為redis是單線程的，可以在redis中維護一個鍵值對，然后哪個表需要直接去redis中取值然后加一，但是這個跟上面一樣由于單線程都是對高并發(fā)的支持不高，只適合并發(fā)量小的項目。
用redis實現(xiàn)需要注意一點，要考慮到redis持久化的問題。redis有兩種持久化方式RDB和AOF。RDB會定時打一個快照進行持久化，假如連續(xù)自增但redis沒及時持久化，而這會Redis掛掉了，重啟Redis后會出現(xiàn)ID重復(fù)的情況。AOF會對每條寫命令進行持久化，即使Redis掛掉了也不會出現(xiàn)ID重復(fù)的情況，但由于incr命令的特殊性，會導(dǎo)致Redis重啟恢復(fù)的數(shù)據(jù)時間過長。
5、uuid
可以使用uuid作為不重復(fù)主鍵id，但是uuid有個問題就是其是無序的字符串，如果使用uuid當做主鍵，那么主鍵索引就會失效。
優(yōu)點：生成足夠簡單，本地生成無網(wǎng)絡(luò)消耗，具有唯一性
缺點：
無序的字符串，不具備趨勢自增特性；沒有具體的業(yè)務(wù)含義；存儲以及查詢對MySQL的性能消耗較大，作為數(shù)據(jù)庫主鍵 UUID 的無序性會導(dǎo)致數(shù)據(jù)位置頻繁變動，嚴重影響性能。
6、雪花算法
雪花算法是解決分布式id的一個高效的方案，大部分互聯(lián)網(wǎng)公司都在使用雪花算法，當然還有公司自己實現(xiàn)其他的方案，比如百度（uid-generator）、美團（Leaf）、滴滴（Tinyid）
雪花算法的原理：
雪花算法就是使用64位long類型的數(shù)據(jù)存儲id，最高位一位存儲0或者1,0代表整數(shù)，1代表負數(shù)，一般都是0，所以最高位不變，41位存儲毫秒級時間戳，10位存儲機器碼（包括5位datacenterId和5位workerId），12存儲序列號。這樣最大2的10次方的機器，也就是1024臺機器，最多每毫秒每臺機器產(chǎn)生2的12次方也就是4096個id。
總結(jié)
以上是生活随笔為你收集整理的mysql主从数据一致性问题及MHA和MGR的架构及底层原理的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： AMOLED原理介紹
- 下一篇： linux cmake编译源码,linu