網際網路行業資料庫相關中介軟體介紹與實踐！

這裡主要介紹網際網路行業內有關資料庫的相關中介軟體。資料庫相關平臺主要解決以下三個方面的問題：

• 為海量前臺資料提供高效能、大容量、高可用性的訪問

• 為資料變更的消費提供準實時的保障

• 高效的異地資料同步

應用層通過分表分庫中介軟體訪問資料庫，包括讀操作（Select）和寫操作（update, insert和delete等，DDL, DCL）。寫操作會在資料庫上產生變更記錄，MySQL的變更記錄叫binlog, Oracle的稱之為redolog, 增量資料訂閱與消費中介軟體解析這些變更，並以統一的格式儲存起來，下層應用根據這些資料進行消費應用。當然，在資料庫與資料庫本身之間也會有資料庫遷移的操作，這種操作可以不需要增量資料訂閱與消費中介軟體的資料，而可以自行處理。

資料庫中介軟體有以下幾種：

• 分散式資料庫分表分庫

• 資料增量訂閱與消費

• 資料庫同步（全量、增量、跨機房、複製）

• 跨資料庫（資料來源）遷移

整個產品族圖如下：

• 最上層的是分散式資料庫分表分庫中介軟體，負責和上層應用打交道，對應用可表現為一個獨立的資料庫，而遮蔽底層複雜的系統細節。分散式資料庫中介軟體除了基本的分表分庫功能，還可以豐富一下，比如講讀寫分離或者水平擴容功能整合在一起，或者比如讀寫分離本身也可以作為一個獨立的中介軟體。（Cobar, MyCAT, TDDL, DRDS, DDB）

• 增量資料訂閱和消費，使用者對資料庫操作，比如DML, DCL, DDL等，這些操作會產生增量資料，下層應用可以通過監測這些增量資料進行相應的處理。典型代表Canal，根據MySQL的binlog實現。也有針對Oracle(redolog)的增量資料訂閱與消費的中介軟體。（Canal, Erosa）

• 資料庫同步中介軟體涉及資料庫之間的同步操作，可以實現跨（同）機房同步以及異地容災備份、分流等功能。可以涉及多種資料庫，處理之後的資料也可以以多種形式儲存。（Otter, JingoBus, DRC）

• 資料庫與資料庫之間會有資料遷移（同步）的動作，同款資料同步原理比較簡單，比如MySQL主備同步，只要在資料庫層進行相應的配置既可，但是跨資料庫同步就比較複雜了，比如Oracle->MySQL. 資料遷移一般包括三個步驟：全量複製，將原資料庫的資料全量遷移到新資料庫，在這遷移的過程中也會有新的資料產生；增量同步，對新產生的資料進行同步，並持續一段時間以保證資料同步；原庫停寫，切換新庫。將“跨資料庫”這個含義擴大一下——“跨資料來源”，比如HDFS, HBase, FTP等都可以相互同步。（yugong, DataX）

分散式資料庫

隨著網際網路產品在體量和規模上日益膨脹，無論是Oracle還是MySQL，都會第一時間面臨來自磁碟，CPU和記憶體等單機瓶頸，為此，產品方除了需要不斷購買成本難以控制的高規格伺服器，還要面臨不斷迭代的線上資料遷移。在這種情況下，無論是海量的結構化資料還是快速成長的業務規模，都迫切需要一種水平擴充套件的方法將儲存成本分攤到成本可控的商用伺服器上。同時，也希望通過線性擴容降低全量資料遷移對線上服務帶來的影響，分庫分表方案便應運而生。

分表分庫類的中介軟體主要有兩種形式嚮應用提供服務：

• 一種是以JDBC的jar包形式為Java應用提供直接依賴，Java應用通過提供的JDBC包實現透明訪問分散式資料庫叢集中的各個分庫分表，典型代表網易的DDB和阿里的TDDL.

• 另一種是為應用部署獨立的服務來滿足應用分庫分表的需求，在這種方式下通過標準JDBC訪問Proxy，而Proxy則根據MySQL標準通訊協議對客戶端請求解析，還原應用SQL請求，然後通過本地訪問資料庫叢集，最後再將得到的結果根據MySQL標準通訊協議編碼返回給客戶端。典型代表阿里的Cobar, Cobar變種MyCAT, 阿里的DRDS，網易的DDB proxy模式以及DDB的私有云模式。

Cobar

Cobar 是提供關係型資料庫（MySQL）分散式服務的中介軟體，它可以讓傳統的資料庫得到良好的線性擴充套件，並看上去還是一個資料庫，對應用保持透明。

Cobar以Proxy的形式位於前臺應用和實際資料庫之間，對前臺的開放的介面是MySQL通訊協議。將前臺SQL語句變更並按照資料分佈規則發到合適的後臺資料分庫，再合併返回結果，模擬單庫下的資料庫行為。

Cobar屬於阿里B2B事業群，始於2008年，在阿里服役3年多，接管3000+個MySQL資料庫的schema,叢集日處理線上SQL請求50億次以上。由於Cobar發起人的離職，Cobar停止維護。後續的類似中介軟體，比如MyCAT建立於Cobar之上，包括現在阿里服役的RDRS其中也複用了Cobar-Proxy的相關程式碼。

Cobar結構

• 與應用之間通過MySQL protocol進行互動，是一個proxy的結構，對外暴露jdbc:mysql://CobarIP:port/schema。對應用透明。

• 無需引入新的jar包，從訪問遷移到資料庫訪問Cobar可以複用原有的基於JDBC的DAO。

• Cobar前後端都實現了MySQL協議，當接受到SQL請求時，會一次進行解釋（SQL Parser）和路由（SQL Router）工作，然後使用SQL Executor去後端模組獲取資料集（後端模組還負責心跳檢查功能）；如果資料集來自多個資料來源，Cobar則需要把資料集進行組合（Result Merge），最後返回響應。

• 資料庫連線複用。Cobar使用連線詞與後臺真是資料庫進行互動。（實際應用中，根據應用的不同，使用proxy結構後資料庫連線數能夠節約2-10倍不等。）

• Cobar事務，Cobar在單庫的情況下保持事務的強一致性，分庫的情況下保持事務的弱一致性，分庫事務採用2PC協議，包括執行階段和提交階段。

Cobar的前端是NIO的，而後端跟MySQL互動是阻塞模式，其NIO程式碼只給出了框架，還沒有來得及實現。 據稱未開源版的Cobar實現了後端的NIO。 

