DRDS 是阿里云提供的一款分布式數據庫產品，它的原型是在阿里內部使用了 10 年的數據庫中間件 TDDL。DRDS 在 TDDL 提供的數據切分和 SQL 路由能力上，強化了分布式查詢，事務和水平擴容能力。

什么是柔性事務？

在分布式數據庫中，數據存儲在多個節點將引入兩個問題：

• 分布式事務 - 業務需要更新多個節點的數據。
• 全局二級索引 - 查詢無法準確的定位數據位于哪個節點。

由于全局二級索引的同步依賴于事務，因此 分布式事務 是所有分布式數據庫產品都需要解決的核心問題。這一問題的關鍵是 —— 數據存儲在多個節點，原本在單機數據庫上不難實現的 ACID 特性在分布式環境下變得困難：

因為網絡通信的不可靠，事務的原子性需要用多次日志和網絡通信來保證。

存儲節點的增加，放大了單個存儲節點在事務過程中出現故障的風險。

用鎖實現的事務隔離性，在故障或網絡抖動時嚴重影響性能。

因此，在高可用與高性能的應用場景，分布式事務的最佳實踐是放棄 ACID，遵循 BASE 的原則重構業務流程：

區別于 ACID 特性的數據庫事務，這種放棄強一致性，采取最終一致方式執行的分布式事務稱為 “柔性事務” (Flexible Transactions)。

在阿里巴巴，“柔性事務” 已經是重構分布式事務的標準方法，覆蓋了商品、交易、支付各個大規模應用場景，并且經受了雙十一的考驗。阿里內部最常用的柔性事務方案有 “消息事務” 與 “TCC 事務” (Try / Confirm / Cancel)，它們的基本原理是一致的：

將業務中的分布式事務分解成一個個在獨立分庫上執行的子事務。

用異步重試的方式執行這些子事務，由框架或應用保證重試的 “冪等”(相同的業務邏輯不會被重復執行)。

如果需要回滾，以同樣方式執行另一組子事務組成的補償操作，恢復事務前的業務狀態。

柔性事務放棄了隔離性，減小了事務中鎖的粒度，使得應用能夠更好的利用數據庫的并發性能，實現吞吐量的線性擴展。異步執行方式可以更好的適應分布式環境，在網絡抖動、節點故障的情況下能夠盡量保障服務的可用性 (Availability)。因此在高可用、高性能的應用場景，柔性事務是最佳的選擇。

但是，現有的柔性事務方案都存在一個共同問題：它們是以框架或者中間件的形式存在，應用需要付出較大的改造成本：

框架和中間件的接口帶來了學習成本。

用戶需要理解一些概念(例如 “可靠消息” “冪等”)才能正確的使用。

需要業務流程去適配工具，應用不但在架構上要大幅調整，而且還影響業務流程的直觀性。

有沒有更好的方案？

有。 DRDS / TDDL 在新發布的 5.3 版本開始提供兩種類型的分布式事務：柔性事務 (FLEXIBLE) 和兩階段提交事務 (XA)。前者將柔性事務與傳統數據庫的使用方式相結合，提供了簡單易用、低成本、高性能的 DRDS 分布式事務功能。

使用 DRDS 柔性事務

開啟 DRDS 柔性事務只需要一行代碼：

除了一行代碼，DRDS 柔性事務的使用方法和普通事務完全相同：應用首先用 SET autocommit = 0和 SET drds_transaction_policy = 'flexible' 開啟柔性事務；然后在同一個會話中執行事務的 SQL 語句 —— 最后當應用發起 commit 或 rollback 后，DRDS 將保證這些 SQL 語句執行的原子性：全部成功，或者全部失敗。

相比 TCC 或消息事務, DRDS 不需要業務編寫補償操作的回滾語句。DRDS 會根據事務中 SQL 語句的語義，自動生成相應的補償操作。

例如，如果業務執行的是一條典型的資金扣減操作：

DRDS 會自動生成對應的反向退款操作：

由于柔性事務的弱隔離性，應用通常會擔心：提交失敗后，異步回滾操作是否會覆蓋并發的更新，造成 "Lost update" 或者 “回滾覆蓋” 問題。在傳統 TCC 或消息事務中，回滾覆蓋問題需要由應用引入狀態、版本號、或樂觀鎖機制來規避。

DRDS 柔性事務則使用了一些創新的方式來解決這個問題：

1. 增量回滾

前面的例子已經展示了增量回滾是如何工作的：如果 DRDS 識別應用的 UPDATE 語句中包含 “增量操作”，例如：balance = balance - 100，則會在回滾語句中使用 balance = balance + 100 進行補償。由于增量操作的結果與順序無關，即使事務異步回滾，也不會覆蓋任何一筆業務的更新結果。

增量操作的定義是 UPDATE 語句符合以下格式：

