轉(zhuǎn)載鏈接：https://mp.weixin.qq.com/s/MxS1VUF7021V-3uZF1piYA
深耕HikariCP、數(shù)據(jù)庫領(lǐng)域的公眾號

在分布式數(shù)據(jù)庫、云原生數(shù)據(jù)庫、NewSQL 等名詞在數(shù)據(jù)庫領(lǐng)域?qū)映霾桓F的當(dāng)今，變革——在這個(gè)相對穩(wěn)定的領(lǐng)域已愈加不可避免。相比于完全革新，漸進(jìn)式增強(qiáng)的方案在擁有厚重沉淀的行業(yè)則更受青睞。

同所有分布式領(lǐng)域的解決方案相同，分而治之的透明化數(shù)據(jù)分片方案，是新一代數(shù)據(jù)庫解決海量數(shù)據(jù)的核心理念。水平拆分使得分布式事務(wù)的重要性，較之垂直拆分的業(yè)務(wù)系統(tǒng)進(jìn)一步提升。另外，彈性擴(kuò)（縮）容、HTAP 等概念也是新一代數(shù)據(jù)庫的關(guān)注重點(diǎn)。京東數(shù)科開源的 Apache ShardingSphere 在數(shù)據(jù)分片方面已逐漸成熟，在此場景之上開發(fā)的分布式事務(wù)中間件 JDTX 與之共同組成了分布式數(shù)據(jù)庫的內(nèi)核拼圖。

JDTX 是由京東數(shù)科的數(shù)據(jù)研發(fā)團(tuán)隊(duì)傾力打造的分布式事務(wù)中間件。本次分享是 JDTX 首次公開出現(xiàn)在大眾視野面前，分享內(nèi)容涵蓋 JDTX 的核心設(shè)計(jì)理念及相關(guān)的技術(shù)實(shí)現(xiàn)難點(diǎn)，希望能為打造分布式事務(wù)解決方案的團(tuán)隊(duì)提供一些思路。

這本新書也介紹了關(guān)于Apache ShardingSphere的內(nèi)容：

背景

數(shù)據(jù)庫事務(wù)需要滿足 ACID（原子性、一致性、隔離性、持久性）4 個(gè)特性。

在單一數(shù)據(jù)節(jié)點(diǎn)中，事務(wù)僅限于對單一數(shù)據(jù)庫資源的訪問控制，稱之為本地事務(wù)。幾乎所有的成熟的關(guān)系型數(shù)據(jù)庫都提供了對本地事務(wù)的原生支持。但是在基于微服務(wù)的分布式應(yīng)用環(huán)境下，越來越多的應(yīng)用場景要求對多個(gè)服務(wù)的訪問及其相對應(yīng)的多個(gè)數(shù)據(jù)庫資源能納入到同一個(gè)事務(wù)當(dāng)中，分布式事務(wù)應(yīng)運(yùn)而生。

關(guān)系型數(shù)據(jù)庫雖然對本地事務(wù)提供了完美的 ACID 原生支持。但在分布式的場景下，它卻成為系統(tǒng)性能的桎梏。如何讓數(shù)據(jù)庫在分布式場景下滿足 ACID 的特性或找尋相應(yīng)的替代方案，是分布式事務(wù)的重點(diǎn)工作。

本地事務(wù)

在不開啟任何分布式事務(wù)管理器的前提下，讓每個(gè)數(shù)據(jù)節(jié)點(diǎn)各自管理自己的事務(wù)。它們之間沒有協(xié)調(diào)以及通信的能力，也并不互相知曉其他數(shù)據(jù)節(jié)點(diǎn)事務(wù)的成功與否。本地事務(wù)在性能方面無任何損耗，但在強(qiáng)一致性以及最終一致性方面則力不從心。

兩階段提交

XA 協(xié)議最早的分布式事務(wù)模型是由 X/Open 國際聯(lián)盟提出的 X/Open Distributed Transaction Processing（DTP）模型，簡稱 XA 協(xié)議。

基于 XA 協(xié)議實(shí)現(xiàn)的分布式事務(wù)對業(yè)務(wù)侵入很小。它最大的優(yōu)勢就是對使用方透明，用戶可以像使用本地事務(wù)一樣使用基于 XA 協(xié)議的分布式事務(wù)。XA 協(xié)議能夠嚴(yán)格保障事務(wù) ACID 特性。

