DDIA讀書筆記 第五章 資料同步

2021-10-03 23:17:44 字數 1884 閱讀 9811

通常主節點負責寫入,從節點負責讀取,主節點的資訊需要同步給從節點。

主從同步按照同步方式可以分為同步同步,非同步同步,半同步同步。同步同步需要等待從節點返回確認資訊,才可以進行下一次同步,非同步同步則不需要。半同步同步則是部分節點同步同步,部分節點非同步同步,在吞吐量和一致性方面做了乙個折中。

基於語句的同步,就是將主節點的操作語句傳送給從節點,讓從節點執行。這種方式在有些場景下不適用:

wal 預寫日誌,記錄了某塊磁碟的某個位元組的變化,主從節點基於 wal 進行同步,會使得同步和儲存引擎緊密耦合,不方便版本公升級。

同步行請求,包括行插入、行刪除、行更新,相較於基於預寫日誌的同步,解耦了儲存引擎,

邏輯日誌與儲存引擎解耦

因為主節點的資訊同步到從節點有時延,所以客戶端從從節點上讀取的資料不一定是最新的。這就是同步滯後問題。

乙個使用者寫完後再讀,主節點未能在讀之前將資料同步給從節點,給使用者造成了寫入沒成功的錯覺,如下圖。

為了保證 read-after-write 一致性,可以採取如下方案:

主節點寫入後,同步到兩個從節點的時延不一致,導致第一次讀有效,第二次讀無效,如下圖。

為了保證單調讀一致性,可以讓使用者固定從某乙個從節點讀,例如對使用者 id 做 hash 路由到從節點。

字首一致讀指的是,讀取的順序和寫入的順序相同,這在後面章節會講到。

有關同步滯後問題,可以從應用層出發去解決,因為應用層可以判斷資料是否是最新的。事務也可以一定程度地保證一致性。

單個資料中心使用多主節點沒什麼意義,多主節點一般適用於多個資料中心的場景。

一種極端的場景就是乙個客戶端裝置就是乙個資料中心,比如筆記軟體,在手機或筆記本離線時也要有修改能力,上線後再進行主節點之間的同步。

多主節點很容易面臨寫衝突問題。

應用層對特定的寫操作總是通過某乙個主節點,這就需要路由層面的邏輯來實現。例如對於每個使用者只能修改自己資料的場景,把同一使用者路由到同一主節點,就可以避免寫衝突。

主節點之間可以用環形、星形、全鏈結的拓撲結構。

環形和星形的結構,寫請求需要多次**才能到達所有主節點,且某乙個節點故障,會影響其它節點的日誌同步。全鏈結拓撲則沒有這個問題,但是由於乙個節點會收到多個節點的操作請求,需要確保這些請求是正確有序的,這一點在無主章節進一步**。

共 n 個節點,寫入時需寫入 w 個節點,讀取則從 r 個節點讀取。n w r 需滿足:n < w + r。這樣寫入的節點集合和讀取的節點集合必然有交集,所以一定能讀取到最新值。這稱之為 quorum 機制。

那麼如何確認哪個節點的值更新呢?版本號或者時間戳都是供選擇的方案。

併發寫即多個客戶端對同乙個鍵同時寫入,但因為時鐘同步和網路阻塞的緣故,「同時」很難界定,因此如果事件a和b互相意識不到對方,則a和b就是併發的,而不要求時間上的同時發生。

處理併發寫的難點之一是確定操作的依賴關係,或者說,先後順序。下圖用乙個購物車的例子說明了一種基於版本號的單節點併發處理演算法。

演算法流程如下:

對於刪除的項,不是簡單地從資料庫裡刪除,因為這樣在 merge 時又會把刪除的項加進來,正確的操作是標記刪除,在合併時再刪除。

以上所述均是針對單個主節點的情況,如果多個主節點,乙個版本號就沒法解決了。乙個解決方案是版本向量,每個主節點的每個鍵都有乙個版本號。

第五章 讀書筆記

第五章 搭建s3c6410開發板的測試環境 一.s3c6410開發板簡介.s3c6410是三星公司推出的一款低功耗,高價效比的risc處理器,它基於arm11核心,可廣泛應用於移動 和通用處理器等領域。該處理器有乙個非常先進的3d加速器,能實現4m s的3d加速 二.安裝串列埠除錯工具 minico...

C Template 讀書筆記 第五章

內容 技巧性基礎知識 關鍵字 typename template this 模板的模板引數 零初始化 字串的模板實參 具體內容描述 1.對模板使用typename 場景 template class test 這裡需要增加typename,需要標記告訴編譯器這個是宣告乙個模板引數型別t裡面的subt...

C 讀書筆記 第五章 語句

空語句 程式某處語法上需要一條語句而邏輯上不需要 建議使用時加注釋 while cin s s sought 空塊的作用等同於空語句 上面的 也可以用 代替 懸垂 else switch case關鍵字和它對應的值一起被稱為case標籤,case標籤必須是整形常量表示式 case 3.14 錯誤 不...