分布式事务

简单阐述一下自己对分布式事物的理解，如有错误欢迎指正： 刚性事物：即ACID这里不做过多解释，有不明白的同学建议快速掌握。 柔性事物：简单来说为运行过程不一致但最终保持一致。 一、产生原因： 　　分布式(微服务)系统中之间的跨库访问(例：商城项目中的会员数据库，订单数据库，支付数据库等、、、)与同一项目多数据源不同，使用于分布式系统后类似SOA接口之间调用时产生。 二、解决原理： 1）、CAP原理(即：一致性，可用性，分区容错性) 一致性：当系统对一个数据进行写操作时成功后，在查询则必须是改动后的值，当写操作失败也就必须查不多新值，在单机项目中又叫原子性。 　　 可用性：服务可用性，就是说所有的读写请求在一定时间内要得到响应，不能一直等待下去。 　　 分区容错性：指在分布式、微服务系统中，当 部分服务宕机后，其他核心服务能够不受影响能够继续提供服务。 2）、BAS理论： 　 采用CAP演化而来，是对CAP中一致性和可用性权衡的结果，核心思想是：即使无法做到强一致性，但每个业务根据自身的特点，采用适当的方式来使系统达到最终一 　　致 性。主要有以下状态： 　　 基本可用：在分布式系统出现故障时，允许损失部分可用性，保证核心可用，例如：一个服务正常响应时间为：2秒之内，在访问量大时可采用可对部分用户进行降级处理 　　 软状态：允许系统存在中间状态，并且该状态不会允许系统整体可用性

从本地事务到分布式事务到微服务下事务 一、传统本地事务 传统单服务器，单关系型数据库下事务比较简单，完全可用很简单的实现ACID，实际中我们实现一个业务时只需要：开启一个事务-操作数据库-提交/回滚这个事务，这样就完美的实现了一次事务操作，更简单点我们通常会通过spring集成事务直接指定在哪些服务什么样的方法执行什么样的事务即可，更甚至我们业务实现基本都忽略了事务，具体图如下： 二、传统分布式事务 在传统一服务，一个关系数据库架构基础上，随着访问量的增大，单机很明显已满足不了现状，于是我们顺其自然的就考虑到了服务集群部署，数据库分库分表，从而也就实现了这样一个样子，如图： 解释：服务水平扩展，数据库分库分表压力是将下来了，但同时也来了另一个问题，如果我一次请求中同时操作了多个DB这个时候我们的传统事务模式（一）就已经不行了，于是我们就在网上各种搜，终于找到了一个叫2PC（二阶段提交）的东西，具体操作如图： 大概意思： 在最外层有一个事务管理器（TM）来控制整个事务，一个请求过来， 第一阶段：事务管理器通知各个资源管理器（RM）准备提交事务，这时我们处理完业务各个RM准备完毕后给TM一个响应（业务正常/异常） 第二阶段：1、如果反馈TM业务正常那么TM会通知RM可提交事务，如果异常，通知回滚事务 大概就是这个意思，具体可百度 三、微服务下事务 分布式系统，随着业务的不断增加

谈谈业务中使用分布式的场景 首先，需要了解系统为什么使用分布式。 随着互联网的发展，传统单工程项目的很多性能瓶颈越发凸显，性能瓶颈可以有几个方面： 1.应用服务层：随着用户量的增加，并发量增加，单项目难以承受如此大的并发请求导致的性能瓶颈。 2.底层数据库层：随着业务的发展，数据库压力越来越大，导致的性能瓶颈。 #场景1：应用系统集群的 Session 共享 应用系统集群最简单的就是服务器集群，比如：Tomcat 集群。应用系统集群的时候，比较凸显的问题是 Session 共享，Session 共享我们一是可以通过服务器插件来解决。另外一种也可以通过 Redis 等中间件实现。 #场景2：应用系统的服务化拆分 服务化拆分，是目前非常火热的一种方式。现在都在提微服务。通过对传统项目进行服务化拆分，达到服务独立解耦，单服务又可以横向扩容。服务化拆分遇到的经典问题就是分布式事务问题。目前，比较常用的分布式事务解决方案有几种：消息最终一致性、TCC 补偿型事务等。 #场景3：底层数据库的压力分摊 如果系统的性能压力出现在数据库，那我们就可以读写分离、分库分表等方案进行解决。 Session 分布式方案 #基于 nfs(net filesystem) 的 Session 共享 将共享服务器目录 mount 各服务器的本地 session 目录，session 读写受共享服务器 io 限制

