Categories
程式開發

分佈式數據庫,NOSQL,搜索引擎


分佈式數據庫

MySQL通過數據庫的複制,分片方法實現數據的分佈式存儲. 一般分分為一主和多主兩種模式.

MySQL 一主多從復制

主從復製過程:

關鍵字: MySQL Replication

分佈式數據庫,NOSQL,搜索引擎 1

備庫執行change master命令,配置主庫使用的ip,端口,用戶,密碼等參數,連接主庫,配置binlog路徑及偏移量.備庫執行start slave命令, 啟動io_thread和sql_thread兩個線程主庫校驗通過備考的用戶密碼後, 按照配備庫指定的路徑下的binlog發送給備庫. 備庫拿到文件後將binlog寫入到本地中轉日誌relay log中. sql_thread讀取relay_log,解析命令並執行.

binlog 格式:

statement 記錄語句原句, 總從環境不一致是如可能執行結果不同, 如進行delete主從使用的索引可能不一致.

row: 記錄真是操作行的id, 避免上述情況

mixed: 屬於前兩種情況的折中, 對於可能引起主從不一致的使用row, 否則使用statement

相關問題:

問題:

主備延遲:原因主要有機器性能差, 備庫查詢,報表較多導致壓力大, 大事務的執行(歸檔類數據,大表)

解決方案:

可靠性優先:

通過SBM seconds_behind_master,記錄當前備庫延遲了多少秒, 可靠性備份步驟

判斷備庫的SBM 是否小於某一值(如5秒)進行主庫操作,否則等待;主庫改為只讀狀態, 把readonly設置為true;等待備庫的SBM值為0, 備庫狀態改為可讀, readonly設置為false;業務切換到備庫

可用性優先:

不等待主備機同步, 直接完成切換, 這時候可能會出現數據不一致. 如果binlog為mixed模式,

主庫收到一條數據處理請求1, 同時改為只讀, 把readonly設置為true . 備庫切換後收到數據處理請求2, 先處理請求2, 同時從relay log裡讀取處理了請求1;備庫通過binlog將i請求2 同步給主庫, 主庫執行請求2 主庫和備庫請求執行順序相反.

如果binlog為row模式,由於同步的時候記錄rows 信息所以, 當主庫和備庫執行順序相反時, 主備同步的應用線程會報錯duplicate key error錯誤從而防止.主備不同步.

可靠性方案的依賴seconds_behind_master, 可用性方案可能導致部分數據不一致

MySQL 主主複製

關鍵字: MySQL master master Replication

分佈式數據庫,NOSQL,搜索引擎 2

Circular Replication 循環複製,兩個服務器之間進行異步binlog複製, 這種情況下,一般是master節點提供讀寫, stand-by master提供讀操作, master出現故障切換到stanby-master庫.

master-standby 模式中mater節點也會有自己的slave , standby主庫節點間採用半同步複製, 數據丟失的風險降到最低.

MySQL 主從復制方案

從站主控(單複制)

分佈式數據庫,NOSQL,搜索引擎 3

主從結構,主庫通過異步或半同步方式同步數據到備庫, 主庫發生故障從庫,從庫選一個節點做為主庫, 從庫其他節點從新的主節點複製數據.

帶有中繼從站的主站(鏈複製)

分佈式數據庫,NOSQL,搜索引擎 4

與第一個個方案相類似,為了減少主節點的複制壓力, 增加了中繼節點

存在問題:

從屬中繼服務器上的複制滯後將在其所有從屬服務器上產生延遲。從屬中繼服務器上的錯誤記錄將感染其所有從屬服務器。如果從屬中繼服務器發生故障,並且未使用GTID,則其所有從屬服務器都將停止複制,並且需要重新初始化它們。

具有活動主控的主控(循環複製)

分佈式數據庫,NOSQL,搜索引擎 5

主主模式循環複製

可能存在問題:

每台服務器上設置自動增量偏移,以避免主鍵衝突。沒有解決衝突的方法。 MySQL複製當前不支持主服務器和從服務器之間的任何鎖定協議,以保證跨兩個不同服務器的分佈式更新的原子性。常見的做法是只寫一個主機,而另一個主機充當熱備份節點。如果指定的主節點失敗,則必須手動切換到新主節點

帶有備份主控的主控(多次復制)

分佈式數據庫,NOSQL,搜索引擎 6