增量回滾對賬戶、積分、庫存這樣的字段非常有用，而這些字段又通常是需要用分布式事務嚴格保證一致性的關鍵數據。建議在應用中盡量對這一類字段采用 “增量操作” 的方式更新，既節省了一次數據庫操作(SELECT)，又避免了柔性事務 “回滾覆蓋” 的風險。

2. 關鍵事務

另一個防止回滾覆蓋的方法是 “關鍵事務”。

在 DRDS 柔性事務中，應用第一次在事務內執行的 DML(INSERT/UPDATE/DELETE) 操作被放入 “關鍵事務” 內執行。在柔性事務的執行流程中，“關鍵事務” 總是第一個開始，最后一個提交。

DRDS “關鍵事務” 的執行機制與單機事務相同，不需要記錄補償操作，也不需要異步回滾。因此，把具有回滾覆蓋風險的 UPDATE 操作放入 “關鍵事務” 內執行，是一個防止異步回滾的好方法。

“關鍵事務” 的設計，可以讓一個 DRDS 單機事務自然切換到分布式事務。在傳統的柔性事務方案中，應用需要識別業務場景是不是存在分布式事務，然后再根據場景采用不同的事務方式。而 DRDS 的特殊設計，可以做到開啟柔性事務，執行單機事務也不產生任何額外代價。

3. 后置執行

第三個方法是使用 “后置執行” 優化事務流程，防止產生回滾。

DRDS 提供了一個全新的 SQL 執行方式：“后置執行”。用來優化分布式事務中不影響業務最終執行結果的跨庫操作。在分布式事務理論中，這一類優化被稱為 “Best Efforts 1PC”：

使用 “后置執行” 非常簡單，只需要在 SQL 語句的頭部加入 /*TDDL:DEFER*/:

UPDATE account SET balance = balance + 100 WHERE id = 123

DRDS 保證后置執行的 SQL 僅僅執行一次，不需要應用關心出錯重試或者冪等的問題。

“后置執行” 將事務中同步執行的操作轉移至異步執行，減少了分布式事務中持有鎖的時間，提高了事務執行的并行度，因此可以很好的提升分布式事務的性能。同時，由于 “后置執行” 用異步重試替代了回滾，它也是解決回滾覆蓋問題的另一個方法。

使用 DRDS XA 事務

新版本 DRDS 也支持 XA 事務，在柔性事務的基礎上提供了強一致能力。

DRDS XA 事務使用兩階段提交協議 (XA Protocol) 保護子事務的提交與回滾，消除了柔性事務的異步回滾問題。由于 XA Protocol 在提交與回滾階段始終加鎖，避免了事務結束前的臟讀和覆蓋，但是對性能有較大影響。

“后置執行” 功能在 DRDS XA 事務中同樣可用，能夠減少 XA 協議中的鎖，提供了進一步的性能優化空間。

由于 MySQL XA 實現機制的限制，我們建議只有在 DRDS 后端是 MySQL 5.7 版本以上才啟用 XA 事務功能。

低成本、高性能

從穩定性和成本出發，DRDS 柔性事務不引入額外的服務和存儲節點，而是利用后端的 RDS/MySQL 存儲事務日志和回滾信息。在實現上，DRDS 盡可能的減少了事務過程中的數據傳輸和日志開銷，以提升分布式事務的性能。

使用 sysbench 壓測工具表明，在標準的 8core 16G 規格 DRDS 實例上，開啟柔性事務可以達到 9000 QPS 的優異性能。相比不開啟事務的 sysbench 壓測結果，性能差異不到 10%.

小結

從分布式事務的原理出發，最終一致的 “柔性事務” 與提供 ACID 保證的 “強一致事務” 是兩個獨立的發展方向。前者實現了更高的水平擴展能力與性能，代價是應用需要付出額外的開發成本；后者提供了強一致的數據訪問和更好的開發體驗，但存在性能上的限制。

作為行業領先的云原生分布式數據庫，DRDS 同時在兩個方向拓展產品的邊界：

• 降低應用使用 “柔性事務” 的開發成本。
• 持續創新，提升 “強一致事務” 的性能和擴展性。

DRDS 新版本提供的分布式事務功能(柔性事務以及 XA 事務)正是第一階段的成果。

未來的 DRDS 產品將為企業用戶提供更多、更好的選擇：作為基礎的 “強一致事務”、標準的全局事務隔離級別、基于分布式 MVCC 的一致性讀、以及為高性能應用提供的 “柔性事務” 。在默認配置下，DRDS 將提供標準的事務 ACID 保證，以及高于業界水準的性能；而應用只需要付出較少的代價，就可以適配 DRDS 的特性，獲得更高的水平擴展能力和性能保證。

喜歡的小伙伴，點個關注吧，每天分享新的內容！

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的事务对性能影响_DRDS 柔性事务漫谈的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。