Cobar會出現假死，假死以後Cobar會頻繁進行主從切換（如果配置了的話），自動切換本身也存在隱患。

可以計算：Cobar的TPS=5,000,000,000/(3000*24*60*60)=20。

與Cobar相關的還有一共Cobar-Client.

Cobar通過SQL語句轉發的方式實現資料訪問。使用者發來的SQL語句，Cobar解析其內容，判斷該語句所涉及的資料分佈在哪個分庫上，再將語句轉發給此分庫執行。當SQL語句中涉及的拆分欄位有多值，如 IN, 或where條件中沒有出現拆分欄位時，該語句將會轉發至後臺所有分庫執行，再將執行結果以MySQL協議包的形式送回應用端。

通訊模組，負責從連續的網路資料流中識別出一個個MySQL協議包，再解析協議包識別出SQL語句輸出給Parser模組，同時，把Result Merge模組輸入的執行結果，編碼成MySQL的協議包。它以NIO方式實現，有很高的執行效率。之後進行優化，引入了一個ByteBuffer池，將NIO的Buffer統一管理起來，減少了NIO資料互動時的垃圾回收。

Cobar前端使用的是優化後的NIO通訊模組，為了讓該模組在後端使用，Cobar去除了JDBC。與後端資料庫互動，Cobar直接面向協議，目前實現了基於MySQL協議的後端互動。

水平拆分後，後臺有多個資料來源，對他們的管理分為兩個層次：DataNode和replica(HA Pool)。 
DataNode管理拆分，一個DataNode存放一個分片的資料，彼此無資料交集。每個分片的資料存多份以保證高可用，每一份叫做一個replica，由HA層管理。每一個replica表示一個具體的資料來源，它是一個連線池，池內管理每一個具體的JDBC連線。路由運算只關注到DataNode層，之下的層次對其不可見。 
每一份replica之間的資料複製和同步由MySQL本身的replication協議完成，同一時刻只有一個replica提供服務（稱為Master，其餘replica稱為Slave）.Cobar會與之保持心跳，一旦發現它不可用，會切換至另一個replica，解決Oracle單點的第二個問題。

為了節省資料庫的機器數量，可以採用下圖中的方式部署：

HA

在使用者配置了MySQL心跳的情況下，Cobar可以自動向後端連線的MySQL發生心跳，判斷MySQL執行狀況，一旦執行出現異常，Cobar可以自動切換到備機工作，但需要強調的是：

1. Cobar的主備切換有兩種觸發方式，一種是使用者手動觸發，一種是Cobar的心跳語句檢測到異常後自動觸發。那麼，當心跳檢測到主機異常，切換到備機，如果主機恢復了，需要使用者手動切回主機工作，Cobar不會在主機恢復時自動切換回主機，除非備機的心跳也返回異常。

2. Cobar只檢查MySQL主備異常，不關心主備之間的資料同步，因此使用者需要在使用Cobar之前在MySQL主備上配置雙向同步，詳情可以參閱MySQL參考手冊。

Cobar解決的問題

分散式：Cobar的分散式主要是通過將表放入不同的庫來實現。

1. Cobar支援將一張表水平拆分成多份分別放入不同的庫來實現表的水平拆分

2. Cobar也支援將不同的表放入不同的庫

3. 多數情況下，使用者將以上兩種方式混合使用

這裡需要強調的是，Cobar不支援將一張表，例如test表拆分成test_1, test_2, test_3….放在同一個庫中，必須拆分後的表分別放入不同的庫來實現分散式。

Cobar的約束

1. 不支援跨庫情況下的join、分頁、排序、子查詢操作

2. SET語句執行會被忽略，事務和字符集設定除外

3. 分庫情況下，insert語句必須包括拆分欄位列名

4. 分庫情況下，update語句不能更新拆分欄位的值

5. 不支援SAVEPOINT操作

6. 暫時只支援MySQL資料節點

7. 使用JDBC時，不支援rewriteBatchedStatements=true引數設定（預設為false）

8. 使用JDBC時，不支援useServerPrepStmts=true引數設定（預設為false)

9. 使用JDBC時，BLOB, BINARY, VARBINARY欄位不能使用setBlob()或setBinaryStream()方法設定引數

MyCAT

從定義和分類看，它是一個開源的分散式資料庫系統，是一個實現了MySQL協議的Server，前端使用者可以把它看做是一個資料庫代理，用MySQL客戶端工具和命令列訪問，而其後端可以用MySQL Native Protocol與多個MySQL伺服器通訊，也可以用JDBC協議與大多數主流資料庫伺服器通訊，其核心功能是分表分庫，即將一個大表水平分割為N個小表，儲存在後端MySQL伺服器裡或者其他資料庫裡。

MyCAT發展到目前的版本，已經不是一個單純的MySQL代理了，它的後端可以支援MySQL, SQL Server, Oracle, DB2, PostgreSQL等主流資料庫，也支援MongoDB這種新型NoSQL方式的儲存，未來還會支援更多型別的儲存。

MyCAT是一個強大的資料庫中介軟體，不僅僅可以用作讀寫分離，以及分表分庫、容災管理，而且可以用於多租戶應用開發、雲平臺基礎設施，讓你的架構具備很強的適應性和靈活性，藉助於即將釋出的MyCAT只能優化模組，系統的資料訪問瓶頸和熱點一目瞭然，根據這些統計分析資料，你可以自動或手工調整後端儲存，將不同的表隱射到不同儲存引擎上，而整個應用的程式碼一行也不用改變。

MyCAT是在Cobar基礎上發展的版本，兩個顯著提高：

• 後端由BIO改為NIO，併發量有大幅提高；

• 增加了對Order By, Group By, Limit等聚合功能（雖然Cobar也可以支援Order By, Group By, Limit語法，但是結果沒有進行聚合，只是簡單返回給前端，聚合功能還是需要業務系統自己完成）

MyCAT架構

• 事務是弱XA

• MyCAT的原理中最重要的一個動詞是“攔截”，它攔截了使用者發來的SQL語句，首先對SQL語句做了一些特定的分析：如分片分析，路由分析、讀寫分離分析、快取分析等，然後將此SQL發往後端的真實資料庫，並將返回的結果做適當的處理，最終再返回給使用者。

