單機情況下資料庫在不同語言，不同平臺都有各自資料庫訪問元件，各種類似odbc、jdbc的封裝以及orm的處理都已經相當成熟。

資料庫壓力越來越大，處理方法是優化應用，減少壓力。二是對資料庫進行讀寫分離，加入搜尋引擎和快取等，進而採用拆分的方法

垂直拆分（業務邏輯拆分）

單機acid受影響，要麼放棄事物，要麼引入分散式事物

join操作受影響，因為在兩個庫中了

靠外來鍵進行約束的場景會收到影響

水平拆分

前三條和垂直拆分一樣

依賴單庫的自增序列生成唯一id受影響

單個邏輯意義上的表查詢要跨庫

上述只是部分影響，其它例如儲存過程，觸發器等都需要改寫才能完成相應的工作

x/open組織，現在的the open group指定的分散式事物規範

分散式事物規範：XA

分散式事物處理模型：DTP，它由三個元件，ap應用程式，rm資源管理器，tm事物管理器

事物管理器向事物指定標識，監控程序，負責事物的完成和失敗。事物分支標識xid，兩階段回滾需要用到xid

ap可以通過native api呼叫rm，不實現事物支援，也可以通過xa api進行事物呼叫，ap和事物管理器通過tx介面，tm和rm通過xa介面訪問

可以選擇是否實現兩階段提交，兩階段提交之間有準備過程，tm可以根據日誌回滾，但是由於tm的自身穩定性，網路問題，以及兩階段帶來的互動次數增多以及引入tm的開銷，可以考慮是否開啟兩階段提交

大型網站一致性理論基礎：cap

c: consistency 資料寫入成功後所有的節點都會同時看到這個新資料

a:無論成功還是失敗都要有響應

p：部分失效無論系統還是資料的時候系統還能正常雲狀

但是cap不能兼得，要有取捨，ca放棄p這正是單機資料庫的選擇，ap放棄c這正式很多分散式系統的選擇nosql系統就是這樣

一般的外面都是首先滿足ap最後追求c

這就是所謂base模型

basically available：基本可用允許分割槽失敗

soft state：軟狀態，允許一段時間的資料不統一

eventually consistency：最終一致

比兩階段提交更加輕量級的paxos協議

paxos的前提是不能有拜占庭將軍問題

叢集內資料一致性的演算法：quorum和 vector clock

第二種在同一份資料的每一次修改後面加上修改者和時間戳，因為比如四個人聚餐的問題，a說週一，b和c商量說週三可以，後來b和d說週四可以，a通過從c，d返回的資料確定時間，但是不知道先後順序無法判斷，所以要加上時間戳，實現最終的時間一致性

多機的自增問題

oracle 提供對sequence的支援，mysql有auto increment，但是在多機環境下這是個難題

怎麼保證自增序列的一致性和連續性

一個方案：把id集中管理，每次取用

效能問題：遠端取用效能損耗

生成器穩定性

儲存問題

兩種實現：1、中心id生成器 2、內嵌在應用層的id生成邏輯，在id生成的時候請求id

跨庫join

解決方案：1、在應用層把join分開，2、資料冗餘3、藉助外部系統如搜尋引擎解決一些跨庫問題

外來鍵約束：

比艱難，不能完全依賴庫之前的功能了，要求分庫後庫的內容是內聚的，否則只能靠應用層的判斷和容錯了

分表後的資料查詢問題，一般在應用層進行相應的排序，函式處理，求平均值，排序分頁等

資料層的整理流程

sql解析，規則處理，sql改寫，資料來源選擇，sql執行，返回處理合並