使用半同步方式保證了主節點和備份主節點之間數據同步, 當主節點發生故障時,執行主節點故障轉移時,此拓撲效果很好。備用主服務器充當熱備份服務器,因為與其他從屬服務器相比,備用主服務器具有最新數據的可能性最高。

從多個主服務器到單個從服務器(多源複製)

分佈式數據庫,NOSQL,搜索引擎 7

多源複製可用於將多個主服務器備份到單個服務器,合併表分片

MySQL和MariaDB具有不同的多源複製實現,其中MariaDB必須具有配置了gtid-domain-id的GTID,以區分原始事務,而MySQL為從屬服務器複製的每個主服務器使用單獨的複制通道。在MySQL中,可以將多源複製拓撲中的主服務器配置為使用基於全局事務標識符(GTID)的複製或基於二進制日誌位置的複制。

帶複製從站的Galera(混合複製)

分佈式數據庫,NOSQL,搜索引擎 8

混合複製是Galera提供的MySQL異步複製和虛擬同步複製.

數據分片

分片的目標: 並行處理,減少讀寫壓力分片的特點: 水平擴展,減少故障影響. 分片的原理: 通過硬編碼或映射表方式將數據分散到不同數據庫中.

硬編碼實現數據分片: 根據業務數據特點, 通過具體應用的屬性來設置分片

映射表外部存儲: 解耦一種方式防止,應用字段調整導致,重新分片處理

數據分片的挑戰:

需要大量的額外代碼,處理邏輯因此變得更加複雜。無法執行多分片的聯合查詢。無法使用數據庫的事務。隨著數據的增長,如何增加更多的服務器。

分佈式數據庫中間件

MyCatAmoebaCobar

部署方案

單一服務主從復制多應用多數據庫綜合部署: 分庫分錶分片

CAP原理

概念

一致性Consistency:每次讀取數據都應該是最近寫入數據或反饋一個錯誤。可用性Availabiliby:每次請求都應該得到一個響應而不是返回一個錯誤或者無響應。分區耐受性Partition tolerance:因為網絡原因,部分服務節點之前消息丟失或者延時, 系統仍然可以操作。

對於一個分佈式系統而言,網絡失效一定會發生, 分區耐受性P存在情況下, 一致性和可用性必須二選一。

最終一致性

最終一致性:通過各種解決方式最終達到一致。

最終一致寫衝突解決方案:

時間戳覆蓋:後來的覆蓋之前的。客戶端解決衝突:客戶端拿到數據後處理。投票解決衝突(Cassandra)

實例

卡桑德拉·哈斯(Cassandra Hbase)

ACID和BASE

ACID:傳統數據庫

A(Atomicity):事務要么全部完全,要么全部取消I(Isolation): 事務T1和T2同時運行最終結果是相同的,通過鎖來實現D(Durability): 一旦事務提交,數據要保存到數據庫C( Consistency): 只有合法的數據才能寫入數據庫

基礎:NoSQL

B(Basically Available):允許部分可用S(Soft state):允許出現中間狀態, 允許系統在不同節點數據副本之間進行數據同步存在延時。 E(Eventually consistent): 系統中所有副本通過一段時間同步後, 最終達到一致的狀態。

分佈式一致性

Zookeeper 和分佈式一致性架構

腦裂: 一次故障由於網絡調整導致兩個數據庫集群的, 虛擬IP互通導致,數據庫無法啟動.

數據庫主主備份:

zookeeper的分佈式一致性保證。

一致性算法Paxos算法。

投票選舉模式

提議者接受者學習者

三個階段:

1 Prepare階段:Propser 向Acceptors發出Prepare請求。 Acceptors針對收到Prepare進行Promise承諾。

Accept階段:Proposer收到Accept.的Promise,向Acceptors發出Propose請求。 Learn階段:

投票要有順序, Proposal ID 全局遞增

Zab 協議

zookeeper使用協議

Zookeeper API

字符串create(路徑,數據,acl,標誌)void delete(路徑,expectedVersion)統計setData(路徑,數據,expectedVersion)(數據,Stat)getData(路徑,監視)統計存在(路徑,監視)字符串[] getChildren(路徑,觀看)void sync(路徑)列出多個(操作)

配置管理

管理員•setData(“ / config / param1”,“ value”,-1)

使用者•getData(“ / config / param1”,true)

選主