• MyCAT對自身不支援的SQL語句提供了一種解決方案——在要執行的SQL語句前新增額外的一段由註解SQL組織的程式碼，這樣SQL就能正確執行，這段程式碼稱之為“註解”。註解的使用相當於對MyCAT不支援的SQL語句做了一層透明代理轉發，直接交給目標的資料節點進行SQL語句執行。

• MyCAT自身有類似其他資料庫的管理監控方式，可以通過MySQL命令列，登入管理埠（9066）執行相應的SQL進行管理，也可以通過jdbc的方式進行遠端連線管理。

HA

MyCAT作為一個代理層中介軟體，MyCAT系統的高可用設計到MyCAT本身的高可用以及後端MySQL的高可用. 在多數情況下，建議採用MySQL主從複製高可用性配置並交付給MyCAT來完成後端MySQL節點的主從自動切換。

MySQL側的HA

• MySQL節點開啟主從複製的配置方案，並將主節點配置為MyCAT的dataHost裡的writeNode，從節點配置為readNode，同時MyCAT內部定期對一個dataHost裡的所有writeHost與readHost節點發起心跳檢測。

• 正常情況下，MyCAT將第一個writeHost作為寫節點，所有的DML SQL會傳送此節點。

• 若MyCAT開啟了讀寫分離，則查詢節點會根據讀寫分離的策略發往readHost(+writeHost)執行。

• 如果第一個writeHost當機，MyCAT會在預設的三次心跳檢測失敗後，自動切換到下一個可用的writeHost執行DML SQL語句

• 當原來配置的MySQL寫節點當機恢復後，作為從節點，跟隨新的主節點，重新配置主從同步。

MyCAT自身的HA

• 官方建議是採用基於硬體的負載聚亨或者軟體方式的HAproxy等。

• 如果還擔心HAproxy的穩定性和但節點問題，則可以用keepalived的VIP的浮動功能，加以強化。

MyCAT功能和特性

• 支援SQL 92標準

• 支援Mysql叢集，可以作為Proxy使用

• 支援JDBC連線多資料庫

• 支援NoSQL資料庫

• 支援galera sfor mysql叢集，percona-cluster或者mariadb cluster，提供高可用性分片叢集

• 自動故障切換，高可用性

• 支援讀寫分離，支援MySQL雙主多從，以及一主多從的模式

• 支援全域性表，資料自動分片到多個節點，用於高效表關聯查詢

• 支援一致性Hash分片，有效解決分片擴容難題

• 多平臺支援，部署和試試簡單

• 支援Catelet開發，類似資料庫儲存過程，用於跨分片複雜SQL的人工智慧編碼實現

• 支援NIO與AIO兩種網路通訊機制，windows下建議AIO,Linux下目前建議NIO

• 支援MySQL儲存過程呼叫

• 以外掛的方式支援SQL攔截和改寫

• 支援自增長逐漸、支援Oracle的Sequence機制

• 支援Mysql, MongoDB，Oracle, SQL Server, Hive, DB2, PostgreSQL等。

MyCAT目前的專案

• MyCAT-Server:MyCAT核心服務

• MyCAT-Spider:MyCAT爬蟲技術

• MyCAT-ConfigCenter:MyCAT配置中心

• MyCAT-BigSQL:MyCAT大資料處理（暫未更細）

• MyCAT-Web:MyCAT監控及web（新版開發中）

• MyCAT-Balance:MyCAT負載均衡（暫未更細）

DRDS/TDDL

alibaba. Distributed Relational Database Service.

阿里分散式資料庫DRDS的前身是淘寶分散式資料庫層TDDL，大概在2012年的時候，阿里開始嘗試將TDDL這套體系輸出到阿里雲上，也有了一個新的名字：DRDS.

TDDL

Tabao根據自己的業務特點開發了TDDL(Tabao Distributed Data Layer, 外號：頭都大了)。主要解決了分庫分表對應用的透明化以及異構資料庫之間的資料複製，它是一個基於集中式配置的jdbc datasourcce實現，具有主備，讀寫分離，動態資料庫配置等功能。

TDDL並非獨立的中介軟體，只能算作中間層，是以Jar包方式提供給應用呼叫。屬於JDBC Shard的思想。

TDDL處於業務層和JDBC層中間。

TDDL其實主要可以劃分為3層架構，分別是Matrix層，Group層和Atom層。Matrix層用於實現分庫分表邏輯，底層多個Group例項。而Group和Atom共同組成了動態資料來源，Group層實現了資料庫的Master/Slave模式的寫分離邏輯，底層持有多個Atom例項。最後Atom層（持有資料來源）實現資料庫ip, port, password, connectionProperties等資訊的動態推送，以及持有院子的資料來源分離的JBoss資料來源。

TDDL社群處於停滯狀態，網上可查資源也較少。

RDRS

DRDS/TDDL是阿里巴巴自主研發的分散式資料庫服務。DRDS脫胎於阿里巴巴開源的Cobar分散式資料庫引擎，吸收了Cobar核心的Cobar-Proxy原始碼，實現了一套獨立的類似MySQL-Proxy協議的解析端，能夠對傳入的SQL進行解析和處理，對應用程式遮蔽各種複雜的底層DB拓撲結構，獲得單機資料庫一樣的使用體驗，同時借鑑了淘寶TDDL豐富的分散式資料庫實踐經驗，實現了對分散式Join支援，SUM/MAX/COUNT/AVG等聚合函式支援以及排序等函式支援，通過異構索引、小表廣播等解決分散式資料庫使用場景下衍生出的一系列問題，最終形成了完整的分散式資料庫方案。

DRDS在整個阿里系統中所處的位置：

對於很多應用而言，單機資料庫最終都會碰到單機效能上的天花板，在TPS/QPS/記憶體容量/磁碟容量等等一系列系統資源上會碰到各類限制。DRDS的主要目標就是幫您解決這方面的各類問題，他主要提供了兩個功能，讀寫分離和資料庫切分:

• 讀寫分離，能夠執行實現一臺機器寫入，多臺機器讀取，這對於讀多寫少的應用，能夠以極低的成本解決系統的瓶頸。

• 資料庫切分是一個解決系統儲存瓶頸的最終極解決方案，資料庫切分的核心思想其實很簡單，就是分而治之。將資料分散到多臺機器，並保證請求能夠平均的分發到這些機器上，就可以以極低的成本來解決業務的各類效能瓶頸。當然切分也是有代價的，最明顯的代價就是，分散式資料庫會對一些原有單機資料的場景進行限制，因為這些操作，在分散式環境下的延遲或效率非常低效，就算是能夠實現出來，也會因為效能問題而無法使用。