嚴(yán)格保障事務(wù) ACID 特性是一把雙刃劍。事務(wù)執(zhí)行在過程中需要將所需資源全部鎖定，它更加適用于執(zhí)行時(shí)間確定的短事務(wù)。對于長事務(wù)來說，整個(gè)事務(wù)進(jìn)行期間對數(shù)據(jù)的獨(dú)占，將導(dǎo)致對熱點(diǎn)數(shù)據(jù)依賴的業(yè)務(wù)系統(tǒng)并發(fā)性能衰退明顯。因此，在高并發(fā)的性能至上場景中，基于 XA 協(xié)議兩階段提交類型的分布式事務(wù)并不是最佳選擇。

柔性事務(wù)

如果將實(shí)現(xiàn)了 ACID 的事務(wù)要素的事務(wù)稱為剛性事務(wù)的話，那么基于 BASE 事務(wù)要素的事務(wù)則稱為柔性事務(wù)。BASE 是基本可用、柔性狀態(tài)和最終一致性這 3 個(gè)要素的縮寫。

在 ACID 事務(wù)中對一致性和隔離性的要求很高，在事務(wù)執(zhí)行過程中，必須將所有的資源占用。柔性事務(wù)的理念則是通過業(yè)務(wù)邏輯將互斥鎖操作從資源層面上移至業(yè)務(wù)層面。通過放寬對強(qiáng)一致性和隔離性的要求，只要求當(dāng)整個(gè)事務(wù)最終結(jié)束的時(shí)候，數(shù)據(jù)是一致的。而在事務(wù)執(zhí)行期間，任何讀取操作得到的數(shù)據(jù)都有可能被改變。這種弱一致性的設(shè)計(jì)可以用來換取系統(tǒng)吞吐量的提升。Saga 和 TCC 都是典型的柔性事務(wù)實(shí)現(xiàn)方案。

結(jié)論

基于 ACID 的兩階段事務(wù)和基于 BASE 的最終一致性事務(wù)都不是銀彈，可通過下表詳細(xì)對比它們之間的區(qū)別。

? ? ? ? ? ? ? ? 兩階段提交? ? ? ? ? ?柔性事務(wù)

業(yè)務(wù)改造? ? ? ? 無? ? ? ? ? ? ? ? ? 實(shí)現(xiàn)相關(guān)接口

一致性? ? ? ? ? 支持? ? ? ? ? ? ? ? ? 最終一致

隔離性? ? ? ? ? ?支持? ? ? ? ? ? ? ? 業(yè)務(wù)方保證

并發(fā)性能? ? ? 嚴(yán)重衰退? ? ? ? ? ? ?略微衰退

適合場景? ? ?短事務(wù) & 低并發(fā)? ? ? ?長事務(wù) & 高并發(fā)

缺乏并發(fā)度保障的兩階段事務(wù)不能稱之為完善的分布式事務(wù)解決方案；而缺乏對 ACID 原義支持的柔性事務(wù)都甚至不能稱之為數(shù)據(jù)庫事務(wù)，它更適合服務(wù)層的事務(wù)處理。

放眼當(dāng)前，實(shí)難找到無需權(quán)衡即可放之四海而皆準(zhǔn)的分布式事務(wù)解決方案。

JDTX 的分布式事務(wù)解決方案

JDTX 的設(shè)計(jì)目標(biāo)是強(qiáng)一致（支持 ACID 的事務(wù)原義）、高性能（甚至強(qiáng)于本地事務(wù)）、1PC（完全摒棄兩階段提交和兩階段鎖）的完全分布式事務(wù)中間件，目前可用于關(guān)系型數(shù)據(jù)庫。它采用完全開放 SPI 的設(shè)計(jì)方式，提供與 NoSQL 對接的可能，能夠?qū)⒍嘣悩?gòu)數(shù)據(jù)維持在同一事務(wù)中。

設(shè)計(jì)理念

首先通過一張架構(gòu)圖來直觀的了解一下 JDTX 的構(gòu)成。

JDTX 由事務(wù)管理器（TM）和資源管理器（RM）組成。

事務(wù)管理器用于生成全局單調(diào)遞增的事務(wù)日志序列號（LSN），事務(wù)的提交和回滾等核心流程處理，以及未提交事務(wù)的本地元祖（Tuple）持有。