微服务架构：最终一致性 + 事务补偿 分布式事务产生的原因 数据库分库分表 微服务化 在微服务架构中，每个服务在用 本地事务 的时候，知道自己执行的事务是成功还是失败，但是无法知道其他服务节点的事务执行情况，因此需要引入 协调者TM ，负责协调 参与者RM 的行为，并最终决定这些参与者是否把事务进行提交。 随着微服务架构的流行，让分布式事务问题日益突出， 那么常见的分布式事务解决方案有哪些呢？ 如何理解最终一致性和它的事务补偿机制呢？ 刚性事务 - 强一致性 如上图，这是个标准的全局事务， 事务管理器 控制着全局事务，管理事务的生命周期，并通过XA协议与 资源管理器 协调资源；资源管理器负责控制和管理实际的资源 （这里的资源管理器，可以是一个DBMS，或者消息服务管理系统） 两阶段提交 它是XA用于在全局事务中协调多个资源的机制，常用于 事务管理器 和 资源管理器 之间，解决一致性问题，分两阶段： 提交事务请求 执行事务请求 2PC的问题 效率低，与本地事务相比，XA协议的系统开销比较大（数据被锁定的时间跨度整个事务，直到全局事务的结束），只有支持XA协议的资源才能参与分布式事务。 2PC是反可伸缩模式的，在事务处理过程中，参与者需要一直持有资源直到整个事务的结束，这样当业务规模越来越大的情况下，它的局限性就越明显。 数据不一致，在2pc中的第二阶段时，当TM向RM发送提交请求之后

摘要： 阿里妹导读：阿里巴巴的电商业务十分复杂，一方面是市场多样化，业务多样化，另外是消费者，商家的影响面非常广，任何一个小故障都可能引发一些社会问题，所以阿里对产品的质量，对服务的连续性有严格的要求。阿里技术人员在日常的研发运维过程中，积累了丰富的实战经验。 阿里妹导读：阿里巴巴的电商业务十分复杂，一方面是市场多样化，业务多样化，另外是消费者，商家的影响面非常广，任何一个小故障都可能引发一些社会问题，所以阿里对产品的质量，对服务的连续性有严格的要求。阿里技术人员在日常的研发运维过程中，积累了丰富的实战经验。今天，阿里妹将为大家分享一个关于故障，排查，分析和改进的真实案例。他山之石可以攻玉，希望对广大开发和运维工程师带来帮助。 背景说明 某日，做产品X的开发接到客户公司电话，说是对账出了1分钱的差错，无法处理。本着“客户第一”的宗旨，开发立马上线查看情况。查完发现，按照产品X当日的年化收益率，正常情况下用户在转入57元后一共收益3分钱，合计是57.03元。但是该客户当日却有一笔消费57.04元，导致客户公司系统对多出的1分钱处理不了。再进一步分析，发现用户收益结转时多了1分钱的收益，并且已消费…… 也就是说，本来用户只有3分钱收益，结果多发了1分钱给他，也就给公司造成1分钱的损失！用户在产品X里当天收益本应该是0.03元，怎么会变成0.04元呢？多出的1分钱收益从哪里来的呢？

一，复制，对数据进行备份，实现搞可用，提高吞吐量，实现高性能。 　　1，主从架构 　　2，多主架构 　　3，主主从从 　　4，主备 （实际用得多） 二，分片/分库分表 （） 1，垂直拆分 　　1，垂直分表 　　2，垂直分库 　　 如果做垂直分库，应该把有关联的表放在同一个库中，因为数据库的事务不能跨库，不能使用inner join, order_by ,等链接查询，只能分次数查询，在应用端在合并。 2，水平拆分 　　1，水平分表 　　2，水平分库分表 　　3，分布式id 　需求：水平分表后，需要保证多表id冲突问题 　雪花算法：1bit + 时间戳41 + 机器id10 序列号12 　id 取模运算 分布式事务 ： 在一个事务不能完成的情况下， 核心：二阶段提交协议（简称2PC协议/XA协议） 问题：会出现事务等待情况，增加死锁的机率 基于状态/消息的最终一致性方案（使用较多） 悲观锁： 　　开发者主动设置 乐观锁： 　　先不加锁（假设没有并发），但更新前校验数据的一致性，手动代码实现（先查在更新） 　　 来源： https://www.cnblogs.com/wjun0/p/11881212.html

