OB君：好消息！「 OceanBase 2.2 版本 」正式上線官網啦！（點選閱讀原文即可直接下載下傳）OceanBase 2.2版本是成功支撐2019年天貓雙11大促的穩定版本，同時也是用于TPC-C測試且榮登TPC-C性能榜首的版本。本文為 “OceanBase 2.2 解析系列” 第一篇，該系列将從事務、SQL、相容性等次元為大家全面解讀2.2版本的功能和特性。歡迎持續關注！
一路走來，OceanBase 始終堅持自主研發，去年雙11正式對外釋出的OceanBase 2.2 版本為内外部業務提供了很多新增的功能。與此同時，事務引擎也在持續疊代，推出了可串行化隔離級别、複制表、閃回等重要更新。本文将對OceanBase 2.2版本中事務引擎的三大重點功能分别進行介紹。
功能一：可串行化隔離級别
OceanBase 2.2 版本在之前 MySQL 相容性模式的基礎上推出了相容 Oracle 的模式。事務處理能力是 Oracle 相容性模式的重要組成部分。Oracle 事務引擎最有特點的功能是基于多版本控制的事務隔離能力，支援讀已送出（Read Committed）和可串行化（Serializable）兩種隔離級别。Oracle 兩種隔離級别均支援讀寫分離能力，修改操作不會影響讀取的進行，讀取操作也不會阻塞修改。
OceanBase 2.2 版本的 Oracle 相容模式目标是提供給使用者友善的移植應用的能力。OceanBase 事務引擎完全相容 Oracle 的 Read Committed 和 Serializable 隔離級别。OceanBase 的事務處理采用的也是多版本并發控制的方案，DML 語句的修改不是在資料項上直接生效，而是以一個新版本的形式寫入，同時保留舊版本的資料。
OceanBase 中的每一個事務有兩種版本号，一個是讀取使用的版本号，另一個是送出版本号。讀取使用的版本号叫做“讀版本号”或者“快照版本号”，對于讀取的每一行資料，即使行上有新的修改，讀取操作依然要找到快照版本号所對應的資料項。事務的送出版本号是在事務送出時産生，本事務的所有修改資料都會被标記上這個“送出版本号”。
Read Committed 與 Serializable 兩種隔離級别的不同在于“讀版本号”的生成邏輯。Read Committed 為了實作讀到已經送出的資料，事務内每條語句會取目前系統的最新版本号，保證讀取操作不會遺漏讀取所在事務開啟後才送出的其他事務所做的修改。Serializable 隔離級别是在事務開始時擷取了”讀版本号“後，整個事務不會再變化，保證了整個事務都會見到資料庫的同一個快照狀态。
舉個例子來說明兩者的特性。下圖示範在 Read Committed 隔離級别下，事務内可以見到别的事務修改完成的資料。
下圖示範在 Serializable 隔離級别下，事務内不能見到别的事務修改完成的資料。
Session 1 的 SELECT 語句是 Serializable 隔離級别，使用事務開啟時擷取的“讀版本号”，不會讀到後續事務的修改(3,3)
應用如何選擇 Read Committed 還是 Serializable 隔離級别沒有一招鮮的政策，需要從實際需要出發。通常來說，Read Committed 可以滿足大部分應用場景的需求。同時，Serializable 隔離級别為了支援事務級别的快照能力，可能會引發更大機率事務排程異常，最終導緻并發的事務執行無法滿足可串行化隔離級别，出現復原。下面的例子描述了一種無法串行化的報錯。
功能二：實時一緻的複制表
OceanBase 的分布式架構從本質上決定了資料被分散在不同的機器上分别服務，SQL 語句執行時會根據所操作資料的位置生成最優的執行計劃，或在一台機器或在多台機器運作 SQL 的執行計劃。
雖然 SQL 引擎會根據最優的政策來優化執行的開銷和執行的時間，但是涉及多台機器資料的操作時，跨機器之間的資料傳輸很多時候不可避免。例如很多業務中存儲關鍵資訊的配置表，還有金融業務中存儲匯率資訊的表。
這類表格内的資料被頻繁通路，通過網絡被反複的傳輸到各台機器上，帶來的開銷有時很大，而這種開銷可以通過“複制表”功能來優化。複制表将需要被頻繁通路的資料複制到叢集的每一台機器上，反複的操作不需要再跨機傳輸資料。
TPC-C 測試模型中有一張商品（ITEM）表，這張表的内容是測試所模拟的銷售公司所有售賣的商品資訊，包含了商品的名字、價格等資訊。“訂單建立”事務執行中需要請求這張表内的資料來确定訂單的價格資訊，這樣的商品表也是複制表可以優化的典型場景。
将資料複制到多機帶來的最大挑戰是對于資料的修改要在所有機器上實時生效，否則一部分機器讀到新的資料另一部分讀到舊的資料，這一定是不滿足使用者需求的功能。OceanBase 使用特殊的廣播協定保證複制表的副本一緻性，當複制表發生修改時，所有的副本會同時修改。并且，隻有在所有機器上的副本都修改成功時，修改操作才會生效。
在分布式系統中，另一個棘手的問題又會出現，如果複制表修改的過程中有機器出現故障，故障機器上的複制表的副本無法修改，那麼複制表就再也不能改了嗎？如果不解決這個問題，複制表在出現機器故障時就會拖累使用者的操作。
OceanBase 采用了租約機制來解決這個難題。每台機器上有效的複制表副本都會獲得租約，當複制表修改時，修改要同步到所有有租約的副本。如果出現機器故障，故障機器上的複制表副本的租約會失效，失效的副本不會被同步新的修改，是以不會阻塞複制表後續的修改操作。失效的副本同時會拒絕讀取操作，保證不會讀到舊的資料。當失效副本恢複後，可以追趕遺漏的資料，等其追趕到最新狀态後會被重新授予租約。
功能三：指定快照版本查詢
OceanBase 事務引擎的多版本并發控制機制是通過修改操作産生新的資料版本來實作，這個機制除了可以解決事務并發控制的需求，還能夠支援其他很多功能，比如指定快照版本查詢的能力可以用于檢視曆史資料，相容 Oracle 的 Flashback Query 功能。
使用者可以在 SELECT 語句中使用 AS OF 關鍵字來指定需要讀取的曆史版本，支援使用 SCN 和 TIMESTAMP 兩種方式。使用 SCN 指定事務送出版本号，使用 TIMESTAMP 指定一個具體的時間戳。而 OceanBase 允許使用者回溯的曆史時間通過 UNDO_RETENTION 變量來指定，OceanBase 會保留 UNDO_RETENTION 時間内的所有曆史版本。
下面是一個使用方式的樣例。
指定快照版本查詢的功能在很多場景都有用，OceanBase 的資料導出工具内就使用了此功能來提供一緻的快照導出能力。導出工具會在開始時确定導出事務版本号，在之後讀取資料時均使用 SELECT AS OF 語句指定版本号讀取，那麼所有導出的資料都是資料庫内的一個快照版本狀态。
總結
OceanBase 2.2版本是相容 Oracle 的重要裡程碑版本，也是完成 TPC-C 測試的重要版本。事務引擎在功能和性能上都做了進一步的更新，可以更好地滿足業務對于資料的需求。未來，随着商業化的程序不斷加速，OceanBase 事務引擎還會在功能和性能兩方面繼續全速前進。
立即申請免費體驗OceanBase 2.2版本
「 OceanBase 2.2 版本 」正式上線官網啦！OceanBase 2.2版本是成功支撐2019年天貓雙11大促的穩定版本，同時也是用于TPC-C測試且榮登TPC-C性能榜首的版本。OceanBase 2.2版本除了在螞蟻金服和網商銀行廣泛使用外，目前也在部分金融機構中使用。
想要立即體驗「OceanBase 2.2版本」？
免費擷取連結：
https://oceanbase.alipay.com/download/resource如果你在安裝和使用的過程中遇到問題且希望跟OceanBase一線專家進行技術交流，加入OceanBase技術交流釘釘群，打開釘釘搜尋群号：21949783（備注：OB 2.2） 即可加入。
我們非常重視來自每一位開發者使用者的體驗和心得，希望能夠獲得你們的寶貴回報。