分布式資料庫一致性

① 資料庫的acid中的一致性到底是什麼意思

數據一致性通常指關聯數據之間的邏輯關系是否正確和完整。而數據存儲的一致性模型則可以認為是存儲系統和數據使用者之間的一種約定。如果使用者遵循這種約定，則可以得到系統所承諾的訪問結果

常用的一致性模型有：
a、嚴格一致性（linearizability, strict/atomic Consistency）：讀出的數據始終為最近寫入的數據。這種一致性只有全局時鍾存在時才有可能，在分布式網路環境不可能實現。

b、順序一致性（sequential consistency）：所有使用者以同樣的順序看到對同一數據的操作，但是該順序不一定是實時的。
c、因果一致性（causal consistency）：只有存在因果關系的寫操作才要求所有使用者以相同的次序看到，對於無因果關系的寫入則並行進行，無次序保證。因果一致性可以看做對順序一致性性能的一種優化，但在實現時必須建立與維護因果依賴圖，是相當困難的。
d、管道一致性（PRAM/FIFO consistency）：在因果一致性模型上的進一步弱化，要求由某一個使用者完成的寫操作可以被其他所有的使用者按照順序的感知到，而從不同使用者中來的寫操作則無需保證順序，就像一個一個的管道一樣。 相對來說比較容易實現。
e、弱一致性（weak consistency）：只要求對共享數據結構的訪問保證順序一致性。對於同步變數的操作具有順序一致性，是全局可見的，且只有當沒有寫操作等待處理時才可進行，以保證對於臨界區域的訪問順序進行。在同步時點，所有使用者可以看到相同的數據。
f、 釋放一致性（release consistency）：弱一致性無法區分使用者是要進入臨界區還是要出臨界區， 釋放一致性使用兩個不同的操作語句進行了區分。需要寫入時使用者acquire該對象，寫完後release，acquire-release之間形成了一個臨界區，提供 釋放一致性也就意味著當release操作發生後，所有使用者應該可以看到該操作。

② 分布式資料庫有什麼特點

1.數據獨立性與位置透明性
數據獨立性是資料庫方法追求的主要目標之一，分布透明性指用戶不必關心數據的邏輯分區，不必關心數據物理位置分布的細節，也不必關心重復副本（冗餘數據）的一致性問題，同時也不必關心局部場地上資料庫支持哪種數據模型。分布透明性的優點是很明顯的。有了分布透明性，用戶的應用程序書寫起來就如同數據沒有分布一樣。當數據從一個場地移到另一個場地時不必改寫應用程序。當增加某些數據的重復副本時也不必改寫應用程序。數據分布的信息由系統存儲在數據字典中。用戶對非本地數據的訪問請求由系統根據數據字典予以解釋、轉換、傳送。

