一，分布式資料庫的簡單了解
我們目前使用的資料庫中介軟體udal，據文件描述，底層使用的是阿里的開源cobar，網上了解cobar社群幾年前早已經不更新了，現在比較火熱的是mycat中介軟體。udal與mycat類似，此外根據自身業務需求，增加了全域性序列，切片索引，日誌，web統一管理介面等。
1，核心問題—事務
分布式資料庫的核心問題的是事務的管理，cobar是不支援分布式事務的，mycat也只支援弱分布式事務。市面上其他各種分布式資料庫中介軟體，包括 360 atals、美團點評的dbproxy、攜程的dal等均只支援單庫的事務。即使是單庫的事務，是不是跟操作單個資料庫的原理一樣？當然對於我們使用者感知而言，確實跟操作單庫是沒有區別。但在事務實現上，跟傳統的操作單個資料庫是有區別的。接下來討論下傳統資料庫裡面是如何實現事務，然後再分析分布式事務的複雜性，為啥這麼多開源社群大牛暫時都不能解決。
2，分片及路由規則
分布式資料庫把原來單個庫的資料分開儲存，其過程就是分片，其結果就是得到多個資料庫，每個資料庫稱為片。一般而言，會預先設計好合理的分片鍵，使資料盡可能的均勻落在每乙個片上。具體分片演算法主要是hash演算法和hash一致性演算法等，演算法內容不是本次討論重點就暫時忽略。在管理分片時，有乙個資料儲存節點的概念，這是乙個邏輯上的劃分，乙個節點可以包含乙個或者多個片，也可以跨多個物理伺服器。這裡是部署上的規則，預設地，我們認為單個資料庫節點指的是單個物理片。對於使用者而言，感知的是乙個庫，這是由於中介軟體提供了統一管理的方式，對外界暴露乙個訪問位址，請求過來後，根據路由規則再跳轉到具體的某個庫裡面。
3，路由規則
中介軟體如何知道使用者要操作哪個庫，使用的是之前定義好的分片鍵。當使用者傳送資料庫操作語句時，中介軟體會根據分片演算法得到具體資料落在哪乙個片上。中介軟體統一管理每個物理片，會在元資料管理層上建立乙個對映關係，即當分片演算法得出操作的資料節點為dn1時，中介軟體就會根據對映關係獲得節點dn1的連線，並把經過初步解析的sql送給dn1節點。這裡就跟我們平時操作單庫一樣，只不過這個過程由中介軟體完成，對使用者不可見。注意select與delete,insert,update的區別，select 根據分片鍵得到具體執行sql的資料節點，如果沒有分片鍵，中介軟體會預設把sql傳送到每乙個節點上去執行，就是廣播。如果是insert語句，預設是必須帶有路由標識，因為中間解析sql的時候，如果沒有分片建，插入資料的時候廣播去插入每個資料節點，顯然是不合理的。同理，delete, update也需要帶有路由標識。
二，傳統單個資料庫的事務控制
事務的目的是為了保證一系列操作的原子性，要麼同時成功，要麼同時失敗。資料庫本身已實現事務，使用者使用資料庫需要事務的時候，只需要開啟乙個資料庫的事務，並在此事務期間執行一些操作，提交事務後由資料庫保證事務的完整性。這裡通過spring配置的顯示事務，只是開啟乙個資料庫事務，就好比告訴資料庫，接下來的操作你必須保證要麼全部成功，要麼全部失敗。具體做事由資料庫完成，spring不管這事，他只在有需求的時候，去通知某個人去做這件事。那麼資料庫怎麼實現事務的？每次使用者在執行dml語句時，資料庫會有日誌記錄下，在整個事務期間所有的操作和對應變更的資料，有多條就記錄多條，並以二進位制的方式儲存在資料庫儲存系統中。這裡大批量的資料操作涉及到很大io開銷，如何儲存，備份以及效率問題不做延伸。當最後某條語句失敗時，資料庫就開始回滾，實現過程就是解析之前記錄的日誌資訊，進行逆操作。主從同步，分布式全域性序列的生成也可以採用解析日誌的方式實現。強調，使用者在操作層面上只負責開啟乙個事務事件，具體事務執行由資料庫完成。對於不在同乙個事務裡面，但又要保證所有操作的原子性，就要自己手動寫**回滾了。
三，分布式資料庫的事務控制
在應用層，我們像操作單庫時開啟乙個事務，現在問題就來了，開啟乙個事務後，中介軟體怎麼知道使用者接下來即將操作的是哪乙個庫。對於使用者來說，開啟事務後執行sql的節點完全隨機。當然你說，怎麼獲得事務由中介軟體完成，我們不關注，只需要開啟事務就行了。沒錯，這個確實是中間完成的，但是如果要自己去實現，該怎麼辦？
1，同一節點的事務
這裡提供乙個思路，當使用者需要事務時，就向中介軟體發出乙個訊息，意思是接下來我要開啟乙個事務了，請各單位做好準備，但此時中介軟體名下這麼多資料庫，也不知道你要操作的是哪個啊。中介軟體正犯愁時，然後使用者就傳送insert語句來了，中介軟體一看帶有分片鍵，這事好辦了，立馬根據對映關係拿到了某個節點的事務。中介軟體一想，既然路由到具體的資料庫了，那麼接下來操作就跟單庫一樣了，但是使用者接下來所有操作必須保證都在同乙個庫裡面。等所有操作執行完畢，使用者傳送commit，中介軟體收到資訊就知道事務結束了，於是就通知底層那個庫結束事務。這裡問題又來了，事務如果失敗了，到底是回滾還是不回滾？因為某些操作可以容忍失敗的情況，不能一棒子打死，所以這裡還需要使用者判斷是否回滾。如果不回滾，那執行錯誤的資料咋辦？就得有補償機制來操作了。預設地，如果是由於網路抖動帶來的異常，一般重複操作失敗步驟並限制重複次數，保持冪等性，直到成功為止。但對於資料本身或者**問題，就屬於故障了。這裡重複寫表的操作實現有多種，需要實時更新的資料，可以用非同步訊息佇列來處理，對於非實時資料，半夜沒人的時候用定時任務寫也可以。
2，分布式事務
2.1 分布式事務的產生
為啥會有分布式事務這個概念，比如我們開始獲得乙個事務事件，進行以下操作，首先在dn1上update表a，然後又在dn2上insert表b，這下中介軟體犯愁了，我不是告訴你必須得在同乙個節點裡面嗎？中介軟體還是開啟節點dn1的事務，並預設你接下來操作都是在節點dn1裡面的。這時忽然來了個節點dn2的操作，中介軟體又跑到節點dn2上執行，由於預設只開啟dn1的事務，如果此時節點dn2失敗，中介軟體不處理，他只能保證dn1上所有操作要麼失敗要麼成功。所以，更新dn1上的a表和插入dn2上表b並不在同乙個事務裡面，無法保證原子性，就產生了分布式事務。這裡指的是，如同cobar不提供分布式事務的情況。
2.2 弱xa事務
mycat有提供弱分布式事務的解決方案，如同上述情況，在dn1上update表a後，需要在在dn2上insert表b時，在dn2節點開啟乙個事務，此時我們的事務由事務dn1和事務dn2組成。如果dn1事務成功，並commit，接下來進行事務dn2，如果事務2失敗，立馬回滾事務dn2的操作，但是不回滾dn1的操作。這就是弱事務的解決方案。
2.3強xa事務
如同上述情況，如果事務dn2失敗，那麼連同之前事務dn1也同時回滾，嚴格保證分布式事務的原子性。這裡原理很簡單，實現過程也不是很難。但是考慮到使用業務背景的複雜性，在乙個分布式事務中可能需要包含很多個子事務，一方面，如果由於某個原因導致最後一步失敗，就立馬回滾整個操作，尤其是複雜的組合事務，採用強xa事務會嚴重影響應用伺服器的效率。其次，事務是通過網路在節點之間傳輸，具有一定不可靠性，如果嚴格保證事務一致性，將犧牲系統本身很大的效能。所以，軟體領域的一句話很實用，解決乙個問題的最好方式就是繞過它。盡可能保證所有操作在同一事務下，無法避免的再討論了。
分布式資料庫
網路選課系統中分布式資料庫設計 何翠雙王巧雲張麗麗 摘要 關鍵字 選課 分布式 資料庫 distributed system of on line course choosing abstract key words course choosing distributed database 隨著學校...
分布式資料庫
1 背景 我們知道資料是乙個公司的命脈，隨著業務越做越大，資料量也會越來越大，計算也會越來越複雜，效能，可靠性，可擴充套件性的需求就會越來越強烈，這個時候乙個集中式的資料庫顯然已經滿足不了需求了。對於技術決策者來說有兩條路可以走，第一 按照現有的大型資料庫的解決方案，比如sql server clu...
分布式資料庫
一 分布式資料庫的出現的場景 網際網路 軟體國產化 o2o 五新 新零售 新製造，新金融 新資源 新技術 等主題接連提出來，並且在各個行業落地，給資料庫帶來了巨大機會，具體包含3個方向 1.遠超單機資料庫容量的資料儲存和訪問峰值 2.實時資料分析檢索 oltp兼顧olap 3.更高階別的容災需求。這...