自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

分布式數(shù)據(jù)庫數(shù)據(jù)一致性原理說明與實現(xiàn)

數(shù)據(jù)庫 大數(shù)據(jù) 分布式
分布式數(shù)據(jù)庫的數(shù)據(jù)一致性管理是其最重要的內(nèi)核技術(shù)之一,也是保證分布式數(shù)據(jù)庫滿足數(shù)據(jù)庫最基本的ACID特性中的 “一致性”(Consistency)的保障。在分布式技術(shù)發(fā)展下,數(shù)據(jù)一致性的解決方法和技術(shù)也在不斷的演進,本文就以作者實際研發(fā)的分布式數(shù)據(jù)庫作為案例,介紹分布式數(shù)據(jù)庫數(shù)據(jù)一致性的原理以及實際實現(xiàn)。

[[206931]]

前言

分布式數(shù)據(jù)庫的數(shù)據(jù)一致性管理是其最重要的內(nèi)核技術(shù)之一,也是保證分布式數(shù)據(jù)庫滿足數(shù)據(jù)庫最基本的ACID特性中的 “一致性”(Consistency)的保障。在分布式技術(shù)發(fā)展下,數(shù)據(jù)一致性的解決方法和技術(shù)也在不斷的演進,本文就以作者實際研發(fā)的分布式數(shù)據(jù)庫作為案例,介紹分布式數(shù)據(jù)庫數(shù)據(jù)一致性的原理以及實際實現(xiàn)。

1.數(shù)據(jù)一致性

1.1數(shù)據(jù)一致性是什么

大部份使用傳統(tǒng)關(guān)系型數(shù)據(jù)庫的DBA在看到“數(shù)據(jù)一致性”時,***反應(yīng)可能都是數(shù)據(jù)在跨表事務(wù)中的數(shù)據(jù)一致性場景。但是本文介紹的“數(shù)據(jù)一致性”,指的是“數(shù)據(jù)在多份副本中存儲時,如何保障數(shù)據(jù)的一致性”場景。

由于在大數(shù)據(jù)領(lǐng)域,數(shù)據(jù)的安全不再由硬件來保證,而是通過軟件手段,通過同時將數(shù)據(jù)寫入到多個副本中,來確保數(shù)據(jù)的安全。數(shù)據(jù)庫在同時向多個副本寫入記錄時,如何確保每個副本數(shù)據(jù)一致,稱為“數(shù)據(jù)一致性”。

1.2關(guān)系型數(shù)據(jù)庫如何保障數(shù)據(jù)一致性

傳統(tǒng)的關(guān)系型數(shù)據(jù)庫對于運行環(huán)境–硬件要求都比較高,例如Oracle會建議用戶使用小型機+共享存儲作為數(shù)據(jù)庫的運行環(huán)境,DB2 DPF也同樣建議用戶采用更好的服務(wù)器+高端存儲來搭建數(shù)據(jù)庫的運行環(huán)境。所以在數(shù)據(jù)存儲安全的技術(shù)要求下,傳統(tǒng)關(guān)系型數(shù)據(jù)庫更多是依賴硬件的技術(shù)來保障數(shù)據(jù)的安全性。

 

 

 

 

 

因為關(guān)系型數(shù)據(jù)庫的數(shù)據(jù)安全是基于硬件來保障,并且數(shù)據(jù)也不會通過同時存儲多份來保障數(shù)據(jù)的安全,所以關(guān)系型數(shù)據(jù)庫的用戶默認認為數(shù)據(jù)存儲是一致的。

1.3分布式存儲如何保障數(shù)據(jù)一致性

本文在討論分布式存儲時,主要指的是大數(shù)據(jù)產(chǎn)品中的分布式文件系統(tǒng)和分布式數(shù)據(jù)庫,例如:SequoiaDB和HDFS。

用戶在搞明白分布式存儲的數(shù)據(jù)一致性原理時,必須要先明白為什么他們就需要數(shù)據(jù)一致性,和分布式存儲的數(shù)據(jù)存儲與關(guān)系型數(shù)據(jù)庫的數(shù)據(jù)存儲又有什么區(qū)別。