2.集中和節點自治相結合
在分布式資料庫中，數據的共享有兩個層次：一是局部共享，即在局部資料庫中存儲局部場地上各用戶的共享數據．這些數據是本場地用戶常用的。二是全局共享，即在分布式資料庫的各個場地也存儲可供網中其它場地的用戶共享的數據，支持系統中的全局應用。因此，相應的控制結構也具有兩個層次：集中和自治。分布式資料庫系統常常採用集中和自治相結合的控制結構,各局部的DBMS可以獨立地管理局部資料庫，具有自治的功能。同時，系統又設有集中控制機制，協調各局部DBMS的工作，執行全局應用。另外，在不同的系統集中和自治的程度不盡相同。
3.支持全局資料庫的一致性和和可恢復性
分布式資料庫中各局部資料庫即滿足集中式資料庫的一致性、可串列性和可恢復性，還保證了資料庫的全局一致性、並行操作的可串列性和系統的全局可恢復性。這是因為全局應用要涉及兩個以上結點的數據。因此在分布式資料庫系統中一個業務可能由不同場地上的多個操作組成。這樣，當其中某一個結點出現故障操作失敗後如何使全局業務滾回呢？如何使另一個結點撤銷已執行的操作(若操作已完成或完成一部分）或者不必再執行業務的其它操作(若操作尚沒執行)？這些技術要比集中式資料庫復雜和困難得多，分布式資料庫系統必須解決這些問題。
4.復制透明性
用戶不用關心資料庫在網路中各個節點的復制情況，被復制的數據的更新都由系統自動完成。在分布式資料庫系統中，可以把一個場地的數據復制到其他場地存放，應用程序可以使用復制到本地的數據在本地完成分布式操作，避免通過網路傳輸數據，提高了系統的運行和查詢效率。但是對於復制數據的更新操作，就要涉及到對所有復制數據的更新。
5.易於擴展性
在大多數網路環境中，單個資料庫伺服器最終會不滿足使用。如果伺服器軟體支持透明的水平擴展，那麼就可以增加多個伺服器來進一步分布數據和分擔處理任務。

③ 分布式系統中，為什麼要定義不同的一致性模型，其具有什麼意義

1. 資料庫定義:資料庫是長期儲存在計算機內、有組織的、可共享的大量數據的集合。資料庫中的數據按一定的數據模型組織、描述和儲存，具有較小的冗餘度、較高的數據獨立性和易擴展性，並可為各種用戶共享。2. 資料庫管理技術發展的三個階段：人工管理階段，文件系統階段，資料庫系統階段。3. DBMS（資料庫管理系統）是位於用戶與操作系統之間的一層數據管理軟體。主要功能：1，數據定義功能。2，數據組織、存儲和管理。3，數據操縱功能。4，資料庫的事務管理和運行管理。5，資料庫的建立和維護功能。6，其他功能。4. 什麼是數據模型及其要素? (設計題)： 數據模型是資料庫中用來對現實世界進行抽象的工具，是資料庫中用於提供信息表示和操作手段的形式構架。一般地講，數據模型是嚴格定義的概念的集合。這些概 念精確地描述系統的靜態特性、動態特性和完整性約束條件。因此數據模型通常由數據結構、數據操作和完整性約束三部分組成。 (1)數據結構：是所研究的對象類型的集合，是對系統的靜態特性的描述。 (2)數據操作：是指對資料庫中各種對象(型)的實例(值)允許進行的操作的集合，包括操作及有關的操作規則，是對系統動態特性的描述。 (3)數據的約束條件：是完整性規則的集合，完整性規則是給定的數據模型中數據及其聯系所具有的制約和依存規則，用以限定符合數據模型的資料庫狀態以及狀態的變化，以保證數據的正確、有效、相容。最常用的數據模型：層次模型，網狀模型，關系模型，面積對象模型，對象關系模型。5.常用的數據模型有哪些（邏輯模型是主要的），各有什麼特徵，數據結構是什麼樣的。答：數據模型可分為兩類：第一類是概念模型，也稱信息模型，它是按用戶的觀點來地數據和信息建模，主要用於資料庫設計。第二類是邏輯模型和物理模型。其中邏輯模型主要包括層次模型、層次模型、關系模型、面向對象模型和對象關系模型等。它是按計算機系統的觀點對數據建模，主要用於DBMS的實現。物理模型是對數據最低層的抽象，它描述數據在系統內部的表示方式和存取方法，在磁碟或磁帶上的存儲方式和存取方法，是面向計算機系統的。物理模型是具體實現是DBMS的任務，資料庫設計人員要了解和選擇物理醋，一般用戶則不必考慮物理級的細節。層次數據模型的數據結構特點：一是：有且只有一個結點沒有雙親結點，這個結點稱為根結點。二是：根 以外的其他結點有且只有一個雙親結點。優點是：1.層次 數據結構比較簡單清晰。2.層次資料庫的查詢效率高。3.層次數據模型提供了良好的完整性支持。缺點主要有：1.現實世界中很多聯系是非層次性的，如結點之間具有多對多聯系。2.一個結點具有多個雙親等 ，層次模型表示這類聯系的方法很笨拙，只能通過引入冗餘數據或創建非自然的數據結構來解決。對插入和刪除操作的限制比較多，因此應用程序的編寫比較復雜。3.查詢子女結點必須通過雙親結點。4.由於結構嚴密，層次命令趨於程序化。可見用層次模型對具有一對多的層次聯系的部門描述非常自然，直觀容易理解，這是層次資料庫的突出優點。網狀模型：特點：1.允許一個以上的結點無雙親2.一個結點可以有多於一個的雙親。網狀數據模型的優點主要有：1.能夠更為直接地描述現實世界，如一個結點可以有多個雙親。結點 之間可以有多種上聯第。2.具有良好的性能，存取效率較高。缺點主要有：1.結構比較復雜，而且隨著應用環境的擴大，資料庫的結構就變得越來越復雜，不利於最終 用戶掌握。2.網狀模型的DDL,DML復雜,並且要嵌入某一種高級語言中，用戶不容易掌握，不容易使用。關系數據模型具有下列優點：1.關系模型與非關系模型不同，它是建立在嚴格的數學概念的基礎上的。2.關系模型的概念單一。。3.關系模型的存取路徑對用戶透明，從而具有更高的數據獨立性，更好的安全保密性，也簡化了程序員的工作和資料庫開發的建立 的工作。。主要的缺點是：由於存取路徑房租明，查詢效率往往不如非關系數據模型。因此為了提高性能，DBMS必須對用戶的查詢請求進行優化。因此增加 了開發DBMS的難度，不過用戶不必考慮這些系統內部的優化技術細節。6.三級體系結構，外模式，模式 ，內模式定義是什麼？模式也稱邏輯模式，是資料庫中全體數據的邏輯結構和牲的描述，是所有用戶的公共數據視圖。 外模式也稱子模式或用戶模式，它是資料庫用戶能夠看見和使用的局部數據的邏輯結構和特徵的描述，是資料庫用戶的數據視圖是與某一應用有關的數據的邏輯表示。 內模式也稱存儲模式 ，是一個資料庫只有一個內模式。它是數據物理結構和存儲方式的描述，是數據在資料庫內部的表示方式。7.兩級映像和兩級獨立性，為什麼叫物理獨立性和邏輯獨立性。當模式改變時由資料庫管理員對各個外模式、模式的映像亻相應改變，可以使外模式保持不變。應用程序是依據數據的外模式編寫的，從而應用程序不必修改，保證了數據與程序的邏輯獨立生，簡稱數據的邏輯獨立性。當資料庫的存儲結構改變了，由資料庫管理員對模式、內模式映像作 相應改變，可以使模式保持不變，從而應用程序也不必改變。保證了數據與程序的物理獨立性，簡稱數據的物理獨立性。8.資料庫系統一般由資料庫、資料庫管理系統 （及其開發工具）、應用系統和資料庫管理員構成。9.關系的完整性（實體完整性、參照完整性、和用戶定義的完整性）三部分內容，其中前二者是系統自動支持的，DBMS完整性控制子系統的三個主要功能？：提供定義完整性約束條件的機制，提供完整性檢查的方法，違約處理。16.SQL的定義；即結構化查詢語言，是關系資料庫的標准語言，是一個通用的、功能極強的關系資料庫語言。分類（互動式和嵌入式）17.group by 和having子句的作用20.視圖的概念：視圖是從一個或幾個基本表導出的表。及相關操作：定義視圖，查詢視圖，更新視圖。視圖更新有什麼操作：插入，刪除，和修改。22.資料庫規范化的方法函數依賴的定義什麼叫1NF2NF3NF BCNF定義：關系資料庫中的關系是要滿足一定要求的，滿足不同程度要求的為不同範式。滿足最低要求的叫第一範式，簡稱1NF。在第一範式中滿足進一步要求的為第二範式，其餘以此類推。各種範式之間的聯系有：5NF（4NF（BCNF（3NF（2NF（1NF。25.資料庫設計的幾個階段，每個階段常用的方法和簡要的內容：六個階段：需求分析、概念結構設計、羅織結構設計、物理設計、資料庫實施、資料庫運行和維護。28.事務的概念？事務有哪些基本屬性commit roll back含義：事務：是用戶定義的一個資料庫操作序列，這些操作要麼全做，要麼全不做，是一個不可分割的單位。四個特性：原子性，一致性，隔離性，持續性。Commit（提交：提交事務的所有操作） rollback（回滾：在事務運行的過程中發生了某種故障，事務不能繼續執行，系統將事務中對資料庫的所有已完成的操作全部撤銷，回滾到事務開始時的狀態。 29.什麼叫資料庫系統的可恢復性？：資料庫管理系統具有把資料庫從錯誤狀態恢復到某一已知的正確狀態的功能，這就是資料庫系統的可恢復性。資料庫故障的種類：事務內部的故障，系統故障（軟故障），介質故障（硬故障），計算機病毒。30.不進行並發控制可能產生的問題？：多個事務對資料庫並發操作可能造成事務ACID特點遭到在破壞。如何解決（三個）：1，丟失修改 2，不可重復讀 3，讀「臟」數據。31.三級封鎖協議？能解決什麼問題？：一級封鎖協議：事務T在修改數據R之前必須先對其加X鎖，直到事務結束才釋放。事務結束包括正常結束（COMMIT）和非正常結束（ROLLBACK）。一級封鎖協議中，如果是讀數據不修改，是不需要加鎖的，可防止丟失修改。二級封鎖協議：在一級封鎖協議基礎上，加上事務T在讀數據R之前必須先對其加上S鎖，讀完後即可釋放S鎖。在二級封鎖協議中，由於讀完數據後即可釋放S鎖，所以它不能保證可重復讀。三級封鎖協議：一級封鎖協議加上事務T在讀取數據R之前必須先對其加S鎖，直到事務結束才釋放。三級封鎖協議除了防止了丟失修改和不讀「臟」數據外，還進一步防止了不可重復讀。上述三級協議的主要區別在於：什麼操作需要申請封鎖，以及何時釋放鎖。一般採取哪三種措施？插入呢？刪除呢？：1，拒絕執行（不允許該操作執行），2，級連操作（當刪除或修改被參照表的一個元組造成了與參照表的不一致，則刪除或修改參照表中的所有造成不一致的元組），3，設置為空值（當刪除或修改被參照表的一個元組時造成了不一致，則將參照表中的所有不造成不一致的元組的對應屬性設置為空值）。38.視圖對資料庫安全性的作用？：1，視圖能夠簡化用戶的操作，2，視力使用戶能以多種角度看待同一數據，3，視圖對重構資料庫提供了一定程度的邏輯獨立性，4，視圖能夠對機密數據提供安全保護，5，適當的利用視圖可以更清晰的表達查詢。資料庫：儲存在計算機內，永久存儲、有組織、有共享的大量數據的集合。數據管理技術的發展階段：1.人工管理階段：數據不保存，應用程序管理數據，數據不共享，數據不具有獨立性。2.文件系統階段：數據可以長期保存，由文件系統管理數據；數據共享性太差，冗餘度大，數據獨立性差。3.資料庫系統階段：出現資料庫管理系統。資料庫系統的特點：數據結構化（本質區別）；數據共享性高、冗餘度低、易擴充；數據獨立性高；數據有DBMS統一管理和控制。資料庫管理系統：1.定義：DBMS，是位於用戶與操作系統之間的一層數據管理軟體。2.功能：數據定義功能；數據組織、存儲和管理；數據操縱功能；資料庫的事務管理和運行管理；資料庫的建立和維護功能；通信功能、數據轉換功能、互訪和互操作功能。資料庫系統：1.概念：DBS，是指在計算機系統中引入資料庫後的系統。2.組成：一般由資料庫、資料庫管理系統、應用系統、資料庫管理員構成。3.分類：集中式，C/S式，並行式，分布式。數據模型：1.定義：現實世界數據特徵的抽象。2.組成，三要素：數據結構、數據操作、數據的完整性約束。兩類數據模型為1）概念模型2）邏輯模型和物理模型。數據結構：描述資料庫的組成對象以及對象之間的聯系，主要描述與對象的類型、內容、性質有關的對象和與數據之間聯系有關的對象。常用的數據模型：1.層次模型，用樹形結構表示各類實體以及實體間的聯系。2.網狀模型，允許一個以上的結點無雙親，允許一個結點可以有多於一個的雙親。3.關系模型，包含單一數據結構

④ 分布式存儲中，怎樣使用paxos演算法保證數據的一致性

在分布式系統中，我們經常遇到多數據副本保持一致的問題，在我們所能找到的資料中該問題講的很籠統，模模糊糊的，把多個問題或分類糅合在一起，難以理解。在思考和翻閱資料後，通俗地把一致性的問題可分解為2個問題：
1、任何一次修改保證數據一致性。
2、多次數據修改的一致性。
在弱一致性的演算法，不要求每次修改的內容在修改後多副本的內容是一致的，對問題1的解決比較寬松，更多解決問題2，該類演算法追求每次修改的高度並發性，減少多副本之間修改的關聯性，以獲得更好的並發性能。例如最終一致性，無所謂每次用戶修改後的多副本的一致性及格過，只要求在單調的時間方向上，數據最終保持一致，如此獲得了修改極大的並發性能。
在強一致性的演算法中，強調單次修改後結果的一致，需要保證了對問題1和問題2要求的實現，犧牲了並發性能。本文是討論對解決問題1實現演算法，這些演算法往往在強一致性要求的應用中使用。
解決問題1的方法，通常有兩階段提交演算法、採用分布式鎖服務和採用樂觀鎖原理實現的同步方式,下面分別介紹這幾種演算法的實現原理。

兩階段提交演算法

在兩階段提交協議中，系統一般包含兩類機器（或節點）：一類為協調者（coordinator），通常一個系統中只有一個；另一類為事務參與者（participants，cohorts或workers），一般包含多個，在數據存儲系統中可以理解為數據副本的個數。兩階段提交協議由兩個階段組成，在正常的執行下，這兩個階段的執行過程如下所述：
階段1：請求階段（commit-request phase，或稱表決階段，voting phase）。
在請求階段，協調者將通知事務參與者准備提交或取消事務，然後進入表決過程。在表決過程中，參與者將告知協調者自己的決策：同意（事務參與者本地作業執行成功）或取消（本地作業執行故障）。
階段2：提交階段（commit phase）。
在該階段，協調者將基於第一個階段的投票結果進行決策：提交或取消。當且僅當所有的參與者同意提交事務協調者才通知所有的參與者提交事務，否則協調者將通知所有的參與者取消事務。參與者在接收到協調者發來的消息後將執行響應的操作。
舉個例子：A組織B、C和D三個人去爬長城：如果所有人都同意去爬長城，那麼活動將舉行；如果有一人不同意去爬長城，那麼活動將取消。用2PC演算法解決該問題的過程如下：
首先A將成為該活動的協調者，B、C和D將成為該活動的參與者。
階段1：A發郵件給B、C和D，提出下周三去爬山，問是否同意。那麼此時A需要等待B、C和D的郵件。B、C和D分別查看自己的日程安排表。B、C發現自己在當日沒有活動安排，則發郵件告訴A它們同意下周三去爬長城。由於某種原因，D白天沒有查看郵件。那麼此時A、B和C均需要等待。到晚上的時候，D發現了A的郵件，然後查看日程安排，發現周三當天已經有別的安排，那麼D回復A說活動取消吧。
階段2：此時A收到了所有活動參與者的郵件，並且A發現D下周三不能去爬山。那麼A將發郵件通知B、C和D，下周三爬長城活動取消。此時B、C回復A「太可惜了」，D回復A「不好意思」。至此該事務終止。
兩階段提交演算法在分布式系統結合，可實現單用戶對文件（對象）多個副本的修改，多副本數據的同步。其結合的原理如下：
1、客戶端（協調者）向所有的數據副本的存儲主機（參與者）發送：修改具體的文件名、偏移量、數據和長度信息，請求修改數據，該消息是1階段的請求消息。
2、存儲主機接收到請求後，備份修改前的數據以備回滾，修改文件數據後，向客戶端回應修改成功的消息。 如果存儲主機由於某些原因（磁碟損壞、空間不足等）不能修改數據，回應修改失敗的消息。
3、客戶端接收發送出去的每一個消息回應，如果存儲主機全部回應都修改成功，向每存儲主機發送確認修改的提交消息；如果存在存儲主機回應修改失敗，或者超時未回應，客戶端向所有存儲主機發送取消修改的提交消息。該消息是2階段的提交消息。
4、存儲主機接收到客戶端的提交消息，如果是確認修改，則直接回應該提交OK消息；如果是取消修改，則將修改數據還原為修改前，然後回應取消修改OK的消息。
5、 客戶端接收全部存儲主機的回應，整個操作成功。
在該過程中可能存在通信失敗，例如網路中斷、主機宕機等諸多的原因，對於未在演算法中定義的其它異常，都認為是提交失敗，都需要回滾，這是該演算法基於確定的通信回復實現的，在參與者的確定回復（無論是回復失敗還是回復成功）之上執行邏輯處理，符合確定性的條件當然能夠獲得確定性的結果哲學原理。

分布式鎖服務

分布式鎖是對數據被外界修改持保守態度，在整個數據處理過程中將數據處於鎖定狀態，在用戶修改數據的同時，其它用戶不允許修改。
採用分布式鎖服務實現數據一致性，是在操作目標之前先獲取操作許可，然後再執行操作，如果其他用戶同時嘗試操作該目標將被阻止，直到前一個用戶釋放許可後，其他用戶才能夠操作目標。分析這個過程，如果只有一個用戶操作目標，沒有多個用戶並發沖突，也申請了操作許可，造成了由於申請操作許可所帶來的資源使用消耗，浪費網路通信和增加了延時。
採用分布式鎖實現多副本內容修改的一致性問題， 選擇控制內容顆粒度實現申請鎖服務。例如我們要保證一個文件的多個副本修改一致， 可以對整個文件修改設置一把鎖，修改時申請鎖，修改這個文件的多個副本，確保多個副本修改的一致，修改完成後釋放鎖；也可以對文件分段，或者是文件中的單個位元組設置鎖， 實現更細顆粒度的鎖操作，減少沖突。
常用的鎖實現演算法有Lamport bakery algorithm （俗稱麵包店演算法）， 還有Paxos演算法。下面對其原理做簡單概述。

Lamport麵包店演算法

是解決多個線程並發訪問一個共享的單用戶資源的互斥問題的演算法。 由Leslie Lamport（英語：Leslie Lamport）發明。
Lamport把這個並發控制演算法可以非常直觀地類比為顧客去麵包店采購。麵包店只能接待一位顧客的采購。已知有n位顧客要進入麵包店采購，安排他們按照次序在前台登記一個簽到號碼。該簽到號碼逐次加1。根據簽到號碼的由小到大的順序依次入店購貨。完成購買的顧客在前台把其簽到號碼歸0. 如果完成購買的顧客要再次進店購買，就必須重新排隊。
這個類比中的顧客就相當於線程，而入店購貨就是進入臨界區獨占訪問該共享資源。由於計算機實現的特點，存在兩個線程獲得相同的簽到號碼的情況，這是因為兩個線程幾乎同時申請排隊的簽到號碼，讀取已經發出去的簽到號碼情況，這兩個線程讀到的數據是完全一樣的，然後各自在讀到的數據上找到最大值，再加1作為自己的排隊簽到號碼。為此，該演算法規定如果兩個線程的排隊簽到號碼相等，則線程id號較小的具有優先權。
把該演算法原理與分布式系統相結合，即可實現分步鎖。

Paxos演算法

該演算法比較熱門，參見WIKI，http://zh.wikipedia.org/wiki/Paxos%E7%AE%97%E6%B3%95
Paxos演算法解決的問題是一個分布式系統如何就某個值(決議)達成一致。一個典型的場景是，在一個分布式資料庫系統中，如果各節點的初始狀態一致，每個節點都執行相同的操作序列，那麼他們最後能得到一個一致的狀態。為保證每個節點執行相同的命令序列，需要在每一條指令上執行一個「一致性演算法」以保證每個節點看到的指令一致。一個通用的一致性演算法可以應用在許多場景中，是分布式計算中的重要問題。節點通信存在兩種模型：共享內存(Shared memory)和消息傳遞(Messages passing)。Paxos演算法就是一種基於消息傳遞模型的一致性演算法。BigTable使用一個分布式數據鎖服務Chubby，而Chubby使用Paxos演算法來保證備份的一致性。

採用樂觀鎖原理實現的同步

我們舉個例子說明該演算法的實現原理。如一個金融系統，當某個操作員讀取用戶的數據，並在讀出的用戶數據的基礎上進行修改時（如更改用戶帳戶余額），如果採用前面的分布式鎖服務機制，也就意味著整個操作過程中（從操作員讀出數據、開始修改直至提交修改結果的全過程，甚至還包括操作員中途去煮咖啡的時間），資料庫記錄始終處於加鎖狀態，可以想見，如果面對幾百上千個並發，這樣的情況將導致怎樣的後果。
樂觀鎖機制在一定程度上解決了這個問題。樂觀鎖，大多是基於數據版本（ Version）記錄機制實現。何謂數據版本？即為數據增加一個版本標識，在基於資料庫表的版本解決方案中，一般是通過為資料庫表增加一個 「version」 欄位來實現。讀取出數據時，將此版本號一同讀出，之後更新時，對此版本號加一。此時，將提交數據的版本數據與資料庫表對應記錄的當前版本信息進行比對，如果提交的數據版本號大於資料庫表當前版本號，則予以更新，否則認為是過期數據。
對於上面修改用戶帳戶信息的例子而言，假設資料庫中帳戶信息表中有一個 version 欄位，當前值為 1 ；而當前帳戶余額欄位（ balance ）為 $100 。
操作員 A 此時將其讀出（version=1 ），並從其帳戶余額中扣除 $50（$100-$50 ）。
在操作員 A 操作的過程中，操作員B也讀入此用戶信息（ version=1 ），並從其帳戶余額中扣除 $20 （ $100-$20 ）。
操作員 A 完成了修改工作，將數據版本號加一（ version=2 ），連同帳戶扣除後余額（ balance=$50 ），提交至資料庫更新，此時由於提交數據版本大於資料庫記錄當前版本，數據被更新，資料庫記錄 version 更新為 2 。
操作員 B 完成了操作，也將版本號加一（ version=2 ）試圖向資料庫提交數據（ balance=$80 ），但此時比對資料庫記錄版本時發現，操作員 B 提交的數據版本號為 2 ，資料庫記錄當前版本也為 2 ，不滿足 「 提交版本必須大於記錄當前版本才能執行更新 「 的樂觀鎖策略，因此，操作員 B 的提交被駁回。這樣，就避免了操作員 B 用基於 version=1 的舊數據修改的結果覆蓋操作員A 的操作結果的可能。
樂觀鎖機制與分布式系統相結合上， 我整理了偽代碼如下：
obj 操作的目標
vlaue 修改的值
atom_update_ver 每個目標上的版本，每次修改該值遞增
set( obj, value)
{
//從每個節點上取出修改前的對象版本
get original_ver = obj.atom_update_ver from each node;
//將值賦到每個節點的obj目標
set obj = value from each node;
//條件修改每個節點的obj版本，目標版本加一
//比較和修改操作是原子操作
result = (set obj.atom_update_ver = original_ver + 1
where original_ver + 1 > obj.atom_update_ver
for each node);
if(result == ok)
return set_ok;
else
return set(obj, value);//不成功遞歸修改

該演算法未考慮節點下線、失效等問題，在後續我將分析採用樂觀鎖原理實現一致性演算法，解決問題2、節點失效、通信失敗等問題。

⑤ 分布式系統常用的一致性演算法有哪些

有一些系統設計基礎的話，給你推薦幾本書吧： 《面向模式的軟體架構 卷4：分布式計算的模式語言》出版社：人民郵電出版社 主要講分布式計算系統軟體的設計和實現。 偏軟體方向，相對較專業。 《分布式計算（第二版）》出版社：電子工業出版社 主要介紹分布式計算的數學基礎和理論，揭示設計分布式系統的底層問題（通信、協調、同步及不確定）和基本的演算法概念及下界技術。 容易理解，適合自學。 《分布式系統原理與范型》出版社：清華大學出版社 全書的第一部分討論了分布式系統的原理、概念和技術，其中包括通信、進程、命名、同步、一致性和復制、容錯以及安全。第二部分給出了一些實際的分布式系統：基於對象的分布式系統、分布式文件系統、基於文檔的分布式系統以及基於協作的分布式系統，介紹了一些實際系統的設計思想和實現技術。 容易理解，適合自學。

⑥ 有哪些分布式資料庫，實現最終一致性的

可以關注下國產分布式資料庫 TiDB，由於實現原理的原因，tidb 天生數據強一致性。TiDB 社區（AskTUG）

• 分布式事務

  TiDB 100% 支持標準的 ACID 事務。

• 真正金融級高可用

  相比於傳統主從 (M-S) 復制方案，基於 Raft 的多數派選舉協議可以提供金融級的 100% 數據強一致性保證，且在不丟失大多數副本的前提下，可以實現故障的自動恢復 (auto-failover)，無需人工介入。

⑦ 資料庫系統中 數據的一致性指的是什麼

同步更新。

簡單說來就是一條column的數據在多個表中保持同步更新， 一般用foreign key實現mapping

比如兩張表table1,table2

其中table1的uid column是primary key，table2的uid column是foreign key,

則當修改table1的uid column的一row時，table2的對應row也會自動更新。

(7)分布式資料庫一致性擴展閱讀：

常用的一致性模型有：

1、嚴格一致性（linearizability, strict/atomic Consistency）：讀出的數據始終為最近寫入的數據。這種一致性只有全局時鍾存在時才有可能，在分布式網路環境不可能實現。

2、順序一致性（sequential consistency）：所有使用者以同樣的順序看到對同一數據的操作，但是該順序不一定是實時的，等。

⑧ 什麼是NoSQL資料庫

2. 什麼是NoSQL？
2.1 NoSQL 概述
NoSQL(NoSQL = Not Only SQL )，意即「不僅僅是SQL」，
泛指非關系型的資料庫。隨著互聯網web2.0網站的興起，傳統的關系資料庫在應付web2.0網站，特別是超大規模和高並發的SNS類型的web2.0純動態網站已經顯得力不從心，暴露了很多難以克服的問題，而非關系型的資料庫則由於其本身的特點得到了非常迅速的發展。NoSQL資料庫的產生就是為了解決大規模數據集合多重數據種類帶來的挑戰，尤其是大數據應用難題，包括超大規模數據的存儲。
（例如谷歌或Facebook每天為他們的用戶收集萬億比特的數據）。這些類型的數據存儲不需要固定的模式，無需多餘操作就可以橫向擴展。
2.2 NoSQL代表
MongDB、 Redis、Memcache
3. 關系型資料庫與NoSQL的區別？
3.1 RDBMS
高度組織化結構化數據
結構化查詢語言（SQL）
數據和關系都存儲在單獨的表中。
數據操縱語言，數據定義語言
嚴格的一致性
基礎事務
ACID
關系型資料庫遵循ACID規則
事務在英文中是transaction，和現實世界中的交易很類似，它有如下四個特性：
A (Atomicity) 原子性
原子性很容易理解，也就是說事務里的所有操作要麼全部做完，要麼都不做，事務成功的條件是事務里的所有操作都成功，只要有一個操作失敗，整個事務就失敗，需要回滾。比如銀行轉賬，從A賬戶轉100元至B賬戶，分為兩個步驟：1）從A賬戶取100元；2）存入100元至B賬戶。這兩步要麼一起完成，要麼一起不完成，如果只完成第一步，第二步失敗，錢會莫名其妙少了100元。
C (Consistency) 一致性
一致性也比較容易理解，也就是說資料庫要一直處於一致的狀態，事務的運行不會改變資料庫原本的一致性約束。
I (Isolation) 獨立性
所謂的獨立性是指並發的事務之間不會互相影響，如果一個事務要訪問的數據正在被另外一個事務修改，只要另外一個事務未提交，它所訪問的數據就不受未提交事務的影響。比如現有有個交易是從A賬戶轉100元至B賬戶，在這個交易還未完成的情況下，如果此時B查詢自己的賬戶，是看不到新增加的100元的
D (Durability) 持久性
持久性是指一旦事務提交後，它所做的修改將會永久的保存在資料庫上，即使出現宕機也不會丟失。
3.2 NoSQL
代表著不僅僅是SQL
沒有聲明性查詢語言
沒有預定義的模式
鍵 - 值對存儲，列存儲，文檔存儲，圖形資料庫
最終一致性，而非ACID屬性
非結構化和不可預知的數據
CAP定理
高性能，高可用性和可伸縮性
分布式資料庫中的CAP原理(了解)
CAP定理：
Consistency(一致性), 數據一致更新，所有數據變動都是同步的
Availability(可用性), 好的響應性能
Partition tolerance(分區容錯性) 可靠性
P: 系統中任意信息的丟失或失敗不會影響系統的繼續運作。
定理：任何分布式系統只可同時滿足二點，沒法三者兼顧。
CAP理論的核心是：一個分布式系統不可能同時很好的滿足一致性，可用性和分區容錯性這三個需求，
因此，根據 CAP 原理將 NoSQL 資料庫分成了滿足 CA 原則、滿足 CP 原則和滿足 AP 原則三 大類：
CA - 單點集群，滿足一致性，可用性的系統，通常在可擴展性上不太強大。
CP - 滿足一致性，分區容忍性的系統，通常性能不是特別高。
AP - 滿足可用性，分區容忍性的系統，通常可能對一致性要求低一些。
CAP理論就是說在分布式存儲系統中，最多隻能實現上面的兩點。
而由於當前的網路硬體肯定會出現延遲丟包等問題，所以分區容忍性是我們必須需要實現的。
所以我們只能在一致性和可用性之間進行權衡，沒有NoSQL系統能同時保證這三點。
說明：C：強一致性 A：高可用性 P：分布式容忍性
舉例：
CA：傳統Oracle資料庫
AP：大多數網站架構的選擇
CP：Redis、Mongodb
注意：分布式架構的時候必須做出取捨。
一致性和可用性之間取一個平衡。多餘大多數web應用，其實並不需要強一致性。
因此犧牲C換取P，這是目前分布式資料庫產品的方向。
4. 當下NoSQL的經典應用
當下的應用是 SQL 與 NoSQL 一起使用的。
代表項目：阿里巴巴商品信息的存放。
去 IOE 化。
ps：I 是指 IBM 的小型機，很貴的，好像好幾萬一台；O 是指 Oracle 資料庫，也很貴的，好幾萬呢；M 是指 EMC 的存儲設備，也很貴的。
難點：
數據類型多樣性。
數據源多樣性和變化重構。
數據源改造而服務平台不需要大面積重構。

⑨ 什麼是分布式環境中數據的強一致性

一致性又可以分為強一致性與弱一致性。 強一致性可以理解為在任意時刻，所有節點中的數據是一樣的。同一時間點，你在節點A中獲取到key1的值與在節點B中獲取到key1的值應該都是一樣的。 弱一致性包含很多種不同的實現，目前分布式系統中廣泛實現

⑩ 如何解決分布式系統數據事務一致性問題

用戶在京東上下了一個訂單，發現自己在京東的賬戶裡面有餘額，然後使用余額支付，支付成功之後，訂單狀態修改為支付成功，然後通知倉庫發貨。假設訂單系統，支付系統，倉庫系統是三個獨立的應用，是獨立部署的，系統之間通過遠程服務調用。 訂單的有三個狀態：I:初始 P:已支付 W:已出庫，訂單金額100, 會員帳戶余額200 如果整個流程比較順利，正常情況下，訂單的狀態會變為I->P->W，會員帳戶余額100，訂單出庫。 但是如果流程不順利了？考慮以下幾種情況 1：訂單系統調用支付系統支付訂單，支付成功，但是返回給訂單系統數據超時，訂單還是I（初始狀態），但是此時會員帳戶余額100,會員肯定會馬上找京東罵京東，為啥不給老子發貨，我都付錢了 2：訂單系統調用支付系統成功，狀態也已經更新成功，但是通知倉庫發貨失敗，這個時候訂單是P（已支付）狀態，此時會員帳戶余額是100,但是倉庫不會發貨。會員也要罵京東。 3：訂單系統調用支付系統成功，狀態也已經更新成功，然後通知倉庫發貨，倉庫告訴訂單系統，沒有貨了。這個時候數據狀態和第二種情況一樣。 對於問題一，我們來分析一下解決方案，能想到的解決方案如下 1 假設調用支付系統支付訂單的時候先不扣錢，訂單狀態更新完成之後，在通知支付系統你扣錢 如果採用這種設計方案，那麼在同一時刻，這個用戶，又支付了另外一筆訂單，訂單價格200，順利完成了整個訂單支付流程，由於當前訂單的狀態已經變成了支付成功，但是實際用戶已經沒有錢支付了，這筆訂單的狀態就不一致了。即使用戶在同一個時刻沒有進行另外的訂單支付行為，通知支付系統扣錢這個動作也有可能完不成，因為也有可能失敗，反而增加了系統的復雜性。 2 訂單系統自動發起重試，多重試幾次，例如三次，直到扣款成功為止。 這個看起來也是不錯的考慮，但是和解決方案一樣，解決不了問題，還會帶來新的問題，假設訂單系統第一次調用支付系統成功，但是沒有辦法收到應答，訂單系統又發起調用，完了，重復支付，一次訂單支付了200。 假設支付系統正在發布，你重試多少次都一樣，都會失敗。這個時候用戶在等待，你怎麼處理？ 3 在第二種方案的基礎上，我們先解決訂單的重復支付行為，我們需要在支付系統上對訂單號進行控制，一筆訂單如果已經支付成功，不能在進行支付。返回重復支付標識。那麼訂單系統根據返回的標識，更新訂單狀態。 接下來解決重試問題，我們假設應用上重試三次，如果三次都失敗，先返回給用戶提示支付結果未知。假設這個時候用戶重新發起支付，訂單系統調用支付系統，發現訂單已經支付，那麼繼續下面的流程。如果會員沒有發起支付，系統定時（一分鍾一次）去核對訂單狀態，如果發現已經被支付，則繼續後續的流程。 這種方案，用戶體驗非常差，告訴用戶支付結果未知，用戶一定會罵你，你丫咋回事情，我明明支付了，你告訴我未知。假設告訴用戶支付失敗，萬一實際是成功的咋辦。你告訴用戶支付成功，萬一支付失敗咋辦。 4 第三種方案能夠解決訂單和支付數據的一致性問題，但是用戶體驗非常差。當然這種情況比較可能是少數，可以犧牲這一部分的用戶體驗，我們還有沒有更好的解決方案，既能照顧用戶體驗，又能夠保證資金的安全性。 我們再回來看看第一種方案，我們先不扣錢，但是有木有辦法讓這一部分錢不讓用戶使用，對了，我們先把這一部分錢凍結起來，訂單系統先調用支付系統成功的時候，支付系統先不扣錢，而是先把錢凍結起來，不讓用戶給其他訂單支付，然後等訂單系統把訂單狀態更新為支付成功的時候，再通知支付系統，你扣錢吧，這個時候支付系統扣錢，完成後續的操作。 看起來這個方案不錯，我們仔細在分析一下流程，這個方案還存在什麼問題，假設訂單系統在調用支付系統凍結的時候，支付系統凍結成功，但是訂單系統超時，這個時候返回給用戶，告知用戶支付失敗，如果用戶再次支付這筆訂單，那麼由於支付系統進行控制，告訴訂單系統凍結成功，訂單系統更新狀態，然後通知支付系統，扣錢吧。如果這個時候通知失敗，木有問題，反正錢都已經是凍結的了，用戶不能用，我只要定時掃描訂單和支付狀態，進行扣錢而已。 那麼如果變態的用戶重新拍下來一筆訂單,100塊錢，對新的訂單進行支付，這個時候由於先前那一筆訂單的錢被凍結了，這個時候用戶余額剩餘100，凍結100，發現可用的余額足夠，那就直接在對用戶扣錢。這個時候余額剩餘0，凍結100。先前那一筆怎麼辦，一個辦法就是定時掃描，發現訂單狀態是初始的話，就對用戶的支付余額進行解凍處理。這個時候用戶的余額變成100，訂單數據和支付數據又一致了。假設原先用戶余額只有100，被凍結了，用戶重新下單，支付的時候就失敗了啊，的確會發生這一種情況，所以要盡可能的保證在第一次訂單結果不明確的情況，盡早解凍用戶余額，比如10秒之內。但是不管如何快速，總有數據不一致的時刻，這個是沒有辦法避免的。 第二種情況和第三種情況如何處理，下次在分析吧。 由於互聯網目前越來越強調分布式架構，如果是交易類系統，面臨的將會是分布式事務上的挑戰。當然目前有很多開源的分布式事務產品，例如java JPA，但是這種解決方案的成本是非常高的，而且實現起來非常復雜，效率也比較低下。對於極端的情況：例如發布，故障的時候都是沒有辦法保證強一致性的。