中文字幕理论片,69视频免费在线观看,亚洲成人app,国产1级毛片,刘涛最大尺度戏视频,欧美亚洲美女视频,2021韩国美女仙女屋vip视频

天翼電子商務有限公子（簡稱“甜橙金融”）是中國電信的全資子公司，2011 年 3 月成立于北京，現(xiàn)賬戶用戶已突破 1.5 億，成為國內(nèi)最大的民生繳費平臺、移動支付領域 5 強、互聯(lián)網(wǎng)金融領域 16 強。甜橙金融技術團隊在經(jīng)歷 2016 年成功“上云”后，便開始著手建設新華南機房。新華南機房的設計目標是與當前的兩個華東機房一起，形成符合甜橙金融業(yè)務快速發(fā)展需要兼顧迎檢要求的“兩地三中心”異地雙活架構。

本文系統(tǒng)介紹了我們在業(yè)務需求驅(qū)動下的數(shù)據(jù)中心建設的演進過程，以及我們在此基礎上進行的 “ 異地雙活 ” 探索和驗證，其中“ 異地雙活 ”主要是基于數(shù)據(jù)訪問層（ Data Access Layer，DAL ）和數(shù)據(jù)層庫（ Database ）兩個方面展開介紹， 希望在雙活建設上能給大家?guī)硇碌乃悸贰?/p>

圖 1. 甜橙金融 IDC 機房架構演進

1. 本地數(shù)據(jù)中心階段（2011 年 -2013 年）

最初的機房架構比較單一。華東、華南兩地各有一個本地機房，且各本地機房主要負責華東、華南兩個研發(fā)中心自身的發(fā)展需求。兩個本地機房之間通過 CN2 和 DCN 直連。

圖 2. 甜橙金融本地數(shù)據(jù)中心架構

在發(fā)展初期，這樣的 IDC 機房架構加上兩地研發(fā)中心，使得我們的業(yè)務在短時間內(nèi)得以快速開發(fā)迭代、部署落地，一定程度上滿足了當時的業(yè)務需求。

架構痛點：2013 年后期，在經(jīng)歷了幾次大型促銷活動引發(fā)的一系列故障后，本地機房架構的短板逐漸浮現(xiàn)，如業(yè)務沒有跨機房冗余，在出現(xiàn)緊急事件時無法繼續(xù)提供必要服務等。因此，經(jīng)過內(nèi)部討論評估，我們初步制定了 IDC 機房架構的演進策略，開始著手建設同城機房。

2. 同城冷備階段（2014 年 -2015 年）

這一階段我們在華東地區(qū)規(guī)劃并建設了兩個同城機房，兩個華東數(shù)據(jù)中心均可以為華東研發(fā)中心提供業(yè)務相關服務。之所以依舊定義為同城冷備主要還是基于數(shù)據(jù)層面，因為從數(shù)據(jù)層面上說這種機房架構仍屬于冷備架構。雖然兩個數(shù)據(jù)中心的應用服務都可以接受并處理用戶請求，但用戶對數(shù)據(jù)的請求則同一時間只在固定的數(shù)據(jù)中心中讀寫。由于同城機房的網(wǎng)絡延時基本可以忽略，兩個數(shù)據(jù)中心則通過數(shù)據(jù)庫層面進行異步數(shù)據(jù)同步。

圖 3. 甜橙金融同城冷備數(shù)據(jù)中心架構

同城冷備架構讓我們的個人賬戶等核心業(yè)務有了必要的業(yè)務容災條件，同時由于兩個數(shù)據(jù)中心都可以處理正常業(yè)務請求，所以數(shù)據(jù)中心整體的資源處理能力也成倍擴充。

架構痛點： 添加新的數(shù)據(jù)中心除了帶來 IDC、線路、維護成本上的增加外，并沒有解決我們?nèi)A南數(shù)據(jù)中心業(yè)務無冗余的困境，且由于其中一個數(shù)據(jù)中心的數(shù)據(jù)是冷備數(shù)據(jù)，當出現(xiàn)嚴重故障時，冷備數(shù)據(jù)是否可以直接拉起使用也因業(yè)務差異而定。

隨著甜橙金融業(yè)務的發(fā)展，我們認為華東數(shù)據(jù)中心同城冷備架構已無法滿足我們業(yè)務發(fā)展的需求，但是受限于當時的基礎技術儲備能力，因此我們計劃進行全業(yè)務改造，逐步滿足建立異地雙活機房條件。

3. 同地區(qū)冷備階段（2016 年 10 月 -2017 年 4 月）