其他功能特性

1.分散式MySQL執行引擎

主要目標是實現與單機資料庫SQL引擎的完全相容，實現SQL的智慧下推，能夠智慧分析SQL，解析出那些SQL可以直接下發，那些SQL需要進行優化改造，優化成什麼樣，以及路由到哪些例項節點上執行，充分發揮資料庫例項的全部能力，減少網路之間的資料傳輸量，最終對不同例項處理後的少量結果進行聚合計算返回給應用呼叫方。這就是分散式SQL引擎的智慧下推功能。 
分散式引擎的職責包含SQL解析，優化，執行和合並四個流程。

支援市面上幾乎所有的語言（具有MySQL訪問能力的），相容90%以上MySQL語法。

案例分析： 

比如一個簡單的AVG操作，對於一些比較初級的分散式資料庫模型而言，常見做法是把AVG直接下發到所有儲存節點，這樣造成的結果就是語法相容，語義不相容，最終拿到的是錯誤結果。而DRDS的智慧下推引擎，對SQL的語法做充分的語義相容性適配，針對AVG操作，只能由引擎將邏輯AVG SQL解析優化為SUM和COUNT的SQL然後進行下推，由底層的資料庫例項節點完成SUM和COUNT計算，充分利用底層節點的計算能力，在引擎層將各個儲存節點的SUM和COUNT結果聚合計算，最終計算出AVG。

2.線上平滑擴容

線上資料擴容的重點在於“線上”兩字，也就是使用者不需要停止業務進行割接操作，直接就可以新增新的RDS節點到叢集中，實現無縫的自由擴充套件。RDRS則將整個擴容過程分為幾個階段，包括全量遷移，增量同步，切換資料庫等幾個步驟。資料會提前進行搬遷，並進行增量並行同步一段時間，因此，我們可以在非常短的時間內（秒級別）完成資料庫的最終擴容切換工作，對業務沒有影響。

3.小表廣播

在一些大的業務表進行了切分後，總會存在一些表的資料量不大，更新量也不大的原始資訊表。這些表往往會與我們的切分後大表進行join操作，這種操作物理上就會造成分散式join查詢，效率從整體上會比較地下。針對這種分散式join的場景，開發了OETL專用工具來進行小表廣播，將原資訊表的所有資料（包括增量更新）全部自動的廣播到大表的機器上，這樣，就可以讓原來的分散式查詢變成單機本地查詢了。

4.全域性唯一ID

DRDS sequence功能的目標只是為了保證資料的全域性唯一，雖然基本上是按時間序列獲取的，但並不全域性有序。

5.異構索引

解決分散式場景下資料拆分維度和資料查詢使用維度不一致導致的低效問題。

當資料表被拆分為多個分庫分表時，資料在分庫分表的分佈規則就固定了。但是通常資料的業務使用場景非常複雜，如果資料的查詢維度和資料拆分分佈的規則一直，單條SQL會在一個分庫分表上執行；如果資料的查詢使用維度和資料拆分分佈的規格不一致，單條SQL可能在多個分庫分表上執行，出現跨庫查詢，跨庫查詢會增加IO成本，查詢效率必然下降。

解決這個問題的思路還是分散式資料庫的一貫原則，讓SQL執行在單庫上完成，實際採用的方式就是用“空間換效率”的方案，也就是將同一份資料表，冗餘儲存多份，按照不同的業務使用場景進行拆分，保持拆分維度和使用維度統一，而多份資料之間會實時資料複製以解決資料一致性問題，這就是“異構索引”方案。當然異構索引表不能無限制濫用，過多的異構索引表會影響同步效率，對源資料表造成同步壓力。

其他同款中介軟體

Altas, Vitess, Heisenberg, CDS, DDB， OneProxy等等。

Atlas

Qihoo 360. 
Web平臺部基礎架構團隊開發維護的一個基於MySQL協議的資料中間層專案，它是在mysql-proxy 0.8.2版本上對其進行優化，增加了一些新的功能特性。 
Atlas是一個位於應用程式與MySQL之間，它實現了MySQL的客戶端和服務端協議，作為服務端與應用程式通訊，同時作為客戶端與MySQL通訊。它對應用程式遮蔽了DB的細節。 
Altas不能實現分散式分表，所有的字表必須在同一臺DB的同一個DataBase裡且所有的字表必須實現建好，Altas沒有自動建表的功能。

Heisenberg

Baidu. 
其優點：分庫分表與應用脫離，分庫表如同使用單庫表一樣，減少db連線數壓力，熱重啟配置，可水平擴容，遵守MySQL原生協議，讀寫分離，無語言限制，mysqlclient, c, Java都可以使用Heisenberg伺服器通過管理命令可以檢視，如連線數，執行緒池，結點等，並可以調整採用velocity的分庫分表指令碼進行自定義分庫表，相當的靈活。 
（開源版已停止維護）

CDS

JD. Completed Database Sharding. 
CDS是一款基於客戶端開發的分庫分表中介軟體產品，實現了JDBC標準API，支援分庫分表，讀寫分離和資料運維等諸多共，提供高效能，高併發和高可靠的海量資料路由存取服務，業務系統可近乎零成本進行介入，目前支援MySQL, Oracle和SQL Server. 
(架構上和Cobar，MyCAT相似，直接採用jdbc對接，沒有實現類似MySQL協議，沒有NIO,AIO，SQL Parser模組採用JSqlParser, Sql解析器有：druid>JSqlParser>fdbparser.)

DDB

豬場. Distributed DataBase. 
DDB經歷了三次服務模式的重大更迭：Driver模式->Proxy模式->雲模式。

• Driver模式：基於JDBC驅動訪問，提供一個db.jar, 和TDDL類似， 位於應用層和JDBC之間.

• Proxy模式：在DDB中搭建了一組代理伺服器來提供標準的MySQL服務，在代理伺服器內部實現分庫分表的邏輯。應用通過標準資料庫驅動訪問DDB Proxy, Proxy內部通過MySQL解碼器將請求還原為SQL, 並由DDB Driver執行得到結果。

• 私有云模式：基於網易私有云開發的一套平臺化管理工具Cloudadmin, 將DDB原先Master的功能打散，一部分分庫相關功能整合到proxy中，如分庫管理、表管理、使用者管理等，一部分中心化功能整合到Cloudadmin中，如報警監控，此外，Cloudadmin中提供了一鍵部署、自動和手動備份，版本管理等平臺化功能。

