SevenCoding的博客

消息存储流程消息存储入口：DefaultMessageStore#putMessage代码：CommitLog#putMessage代码：MappedFile#appendMessagesInner代码：CommitLog#doAppend代码：CommitLog#calMsgLength代码：CommitLog#doAppend代码：CommitLog#putMessage存储文件RocketMQ通过使用内存映射文件提高IO访问性能，无论是CommitLog、ConsumerQueue还

消息中间件的设计思路一般是基于主题订阅发布的机制，消息生产者（Producer）发送某一个主题到消息服务器，消息服务器负责将消息持久化存储，消息消费者（Consumer）订阅该兴趣的主题，消息服务器根据订阅信息（路由信息）将消息推送到消费者（Push模式）或者消费者主动向消息服务器拉去（Pull模式），从而实现消息生产者与消息消费者解耦。那消息生产者如何知道消息要发送到哪台消息服务器呢？消息生产者的代码都在client模块中，相对于RocketMQ来讲，消息生产者就是客户端，也是消息的提供者。

分布式队列因为有高可靠性的要求，所以数据要进行持久化存储。Apache下开源的另外一款MQ—ActiveMQ（默认采用的KahaDB做消息存储）可选用JDBC的方式来做消息持久化，通过简单的xml配置信息即可实现JDBC消息存储。由于，普通关系型数据库（如Mysql）在单表数据量达到千万级别的情况下，其IO读写性能往往会出现瓶颈。在可靠性方面，该种方案非常依赖DB，如果一旦DB出现故障，则MQ的消息就无法落盘存储会导致线上故障文件系统目前业界较为常用的几款产品（RocketMQ/Kafka/RabbitMQ

在支付场景中，支付成功后利用RabbitMQ通知交易服务，更新业务订单状态为已支付。但是大家思考一下，如果这里MQ通知失败，支付服务中支付流水显示支付成功，而交易服务中的订单状态却显示未支付，数据出现了不一致。此时前端发送请求查询支付状态时，肯定是查询交易服务状态，会发现业务订单未支付，而用户自己知道已经支付成功，这就导致用户体验不一致。因此，这里必须尽可能确保MQ消息的可靠性，即：消息应该至少被消费者处理1次该如何确保MQ消息的可靠性？如果真的发送失败，有没有其它的兜底方案？

接下来，我们就学习它的基本概念和基础用法。多个消费者绑定到一个队列，同一条消息只会被一个消费者处理通过设置prefetch来控制消费者预取的消息数量交换机的作用是什么？接收publisher发送的消息将消息按照规则路由到与之绑定的队列不能缓存消息，路由失败，消息丢失FanoutExchange的会将消息路由到每个绑定的队列描述下Direct交换机与Fanout交换机的差异？Fanout交换机将消息路由给每一个与之绑定的队列。

在com.alibaba.dubbo.rpc.Protocol extension = (com.alibaba.dubbo.rpc.Protocol)ExtensionLoader.getExtensionLoader(com.alibaba.dubbo.rpc.Protocol.class).getExtension(extName)这个代码中，当然这个是有在具体的暴露服务或者引用远程服务才被调用执行的。到这一步就可以认为是dubbo的spi加载整个的过程完成了，整个链路有些长，需要好好的梳理一下。

首先是支持事务的，但与关系型数据库的事务有区别。

如果发现比自己小的那个节点被删除，则客户端的Watcher会收到相应通知，此时再次判断自己创建的节点是否是lock子节点中序号最小的，如果是则获取到了锁，如果不是则重复以上步骤继续获取到比自己小的一个节点并注册监听。当某个客户端释放锁时，需要触发所有等待的客户端获取锁，可能会导致较多的网络通信和监听事件。在整个分布式锁的竞争过程中，大量的「Watcher通知」和「子节点列表的获取」操作重复运行，并且大多数节点的运行结果都是判断出自己当前并不是编号最小的节点，继续等待下一次通知，而不是执行业务逻辑。