Eureka、Consul、Zookeeper的基本原理与比较。 前言 在云计算和容器化技术发展火热的当下，对于微服务架构，服务注册与发现组件是必不可少的。在传统的服务架构中，服务的规模处于运维人员的可控范围内。当部署服务的多个节点时，一般使用静态配置的方式实现服务信息的设定。在微服务应用中，服务实例的数量和网络地址都是动态变化的，这对系统运维提出了巨大的挑战。因此，动态的服务注册与发现就显得尤为重要。 解决的问题 在一个分布式系统中，服务注册与发现组件主要解决两个问题：服务注册和服务发现。 服务注册：服务实例将自身服务信息注册到注册中心。这部分服务信息包括服务所在主机IP和提供服务的Port，以及暴露服务自身状态以及访问协议等信息。 服务发现：服务实例请求注册中心获取所依赖服务信息。服务实例通过注册中心，获取到注册到其中的服务实例的信息，通过这些信息去请求它们提供的服务。 除此之外，服务注册与发现需要关注监控服务实例运行状态、负载均衡等问题。 监控：微服务应用中，服务处于动态变化的情况，需要一定机制处理无效的服务实例。一般来讲，服务实例与注册中心在注册后通过心跳的方式维系联系，一旦心跳缺少，对应的服务实例会被注册中心剔除。 负载均衡：同一服务可能同时存在多个实例，需要正确处理对该服务的负载均衡。 CAP CAP原则，指的是在一个分布式系统中，Consistency(一致性)

atomikos支持一个分布式事务，结合spring，可以很好的满足一个应用访问多个库的需要。 atomikos 结合spring做配置也很简单 1.配置datasource <!-- 第一个数据库 --> <bean id="dataSource" class="com.atomikos.jdbc.SimpleDataSourceBean" init-method="init" destroy-method="close"> <property name="uniqueResourceName" value="mysql/main" /> <property name="xaDataSourceClassName" value="com.mysql.jdbc.jdbc2.optional.MysqlXADataSource" /> <property name="xaDataSourceProperties" value="URL=${jdbc.url.a};user=${jdbc.username.a};password=${jdbc.password.a}" /> <property name="exclusiveConnectionMode" value="true" /> <property name="connectionPoolSize" value="10" />

它是一个全面的、企业应用开发一站式的解决方案，贯穿表现层、业务层、持久层。但是 Spring 仍然可以和其他的框架无缝整合。 6.1.1. Spring 特点 6.1.1.1. 轻量级 6.1.1.2. 控制反转 6.1.1.3. 面向切面 6.1.1.4. 容器 6.1.1.5. 框架集合 6.1.7. Spring IOC 原理 6.1.7.1. 概念 Spring 通过一个配置文件描述 Bean 及 Bean 之间的依赖关系，利用 Java 语言的反射功能实例化 Bean 并建立 Bean 之间的依赖关系。 Spring 的 IoC 容器在完成这些底层工作的基础上，还提供 了 Bean 实例缓存、生命周期管理、 Bean 实例代理、事件发布、资源装载等高级服务 6.1.7.2. Spring 容器高层视图 Spring 启动时读取应用程序提供的 Bean 配置信息，并在 Spring 容器中生成一份相应的 Bean 配 置注册表，然后根据这张注册表实例化 Bean，装配好 Bean 之间的依赖关系，为上层应用提供准 备就绪的运行环境。 其中 Bean 缓存池为 HashMap 实现 6.1.7.3. IOC 容器实现 BeanFactory-框架基础设施 BeanFactory 是 Spring 框架的基础设施，面向 Spring 本身； ApplicationContext

https://www.cnblogs.com/wupeixuan/p/9302496.html 第一章主要讲的是分布式架构，主要包含以下内容： 集中式的特点 分布式的特点 分布式环境的各种问题 ACID 分布式事务 CAP和BASE理论 1 | 1 集中式与分布式的特点 集中式的特点：部署结构简单（因为基于底层性能卓越的大型主机，不需考虑对服务多个节点的部署，也就不用考虑多个节点之间分布式协调问题） 分布式的特点： 分布性 对等性 并发性 缺乏全局时钟 故障总是会发生 1 | 2 分布式环境的各种问题 分布式环境的各种问题： 通信异常：主要是因为网络本身的不可靠性 网络分区：当网络发生异常时，导致部分节点之间的网络延时不断增大，最终导致部分节点可以通信，而另一部分节点不能。 三态（成功、失败与超时） 节点故障：组成分布式系统的服务器节点出现宕机或“僵死”现象 1 | 3 ACID与分布式事务 事务是由一系列对系统中数据进行访问与更新的操作所组成的一个程序执行逻辑单元，狭义上的事务特指数据库事务。 事务有四个特性，分别是原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability），简称为事务的ACID特性。 原子性（Atomicity）：必须是一个原子的操作序列单元，只允许出现两种状态之一（全部成功执行，全部不执行）。