## 关于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实现试图解决上述问题。让微服务编程变得跟简单。