資料增量訂閱與消費

基於資料庫增量日誌解析，提供增量資料訂閱&消費，目前主要支援了mysql. 
有關資料增量訂閱與消費的中介軟體回顧一下：

• 增量訂閱和消費模組應當包括binlog日誌抓取，binlog日誌解析，事件分發過濾（EventSink），儲存（EventStore）等主要模組。

• 如果需要確保HA可以採用Zookeeper儲存各個子模組的狀態，讓整個增量訂閱和消費模組實現無狀態化，當然作為consumer(客戶端)的狀態也可以儲存在zk之中。

• 整體上通過一個Manager System進行集中管理，分配資源。

Canal

Canal架構圖：

說明：

• server代表一個canal執行例項，對應於一個jvm

• instance對應於一個資料佇列 （1個server對應1..n個instance)

instance模組：

• eventParser (資料來源接入，模擬slave協議和master進行互動，協議解析)

• eventSink (Parser和Store連結器，進行資料過濾，加工，分發的工作)

• eventStore (資料儲存)

• metaManager (增量訂閱&消費資訊管理器)

說明：一臺機器下部署一個canal，一個canal可以執行多個instance(通過配置destinations等), 一般情況下一個client連線一個instance（每個instance可以配置standby功能）, 可以多個client連線同一個instance，但是同一時刻只能有一個client消費instance的資料，這個通過zookeeper控制。

資料庫同步

Otter

背景：alibaba B2B因為業務的特性，賣家主要集中在國內，買家主要集中在國外，所以衍生出了杭州和美國異地機房的需求，同時為了提升使用者體驗，整個機房的架構為雙A，兩邊均可寫，由此誕生了otter這樣一個產品。

otter第一版本可追溯到04~05年，此次外部開源的版本為第4版，開發時間從2011年7月份一直持續到現在，目前阿里巴巴B2B內部的本地/異地機房的同步需求基本全上了otter4。

基於資料庫增量日誌解析，準實時同步到本地機房或異地機房的mysql/oracle資料庫，一個分散式資料庫同步系統。

工作原理

原理描述：

1. 基於Canal開源產品，獲取資料庫增量日誌資料。

2. 典型管理系統架構，manager(Web管理)+node(工作節點) 
   

• manager執行時推送同步配置到node節點

• node節點將同步狀態反饋到manager上

基於zookeeper，解決分散式狀態排程的，允許多node節點之間協同工作。

Otter的作用

1. 異構庫 
   

• mysql->mysql、oracle. (目前開原版只支援mysql增量，目標庫可以是mysql或者oracle,取決於canal的功能)

單機房同步（資料庫之間RTT(Round-Trip Time)<1ms） 

• 資料庫版本升級

• 資料表遷移

• 非同步二級索引

跨機房同步（比如阿里巴巴國際站就是杭州和美國機房的資料庫同步，RTT>200ms） 

• 機房容災

雙向同步 

• 避免迴環演算法（通用的解決方案，支援大部分關係型資料庫）

• 資料一致性演算法（保證雙A機房模式下，資料保證最終一直性）

檔案同步 

• 站點映象（進行資料複製的同時，複製關聯的圖片，比如複製產品資料，同事複製產品圖片。

單機房複製示意圖

說明： 
- 資料On-Fly, 儘可能不落地，更快的進行資料同步。（開啟node load balance演算法, 如果Node節點S+ETL落在不同的Node上，資料會有個網路傳輸過程） 
- node節點可以有failover/loadBalancer.

SETL

S: Select 
為解決資料來源的差異性，比如接入canal獲取增量資料，也可以接入其他系統獲取其他資料等。

E: Extract

T: Transform

L: Load

類似於資料倉儲的ETL模型，具體可為資料join，資料轉化，資料載入。

跨機房複製示意圖

資料涉及網路傳輸，S/E/T/L幾個階段會分散在2個或者更多Node節點上，多個Node之間通過zookeeper進行協同工作（一般是Select和Extract在一個機房的Node, Transform/Load落在另一個機房的Node） 
node節點可以有failover/loadBalancer。(每個機房的Node節點，都可以是叢集，一臺或者多臺機器)

More:

• Otter排程模型：batch處理+雙節點部署。

• Otter資料入庫演算法

• Otter雙向迴環控制

• Otter資料一致性

• Otter高可用性

• Otter擴充套件性

異地雙活資料架構基礎設施DRC

所謂DRC，就是Data Replication Center的縮寫，資料複製中心。這種複製是同步的，支援異構的，高可用的（有嚴格容災系統，實時性好），支援訂閱分發的。專案期初是為了淘寶異地容災而成立的，用於資料庫之間主備同步，後來採用這套技術方案衍生出了DRC-TAIR, DRC-DUMP等專案。

所謂異地雙活主要關注兩件事，一個資料同步，一個資料分發。

到底怎樣的應用會需要異地的雙活？比較常見的場景有三個：

1. 兩個地域或多個地域都有大量使用者的場景，比如在中國的使用者希望他們用杭州的RDS服務，在美國的使用者用美國的RDS服務，這就需要資料在異地同步。很多遊戲，金融，傳媒，電商業務都有這種需求。滿足這個需求的難點在於跨地域的網路，比如網路延時長，丟包多，而且資料在公網傳輸會有資料洩露風險。

2. 資料來源較多，需要介入各種異構資料的場景。比如一個應用需要從ODPS, RDS, OTS， OceanBase, PostgreSQL這幾個服務介入資料，他們的資料結構和介面都不同，這種接入的成本會比較高。因此另一個可用的方法是資料寫入的時候就一份多謝為不同資料結構

3. 下游訂閱很多的情況，比如一份資料，備份系統、通知系統、大資料分析系統、索引系統等等都要來取，如果用上面一份資料多寫的方案是可以應對的，但這裡還有其他難點，就是資料一致性、可擴充套件性、跨網同步穩定性、以及同步的實時性。

DRC支援讀取集團MySQL, RDS, OceanBase, Hbase, Oracle等多種不同的資料來源的實時增量資料，支援寫入資料庫、MetaQ, ODPS等多種儲存媒介.