資源管理器用于管理活躍事務(wù)數(shù)據(jù)。JDTX 的設(shè)計(jì)特點(diǎn)是將在事務(wù)中的數(shù)據(jù)（稱之為活躍數(shù)據(jù)）和不在事務(wù)中的數(shù)據(jù)（稱之為落盤數(shù)據(jù)）分離?；钴S數(shù)據(jù)在落盤至預(yù)寫日志系統(tǒng)（WAL）之后，并將數(shù)據(jù)保存至自研的多版本快照（MVCC）內(nèi)存引擎中。落盤數(shù)據(jù)則是通過異步刷盤的方式，將 MVCC 引擎中的數(shù)據(jù)以流量可控的方式同步至最終的存儲介質(zhì)中（如：關(guān)系型數(shù)據(jù)庫）。

事務(wù)內(nèi)查詢會將落盤數(shù)據(jù)和活躍數(shù)據(jù)合并，并根據(jù)當(dāng)前事務(wù)的隔離級別獲取出符合當(dāng)前事務(wù)可見性的數(shù)據(jù)版本。

方案亮點(diǎn)

無損事務(wù)方案

JDTX 采用 WAL + MVCC 引擎的方式實(shí)現(xiàn)了事務(wù)的 ACID 原義。

原子性 & 一致性支持

JDTX 的 MVCC 引擎可以看做是一個(gè)集中式緩存，可以將兩階段提交簡化至一階段提交。維持單一節(jié)點(diǎn)中數(shù)據(jù)的原子性和一致性，即將分布式事務(wù)的范疇縮減到本地事務(wù)的范疇。

MVCC 引擎可以通過分片 + 主從同步的方式維持水平擴(kuò)展和高可用的能力。JDTX 保證所有對事務(wù)數(shù)據(jù)的訪問都通過 MVCC 引擎的活躍數(shù)據(jù) + 最終數(shù)據(jù)端的落盤數(shù)據(jù)的合并的方式，以保證數(shù)據(jù)的原子性和一致性。

隔離性支持

JDTX 以多版本快照的方式實(shí)現(xiàn)事務(wù)隔離性。目前完整的支持 4 種標(biāo)準(zhǔn)隔離級別中的讀已提交和可重復(fù)讀，已經(jīng)可以滿足絕大部分需求。

持久性支持

JDTX 將事務(wù)的活躍數(shù)據(jù)在存入 MVCC 引擎之前先落盤至 WAL 引擎，以保證服務(wù)器崩潰，內(nèi)存數(shù)據(jù)丟失時(shí)，活躍數(shù)據(jù)依然能夠從 WAL 引擎中完全恢復(fù)。

高性能

JDTX 采用將活躍數(shù)據(jù)異步刷盤至數(shù)據(jù)庫的方式極大的提高了數(shù)據(jù)寫入的性能上限。它的性能瓶頸從數(shù)據(jù)庫寫入耗時(shí)轉(zhuǎn)移到了落盤至 WAL 引擎和存儲至 MVCC 引擎的耗時(shí)。

與數(shù)據(jù)庫的 WAL 系統(tǒng)類似，JDTX 的 WAL 也采用日志順序追加的方式，因此可以簡單的理解為 JDTX 的 WAL 耗時(shí) = 數(shù)據(jù)庫系統(tǒng)的 WAL 耗時(shí)。而 MVCC 緩存則采用哈希數(shù)據(jù)結(jié)構(gòu)，其寫入耗時(shí)小于需要維護(hù) BTree 索引的數(shù)據(jù)庫寫入耗時(shí)。因此，采用 JDTX 的事務(wù)方案，其數(shù)據(jù)更新性能甚至強(qiáng)于不開啟事務(wù)。

另外，JDTX 采取了無 UNDO 日志的事務(wù)回滾策略。未提交的數(shù)據(jù)并不會進(jìn)入 MVCC 引擎，而是被事務(wù)管理器本地持有。因此，只要清理掉未提交數(shù)據(jù)即可完成事務(wù)回滾。無 UNDO 日志的設(shè)計(jì)進(jìn)一步的提升了事務(wù)處理的性能。

高可用

WAL 引擎和 MVCC 引擎均采用分片 + 主備的方式，以保證 JDTX 不會產(chǎn)生單點(diǎn)故障。在 MVCC 引擎完全不可用的情況下，可通過恢復(fù)模式將 WAL 中的數(shù)據(jù)同步至數(shù)據(jù)庫，以保證數(shù)據(jù)的完整性。

跨多元數(shù)據(jù)庫事務(wù)