為了逐步建立異地雙活機房架構，我們在 2015 年底便首先啟動全業(yè)務的上云改造。到 2016 年 10 月底，在經(jīng)過 1 年多的業(yè)務改造及數(shù)據(jù)中心基礎建設后，甜橙金融將原有的兩個華東同城百公里內(nèi)數(shù)據(jù)中心改造為兩個同地區(qū)四百公里內(nèi)數(shù)據(jù)中心。這樣做的目的是為了進一步驗證同城冷備架構在異地是否繼續(xù)可行，并且對遠距離數(shù)據(jù)同步中出現(xiàn)的問題進行調(diào)研。

兩個同地區(qū)數(shù)據(jù)中心的地位和之前也有區(qū)別：在保持原同城冷備方案的前提下，華東新數(shù)據(jù)中心定位為主數(shù)據(jù)中心，主要負責處理甜橙金融核心業(yè)務；華東容災數(shù)據(jù)中心則負責生產(chǎn)數(shù)據(jù)的異地容災備份。

在這一階段，我們的新華南數(shù)據(jù)中心也通過調(diào)研，加緊建設中。

圖 4. 甜橙金融同地區(qū)冷備數(shù)據(jù)中心架構

4. 異地冷備階段（2017 年 4 月至今）

新華南數(shù)據(jù)中心建成后，我們開始將同地區(qū)數(shù)據(jù)中心的冷備架構下線，并同期建設為數(shù)據(jù)容災中心。新的華南數(shù)據(jù)中心則規(guī)劃為可以承載部分公共業(yè)務的應用級異地雙活。

在這一階段建設初期，我們繼續(xù)沿用已經(jīng)比較成熟的應用級雙活經(jīng)驗，將華東、華南兩個數(shù)據(jù)中心的數(shù)據(jù)訪問全部集中在華東主數(shù)據(jù)中心。業(yè)務上則針對跨千公里的網(wǎng)絡環(huán)境進行相應改造。畢竟在原有的應用設計時，一些業(yè)務判斷會強依賴數(shù)據(jù)返回時延，跨千公里網(wǎng)絡時延一般在 20-50ms 內(nèi)，這個對某些業(yè)務會產(chǎn)生較大影響。

圖 5. 甜橙金融異地冷備數(shù)據(jù)中心架構

架構痛點： 在跨千公里數(shù)據(jù)中心數(shù)據(jù)同步方面，由于華南副中心的數(shù)據(jù)只是冷備數(shù)據(jù)，所以設計之初我們便定義其數(shù)據(jù)可用級別為 T 1 日。當然，這樣的設計在數(shù)據(jù)恢復上存在一定問題，比如華南的副中心由于網(wǎng)絡擁堵導致數(shù)據(jù)同步延遲較大，這時如果華東主數(shù)據(jù)中心出現(xiàn)災難性故障，則副中心只能有限接管業(yè)務——數(shù)據(jù)時延最大可能一天。

故障的恢復會采用以下兩種方案：

1. 重新拉起華東主數(shù)據(jù)中心。

2. 華東數(shù)據(jù)容災中心恢復增量備份到華南副數(shù)據(jù)中心。

不管采用哪種方案，這樣的數(shù)據(jù)恢復時長對于核心業(yè)務來說是無法忍受的，這也是我們當前只在公共業(yè)務里采用異地應用級雙活架構的原因。

在數(shù)據(jù)中心建設告一段落后，我們將重點轉(zhuǎn)移到如何實現(xiàn)真正的異地雙活上來，在實現(xiàn)異地雙活架構時所面臨的問題主要包括以下幾個：

1. 跨千公里網(wǎng)絡時延。

2. 業(yè)務改造復雜。

3. 各數(shù)據(jù)中心數(shù)據(jù)一致性問題，包括臟數(shù)據(jù)寫入、數(shù)據(jù)沖突、是否需要改造全局鍵等。

其中，跨千公里數(shù)據(jù)異地同步的難度在業(yè)內(nèi)有著廣泛共識，受限于現(xiàn)在市面中的主流關系型數(shù)據(jù)庫都是基于 CAP 理論做底層設計（注：CAP 理論是指一款數(shù)據(jù)產(chǎn)品在數(shù)據(jù)一致性、可用性和分區(qū)耐受性三者中只能同時滿足其中任意兩者。），因此數(shù)據(jù)異地同步就需要對 CAP 理論進行規(guī)避。

針對上述的問題，我們制定了兩種類型方案并著手進行方案驗證：

1. 消息分發(fā) & DAL 層改造

2. 數(shù)據(jù)層改造（MongoDB、TiDB）