大數(shù)據(jù)技術(shù)的誕生,確確實實讓系統(tǒng)的性能有新的突破,并且支持硬件以水平擴展的方式來獲得線性增長的性能和存儲。這些都是過去傳統(tǒng)關(guān)系型數(shù)據(jù)庫所無法提供的。另外,大數(shù)據(jù)技術(shù)也拋棄了運行環(huán)境必須足夠好的硬性要求,而是允許用戶通過批量廉價X86服務(wù)器+本地磁盤的方式搭建規(guī)模集群,從而獲得比過去依賴硬件垂直擴展所提供的更強的計算能力和更多的存儲空間。

大數(shù)據(jù)技術(shù)的核心思想就是分布式,將一個大的工作任務(wù)分解成多個小任務(wù),然后通過分布式并發(fā)操作的方式將其完成,從而提高整個系統(tǒng)的計算效率或者是存儲能力。而在分布式環(huán)境下,由于硬件的要求降低,必然需要大數(shù)據(jù)產(chǎn)品提供另外一個重要的功能–數(shù)據(jù)安全。

 

 

 

 

大數(shù)據(jù)產(chǎn)品在解決數(shù)據(jù)安全的方式上,都比較接近,簡單來說,就是讓一份數(shù)據(jù)通過異步或者同步的方式保存在多臺機器上,從而保障數(shù)據(jù)的安全。

 

分布式存儲在解決數(shù)據(jù)安全的技術(shù)難點后,又引入了一個新的技術(shù)問題,就是如何保障多個副本中的數(shù)據(jù)一致性。目前SequoiaDB是使用Raft算法來保證數(shù)據(jù)在多個副本中一致性。

2.Raft算法

2.1Raft算法背景

在分布式環(huán)境下,***的一致性算法應(yīng)該是Paxos算法,但是由于它實在過于晦澀難懂,并且實現(xiàn)起來極度困難,所以在2013年,Diego Ongaro、John Ousterhout兩個人以易懂(Understandability)為目標設(shè)計了一套一致性算法Raft。Raft算法***的特點在于簡單易懂,并且實現(xiàn)起來簡單

2.2Raft算法概述

與Paxos不同,Raft強調(diào)的是易懂,Raft和Paxos一樣只要保證n/2+1節(jié)點正常就能夠提供服務(wù)。

眾所周知當問題較為復(fù)雜時可以把問題分解為幾個小問題來處理,Raft也使用了分而治之的思想。Raft算法重點解決三個子問題:選舉(Leader election)、日志復(fù)制(Log replication)、安全性(Safety)。

Raft算法強化了Leader節(jié)點的功能,F(xiàn)ollower節(jié)點的數(shù)據(jù)只能夠從Leader中獲取,所以Follower節(jié)點的實現(xiàn)就變得簡單,只要負責(zé)和Leader保持通信,并且接受Leader推送的數(shù)據(jù)即可。

2.3Raft算法原理

2.3.1 節(jié)點角色

Raft算法中,對節(jié)點的狀態(tài)分為3種角色,分別是Leader(***)、Follower(追隨者)和Candidate(候選者)。

Leader,負責(zé)處理來自客戶端的請求,負責(zé)將日志同步到Follower中,并且保證與Follower之間的heartBeat聯(lián)系;

Follower,當集群剛剛啟動時,所有節(jié)點均為Follower狀態(tài),它的工作主要為響應(yīng)Leader的日志同步請求,響應(yīng)Candidate的請求,以及把請求到Follower的事務(wù)請求轉(zhuǎn)發(fā)給Leader;

Candidate,選舉Leader時負責(zé)投票,選舉出來Leader后,節(jié)點將從Candidate狀態(tài)變?yōu)長eader狀態(tài)。

 

 

 

 

2.3.2 Terms

在分布式環(huán)境下,“時間同步”一直都是老大難的技術(shù)難題。Raft為了解決這個問題,將時間劃分為一個一個的Term(可以理解為“邏輯時間”)來處理在不同時間段里的數(shù)據(jù)一致性。

Terms有以下原則

  • 每個Term中,至多存在一個Leader
  • 某些Term中,有可能存在由于選舉失敗,沒有Leader的情況
  • 每個節(jié)點自己維護本地的currentTerm
  • 每個Term都是一個連續(xù)遞增的編號
  • 如果Follower的Term編號比別的Follower Term編號小時,該Follower Term編號將更新Term編號,以保持與其他Follower Term編號一致

2.3.3 選舉