JDTX 將事務(wù)活躍數(shù)據(jù)和落盤數(shù)據(jù)分離的設(shè)計(jì)方案，使其落盤數(shù)據(jù)存儲端無任何限制。所有的事務(wù)活躍數(shù)據(jù)都會通過異步的落盤執(zhí)行器存儲至后端數(shù)據(jù)庫，因此后端是否為同構(gòu)數(shù)據(jù)庫，其實(shí)并無影響。

使用 JDTX 能夠保證跨多元存儲端（如：MySQL、PostgreSQL 甚至是 MongoDB、Redis 等 NoSQL）的分布式事務(wù)維持在同一事務(wù)語義之中。

實(shí)現(xiàn)難點(diǎn)

MVCC 內(nèi)核

事務(wù)隔離級別有兩種常見的實(shí)現(xiàn)方案，即鎖實(shí)現(xiàn)和 MVCC 實(shí)現(xiàn)。除了 Infomix 等少數(shù)數(shù)據(jù)庫，大部分關(guān)系型數(shù)據(jù)庫均采用 MVCC 實(shí)現(xiàn)。

讀未提交、讀已提交、可重復(fù)讀和可序列化這 4 種事務(wù)隔離級別的標(biāo)準(zhǔn)，是 ANSI 所定義的基于鎖實(shí)現(xiàn)的方式。事務(wù)的并行度隨著隔離級別的增加而衰減，除了并發(fā)度最低的可序列化，其他隔離級別都伴隨著對一致性的權(quán)衡和犧牲。

下表是基于鎖實(shí)現(xiàn)的隔離級別對照表。

隔離級別? ? ? ? ? ? ? ?臟讀? ? ? ? ? ? ? ? ?不可重復(fù)讀? ? ? ? ? ? 幻讀

讀未提交? ? ? ? ? ? ? ? 可能? ? ? ? ? ? ? ? ? ? ? 可能? ? ? ? ? ? ? ? ?可能

讀已提交? ? ? ? ? ? ? ?不可能? ? ? ? ? ? ? ? ? ? 可能? ? ? ? ? ? ? ? ?可能

可重復(fù)讀? ? ? ? ? ? ? ?不可能? ? ? ? ? ? ? ? ? ? 不可能? ? ? ? ? ? ? 可能

可序列化? ? ? ? ? ? ? ?不可能? ? ? ? ? ? ? ? ? ? 不可能? ? ? ? ? ? 不可能

通過 MVCC 實(shí)現(xiàn)的隔離級別實(shí)際上只有 SI（快照隔離）和 SSI（可序列化快照隔離）這 2 種。SI 和 SSI 與 ANSI 的 4 種隔離級別并不能完全對照。其中的讀未提交，與讀已提交在 MVCC 的實(shí)現(xiàn)中性能并無差別，可以忽略不計(jì)。因此 SI 可以對應(yīng)為讀已提交和可重復(fù)讀這 2 種隔離級別。實(shí)際上，即使是幻讀，在 SI 隔離級別中也是不會出現(xiàn)的。

由于快照并發(fā)控制并不能真正意義上保證事務(wù)是“可串行化”的，所以事務(wù)間的并發(fā)操作依舊有可能引發(fā)數(shù)據(jù)異?，F(xiàn)象。但這里的異常不同于之前提到的臟讀、丟失更新的異常，而是一種業(yè)務(wù)數(shù)據(jù)間邏輯語義層面的異常，也可以說是由于未能滿足數(shù)據(jù)間的語義約束而產(chǎn)生的異常。這被稱之為寫偏序（Write skew），它的檢測可依據(jù)并發(fā)事務(wù)間讀寫依賴的多版本可串行化圖（The multiversion serialization graph）來實(shí)現(xiàn)，即 SSI 隔離級別。

下表是基于 MVCC 實(shí)現(xiàn)的隔離級別對照表。

隔離級別? ? ? ? ? ? ? 臟讀? ? ? ? ?不可重復(fù)讀? ? ? ? ? 幻讀? ? ? ? ? ? ? ?寫偏序

讀未提交? ? ? ? ? ?無需實(shí)現(xiàn)? ? ? ? 無需實(shí)現(xiàn)? ? ? ? ?無需實(shí)現(xiàn)? ? ? ?無需實(shí)現(xiàn)

讀已提交? ? ? ? ? ? ?不可能? ? ? ? ? ? ?可能? ? ? ? ? ? ? 可能? ? ? ? ? ? ? ? 可能

可重復(fù)讀? ? ? ? ? ? 不可能? ? ? ? ? ? ? 不可能? ? ? ? ? 不可能? ? ? ? ? ?可能

