Direct Exchange(直连交换机)所有发送到 Direct Exchange 的消息被转发到 RouteKey 中指定的 Queue。 也就是消息中的 Routing Key 如果和 Binding Key 一致，Direct Exchange 则将消息发到对应的 queue 中通过 Routing Key 为 naicha 的路由键发送消息给交换机，交换机会去查找 Binding Key 也是 naicha 的队列，而与 naicha 绑定的队列是 milktea...

1. AMQP协议生产者（Producer）：发送消息的应用。 消费者（Consumer）：接收消息的应用。 队列（Queue）：存储消息的缓存，一个队列queue存多条消息。 消息（Message）：由生产者通过RabbitMQ发送给消费者的信息，消息存储在消息队列queue中。 连接（Connection）：连接RabbitMQ和应用服务器的TCP连接（上图中发送消息和接收消息都是必须先建立连接的）。 通道（Channel）：连接里的一个虚拟通道。当你通过消息队列发送或者...

...

循环依赖产生原因在创建B类的Bean的过程中，如果B类中存在一个A类的a属性，那么在创建B的Bean的过程中就需要A类对应的Bean，但是，触发B类Bean的创建的条件是A类Bean在创建过程中的依赖注入，所以这里就出现了循环依赖：ABean创建-->依赖了B属性-->触发BBean创建--->B依赖了A属性--->需要ABean（但ABean还在创建过程中）从而导致ABean创建不出来，BBean也创建不出来。三级缓存：singletonObject...

主要是分两部分new SpringApplication(primarySource).run(args)，一部分是前面的对象，一部分是run。SpringApplication(primarySource)：确定web应用类型加载ApplicationContextInitializer加载ApplicationListener确定主启动类run():准备Environment对象打印Banner实例化IOC容器准备容器，为容器设置environment，BeanFacto...

Seata TCC 模式回顾总览中的描述：一个分布式的全局事务，整体是 两阶段提交 的模型。全局事务是由若干分支事务组成的，分支事务要满足 两阶段提交 的模型要求，即需要每个分支事务都具备自己的：一阶段 prepare 行为二阶段 commit 或 rollback 行为根据两阶段行为模式的不同，我们将分支事务划分为 Automatic (Branch) Transaction Mode 和 TCC (Branch) Transaction Mode.AT 模式基于 支持本地...

前提支持XA 事务的数据库。Java 应用，通过 JDBC 访问数据库。整体机制在 Seata 定义的分布式事务框架内，利用事务资源（数据库、消息服务等）对 XA 协议的支持，以 XA 协议的机制来管理分支事务的一种事务模式。执行阶段：可回滚：业务 SQL 操作放在 XA 分支中进行，由资源对 XA 协议的支持来保证 可回滚持久化：XA 分支完成后，执行 XA prepare，同样，由资源对 XA 协议的支持来保证 持久化（即，之后任何意外都不会造成无法回滚的情况）完成阶段：...

前提基于支持本地 ACID 事务的关系型数据库。Java 应用，通过 JDBC 访问数据库。整体机制两阶段提交协议的演变：一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。二阶段： 提交异步化，非常快速地完成。回滚通过一阶段的回滚日志进行反向补偿。写隔离一阶段本地事务提交前，需要确保先拿到 全局锁 。拿不到 全局锁 ，不能提交本地事务。拿 全局锁 的尝试被限制在一定范围内，超出范围将放弃，并回滚本地事务，释放本地锁。以一个示例来说明：两个全局事务 t...

著作权归@pdai所有 原文链接：https://pdai.tech/md/arch/arch-z-transection.html什么是分布式事务事务是一个程序执行单元，里面的所有操作要么全部执行成功，要么全部执行失败。在分布式系统中，这些操作可能是位于不同的服务中，那么如果也能保证这些操作要么全部执行成功要么全部执行失败呢？这便是分布式事务要解决的问题。以一个网上的经典下单减库存例子为例：单体应用所有的业务都使用一个数据库，整个下单流程或许只用在一个方法里同一个事务下操作...

在高并发场景的架构里，幂等性是必须得保证的。比如说支付功能，用户发起支付，如果后台没有做幂等校验，刚好用户手抖多点了几下，于是后台就可能多次受到同一个订单请求，不做幂等很容易就让用户重复支付了，这样用户是肯定不能忍的。解决方案：1，查询和删除不在幂等讨论范围，查询肯定没有幂等的说，删除：第一次删除成功后，后面来删除直接返回0，也是返回成功。2，建唯一索引：唯一索引或唯一组合索引来防止新增数据存在脏数据 （当表存在唯一索引，并发时新增异常时，再查询一次就可以了，数据应该已经存在...