Raft的選舉由定時器觸發(fā),每個節(jié)點的觸發(fā)時間都不相同。

所有的節(jié)點在開始時狀態(tài)都為Follower,當定時器觸發(fā)選舉后Term編號遞增,該節(jié)點的狀態(tài)由Follower轉(zhuǎn)為Candidate,并且向其他節(jié)點發(fā)起RequestVote RPC請求,這時選舉有3種情況可能發(fā)生:

發(fā)起RequestVote的節(jié)點收到n/2+1(過半數(shù))個節(jié)點的投票,該節(jié)點將從Candidate狀態(tài)變?yōu)長eader狀態(tài),開始向其他節(jié)點發(fā)送HeartBeat以保持Leader的正常狀態(tài)

如果收到投票請求后,該節(jié)點發(fā)現(xiàn)發(fā)起投票的節(jié)點Term大于自己,則該節(jié)點狀態(tài)從Candidate轉(zhuǎn)為Follower,否則保持Candidate狀態(tài),并且拒絕該投票請求

選舉期間發(fā)生了超時,則Term編號遞增,重新發(fā)起選舉

 

 

 

 

 

2.3.4 日志復(fù)制

日志復(fù)制主要的作用就是用來保證節(jié)點的數(shù)據(jù)一致性與高可用性。

當Leader被選舉出來后,所有的事務(wù)操作都必須要經(jīng)過Leader處理。這些事務(wù)操作成功后,將會被按順序?qū)懭氲絃OG中,每個LOG都包含一個index編號。

Leader在LOG發(fā)生變化后,通過HeartBeat將新的LOG同步到Follower上,F(xiàn)ollower在接收到LOG后,再向Leader發(fā)送ACK信息,當Leader接到大多數(shù)(2/n+1)Follower的ACK信息后,將該LOG設(shè)置為已提交,并且Leader將LOG追加到本地磁盤中。

同時Leader將在下一個HeartBeat中,通知所有的Follower將該LOG存儲在各自的本地磁盤中。

2.3.5 安全性

安全性是用于確保每個節(jié)點都是按照相同的日志序列進行執(zhí)行的安全機制。

如果當某個Follower在同步Leader的日志時失敗,但是未來該Follower又可能被選舉為Leader時,就有可能導(dǎo)致前一個Leader已經(jīng)commit的日志發(fā)生覆蓋,這樣就導(dǎo)致了節(jié)點執(zhí)行不同序列的日志。

Raft的安全性就是用于保證選舉出來的Leader一定包含先前已經(jīng)commit LOG 的機制,主要遵循的原則如下:

每個Term 只能選舉一個Leader;

Leader的日志完整性,則當Candidate重新選舉Leader時,新的Leader必須要包含先前已經(jīng)commit的LOG;

Candidate在選舉新的Leader時,使用Term來保證LOG的完整性;

3.分布式數(shù)據(jù)庫數(shù)據(jù)一致性技術(shù)實現(xiàn)

以國產(chǎn)原廠的分布式數(shù)據(jù)庫SequoiaDB為例,SequoiaDB在多副本的部署中,采用Raft算法保證數(shù)據(jù)在多副本環(huán)境中保持一致。

SequoiaDB集群中,總共包含3中角色節(jié)點,分別是協(xié)調(diào)節(jié)點、編目節(jié)點和數(shù)據(jù)節(jié)點。由于協(xié)調(diào)節(jié)點本身不存任何數(shù)據(jù),所以只有編目節(jié)點和數(shù)據(jù)節(jié)點存在事務(wù)操作,換言之,編目分區(qū)組和數(shù)據(jù)分區(qū)組的副本同步采用Raft算法保證數(shù)據(jù)一致性。

 

 

 

 

 

3.1編目節(jié)點和數(shù)據(jù)節(jié)點的事務(wù)日志介紹

編目節(jié)點和數(shù)據(jù)節(jié)點由于都是需要存儲數(shù)據(jù)的,并且在集群部署中該,為了確保數(shù)據(jù)的安全,都是建議采用分布式的方式進行部署,所以在數(shù)據(jù)同步中,需要采用Raft算法的基本原理進行數(shù)據(jù)同步。

編目節(jié)點和數(shù)據(jù)節(jié)點在存儲數(shù)據(jù)時,共包含兩大部分,一個真實的數(shù)據(jù)文件,另一個是事務(wù)日志文件。

 

 

 

 