如果成功,則遵循數據中描述的領導者,然後返回create(“ / servers / leader”,主機名,EPHEMERAL);如果成功,則退出並返回到步驟1。

集群管理

監控過程:

1.在/ nodes上觀看

2.在監視觸發器上,執行getChildren(/ nodes,true)

3.跟踪哪些節點消失了

每個節點:

1.創建/ nodes / node-$ {i}作為臨時節點

2.繼續定期更新/ nodes / node-$ {i}以更改節點狀態(狀態更新可能是load / iostat / cpu / others)

搜索引擎

通過爬蟲系統爬到內容,內容去重存儲;基於內容構建倒排索引計算每個頁面間的鏈接關係;對每個頁面進行打分, 基於倒排索引和鏈接關係進行檢索;構建出一個排序後的頁面內容根據搜索詞將頁面展示給客戶

爬蟲系統:

爬蟲禁爬協議

文檔矩陣與倒排索引

哪些文檔中包含關鍵詞,通過文檔矩陣構建倒排索引, 詞和文檔列表

帶詞頻的倒排索引帶詞頻和位置的倒排索引

Lucene和ElasticSearch

Doris – 海量KV Engine

產品設計介紹

當前現狀:

存在的問題:

證明設計的產品必要性對現有工作有幫助.

產品針對現狀問題的解決產品目標:

功能目標

非功能目標.

約束

技術指標

集群:

容量:

可用性:

伸縮性,平滑擴容

高性能:

邏輯架構

兩層架構Client , DataServer+Store四個核心組件: Client ,DataServer, Store, Administration

概念模型:

Machine :物理機Node: 分區單元,Namespace:數據邏輯劃分未Tag, Client可識別, 數據管理無需識別.

數據分區:

客戶端程序自己進行數據分片的選擇: 解決海量數據存儲客戶端計算分區分區算法(Partition Policy) Client 向Config Server 抓取分區配置

基於虛擬節點的分區算法

/**
* 映射关系算法主要算法过程,构造物理节点到虚拟节点的映射关系
* 客户端路由一般不需要该方法,server端迁移的时候若以虚拟节点为单位迁移需要调用该方法
* @param physicalNodesNum 映射关系中物理节点的数目
* @param virtualNodesNum 映射关系中虚拟节点的数目
* @return List方式的二维数组,第一维(级)物理节点,第二维(级)是虚拟节点
*/
public static List makeP2VMapping(int physicalNodesNum, int virtualNodesNum) {
List h = new ArrayList();
List t = new ArrayList();

for (int i = 0; i < virtualNodesNum; i++) { t.add(i); } h.add if (physicalNodesNum == 1) { return h; } for (int k = 2; k <= physicalNodesNum; k++) { List temp1 = new ArrayList();
List temp3 = new ArrayList();
int y[] = new int[k];
for (int i = 1; i <= k; i++) { y[i - 1] = (virtualNodesNum - sumY(y, i - 1)) / (k + 1 - i);// 初始化物理节点内虚拟节点数目 } for (int j = 0; j < (k-1); j++) { List temp2 = new ArrayList(); for (int x = 0; x < h.get(j).size(); x++) { if (x < y[j]) { temp2.add(h.get(j).get(x)); } else { temp3.add(h.get(j).get(x)); } } temp1.add(temp2); } temp1.add(temp3); h = temp1; } return h; } private static int sumY(int[] y, int i) { int sum = 0; for (int k = 0; k < i; k++) { sum += y[k ]; } return sum; }

遞增的處理, 每次從新增一個物理節點, 從原有節點取出排在後面的節點放到新的物理節點裡 .

基本訪問架構

對等Node 訪問

雙寫保證可用性(W=2, R=1)

基於分區算法查找兩個Node

複製1節點複製2節點

數據恢復和數據同步

重做日誌更新日誌

健康檢查和配置抓取

關鍵技術點

臨時失效的fail over永久失效額的fail over擴容數據遷移

數據可識別功能- 邏輯數據結構

數據分組

Namespace:一個業務實體數據的集合Data Definition Namespace的MetaData數據結構定義,滿足“數據定義可描述“的需求。

參考及引用

架構師訓練營作業-李智慧老師相關講義

攝影者 弗拉德·謝安來自 像素

https://medium.com/swlh/zero-downtime-master-slave-replication-4f2814138edf

Mysql實戰45講

https://severalnines.com/resources/database-management-tutorials/mysql-replication-high-availability-tutorial