以前在一個城市做雙機房主備，兩個機房是資料對等的，寫入是隨機分佈，然後通過主備HA進行資料同步。這樣機房對等的思路會導致業務增長、資料增長只能通過兩個機房不停堆機器來解決。另一方面，如果整個城市斷電，那麼雙活就成了雙死。下一個思路是做跨城市，早期常用的做法是一個城市寫，另一個城市冷備，就是晚上做同步，但這就意味著白天如果發生了什麼事兒，這一天的資料就比較危險。另一個思路是兩個城市多寫，資料落兩邊，這樣的問題是應用呼叫次數頻繁的話，如果呼叫異地資料多來那麼一兩次，整個應用的延時就很長。這個思路再進一步發展，就是做單元內封閉以減少異地呼叫，這就涉及到業務上的改造。

順著這個思路，阿里的異地雙活重點做了幾件事。一個是熱插拔，可以做到在業務高峰時增加節點，高峰過了把增加的節點關閉。做到這個的一個關鍵是流量實時切換 ，DRC可以在20秒以內把一個單元（region）的流量遷移到另一個單元。另一個是資料實時恢復，就是通過一定的冗餘設計，一旦一個單元掛掉了，可以在另一個單元做全量恢復。

異地多活在資料方面的挑戰是非常大的。雙十一期間，交易會激增，所以交易鏈路做了單元化。交易鏈路的資料分為三個維度：買家、賣家、商品。買家之間通常沒有太多交叉，天然的適應這種隔離，而且賣家對延遲的敏感度非常高，所以按照賣家維度切分，在單元內封閉，而賣家和商品都是在中心寫入。

資料方面的兩個核心要求：

1. 一致性，要求賣家和商品一致，單元和中心一致，也就是資料同步不能丟資料，不能錯資料，還要保證事務。

2. 實時性，需要做到秒級別的延遲。

雙單元的同步架構有兩種： 
一種是讀寫分離的方式，中心寫，單元讀。單元需要的資料如果沒有從中心及時同步過來，或者同步錯了，那有問題這段時間的交易會全部收到影響。這裡的核心是，保證秒級延遲，同時保證一致性。（JD的多中心交易系統就採用了這種方式）

第二種同步架構是單元封閉的方式。中心和單元各有寫入，我們通過冗餘是的中心和單元隨時可以各自接管。（類似Otter）

這裡的關鍵是：

• 避免迴圈複製：通過在DB透傳打標事務的方式實現。

• 限流：峰值的壓力，我們單元化本來就選取了流量激增業務，兩邊都實時同步100%全量資料，峰值對每個系統的壓力有增無減。DRC的store和congo都可以根據TPS或者流量限流。限速演算法的核心思想分為批量取樣，獎懲時間，平滑變速。

Otter與DRC的區別： 
- Otter是阿里B2B的產品，DRC是阿里技術保障團隊的產品 
- Otter是針對MySQL的，DRC可以支援多種型別的資料來源 
- DRC從業務上進行了劃分，可以實現單元內封閉，Otter的實現不涉及業務，而是在純資料庫層打通的技術 
- Otter是雙寫，DRC是中心寫、分中心讀，或者都部分寫，相互同步。 
- Otter所處的網路環境較DRC差，解決一致性問題也較複雜（基於trusted source的單向環回的補救，基於時間交集的補救），DRC有兩種實現方式，具體參考上面。

異地多活中DRC的核心能力就是在低延遲，一致性和高可用。

• 一致性：基於日誌流式抓取、回放庫表結構變更、基於事務的衝突檢測。

• 低延遲：最大延遲不超過1s, 訊息協議優化，三級資料儲存，預讀優化IO, 多連線複用和傳輸壓縮，高效的併發複製演算法。

• 高可用：主備切換，拓撲變化，心跳跟蹤，多維度容災。

JD多中心交易系統

JD資料複製中介軟體考察和借鑑了開源社群的實現，例如Databus、Canal/Otter、OpenReplicator等，解析部分使用了Canal的DBSync。

多中心交易本質上是一個更大的分散式系統，交易流程中依賴和產生的資料和服務有不同的特點，必然涉及到資料分割槽、路由、複製、讀寫一致性、延遲等分散式領域的常見問題。

其中，資料一致性是電商網站需要面臨的首要問題，越是流量增大的時候越要保證資料更新的即時性和準確性。在多中心之間需要同步賣家資料和商品資料，如果同步的延時太長，買家、賣家都不可接受。比如，賣家改了價格或庫存，使用者不能過很久才看到。同樣，資料正確性也是很大的挑戰，賣掉的商品能夠及時減少，退貨的商品能夠及時增加。這都時刻考驗著後端系統和資料庫平臺的健壯性。

除了資料一致性之外，如何保證路由規則的一致性也是關鍵性的問題。從技術角度來說，要保障單一使用者從登入到訪問服務、到訪問資料庫，全鏈路的路由規則都是完全一致的。如果路由錯誤，看到的資料不正確，也會影響到終端使用者的體驗。 架構

系統包括一個主中心和多個分中心，主中心與分中心之間通過資料匯流排交換資料。資料流向中，主資料(商品資料、商家資料、使用者資料等)的流向從主中心通過資料匯流排實時同步到分中心，分中心只讀；而交易資料(訂單資料)的流向從分中心實時同步到主中心；在故障時，會從分中心轉移到主中心。

在這個系統中，有多處體現分流的概念。首先，買家訪問京東網站下單時，會被優先分流到附近的交易中心；其次，根據交易系統的特點，接單前（包括購物車、結算頁等），多中心交易按使用者維度分流，如下圖所示。使用者登入時，查詢使用者與區域的對映關係表（類似你是哪個片區的），標識此使用者屬於哪個分中心，並儲存標識到cookie中，然後將使用者路由到指定的分中心。使用者訪問其他系統，如購物車和結算頁時，從cookie中讀取標識，重定向到相應分中心頁面。

通過分流，將使用者分配到相應的分中心，一方面響應速度快，使用者體驗更好，不用跨地域訪問資料中心了；另一方面，每個中心服務一定數量的使用者，水平擴充套件性好，也能支撐更大的交易規模了。當然，多資料中心不能盲目幹活，還考慮到容災備份的問題。（支付寶光纖事件）

交易系統包括應用和資料部分，應用部分是無狀態的，就是說，這些工作是無差別的，一臺伺服器出問題，我換一臺伺服器來處理就是了，較容易實現多機房多活。但是資料不一樣，多中心交易本質上是一個更大的分散式系統，必然涉及到資料分割槽、路由、複製、讀寫一致性、延遲等分散式領域的常見問題。

