徹底掌握分布式事務(wù)2PC、3PC模型
公眾號 源碼興趣圈 寫的第 64 篇原創(chuàng)文章
工作中使用最多的是本地事務(wù)，但是在對單一項目拆分為 SOA、微服務(wù)之后，就會牽扯出分布式事務(wù)場景
文章以分布式事務(wù)為主線展開說明，并且針對 2PC、3PC 算法進行詳細(xì)的講解，最后通過一個 Demo 來更深入掌握分布式事務(wù)，文章目錄結(jié)構(gòu)如下
什么是事務(wù) 什么是分布式事務(wù) DTP 模型和 XA 規(guī)范
什么是 DTP 模型 什么是 XA 規(guī)范 2PC 一致性算法
2PC-準(zhǔn)備階段 2PC-提交階段 2PC 算法優(yōu)缺點 3PC 一致性算法 JDBC 操作 MySQL XA 事務(wù) 結(jié)言
什么是事務(wù)
事務(wù)是數(shù)據(jù)庫操作的最小工作單元，一組不可再分割的操作集合，是作為單個邏輯工作單元執(zhí)行的一系列操作。這些操作作為一個整體一起向系統(tǒng)提交，要么都執(zhí)行、要么都不執(zhí)行
事務(wù)具有四個特征，分別是原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）和持久性（Durability），簡稱為事務(wù)的 ACID 特性
如何保證事務(wù)的 ACID 特性？
原子性（Atomicity）：事務(wù)內(nèi) SQL 要么同時成功要么同時失敗，基于撤銷日志（undo 日志）實現(xiàn)
一致性（Consistency）：系統(tǒng)從一個正確態(tài)轉(zhuǎn)移到另一個正確態(tài)，由應(yīng)用通過 AID 來保證，可以說是事務(wù)的核心特性
隔離性（Isolation）：控制事務(wù)并發(fā)執(zhí)行時數(shù)據(jù)的可見性，基于鎖和多版本并發(fā)控制（mvcc）實現(xiàn)
持久性（Durability）：提交后一定存儲成功不會丟失，基于重做日志（redo log）實現(xiàn)
文章主要是介紹分布式事務(wù) 2PC 和 3PC，關(guān)于 redo、undo 日志、mvcc、鎖這塊的內(nèi)容后續(xù)再詳細(xì)介紹
在早些時候，我們應(yīng)用程序還是單體項目，所以操作的都是單一數(shù)據(jù)庫，這種情況下我們稱之為本地事務(wù)。本地事務(wù)的 ACID 一般都是由數(shù)據(jù)庫層面支持的，比如我們工作中常用的 MySQL 數(shù)據(jù)庫
平常我們在操作 MySQL 客戶端時，MySQL 會隱式對事務(wù)做自動提交，所以日常工作不會涉及手動書寫事務(wù)的創(chuàng)建、提交、回滾等操作。如果想要試驗鎖、MVCC等特性，可以創(chuàng)建多個會話，通過begin、commit、rollback等命令來試驗下不同事務(wù)之間的數(shù)據(jù)，看執(zhí)行結(jié)果和自己所想是否一致
我們平常開發(fā)項目代碼時使用的是 Spring 封裝好的事務(wù)，所以也不會手動編寫對數(shù)據(jù)庫事務(wù)的提交、回滾等方法（個別情況除外）。這里使用原生 JDBC 寫一個示例代碼，幫助大家理解如何通過事務(wù)保證 ACID 四大特性
Connection conn = ...; // 獲取數(shù)據(jù)庫連接
conn.setAutoCommit(false); // 開啟事務(wù)
try {
// ...執(zhí)行增刪改查sql
conn.commit(); // 提交事務(wù)
} catch (Exception e) {
conn.rollback(); // 事務(wù)回滾
} finally {
conn.close(); // 關(guān)閉鏈接
}
設(shè)想一下，每次進行數(shù)據(jù)庫操作，都要寫重復(fù)的創(chuàng)建事務(wù)、提交、回滾等方法是不是挺痛苦的，那 Spring 如何自動幫助我們管理事務(wù)的呢？Spring 項目中我們一般使用兩種方式來進行事務(wù)的管理，編程式事務(wù)和聲明式事務(wù)
項目中使用 Spring 管理事務(wù)，要么在接口方法上添加注解 @Transactional，要么使用 AOP 配置切面事務(wù)。其實這兩種方式大同小異，只不過 @Transactional 的粒度更細(xì)一些，實現(xiàn)原理上都是依賴 AOP，舉例說明下
@Service
public class TransactionalService {
@Transactional
public void save() {
// 業(yè)務(wù)操作
}
}
TransactionalService 會被 Spring 創(chuàng)建一個代理對象放入到容器中，創(chuàng)建后的代理對象相當(dāng)于下述類
public class TransactionalServiceProxy {
private TransactionalService transactionalService;
public TransactionalServiceProxy(TransactionalService transactionalService) {
this.transactionalService = transactionalService;
}
public void save() {
try {
// 開啟事務(wù)操作
transactionalService.save();
} catch (Exception e) {
// 出現(xiàn)異常則進行回滾
}
// 提交事務(wù)
}
}
示例代碼看著簡潔明了，但是真正的代碼生成代碼對比要復(fù)雜很多。關(guān)于事務(wù)管理器，Spring 提供了接口 PlatformTransactionManager，其內(nèi)部包含兩個重要實現(xiàn)類
DataSourceTransactionManager：支持本地事務(wù)，內(nèi)部通過java.sql.Connection來開啟、提交和回滾事務(wù)JtaTransactionManager：用于支持分布式事務(wù)，其實現(xiàn)了 JTA 規(guī)范，使用 XA 協(xié)議進行兩階段提交
通過這兩個實現(xiàn)類得知，平常我們使用的編程式事務(wù)和聲明式事務(wù)依賴于本地事務(wù)管理實現(xiàn)，Spring 同時也支持分布式事務(wù)，關(guān)于 JTA 分布式事務(wù)的支持網(wǎng)上資料挺多的，就不在這里贅述了
什么是分布式事務(wù)
日常業(yè)務(wù)代碼中的本地事務(wù)我們一直都在用，理解起來并不困難。但是隨著服務(wù)化（SOA）、微服務(wù)的流行，平常我們的單一業(yè)務(wù)系統(tǒng)被拆分成為了多個系統(tǒng)，為了迎合業(yè)務(wù)系統(tǒng)的變更，數(shù)據(jù)庫也結(jié)合業(yè)務(wù)進行了拆分
比如以學(xué)校管理系統(tǒng)舉例說明，可能就會拆分為學(xué)生服務(wù)、課程服務(wù)、老師服務(wù)等，數(shù)據(jù)庫也拆分為多個庫。當(dāng)這種情況，把不同的服務(wù)部署到服務(wù)器，就會有可能面臨下述的服務(wù)調(diào)用
ServiceA 服務(wù)需要操作數(shù)據(jù)庫執(zhí)行本地事務(wù)，同時需要調(diào)用 ServiceB 和 ServiceC 服務(wù)發(fā)起事務(wù)調(diào)用，如何保證三個服務(wù)的事務(wù)要么一起成功或者一起失敗，如何保證用戶發(fā)起請求的事務(wù) ACID 特性呢？無疑這就是分布式事務(wù)場景，三個服務(wù)的單一本地事務(wù)都無法保證整個請求的事務(wù)
分布式事務(wù)場景有很多種解決方案，以不同分類來看，強一致性解決方案、最終一致性解決方案，細(xì)分其中的方案包括2PC、3PC、TCC、可靠消息...
業(yè)界中使用較多的像阿里的 RocketMQ 事務(wù)消息、Seata XA模式、可靠消息模型這幾種解決方案。不過，分布式事務(wù)無一例外都是會直接或間接操作多個數(shù)據(jù)庫，而且使用了分布式事務(wù)同時也會帶來新的挑戰(zhàn)，那就是性能問題。如果為了保證強一致性分布式事務(wù)亦或者補償方案的最終一致性，導(dǎo)致了性能的下降，對于正常業(yè)務(wù)而言，無疑是得不償失的
DTP 模型和 XA 規(guī)范
X/Open 組織定義了分布式事務(wù)的模型（DTP）和 分布式事務(wù)協(xié)議（XA），DTP 由以下幾個模型元素組成
AP（Application 應(yīng)用程序）：用于定義事務(wù)邊界(即定義事務(wù)的開始和結(jié)束)，并且在事務(wù)邊界內(nèi)對資源進行操作TM（Transaction Manager 事務(wù)管理器）：負(fù)責(zé)分配事務(wù)唯一標(biāo)識，監(jiān)控事務(wù)的執(zhí)行進度，并負(fù)責(zé)事務(wù)的提交、回滾等RM（Resource Manager 資源管理器）：如數(shù)據(jù)庫、文件系統(tǒng)等，并提供訪問資源的方式CRM（Communication Resource Manager 通信資源管理器）：控制一個TM域(TM domain)內(nèi)或者跨TM域的分布式應(yīng)用之間的通信 CP（Communication Protocol 通信協(xié)議）：提供CRM提供的分布式應(yīng)用節(jié)點之間的底層通信服務(wù)
在 DTP 分布式事務(wù)模型中，基本組成需要涵蓋 AP、TM、RMS（不需要 CRM、CP 也是可以的），如下圖所示
XA 規(guī)范
XA 規(guī)范最重要的作用就是定義 RM（資源管理器）與 TM（事務(wù)管理器）之間的交互接口。另外，XA 規(guī)范除了定義 2PC 之間的交互接口外，同時對 2PC 進行了優(yōu)化
梳理下 DTP、XA、2PC 之間的關(guān)系
DTP 規(guī)定了分布式事務(wù)中的角色模型，并在其中指定了全局事務(wù)的控制需要使用 2PC 協(xié)議來保證數(shù)據(jù)的一致性
2PC 是 Two-Phase Commit 的縮寫，即二階段提交，是計算機網(wǎng)絡(luò)尤其是數(shù)據(jù)庫領(lǐng)域內(nèi)，為了保證分布式系統(tǒng)架構(gòu)下所有節(jié)點在進行事務(wù)處理過程中能夠保證原子性和一致性而設(shè)計的一種算法。同時，2PC 也被認(rèn)為是一種一致性協(xié)議，用來保證分布式系統(tǒng)數(shù)據(jù)的一致性
XA 規(guī)范是 X/Open 組織提出的分布式事務(wù)處理規(guī)范，XA 規(guī)范定義了 2PC（兩階段提交協(xié)議）中需要用到的接口，也就是上圖中 RM 和 TM 之間的交互。2PC 和 XA 兩者最容易混淆，可以這么理解，DTP 模型定義 TM 和 RM 之間通訊的接口規(guī)范叫 XA，然后 關(guān)系數(shù)據(jù)庫（比如MySQL）基于 X/Open 提出的的 XA 規(guī)范（核心依賴于 2PC 算法）被稱為 XA 方案
2PC 一致性算法
當(dāng)應(yīng)用程序（AP）發(fā)起一個事務(wù)操作需要跨越多個分布式節(jié)點的時候，每一個分布式節(jié)點（RM）知道自己進行事務(wù)操作的結(jié)果是成功或是失敗，但是卻不能獲取到其它分布式節(jié)點的操作結(jié)果。為了保證事務(wù)處理的 ACID 特性，就需要引入稱為"協(xié)調(diào)者"的組件（TM）來進行統(tǒng)一調(diào)度分布式的執(zhí)行邏輯
協(xié)調(diào)者負(fù)責(zé)調(diào)度參與整體事務(wù)的分布式節(jié)點的行為，并最終決定這些分布式節(jié)點要把事務(wù)進行提交還是回滾。所以，基于這種思想下，衍生出了二階段提交和三階段提交兩種分布式一致性算法協(xié)議。二階段指的是準(zhǔn)備階段和提交階段，下面我們先看準(zhǔn)備階段都做了什么事情
2PC-準(zhǔn)備階段
二階段提交中第一階段也叫做"投票階段"，即各參與者投票表明自身是否繼續(xù)執(zhí)行接下來的事務(wù)提交步驟
事務(wù)詢問：協(xié)調(diào)者向所有參與本次分布式事務(wù)的參與者發(fā)送事務(wù)內(nèi)容，詢問是否可以執(zhí)行事務(wù)提交操作，然后開始等待各個參與者的響應(yīng)
執(zhí)行事務(wù)：參與者收到協(xié)調(diào)者的事務(wù)請求，執(zhí)行對應(yīng)的事務(wù)，并將內(nèi)容寫入 Undo 和 Redo 日志
返回響應(yīng)：如果各個參與者執(zhí)行了事務(wù)，那么反饋協(xié)調(diào)者 Yes 響應(yīng)；如果各個參與者沒有能夠成功執(zhí)行事務(wù)，那么就會返回協(xié)調(diào)者 No 響應(yīng)
如果第一階段全部參與者返回成功響應(yīng)，那么進入事務(wù)提交步驟，反之本次分布式事務(wù)以失敗返回。以 MySQL 數(shù)據(jù)庫為例，在第一階段，事務(wù)管理器（TM）向所有涉及到的數(shù)據(jù)庫（RM）發(fā)出 prepare（準(zhǔn)備提交） 請求，數(shù)據(jù)庫收到請求后執(zhí)行數(shù)據(jù)修改和日志記錄處理，處理完成后把事務(wù)的狀態(tài)修改為 "可提交"，最終將結(jié)果返回給事務(wù)處理器
2PC-提交階段
提交階段分為兩個流程，一個是各參與者正常執(zhí)行事務(wù)提交流程，并返回 Yes 響應(yīng)，表示各參與者投票執(zhí)行成功；一個是各參與者當(dāng)中有執(zhí)行失敗返回 No 響應(yīng)或超時情況，將觸發(fā)全局回滾，表示分布式事務(wù)執(zhí)行失敗
執(zhí)行事務(wù)提交
中斷事務(wù)
執(zhí)行事務(wù)提交
假設(shè)協(xié)調(diào)者從所有的參與者獲得的反饋都是 Yes 響應(yīng)，那么就會執(zhí)行事務(wù)提交操作
事務(wù)提交：協(xié)調(diào)者向所有參與者節(jié)點發(fā)出 Commit 請求，各個參與者接收到 Commit 請求后，將本地事務(wù)進行提交操作，并在完成提交之后釋放事務(wù)執(zhí)行周期內(nèi)占用的事務(wù)資源
完成事務(wù)：各個參與者完成事務(wù)提交之后，向協(xié)調(diào)者發(fā)送 Ack 響應(yīng)，協(xié)調(diào)者接收到響應(yīng)后完成本次分布式事務(wù)
中斷事務(wù)
假設(shè)任意一個事務(wù)參與者節(jié)點向協(xié)調(diào)者反饋了 No 響應(yīng)（注意這里的 No 響應(yīng)指的是第一階段），或者在等待超時之后，協(xié)調(diào)者沒有接到所有參與者的反饋響應(yīng)，那么就會進行事務(wù)中斷流程
事務(wù)回滾：協(xié)調(diào)者向所有參與者發(fā)出 Rollback 請求，參與者接收到回滾請求后，使用第一階段寫入的 undo log 執(zhí)行事務(wù)的回滾，并在完成回滾事務(wù)之后釋放占用的資源
中斷事務(wù)：參與者在完成事務(wù)回滾之后，向協(xié)調(diào)者發(fā)送 Ack 消息，協(xié)調(diào)者接收到事務(wù)參與者的 Ack 消息之后，完成事務(wù)中斷
2PC 優(yōu)缺點
2PC 提交將事務(wù)的處理過程分為了投票和執(zhí)行兩個階段，核心思想就是對每個事務(wù)都采用先嘗試后提交的方式處理。2PC 優(yōu)點顯而易見，那就是 原理簡單，實現(xiàn)方便。簡單也意味著很多地方不能盡善盡美，這里梳理三個比較核心的缺陷
同步阻塞：無論是在第一階段的過程中，還是在第二階段，所有的
參與者資源和協(xié)調(diào)者資源都是被鎖住的，只有當(dāng)所有節(jié)點準(zhǔn)備完畢，事務(wù)協(xié)調(diào)者才會通知進行全局提交，參與者進行本地事務(wù)提交后才會釋放資源。這樣的過程會比較漫長，對性能影響比較大單點故障：
如果協(xié)調(diào)者出現(xiàn)問題，那么整個二階段提交流程將無法運轉(zhuǎn)。另外，如果協(xié)調(diào)者是在第二階段出現(xiàn)了故障，那么其它參與者將會處于鎖定事務(wù)資源的狀態(tài)中數(shù)據(jù)不一致性：當(dāng)協(xié)調(diào)者在第二階段向所有參與者發(fā)送 Commit 請求后，發(fā)生了
局部網(wǎng)絡(luò)異常或者協(xié)調(diào)者在尚未發(fā)送完 Commit 請求之前自身發(fā)生了崩潰，導(dǎo)致只有部分參與者接收到 Commit 請求，那么接收到的參與者就會進行提交事務(wù)，進而形成了數(shù)據(jù)不一致性
由于 2PC 的簡單方便，所以會產(chǎn)生上述的同步阻塞、單點故障、數(shù)據(jù)不一致等情況，所以在 2PC 的基礎(chǔ)上做了改進，推行出了三階段提交（3PC）
使用 2PC 存在諸多限制，首先就是數(shù)據(jù)庫需要支持 XA 規(guī)范，而且性能與數(shù)據(jù)一致性數(shù)據(jù)均不友好，所以 Seata 中雖然支持 XA 模式，但是主推的還是 AT 模式
3PC 一致性算法
三階段提交（3PC）是二階段提交（2PC）的一個改良版本，引入了兩個新的特性
協(xié)調(diào)者和參與者均引入超時機制，通過超時機制來解決 2PC 的同步阻塞問題，避免事務(wù)資源被永久鎖定把二階段演變?yōu)槿A段，
二階段提交協(xié)議中的第一階段"準(zhǔn)備階段"一分為二，形成了新的 CanCommit、PreCommit、do Commit 三個階段組成事務(wù)處理協(xié)議
這里將不再贅述 3PC 的詳細(xì)提交過程，3PC 相比較于 2PC 最大的優(yōu)點就是降低了參與者的阻塞范圍，并且能夠在協(xié)調(diào)者出現(xiàn)單點故障后繼續(xù)達成一致
雖然通過超時機制解決了資源永久阻塞的問題，但是 3PC 依然存在數(shù)據(jù)不一致的問題。當(dāng)參與者接收到 PreCommit 消息后，如果網(wǎng)絡(luò)出現(xiàn)分區(qū)，此時協(xié)調(diào)者與參與者無法進行正常通信，這種情況下，參與者依然會進行事務(wù)的提交
通過了解 2PC 和 3PC 之后，我們可以知道這兩者都無法徹底解決分布式下的數(shù)據(jù)一致性
JDBC 操作 MySQL XA 事務(wù)
MySQL 從 5.0.3 開始支持 XA 分布式事務(wù)，且只有 InnoDB 存儲引擎支持。MySQL Connector/J 從5.0.0 版本之后開始直接提供對 XA 的支持
在 DTP 模型中，MySQL 屬于 RM 資源管理器，所以這里就不再演示 MySQL 支持 XA 事務(wù)的語句，因為它執(zhí)行的只是自己單一事務(wù)分支，我們通過 JDBC 來演示如何通過 TM 來控制多個 RM 完成 2PC 分布式事務(wù)
這里先來說明需要引入 GAV 的 Maven 版本，因為高版本 8.x 移除了對 XA 分布式事務(wù)的支持（可能也是覺得沒人會用吧）
<dependencies>
<!-- https://mvnrepository.com/artifact/mysql/mysql-connector-java -->
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>5.1.38</version>
</dependency>
</dependencies>
這里為了保證在公眾號閱讀的舒適性，通過 IDEA 將多行代碼合并為一行了，如果小伙伴需要粘貼到 IDEA 中，格式化一下就好了
因為 XA 協(xié)議的基礎(chǔ)是 2PC 一致性算法，所以小伙伴在看代碼時可以對照上面文章講的 DTP 模型和 2PC 來進行理解以及模擬錯誤和執(zhí)行結(jié)果
import com.mysql.jdbc.jdbc2.optional.MysqlXAConnection;import com.mysql.jdbc.jdbc2.optional.MysqlXid;import javax.sql.XAConnection;import javax.transaction.xa.XAException;import javax.transaction.xa.XAResource;import javax.transaction.xa.Xid;import java.sql.*;
public class MysqlXAConnectionTest {
public static void main(String[] args) throws SQLException {
// true 表示打印 XA 語句, 用于調(diào)試
boolean logXaCommands = true;
// 獲得資源管理器操作接口實例 RM1
Connection conn1 = DriverManager.getConnection("jdbc:mysql://localhost:3306/test", "root", "root");XAConnection xaConn1 = new MysqlXAConnection((com.mysql.jdbc.Connection) conn1, logXaCommands);XAResource rm1 = xaConn1.getXAResource();
// 獲得資源管理器操作接口實例 RM2
Connection conn2 = DriverManager.getConnection("jdbc:mysql://localhost:3306/test", "root", "root");XAConnection xaConn2 = new MysqlXAConnection((com.mysql.jdbc.Connection) conn2, logXaCommands);XAResource rm2 = xaConn2.getXAResource();
// AP（應(yīng)用程序）請求 TM（事務(wù)管理器） 執(zhí)行一個分布式事務(wù), TM 生成全局事務(wù) ID
byte[] gtrid = "distributed_transaction_id_1".getBytes();int formatId = 1;
try {
// ============== 分別執(zhí)行 RM1 和 RM2 上的事務(wù)分支 ====================
// TM 生成 RM1 上的事務(wù)分支 ID
byte[] bqual1 = "transaction_001".getBytes();Xid xid1 = new MysqlXid(gtrid, bqual1, formatId);
// 執(zhí)行 RM1 上的事務(wù)分支
rm1.start(xid1, XAResource.TMNOFLAGS);PreparedStatement ps1 = conn1.prepareStatement("INSERT into user(name) VALUES ('jack')");ps1.execute();rm1.end(xid1, XAResource.TMSUCCESS);
// TM 生成 RM2 上的事務(wù)分支 ID
byte[] bqual2 = "transaction_002".getBytes();Xid xid2 = new MysqlXid(gtrid, bqual2, formatId);
// 執(zhí)行 RM2 上的事務(wù)分支
rm2.start(xid2, XAResource.TMNOFLAGS);PreparedStatement ps2 = conn2.prepareStatement("INSERT into user(name) VALUES ('rose')");ps2.execute();rm2.end(xid2, XAResource.TMSUCCESS);
// =================== 兩階段提交 ================================
// phase1: 詢問所有的RM 準(zhǔn)備提交事務(wù)分支
int rm1_prepare = rm1.prepare(xid1);int rm2_prepare = rm2.prepare(xid2);
// phase2: 提交所有事務(wù)分支
if (rm1_prepare == XAResource.XA_OK && rm2_prepare == XAResource.XA_OK) {
// 所有事務(wù)分支都 prepare 成功, 提交所有事務(wù)分支
rm1.commit(xid1, false);rm2.commit(xid2, false);
} else {
// 如果有事務(wù)分支沒有成功, 則回滾
rm1.rollback(xid1);rm1.rollback(xid2);
}
} catch (XAException e) { e.printStackTrace(); } }}
結(jié)言
本文通過圖文并茂的方式講解了如何保證本地事務(wù)的四大特性，分布式事務(wù)的產(chǎn)出背景，以及 2PC、3PC 為何不能解決分布式情況下的數(shù)據(jù)一致性，最后通過 JDBC 演示了 2PC 的執(zhí)行流程。相信大家看過后也對分布式事務(wù)有了較深的印象，同時對 DTP、XA、2PC 這幾種比較容易混淆的概念有了清楚的認(rèn)識
這是《分布式事務(wù)》專欄的第一章開篇，后面陸續(xù)完成通過消息中間件、可靠消息模型、Seata XA模型完成分布式事務(wù)的文章，并對不同的實現(xiàn)方式進行總結(jié)利弊，挑選出合適場景使用不同的分布式事務(wù)解決方案
作者認(rèn)為最好的學(xué)習(xí)方式那就是實戰(zhàn)，如果沒有接觸過分布式事務(wù)的小伙伴，可以通過自己正在寫的項目，模擬出分布式事務(wù)的業(yè)務(wù)場景，加深印象的同時也能夠更好理解分布式事務(wù)解決方案相關(guān)設(shè)計思路
創(chuàng)作不易，文章看到這里如果有所幫助，可以點個關(guān)注支持一下，祝好。我們下期見
站在巨人的肩膀
《從Paxos到Zookeeper分布式一致性原理與實踐》
《田守枝Java技術(shù)博客》
歡迎各位小伙伴添加作者好友，拉你進學(xué)習(xí)交流群。關(guān)注公眾號后回復(fù)
123領(lǐng)取內(nèi)容涵蓋 GO、Netty、Seata、SpringCloud Alibaba、開發(fā)規(guī)范、面試寶典、數(shù)據(jù)結(jié)構(gòu)等學(xué)習(xí)資料！