可序列化? ? ? ? ? ? ?不可能? ? ? ? ? ? ? 不可能? ? ? ? ? 不可能? ? ? ? ?不可能

自研 MVCC 引擎是 JDTX 的主要難點(diǎn)之一。JDTX 采用與 PostgreSQL 類似的 MVCC 實(shí)現(xiàn)方案，通過 xmin 和 xmax 標(biāo)記事務(wù)快照范圍，并在 MVCC 引擎中保存每個(gè)數(shù)據(jù)元祖（Tuple）的 xmin 和 xmax 的事務(wù)信息。同一數(shù)據(jù)的多版本以鏈表的數(shù)據(jù)結(jié)構(gòu)存儲，通過其 xmin 和 xmax 來獲取數(shù)據(jù)的版本在當(dāng)前事務(wù)快照中的可見性。

由于 MySQL 也并未實(shí)現(xiàn) SSI 隔離級別，因此目前的 JDTX 只是實(shí)現(xiàn)了 SI 隔離級別，還并未實(shí)現(xiàn) SSI 隔離級別。

MVCC 數(shù)據(jù)的清理（vacuum）是另一技術(shù)難點(diǎn)。過長的事務(wù)會導(dǎo)致 MVCC 版本過多，導(dǎo)致占用大量存儲空間。尤其是 JDTX 是通過內(nèi)存來存儲 MVCC 的活躍數(shù)據(jù)，因此對內(nèi)存空間的釋放則更加敏感。由于 JDTX 的異步落盤機(jī)制，因此除了 MVCC 標(biāo)準(zhǔn)的垃圾回收邏輯之外，判斷數(shù)據(jù)是否落盤成為清理邏輯的額外規(guī)則。

SQL 查詢引擎

通過 SQL 查詢事務(wù)的活躍數(shù)據(jù)，是 JDTX 的另一個(gè)技術(shù)實(shí)現(xiàn)難點(diǎn)。MVCC 引擎并非關(guān)系型數(shù)據(jù)庫，并不能通過識別 SQL 來查詢相關(guān)數(shù)據(jù)。JDTX 則通過之前 Apache ShardingSphere 所積累的 SQL 解析模塊及其抽象語法樹（AST）來實(shí)現(xiàn)對 SQL 的理解，以及查詢基于內(nèi)存的 MVCC 引擎中的數(shù)據(jù)。

對于 SPJ（select-project-join）的 OLTP 類型 SQL，可以從 SQL 的查詢結(jié)果中獲取數(shù)據(jù)主鍵。JDTX 將落盤數(shù)據(jù)從后端數(shù)據(jù)庫中取出作為最終展現(xiàn)數(shù)據(jù)的基礎(chǔ)，并在此之上從 MVCC 引擎中查詢出當(dāng)前事務(wù)可見的活躍數(shù)據(jù)，并對其結(jié)果進(jìn)行歸并。換句話說，每次事務(wù)內(nèi)查詢都是由落盤數(shù)據(jù) + 活躍數(shù)據(jù)歸并而成。歸并引擎部分參照了 LSM Tree 的設(shè)計(jì)思想。

對于非 SPJ 的 OLAP 類型 SQL，JDTX 則采用另外的查詢方式?；诰酆虾瘮?shù)和分組的 SQL 無法通過主鍵直接將后端數(shù)據(jù)庫中的落盤數(shù)據(jù)和 MVCC 引擎中的鍵值數(shù)據(jù)直接匹配，因此采用以 MVCC 引擎中數(shù)據(jù)為主，并將 SQL 改寫為剔除活躍數(shù)據(jù)主鍵的新 SQL，再從后端數(shù)據(jù)庫中查詢無重復(fù)的聚合數(shù)據(jù)進(jìn)行歸并。

使用限制

分布式無銀彈，這是架構(gòu)師們對現(xiàn)有的分布式系統(tǒng)比較公認(rèn)的看法。雖然 JDTX 具備了很多優(yōu)點(diǎn)，但仍然有一些使用限制。它的使用限制主要有以下 3 點(diǎn)。

需要通過 JDTX 訪問數(shù)據(jù)庫。JDTX 通過其 MVCC 引擎控制事務(wù)的原子性、一致性和隔離性，并通過 WAL 控制事務(wù)的持久性。因此在使用 JDTX 的系統(tǒng)中，跨過事務(wù)中間件直接查詢數(shù)據(jù)庫，是得不到正確的事務(wù)數(shù)據(jù)的，修改數(shù)據(jù)庫則會導(dǎo)致數(shù)據(jù)紊亂。