采用消息進行異地數(shù)據(jù)同步在業(yè)內(nèi)已有很多成功案例。在我們的技術方案里，首先要做的是將被選定進行異地雙活改造的應用入口逐漸收攏，從多入口（域名）訪問改造為統(tǒng)一的入口路由。這樣，入口級應用 MAPI 應運而生，它上線后將之前相對零散的業(yè)務訪問統(tǒng)一起來，這也為后面我們針對 MAPI 做流量分發(fā)及控制提供了必要條件。

圖 6. 甜橙金融異地雙活方案之消息分發(fā) & DAL 層改造

MAPI 通過 DNS 解析將入口流量進行多機房分發(fā)，業(yè)務請求生成的消息會寫入到兩地的機房中。接下來本地機房的消費者會通過 DAL 層將落盤數(shù)據(jù)分發(fā)到相應的數(shù)據(jù)分片里，然后通過數(shù)據(jù)庫自身的復制機制，有延時的將本地數(shù)據(jù)中心的數(shù)據(jù)同步一份到異地數(shù)據(jù)中心。這樣既可保證每個數(shù)據(jù)中心都會保留一份全量數(shù)據(jù)，也可以保證以華東主數(shù)據(jù)中心為主，向華東容災數(shù)據(jù)中心。

Consumer 和 DAL 的改造是該方案的難點。在實施時，我們根據(jù)業(yè)務的性質(zhì)進行了單元化劃分，這也是業(yè)內(nèi)實現(xiàn)雙活架構的常用方案。將不能進行單元化的業(yè)務以全局區(qū)域存放，而可以單元化處理的業(yè)務模塊則放入本地區(qū)域。

圖 7. Global Zone 和 Local Zone

如前文所述，面對異地雙活最大的技術難點數(shù)據(jù)一致性問題，其實主要還是受限于關系型數(shù)據(jù)及 CAP 原理。因此，通過一些技術手段對 CAP 原理進行規(guī)避也能夠達到滿足業(yè)務的數(shù)據(jù)一致性要求。

這里，我有兩個數(shù)據(jù)層改造的思路分享給大家：

1. 基于 MongoDB 副本集的異地雙活架構：

MongoDB 是天然提供分片的 NoSQL 數(shù)據(jù)庫，這樣的天然分片被稱為副本集。副本集的存在為每個 MongoDB 的分片節(jié)點提供了相應的高可用。

它在寫入持久性和讀取一致性上提供了更強的處理能力。比如，通過 write concern 來指定寫入副本的數(shù)量，無論采用應答式寫入還是非應答式寫入，均可保證跨數(shù)據(jù)中心的集群發(fā)生故障時，總會有相應的副本存在以保證寫安全。另外，MongoDB 是滿足 BASE 理論設計的，因此可以從一定程度上規(guī)避 CAP 理論帶來的問題。

圖 8. 基于 MongoDB 副本集的雙活架構

MongoDB 還有一個適合多數(shù)據(jù)中心部署的特征是其故障自動 Failover。這一特性對于異地雙活有重要意義，數(shù)據(jù)庫運維人員可以不用太在意各數(shù)據(jù)中心的數(shù)據(jù)庫節(jié)點的狀態(tài)。我們在進行的方案驗證時，當集群中的節(jié)點發(fā)生故障或出現(xiàn)網(wǎng)絡中斷，MongoDB 基本可以在 5 秒內(nèi)完成故障的 Failover 過程，這主要依賴集群對整個副本集的配置，發(fā)生故障后可以在剩余的副本集中選擇一個新的主 shards。

2. 基于分布式數(shù)據(jù)庫（NewSQL）的異地雙活架構：

從 Google 的 Spanner & F1 論文放出后，業(yè)內(nèi)對于如何打造一套跨數(shù)據(jù)中心的強一致性分布式數(shù)據(jù)庫的工程實踐方法有了深刻的認識和理解。

在開源數(shù)據(jù)庫領域，目前有兩個受 Google Spanner & F1 影響并建立發(fā)展的分布式關系數(shù)據(jù)庫 (NewSQL) 尤其引人矚目。他們分別是來自國內(nèi)的 PingCAP 團隊做的 TiDB 分布式關系數(shù)據(jù)庫項目和美國團隊的 CockroachDB 分布式關系數(shù)據(jù)庫項目。這兩個根據(jù) Spanner & F1 體系打造的分布式關系數(shù)據(jù)庫 (NewSQL) 目前在全球頂級開源分布式數(shù)據(jù)庫領域展開了直接的競爭。

