MySQL Mycat 分布式架構(gòu)

參考：

十多年的珠海網(wǎng)站建設(shè)經(jīng)驗，針對設(shè)計、前端、開發(fā)、售后、文案、推廣等六對一服務(wù)，響應(yīng)快，48小時及時工作處理。全網(wǎng)整合營銷推廣的優(yōu)勢是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動調(diào)整珠海建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計，從而大程度地提升瀏覽體驗。成都創(chuàng)新互聯(lián)公司從事“珠海網(wǎng)站設(shè)計”,“珠海網(wǎng)站推廣”以來，每個客戶項目都認真落實執(zhí)行。

圖中是兩組分片，紅色我們稱為shard1，藍色我們稱為shard2

51 52是服務(wù)器

兩個3307互為主從(雙主)，3309是本地3307的從庫

說明：沒有明確說明是只在某一個節(jié)點上做的，就是兩個節(jié)點都做

兩臺虛擬機 db01 db02

每臺創(chuàng)建四個mysql實例：3307 3308 3309 3310

mysql軟件我們之前已完成二進制安裝，直接初始化即可

我們server-id規(guī)劃為：db01上是7/8/9/10,db02上是17/18/19/20

"箭頭指向誰是主庫"

10.0.0.51:3307 ----- 10.0.0.52:3307

10.0.0.51:3309 ------ 10.0.0.51:3307

10.0.0.52:3309 ------ 10.0.0.52:3307

兩個分片，每個分片四個mysql節(jié)點

shard1：

Master：10.0.0.51:3307

slave1：10.0.0.51:3309

Standby Master：10.0.0.52:3307

slave2：10.0.0.52:3309

shard2：

Master：10.0.0.52:3308

slave1：10.0.0.52:3310

Standby Master：10.0.0.51:3308

slave2：10.0.0.51:3310

shard1

10.0.0.51:3307 ----- 10.0.0.52:3307

db02

db01

db02

10.0.0.51:3309 ------ 10.0.0.51:3307

db01

10.0.0.52:3309 ------ 10.0.0.52:3307

db02

shard2

10.0.0.52:3308 ----- 10.0.0.51:3308

db01

db02

db01

10.0.0.52:3310 ----- 10.0.0.52:3308

db02

10.0.0.51:3310 ----- 10.0.0.51:3308

db01

這個復(fù)制用戶在誰上建都行

注：如果中間出現(xiàn)錯誤，在每個節(jié)點進行執(zhí)行以下命令

常見方案：

360 Atlas-Sharding 360

Alibaba cobar 阿里

Mycat 開源

TDDL 淘寶

Heisenberg 百度

Oceanus 58同城

Vitess 谷歌

OneProxy

DRDS 阿里云

我們裝的是openjdk，不是官方的那個

Mycat-server-xxxxx.linux.tar.gz

配置環(huán)境變量

我們mycat的命令也是在bin目錄下

啟動

8066就是對外提供服務(wù)的端口，9066是管理端口

連接mycat：

默認123456

db01:

我們一般先把原schema.xml備份，然后自己新寫一個：

xml和html看起來差不多，xml是從下往上調(diào)用的

前三行我們不用看，直接從第四行schema開始看起：

定義了schema，然后以/schema結(jié)尾

為什么要用邏輯庫？

業(yè)務(wù)透明化

此配置文件就是實現(xiàn)讀寫分離的配置

重啟mycat

讀寫分離測試

總結(jié)：

以上案例實現(xiàn)了1主1從的讀寫分離功能，寫操作落到主庫，讀操作落到從庫.如果主庫宕機，從庫不能在繼續(xù)提供服務(wù)了。

我們推薦這種架構(gòu)

一寫三讀，

不設(shè)置雙寫的原因是：性能沒提升多少，反而引起主鍵沖突的情況

配置文件：

之后重啟：mycat restart

真正的 writehost：負責寫操作的writehost

standby writeHost ：和readhost一樣，只提供讀服務(wù)

我們此處寫了兩個writehost，默認使用第一個

當寫節(jié)點宕機后，后面跟的readhost也不提供服務(wù)，這時候standby的writehost就提供寫服務(wù)，