SequoiaDB的節(jié)點事務(wù)日志,默認情況下由20個64MB(總大小為1.25GB)的文件構(gòu)成。節(jié)點的事務(wù)日志主要包含一個index編號和數(shù)據(jù)操作內(nèi)容,index編號保持永遠遞增狀態(tài)。

另外,SequoiaDB節(jié)點的事務(wù)日志不會***保存,而是當所有的事務(wù)日志寫滿后,再重新從***個文件開始進行覆蓋寫入。

3.2編目分區(qū)組的數(shù)據(jù)一致性

由于編目分區(qū)組是保存SequoiaDB集群的元信息,數(shù)據(jù)同步要求高,所以編目分區(qū)組的數(shù)據(jù)一致性要求為強一致性,即每次向編目分區(qū)組執(zhí)行事務(wù)操作時,必須要確保所有的編目節(jié)點操作成功,才計算該操作執(zhí)行成功,否則該事務(wù)操作將在整個編目分區(qū)組中回退事務(wù)日志,以保證分區(qū)組內(nèi)的數(shù)據(jù)一致性。

另外,編目分區(qū)組還有一個比較重要的特性,即編目分區(qū)組必須要存在主節(jié)點才能夠正常工作,如果老的主節(jié)點宕機了,編目分區(qū)組暫時沒有主節(jié)點,則該編目分區(qū)組不能夠?qū)ν馓峁┤魏问聞?wù)操作和數(shù)據(jù)查詢操作。

3.3數(shù)據(jù)分區(qū)組的數(shù)據(jù)一致性

數(shù)據(jù)分區(qū)組的數(shù)據(jù)一致性默認情況下為最終一致性性,即只要求主節(jié)點執(zhí)行事務(wù)操作成功即視為操作成功,主節(jié)點將在未來異步同步ReplicaLOG到從節(jié)點上。

3.4主從節(jié)點的事務(wù)日志同步

SequoiaDB的主從節(jié)點是通過事務(wù)日志同步來保證數(shù)據(jù)一致性的,并且主從節(jié)點的事務(wù)日志同步是單線程完成。

如果當主節(jié)點和從節(jié)點的LSN差距為一條記錄,則主節(jié)點會主動將***的事務(wù)日志推送給從節(jié)點。

如果主節(jié)點和從節(jié)點的LSN差距超過一條記錄,則從節(jié)點會主動向主節(jié)點請求同步事務(wù)日志,主節(jié)點收到同步請求后,會將從節(jié)點的LSN號到主節(jié)點***的LSN號對應(yīng)的事務(wù)日志打包一次性發(fā)送給從節(jié)點。

3.5從節(jié)點日志重放

當從節(jié)點獲取到主節(jié)點推送過來的事務(wù)日志后,就會自動解析事務(wù)日志和重放。從節(jié)點在重放事務(wù)日志時,默認情況下會以10并發(fā)來重放事務(wù)日志。

從節(jié)點在執(zhí)行并發(fā)重放日志時有條件限制,即在集合的唯一索引個數(shù)<=1的情況下,INSERT、DELETE、UPDATE、LOB WRITE、LOBUPDATE、LOB REMOVE操作可以支持并發(fā)重放事務(wù)日志。從節(jié)點在做并發(fā)重放時,是通過記錄的OID進行打散并發(fā)執(zhí)行,這樣就可以保證對相同記錄的操作不會由于并發(fā)重放導(dǎo)致數(shù)據(jù)不一致。

但是用戶需要注意,從節(jié)點在重放事務(wù)日志時, DROP CL操作不能夠支持并發(fā)重放。

4.SequoiaDB數(shù)據(jù)一致性應(yīng)用

目前SequoiaDB數(shù)據(jù)分區(qū)組的數(shù)據(jù)一致性是基于集合級別進行配置的。用戶在使用SequoiaDB過程中,可以隨時調(diào)整數(shù)據(jù)一致性的強度。

4.1 創(chuàng)建集合時指定

在一個多副本的SequoiaDB集群中,集合默認的數(shù)據(jù)一致性行級別為“最終一致性”。用戶可以在創(chuàng)建集合時顯式指定該集合的“數(shù)據(jù)一致性強度”,例如可以在SequoiaDB Shell中執(zhí)行以下命令

