SAGA

分布式系统下，分布式数据库遇到的挑战 　　分布式系统下，当访问关系型数据库的i/o占用过高，内存不足，访问过慢的情况下，可以考虑流流行的分库分表的策略，但是这样也会到来很多新的技术挑战。 1.分布式事务 　　当还是单体应用，单体数据库时，完全不需要考虑事务的一致性问题，因为mysql已经帮我们处理事务问题(ACID)，但是这只是针对单体情况下，如果是多个数据库，主从备份，读写分离，那么就会可能造成事务不一致的情况，那么什么事分布式事务，分布式 　　事务又该如何解决呢？ 　　 　　1.有关于事务的概念 　　　　本地事务：本地事务的优点就是支持严格的ACID特性，高效，可靠，状态可以只在资源管理器中维护，而且应用编程模型简单。 　　　　全局事务：当事务由全局事务管理器进行全局管理时成为全局事务，事务管理器负责管理全局的事务状态和参与的资源，协同资源的一致提交回滚。 　　　　两阶段事务：两阶段事务提交采用的是X/OPEN组织所定义的 DTP模型 ，通过抽象出来的 AP , TM , RM 的概念可以保证事务的强一致性。 其中 TM 和 RM 间采用 XA 的协议进行双向通信。 与传统的本地事务相比， 　　　　　　　　　　XA事务增加了prepare阶段，数据库除了被动接受提交指令外，还可以反向通知调用方事务是否可以被提交。 因此 TM 可以收集所有分支事务的prepare结果

微服务兴起的这几年涌现出不少分布式事务框架，比如ByteTCC、TCC-transaction、EasyTransaction以及最近很火爆的Seata。最近刚看了Seata的源码（v0.5.2），借机记录一下自己对分布式事务的一些理解。（3年前这类框架还没成熟，因项目需要自己也写过一个柔性事务框架）。 本文分五部分，首先明确分布式事务概念的演变，然后简单说下为什么大家不用XA，第三部分阐述两阶段提交的“提升”，第四部分介绍Seata的架构的亮点与问题，第五部分谈下分布式事务的取舍。 限于篇幅一些网上可搜索的细节本文不展开阐述（例如XA、Saga、TCC、Seata等原理的的详细介绍）。 一、分布式事务的泛化 提起分布式事务，最早指涉及的是多个资源的数据库事务问题。 wiki对分布式事务的定义：A distributed transaction is a database transaction in which two or more network hosts are involved. 不过事务一词含义随着SOA架构逐渐扩大，根据上下文不同，可分为两类： System transaction； Business transaction。 前者多指数据库事务，后者则多对应一个业务交易。 与此同时，分布式事务的含义也在泛化，尤其SOA、微服务概念流行起来后，多指的是一个业务场景

i use NServiceBus as enterprise Service Bus, in the solution i'm developing i have an orchestration service which receives up to 10k messages from all client applications. I would like to improve the architecture performance and consequently enhance the solution provided. I use a Saga Data class and i would like to share the access to it between all worker threads(up to now i set just to one thread but i want to set at least to 10), what happens when multiple threads try to access the same saga istance? Does NSB already provide such a concurrency feature? Do i have to implement it on my own?

Following this example: https://msdn.microsoft.com/en-us/library/jj591569.aspx (Figure 3) How it fits in a http application? The user should perform a http request to the PlaceOrderController, which will send a PlaceOrderCommand, but how would the Order Process Manager answers the "9. Order Confirmed" to the user? How is the controller aware of that, in order to return this info to the user? Thanks You simply don't answer "Order Confirmed" immediately. Take a look at how Amazon and other shopping sites do it: Upon Order submission, you just receive an "Order Accepted confirmation (e.g., HTTP

I have 2 microservices S1 and S2 . S1 invokes S2 to update a data and then S1 inserts another data,But let's consider S1 fails,Then we need to rollback the data updated by S2 or else we'll be in inconsistent state. I also gone through Saga patterns.will it satisfy this inconsistency Can anyone suggest any better solutions for this? Distributed transactions are problematic for most circumstances and they are bad for services Service Boundary – service boundary is a trust boundary. Atomic transactions require holding locks and holding them on behalf of foreign service is opening a security hole

