<b>摘要：</b>8月24日，阿裡雲資料庫技術峰會到來，本次技術峰會邀請到了阿裡集團和阿裡雲資料庫老司機們，為大家分享了一線資料庫實踐經驗和技術幹貨。在本次峰會上，阿裡巴巴進階技術專家付大超(千震)針對于雲計算時代最好的資料傳輸産品阿裡雲dts的架構設計、基本原理以及相關的應用場景進行了精彩分享。幫助大家了解了阿裡是如何實作異地多活和異構多活的，以及通過dts輕松實作遷移、雙同同步、容災、訂閱的真實案例。
<b>以下内容根據演講嘉賓現場視訊以及ppt整理而成。</b>
本次分享的内容主要圍繞以下四個部分：
一、dts技術架構
二、dts異地&異構多活架構
三、dts應用案例
四、最佳實踐
<b>一、dts技術架構</b>
<b>dts産生的背景</b>
大家下午好，如下圖中左側所示的是幾年之前的支付寶釋出的一條微網誌資訊，這條微部落客要表達的是因為當時杭州的溫度很高，導緻當時的用電壓力比較大，而為了保證居民的正常用電，甚至連阿裡巴巴的機房也是以受到限電。而這樣的限電卻可能會對于阿裡的服務、支付寶的服務甚至是阿裡雲的服務造成影響。在幾年之前，阿裡巴巴就在思考将服務搬到另外一個地方去，這樣即使杭州出現了一些像機房全部斷電這樣由于不可控因素産生無法提供服務的情況，阿裡也依舊能夠為全球的使用者提供線上服務。是以為了實作上述目标，阿裡逐漸開始實作異地多活的場景。
上圖中右側所展示的是中國人民銀行對于資料中心出現的問題的資料統計。可以看出資料中心所出現的問題種類還是比較多的，其中比較典型的就是主機故障、電源故障等。總而言之，就是資料中心會出現各種各樣的異常情況導緻服務中斷。在本質上來說，這樣的異常情況是不可以避免的，阿裡巴巴在思考該如何解決這些問題的時候就想到了可以通過将資料中心做成異地甚至是全球的架構，這樣就可以盡可能地避免因為異常情況導緻的服務不可用。比如在雙11場景之下，當某一個機房挂掉了，業務也并不會受到影響。為了實作這樣的目标，也就産生了dts這款産品。
<b>dts簡介</b>
後來發現阿裡雲也存在着與阿裡巴巴同樣的需求，因為很多使用者需要将自己的資料遷移到阿裡雲上來去建構自己的資料架構，這時候也會遇到同樣的問題。于是dts這款産品逐漸地從内部開放到外部，開始對外提供服務。是以在今天，阿裡雲的外部客戶能夠享受到與阿裡内部一樣的基礎設施和服務。
目前，dts産品有這樣的幾個功能，典型的就是使用者上雲時需要進行資料遷移，幫助使用者将本地機房的資料遷移到阿裡雲的其他資料庫或者使用者在ecs上自建的資料庫上去。總而言之，dts産品的目标就是打通整個資料鍊路。之前的資料在每個産品中，這樣相當于是資料孤島，而通過dts産品能夠消除資料孤島，将資料鍊路完全打通，驅動資料自由地流動。除此之外，dts的功能還有實作長期的資料同步，這一點與資料遷移不同，在長期的資料同步過程中必定會對于可用性、性能以及安全性提出更高的要求，而dts能夠提供長期的資料同步能力。dts的第三個功能就是實作資料訂閱，一些使用者在阿裡雲上擁有很多的資料庫，而使用者想要将rds的增量資料訂閱回去，更加靈活地建構自己的資料架構。dts還提供了一點功能就是檔案遷移，可以将像sql以及csv等以檔案的形式導過來。
通過上述的功能，dts就能夠在應用場景下提供更強大的服務能力。阿裡雲上的資料庫都能夠支援dts，而使用者在ecs上自建的資料庫以及使用者在本地idc上自建的資料庫，包括mysql、oracle、sql server、pg、mongodb以及redis都是能夠支援dts的，而且相對比較特别的是dts還能夠支援增量的能力。而就目前而言，能夠支援oracle、sql server、redis的增量能力的雲産品隻有dts能夠做到。
<b>dts發展曆史</b>
dts的發展經曆了很多個階段，其發展成熟的過程也經曆了一定的演變。在今天，dts能夠支援雙11這樣的場景，其背後是一步一個腳印走下來的，是以每年也都會逐漸地實作新的特性。在2012年的時候，dts就實作了異地冷備；在2013年，實作了同城雙活；在2014年實作了異地多活；在2015年的時候，支付寶和天貓國際都開始了全球化的步伐，而這些交易資料是需要進行全球同步的，因為中美之間的鍊路足夠長，是以dts也實作了中美同步，解決了在上萬公裡的天然網絡延遲的情況下的延時問題以及網絡傳輸的優化問題；最後，在2016年dts實作了異構雙活，也就是實作了兩個異構的資料庫比如從oracle到mysql或從mysql到oceanbase這樣異構場景的雙向多活。
<b>dts架構設計</b>
上圖所展現的是使用者次元的dts産品的架構設計。在最外層所提供了使用者可以直接進行操作的控制台，同時也提供了openapi。阿裡雲在上周上線了openapi的完整文檔來幫助使用者更好地使用這款産品。使用者通過控制台以及openapi這兩種途徑都可以建立dts的任務，這樣的任務會發到反向代理叢集，再到前端叢集，最後再下發到核心的工作叢集上去。在dts底層會存在一個任務排程系統，dts本身是全球服務的，是以可以将指令下發到全球。dts将能夠提供幾個功能，比如資料遷移系統就需要解決資料一緻性的問題，無論是無主鍵表還是innodb引擎，dts都能支援使用者将資料輕松地遷移到rds或者自建的ecs甚至是大資料系統上去。除此之外，dts還提供了資料同步以及資料訂閱的功能。而且還提供了上雲評估功能，這個功能能夠幫助使用者更加輕松地評估自己的系統，因為阿裡雲的使用者中有一些使用者對于自己的系統并不了解，而且可能并沒有專業的dba，是以這些系統需要一款産品能夠為使用者提供一些對于系統所存在的問題的建議，比如将資料從oracle遷移到mysql可能出現哪些内容不相容，可能有哪些無主鍵表，可能有哪些大字段，以及性能如何等。dts能夠為使用者的系統提供一個基本的測試報告，讓使用者可以看到改造成本是什麼樣的。除了核心功能之外，dts還會提供一些輔助系統，比如監控系統、運維系統、以及運輸系統等。
<b>架構優勢：高性能</b>
接下來分享dts的架構優勢，來幫助大家更加清晰地了解應該在什麼樣的場景上去應用dts，并且更好地利用dts的特性來快速實作業務的快速發展。首先，dts的第一個架構優勢就是高性能，如果使用者想要快速地實作異地災備或者上雲，dts可以幫助使用者使得同步性能達到3萬多tps，當然這個資料是在實驗場景之下的。阿裡雲經常會在使用者所送出的工單中發現使用者的源庫和目的庫之間的差别很大，這樣的情況下往往達不到上述的性能。
但是dts會盡可能地提供比測試資料更高的性能，當使用者在實際使用的時候就能夠感覺到即使庫寫的很大，dts也能夠支援。這是因為dts内部有一整套通用的解決方案，比如事務沖突檢測能夠實作并發的事務寫入。舉個例子，事務1寫了表a和表b兩張表，另外一個事務2寫了表c，還有一個事務3寫了表a和表d這兩張表，這樣的話，事務1和事務3是沖突的，因為他們都寫了a這張表，而事務2與他們都不相關，是以事務2是可以和他們并行執行的，而事務1和事務3隻能是串行執行的。這個例子非常簡單，而在實際情況下卻并非如此，因為每個表都有主鍵、唯一索引以及外鍵，上述例子隻是為了幫助大家進行了解。補充一點：mysql的事務處理比較簡單，但是oracle資料庫的事務則不同，其事務是穿插的，是以在oracle中實作事務沖突檢測就會非常複雜。大家如果做過oracle的日志解析就會發現其中存在非常大的困難，而目前無論是對于mysql、oracle、sql server、redis還是mongodb，dts都能夠提供支援。
<b>架構優勢：高可靠</b>
dts的第二個架構優勢就是高可靠。雲計算本身所具有的特性之一就是可以彈性伸縮，當需要資源的時候就去購買，當不需要的時候就釋放掉。而dts的架構設計上也引入了彈性的思想，在為全球提供服務的時候，任何一個服務節點發生故障時，故障節點的任務自動切換到健康的節點繼續完成之前的工作，而應用卻是無感覺的。
這時候就會涉及到一些問題，比如斷點是如何解決的，另外如果表在全量遷移的過程中挂掉了，是否能連接配接起來之後從挂掉的地方繼續運作，這樣盡可能節約時間和計算成本，除此之外還會涉及到無主鍵表所造成的困難，而這些困難和問題都已經被dts所解決了。總而言之，dts能夠為使用者在使用過程中屏蔽掉這些問題。
<b>基于結構化存儲隊列的查詢和分發技術</b>
那麼為什麼dts在架構上具有一定的領先性呢？一部分原因是dts所有的增量解析能力都是基于日志實作的，而不是基于查詢源庫的select表實作的。阿裡雲所有的資料庫産品的增量能力都是基于日志實作的，這樣能夠帶來一些好處，首先對于源庫基本上是沒有影響的，而且使得性能足夠好，可以實作實時地解析，基本上可以做到秒級，而且大部分的資料同步都在幾百毫秒。在做日志解析過程中就需要結構化資料隊列這個元件，它所能夠實作的功能就是無論使用的是哪一種資料庫，都可以将其日志解析過來并且放入到結構化資料隊列裡面，将其解析成dts所需要的格式。接下來就可以通過這個結構化資料隊列為下遊提供服務，比如使用者訂閱資料、進行資料同步以及未來将會開放的sql接口的實時查詢等。sql接口的實時查詢指的是比如使用者想要知道資料庫在過往的曆史中究竟發生了什麼樣的變更，這時就可以根據表格的id查詢該表所有的曆史變更記錄，目前而言這個功能還沒有開放出來，後續将會考慮開放。因為這樣的架構，是以所有的資料庫接入進來都會有天然的實時性。阿裡雲的dts是在2015年4月份上線的，而亞馬遜aws在2015年9月份上線了一個類似的産品，但是今天可以不謙虛地說阿裡雲dts是目前同類産品中做的最好的。
<b>二、dts異地&異構多活架構</b>
<b>dts異地多活</b>
接下來根據下面這張圖分享dts的異地多活是如何實作的。其實在實作阿裡巴巴的異地多活的時候就已經将這套東西整合總結出來了，是以也希望将這套比較複雜的能力賦予公有雲的使用者，比如阿裡雲dts輸出了一個雙向輸出的功能，也就是異地多活的能力，使得使用者可以親身地建構這套東西。在下圖所示的場景裡面，使用者擁有一個a城主庫還有一個b城主庫，并且希望實作異地雙活。
使用者希望既寫a城主庫又寫b城主庫，通過dts就是先建立一個從a到b的正向任務，也就是中間通過一個結構化隊列以及dwriter子產品實作與所有的資料庫之間的事務一緻性的寫入。這裡特别強調在場景上必須實作事務一緻性，這是因為像是在天貓或者淘寶下單的時候，訂單往往會涉及到幾百條sql以及幾個庫，而且一個事務可能會涉及到幾個表的若幹個字段，而其本質上是一個事務，而如果将事務拆開并且同步到b城主庫上面去的時候就會發現有些資料當讀取過來之後就是不一緻的，比如對于一筆訂單而言，可能在a城主庫中讀取的資料發現已經支付，但是在b城中讀取出來的資料發現這筆訂單還沒有支付，這就會産生資料不一緻的問題。是以希望在這樣的場景下也能夠保持事務的一緻性，這一點也是非常重要的，否則的話在一些非常嚴格的場景下會産生非常多的問題，比如像銀行的流水業務場景。是以dts所需要解決的問題中，一個是日志的解析，另外一個就是通用的事務解決方案，這樣一來正向的方案就建立完成了，同樣的反向方案也能夠建立。但是在建立反向方案的時候需要解決防循環的問題，也就是不能出現讓從a城主庫寫的資料到了b城主庫然後又回到a城主庫這樣的循環。而防止循環的方案在dts的異地多活場景中也已經實作了。
<b>dts異構多活</b>
其實在這個場景之下還有一個比較大的問題就是兩邊資料庫都可以寫入，如何去判斷資料是否一緻，當資料出現不一緻時如何判斷出來，以及在判斷出來之後又應該如何去進行修複。而且如果沒有這樣的修複能力，一旦資料出現了問題，損失将是無法挽回的。在今天，阿裡巴巴的淘寶、天貓以及支付寶的交易都是搭建在這樣的平台之上的，如果出現資料不一緻的情況，将會造成極大的影響和損失。正是因為資料一緻的問題非常重要，是以一定要有資料的一緻性校驗的能力，而在dts的異地多活解決方案中恰恰擁有這樣的能力，能夠輕松地校驗兩端的資料庫是否是一緻的，并且可以非常輕松地訂正表，當出現問題時也可以及時地進行修複。
在下圖所示的場景中，展現的是從oracle資料庫遷移到oceanbase或者mysql資料庫。阿裡雲的很多政府部門或者銀行的客戶使用的資料庫還是oracle或者db2，而這些使用者往往也希望借鑒阿裡巴巴的架構來實作自己的全球化分布來避免單點問題。而在這樣的場景之下如何去支援異構資料呢？今天，阿裡雲線上上已經能夠為使用者提供這樣的能力，而且在銀行業也有實際落地的案例，dts能夠将oracle資料庫中的日志解析出來寫給oceanbase，而且在這裡面還可以支援ddl功能，比如從oracle到mysql可以支援ddl。而如果大家對于oracle和mysql比較了解的話就會明白他們兩者之間的ddl的差别是非常大的。當然這裡并不是說阿裡雲dts的異構多活解決方案能夠支援所有的ddl，但是對于大多數的ddl而言都是能夠支援的。
在上圖所示的場景裡面存在着一個非常大的問題，就是使用者其實從oracle到oceanbase之間存在着一個緩慢的過程，是以從oracle逐漸切入到oceanbase或者mysql上需要一個灰階的能力。在這個場景中，首先假設有三個使用者向a城oracle中寫資料，這時候想要切一個使用者到b城上去，這時候就需要dts提供一個能力來告訴使用者這個鍊路的延時是什麼樣的，如果延時很小就可以将使用者從a城切換到b城，這樣就可以逐漸地将所有的使用者從a城切換到b城上面去。但是當切換過去之後使用者可能還是不放心，因為對于像銀行業這樣的行業而言，如果沒有後備的措施，一旦雲端發生問題可能就會出現無法遷回到oracle上去的風險。是以為了讓使用者放心，dts同樣也提供了遷回到oracle的能力。而這個功能的實作也存在着比較大的挑戰，因為從mysql或者oceanbase上遷移回oracle的過程中，資料庫也存在着很大的差異性，這樣的差異性就需要dts異構多活産品來抹平，這款産品同樣也會提供全量和增量的校驗能力，能夠實時地發現資料的不一緻情況。當将所有的使用者全部切換到b城之後就實作了将使用者主要業務遷移到阿裡雲自主可用的rds、oceanbase以及polardb上去。
<b>案例：阿裡異構多活</b>
之前分享了阿裡異地多活的技術實作，實際上，除了技術實作以外，還需要從業務層面進行分析。這裡使用淘寶中賣家商品次元的場景為例子進行說明，比如從中心到單元是按照使用者的id，也就是買家的次元去取模分割，這樣每個單元都會得到一部分的流量，同時中心也會得到一部分的流量。是以如果單元的數量越多，理論上對于雙11的支援能力也就越強。在2015年的雙11當天單是賣家商品資料庫全天同步的資料量就在pb級别了，而且這套方案不是單執行個體的，而是整套叢集的，高峰時候的增量流量在gbps級别。當運作的資料架構足夠大的時候就會發現往往需要去接資料庫的下遊，包括實時的計算、分析、搜尋以及備份等。而阿裡的這套機制也是比較完善的，大家在雙11的時候看到的能夠實時地捕獲訂單以及交易額的資料媒體大螢幕上的資料都是來源于dts的，媒體大屏上的資料是絕對真實的，是直接從生産中擷取的，而且能夠做到秒級别的重新整理，是以訂單、消費額以及物流情況基本上都能夠實時地轉移給媒體顯示。
在這個平台裡面，dts提供了異地多活能力，首先解決了阿裡巴巴的單點的問題，除此之外還解決了多下遊消費的問題。現在很多公司在進行實時計算的時候是以全量的方式去拉取的源庫，比如将全量資料每天定時拉取到hadoop叢集或者odps中去并進行實時計算，但是随着業務的逐漸發展，會發現使用者所需要拉取的庫越來越大，同時給系統造成的壓力也越來越大，而且資料拉取的下遊也會變多，比如搜尋、實時計算等，他們需要dts這樣的産品。隻要為他提供一個将日志解析成增量的能力，然後賦予資料庫的下遊共同消費這些增量的能力，就可以實作隻拉取一次，讓大家能夠多次消費，而且這個過程還不是通過sql去查詢源庫，是以對于源庫基本沒有影響，而與此同時對于下遊而言，收益則是非常大的。
<b>案例：阿裡雲全球化</b>
除了dts在阿裡的應用場景之外，還有阿裡雲上的應用場景。在今天很多雲計算的使用者選擇了阿裡雲的産品，而阿裡雲能夠提供比如像華東、杭州以及新加坡等很多的region，阿裡雲目前有十幾個region分布于全球，并且還在快速地擴充之中。阿裡雲天生就是全球化的架構，而阿裡雲的志向就是做全球化的雲計算服務，可以說是志向高遠，是以在進行架構設計的時候就需要去考慮使阿裡雲的雲産品能夠實作全球化的架構。
因為dts是提供給阿裡雲自己的産品來實作全球化服務的，而像rds、ecs上面的資料是需要和中心進行互動的，比如使用者購買一個rds，那麼這個rds執行個體是如何生産出來的，執行個體與中心之間如何實作資訊的互動的，其中的控制節點又是如何控制流動的，這一套東西其實都是基于dts所提供的全球化和單元化架構實作的。其實，阿裡雲和阿裡的實作方式還不完全相同，阿裡雲所實作的是雙中心的架構，而阿裡目前實作的是單中心的架構，但是單中心有backup，是以無論是這兩種方式中的哪一種都是可以支撐交易以及下單業務的，是以dts架構上的複雜性會更高一些。
dts可以支援關系型資料庫，也支援大資料，還支援nosql以及一些應用領域。是以在場景上來看，dts支援的範圍是非常廣泛的。
<b>三、dts應用案例</b>
接下來分享一些場景下的dts應用案例，幫助大家了解在什麼樣的場景下使用dts，以及應該如何使用dts。
<b>案例1：某國内大型商場使用dts從oracle不停機遷移到rds</b>
下圖中所展示的是一個真實的案例，某國内大型商場原本是oracle的使用者，但是他希望将自己的資料遷移到雲上來。進行遷移可以選擇去購買oracle的服務，但是這個服務是比較昂貴的，而且也會比較複雜，是以使用者希望通過dts來完成。其實對于dts而言，在頁面上建立這樣的一個任務是比較簡單的，使用者隻需要點選幾下滑鼠就可以實作，也不需要專業顧問去提供實作方案的建議。因為不需要付昂貴的軟體采購費用和顧問咨詢費用，是以使用dts進行資料遷移的成本是比較低的，可能僅需要幾元錢就能夠完成從oracle不停機地遷移到rds的工作。
如上圖所示，首先會把oracle的庫表列遷入到rds上去，然後再将全量資料以及增量資料遷移過去。這個過程需要確定的就是如何保證将全量遷移過程中引入的增量寫入到目的庫中去，還有oracle的無主鍵問題應該如何解決，而這些問題都是比較困難的，單純依靠使用者自己去解決則是比較麻煩的，但是使用dts就能夠友善地解決上述問題。阿裡雲為使用者提供了這樣的簡單功能，而使用者卻給阿裡雲提出了更多的場景，比如還是這個大型商場使用者，他們還提出了從oracle到oracle的雙向遷移能力以及從oracle到rds的雙向能力，阿裡雲也為使用者提供了這樣的能力，不僅僅實作了架構的靈活轉換，還為使用者節約了大量的成本。
<b>案例2：某遊戲公司通過dts同步到海外實作就近通路</b>
當今中國的遊戲行業蓬勃發展，很多遊戲公司開始布局海外市場，并且發展情況良好。很多使用了阿裡雲的遊戲公司也提出了這樣的新需求：希望将把遊戲資料在中美之間進行同步，把下發的遊戲參數資訊、購買資訊等從中國傳給美國或者從美國傳回中國。阿裡雲可以通過dts的中美同步功能幫助使用者實作萬公裡毫秒級延遲的資料同步能力。很多國内發展比較好的創業公司都使用了dts的中美同步服務，不僅僅是遊戲公司，還包括一些無人機之類的公司也都使用了這樣的功能。
<b>案例3：某大型央企通過dts進行在離線實時同步分析目标使用者</b>
目前一些央企、國企也開始走上了上雲之路，隻不過對于央企或國企而言，上雲的道路可能需要分步驟地完成，比如通過dts逐漸地實作大資料分析，對于央企或國企而言，可能原來在本地并沒有搭建自己的大資料平台，而現在希望借助阿裡雲上比較友善的像maxcompute等來實作大資料能力，而dts就能夠幫助他們實作這樣的目标。因為搭建這樣的一個大資料叢集本身的成本是非常高的，而使用阿裡雲卻是非常友善的，并且成本也會比較低，隻需要按需付費就可以了。通過dts增量能力可以直接寫給maxcompute或者通過spark的流式接入寫給其下遊的計算服務，這樣也可以解決知識計算以及流式計算的需求。
<b>案例4：某大型網際網路公司通過dts建構公有雲異地多活架構</b>
大型網際網路公司可以通過dts建構如上圖所示的公有雲異地多活架構，這個案例的基本内容在前面已經分享了，這裡不再贅述。
<b>案例5：某視訊類科技公司訂閱dts做緩存更新</b>
有一些使用者在實作自己的網際網路架構過程中不可避免地需要使用到緩存，無論是memcache還是redis，這些緩存所起到的作用就是幫忙擋一層通路。如果沒有緩存層，就難以應對像雙11這樣的場景。而緩存層也都存在着失效的問題，通過使用dts的資料訂閱功能，實時擷取資料庫更新資料，就能夠更新緩存内容，解決緩存失效的問題，而使用者使用和搭建這套架構所需要的成本也比較低。
<b>案例6：某商業銀行通過dts建構私有雲的兩地三中心容災架構</b>
重點分享一下這個案例。應中國人民銀行的要求，所有的銀行都需要提供“兩地三中心”的容災能力，“兩地三中心”也成為了銀行的标配。而在這之前，很多的銀行曾出現過因為資料庫版本更新、資料庫運維以及其他原因造成服務不可用的問題，但是對于很多銀行而言，是不敢輕易切換目的庫的，因為這可能對于銀行的業務造成很大的影響。銀行不敢切換到目的庫的本質原因就是他們無法保證目的庫能夠正常使用。而通過dts這款産品能夠確定目的庫通過異地的兩地三中心搭建出來一個備庫，使其能夠實時使用的并且有效。因為通過檔案這種方式無法驗證副本集是否是有效的，而dts卻是通過備庫與第三方庫進行有效性驗證。
上圖中的兩地是深圳和杭州，杭州有兩個機房idc a和b，深圳有idc c，這樣的情況下需要搭建兩地——深圳和杭州，三中心——idc a、b、c三個機房這樣的異地多活的架構。使用下圖的這種方案是比較輕松的，因為在同城内部是通過阿裡雲rds實作運載的，對于異地的情況可以通過使用dts實作深圳機房的資料運載，而且rto或者rpo基本在1秒左右。除此之外，将服務切到杭州去之後還可以通過dts切回到杭州。而成本也會降低一些，這是因為首先對于同城部分，阿裡雲rds已經幫助使用者實作了；對于異地的資料庫而言，從節省成本的角度，可以自己搭建，當然也可以通過rds來實作。最重要的一點就是目的端的資料庫是實時的、有效的，并且能夠提供可靠的線上服務。
在上述案例中，如果idc a出現了故障，這時候rds會去做主備切換，但是服務卻不會受影響。如果現在使用者100%的流量都寫入到杭州，應用端會自動切換到idc b上來，保證整個服務是可用的。
如果上述案例中的idc a和b都挂掉了，也就說整個杭州的機房全部挂掉了，在這樣的情況下該如何保證服務的可用性？實際上這時候需要通過檢視dts的界面來看其延時是多少，如果延時很小就可以做一些标準的切換流程，把應用的流量切換到深圳去。這個時候即便是整個杭州的機房全部挂掉了，也能夠保證服務的正常運作。剛才提到的rpo是1秒，如果可以做到更好，就可以實作杭州節點中的資料在機房恢複之後還能找回來，隻是可能某一秒的資料沒有寫過來，但是當杭州的節點恢複了，資料還是可以同步到深圳節點去的。
<b>四、最佳實踐</b>
上面分享了dts的一些使用場景，最後為介紹dts在使用過程中使用者反映比較多的典型問題以及最佳實踐。
<b>1.dts連接配接不上源庫報錯，</b>這種報錯産生的場景和原因有很多，比如資料庫是否開放了可以遠端連接配接的權限，因為一些資料庫會限制隻允許某些ip進行通路；使用者填寫的使用者名和密碼是否是正确的；以及資料庫有沒有連接配接到公網。是以在這樣的場景上，使用者發現dts連接配接不上源庫就需要自己在另外一台ecs上登入自己的源庫，檢視是否能夠連接配接上，如果能夠連接配接上，說明目前的網路連接配接是正常的。而在阿裡雲所接收的工單中發現很多情況下使用者的源庫限制了ip通路，因為如果使用者使用的是自建的資料庫而不是rds版本的資料庫，就會自動地限制隻允許某些ip進行通路，這也是出于安全性的考慮。是以建議使用者在出現這樣問題的時候在另外一台ecs上直接通路源庫并檢視通路情況。
<b>2.使用dts遷移上雲的過程中，</b>如何将應用切換到rds上去？其實這樣的過程具有非常嚴格的規範，比如應該怎麼去切換資料庫。這個過程在這裡進行簡單說明，首先如果發現dts的延時很小了，就應該将源庫置成read only的。除此之外，還需要在源庫上将應用的session全部清除掉，因為如果不清除掉，應用還是可以進行寫操作。将session全部清除掉之後就能夠確定應用不會再執行寫操作，這個時候再将應用切換到目的端。而有時候因為應用機器規模很大，是以導緻切不幹淨，使得有的應用還在向源端的庫進行寫入，這樣就會導緻資料不一緻，也就是出現了“雙寫”的情況，這也是一個值得吸取的經驗教訓。
<b>3.源庫和目的庫庫名、表名、列名不同，</b>比如源庫本地是a庫改變成目的庫是b庫，源庫中表名是a表到了目的庫的表名稱變成了b表。在這種場景上，dts提供了庫、表、列的映射，使得使用者可以很友善地去進行映射。
<b>4.源庫和目的庫都有觸發器，</b>很多使用者的源庫上有觸發器，而且想要将源庫的資料遷移到目的庫上去，是以往往會在目的庫上再建同樣的觸發器。然而，其實目的庫的觸發器是不用建的，因為源庫上的觸發器所産生的資料會産生binlog，而通過dts進行遷移，源庫表中有觸發器就不需要再向目的端庫建立觸發器了，因為dts已經幫助使用者将觸發器上産生的資料同步到目的端了。不然如果使用者在目的端庫上也建立觸發器就會報錯，因為源庫上觸發器已經産生了同一條記錄，這樣就會出現主鍵沖突，進而導緻報錯。
<b>5.跨賬号遷移的問題，</b>也就是在跨賬号進行遷移的時候，使用者不知道應該如何遷移。dts在頁面上提供了跨賬号遷移的功能，使用者可以填寫另外一個賬号的使用者名和密碼，實作跨賬号的遷移。而阿裡雲dts還提供了專業的文檔幫助使用者實作這樣的功能。
<b>6.遷移同步過程中進行了rename表操作，</b>很多使用者在源庫上需要做線上的ddl，而做線上ddl的時候，很多工具會産生rename表，而rename的表也在遷移的對象裡面。比如需要遷移a、b、c三個表，使用者将a表rename成d表，再将d表rename成c表，這樣的過程中d表并不在同步對像裡面，是以并不會将其同步到目的端去，因為已經選擇了a、b、c表，後來d表才出現，是以d表必然不在同步對象中。而在目的端執行從d rename成c的時候發現沒有d這張表了，是以如果需要做rename操作，建議使用者直接選擇将整個庫進行遷移。整個遷移就能夠将源庫上所有的表全部同步過去，這樣就不會出現rename而導緻的目的端某個表不存在的問題了。總結而言，這是因為使用開源的工具做了線上ddl導緻rename操作進而導緻的比較常見的錯誤，而這個錯誤也是值得重視的。
<b>7.主子賬号遷移、同步，</b>當公司發展壯大了，就會涉及到很多主子賬号的問題。為了解決這個問題就需要使用者在使用主子賬号做遷移或者同步的時候通過主賬号給子賬号授權，通過授權确定什麼賬号可以使用哪一個rds。
<b>8.遷移和同步過程中有ddl，</b>mysql到mysql這種場景是支援ddl的，很多使用者會出現在源庫上建立了ddl并且還跑到目的庫上建了一個ddl的情況，也就是兩個庫上都建了一個ddl，而這樣肯定會出現問題。是以對于mysql這種場景不需要兩邊都做ddl，在源庫做一個表結構，dts可以幫助使用者同步到目的端去。
<b>9.公共雲和金融雲之間遷移、同步，</b>在公共雲和金融雲之間是存在隔離的，因為金融雲的隔離級别相對而言比較高。資料可以從公共雲到金融雲，但是反過來從金融雲到公共雲卻是不可以的。
<b>10.目标庫多了一個表increment_trx，</b>這個表實際上是dts在同步過程中或者增量遷移過程中建的中繼資料表，這張表為的是解決斷點續傳問題的，如果還處于資料遷移過程中就不要删除這個表，如果沒有dts任務在運作的時候，就可以删除這個表。
<b>11.使用者想要實作a->b->c遷移，以及實作級聯同步，</b>之前對于這樣的級聯遷移或者同步的需求是會進行攔截的，但是現在dts也開始支援這樣的操作了，可以實作級聯的遷移和同步。
<b>12.使用者在使用資料訂閱啟動sdk報如下的錯誤:keep alive error，</b>這表示的意思就是訂閱程式連接配接不上dts的服務，比如在沒有連接配接公網的時候就會出現這樣的錯誤，是以需要讓使用者自己的服務能夠連接配接外面的公網。阿裡雲所提供的服務是在公網上的，未來阿裡雲也會對訂閱功能提供私網服務。