后面跟的readhost提供讀服務(wù)

測試：

讀寫分離測試

對db01 3307節(jié)點進行關(guān)閉和啟動,測試讀寫操作

結(jié)果應(yīng)為另一臺(52)的3307(17)是寫，3309(19)是讀

一旦7號節(jié)點恢復(fù)，此時因為7落后了，寫節(jié)點仍是17

balance屬性

負載均衡類型，目前的取值有3種：

writeType屬性

負載均衡類型，目前的取值有2種：

switchType屬性

-1 表示不自動切換

1 默認值，自動切換

2 基于MySQL主從同步的狀態(tài)決定是否切換 ，心跳語句為 show slave status

datahost其他配置

dataHost name="localhost1" maxCon="1000" minCon="10" balance="1" writeType="0" dbType="mysql" dbDriver="native" switchType="1"

maxCon="1000"：最大的并發(fā)連接數(shù)

minCon="10" ：mycat在啟動之后，會在后端節(jié)點上自動開啟的連接線程，長連接，好處是連接速度快，弊端是占內(nèi)存

tempReadHostAvailable="1"

這個一主一從時（1個writehost，1個readhost時），可以開啟這個參數(shù)，如果2個writehost，2個readhost時

heartbeatselect user()/heartbeat 監(jiān)測心跳

其他參數(shù)sqlMaxLimit自動分頁,必須在啟用分表的情況下才生效

創(chuàng)建測試庫和表:

我們重啟mycat后連接到8066

發(fā)現(xiàn)跟一個庫一樣，實際上已經(jīng)分到不同的物理硬件上了

分片：對一個"bigtable"，比如說t3表

熱點數(shù)據(jù)表 核心表

(1)行數(shù)非常多，800w下坡

(2)訪問非常頻繁

分片的目的：

（1）將大數(shù)據(jù)量進行分布存儲

（2）提供均衡的訪問路由

分片策略：

范圍 range 800w 1-400w 400w01-800w 不適用于業(yè)務(wù)訪問不均勻的情況

取模 mod (取余數(shù)) 和節(jié)點的數(shù)量進行取模

枚舉 按枚舉的種類分，如移動項目按省份分

哈希 hash

時間 流水

優(yōu)化關(guān)聯(lián)查詢（否則join的表在不同分片上，效率會比單庫還要低）

全局表

ER分片

案例：移動統(tǒng)一：先拆出邊緣業(yè)務(wù)，再按地域分片，但對應(yīng)用來說是統(tǒng)一的

vim rule.xml

tableRule name="auto-sharding-long"

rule

columnsid/columns

algorithmrang-long/algorithm

/rule

function name="rang-long"

class="io.mycat.route.function.AutoPartitionByLong"

property name="mapFile"autopartition-long.txt/property

/function

===================================

vim autopartition-long.txt

0-10=0

11-20=1

創(chuàng)建測試表：

mysql -S /data/3307/mysql.sock -e "use taobao;create table t3 (id int not null primary key auto_increment,name varchar(20) not null);"

mysql -S /data/3308/mysql.sock -e "use taobao;create table t3 (id int not null primary key auto_increment,name varchar(20) not null);"

測試：

重啟mycat

mycat restart

mysql -uroot -p123456 -h 127.0.0.1 -P 8066

insert into t3(id,name) values(1,'a');

insert into t3(id,name) values(2,'b');

insert into t3(id,name) values(3,'c');

insert into t3(id,name) values(4,'d');

insert into t3(id,name) values(11,'aa');

insert into t3(id,name) values(12,'bb');

insert into t3(id,name) values(13,'cc');

insert into t3(id,name) values(14,'dd');

取余分片方式：分片鍵（一個列）與節(jié)點數(shù)量進行取余，得到余數(shù)，將數(shù)據(jù)寫入對應(yīng)節(jié)點

vim schema.xml

table name="t4" dataNode="sh1,sh2" rule="mod-long" /

vim rule.xml

property name="count"2/property

準備測試環(huán)境

創(chuàng)建測試表：

mysql -S /data/3307/mysql.sock -e "use taobao;create table t4 (id int not null primary key auto_increment,name varchar(20) not null);"

