?
-
3.深入了解復(fù)制
?
3.1、基于語句的復(fù)制(Statement-Based Replication)MySQL 5.0及之前的版本僅支持基于語句的復(fù)制(也叫做邏輯復(fù)制,logical replication),這在數(shù)據(jù)庫并不常見。master記錄下改變數(shù)據(jù)的查詢,然后,slave從中繼日志中讀取事件,并執(zhí)行它,這些SQL語句與master執(zhí)行的語句一樣。這種方式的優(yōu)點就是實現(xiàn)簡單。此外,基于語句的復(fù)制的二進制日志可以很好的進行壓縮,而且日志的數(shù)據(jù)量也較小,占用帶寬少——例如,一個更新GB的數(shù)據(jù)的查詢僅需要幾十個字節(jié)的二進制日志。而mysqlbinlog對于基于語句的日志處理十分方便。 但是,基于語句的復(fù)制并不是像它看起來那么簡單,因為一些查詢語句依賴于master的特定條件,例如,master與slave可能有不同的時間。所以,MySQL的二進制日志的格式不僅僅是查詢語句,還包括一些元數(shù)據(jù)信息,例如,當前的時間戳。即使如此,還是有一些語句,比如,CURRENT USER函數(shù),不能正確的進行復(fù)制。此外,存儲過程和觸發(fā)器也是一個問題。 另外一個問題就是基于語句的復(fù)制必須是串行化的。這要求大量特殊的代碼,配置,例如InnoDB的next-key鎖等。并不是所有的存儲引擎都支持基于語句的復(fù)制。
3.2、基于記錄的復(fù)制(Row-Based Replication) MySQL增加基于記錄的復(fù)制,在二進制日志中記錄下實際數(shù)據(jù)的改變,這與其它一些DBMS的實現(xiàn)方式類似。這種方式有優(yōu)點,也有缺點。優(yōu)點就是可以對任何語句都能正確工作,一些語句的效率更高。主要的缺點就是二進制日志可能會很大,而且不直觀,所以,你不能使用mysqlbinlog來查看二進制日志。對于一些語句,基于記錄的復(fù)制能夠更有效的工作,如:mysql> INSERT INTO summary_table(col1, col2, sum_col3) -> SELECT col1, col2, sum(col3) -> FROM enormous_table -> GROUP BY col1, col2; 假設(shè),只有三種唯一的col1和col2的組合,但是,該查詢會掃描原表的許多行,卻僅返回三條記錄。此時,基于記錄的復(fù)制效率更高。 另一方面,下面的語句,基于語句的復(fù)制更有效: mysql> UPDATE enormous_table SET col1 = 0;此時使用基于記錄的復(fù)制代價會非常高。由于兩種方式不能對所有情況都能很好的處理,所以,MySQL 5.1支持在基于語句的復(fù)制和基于記錄的復(fù)制之前動態(tài)交換。你可以通過設(shè)置session變量binlog_format來進行控制。
3.3、復(fù)制相關(guān)的文件除了二進制日志和中繼日志文件外,還有其它一些與復(fù)制相關(guān)的文件。如下:
(1)mysql-bin.index服務(wù)器一旦開啟二進制日志,會產(chǎn)生一個與二日志文件同名,但是以.index結(jié)尾的文件。它用于跟蹤磁盤上存在哪些二進制日志文件。MySQL用它來定位二進制日志文件。
(2)mysql-relay-bin.index該文件的功能與mysql-bin.index類似,但是它是針對中繼日志,而不是二進制日志。
(3)master.info保存從服務(wù)器連接至主服務(wù)時所需要的信息,每行一個值保存master的相關(guān)信息。不要刪除它,否則,slave重啟后不能連接master。
(4)relay-log.info 保存了復(fù)制位置:包括二進制日志和中繼日志的文件及位置。
3.4、發(fā)送復(fù)制事件到其它slave
當設(shè)置log_slave_updates時,你可以讓slave扮演其它slave的master。此時,slave把SQL線程執(zhí)行的事件寫進行自己的二進制日志(binary log),然后,它的slave可以獲取這些事件并執(zhí)行它。如下:
QTlBTWGdZZUFBR09GMUtqaHNVMTI0LmpwZw==" border="0" height="349" hspace="0" src="http://www.it165.net/uploadfile/files/2014/0419/201404190833212.jpg" title="yyyy.jpg" vspace="0" width="733" />
?
3.5、復(fù)制過濾(Replication Filters)
復(fù)制過濾可以讓你只復(fù)***務(wù)器中的一部分數(shù)據(jù),有兩種復(fù)制過濾:在master上過濾二進制日志中的事件;在slave上過濾中繼日志中的事件。如下:
?
4.復(fù)制的常用拓撲結(jié)構(gòu)復(fù)制的體系結(jié)構(gòu)有以下一些基本原則:(1)每個slave可以有一個或多個master;(2)每個slave只能有一個唯一的服務(wù)器ID;(3)每個master可以有很多slave;(4)如果設(shè)置log_slave_updates,slave可以是其它slave的master,從而擴散master的更新。
在早期的 MySQL 是不支持多主服務(wù)器復(fù)制(Multimaster Replication)——即一個slave可以有多個master的場景,但是MariaDB目前已經(jīng)支持。但是,通過一些簡單的組合,我們卻可以建立靈活而強大的復(fù)制體系結(jié)構(gòu)。
?
4.1、單一master和多slave由一個master和一個slave組成復(fù)制系統(tǒng)是最簡單的情況。Slave之間并不相互通信,只能與master進行通信。
在實際應(yīng)用場景中, MySQL 復(fù)制90%以上都是一個Master復(fù)制到一個或者多個Slave的架構(gòu)模式,主要用于讀壓力比較大的應(yīng)用的數(shù)據(jù)庫端廉價擴展解決方案。因為只要Master和Slave的壓力不是太大(尤其是Slave端壓力)的話,異步復(fù)制的延時一般都很少很少。尤其是自從Slave端的復(fù)制方式改成兩個線程處理之后,更是減小了Slave端的延時問題。而帶來的效益是,對于數(shù)據(jù)實時性要求不是特別Critical的應(yīng)用,只需要通過廉價的pcserver來擴展Slave的數(shù)量,將讀壓力分散到多臺Slave的機器上面,即可通過分散單臺數(shù)據(jù)庫服務(wù)器的讀壓力來解決數(shù)據(jù)庫端的讀性能瓶頸,畢竟在大多數(shù)數(shù)據(jù)庫應(yīng)用系統(tǒng)中的讀壓力還是要比寫壓力大很多。這在很大程度上解決了目前很多中小型網(wǎng)站的數(shù)據(jù)庫壓力瓶頸問題,甚至有些大型網(wǎng)站也在使用類似方案解決數(shù)據(jù)庫瓶頸。
如下:
如果寫操作較少,而讀操作很時,可以采取這種結(jié)構(gòu)。你可以將讀操作分布到其它的slave,從而減小master的壓力。但是,當slave增加到一定數(shù)量時,slave對master的負載以及網(wǎng)絡(luò)帶寬都會成為一個嚴重的問題。這種結(jié)構(gòu)雖然簡單,但是,它卻非常靈活,足夠滿足大多數(shù)應(yīng)用需求。一些建議:(1) 不同的slave扮演不同的作用(例如使用不同的索引,或者不同的存儲引擎);(2) 用一個slave作為備用master,只進行復(fù)制;(3) 用一個遠程的slave,用于災(zāi)難恢復(fù);大家應(yīng)該都比較清楚,從一個Master節(jié)點可以復(fù)制出多個Slave節(jié)點,可能有人會想,那一個Slave節(jié)點是否可以從多個Master節(jié)點上面進行復(fù)制呢?這是完全可以實現(xiàn)的,目前在MariaDB中已經(jīng)實現(xiàn)multi-master replication 功能;可參考《MariaDB多源(主)復(fù)制》
?
4.2、主動模式的Master-Master(Master-Master in Active-Active Mode)Master-Master復(fù)制的兩臺服務(wù)器,既是master,又是另一臺服務(wù)器的slave。這樣,任何一方所做的變更,都會通過復(fù)制應(yīng)用到另外一方的數(shù)據(jù)庫中??赡苡行┳x者朋友會有一個擔心,這樣搭建復(fù)制環(huán)境之后,難道不會造成兩臺MySQL之間的循環(huán)復(fù)制么?實際上MySQL自己早就想到了這一點,所以在MySQL的BinaryLog中記錄了當前MySQL的server-id,而且這個參數(shù)也是我們搭建MySQLReplication的時候必須明確指定,而且Master和Slave的server-id參數(shù)值比需要不一致才能使MySQLReplication搭建成功。一旦有了server-id的值之后,MySQL就很容易判斷某個變更是從哪一個MySQLServer最初產(chǎn)生的,所以就很容易避免出現(xiàn)循環(huán)復(fù)制的情況。而且,如果我們不打開記錄Slave的BinaryLog的選項(--log-slave-update)的時候,MySQL根本就不會記錄復(fù)制過程中的變更到BinaryLog中,就更不用擔心可能會出現(xiàn)循環(huán)復(fù)制的情形了。如圖:
主動的Master-Master復(fù)制有一些特殊的用處。例如,地理上分布的兩個部分都需要自己的可寫的數(shù)據(jù)副本。這種結(jié)構(gòu)最大的問題就是更新沖突。假設(shè)一個表只有一行(一列)的數(shù)據(jù),其值為1,如果兩個服務(wù)器分別同時執(zhí)行如下語句:在第一個服務(wù)器上執(zhí)行:mysql> UPDATE tbl SET col=col + 1;在第二個服務(wù)器上執(zhí)行:mysql> UPDATE tbl SET col=col * 2;那么結(jié)果是多少呢?一臺服務(wù)器是4,另一個服務(wù)器是3,但是,這并不會產(chǎn)生錯誤。實際上,MySQL并不支持其它一些DBMS支持的多主服務(wù)器復(fù)制(Multimaster Replication),這是MySQL的復(fù)制功能很大的一個限制(多主服務(wù)器的難點在于解決更新沖突),但是,如果你實在有這種需求,你可以采用MySQL Cluster,以及將Cluster和Replication結(jié)合起來,可以建立強大的高性能的數(shù)據(jù)庫平臺。但是,可以通過其它一些方式來模擬這種多主服務(wù)器的復(fù)制。
?
示例:雙主模式配置 :
?
環(huán)境:
Master1/Master2 Platfrom IP APP Version Master1 CentOS6.5_X86-64 172.16.41.1 mariadb-10.0.10 Master2 CentOS6.5_X86-64 172.16.41.2 mariadb-10.0.10 1.配置雙主:
#Master1的配置:
?
(1)修改server-id主配置文件/etc/my.cnf [mysqld]段中,修改如下行:?
server-id = 1 主配置文件/etc/my.cnf [mysqld]段中,修改如下行:
log-bin = /mydata/binlogs/master1-bin
relay-log = /mydata/relaylogs/relay-bin
?
確保中繼日志選項開啟
MariaDB [(none)]> SHOW GLOBAL VARIABLES LIKE 'relay_log';+---------------+-----------------------------+| Variable_name | Value |+---------------+-----------------------------+| relay_log | /mydata/relaylogs/relay-bin |+---------------+-----------------------------+1 row in set (0.00 sec)
?
auto-increment-offset = 1 //起始值
auto-increment-increment = 2 //步長
?
確保自動增長選項已開啟:
MariaDB [(none)]> SHOW GLOBAL VARIABLES LIKE 'auto_inc%';
+--------------------------+-------+
| Variable_name | Value |
+--------------------------+-------+
| auto_increment_increment | 2 |
| auto_increment_offset | 1 |
+--------------------------+-------+
?
(4)創(chuàng)建有復(fù)制權(quán)限的用戶,命令如下:
?
MariaDB [(none)]> CREATE USER 'luccy'@'172.16.41.2' IDENTIFIED BY 'qazwsx123';MariaDB [(none)]> REVOKE ALL PRIVILEGES ,GRANT OPTION FROM 'luccy'@'172.16.41.2';MariaDB [(none)]> GRANT RELOAD,LOCK TABLES, REPLICATION CLIENT ,REPLICATION SLAVE ON *.* TO 'luccy'@'172.16.41.2'; MariaDB [(none)]> FLUSH PRIVILEGES;
?
#Master2的配置:
(1)修改server-id#
?
主配置文件/etc/my.cnf [mysqld]段中,修改如下行:?
server-id = 2 ?
log-bin = /mydata/binlogs/master2-bin
relay-log = /mydata/relaylogs/relay-bin
確保中繼日志選項開啟
MariaDB [(none)]> SHOW GLOBAL VARIABLES LIKE 'relay_log';+---------------+-----------------------------+| Variable_name | Value |+---------------+-----------------------------+| relay_log | /mydata/relaylogs/relay-bin |+---------------+-----------------------------+
?
(3)添加下面兩項,以避免在MySQL自動為INSERT語句選擇不互相沖突的值
auto-increment-offset = 2 //起始值
auto-increment-increment = 2 //步長
?
?
確保自動增長選項已開啟:
MariaDB [(none)]> SHOW GLOBAL VARIABLES LIKE 'auto_inc%';
+--------------------------+-------+
| Variable_name | Value |
+--------------------------+-------+
| auto_increment_increment | 2 |
| auto_increment_offset | 2 |
+--------------------------+-------+
(4)創(chuàng)建有復(fù)制權(quán)限的用戶,命令如下:
?
MariaDB [(none)]> CREATE USER 'jerry'@'172.16.41.1' IDENTIFIED BY 'qazwsx123';MariaDB [(none)]> REVOKE ALL PRIVILEGES ,GRANT OPTION FROM 'jerry'@'172.16.41.1';MariaDB [(none)]> GRANT RELOAD,LOCK TABLES, REPLICATION CLIENT ,REPLICATION SLAVE ON *.* TO 'jerry'@'172.16.41.1'; MariaDB [(none)]> FLUSH PRIVILEGES;
如果此時兩臺服務(wù)器均為新建立,且無其它寫入操作,各服務(wù)器只需記錄當前自己二進制日志文件及事件位置,以之作為另外的服務(wù)器復(fù)制起始位置即可
#Master1:
?
MariaDB [(none)]> SHOW MASTER STATUS;
+--------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+--------------------+----------+--------------+------------------+
| master1-bin.000001 | 969 | | |
+--------------------+----------+--------------+------------------+
#Master2:
?
?
MariaDB [(none)]> SHOW MASTER STATUS;
+--------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+--------------------+----------+--------------+------------------+
| master2-bin.000001 | 314 | | |
+--------------------+----------+--------------+------------------+
各服務(wù)器接下來指定對另一臺服務(wù)器為自己的主服務(wù)器
#Master1指向Master2 MariaDB [(none)]> CHANGE MASTER TO MASTER_USER='luccy',MASTER_HOST='172.16.41.2',MASTER_PASSWORD='qazwsx123',MASTER_LOG_FILE='master2-bin.000005',MASTER_LOG_POS=328;
?
#Master2指向Master1
MariaDB [(none)]> CHANGE MASTER TO MASTER_USER='jerry',MASTER_HOST='172.16.41.1',MASTER_PASSWORD='qazwsx123',MASTER_LOG_FILE='master1-bin.000005',MASTER_LOG_POS=1592;
啟動個服務(wù)器復(fù)制進程
#Master1
MariaDB [(none)]> START SLAVE;
MariaDB [mysql]> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 172.16.41.2
Master_User: jerry
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: master2-bin.000006
Read_Master_Log_Pos: 328
Relay_Log_File: relay-bin.000004
Relay_Log_Pos: 617
Relay_Master_Log_File: master2-bin.000006
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
..........
..........
?
#Master2
MariaDB [(none)]> START SLAVE;
?
MariaDB [(none)]> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 172.16.41.1
Master_User: luccy
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: master1-bin.000005
Read_Master_Log_Pos: 1592
Relay_Log_File: relay-bin.000002
Relay_Log_Pos: 537
Relay_Master_Log_File: master1-bin.000005
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
.......... ..........
?
雙主測試:
(1)在Master1上創(chuàng)建數(shù)據(jù)庫 testdb:
MariaDB [(none)]> CREATE DATABASE testdb;
MariaDB [(none)]> SHOW DATABASES;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| test |
| testdb |
+--------------------+
在Master2上查看結(jié)果與在Master1上所查得結(jié)果一樣!
(2)在Master1上創(chuàng)建數(shù)據(jù)庫 mydb:
MariaDB [(none)]> SHOW DATABASES;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mydb |
| mysql |
| performance_schema |
| test |
| testdb |
+--------------------+
在Master1上查看結(jié)果與在Master2上所查得結(jié)果一樣!
(3)在Master1的mydb上面新建一張表mytable1,并插入語句
MariaDB [(none)]> use mydb
MariaDB [mydb]> CREATE TABLE mytable1 (ID INT AUTO_INCREMENT UNIQUE KEY, Name CHAR(20));
MariaDB [mydb]> DESC mytable1;
+-------+----------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------+----------+------+-----+---------+----------------+
| ID | int(11) | NO | PRI | NULL | auto_increment |
| Name | char(20) | YES | | NULL | |
+-------+----------+------+-----+---------+----------------+
MariaDB [mydb]> INSERT INTO mytable1(Name) VALUES ('larry'),('jim'),('jerry');
Query OK, 3 rows affected (0.01 sec)
Records: 3 Duplicates: 0 Warnings: 0
?
MariaDB [mydb]> SELECT * FROM mytable1;
+----+-------+
| ID | Name |
+----+-------+
| 1 | larry| //自動增長的效果,在Master1上定義的起始值為1,步徑為2
| 3 | jim |
| 5 | jerry|
+----+-------+
在Master2上面插入字段(以上內(nèi)容已經(jīng)同步到Master2)
MariaDB [mydb]>INSERT INTO mytable1(Name) VALUES ('Zhang San'),('Li Si'),('Wang Wu');
MariaDB [mydb]> SELECT * FROM mytable1;
+----+-----------+
| ID | Name |
+----+-----------+
| 1 | larry |
| 3 | jim |
| 5 | jerry |
| 6 | Zhang San |
| 8 | Li Si |
| 10 | Wang Wu |
+----+-----------+
//看來不是想要的結(jié)果,雖然說MySQL自動為INSERT選擇的值不會再出現(xiàn)互相沖突的情況,但是貌似沒有按數(shù)字排序,找不到解決這個問題的辦法,除非不選擇用雙主模式!
? 4.3、主動-被動模式的Master-Master(Master-Master in Active-Passive Mode)
這是master-master結(jié)構(gòu)變化而來的,它避免了M-M的缺點,實際上,這是一種具有容錯和高可用性的系統(tǒng)。它的不同點在于其中一個服務(wù)只能進行只讀操作。如圖:
?
?
4.4 級聯(lián)復(fù)制架構(gòu) Master –Slaves - Slaves
在有些應(yīng)用場景中,可能讀寫壓力差別比較大,讀壓力特別的大,一個Master可能需要上10臺甚至更多的Slave才能夠支撐注讀的壓力。這時候,Master就會比較吃力了,因為僅僅連上來的SlaveIO線程就比較多了,這樣寫的壓力稍微大一點的時候,Master端因為復(fù)制就會消耗較多的資源,很容易造成復(fù)制的延時。
遇到這種情況如何解決呢?這時候我們就可以利用MySQL可以在Slave端記錄復(fù)制所產(chǎn)生變更的BinaryLog信息的功能,也就是打開—log-slave-update選項。然后,通過二級(或者是更多級別)復(fù)制來減少Master端因為復(fù)制所帶來的壓力。也就是說,我們首先通過少數(shù)幾臺MySQL從Master來進行復(fù)制,這幾臺機器我們姑且稱之為第一級Slave集群,然后其他的Slave再從第一級Slave集群來進行復(fù)制。從第一級Slave進行復(fù)制的Slave,我稱之為第二級Slave集群。如果有需要,我們可以繼續(xù)往下增加更多層次的復(fù)制。這樣,我們很容易就控制了每一臺MySQL上面所附屬Slave的數(shù)量。這種架構(gòu)我稱之為Master-Slaves-Slaves架構(gòu)
這種多層級聯(lián)復(fù)制的架構(gòu),很容易就解決了Master端因為附屬Slave太多而成為瓶頸的風險。下圖展示了多層級聯(lián)復(fù)制的Replication架構(gòu)。
當然,如果條件允許,我更傾向于建議大家通過拆分成多個Replication集群來解決
上述瓶頸問題。畢竟Slave并沒有減少寫的量,所有Slave實際上仍然還是應(yīng)用了所有的數(shù)據(jù)變更操作,沒有減少任何寫IO。相反,Slave越多,整個集群的寫IO總量也就會越多,我們沒有非常明顯的感覺,僅僅只是因為分散到了多臺機器上面,所以不是很容易表現(xiàn)出來。
此外,增加復(fù)制的級聯(lián)層次,同一個變更傳到最底層的Slave所需要經(jīng)過的MySQL也會更多,同樣可能造成延時較長的風險。而如果我們通過分拆集群的方式來解決的話,可能就會要好很多了,當然,分拆集群也需要更復(fù)雜的技術(shù)和更復(fù)雜的應(yīng)用系統(tǒng)架構(gòu)。
4.5、帶從服務(wù)器的Master-Master結(jié)構(gòu)(Master-Master with Slaves)這種結(jié)構(gòu)的優(yōu)點就是提供了冗余。在地理上分布的復(fù)制結(jié)構(gòu),它不存在單一節(jié)點故障問題,而且還可以將讀密集型的請求放到slave上。
級聯(lián)復(fù)制在一定程度上面確實解決了Master因為所附屬的Slave過多而成為瓶頸的問題,但是他并不能解決人工維護和出現(xiàn)異常需要切換后可能存在重新搭建Replication的問題。這樣就很自然的引申出了DualMaster與級聯(lián)復(fù)制結(jié)合的Replication架構(gòu),我稱之為Master-Master-Slaves架構(gòu)
和Master-Slaves-Slaves架構(gòu)相比,區(qū)別僅僅只是將第一級Slave集群換成了一臺單獨的Master,作為備用Master,然后再從這個備用的Master進行復(fù)制到一個Slave集群。
這種DualMaster與級聯(lián)復(fù)制結(jié)合的架構(gòu),最大的好處就是既可以避免主Master的寫入操作不會受到Slave集群的復(fù)制所帶來的影響,同時主Master需要切換的時候也基本上不會出現(xiàn)重搭Replication的情況。但是,這個架構(gòu)也有一個弊端,那就是備用的Master有可能成為瓶頸,因為如果后面的Slave集群比較大的話,備用Master可能會因為過多的SlaveIO線程請求而成為瓶頸。當然,該備用Master不提供任何的讀服務(wù)的時候,瓶頸出現(xiàn)的可能性并不是特別高,如果出現(xiàn)瓶頸,也可以在備用Master后面再次進行級聯(lián)復(fù)制,架設(shè)多層Slave集群。當然,級聯(lián)復(fù)制的級別越多,Slave集群可能出現(xiàn)的數(shù)據(jù)延時也會更為明顯,所以考慮使用多層級聯(lián)復(fù)制之前,也需要評估數(shù)據(jù)延時對應(yīng)用系統(tǒng)的影響。
延伸閱讀:
? MariaDB/Mysql之主從架構(gòu)的復(fù)制原理及主從/雙主配置詳解(一)
?
更多文章、技術(shù)交流、商務(wù)合作、聯(lián)系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號聯(lián)系: 360901061
您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
