Hi Dainiel Here are my answer to you question， we will write an english version for it shortly.
1. Saga的执行是同步的还是异步的？发起Saga之后，是等所有Sub-transaction都完成才返回，还是立即返回？ 目前Saga事情的执行是同步的，后续我们会提供异步方式的实现。 2. Saga是并行还是顺序执行Sub-transaction的？ Saga pack 是根据调用的代码来决定Saga事件，如果Saga子事件是并行方式调用的， 那Saga协调器也是采用并行方式进行处理的。 3. Saga对于do、compenstation的实现有什么要求？ 对服务调用要求是要支持幂等的。 4. Saga保证了A、C、I、D中的哪些部分？ 按照前面的回复， Saga 支持 ACD。 5. Saga可以嵌套吗？ Saga实现支持子事件嵌套的方式。 6. 如何水平扩展Saga Alpha？ Saga Alpha在设计过程中状态信息都存储到数据库，是支持水平扩展的。 7. Saga omega 处的代码重构时需要注意什么，以保证不会破坏原Saga/还未执行完毕的Saga？ Saga omega只是通过切面编程的方式获取Saga调用事件，并触发对应的处理流程。 我不太明白你说的Saga omega处的代码重构是什么意思？解释一下吗？ 8. Saga omega 在执行Saga过程中如果中断，那么重启后Saga还会继续执行吗？ Saga协调管理的的服务调用如果支持幂等， 调用过程完成后重启Saga协调器 Alpha之后，是可以支持Saga恢复的。 9. 对于@SagaStart，@Compensable注释的方法，对其方法参数有何要求？ 因为omega将记录Compensable标注的方法的调用参数来调用Compensable里面提供的补偿方法， 这些参数需要能够序列化。 目前对于SagaStart没有什么特别的要求， Willem Jiang Blog: http://willemjiang.blogspot.com (English) http://jnn.iteye.com (Chinese) Twitter: willemjiang Weibo: 姜宁willem On Tue, Mar 13, 2018 at 2:33 PM, Daniel Qian <chanjars...@gmail.com> wrote: > Hi Willem Jiang, thanks for your reply. > > I'd like to help listing a FAQ for this project, but for now, I can > only provide Qs not As. Here is my Qs (sorry written in Chinese to > avoid poor english obscure the meaning): > > 1. Saga的执行是同步的还是异步的？发起Saga之后，是等所有Sub-transaction都完成才返回，还是立即返回？ > 2. Saga是并行还是顺序执行Sub-transaction的？ > 3. Saga对于do、compenstation的实现有什么要求？ > 4. Saga保证了A、C、I、D中的哪些部分？ > 5. Saga可以嵌套吗？ > 6. 如何水平扩展Saga Alpha？ > 7. Saga omega 处的代码重构时需要注意什么，以保证不会破坏原Saga/还未执行完毕的Saga？ > 8. Saga omega 在执行Saga过程中如果中断，那么重启后Saga还会继续执行吗？ > 9. 对于@SagaStart，@Compensable注释的方法，对其方法参数有何要求？ > > Hi Zheng Feng, thanks for your reply, too. > > I watched Richardson's presentation > (https://www.infoq.com/presentations/saga-microservices) and he talked > about ACD: > > A：all sub-transaction are executed OR all are compensated > C：local consistency is handled by service. cross-service consistency > is handled by application > D：durability is handled by local database > > These definitions are a little different from which defined in > traditional transactions (https://en.wikipedia.org/wiki/ACID). > > So I think even though "traditional transaction" and "distributed > transaction" are all called "transactions", but they are different > things. > > Unlike traditional transaction ACID are guaranteed by techs such as JTA, > XA. > > In distributed transactions(Saga, TCC, etc) ACD are guaranteed by > service/application code. > > So this ACID is not that ACID (此ACID非彼ACID), this transaction is not > that transaction(此事务非彼事务). > > I think we can clarify that in the doc. > > 2018-03-12 18:05 GMT+08:00 Zheng Feng <zh.f...@gmail.com>: > > Well, that could be an interesting question. I think it depends on how > you > > define what is "all or nothing". For a example of booking which is often > > used in the Saga transaction. > > The request of the user is that "WE HAVE TO BOOKING A FLIGHT PEK-SHA AND > > TWO NIGHTS IN SHANGHAI HOTEL" > > > > 1. Start a Saga transaction > > 2. booking a flight > > 3. booking a hotel > > 4a. ALL bookings are OK ( We get "all") > > 4b. booking a hotel is failed, we have to compensate to cancel the flight > > (We get "nothing") > > 5. End a Saga transaction > > > > So from the user's perspective, they get "all or nothing" and from the > > database it could have something changed ( the status of the flight > booking > > order). And I think this is why the Saga pattern relax the "ISOLATION" > > attribute from the ACID. > > > > I hope it could be helpful for you to understand the Saga transaction. > > > > 2018-03-12 16:47 GMT+08:00 Daniel Qian <chanjars...@gmail.com>: > > > >> Thanks for reply. > >> > >> I'll checkout refs you give. Saga project is really really lack of docs, > >> hope you guys will work on that. > >> > >> And 1 more question. > >> > >> The wiki says Atomicity: > >> > >> > Atomicity requires that each transaction be **"all or nothing"**: if > one > >> part of the transaction fails, then the entire transaction fails, and > the > >> database state is left **unchanged**. > >> > >> I think the Saga's do-compensate pattern is not "all or nothing", > database > >> is not left "unchanged", there is actually something changed(ie. a > canceled > >> order) in database (saga event log database or microservice database). > >> > >> 2018-03-10 10:56 GMT+08:00 Eric Lee <eric.lee....@gmail.com>: > >> > >> > Well, Saga actually provides guarantee of ACD. You can checkout Chris > >> > Richardson's > >> > latest talk of saga[1] for details. In the original saga paper[2], it > >> > mentions that > >> > > >> > > At the outer level full atomicity is not provided. That is, sagas > may > >> > view > >> > > the partial results of other sagas. > >> > > > >> > According to the ACID definition[3], it shows saga does not provide > >> > isolation guarantee instead of atomicity as all sub transactions > within a > >> > global transaction is either done or compensated. > >> > > >> > For each global transaction, it will have both SagaStartedEvent and > >> > SagaEndedEvent while for each sub transaction, it will have > >> TxStartedEvent > >> > and either TxEndedEvent or TxCompensatedEvent. If the global > transaction > >> > succeeds, saga guarantees that all sub transactions will have both > >> > TxStartedEvent and TxEndedEvent. If the global transaction fails, saga > >> > guarantees that all completed sub transactions are compensated and > hence > >> > have all of TxStartedEvent, TxEndedEvent, TxCompensatedEvent. In this > >> way, > >> > we can guarantee the consistency. > >> > > >> > Besides, the implementation of saga coordinator is stateless, all saga > >> > event logs are stored in persistent storage. In this way, we can > >> guarantee > >> > the durability. > >> > > >> > BTW, we have refactored the saga lately. The architecture in the blog > you > >> > saw is outdated. You can checkout its latest implementation from [4]. > If > >> > you have any questions or advice for our new architecture, welcome to > >> point > >> > them out. > >> > > >> > [1] https://www.infoq.com/presentations/saga-microservices > >> > [2] https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf > >> > [3] https://en.wikipedia.org/wiki/ACID > >> > [4] https://github.com/apache/incubator-servicecomb-saga > >> > > >> > > >> > Best Regards! > >> > Eric Lee > >> > > >> > 2018-03-09 15:59 GMT+08:00 Daniel Qian <chanjars...@gmail.com>: > >> > > >> > > Hello guys: > >> > > > >> > > I read the amazing blog "Eventual Data Consistency Solution in > >> > ServiceComb > >> > > - part 2" and I'm kind of confused about these two statements: > >> > > > >> > > > Saga does not provide ACID guarantee, because atomicity and > isolation > >> > are > >> > > not satisfied .... > >> > > > >> > > > With durable saga log, saga guarantees consistency and durability > >> > > > >> > > I guess the first statement is talking about how so called > >> "Transaction" > >> > > behaves in **Saga pattern**. > >> > > > >> > > And the second statement is talking about the implementation of > Saga's > >> > > state store. But that's a little strange to say "Saga provides C > and D > >> > > because it's state store provides C and D". > >> > > > >> > > I think Saga pattern actually does not guarantee either of A, C, I > or > >> D. > >> > Am > >> > > I right? > >> > > > >> > > > >> > > -- > >> > > > >> > > > >> > > > >> > > Daniel Qian > >> > > > >> > > >> > >> > >> > >> -- > >> > >> > >> > >> Daniel Qian > >> > > > > -- > > > > Daniel Qian >