mysql -S /data/3308/mysql.sock -e "use taobao;create table t4 (id int not null primary key auto_increment,name varchar(20) not null);"

重啟mycat

mycat restart

測試：

mysql -uroot -p123456 -h10.0.0.52 -P8066

use TESTDB

insert into t4(id,name) values(1,'a');

insert into t4(id,name) values(2,'b');

insert into t4(id,name) values(3,'c');

insert into t4(id,name) values(4,'d');

分別登錄后端節(jié)點查詢數(shù)據(jù)

mysql -S /data/3307/mysql.sock

use taobao

select * from t4;

mysql -S /data/3308/mysql.sock

use taobao

select * from t4;

t5 表

id name telnum

1 bj 1212

2 sh 22222

3 bj 3333

4 sh 44444

5 bj 5555

sharding-by-intfile

vim schema.xml

table name="t5" dataNode="sh1,sh2" rule="sharding-by-intfile" /

vim rule.xml

tableRule name="sharding-by-intfile"

rule columnsname/columns

algorithmhash-int/algorithm

/rule

/tableRule

function name="hash-int" class="org.opencloudb.route.function.PartitionByFileMap"

property name="mapFile"partition-hash-int.txt/property

property name="type"1/property

property name="defaultNode"0/property

/function

partition-hash-int.txt 配置：

bj=0

sh=1

DEFAULT_NODE=1

columns 標識將要分片的表字段，algorithm 分片函數(shù)， 其中分片函數(shù)配置中，mapFile標識配置文件名稱

準備測試環(huán)境

mysql -S /data/3307/mysql.sock -e "use taobao;create table t5 (id int not null primary key auto_increment,name varchar(20) not null);"

mysql -S /data/3308/mysql.sock -e "use taobao;create table t5 (id int not null primary key auto_increment,name varchar(20) not null);"

重啟mycat

mycat restart

mysql -uroot -p123456 -h10.0.0.51 -P8066

use TESTDB

insert into t5(id,name) values(1,'bj');

insert into t5(id,name) values(2,'sh');

insert into t5(id,name) values(3,'bj');

insert into t5(id,name) values(4,'sh');

insert into t5(id,name) values(5,'tj');

a b c d

join

t

select t1.name ,t.x from t1

join t

select t2.name ,t.x from t2

join t

select t3.name ,t.x from t3

join t

使用場景：

如果你的業(yè)務(wù)中有些數(shù)據(jù)類似于數(shù)據(jù)字典，比如配置文件的配置，

常用業(yè)務(wù)的配置或者數(shù)據(jù)量不大很少變動的表，這些表往往不是特別大，

而且大部分的業(yè)務(wù)場景都會用到，那么這種表適合于Mycat全局表，無須對數(shù)據(jù)進行切分，

要在所有的分片上保存一份數(shù)據(jù)即可，Mycat 在Join操作中，業(yè)務(wù)表與全局表進行Join聚合會優(yōu)先選擇相同分片內(nèi)的全局表join，

避免跨庫Join，在進行數(shù)據(jù)插入操作時，mycat將把數(shù)據(jù)分發(fā)到全局表對應(yīng)的所有分片執(zhí)行，在進行數(shù)據(jù)讀取時候?qū)S機獲取一個節(jié)點讀取數(shù)據(jù)。

vim schema.xml

table name="t_area" primaryKey="id" type="global" dataNode="sh1,sh2" /

后端數(shù)據(jù)準備

mysql -S /data/3307/mysql.sock

use taobao

create table t_area (id int not null primary key auto_increment,name varchar(20) not null);

mysql -S /data/3308/mysql.sock

use taobao

create table t_area (id int not null primary key auto_increment,name varchar(20) not null);

重啟mycat

mycat restart

測試：

mysql -uroot -p123456 -h10.0.0.52 -P8066

use TESTDB

insert into t_area(id,name) values(1,'a');

insert into t_area(id,name) values(2,'b');

insert into t_area(id,name) values(3,'c');

insert into t_area(id,name) values(4,'d');

A

join

B

為了防止跨分片join，可以使用E-R模式

A join B

on a.xx=b.yy

join C

on A.id=C.id

