斩秋的专栏

原创 11. Dubbo原理解析-注册中心之接口介绍

服务注册与发现的中心，服务的提供者将服务发布到注册中心，服务的使用着到注册中引用服务。Dubbo的注册中心提供了多种实现，其实现是基于dubbo的spi的扩展机制的，使用着可以直接实现自己的注册中心。@SPI("dubbo")public interface RegistryFactory {   /**    * 连接注册中心.    * 连接注册中心需处理契约

原创 10. Dubbo原理解析-Listener & filter

ListenerExporterListener: dubbo在服务暴露(exporter)以及销毁暴露(unexporter)服务的过程中提供了回调窗口，供用户做业务处理。ProtocolListenerWrapper在暴露过程中构建了监听器链public class ProtocolListenerWrapper implements Protocol {   public

原创 9. Dubbo原理解析-服务引用

服务引用是服务的消费方向注册中心订阅服务提供方提供的服务地址后向服务提供方引用服务的过程。服务的应用方在spring的配置实例如下：dubbo:referenceid="demoService"interface="com.alibaba.dubbo.demo. DemoService"/>如上配置spring在容器启动的时候会解析自定义的schema元素转换成dubbo内部数

原创 8. Dubbo原理解析-服务发布

服务发布是服务提供方向注册中注册服务过程，以便服务消费者从注册中心查阅并调用服务。服务发布方在spring的配置文件中配置如下：上面是在spring中配置的服务的具体实现，是spring中的一个普通的bean上面的配置spring容器在启动的过程中会解析自定义的schema元素dubbo转换成实际的配置实现ServiceBean ，并把服务暴露出去。Servic

原创 7. Dubbo原理解析-与spring融合

Spring中bean的定义可以通过编程，可以定义在properties文件，也可以定义在通过xml文件中，用的最多的是通过xml形式，由于xml格式具有很好的自说明便于编写及维护。对于xml的文档结构、数据定义及格式验证可以通过DTD和Schema， 在spring2.0之前采用的是DTD，在spring2.0之后采用Schema。使用Schema方式使得spring更加便于与第三方进行集成以及

原创 6. Dubbo原理解析-代理之Javassist生成的伪代码

下面我们以伪代码来展示下生成的代理类比如我们要对如下接口生成代理public interface DemoService {    String sayHello(String name);    String  sayHelloAgain(Stringname);}生成的代理对象public class  DemoService.proxy10001impleme

原创 5.Dubbo原理解析-代理之Javassist字节码技术生成代理

JavassistProxyFactory:利用字节码技术来创建对象public T getProxy(Invoker invoker,Class[] interfaces) {       return (T) Proxy.getProxy(interfaces).newInstance(newInvokerInvocationHndler(invoker));}看似跟jdk生

原创 4. Dubbo原理解析-代理之接口定义

代理模式这里不再逻辑介绍，dubbo中有使用这种模式，如： dubbo服务的消费端获取的就是对远程服务的一个代理。Dubbo由代理工厂ProxyFactory对象创建代理对象一：ProxyFactory的接口定义@SPI("javassist")public interface ProxyFactory {   @Adaptive({Constants.PROXY_KEY})

原创 3. Dubbo原理解析-Dubbo内核实现之动态编译

我们运行的java代码，一般都是编译之后的字节码。Dubbo为了实现基于spi思想的扩展特性，特别是能够灵活添加额外功能，对于扩展或者说是策略的选择这个叫做控制类也好设配类也好的类要能够动态生成。当然对应已知需求如Protocol, ProxyFactory他们的策略选择的设配类代码dubbo直接提供也无妨，但是dubbo作为一个高扩展性的框架，使得用户能够添加自己的需求，根据配置动态生成自己的设

原创 2. Dubbo原理解析-Dubbo内核实现之基于SPI思想Dubbo内核实现

SPI接口定义定义了@SPI注解public @interface SPI {       Stringvalue() default ""; //指定默认的扩展点}  只有在接口打了@SPI注解的接口类才会去查找扩展点实现会依次从这几个文件中读取扩展点META-INF/dubbo/internal/   //dubbo内部实现的各种扩展都放在了这个目录了META-

原创 1. Dubbo原理解析-Dubbo内核实现之SPI简单介绍

Dubbo采用微内核+插件体系，使得设计优雅，扩展性强。那所谓的微内核+插件体系是如何实现的呢！大家是否熟悉spi(service providerinterface)机制，即我们定义了服务接口标准，让厂商去实现（如果不了解spi的请谷歌百度下）, jdk通过ServiceLoader类实现spi机制的服务查找功能。 JDK实现spi服务查找: ServiceLoader首先定义下示例

原创 RocketMQ原理解析-Remoting3.通信层整体交互图

原创 RocketMQ原理解析-Remoting2. 通信层底层传输协议

RocketMq服务器与客户端通过传递RemotingCommand来交互，通过NettyDecoder，NettyEncoder对RemotingCommand进行协议的编码与解码 协议格式             1        2               3          4协议分4部分，含义分别如下1、大端4个字节整数，等于2、3、4长度总和2、大端

原创 RocketMQ原理解析-Remoting1. 通信层实现

Rocketmq的通信层是基于通信框架netty 4.0.21.Final之上做了简单的协议封装，是强依赖。一： NettyRemotingAbstract  Server与Client公用抽象类ResponseFuture模式:        invokeSyncImpl和invokeAsyncImpl都使用了       请求方会new一个ResponseFuture对象缓

原创 RocketMQ原理解析-namesrv

Namesrv名称服务，是没有状态可集群横向扩展。1.      每个broker启动的时候会向namesrv注册2.      Producer发送消息的时候根据topic获取路由到broker的信息3.      Consumer根据topic到namesrv获取topic的路由到broker的信息 一：Namesrv功能：         接收broker的请求注册b

原创 RocketMQ原理解析-broker 6.索引服务

索引结构IndexFile 存储具体消息索引的文件，文件的内容结构如图：

原创 RocketMQ原理解析-broker 3.load&recover

Broker启动的时候需要加载一系列的配置，启动一系列的任务，主要分布在BrokerController 的initialize()和start()方法中1.      加载topic配置2.      加载消费进度consumer offset 3.      加载消费者订阅关系consumer subscription4.      加载本地消息messageStore.loa

原创 RocketMQ原理解析-broker 4.HA & master slave

在broker启动的时候BrokerController如果是slave，配置了master地址更新，没有配置所有broker会想namesrv注册，从namesrv获取haServerAddr，然后更新到HAClient 当HAClient的MasterAddress不为空的时候（因为broker  master和slave都构建了HAClient）会主动连接master获取Socket

原创 RocketMQ原理解析-broker 2.消息存储

Rocketmq的消息的存储是由consume queue和 commitLog 配合完成的1）  consume queue 消息的逻辑队列，相当于字典的目录用来指定消息在消息的真正的物理文件commitLog上的位置,每个topic下的每个queue都有一个对应的consumequeue文件。文件地址：${user.home} \store\consumequeue\${topic

原创 RocketMQ原理解析-broker 1. broker的启动

brker的启动Broker向namesrv注册1.      获取namesrv的地址列表（是乱序的）2.      遍历向每个namesrv注册topic的配置信息topicconfigTopic在broker文件上的存储json格式"TopicTest":{                            "perm":6,           

原创 RocketMQ原理解析-consumer 7.shutdown

DefaultMQPushConsumerImpl  关闭消费端         关闭消费线程         将分配到的Set的消费进度保存到broker利用DefaultMQPushConsumerImpl获取ProcessQueueTable的keyset的messagequeue去获取RemoteBrokerOffsetStore.offsetTableMap中的消费进度，

原创 RocketMQ原理解析-consumer 6.pull消息消费

消费者主动拉取消息消费，客户端通过类DefaultMQPullConsumer         客户端可以指定特定MessageQueue         也可以通过DefaultMQPullConsumer.fetchMessageQueuesInBalance(topic) 获取消费的队列         业务自己获取消费队列，自己到broker拉取消息，以及自己更新消费进度因

原创 RocketMQ原理解析-consumer 5.push消费-顺序消费消息

顺序消费服务ConsumeMessageConcurrentlyService构建的时候                   构建一个线程池来接收消费请求ConsumeRequest                   构建一个单线程的本地线程,用来稍后定时重新消费ConsumeRequest, 用来执行定时周期性（一秒）钟锁队列任务          周期性锁队列lockMQPe

原创 RocketMQ原理解析-consumer 4.长轮询push消息—并发消费消息

通过长轮询拉取到消息后会提交到消息服务ConsumeMessageConcurrentlyService，ConsumeMessageConcurrentlyServic的submitConsumeRequest方法构建ConsumeRequest任务提交到线程池。长轮询向broker拉取消息是批量拉取的， 默认设置批量的值为pullBatchSize= 32，可配置消费端cons

原创 RocketMQ原理解析-consumer 2.消费端负载均衡

消费端负载均衡

原创 RocketMQ原理解析-consumer 3.长轮询

Rocketmq的消息是由consumer端主动到broker拉取的, consumer向broker发送拉消息请求， PullMessageService服务通过一个线程将阻塞队列LinkedBlockingQueue中的PullRequest到broker拉取消息         DefaultMQPushConsumerImpl的pullMessage(pullRequest)方法执行向

原创 RocketMQ原理解析-consumer 1.启动

有别于其他消息中间件由broker做负载均衡并主动向consumer投递消息，RocketMq是基于拉模式拉取消息，consumer做负载均衡并通过长轮询向broker拉消息。 Consumer消费拉取的消息的方式有两种1.      Push方式：rocketmq已经提供了很全面的实现，consumer通过长轮询拉取消息后回调MessageListener接口实现完成消费，应用系统只

原创 RocketMQ原理解析-producer 6.消息在broker落地之事物消息

消息落地commitLog针对事物消息的处理，消息的第20位开始的八位记录是的消息在逻辑队列中的queueoffset，但是针对事物消息为preparedType和rollbackType的存储的是事物状态表的索引偏移量分发事物消息：         分发消息位置信息到ConsumeQueue: 事物状态为preparedType和rollbackType的消息不会将请

原创 RocketMQ原理解析-producer 5.消息在broker落地之普通消息

Broker根据producer请求的RequestCode.SEND_MESSAGE选择对应的处理器SendMessageProcessor         根据请求消息内容构建消息内部结构MessageExtBrokerInner         调DefaultMessageStore加消息写入commitlog

原创 RocketMQ原理解析-producer 4.发送分布式事物消息

先引入官方文档图：

原创 RocketMQ原理解析-producer 3.如何发送顺序消息

Rocketmq能够保证消息严格顺序，但是Rocketmq需要producer保证顺序消息按顺序发送到同一个queue中，比如购买流程(1)下单(2)支付(3)支付成功，这三个消息需要根据特定规则将这个三个消息按顺序发送到一个queue 如何实现把顺序消息发送到同一个queue:           一般消息是通过轮询所有队列发送的，顺序消息可以根据业务比如说订单号orderId相同的

原创 RocketMQ原理解析-producer 2.如何发送消息

Producer轮询某topic下的所有队列的方式来实现发送方的负载均衡1）  Topic下的所有队列如何理解：比如broker1, broker2, borker3三台broker机器都配置了Topic_ABroker1 的队列为queue0 , queue1Broker2 的队列为queue0, queue2, queue3,Broker3 的队列为queue0当然

原创 RocketMQ原理解析-producer 1.启动流程

Producer启动流程 Producer如何感知要发送消息的broker即brokerAddrTable中的值是怎么获得的， 1.      发送消息的时候指定会指定topic，如果producer集合中没有会根据指定topic到namesrv获取topic发布信息TopicPublishInfo，并放入本地集合2.      定时从namesrv更新topic路由信息，