首先应用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 <[email protected]> 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 <[email protected]>: > > 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 <[email protected]> > 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 <[email protected]>: > >> > 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 <[email protected]>: > >> > > >> >> 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 <[email protected]>: > >> >> > >> >> > 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 <[email protected]>: > >> >> > > >> >> > > 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 >