table name="A" dataNode="sh1,sh2" rule="mod-long"

childTable name="B" joinKey="yy" parentKey="xx" /

/table

mysql做主從架構(gòu)，編寫sql時，要注意些什么

有兩種方法，一種方法使用mysql的check table和repair table 的sql語句，另一種方法是使用MySQL提供的多個myisamchk, isamchk數(shù)據(jù)檢測恢復(fù)工具。前者使用起來比較簡便。推薦使用。

1. check table 和 repair table

登陸mysql 終端：

mysql -uxxxxx -p dbname

check table tabTest;

如果出現(xiàn)的結(jié)果說Status是OK，則不用修復(fù)，如果有Error，可以用：

repair table tabTest;

進行修復(fù)，修復(fù)之后可以在用check table命令來進行檢查。在新版本的phpMyAdmin里面也可以使用check/repair的功能。

2. myisamchk, isamchk

其中myisamchk適用于MYISAM類型的數(shù)據(jù)表，而isamchk適用于ISAM類型的數(shù)據(jù)表。這兩條命令的主要參數(shù)相同，一般新的系統(tǒng)都使用MYISAM作為缺省的數(shù)據(jù)表類型，這里以myisamchk為例子進行說明。當發(fā)現(xiàn)某個數(shù)據(jù)表出現(xiàn)問題時可以使用：

myisamchk tablename.MYI

進行檢測，如果需要修復(fù)的話，可以使用：

myisamchk -of tablename.MYI

關(guān)于myisamchk的詳細參數(shù)說明，可以參見它的使用幫助。需要注意的時在進行修改時必須確保MySQL服務(wù)器沒有訪問這個數(shù)據(jù)表，保險的情況下是最好在進行檢測時把MySQL服務(wù)器Shutdown掉。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

另外可以把下面的命令放在你的rc.local里面啟動MySQL服務(wù)器前：

