1. 資料庫恢復的資料庫恢復的三種方式
資料庫可能因為硬體或軟體（或兩者同時）的故障變得不可用，不同的故障情況需要不同的恢復操作。我們必須決定最適合業務環境的恢復方法。在資料庫中恢復有3種類型或方法，即應急（crash）恢復、版本（version）恢復和前滾（rool forward）恢復。 應急恢復用於防止資料庫處於不一致或不可用狀態。資料庫執行的事務（也稱工作單元）可能被意外中斷，若在作為工作單位一部分的所有更改完成和提交之前發生故障，則該資料庫就會處於不一致和不可用的狀態。這時，需要將該資料庫轉化為一致和可用的狀態。
為此，需要回滾未完成的事務，並完成當發生崩潰時仍在內存中的已提交事務。如在COMMIT語句之前發生了電源故障，則在下一次重新啟動並再次訪問該資料庫時，需要回滾到執行COMMMIT語句前的狀態。回滾語句的順序與最初執行時的順序相反。 這種恢復技術是版本恢復的一個擴展，使用完整的資料庫備份和日誌相結合，可以使一個資料庫或者被選擇的表空間恢復到某個特定時間點。如果從備份時刻起到發生故障時的所有日誌文件都可以獲得的話，則可以恢復到日誌上涵蓋到的任意時間點。前滾恢復需要在配置中被明確激活才能生效。
2. 有哪些分布式資料庫,實現最終一致性的(分布式資料庫與集中式資料庫的區別)
一個分布式資料庫在用戶面前為單個邏輯資料庫，但實際上是由存儲在多台計算機上的一組資料庫組成
在幾台計算機上的資料庫通過網路可同時修改和存取，每一資料庫受它的局部的DBMS控制
分布式資料庫中每一個資料庫伺服器合作地維護全局資料庫的一致性
在系統中的每一台計算機稱為結點
如果一結點具有管理資料庫軟體，該結點稱為資料庫伺服器
如果一個結點為請求伺服器的信息的一應用，該結點稱為客戶
在ORACLE客戶，執行資料庫應用，可存取數據信息和與用戶交互
在伺服器，執行ORACLE軟體，處理對ORACLE資料庫並發、共享數據存取
ORACLE允許上述兩部分在同一台計算機上，但當客戶部分和伺服器部分是由網連接的不同計算機上時，更有效
分布處理是由多台處理機分擔單個任務的處理
在ORACLE資料庫系統中分布處理的例子如：客戶和伺服器是位於網路連接的不同計算機上
單台計算機上有多個處理器，不同處理器分別執行客戶應用
sql*NET是ORACLE網路介面，允許運行在網路工作站的ORACLE工具和伺服器上，可存取、修改、共享和存儲在其它伺服器上的數據
SAQL*NET可被認為是網路通信的程序介面
SQL*NET利用通信協議和應用程序介面（API）為OARCLE提供一個分布式資料庫和分布處理
SQL*NET驅動器為在資料庫伺服器上運行的ORACLE進程與ORACLE工具的用戶進程之間提供一個介面
參與分布式資料庫的每一伺服器是分別地獨立地管理資料庫，好像每一資料庫不是網路化的資料庫
每一個資料庫獨立地被管理，稱為場地自治性
場地自治性有下列好處：◆系統的結點可反映公司的邏輯組織
◆由局部資料庫管理員控制局部數據，這樣每一個資料庫管理員責任域要小一些，可更好管理
◆只要一個資料庫和網路是可用，那麼全局資料庫可部分可用
不會因一個資料庫的故障而停止全部操作或引起性能瓶頸
◆故障恢復通常在單個結點上進行
◆每個局部資料庫存在一個數據字典
◆結點可獨立地升級軟體
可從分布式資料庫的所有結點存取模式對象，因此正像非分布的局部的DBMS，必須提供一種機制，可在局部資料庫中引用一個對象
分布式DBMS必須提供一種命名模式，以致分布式資料庫中一個對象可在應用中唯一標識和引用
一般彩在層次結構的每一層實施唯一性
分布式DVMS簡單地擴充層次命名模型，實施在網路上唯一資料庫命名
因此一個對象的全局對象名保證在分布式資料庫內是唯一
ORACLE允許在SQL語句中使用佤對象名引用分布式資料庫中的模式對象（表、視圖和過程）
在ORACLE中，一個模式對象的全局名由三部分組成：包含對象的模式名、對象名、資料庫名、其形式如：SCOTT
EMP@SALES
DIVISION3
ACME
COM其中SCOTT為模式名,EMP為表名,@符號之後為資料庫名
一個遠程查詢為一查詢,是從一個或多個遠程表中選擇信息,這些表駐留在同一個遠程結點
一個分布式查詢可從兩個或多個結點檢索數據
一個分布式更新可修改兩個或兩個以上結點的數據
一個遠程事務為搏老一個事務,包含一人或多個遠程語句,它所引用的全部是在同一個遠程結點上
一個分布式事務中一個事務,包含一個或多個語句修改分布式資料庫的兩個或多個不同結點的數據
在分布式資料庫中,事務控制必須在網路上直轄市,保證數據一致性
兩階段提交機制保證參與分布式事務的全部資料庫伺服器是全部提交或全部回滾事務中的語句
ORACLE分布式資料庫系統結構可由ORACLE資料庫管理員為終端用戶和應用提供位置透明性,利用視圖、同義詞、過程可提供ORACLE分布式資料庫系統中的位置透明性
ORACLE允許在SELECT(查詢)、INSERT、UPDATE、DELETE、SELECTFORUPDATE和LOCKTABLE語句中引用遠程數據
對於查詢，包含有連接、聚合、子查詢和SELECTFORUPDATE，可引用本地的、遠程的表和視圖
對於UPDATE、INSERT、DELETE和LOCKTABLE語句可引用本地的和遠程的表
注意在引用LONG和LONGRAW列、序列、修改表和封鎖表時，必須位於同一個結衡雹點
ORACLE不允許作遠程DDL語句
在單場地或分布式資料庫中基攔升，所有事務都是用COMMIT或ROLLBACK語句中止
ORACLE提供兩種機制實現分布式資料庫中表重復的透明性：錶快照提供非同步的表重復；觸發器實現同步的表的重復
在兩種情況下，都實現了對表重復的透明性
3. 資料庫原理中，介質故障的恢復方法有哪些（最少五種）
發生介質故障後，磁碟上的物理數據和日誌文件被破壞，這是最嚴重的一種故障，恢復方法是重裝資料庫，然後重做已完成的事務。具體地說就是：
1. 裝入最新的資料庫後備副本（離故障發生時刻最近的轉儲副本），使資料庫恢復到最近一次轉儲時的一致性狀態。
對於動態轉儲的資料庫副本，還須同時裝入轉儲開始時刻的日誌文件副本，利用恢復系統故障的方法（即REDO+UNDO），才能將資料庫恢復到一致性狀態。
2. 裝入相應的日誌文件副本（轉儲結束時刻的日誌文件副本），重做已完成的事務。即：
首先掃描日誌文件，找出故障發生時已提交的事務的標識，將其記入重做隊列。
然後正向掃描日誌文件，對重做隊列中的所有事務進行重做處理。即將日誌記錄中「更新後的值」寫入資料庫。
這樣就可以將資料庫恢復至故障前某一時刻的一致狀態了。
資料庫鏡像
4. 資料庫恢復的基本原則
要使資料庫具有可恢復性，基本原理就是 「冗餘」，即數據的重復存儲。
資料庫恢復實現方法：
(1) 數據轉儲(mp)(又稱「倒庫」) 轉儲是指DBA將整個資料庫復制到磁帶或另 一個磁碟上保存起來的過程。這些備用的數 據文本稱為後備副本或後援副本。一時發生 故障，可以將後備副本重新裝入。
(2) 建立「日誌」文件（logging)。 日誌文件是用來記錄事務對資料庫的更新操 作的文件。對於資料庫的每次插入、刪除或 修改，記下改變前後 的值，寫到「「日誌」 文件，以便有案可查。
5. 如何進行事務故障恢復，系統故障恢復，介質故障恢
1)事務故障恢復。由系統自動完成，對用戶是透明的。
DBMS執行恢復操作的步驟如下：
①反向掃描日誌文件(即從最後向前掃描日誌文件)，查找該事務的更新操作。
②對該事務的更新操作執行逆操作，即將日誌記錄中「更新前的值」寫入資料庫。
③繼續反向掃描日誌文件，做同樣處理。
④如此處理下去，直至讀到此事務的開始標記，該事務故障的恢復就完成了。
(2)系統故障恢復。系統故障可能會造成資料庫處於不一致性狀態：一是未完成事務對資料庫的更新可能已寫入資料庫；二是已提交事務對資料庫的更新可能還留在緩沖區，沒來得及寫入資料庫。因此，恢復操作就是要撤銷故障發生時未完成的事務，重做已完成的事務。
系統故障的恢復步驟如下：
①正向掃描日誌文件，找出在故障發生前已經提交的事務隊列(REDO隊列)和未完成的事務隊列(UNDO隊列)。
②對撤銷隊列中的各個事務進行UNDO處理。進行UNDO處理的方法是，反向掃描日誌文件，對每個UNDO事務的更新操作執行逆操作，即將日誌記錄中「更新前的值」寫入資料庫。
③對重做隊列中的各個事務進行REDO處理。進行REDO處理的方法是，正向掃描日誌文件，對每個REDO事務重新執行日誌文件登記的操作，即將日誌記錄中「更新後的值」寫入資料庫。
(3)介質故障恢復。介質故障是最嚴重的一種故障。恢復方法是重裝資料庫，然後重做已完成的事務。具體過程如下：
①DBA裝入最新的資料庫後備副本(離故障發生時刻最近的轉儲副本)，使資料庫恢復到轉儲時的一致性狀態。
②DBA裝入轉儲結束時刻的日誌文件副本。
③DBA啟動系統恢復命令，由DBMS完成恢復功能，即重做已完成的事務。
6. 分庫分表 VS newsql資料庫
最近與同行 科技 交流，經常被問到分庫分表與分布式資料庫如何選擇，網上也有很多關於中間件+傳統關系資料庫（分庫分表）與NewSQL分布式資料庫的文章，但有些觀點與判斷是我覺得是偏激的，脫離環境去評價方案好壞其實有失公允。
本文通過對兩種模式關鍵特性實現原理對比，希望可以盡可能客觀、中立的闡明各自真實的優缺點以及適用場景。
首先關於「中間件+關系資料庫分庫分表」算不算NewSQL分布式資料庫問題，國外有篇論文pavlo-newsql-sigmodrec，如果根據該文中的分類，Spanner、TiDB、OB算是第一種新架構型，Sharding-Sphere、Mycat、DRDS等中間件方案算是第二種（文中還有第三種雲資料庫，本文暫不詳細介紹）。
基於中間件（包括SDK和Proxy兩種形式）+傳統關系資料庫（分庫分表）模式是不是分布式架構？我覺得是的，因為存儲確實也分布式了，也能實現橫向擴展。但是不是"偽"分布式資料庫？從架構先進性來看，這么說也有一定道理。"偽"主要體現在中間件層與底層DB重復的SQL解析與執行計劃生成、存儲引擎基於B+Tree等，這在分布式資料庫架構中實際上冗餘低效的。為了避免引起真偽分布式資料庫的口水戰，本文中NewSQL資料庫特指這種新架構NewSQL資料庫。
NewSQL資料庫相比中間件+分庫分表的先進在哪兒？畫一個簡單的架構對比圖：
這些大多也是NewSQL資料庫產品主要宣傳的點，不過這些看起來很美好的功能是否真的如此？接下來針對以上幾點分別闡述下的我的理解。
這是把雙刃劍。
CAP限制
想想更早些出現的NoSQL資料庫為何不支持分布式事務（最新版的mongoDB等也開始支持了），是缺乏理論與實踐支撐嗎？並不是，原因是CAP定理依然是分布式資料庫頭上的頸箍咒，在保證強一致的同時必然會犧牲可用性A或分區容忍性P。為什麼大部分NoSQL不提供分布式事務？
那麼NewSQL資料庫突破CAP定理限制了嗎？並沒有。NewSQL資料庫的鼻主Google Spanner（目前絕大部分分布式資料庫都是按照Spanner架構設計的）提供了一致性和大於5個9的可用性，宣稱是一個「實際上是CA」的，其真正的含義是 系統處於 CA 狀態的概率非常高，由於網路分區導致的服務停用的概率非常小 ，究其真正原因是其打造私有全球網保證了不會出現網路中斷引發的網路分區，另外就是其高效的運維隊伍,這也是cloud spanner的賣點。詳細可見CAP提出者Eric Brewer寫的《Spanner, TrueTime 和CAP理論》。
完備性 ：
兩階段提交協議是否嚴格支持ACID，各種異常場景是不是都可以覆蓋？
2PC在commit階段發送異常，其實跟最大努力一階段提交類似也會有部分可見問題，嚴格講一段時間內並不能保證A原子性和C一致性（待故障恢復後recovery機制可以保證最終的A和C）。完備的分布式事務支持並不是一件簡單的事情，需要可以應對網路以及各種硬體包括網卡、磁碟、CPU、內存、電源等各類異常，通過嚴格的測試。之前跟某友商交流，他們甚至說目前已知的NewSQL在分布式事務支持上都是不完整的，他們都有案例跑不過，圈內人士這么篤定，也說明了 分布式事務的支持完整程度其實是層次不齊的。
但分布式事務又是這些NewSQL資料庫的一個非常重要的底層機制，跨資源的DML、DDL等都依賴其實現，如果這塊的性能、完備性打折扣，上層跨分片SQL執行的正確性會受到很大影響。
性能
傳統關系資料庫也支持分布式事務XA，但為何很少有高並發場景下用呢？ 因為XA的基礎兩階段提交協議存在網路開銷大，阻塞時間長、死鎖等問題，這也導致了其實際上很少大規模用在基於傳統關系資料庫的OLTP系統中。
NewSQL資料庫的分布式事務實現也仍然多基於兩階段提交協議，例如google percolator分布式事務模型，
採用原子鍾+MVCC+ Snapshot Isolation（SI），這種方式通過TSO(Timestamp Oracle)保證了全局一致性，通過MVCC避免了鎖，另外通過primary lock和secondary lock將提交的一部分轉為非同步，相比XA確實提高了分布式事務的性能。
但不管如何優化，相比於1PC，2PC多出來的GID獲取、網路開銷、prepare日誌持久化還是會帶來很大的性能損失，尤其是跨節點的數量比較多時會更加顯著，例如在銀行場景做個批量扣款，一個文件可能上W個賬戶，這樣的場景無論怎麼做還是吞吐都不會很高。
雖然NewSQL分布式資料庫產品都宣傳完備支持分布式事務，但這並不是說應用可以完全不用關心數據拆分，這些資料庫的最佳實踐中仍然會寫到，應用的大部分場景盡可能避免分布式事務。
既然強一致事務付出的性能代價太大，我們可以反思下是否真的需要這種強一致的分布式事務？尤其是在做微服務拆分後，很多系統也不太可能放在一個統一的資料庫中。嘗試將一致性要求弱化，便是柔性事務，放棄ACID(Atomicity,Consistency, Isolation, Durability)，轉投BASE(Basically Available,Soft state,Eventually consistent)，例如Saga、TCC、可靠消息保證最終一致等模型，對於大規模高並發OLTP場景，我個人更建議使用柔性事務而非強一致的分布式事務。關於柔性事務，筆者之前也寫過一個技術組件，最近幾年也涌現出了一些新的模型與框架（例如阿里剛開源的Fescar），限於篇幅不再贅述，有空再單獨寫篇文章。
HA與異地多活
主從模式並不是最優的方式，就算是半同步復制，在極端情況下（半同步轉非同步）也存在丟數問題，目前業界公認更好的方案是基於paxos分布式一致性協議或者其它類paxos如raft方式，Google Spanner、TiDB、cockcoachDB、OB都採用了這種方式，基於Paxos協議的多副本存儲，遵循過半寫原則，支持自動選主，解決了數據的高可靠，縮短了failover時間，提高了可用性，特別是減少了運維的工作量，這種方案技術上已經很成熟，也是NewSQL資料庫底層的標配。
當然這種方式其實也可以用在傳統關系資料庫，阿里、微信團隊等也有將MySQL存儲改造支持paxos多副本的，MySQL也推出了官方版MySQL Group Cluster，預計不遠的未來主從模式可能就成為 歷史 了。
需要注意的是很多NewSQL資料庫廠商宣傳基於paxos或raft協議可以實現【異地多活】，這個實際上是有前提的，那就是異地之間網路延遲不能太高 。以銀行「兩地三中心」為例，異地之間多相隔數千里，延時達到數十毫秒，如果要多活，那便需異地副本也參與資料庫日誌過半確認，這樣高的延時幾乎沒有OLTP系統可以接受的。
資料庫層面做異地多活是個美好的願景，但距離導致的延時目前並沒有好的方案。 之前跟螞蟻團隊交流，螞蟻異地多活的方案是在應用層通過MQ同步雙寫交易信息，異地DC將交易信息保存在分布式緩存中，一旦發生異地切換，資料庫同步中間件會告之數據延遲時間，應用從緩存中讀取交易信息，將這段時間內涉及到的業務對象例如用戶、賬戶進行黑名單管理，等數據同步追上之後再將這些業務對象從黑名單中剔除。由於雙寫的不是所有資料庫操作日誌而只是交易信息，數據延遲隻影響一段時間內數據，這是目前我覺得比較靠譜的異地度多活方案。
另外有些系統進行了單元化改造，這在paxos選主時也要結合考慮進去，這也是目前很多NewSQL資料庫欠缺的功能。
Scale橫向擴展與分片機制
paxos演算法解決了高可用、高可靠問題，並沒有解決Scale橫向擴展的問題，所以分片是必須支持的。NewSQL資料庫都是天生內置分片機制的，而且會根據每個分片的數據負載(磁碟使用率、寫入速度等)自動識別熱點，然後進行分片的分裂、數據遷移、合並，這些過程應用是無感知的，這省去了DBA的很多運維工作量。以TiDB為例，它將數據切成region，如果region到64M時，數據自動進行遷移。
分庫分表模式下需要應用設計之初就要明確各表的拆分鍵、拆分方式（range、取模、一致性哈希或者自定義路由表）、路由規則、拆分庫表數量、擴容方式等。相比NewSQL資料庫，這種模式給應用帶來了很大侵入和復雜度，這對大多數系統來說也是一大挑戰。
這里有個問題是NewSQL資料庫統一的內置分片策略（例如tidb基於range）可能並不是最高效的，因為與領域模型中的劃分要素並不一致，這導致的後果是很多交易會產生分布式事務。 舉個例子，銀行核心業務系統是以客戶為維度，也就是說客戶表、該客戶的賬戶表、流水表在絕大部分場景下是一起寫的，但如果按照各表主鍵range進行分片，這個交易並不能在一個分片上完成，這在高頻OLTP系統中會帶來性能問題。
分布式SQL支持
常見的單分片SQL，這兩者都能很好支持。NewSQL資料庫由於定位與目標是一個通用的資料庫，所以支持的SQL會更完整，包括跨分片的join、聚合等復雜SQL。中間件模式多面向應用需求設計，不過大部分也支持帶拆分鍵SQL、庫表遍歷、單庫join、聚合、排序、分頁等。但對跨庫的join以及聚合支持就不夠了。
NewSQL資料庫一般並不支持存儲過程、視圖、外鍵等功能，而中間件模式底層就是傳統關系資料庫，這些功能如果只是涉及單庫是比較容易支持的。
NewSQL資料庫往往選擇兼容MySQL或者PostgreSQL協議，所以SQL支持僅局限於這兩種，中間件例如驅動模式往往只需做簡單的SQL解析、計算路由、SQL重寫，所以可以支持更多種類的資料庫SQL。
SQL支持的差異主要在於分布式SQL執行計劃生成器，由於NewSQL資料庫具有底層數據的分布、統計信息，因此可以做CBO，生成的執行計劃效率更高，而中間件模式下沒有這些信息，往往只能基於規則RBO（Rule-Based-Opimization），這也是為什麼中間件模式一般並不支持跨庫join，因為實現了效率也往往並不高，還不如交給應用去做。
存儲引擎
傳統關系資料庫的存儲引擎設計都是面向磁碟的，大多都基於B+樹。B+樹通過降低樹的高度減少隨機讀、進而減少磁碟尋道次數，提高讀的性能，但大量的隨機寫會導致樹的分裂，從而帶來隨機寫，導致寫性能下降。NewSQL的底層存儲引擎則多採用LSM，相比B+樹LSM將對磁碟的隨機寫變成順序寫，大大提高了寫的性能。不過LSM的的讀由於需要合並數據性能比B+樹差，一般來說LSM更適合應在寫大於讀的場景。當然這只是單純數據結構角度的對比，在資料庫實際實現時還會通過SSD、緩沖、bloom filter等方式優化讀寫性能，所以讀性能基本不會下降太多。NewSQL數據由於多副本、分布式事務等開銷，相比單機關系資料庫SQL的響應時間並不佔優，但由於集群的彈性擴展，整體QPS提升還是很明顯的，這也是NewSQL資料庫廠商說分布式資料庫更看重的是吞吐，而不是單筆SQL響應時間的原因。
成熟度與生態
分布式資料庫是個新型通用底層軟體，准確的衡量與評價需要一個多維度的測試模型，需包括發展現狀、使用情況、社區生態、監控運維、周邊配套工具、功能滿足度、DBA人才、SQL兼容性、性能測試、高可用測試、在線擴容、分布式事務、隔離級別、在線DDL等等，雖然NewSQL資料庫發展經過了一定時間檢驗，但多集中在互聯網以及傳統企業非核心交易系統中，目前還處於快速迭代、規模使用不斷優化完善的階段。
相比而言，傳統關系資料庫則經過了多年的發展，通過完整的評測，在成熟度、功能、性能、周邊生態、風險把控、相關人才積累等多方面都具有明顯優勢，同時對已建系統的兼容性也更好。
對於互聯網公司，數據量的增長壓力以及追求新技術的基因會更傾向於嘗試NewSQL資料庫，不用再考慮庫表拆分、應用改造、擴容、事務一致性等問題怎麼看都是非常吸引人的方案。
對於傳統企業例如銀行這種風險意識較高的行業來說，NewSQL資料庫則可能在未來一段時間內仍處於 探索 、審慎試點的階段。基於中間件+分庫分表模式架構簡單，技術門檻更低，雖然沒有NewSQL資料庫功能全面，但大部分場景最核心的訴求也就是拆分後SQL的正確路由，而此功能中間件模式應對還是綽綽有餘的，可以說在大多數OLTP場景是夠用的。
限於篇幅，其它特性例如在線DDL、數據遷移、運維工具等特性就不在本文展開對比。
總結
如果看完以上內容，您還不知道選哪種模式，那麼結合以下幾個問題，先思考下NewSQL資料庫解決的點對於自身是不是真正的痛點：
如果以上有2到3個是肯定的，那麼你可以考慮用NewSQL資料庫了，雖然前期可能需要一定的學習成本，但它是資料庫的發展方向，未來收益也會更高，尤其是互聯網行業，隨著數據量的突飛猛進，分庫分表帶來的痛苦會與日俱增。當然選擇NewSQL資料庫你也要做好承擔一定風險的准備。
如果你還未做出抉擇，不妨再想想下面幾個問題：
如果這些問題有多數是肯定的，那還是分庫分表吧。在軟體領域很少有完美的解決方案，NewSQL資料庫也不是數據分布式架構的銀彈。相比而言分庫分表是一個代價更低、風險更小的方案，它最大程度復用傳統關系資料庫生態，通過中間件也可以滿足分庫分表後的絕大多數功能，定製化能力更強。 在當前NewSQL資料庫還未完全成熟的階段，分庫分表可以說是一個上限低但下限高的方案，尤其傳統行業的核心系統，如果你仍然打算把資料庫當做一個黑盒產品來用，踏踏實實用好分庫分表會被認為是個穩妥的選擇。
很多時候軟體選型取決於領域特徵以及架構師風格，限於筆者知識與所屬行業特點所限，以上僅為個人粗淺的一些觀點，歡迎討論。
7. 分布式資料庫系統(DDBS)概述
一 什麼是分布式資料庫
分布式資料庫系統是在集中式資料庫系統的基礎上發展來的 是資料庫技術與網路技術結合的產物
分布式資料庫系統有兩種 一種是物理上分布的 但邏輯上卻是集中的 這種分布式資料庫只適宜用途比較單一的 不大的單位或部門 另一種分布式資料庫系統在物理上和邏輯上都是分布的 也就是所謂聯邦式分布資料庫系統 由於組成聯邦的各個子資料庫系統是相對 自治 的 這種系統可以容納多種不同用途的 差異較大的資料庫 比較適宜於大范圍內資料庫的集成
分布式資料庫系統(DDBS)包含分布式資料庫管理系統(DDBMS)和分布式資料庫(DDB)
在分布式資料庫系統中 一個應用程序可以對資料庫進行透明操作 資料庫中的數據分別在不同的局部資料庫中存儲 由不同的DBMS進行管理 在不同的機器上運行 由不同的操作系統支持 被不同的通信網路連接在一起
一個分布式資料庫在邏輯上是一個統一的整體 即在用戶面前為單個邏輯資料庫 在物理上則是分別存儲在不同的物理節點上 一個應用程序通過網路的連接可以訪問分布在不同地理位置的資料庫 它的分布性表現在資料庫中的數據不是存儲在同一場地 更確切地講 不存儲在同一計算機的存儲設備上 這就是與集中式資料庫的區別 從用戶的角度看 一個分布式資料庫系統在邏輯上和集中式資料庫系統一樣 用戶可以在任何一個場地執行全局應用 就好那些數據是存儲在同一台計算機上 有單個資料庫管理系統(DBMS)管理一樣 用戶並沒有什麼感覺不一樣
分布式資料庫中每一個資料庫伺服器合作地維護全局資料庫的一致性
分布式資料庫系統是一個客戶/伺服器體系結構
在系統中的每一台計算機稱為結點 如果一結點具有管理資料庫軟體 該結點稱為資料庫伺服器 如果一個結點為請求伺服器的信息的一應用 該結點稱為客戶 在ORACLE客戶 執行資料庫應用 可存取數據信息和與用戶交互 在伺服器 執行ORACLE軟體 處理對ORACLE資料庫並發 共享數據存取 ORACLE允許上述兩部分在同一台計算機上 但當客戶部分和伺服器部分是由網連接的不同計算機上時 更有效
分布處理是由多台處理機分擔單個任務的處理 在ORACLE資料庫系統中分布處理的例子如
客戶和伺服器是位於網路連接的不同計算機上
單台計算機上有多個處理器 不同處理器分別執行客戶應用
參與分布式資料庫的每一伺服器是分別地獨立地管理資料庫 好像每一資料庫不是網路化的資料庫 每一個資料庫獨立地被管理 稱為場地自治性 場地自治性有下列好處
◆系統的結點可反映公司的邏輯組織
◆由局部資料庫管理員控制局部數據 這樣每一個資料庫管理員責任域要小一些 可更好管理
◆只要一個資料庫和網路是可用 那麼全局資料庫可部分可用 不會因一個資料庫的故障而停止全部操作或引起性能瓶頸
◆故障恢復通常在單個結點上進行
◆每個局部資料庫存在一個數據字典
◆結點可獨立地升級軟體
可從分布式資料庫的所有結點存取模式對象 因此正像非分布的局部的DBMS 必須提供一種機制 可在局部資料庫中引用一個對象 分布式DBMS必須提供一種命名模式 以致分布式資料庫中一個對象可在應用中唯一標識和引用 一般在層次結構的每一層實施唯一性 分布式DBMS簡單地擴充層次命名模型 實施在網路上唯一資料庫命名 因此一個對象的全局對象名保證在分布式資料庫內是唯一
ORACLE允許在SQL語句中使用全局對象名引用分布式資料庫中的模式對象(表 視圖和過程) 在ORACLE中 一個模式對象的全局名由三部分組成 包含對象的模式名 對象名 資料庫名 其形式如
SCOTT EMP@SALES DIVISION ACME
一個遠程查詢為一查詢 是從一個或多個遠程表中選擇信息 這些表駐留在同一個遠程結點
一個分布式查詢可從兩個或多個結點檢索數據 一個分布式更新可修改兩個或兩個以上結點的數據
一個遠程事務為一個事務 包含一人或多個遠程語句 它所引用的全部是在同一個遠程結點上 一個分布式事務中一個事務 包含一個或多個語句修改分布式資料庫的兩個或多個不同結點的數據
在分布式資料庫中 事務控制必須在網路上直轄市 保證數據一致性 兩階段提交機制保證參與分布式事務的全部資料庫伺服器是全部提交或全部回滾事務中的語句
ORACLE分布式資料庫系統結構可由ORACLE資料庫管理員為終端用戶和應用提供位置透明性 利用視圖 同義詞 過程可提供ORACLE分布式資料庫系統中的位置透明性
ORACLE提供兩種機制實現分布式資料庫中表重復的透明性 錶快照提供非同步的表重復;觸發器實現同步的表的重復 在兩種情況下 都實現了對表重復的透明性
在單場地或分布式資料庫中 所有事務都是用MIT或ROLLBACK語句中止
二 分布式資料庫系統的分類
( ) 同構同質型DDBS 各個場地都採用同一類型的數據模型(譬如都是關系型) 並且是同一型號的DBMS
( )同構異質型DDBS 各個場地採用同一類型的數據模型 但是DBMS的型號不同 譬如DB ORACLE SYBASE SQL Server等
( )異構型DDBS 各個場地的數據模型的型號不同 甚至類型也不同 隨著計算機網路技術的發展 異種機聯網問題已經得到較好的解決 此時依靠異構型DDBS就能存取全網中各種異構局部庫中的數據
三 分布式資料庫系統主要特點
DDBS的基本特點
( )物理分布性 數據不是存儲在一個場地上 而是存儲在計算機網路的多個場地上
邏輯整體性 數據物理分布在各個場地 但邏輯上是一個整體 它們被所有用戶(全局用戶)共享 並由一個DDBMS統一管理
( )場地自治性 各場地上的數據由本地的DBMS管理 具有自治處理能力 完成本場地的應用(局部應用)
( )場地之間協作性 各場地雖然具有高度的自治性 但是又相互協作構成一個整體
DDBS的其他特點
( )數據獨立性
( )集中與自治相結合的控制機制
( )適當增加數據冗餘度
( )事務管理的分布性
四 分布式資料庫系統的優點
( )更適合分布式的管理與控制
分布式資料庫系統的結構更適合具有地理分布特性的組織或機構使用 允許分布在不同區域 不同級別的各個部門對其自身的數據實行局部控制 例如 實現全局數據在本地錄入 查詢 維護 這時由於計算機資源靠近用戶 可以降低通信代價 提高響應速度 而涉及其他場地資料庫中的數據只是少量的 從而可以大大減少網路上的信息傳輸量;同時 局部數據的安全性也可以做得更好
( )具有靈活的體系結構
集中式資料庫系統強調的是集中式控制 物理資料庫是存放在一個場地上的 由一個DBMS集中管理 多個用戶只可以通過近程或遠程終端在多用戶操作系統支持下運行該DBMS來共享集中是資料庫中的數據 而分布式資料庫系統的場地局部DBMS的自治性 使得大部分的局部事務管理和控制都能就地解決 只有在涉及其他場地的數據時才需要通過網路作為全局事務來管理 分布式DBMS可以設計成具有不同程度的自治性 從具有充分的場地自治到幾乎是完全集中式的控制
( )系統經濟 可靠性高 可用性好
與一個大型計算機支持一個大型的集中式資料庫在加一些進程和遠程終端相比 由超級微型計算機或超級小型計算機支持的分布式資料庫系統往往具有更高的性價比和實施靈活性 分布式系統比集中式系統具有更高的可靠性和更好的可用性 如由於數據分布在多個場地並有許多復制數據 在個別場地或個別通信鏈路發生故障時 不致於導致整個系統的崩潰 而且系統的局部故障不會引起全局失控
( )在一定條件下響應速度加快
如果存取的數據在本地資料庫中 那麼就可以由用戶所在的計算機來執行 速度就快
( )可擴展性好 易於集成現有系統 也易於擴充
對於一個企業或組織 可以採用分布式資料庫技術在以建立的若干資料庫的基礎上開發全局應用 對原有的局部資料庫系統作某些改動 形成一個分布式系統 這比重建一個大型資料庫系統要簡單 既省時間 又省財力 物力 也可以通過增加場地數的辦法 迅速擴充已有的分布式資料庫系統
五 分布式資料庫系統的劣勢
( )通信開銷較大 故障率高
例如 在網路通信傳輸速度不高時 系統的響應速度慢 與通信相關的因素往往導致系統故障 同時系統本身的復雜性也容易導致較高的故障率 當故障發生後系統恢復也比較復雜 可靠性有待提高
( )數據的存取結構復雜
一般來說 在分布時資料庫中存取數據 比在集中時資料庫中存取數據更復雜 開銷更大
( )數據的安全性和保密性較難控制
在具有高度場地自治的分布時資料庫中 不同場地的局部資料庫管理員可以採用不同的安全措施 但是無法保證全局數據都是安全的 安全性問題式分布式系統固有的問題 因為分布式系統式通過通信網路來實現分布控制的 而通信網路本身卻在保護數據的安全性和保密性方面存在弱點 數據很容易被竊取
分布式資料庫的設計 場地劃分及數據在不同場地的分配比較復雜 數據的劃分及分配對系統的性能 響應速度及可用性等具有極大的影響 不同場地的通信速度與局部資料庫系統的存取部件的存取速度相比 是非常慢的 通信系統有較高的延遲 在CPU上處理通信信息的代價很高 分布式資料庫系統中要注意解決分布式資料庫的設計 查詢處理和優化 事務管理及並發控制和目錄管理等問題
六 分布式資料庫系統 數據分片
類型
水平分片
按一定的條件把全局關系的所有元組劃分成若干不相交的子集 每個子集為關系的一個片段
垂直分片
把一個全局關系的屬性集分成若乾子集 並在這些子集上作投影運算 每個投影稱為垂直分片
導出分片
又稱為導出水平分片 即水平分片的條件不是本關系屬性的條件 而是其他關系屬性的條件
混合分片
以上三種方法的混合 可以先水平分片再垂直分片 或先垂直分片再水平分片 或其他形式 但他們的結果是不相同的
條件
( )完備性條件
必須把全局關系的所有數據映射到片段中 決不允許有屬於全局關系的數據卻不屬於它的任何一個片段
( )可重構條件
必須保證能夠由同一個全局關系的各個片段來重建該全局關系 對於水平分片可用並操作重構全局關系;對於垂直分片可用聯接操作重構全局關系
( )不相交條件
要求一個全局關系被分割後所得的各個數據片段互不重疊(對垂直分片的主鍵除外)
七 分布式資料庫系統 數據分配方式
( )集中式 所有數據片段都安排在同一個場地上
( )分割式
所有數據只有一份 它被分割成若干邏輯片段 每個邏輯片段被指派在一個特定的場地上
( )全復制式 數據在每個場地重復存儲 也就是每個場地上都有一個完整的數據副本
( )混合式 這是一種介乎於分割式和全復制式之間的分配方式
八 分布式資料庫系統 體系結構
數據分片和數據分配概念的分離 形成了 數據分布獨立型 概念
數據冗餘的顯式控制 數據在各個場地的分配情況在分配模式中一目瞭然 便於系統管理
局部DBMS的獨立性 這個特徵也稱為 局部映射透明性 此特徵允許我們在不考慮局部DBMS專用數據模型的情況下 研究DDB管理的有關問題
九 分布式資料庫管理系統
接受用戶請求 並判定把它送到哪裡 或必須訪問哪些計算機才能滿足該要求
訪問網路數據字典 了解如何請求和使用其中的信息
如果目標數據存儲於系統的多個計算機上 就必須進行分布式處理
通信介面功能 在用戶 局部DBMS和其他計算機的DBMS之間進行協調
在一個異構型分布式處理環境中 還需提供數據和進程移植的支持 這里的異構型是指各個場地的硬體 軟體之間存在著差別
分布式資料庫管理系統
lishixin/Article/program/Oracle/201311/16998
8. 求救，分布式事務怎麼處理
1.性能和時延問題在服務化之前，業務通常都是本地API調用，本地方法調用性能損耗較小。服務化之後，服務提供者和消費者之間採用遠程網路通信，增加了額外的性能損耗：1）客戶端需要對消息進行序列化，主要佔用CPU計算資源。2）序列化時需要創建二進制數組，耗費JVM堆內存或者堆外內存。3）客戶端需要將序列化之後的二進制數組發送給服務端，佔用網路帶寬資源。4）服務端讀取到碼流之後，需要將請求數據報反序列化成請求對象，佔用CPU計算資源。5）服務端通過反射的方式調用服務提供者實現類，反射本身對性能影響就比較大。6）服務端將響應結果序列化，佔用CPU計算資源。7）服務端將應答碼流發送給客戶端，佔用網路帶寬資源。8）客戶端讀取應答碼流，反序列化成響應消息，佔用CPU資源。通過分析我們發現，一個簡單的本地方法調用，切換成遠程服務調用之後，額外增加了很多處理流程，不僅佔用大量的系統資源，同時增加了時延。一些復雜的應用會拆分成多個服務，形成服務調用鏈，如果服務化框架的性能比較差、服務調用時延也比較大，業務服務化之後的性能和時延將無法滿足業務的性能需求。1.1RPC框架高性能設計影響RPC框架性能的主要因素有三個。1）I/O調度模型：同步阻塞I/O（BIO）還是非阻塞I/O（NIO）。2）序列化框架的選擇：文本協議、二進制協議或壓縮二進制協議。3）線程調度模型：串列調度還是並行調度，鎖競爭還是無鎖化演算法。1.I/O調度模型在I/O編程過程中，當需要同時處理多個客戶端接入請求時，可以利用多線程或者I/O多路復用技術進行處理。I/O多路復用技術通過把多個I/O的阻塞復用到同一個select的阻塞上，從而使得系統在單線程的情況下可以同時處理多個客戶端請求。與傳統的多線程/多進程模型比，I/O多路復用的最大優勢是系統開銷小，系統不需要創建新的額外進程或者線程，也不需要維護這些進程和線程的運行，降低了系統的維護工作量，節省了系統資源。JDK1.5_update10版本使用epoll替代了傳統的select/poll，極大地提升了NIO通信的性能，它的工作原理如圖1-1所示。圖1-1非阻塞I/O工作原理Netty是一個開源的高性能NIO通信框架：它的I/O線程NioEventLoop由於聚合了多路復用器Selector，可以同時並發處理成百上千個客戶端Channel。由於讀寫操作都是非阻塞的，這就可以充分提升I/O線程的運行效率，避免由於頻繁I/O阻塞導致的線程掛起。另外，由於Netty採用了非同步通信模式，一個I/O線程可以並發處理N個客戶端連接和讀寫操作，這從根本上解決了傳統同步阻塞I/O一連接一線程模型，架構的性能、彈性伸縮能力和可靠性都得到了極大的提升。Netty被精心設計，提供了很多獨特的性能提升特性，使它做到了在各種NIO框架中性能排名第一，它的性能優化措施總結如下。1）零拷貝：（1）Netty的接收和發送ByteBuffer採用DIRECTBUFFERS，使用堆外直接內存進行Socket讀寫，不需要進行位元組緩沖區的二次拷貝。如果使用傳統的堆內存（HEAPBUFFERS）進行Socket讀寫，JVM會將堆內存Buffer拷貝一份到直接內存中，然後才寫入Socket中。相比於堆外直接內存，消息在發腔兆送過程中多了一次緩沖區的內存拷貝。（2）Netty提供了組合Buffer對象，可以聚合多個ByteBuffer對象，用戶可以像操作一個Buffer那樣方便地對組合Buffer進行操作，避免了傳統通過內存拷貝的方式將幾手圓悔個小Buffer合並成一個大的Buffer。（3）Netty的文件傳輸採用了transferTo方法，它可以直接將文件緩沖區的數據發送到目標Channel，避免了傳統通過循環write方式導致的內存拷貝問題。2）內存池：隨著JVM虛擬機和JIT即時編譯技術的發展，對象的分配和回收是個非常輕量級的工作。但是對於緩沖區Buffer，情況卻稍有不同，特別是對於堆外直接內存的分配和回收，是一件耗時的操作。為了盡量重用緩沖區，Netty提供了基於內存池的緩沖區重用機制。性能測試表明，採用內存池的ByteBuf相比於朝生夕滅的ByteBuf，性能高23倍左右（性能數據與使用場景強相關）。3）無鎖化的串列設計：在大多畢正數場景下，並行多線程處理可以提升系統的並發性能。但是，如果對於共享資源的並發訪問處理不當，會帶來嚴重的鎖競爭，這最終會導致性能的下降。為了盡可能地避免鎖競爭帶來的性能損耗，可以通過串列化設計，即消息的處理盡可能在同一個線程內完成，期間不進行線程切換，這樣就避免了多線程競爭和同步鎖。為了盡可能提升性能，Netty採用了串列無鎖化設計，在I/O線程內部進行串列操作，避免多線程競爭導致的性能下降。表面上看，串列化設計似乎CPU利用率不高，並發程度不夠。但是，通過調整NIO線程池的線程參數，可以同時啟動多個串列化的線程並行運行，這種局部無鎖化的串列線程設計相比一個隊列-多個工作線程模型性能更優。4）高效的並發編程：volatile的大量、正確使用；CAS和原子類的廣泛使用；線程安全容器的使用；通過讀寫鎖提升並發性能。2.高性能序列化框架影響序列化性能的關鍵因素總結如下。1）序列化後的碼流大小（網路帶寬的佔用）。2）序列化&反序列化的性能（CPU資源佔用）。3）是否支持跨語言（異構系統的對接和開發語言切換）。4）並發調用的性能表現：穩定性、線性增長、偶現的時延毛刺等。相比於JSON等文本協議，二進制序列化框架性能更優異，以Java原生序列化和Protobuf二進制序列化為例進行性能測試對比，結果如圖1-2所示。圖1-2序列化性能測試對比數據在序列化框架的技術選型中，如無特殊要求，盡量選擇性能更優的二進制序列化框架，碼流是否壓縮，則需要根據通信內容做靈活選擇，對於圖片、音頻、有大量重復內容的文本文件（例如小說）可以採用碼流壓縮，常用的壓縮演算法包括GZip、Zig-Zag等。3.高性能的Reactor線程模型該模型的特點總結如下。1）有專門一個NIO線程：Acceptor線程用於監聽服務端，接收客戶端的TCP連接請求。2）網路I/O操作：讀、寫等由一個NIO線程池負責，線程池可以採用標準的JDK線程池實現，它包含一個任務隊列和N個可用的線程，由這些NIO線程負責消息的讀取、解碼、編碼和發送。3）1個NIO線程可以同時處理N條鏈路，但是1個鏈路只對應1個NIO線程，防止產生並發操作。由於Reactor模式使用的是非同步非阻塞I/O，所有的I/O操作都不會導致阻塞，理論上一個線程可以獨立處理所有I/O相關的操作，因此在絕大多數場景下，Reactor多線程模型都可以完全滿足業務性能需求。Reactor線程調度模型的工作原理示意如圖1-3所示。圖1-3高性能的Reactor線程調度模型1.2業務最佳實踐要保證高性能，單依靠分布式服務框架是不夠的，還需要應用的配合，應用服務化高性能實踐總結如下：1）能非同步的盡可能使用非同步或者並行服務調用，提升服務的吞吐量，有效降低服務調用時延。2）無論是NIO通信框架的線程池還是後端業務線程池，線程參數的配置必須合理。如果採用JDK默認的線程池，最大線程數建議不超過20個。因為JDK的線程池默認採用N個線程爭用1個同步阻塞隊列方式，當線程數過大時，會導致激烈的鎖競爭，此時性能不僅不會提升，反而會下降。3）盡量減小要傳輸的碼流大小，提升性能。本地調用時，由於在同一塊堆內存中訪問，參數大小對性能沒有任何影響。跨進程通信時，往往傳遞的是個復雜對象，如果明確對方只使用其中的某幾個欄位或者某個對象引用，則不要把整個復雜對象都傳遞過去。舉例，對象A持有8個基本類型的欄位，2個復雜對象B和C。如果明確服務提供者只需要用到A聚合的C對象，則請求參數應該是C，而不是整個對象A。4）設置合適的客戶端超時時間，防止業務高峰期因為服務端響應慢導致業務線程等應答時被阻塞，進而引起後續其他服務的消息在隊列中排隊，造成故障擴散。5）對於重要的服務，可以單獨部署到獨立的服務線程池中，與其他非核心服務做隔離，保障核心服務的高效運行。6）利用Docker等輕量級OS容器部署服務，對服務做物理資源層隔離，避免虛擬化之後導致的超過20%的性能損耗。7）設置合理的服務調度優先順序，並根據線上性能監控數據做實時調整。2.事務一致性問題服務化之前，業務採用本地事務，多個本地SQL調用可以用一個大的事務塊封裝起來，如果某一個資料庫操作發生異常，就可以將之前的SQL操作進行回滾，只有所有SQL操作全部成功，才最終提交，這就保證了事務強一致性，如圖2-1所示。服務化之後，三個資料庫操作可能被拆分到獨立的三個資料庫訪問服務中，此時原來的本地SQL調用演變成了遠程服務調用，事務一致性無法得到保證，如圖2-2所示。圖2-2服務化之後引入分布式事務問題假如服務A和服務B調用成功，則A和B的SQL將會被提交，最後執行服務C，它的SQL操作失敗，對於應用1消費者而言，服務A和服務B的相關SQL操作已經提交，服務C發生了回滾，這就導致事務不一致。從圖2-2可以得知，服務化之後事務不一致主要是由服務分布式部署導致的，因此也被稱為分布式事務問題。2.1分布式事務設計方案通常，分布式事務基於兩階段提交實現，它的工作原理示意圖如圖2-3所示。圖2-3兩階段提交原理圖階段1：全局事務管理器向所有事務參與者發送准備請求；事務參與者向全局事務管理器回復自己是否准備就緒。階段2：全局事務管理器接收到所有事務參與者的回復之後做判斷，如果所有事務參與者都可以提交，則向所有事務提交者發送提交申請，否則進行回滾。事務參與者根據全局事務管理器的指令進行提交或者回滾操作。分布式事務回滾原理圖如圖2-4所示。圖2-4分布式事務回滾原理圖兩階段提交採用的是悲觀鎖策略，由於各個事務參與者需要等待響應最慢的參與者，因此性能比較差。第一個問題是協議本身的成本：整個協議過程是需要加鎖的，比如鎖住資料庫的某條記錄，且需要持久化大量事務狀態相關的操作日誌。更為麻煩的是，兩階段鎖在出現故障時表現出來的脆弱性，比如兩階段鎖的致命缺陷：當協調者出現故障，整個事務需要等到協調者恢復後才能繼續執行，如果協調者出現類似磁碟故障等錯誤，該事務將被永久遺棄。對於分布式服務框架而言，從功能特性上需要支持分布式事務。在實際業務使用過程中，如果能夠通過最終一致性解決問題，則不需要做強一致性；如果能夠避免分布式事務，則盡量在業務層避免使用分布式事務。2.2分布式事務優化既然分布式事務有諸多缺點，那麼為什麼我們還在使用呢？有沒有更好的解決方案來改進或者替換呢？如果我們只是針對分布式事務去優化的話，發現其實能改進的空間很小，畢竟瓶頸在分布式事務模型本身。那我們回到問題的根源：為什麼我們需要分布式事務？因為我們需要各個資源數據保持一致性，但是對於分布式事務提供的強一致性，所有業務場景真的都需要嗎？大多數業務場景都能容忍短暫的不一致，不同的業務對不一致的容忍時間不同。像銀行轉賬業務，中間有幾分鍾的不一致時間，用戶通常都是可以理解和容忍的。在大多數的業務場景中，我們可以使用最終一致性替代傳統的強一致性，盡量避免使用分布式事務。在實踐中常用的最終一致性方案就是使用帶有事務功能的MQ做中間人角色，它的工作原理如下：在做本地事務之前，先向MQ發送一個prepare消息，然後執行本地事務，本地事務提交成功的話，向MQ發送一個commit消息，否則發送一個rollback消息，取消之前的消息。MQ只會在收到commit確認才會將消息投遞出去，所以這樣的形式可以保證在一切正常的情況下，本地事務和MQ可以達到一致性。但是分布式調用存在很多異常場景，諸如網路超時、VM宕機等。假如系統執行了local_tx()成功之後，還沒來得及將commit消息發送給MQ，或者說發送出去由於網路超時等原因，MQ沒有收到commit，發生了commit消息丟失，那麼MQ就不會把prepare消息投遞出去。MQ會根據策略去嘗試詢問（回調）發消息的系統（checkCommit）進行檢查該消息是否應該投遞出去或者丟棄，得到系統的確認之後，MQ會做投遞還是丟棄，這樣就完全保證了MQ和發消息的系統的一致性，從而保證了接收消息系統的一致性。3.研發團隊協作問題服務化之後，特別是採用微服務架構以後。研發團隊會被拆分成多個服務化小組，例如AWS的TwoPizzaTeam，每個團隊由2~3名研發負責服務的開發、測試、部署上線、運維和運營等。隨著服務數的膨脹，研發團隊的增多，跨團隊的協同配合將會成為一個制約研發效率提升的因素。3.1共用服務注冊中心為了方便開發測試，經常會在線下共用一個所有服務共享的服務注冊中心，這時，一個正在開發中的服務發布到服務注冊中心，可能會導致一些消費者不可用。解決方案：可以讓服務提供者開發方，只訂閱服務（開發的服務可能依賴其他服務），而不注冊正在開發的服務，通過直連測試正在開發的服務。它的工作原理如圖3-1所示。圖3-1隻訂閱，不發布3.2直連提供者在開發和測試環境下，如果公共的服務注冊中心沒有搭建，消費者將無法獲取服務提供者的地址列表，只能做本地單元測試或使用模擬樁測試。還有一種場景就是在實際測試中，服務提供者往往多實例部署，如果服務提供者存在Bug，就需要做遠程斷點調試，這會帶來兩個問題：1）服務提供者多實例部署，遠程調試地址無法確定，調試效率低下。2）多個消費者可能共用一套測試聯調環境，斷點調試過程中可能被其他消費者意外打斷。解決策略：繞過注冊中心，只測試指定服務提供者，這時候可能需要點對點直連，點對點直聯方式將以服務介面為單位，忽略注冊中心的提供者列表。3.3多團隊進度協同假如前端Web門戶依賴後台A、B、C和D4個服務，分別由4個不同的研發團隊負責，門戶要求新特性2周內上線。A和B內部需求優先順序排序將門戶的優先順序排的比較高，可以滿足交付時間點。但是C和D服務所在團隊由於同時需要開發其他優先順序更高的服務，因此把優先順序排的相對較低，無法滿足2周交付。在C和D提供版本之前，門戶只能先通過打測試樁的方式完成Mock測試，但是由於並沒有真實的測試過C和D服務，因此需求無法按期交付。應用依賴的服務越多，特性交付效率就越低下，交付的速度取決於依賴的最遲交付的那個服務。假如Web門戶依賴後台的100個服務，只要1個核心服務沒有按期交付，則整個進度就會延遲。解決方案：調用鏈可以將應用、服務和中間件之間的依賴關系串接並展示出來，基於調用鏈首入口的交付日期作為輸入，利用依賴管理工具，可以自動計算出調用鏈上各個服務的最遲交付時間點。通過調用鏈分析和標准化的依賴計算工具，可以避免人為需求排序失誤導致的需求延期。3.4服務降級和Mock測試在實際項目開發中，由於小組之間、個人開發者之間開發節奏不一致，經常會出現消費者等待依賴的服務提供者提供聯調版本的情況，相互等待會降低項目的研發進度。解決方案：服務提供者首先將介面定下來並提供給消費者，消費者可以將服務降級同Mock測試結合起來，在Mock測試代碼中實現容錯降級的業務邏輯（業務放通），這樣既完成了Mock測試，又實現了服務降級的業務邏輯開發，一舉兩得。3.5協同調試問題在實際項目開發過程中，各研發團隊進度不一致很正常。如果消費者坐等服務提供者按時提供版本，往往會造成人力資源浪費，影響項目進度。解決方案：分布式服務框架提供Mock樁管理框架，當周邊服務提供者尚未完成開發時，將路由切換到模擬測試模式，自動調用Mock樁；業務集成測試和上線時，則要能夠自動切換到真實的服務提供者上，可以結合服務降級功能實現。3.6介面前向兼容性由於線上的Bug修復、內部重構和需求變更，服務提供者會經常修改內部實現，包括但不限於：介面參數變化、參數欄位變化、業務邏輯變化和數據表結構變化。在實際項目中經常會發生服務提供者修改了介面或者數據結構，但是並沒有及時知會到所有消費者，導致服務調用失敗。解決方案：1）制定並嚴格執行《服務前向兼容性規范》，避免發生不兼容修改或者私自修改不通知周邊的情況。2）介面兼容性技術保障：例如Thrift的IDL，支持新增、修改和刪除欄位，欄位定義位置無關性，碼流支持亂序等。4.總結服務化之後，無論是服務化框架，還是業務服務，都面臨諸多挑戰，本章摘取了其中一些比較重要的問題，並給出解決方案和最佳實踐。對於本章節沒有列出的問題，則需要服務框架開發者和使用者在實踐中探索，找出一條適合自己產品的服務化最佳實踐。
9. 資料庫運行過程中常見的故障有哪幾類試述對各類故障的恢復策略。
資料庫運行過程中常見的故障有3類：事物故障、系統故障、介質故障。
恢復策略：
1、事物故障：
發生事務故障時，被迫中斷的事務可能已對資料庫進行丁修改，為了消除該事務對資料庫的影響，要利用日誌文件中所記載的信息，強行回滾該事務，將資料庫恢復到修改前的初始狀態。
為此，要檢查日誌文件中由這些事務所引起的發生變化的記錄，取消這些沒有完成的事務所做的一切改變，這類恢復操作稱為事務撤銷。
2、系統故障：
系統故障的恢復要完成兩方面的工作，既要撤銷所有末完成的事務，還要重做所有已提交的事務，這樣才能將資料庫真正恢復到一致的狀態。
3、介質故障：
介質故障比事務故障和系統故障發生的可能性要小，但這是最嚴重的一種故障，破壞性很大，磁碟上的物理數據和日誌文件可能被破壞，這需要裝入發生介肢純質故障前最新的後備資料庫副本，然後利用日誌文件重做該副本後所運行的所有事務。
(9)分布式資料庫事務故障恢復原則擴展閱讀：
「數據故障恢復」和「完整性約束」、「並發控制」一樣，都是資料庫數據保護機制中的一種完整性控制。所有的系統都免不了會發生故障，有可能是硬體失靈，有可能是軟體系統崩潰，也有可能是其他外界的原因，比如斷電等等。
資料庫運行的突然中斷會使資料庫處在一個錯誤的狀態局飢雀，而且故障排除後沒有辦法讓系統精確地從斷點繼續執行下去。這就要求DBMS要有一套故障後的數據恢復機構，保證數桐早據庫能夠回復到一致的、正確地狀態去。
參考資料來源：網路-事務故障
參考資料來源：網路-系統故障
參考資料來源：網路-介質故障
10. 在分布式系統中，為什麼有時難以隱藏故障的發生以及故障恢復過程
分布式系統（distributed system）是建立在網路之上行螞的軟體系統。正是因為軟體的特性，所以分布式系統具有高度的內聚性和透明性。因此，網路和分布式系統之間的區別凳虛更多的在於高層軟體（特別是操作系統），而不是硬體。內聚性是指每一個資料庫分布節點高度自治，有本地的資料庫管理系統。透明性是指每一個資料庫分布節點對用檔粗埋戶的應用來說都是透明的，看不出是本地還是遠程。在分布式資料庫系統中，用戶感覺不到數據是分布的，即用戶不須知道關系是否分割、有無副本、數據存於哪個站點以及事務在哪個站點上執行等。