servicecomb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Qian <chanjars...@gmail.com>
Subject Re: A question about ACID guarantees Saga provides
Date Wed, 14 Mar 2018 01:20:35 GMT
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.jiang@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 <chanjarster@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.feng@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 <chanjarster@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.ltk@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 <chanjarster@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
Mime
View raw message