[ -x /tmp/mysql.sock ] /pathtochk/myisamchk -of /DATA_DIR/*/*.MYI

其中的/tmp/mysql.sock是MySQL監(jiān)聽的Sock文件位置，對于使用RPM安裝的用戶應(yīng)該是/var/lib/mysql/mysql.sock，對于使用源碼安裝則是/tmp/mysql.sock可以根據(jù)自己的實際情況進行變更，而pathtochk則是myisamchk所在的位置，DATA_DIR是你的MySQL數(shù)據(jù)庫存放的位置。

需要注意的時，如果你打算把這條命令放在你的rc.local里面，必須確認在執(zhí)行這條指令時MySQL服務(wù)器必須沒有啟動！檢測修復(fù)所有數(shù)據(jù)庫(表)

五大常見的MySQL高可用方案(最全)

1. 概述

我們在考慮MySQL數(shù)據(jù)庫的高可用的架構(gòu)時，主要要考慮如下幾方面：

如果數(shù)據(jù)庫發(fā)生了宕機或者意外中斷等故障，能盡快恢復(fù)數(shù)據(jù)庫的可用性，盡可能的減少停機時間，保證業(yè)務(wù)不會因為數(shù)據(jù)庫的故障而中斷。

用作備份、只讀副本等功能的非主節(jié)點的數(shù)據(jù)應(yīng)該和主節(jié)點的數(shù)據(jù)實時或者最終保持一致。

當業(yè)務(wù)發(fā)生數(shù)據(jù)庫切換時，切換前后的數(shù)據(jù)庫內(nèi)容應(yīng)當一致，不會因為數(shù)據(jù)缺失或者數(shù)據(jù)不一致而影響業(yè)務(wù)。

關(guān)于對高可用的分級在這里我們不做詳細的討論，這里只討論常用高可用方案的優(yōu)缺點以及高可用方案的選型。

2. 高可用方案

2.1. 主從或主主半同步復(fù)制

使用雙節(jié)點數(shù)據(jù)庫，搭建單向或者雙向的半同步復(fù)制。在5.7以后的版本中，由于lossless replication、logical多線程復(fù)制等一些列新特性的引入，使得MySQL原生半同步復(fù)制更加可靠。

常見架構(gòu)如下：

通常會和proxy、keepalived等第三方軟件同時使用，即可以用來監(jiān)控數(shù)據(jù)庫的 健康 ，又可以執(zhí)行一系列管理命令。如果主庫發(fā)生故障，切換到備庫后仍然可以繼續(xù)使用數(shù)據(jù)庫。

優(yōu)點：

架構(gòu)比較簡單，使用原生半同步復(fù)制作為數(shù)據(jù)同步的依據(jù)；

雙節(jié)點，沒有主機宕機后的選主問題，直接切換即可；

雙節(jié)點，需求資源少，部署簡單；

缺點：

完全依賴于半同步復(fù)制，如果半同步復(fù)制退化為異步復(fù)制，數(shù)據(jù)一致性無法得到保證；

需要額外考慮haproxy、keepalived的高可用機制。

2.2. 半同步復(fù)制優(yōu)化

半同步復(fù)制機制是可靠的。如果半同步復(fù)制一直是生效的，那么便可以認為數(shù)據(jù)是一致的。但是由于網(wǎng)絡(luò)波動等一些客觀原因，導致半同步復(fù)制發(fā)生超時而切換為異步復(fù)制，那么這時便不能保證數(shù)據(jù)的一致性。所以盡可能的保證半同步復(fù)制，便可提高數(shù)據(jù)的一致性。

該方案同樣使用雙節(jié)點架構(gòu)，但是在原有半同復(fù)制的基礎(chǔ)上做了功能上的優(yōu)化，使半同步復(fù)制的機制變得更加可靠。

可參考的優(yōu)化方案如下：

2.2.1. 雙通道復(fù)制

半同步復(fù)制由于發(fā)生超時后，復(fù)制斷開，當再次建立起復(fù)制時，同時建立兩條通道，其中一條半同步復(fù)制通道從當前位置開始復(fù)制，保證從機知道當前主機執(zhí)行的進度。另外一條異步復(fù)制通道開始追補從機落后的數(shù)據(jù)。當異步復(fù)制通道追趕到半同步復(fù)制的起始位置時，恢復(fù)半同步復(fù)制。

2.2.2. binlog文件服務(wù)器

搭建兩條半同步復(fù)制通道，其中連接文件服務(wù)器的半同步通道正常情況下不啟用，當主從的半同步復(fù)制發(fā)生網(wǎng)絡(luò)問題退化后，啟動與文件服務(wù)器的半同步復(fù)制通道。當主從半同步復(fù)制恢復(fù)后，關(guān)閉與文件服務(wù)器的半同步復(fù)制通道。

優(yōu)點：

雙節(jié)點，需求資源少，部署簡單；

架構(gòu)簡單，沒有選主的問題，直接切換即可;

相比于原生復(fù)制，優(yōu)化后的半同步復(fù)制更能保證數(shù)據(jù)的一致性。

缺點：

需要修改內(nèi)核源碼或者使用mysql通信協(xié)議。需要對源碼有一定的了解，并能做一定程度的二次開發(fā)。

依舊依賴于半同步復(fù)制，沒有從根本上解決數(shù)據(jù)一致性問題。

2.3. 高可用架構(gòu)優(yōu)化

將雙節(jié)點數(shù)據(jù)庫擴展到多節(jié)點數(shù)據(jù)庫，或者多節(jié)點數(shù)據(jù)庫集群。可以根據(jù)自己的需要選擇一主兩從、一主多從或者多主多從的集群。

由于半同步復(fù)制，存在接收到一個從機的成功應(yīng)答即認為半同步復(fù)制成功的特性，所以多從半同步復(fù)制的可靠性要優(yōu)于單從半同步復(fù)制的可靠性。并且多節(jié)點同時宕機的幾率也要小于單節(jié)點宕機的幾率，所以多節(jié)點架構(gòu)在一定程度上可以認為高可用性是好于雙節(jié)點架構(gòu)。

但是由于數(shù)據(jù)庫數(shù)量較多，所以需要數(shù)據(jù)庫管理軟件來保證數(shù)據(jù)庫的可維護性。可以選擇MMM、MHA或者各個版本的proxy等等。常見方案如下：

2.3.1. MHA+多節(jié)點集群

MHA Manager會定時探測集群中的master節(jié)點，當master出現(xiàn)故障時，它可以自動將最新數(shù)據(jù)的slave提升為新的master，然后將所有其他的slave重新指向新的master，整個故障轉(zhuǎn)移過程對應(yīng)用程序完全透明。

MHA Node運行在每臺MySQL服務(wù)器上，主要作用是切換時處理二進制日志，確保切換盡量少丟數(shù)據(jù)。

MHA也可以擴展到如下的多節(jié)點集群：

優(yōu)點：

可以進行故障的自動檢測和轉(zhuǎn)移;

可擴展性較好，可以根據(jù)需要擴展MySQL的節(jié)點數(shù)量和結(jié)構(gòu);

相比于雙節(jié)點的MySQL復(fù)制，三節(jié)點/多節(jié)點的MySQL發(fā)生不可用的概率更低

缺點：

至少需要三節(jié)點，相對于雙節(jié)點需要更多的資源;

邏輯較為復(fù)雜，發(fā)生故障后排查問題，定位問題更加困難;

數(shù)據(jù)一致性仍然靠原生半同步復(fù)制保證，仍然存在數(shù)據(jù)不一致的風險;

可能因為網(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)點：

較好的保證了整個系統(tǒng)的高可用性，包括proxy、MySQL;

擴展性較好，可以擴展為大規(guī)模集群;

缺點：

數(shù)據(jù)一致性仍然依賴于原生的mysql半同步復(fù)制;

引入zk，整個系統(tǒng)的邏輯變得更加復(fù)雜;

2.4. 共享存儲

共享存儲實現(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相比）連接，通過這種連接實現(xiàn)數(shù)據(jù)的集中式存儲。常用架構(gòu)如下：

使用共享存儲時，MySQL服務(wù)器能夠正常掛載文件系統(tǒng)并操作，如果主庫發(fā)生宕機，備庫可以掛載相同的文件系統(tǒng)，保證主庫和備庫使用相同的數(shù)據(jù)。

優(yōu)點：

兩節(jié)點即可，部署簡單，切換邏輯簡單；

很好的保證數(shù)據(jù)的強一致性；

不會因為MySQL的邏輯錯誤發(fā)生數(shù)據(jù)不一致的情況；

缺點：

需要考慮共享存儲的高可用；

價格昂貴；

2.4.2. DRBD磁盤復(fù)制

DRBD是一種基于軟件、基于網(wǎng)絡(luò)的塊復(fù)制存儲解決方案，主要用于對服務(wù)器之間的磁盤、分區(qū)、邏輯卷等進行數(shù)據(jù)鏡像，當用戶將數(shù)據(jù)寫入本地磁盤時，還會將數(shù)據(jù)發(fā)送到網(wǎng)絡(luò)中另一臺主機的磁盤上，這樣的本地主機(主節(jié)點)與遠程主機(備節(jié)點)的數(shù)據(jù)就可以保證實時同步。常用架構(gòu)如下：

當本地主機出現(xiàn)問題，遠程主機上還保留著一份相同的數(shù)據(jù)，可以繼續(xù)使用，保證了數(shù)據(jù)的安全。

DRBD是linux內(nèi)核模塊實現(xiàn)的快級別的同步復(fù)制技術(shù)，可以與SAN達到相同的共享存儲效果。

優(yōu)點：

兩節(jié)點即可，部署簡單，切換邏輯簡單；

相比于SAN儲存網(wǎng)絡(luò)，價格低廉；

保證數(shù)據(jù)的強一致性；

缺點：

對io性能影響較大；

從庫不提供讀操作；

2.5. 分布式協(xié)議

分布式協(xié)議可以很好解決數(shù)據(jù)一致性問題。比較常見的方案如下：

2.5.1. MySQL cluster

MySQL cluster是官方集群的部署方案，通過使用NDB存儲引擎實時備份冗余數(shù)據(jù)，實現(xiàn)數(shù)據(jù)庫的高可用性和數(shù)據(jù)一致性。

優(yōu)點：

全部使用官方組件，不依賴于第三方軟件；

可以實現(xiàn)數(shù)據(jù)的強一致性；

缺點：

國內(nèi)使用的較少；

配置較復(fù)雜，需要使用NDB儲存引擎，與MySQL常規(guī)引擎存在一定差異；

至少三節(jié)點；

2.5.2. Galera

基于Galera的MySQL高可用集群， 是多主數(shù)據(jù)同步的MySQL集群解決方案，使用簡單，沒有單點故障，可用性高。常見架構(gòu)如下：

優(yōu)點：

多主寫入，無延遲復(fù)制，能保證數(shù)據(jù)強一致性；

有成熟的社區(qū)，有互聯(lián)網(wǎng)公司在大規(guī)模的使用；

自動故障轉(zhuǎn)移，自動添加、剔除節(jié)點；

缺點：

需要為原生MySQL節(jié)點打wsrep補丁

只支持innodb儲存引擎

至少三節(jié)點；

2.5.3. POAXS

Paxos 算法解決的問題是一個分布式系統(tǒng)如何就某個值（決議）達成一致。這個算法被認為是同類算法中最有效的。Paxos與MySQL相結(jié)合可以實現(xiàn)在分布式的MySQL數(shù)據(jù)的強一致性。常見架構(gòu)如下：

優(yōu)點：

多主寫入，無延遲復(fù)制，能保證數(shù)據(jù)強一致性；

有成熟理論基礎(chǔ)；

自動故障轉(zhuǎn)移，自動添加、剔除節(jié)點；

缺點：

只支持innodb儲存引擎

至少三節(jié)點；

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服務(wù)器架構(gòu)可擴展性特點

服務(wù)器架構(gòu)隨著應(yīng)用場景的不同采用的架構(gòu)方式也是不一樣的，而今天我們就通過案例分析來簡單學習一下，在服務(wù)器架構(gòu)中的可擴展性都有哪些特點。

MySQL的可擴展性

架構(gòu)的可擴展性往往和并發(fā)是息息相關(guān)，沒有并發(fā)的增長，也就沒有必要做高可擴展性的架構(gòu)，這里對可擴展性進行簡單介紹一下，常用的擴展手段有以下兩種

Scale-up:縱向擴展，通過替換為更好的機器和資源來實現(xiàn)伸縮，提升服務(wù)能力

Scale-out:橫向擴展,通過加節(jié)點(機器)來實現(xiàn)伸縮，提升服務(wù)能力

對于互聯(lián)網(wǎng)的高并發(fā)應(yīng)用來說，無疑Scaleout才是出路，通過縱向的買更的機器一直是我們所避諱的問題，也不是長久之計，在scaleout的理論下，可擴展性的理想狀態(tài)是什么?

可擴展性的理想狀態(tài)

一個服務(wù)，當面臨更高的并發(fā)的時候，能夠通過簡單增加機器來提升服務(wù)支撐的并發(fā)度，且增加機器過程中對線上服務(wù)無影響(nodowntime)，這就是可擴展性的理想狀態(tài)!

MySQL架構(gòu)的演變

MySQL簡單網(wǎng)站架構(gòu)(V1.0)

一個簡單的小型網(wǎng)站或者應(yīng)用背后的架構(gòu)可以非常簡單,數(shù)據(jù)存儲只需要一個mysqlinstance就能滿足數(shù)據(jù)讀取和寫入需求(這里忽略掉了數(shù)據(jù)備份的實例)，處于這個時間段的網(wǎng)站，一般會把所有的信息存到一個databaseinstance里面。

在這樣的架構(gòu)下，電腦培訓來看看數(shù)據(jù)存儲的瓶頸是什么?

單實例單業(yè)務(wù)，依然存在V1.0所述瓶頸，遇到瓶頸時可以考慮往本文更高V版本升級,若是讀請求導致達到性能瓶頸可以考慮往V3.0升級，其他瓶頸考慮往V4.0升級

網(wǎng)站標題：mysql架構(gòu)怎么做 Mysql架構(gòu)圖
文章網(wǎng)址：http://vcdvsql.cn/article2/dopejic.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供軟件開發(fā)、商城網(wǎng)站、手機網(wǎng)站建設(shè)、品牌網(wǎng)站制作、網(wǎng)站策劃、微信公眾號

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)