我們在探索多中心雙活數(shù)據(jù)中心架構演進的時候，考慮到開源社區(qū)的穩(wěn)定及活躍程度，重點調(diào)研和關注 TiDB 在多中心架構多活模式中的技術價值和架構探討。TiDB 在數(shù)據(jù)庫領域?qū)儆谧钚碌牡谌植际疥P系數(shù)據(jù)庫，其具備如下 NewSQL 核心特性：

1. SQL 支持 （尤其與 MySQL 兼容性，使得其面對業(yè)務完全透明）

2. 水平在線彈性擴展

3. 支持分布式事務

4. 跨數(shù)據(jù)中心數(shù)據(jù)強一致性保證

5. 故障自恢復的高可用

6. 應用解耦，沒有業(yè)務侵入性

TiDB 整個項目和產(chǎn)品的運作方式以標準的國際開源項目在運營和發(fā)展，這點也是我們重點圍繞 TiDB 做探索性研究論證的主要動因，一個健康發(fā)展的開源項目能夠使得我們在應用其到比如多中心多活這樣的業(yè)務場景中，更有信心和保障。

TiDB 數(shù)據(jù)庫的主要架構如下：

圖 9.TiDB 架構（圖出自 TiDB 官網(wǎng)）

TiDB Server (分布式計算集群)：TiDB Server 負責接收 SQL 請求，處理 SQL 相關的邏輯，并通過 PD 找到存儲計算所需數(shù)據(jù)的 TiKV 地址，與 TiKV 交互獲取數(shù)據(jù)。

TiKV Server (數(shù)據(jù)分布式存儲集群)：TiKV Server 負責存儲數(shù)據(jù)，從外部看 TiKV 是一個分布式的提供事務的 Key-Value 存儲引擎。

PD Server (管理集群)：Placement Driver (簡稱 PD) 是整個集群的管理模塊，其主要工作有三個： 一是存儲集群的元信息（某個 Key 存儲在哪個 TiKV 節(jié)點）；二是對 TiKV 集群進行調(diào)度和負載均衡（如數(shù)據(jù)的遷移、Raft group leader 的遷移等）；三是分配全局唯一且遞增的事務 ID。

結合我們?nèi)A東主數(shù)據(jù)中心、容災數(shù)據(jù)中心和華南數(shù)據(jù)的三中心布局，在異地多活的場景中，我們設計的甜橙金融基于 TiDB 數(shù)據(jù)庫的雙活架構如下所示：

圖 10. 甜橙金融異地雙活架構

TiDB 分布式數(shù)據(jù)庫在多中心多活的部署和運行模式下，依靠其核心調(diào)度 PD 對跨 1000 公里以上集群的調(diào)度管理。我們在實驗后，總結了以下重要特點：

