@Willem Jiang，多谢。我回头会试试看。 2018-03-14 22:46 GMT+08:00 Willem Jiang <willem.ji...@gmail.com>: > 首先应用App启动时候，如果版本信息（应用名 + 版本号）发生变化可以通过Omega通知Alpha。 > 这样就不不会出现版本执行错误的情况。 > > 对于你举的1.0 升级到 2.0 的情况可能需要通过优雅停机的方式来解决了。 > 因为App 1.0 可能会有多个实例， Alpha在执行回滚的过程中如果只通过Omega来回调的话很难解决实例突然终止的问题， > 我现在想到的办法是让Alpha直接调用App 1.0提供的恢复服务接口。 > 如果App1.0的服务接口是幂等的且无状态的话，那我们还是能够做到事务的最终一致。 > > > > > Willem Jiang > > Blog: http://willemjiang.blogspot.com (English) > http://jnn.iteye.com (Chinese) > Twitter: willemjiang > Weibo: 姜宁willem > > On Wed, Mar 14, 2018 at 9:20 AM, Daniel Qian <chanjars...@gmail.com> wrote: > >> Thanks a lot, Willem Jiang, 关于Q7我举个例子来说明我的意思： >> >> App version 1.0 里的Saga是这样的：call methodA, call methodB >> App version 2.0 里的代码是这样的：call methodA, call methodC >> >> 把App从1.0 升级到 2.0必定需要将原1.0的App进程停止，然后启动2.0的App进程。 >> 在停止1.0的App进程的时候，可能会出现Saga只执行了一半。 >> >> 那么启动2.0的App进程之后，会出现以下哪种情况： >> >> 1. 1.0 App的未执行完成的Saga永远保持未完成状态 >> 2. 会Saga Alpha会尝试使用2.0App的代码，继续执行未完成Saga >> >> 2018-03-13 22:52 GMT+08:00 Willem Jiang <willem.ji...@gmail.com>: >> > 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 >> >> >> >> >> >> -- >> >> >> >> Daniel Qian >>
-- Daniel Qian
