## 關于Saga的一些認識 在說明BeetlSQL如何實現Saga事務前，有必要說明一下Saga的概念。Saga初期是長事務的解決方案，微服務流行后也可以為微服務提供事務解決方案。不同于傳統的數據庫事務或者2階段提交，必須·依賴于數據庫系統實現ACID事務，Saga不依賴于特定系統（實際上也不可能讓所有系統實現ACID，比如Redis，Mongdb），只要求特定系統能提供補償操作，在出錯的時候能執行補償操作即可。因此可以很方便用在現代的微服務架構中。 > 一個長事務的例子，如訂購電影票，分為選座位和支付倆個步驟。用戶可能會花好幾分鐘才能能完成。另一個例子是下單旅游產品，需要酒店，飛機，旅行社各個系統協作。 關于Saga，我認為最好的文章是 https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/saga/saga，因為他即告訴你什么是Saga。也告訴你Saga不完美的地方。 因此Saga的核心是補償操作以及執行這些操作的任務的管理。下面列舉了一些目前我認為的現在一些Saga框架實現的缺點 * 補償操作需要手動編寫，這工作量不小，而且容易寫錯，需要仔細審核代碼 * 有些框架能自動根據SQL產生逆向SQL，這有效減少了編寫補償的工作。但解析SQL和生成逆向SQL的難度非常大，會成為Saga框架的主要難點 * 現在幾乎所有的Saga框架將要改變編寫微服務調用方式，因為Saga提倡通過消息調用來實現服務調用和補償操作。不符合編寫業務代碼習慣，還是期望能在編寫微服務的時候，像傳統事務編程模式那樣，微服務業務代碼嵌套在一個Saga事務開始，提交或者回滾即可 * 幾乎所有的框架都要實現進行Saga編排，即Saga事務里那些微服務調用必須事先編排（配置）。這非常不靈活，因為業務時刻在變化。非常有可能升級了業務代碼，卻忘記重新編碼。 程序員期望能像普通編寫業務代碼那樣而不需要實現編排配置 BeetlSQL的Saga實現試圖解決上述問題。讓微服務編程變得跟簡單。