db.CSNAME.createCL(“CLNAME”,{ReplSize:3})

ReplSize參數(shù)填寫范圍

 

 

 

 

4.2 修改已經(jīng)存在的集合

如果集合在創(chuàng)建時沒有設(shè)置“數(shù)據(jù)一致性”ReplSize參數(shù),用戶也可以對已經(jīng)存在的集合進行修改,在SequoiaDB Shell修改命令如下

db.CSNAME.CLNAME.alter({ReplSize:3})

ReplSize的取值范圍和創(chuàng)建集合時一致。

4.3 如何查看集合的ReplSize參數(shù)

如果用戶希望檢查當前集合的RepliSize參數(shù)值,可以通過數(shù)據(jù)庫快照進行查看,在SequoiaDB Shell查看命令如下

  1. db.snapshot(SDB_SNAP_CATALOG,{}, {"Name":null"IsMainCL":null,"MainCLName":null"ReplSize":null}) 

打印信息如下

  1.  
  2. "MainCLName":"test.main2"
  3.  
  4. "Name""foo.bar2"
  5.  
  6. "IsMainCL"null
  7.  
  8. "ReplSize"null 
  9.  
  10.  
  11.  
  12. "IsMainCL"true
  13.  
  14. "Name""test.main2"
  15.  
  16. "MainCLName"null
  17.  
  18. "ReplSize"null 
  19.  
  20.  
  21.  
  22. "Name""foo.tt"
  23.  
  24. "ReplSize": 3, 
  25.  
  26. "IsMainCL"null
  27.  
  28. "MainCLName"null 
  29.  

 

5. 總結(jié)

分布式的數(shù)據(jù)庫,通過Raft算法來確保在分布式情況上數(shù)據(jù)的一致性,并且編目分區(qū)組和數(shù)據(jù)分區(qū)組對數(shù)據(jù)一致性要求又有所不同,編目分區(qū)組始終要求的是數(shù)據(jù)在多副本請情況下數(shù)據(jù)強一致性,而數(shù)據(jù)分區(qū)組則可以由用戶在創(chuàng)建集合時來執(zhí)行數(shù)據(jù)一致性的強度,強度越高,數(shù)據(jù)安全性越好,但是執(zhí)行的效率就會相對較差,反之依然。

目前SequoiaDB在數(shù)據(jù)一致性場景上,用戶的調(diào)整空間較大,可以根據(jù)不同的業(yè)務(wù)要求來調(diào)整數(shù)據(jù)一致性的強度,以滿足業(yè)務(wù)或追求性能***,或者數(shù)據(jù)最安全的技術(shù)要求。 

責(zé)任編輯:龐桂玉 來源: 36大數(shù)據(jù)
相關(guān)推薦

2025-03-27 03:00:00

2024-05-30 07:00:51

2012-09-24 09:35:42

分布式系統(tǒng)

2019-10-11 23:27:19

分布式一致性算法開發(fā)

2019-10-09 08:41:49

XA2PC3PC

2021-06-03 15:27:31

RaftSOFAJRaft

2018-09-11 10:46:10

緩存數(shù)據(jù)庫一致性

2018-05-16 16:10:28

數(shù)據(jù)庫緩存MySQL

2009-06-18 09:18:08

Oracle檢索數(shù)據(jù)數(shù)據(jù)一致性事務(wù)恢復(fù)

2023-12-01 13:51:21

數(shù)據(jù)一致性數(shù)據(jù)庫

2023-08-22 09:32:44

邊緣計算管理

2019-09-05 08:43:34

微服務(wù)分布式一致性數(shù)據(jù)共享

2022-12-05 08:24:32

mongodb數(shù)據(jù)庫數(shù)據(jù)

2021-11-22 16:30:30

分布式一致性分布式系統(tǒng)

2025-04-27 08:52:21

Redis數(shù)據(jù)庫緩存

2021-04-24 16:58:03

數(shù)據(jù)庫工具技術(shù)

2021-06-11 09:21:58

緩存數(shù)據(jù)庫Redis

2024-12-26 15:01:29

2017-10-30 10:24:03

存儲系統(tǒng)數(shù)據(jù)

2025-03-27 08:20:54

點贊
收藏

51CTO技術(shù)棧公眾號