另外，交易流程中依賴和產生的資料和服務有不同的特點。比如商品、促銷和價格、庫存的讀服務，我們可以將之稱為基礎主資料，它們在使用者下單流程中是無法分割槽的，否則無法實現單機房內流量閉環，也就是說，不能因為分割槽資料的不一致，導致同一使用者在單一流程中看到不同的資料（假如你加入購物車時是促銷20塊，結賬是25塊，你會不會表情扭曲？）而商品、促銷和價格的寫服務,是給採銷、第三方POP商家應用呼叫的，這種業務場景的可用性目標，主機房部署和冷備模式即可滿足，而且業務人員的操作流程會抵消寫複製延遲。

簡單來說，資料的問題表現在以下幾個方面：一、 如何保證資料的即時性和準確性，多中心之間需要同步賣家資料和商品資料，如果同步的延時太長,買家、賣家都不可接受，由於是異地部署，最好延時能控制在1秒內。比如，賣家改了價格或庫存，使用者不能過很久才看到。同樣，資料正確性也是很大的挑戰,因為資料故障跟應用層故障不一樣，應用出故障了，可能隻影響使用者訪問；資料寫錯了無法恢復。2、如何保證路由規則的一致性，要保障這個使用者從進來到訪問服務，到訪問資料庫，全鏈路的路由規則都是完全一致的；如果路由錯誤，看到的資料不正確。

從同城雙機房的分佈轉變為異地多機房的分佈，給資料同步帶來了新的挑戰，因此如何設計資料匯流排也是專案能否實現的關鍵因素。京東的多中心交易系統通過資料匯流排JingoBus進行快速資料交換，同步效能是mysql的3倍以上，而且可用性高，架構靈活。其中，全新的匯流排設計解決了多中心交易跨機房的資料庫複製和多資料來源間的資料異構同步等難題，實現了高效能、低延時、健壯的資料同步機制。

如圖所示，資料匯流排主要分Relay、Snapshot和Replicator三部分構成，其中Relay從來源資料庫抽取事務日誌，並對Replicator提供日誌訂閱服務，角色上相當於Mysql Slave IO Thread。Snapshot從Relay訂閱所有事務日誌，寫入持久儲存作為快照，同時向Replicator提供批量日誌訂閱服務，角色上相當於Mysql Slave Relay Log。Replicator：事務日誌的消費端，從Relay或Snapshot拉取事務日誌將事務日誌按配置的一致性應用到目標資料庫，角色上相當於Mysql Slave SQL Thread。(參考下面MySQL主備複製原理圖)

正常情況下，Replicator直接連線Relay，消費Relay記憶體佇列中的事務日誌。但有些情況下，因為網路抖動、目標庫的負載過高等因素，可能導致Replicator相對Relay落後很多。另外，當新的消費端加入同一資料來源的訂閱者時，新消費端有冷啟動的問題。為了避免重新從資料來源做全量快照，Snapshot作為Relay的一個特殊消費端，通過一種高吞吐的消費方式，從Relay源源不斷的消費線上事務日誌，通過對事務日誌的有效處理，最終儲存了資料來源的一份一致快照(Consistent Snapshot)，即包括了資料來源庫表中每一行的最新狀態的快照，同時保留了一段比Relay buffer更舊的事務日誌(Log Store)。由此看來，資料匯流排作為一個資料層的通用CDC元件，對於多中心交易專案以及非同步複製場景提供了整體解決方案，奠定了專案的核心內容。

跨資料庫（資料來源）遷移

yugong

去Oracle資料遷移同步工具。定位：資料庫遷移（目前主要支援Oracle->mysql/DRDS）

08年左右，阿里巴巴開始嘗試MySQL的相關研究，並開發了基於MySQL分庫分表技術的相關產品，Cobar/TDDL(目前為阿里雲DRDS產品)，解決了單機Oracle無法滿足的擴充套件性問題，當時也掀起一股去IOE專案的浪潮，愚公這專案因此而誕生，其要解決的目標就是幫助使用者完成從Oracle資料遷移到MySQL上，完成去IOE的第一步.

概述

整個資料遷移過程，分為兩個部分：

1. 全量遷移

2. 增量遷移

過程描述：

1. 增量資料收集（建立Oracle表的增量物化檢視）

2. 進行全量複製

3. 進行增量複製（可並行進行資料校驗）

4. 原庫停寫，切換到新庫

Oracle全量基於JDBC拉取資料，增量基於物化檢視來實現。

架構

說明：

1. 一個JVM Container 對應多個instance，每個instance對應於一張表的遷移任務

2. instance分為三部分 
   

• extractor (從資料來源庫上提取資料，可分為全量/增量實現)

• translator （將源庫上的資料按照目標庫的需求進行自定義轉化）

• applier（將資料更新到目標庫，可分為全量/增量/對比的實現）

自定義資料轉換

如果要遷移的Oracle和mysql的表結構不同，比如表名，欄位名有差異，欄位型別不相容，需要使用自定義資料轉換。如果完全相同則可以跳過。

整個資料流為：DB->Extractor->DataTranslator->Applier->DB, 本程式預留DataTranslator介面（僅支援Java），允許外部使用者自定義資料處理邏輯。比如：

1. 表名不同

2. 欄位名不同

3. 欄位型別不同

4. 欄位個數不同

5. 執行過程join其他表的資料做計算等

執行模式介紹

1.MARK模式（MARK）

開啟增量日誌模式，如果是Oracle就是建立物化檢視（materialized view）。

2.CLEAR模式（CLEAR）

清理增量日誌的機率，如果是Oracle就是刪除物化檢視

3.全量模式（FULL)

全量模式，顧名思議即為對源表進行一次全量操作，遍歷源表所有的資料後，插入目標表.

全量有兩種處理方式：

1. 分頁處理：如果源表存在主鍵，只有一個主鍵欄位，並且主鍵欄位型別為Number型別，預設會選擇該分頁處理模式. 優點：支援斷點續做，對源庫壓力相對較小。 缺點：遷移速度慢

2. once處理：通過select * from訪問整個源表的某一個mvcc版本的資料，通過cursor.next遍歷整個結果集. 優點：遷移速度快，為分頁處理的5倍左右。 缺點：源庫壓力大，如果源庫併發修改量大，會導致資料庫MVCC版本過多，出現棧錯誤. 還有就是不支援斷點續做.

4.增量模式（INC）