在微服务架构中，服务与服务之间通过远程调用的方式进行通信，一旦某个被调用的服务发生了故障，其依赖服务也会发生故障，此时就会发生故障的蔓延，最终导致灾难性雪崩效应。。本文则着重介绍请求限流算法。

单体架构：简单方便，高度耦合，扩展性差，适合小型项目。例如：学生管理系统分布式架构：松耦合，扩展性好，但架构复杂，难度大。适合大型互联网项目，例如：京东、淘宝微服务：一种良好的分布式架构方案①优点：拆分粒度更小、服务更独立、耦合度更低②缺点：架构非常复杂，运维、监控、部署难度提高SpringCloud是微服务架构的一站式解决方案，集成了各种优秀微服务功能组件Ribbon 是一个基于 Http 和 TCP 的客服端负载均衡工具，它是基于 Netflix Ribbon 实现的。

2PC，两阶段提交，将事务的提交过程分为资源准备和资源提交两个阶段，并且由事务协调者来协调所有事务参与者，如果准备阶段所有事务参与者都预留资源成功，则进行第二阶段的资源提交，否则事务协调者回滚资源。由事务协调者询问通知各个事务参与者，是否准备好了执行事务，具体流程图如下：协调者收到各个参与者的准备消息后，根据反馈情况通知各个参与者commit提交或者rollback回滚**事务提交：**当第一阶段所有参与者都反馈同意时，协调者发起正式提交事务的请求，当所有参与者都回复同意时，则意味着完成事务，具体流程如下：

幂等概念来自数学，表示对数据源做N次变换和1次变换的结果是相同的。在计算机中编程中，一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数或幂等方法是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。简单理解就是，一个逻辑即使被重复执行多次，也不影响最终结果的一致性，这叫幂等。幂等包括第一次请求的时候对资源产生了副作用，但是以后的多次请求都不会再对资源产生副作用。

ZAB（ZooKeeper Atomic Broadcast 原子广播） 协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议。在 ZooKeeper 中，主要依赖 ZAB 协议来实现分布式数据一致性，基于该协议，ZooKeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间的数据一致性。ZAB 协议包括两种基本的模式，分别是。

举例如下：假如现在一共有 3 个将军 A，B 和 C，每个将军都有一个随机时间的倒计时器，倒计时一结束，这个将军就把自己当成大将军候选人，然后派信使传递选举投票的信息给将军 B 和 C，如果将军 B 和 C 还没有把自己当作候选人（自己的倒计时还没有结束），并且没有把选举票投给其他人，它们就会把票投给将军 A，信使回到将军 A 时，将军 A 知道自己收到了足够的票数，成为大将军。每个服务器的状态机按照日志顺序处理已提交的命令，并将输出返回给客户端，因此，这些服务器形成了一个单一的、高度可靠的状态机。

Paxos 算法是第一个被证明完备的分布式系统共识算法。共识算法的作用是让分布式系统中的多个节点之间对某个提案（Proposal）达成一致的看法。提案的含义在分布式系统中十分宽泛，像哪一个节点是 Leader 节点、多个事件发生的顺序等等都可以是一个提案。Basic Paxos 算法：描述的是多节点之间如何就某个值(提案 Value)达成共识。Multi-Paxos 思想：描述的是执行多个 Basic Paxos 实例，就一系列值达成共识。

CAP也就是Consistency（一致性）Availability（可用性）Partition Tolerance（分区容错性）这三个单词首字母组合。CAP 理论的提出者布鲁尔在提出 CAP 猜想的时候，并没有详细定义三个单词的明确定义。因此，对于 CAP 的民间解读有很多，一般比较被大家推荐的是下面这种版本的解读。一致性（Consistency） : 所有节点访问同一份最新的数据副本可用性（Availability）: 非故障的节点在合理的时间内返回合理的响应（无论是响应成功或失败）。

Dubbo是一个分布式、高性能、透明化的RPC服务框架，提供服务自动注册、自动发现等高效服务治理方案，可以和Spring框架无缝集成。Dubbo最常用的应用就是远程调用。：配置当前应用信息：配置提供服务的协议信息：配置注册相关信息：配置暴露的服务信息：配置当前应用信息：配置引用的服务信息。