• 標簽系統(tǒng) (Label) :   TiDB 內(nèi)置有一套標簽系統(tǒng)，可以為一套集群的不同節(jié)點，按照 Site (數(shù)據(jù)中心），Rack (同中心內(nèi)不同機架)，Host (不同物理機節(jié)點) 來對應設置標簽信息，從而實現(xiàn)將集群的跨數(shù)據(jù)中心物理拓撲和集群調(diào)度連接起來。

• PD 集群調(diào)度器，根據(jù)對物理拓撲的映射，形成跨數(shù)據(jù)中心的實際數(shù)據(jù)和計算調(diào)度策略。

• TiKV 存儲引擎中的數(shù)據(jù)管理最小單位是 Region，每一個 Region 都通過 Raft 產(chǎn)生多個強一致性副本，在整個數(shù)據(jù)存儲空間內(nèi)，形成多個 Raft Group ( Region 和其副本所組成的同步組) 。同一個 Raft Group 中，會選舉出一個 Leader Region， 來自 TiDB SQL 引擎的物理數(shù)據(jù)讀寫，都會訪問所有 Raft Group 中的 Leader Region。

• PD 集群調(diào)度器 根據(jù)調(diào)度策略，會動態(tài)調(diào)度 所有的 Leader Region 按照 業(yè)務要求在三個中心中分布。

• 華東兩個數(shù)據(jù)中心 (主數(shù)據(jù)中心及華東容災中心）與華南數(shù)據(jù)中心的網(wǎng)絡通訊條件理想的情況下，PD 可以將數(shù)據(jù)分布中的 Leader Region 動態(tài)分布到三個中心的節(jié)點上。每個中心都可以以統(tǒng)一視角訪問和操作數(shù)據(jù)庫，TiDB 引擎上的 Multi-Raft 復制機制會在不同中心的數(shù)據(jù)區(qū)域進行強一致性復制 ( Raft Log based) 。

• 華東兩個數(shù)據(jù)中心 (主數(shù)據(jù)中心及華東容災中心）與華南數(shù)據(jù)中心的網(wǎng)絡通訊條件不夠理想的情況下，PD 可以將數(shù)據(jù)分布中的 Leader Region 動態(tài)分布到華東的兩個數(shù)據(jù)中心中，而在異地保留 Follower Region 作為高可用保護。

• 三個中心內(nèi)的數(shù)據(jù)管理單位 Region 都是可以在線的做動態(tài)的分布改變。

• 每個中心的節(jié)點擴容，通過 TiDB 自身的動態(tài)在線擴容機制，也可以實現(xiàn)動態(tài)水平擴展，擴展后的集群中的數(shù)據(jù)，會根據(jù) PD 調(diào)度的管理，自動在后臺完成數(shù)據(jù)重平衡工作，對業(yè)務連續(xù)性不產(chǎn)生影響。

下面就 整個多中心多活的具體可用性實現(xiàn)做一個拆解分析，我們的雙活架構如下圖所示：

圖 11. 基于 TiDB 的異地雙活架構

業(yè)務應用接入層高可用設計

業(yè)務應用通過 F5 , HAProxy , LVS 之類常規(guī)提供 4-7 層的負載均衡設備接入，負載均衡器通過流量接入后，通過流量轉(zhuǎn)發(fā)，直接發(fā)往 TiDB 分布式 SQL 引擎層進行業(yè)務計算。接入層的高可用，可以通過常規(guī)負載均衡的后向服務探測，完成檢測和流量切換。對業(yè)務應用透明。

TiDB 分布式 SQL 引擎計算層高可用設計

TiDB 分布式 SQL 引擎為無狀態(tài)服務，即任意一個集群節(jié)點不保留狀態(tài)數(shù)據(jù)?？梢噪S時增加節(jié)點和減少節(jié)點。節(jié)點發(fā)生故障后，通過前向服務探測和感知，可以自動隔離故障節(jié)點，剩余的 SQL 引擎服務實例可以正常的工作不受影響。對業(yè)務透明。

TiKV 分布式存儲引擎層高可用設計

圖 12.TiDB 底層 Region 設計原理

TiKV 分布式存儲引擎層也是高可用集群架構，內(nèi)置多種高可用底層保障機制，最核心的 Raft 機制確保位于每臺服務器上的每個 TiKV 服務實例中都有數(shù)據(jù)的副本存在，整個 TiKV 集群 如同 RAID 磁盤陣列，每個節(jié)點上都有業(yè)務數(shù)據(jù)，同時也有部分的校驗數(shù)據(jù) （在 TiDB 中為數(shù)據(jù)副本）。

默認副本配置為 3 個，低于 50% 的節(jié)點故障都可以透明容忍，對業(yè)務應用的訪問沒有任何影響。

故障節(jié)點被新節(jié)點替換或修復后重新上線后，集群調(diào)度器會自動建立數(shù)據(jù)的重平衡分配任務。這個過程對業(yè)務完全透明。

PD 集群調(diào)度器高可用設計

圖 13.PD 設計原理

PD 集群調(diào)度器是整個集群的管理節(jié)點，自身也是一套高可用集群的設計。PD 集群保存有整個集群的管理元數(shù)據(jù)，PD 節(jié)點之間通過 Raft 建立強一致性數(shù)據(jù)復制，任意 PD 的損壞或故障均可通過內(nèi)部的高可用機制重新選舉 Leader 對外繼續(xù)提供服務。Leader 選舉過程非常短暫，且選舉過程本身對業(yè)務應用無影響，PD 所在節(jié)點的存儲設備（如磁盤）物理損壞，既不會影響 PD 中集群元數(shù)據(jù)的安全（Raft 復制機制保證），也不會影響真實的業(yè)務數(shù)據(jù)的安全性。

在新技術的嘗試和引入時，甜橙金融內(nèi)部采取更包容的心態(tài)，以期待新技術可以帶給業(yè)務更可靠、便捷的基礎服務，以應對更快速的業(yè)務增長和更嚴峻的技術挑戰(zhàn)。甜橙金融成立 7 年來，從數(shù)據(jù)中心演進建設到數(shù)據(jù)層雙活探索，過程中的探索和思考是我最想和大家分享的。希望我們正在做的一些嘗試，能給正在進行“兩地三中心”建設的同學在數(shù)據(jù)中心建設、應用級雙活和數(shù)據(jù)級雙活上帶來一些新的思路，歡迎業(yè)內(nèi)有此方面研究的朋友一起交流。