全量模式，顧名思議即為對源表增量變化的資料插入目標表，增量模式依賴記錄日誌功能.

目前增量模式的記錄日誌功能，是通過oracle的物化檢視功能。

5.自動模式(ALL)

自動模式，是對全量+增量模式的一種組合，自動化執行，減少操作成本.

自動模式的內部實現步驟：

1. 開啟記錄日誌功能. (建立物化檢視)

2. 執行全量同步模式. (全量完成後，自動進入下一步)

3. 執行增量同步模式. (增量模式，沒有完成的概念，所以也就不會自動退出，需要業務判斷是否可以退出，可以看一下切換流程)

6.對比模式(CHECK)

對比模式，即為對源庫和目標庫的資料進行一次全量對比，驗證一下遷移結果. 對比模式為一種可選執行，做完全量/增量/自動模式後，可選擇性的執行對比模式，來確保本次遷移的正確性.

DataX

DataX是一個在異構的資料庫/檔案系統之間高速交換資料的工具，實現了在任意的資料處理系統(RDBMS/Hdfs/Local filesystem）之間的資料交換。

目前成熟的資料匯入匯出工具比較多，但是一般都只能用於資料匯入或者匯出，並且只能支援一個或者幾個特定型別的資料庫。

這樣帶來的一個問題是，如果我們擁有很多不同型別的資料庫/檔案系統(Mysql/Oracle/Rac/Hive/Other…)，並且經常需要在它們之間匯入匯出資料，那麼我們可能需要開發/維護/學習使用一批這樣的工具(jdbcdump/dbloader/multithread/getmerge+sqlloader/mysqldumper…)。而且以後每增加一種庫型別，我們需要的工具數目將線性增長。(當我們需要將mysql的資料匯入oracle的時候，有沒有過想從jdbcdump和dbloader上各掰下來一半拼在一起到衝動？)這些工具有些使用檔案中轉資料，有些使用管道，不同程度的為資料中轉帶來額外開銷，效率差別很非常大。很多工具也無法滿足ETL任務中常見的需求，比如日期格式轉化，特性字元的轉化，編碼轉換。另外，有些時候，我們希望在一個很短的時間視窗內，將一份資料從一個資料庫同時匯出到多個不同型別的資料庫。DataX正是為了解決這些問題而生。

• 左圖：新增第n+1個資料來源，是不是需要開發n個資料同步工具？

• 右圖：只需要針對新增的資料來源開發一套Reader/Writer外掛，即可實現任意資料的互導。

設計理念

為了解決異構資料來源同步問題，DataX將複雜的網狀的同步鏈路變成了星型資料鏈路，DataX作為中間傳輸載體負責連線各種資料來源。當需要接入一個新的資料來源的時候，只需要將此資料來源對接到DataX，便能跟已有的資料來源做到無縫資料同步。DataX在阿里巴巴集團內被廣泛使用，承擔了所有大資料的離線同步業務，並已持續穩定執行了6年之久。目前每天完成同步8w多道作業，每日傳輸資料量超過300TB。

框架設計

DataX本身作為離線資料同步框架，採用Framework+plugin架構構建。將資料來源讀取和寫入抽象稱為Reader/Writer外掛，納入到整個同步框架中。

• Reader： Reader為資料採集模組，負責採集資料來源的資料，將資料傳送給Framework.

• Writer：Writer為資料寫入模組，負責不斷向Framework取資料，並將資料寫入到目的端

• Framework：Framework用於連線reader和writer,作為兩者的資料傳輸通道，並處理快取，流控，併發，資料轉換等核心技術問題。

DataX框架內部通過雙緩衝佇列、執行緒池封裝等技術，集中處理了高速資料交換遇到的問題，提供簡單的介面與外掛互動，外掛分為Reader和Writer兩類，基於框架提供的外掛介面，可以十分便捷的開發出需要的外掛。比如想要從oracle匯出資料到mysql，那麼需要做的就是開發出OracleReader和MysqlWriter外掛，裝配到框架上即可。並且這樣的外掛一般情況下在其他資料交換場合是可以通用的。

核心架構

DataX3.0 開源版本支援單機多執行緒模式完成同步作業執行，這裡按一個DataX作業生命週期的時序圖，從整體架構設計非常簡要說明DataX各個模組相互關係。

核心模組介紹：

1. DataX完成單個資料同步的作業，我們稱之為Job，DataX接受到一個Job之後，將啟動一個程式來完成整個作業同步過程。DataX Job模組是單個作業的中樞管理節點，承擔了資料清理、子任務切分(將單一作業計算轉化為多個子Task)、TaskGroup管理等功能。

2. DataXJob啟動後，會根據不同的源端切分策略，將Job切分成多個小的Task(子任務)，以便於併發執行。Task便是DataX作業的最小單元，每一個Task都會負責一部分資料的同步工作。

3. 切分多個Task之後，DataX Job會呼叫Scheduler模組，根據配置的併發資料量，將拆分成的Task重新組合，組裝成TaskGroup(任務組)。每一個TaskGroup負責以一定的併發執行完畢分配好的所有Task，預設單個任務組的併發數量為5。

4. 每一個Task都由TaskGroup負責啟動，Task啟動後，會固定啟動Reader—>Channel—>Writer的執行緒來完成任務同步工作。

5. DataX作業執行起來之後， Job監控並等待多個TaskGroup模組任務完成，等待所有TaskGroup任務完成後Job成功退出。否則，異常退出，程式退出值非0。

DataX排程流程：

舉例來說，使用者提交了一個DataX作業，並且配置了20個併發，目的是將一個100張分表的mysql資料同步到odps裡面。 DataX的排程決策思路是： 
1. DataXJob根據分庫分表切分成了100個Task。 
2. 根據20個併發，DataX計算共需要分配4個TaskGroup。 
3. 4個TaskGroup平分切分好的100個Task，每一個TaskGroup負責以5個併發共計執行25個Task。

【本文轉載自 Golang語言社群 ，原文連結：https://mp.weixin.qq.com/s?src=11&timestamp=1534989045&ver=1077&signature=ToJO30*XGVmdovXyPH*VxtSZ1-luOF39RVYMhRawyBaEzImS5l9ypwOPovM3wRIfmjfKaqafI7bDrhL57krSP6E9fd2eQAJUHmSG2Yu9YhwRe-*0XuBcM6O8JeuNAeV9&new=1】

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31077337/viewspace-2212643/，如需轉載，請註明出處，否則將追究法律責任。