在分布式系统下，可以很多种架构从事设计，或者分布式系统对技术架构本身没有做严格的限制。但是结合自己的实践以及基于《领域驱动设计》的推荐， 采用 【事件驱动模式】是比较好的一种分布式系统架构方式。该模式充分实现了 不同系统之间的代码解耦，所有的业务流转是通过事件广播进行驱动的。所有业务都是在针对 名为【事件总线】的组件在编程，也无需知道事件的生产者，每个业务只监听自己感兴趣的事件，然后根据事件触发不同的业务代码 以及 自己在处理完某种业务后，也对外广播发出事件，则标志着当前业务的完成。 基于【事件驱动模式】是一种比较接近人类自然行为的一种模式，该模式给系统的解耦以及重构带来了先天优势。相对比与传统的业务模式，大量的业务流程都是基于代码或者是某种规则引擎加以实现，而 事件驱动模式 则是针对事件总线注册监听， 【事件总线】总是能够忠实的把消息投递给感兴趣的监听者，并且保证其对应业务逻辑的自然触发。一旦有业务变动，我们仅仅是在【事件总线】上增加 或者 移除对应的事件消费者，或者注册新的事件发布者，这种行为并没有影响到当前的业务代码变动。 用日常通俗讲法：更加接近于 小学老师讲课，老师常常会不自觉的吼一声：“小朋友们，记住了吗？”这时，这要是听到该咨询的小朋友 都会回应道：“听懂了”，在此过程中 ，声音作为事件、空气作为事件总线（忠实的传递事件到达监听者），如果这个时候

I have written an Event Sourced Aggregate and now implemented an Event Sourced Saga... I have noticed the two are similair and created an event sourced object as a base class from which both derive. I have seen one demo here http://blog.jonathanoliver.com/cqrs-sagas-with-event-sourcing-part-ii-of-ii/ but feel there may be an issue as Commands could be lost in the event of a process crash as the sending of commands is outside the write transaction? public void Save(ISaga saga) { var events = saga.GetUncommittedEvents(); eventStore.Write(new UncommittedEventStream { Id = saga.Id, Type = saga

不知道你是否遇到过这样的情况，去小卖铺买东西，付了钱，但是店主因为处理了一些其他事，居然忘记你付了钱，又叫你重新付。 又或者在网上购物明明已经扣款，但是却告诉我没有发生交易。这一系列情况都是因为没有事务导致的。这说明了事务在生活中的一些重要性。 有了事务，你去小卖铺买东西，那就是一手交钱一手交货。有了事务，你去网上购物，扣款即产生订单交易。 在进入正文之前，顺便给大家推荐一个Java架构方面的交流学习群： 725633148 ，里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化这些成为架构师必备的知识体系。相信对于已经工作和遇到技术瓶颈的同学，在这个群里会有你需要的内容。有需要的同学请抓紧时间加入进来。 事务的具体定义 事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元，组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交，只要其中任一操作执行失败，都将导致整个事务的回滚。 简单地说，事务提供一种“要么什么都不做，要么做全部（All or Nothing）”机制。 数据库本地事务 ACID 说到数据库事务就不得不说，数据库事务中的四大特性 ACID： A：原子性(Atomicity)，一个事务(transaction)中的所有操作，要么全部完成，要么全部不完成

可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效，请关闭广告屏蔽插件后再试): 问题: What I understand is that all three concepts are related to long-running transactions. A process manager is, to my understanding, a finite state machine which simply reacts on events and emits commands. It does not contain any business logic, it just does routing. Its goal is to bring you to a final state, where you know that your transaction has succeeded or failed. So far, so good. But now my problems in understand start: What is a saga in contrast to a process manager? There is also the document-based approach, as mentioned in CQRS sagas