SQL 支持需要持續(xù)完善。查詢 MVCC 引擎的 SQL 方言兼容則需要持續(xù)提升。相對于無損的 ACID 事務(wù)原義支持所帶來的優(yōu)勢，SQL 兼容度的下降，是 JDTX 帶來的權(quán)衡。

不支持無主鍵數(shù)據(jù)。JDTX 需要通過主鍵來合并 MVCC 引擎和數(shù)據(jù)庫中的數(shù)據(jù)。因此無法處理沒有主鍵的記錄。

JDTX 與 Apache ShardingSphere

通過 Apache ShardingSphere 提供的 JDBC 接入端，可以使 JDTX 無縫的對接至 Java 應(yīng)用。除了 JDBC 接入端，Apache ShardingSphere 也提供了基于 MySQL 和 PostgreSQL 的 Proxy 接入端，使 JDTX 像一個(gè)單獨(dú)的數(shù)據(jù)庫一樣提供分布式事務(wù)的服務(wù)。Apache ShardingSphere 將在未來將接入端剝離，使 JDTX 獨(dú)立使用成為可能。

Apache ShardingSphere 提供了分布式事務(wù)的統(tǒng)一 SPI。JDTX 通過實(shí)現(xiàn) ShardingSphere 提供的 SPI，可以很輕松的融入 Apache ShardingSphere 生態(tài)。結(jié)合 Apache ShardingSphere 與 JDTX，可以將數(shù)據(jù)分片與分布式事務(wù)無縫結(jié)合。

獨(dú)立使用 Apache ShardingSphere 或 JDTX，可以靈活解耦，高度定制，可以看做是基礎(chǔ)組件的樂高積木。而將其聯(lián)合使用，則能夠產(chǎn)生化學(xué)變化，甚至使它們具備組成分布式數(shù)據(jù)庫基礎(chǔ)設(shè)施的能力。架設(shè)在產(chǎn)品最前端的 Apache ShardingSphere 用于 SQL 解析、數(shù)據(jù)庫協(xié)議和數(shù)據(jù)分片；位于中層的 JDTX 用于通過鍵值對和 MVCC 的方式處理事務(wù)活躍數(shù)據(jù)；最底層的數(shù)據(jù)庫則僅作為最終的數(shù)據(jù)存儲端。下圖是 ShardingSphere + JDTX 的架構(gòu)圖。

最后附上 MySQL 架構(gòu)圖，請讀者自行體會其相似之處。

JDTX 的后續(xù)規(guī)劃

JDTX 的自身目標(biāo)是力爭將其打造成為一個(gè)分布式事務(wù)的標(biāo)準(zhǔn)解決方案。在事務(wù)核心流程、MVCC 引擎、WAL 引擎、高可用等核心功能打磨成熟后，JDTX 會將主要精力投放在以下幾個(gè)方面：

提升 SQL 語句兼容性以及多元數(shù)據(jù)庫支持；

實(shí)現(xiàn) SSI 隔離級別，提供完整的 MVCC 隔離級別解決方案；

完善管理端和監(jiān)控端。

除了 JDTX 中間件自身，它也將與 ShardingSphere 等其他數(shù)據(jù)庫中間件更加一體化的提供分布式數(shù)據(jù)庫級別的服務(wù)；并將與 Kubernetes 等云原生平臺更加深度整合，為云原生數(shù)據(jù)庫提供服務(wù)。

作者介紹

張亮，京東數(shù)科數(shù)據(jù)研發(fā)負(fù)責(zé)人， Apache ShardingSphere 發(fā)起人 & PPMC，JDTX 負(fù)責(zé)人。

熱愛開源，主導(dǎo)開源項(xiàng)目 ShardingSphere(原名 Sharding-JDBC) 和 Elastic-Job。擅長以 Java 為主分布式架構(gòu)，推崇優(yōu)雅代碼，對如何寫出具有展現(xiàn)力的代碼有較多研究。

目前主要精力投入在將 ShardingSphere 和 JDTX 打造為業(yè)界一流的金融級數(shù)據(jù)解決方案之上。ShardingSphere 已經(jīng)進(jìn)入 Apache 孵化器，是京東集團(tuán)首個(gè)進(jìn)入 Apache 基金會的開源項(xiàng)目，也是 Apache 基金會首個(gè)分布式數(shù)據(jù)庫中間件。

GitHub: https://github.com/terrymanu ， 隨時(shí)歡迎技術(shù)交流和指正。