前言

之前三篇已经从Producer、Broker、Consumer三者角度出发分析了RocketMQ框架的高可用，本篇简单介绍RocketMQ中的高可用地方。之前对NameServer已经做过详细的分析，就简单的介绍一下吧。

所有高可用部分总结

• RocketMQ源码学习之高可用分析(一)
• RocketMQ源码学习之高可用分析(二)
• RocketMQ源码学习之高可用分析(三)
• RocketMQ源码学习之高可用分析(四)

前言

上一篇开始的地方占了个坑，其实那两个问题也涉及到消费者这边的相关逻辑，本篇主要从保证消费者消费高可用出发，其中涉及到两个方面，其一消费者消费时，会对broker集群的所有队列进行选择，也就需要考虑消费者的负载均衡机制。其二，在Consumer的配置文件中不需要设置消费者是从master读取数据还是slave读取，当master繁忙的时候，Consumer会被自动切换到从slave读取数据，也之所以有了这种机制，当master发生故障的时候，Consumer仍然可以从slave读取数据，不影响Consumer的消费，达到高可用。

前言

上篇在源码层面对RocketMQ的Producer端的高可用进行了分析，主要解释了其负载均衡机制，那么本章就对Broker的高可用做一个简单的分析。

前言

RocketMQ分布式集群是通过其中各个模块的配合实现高可用，RocketMQ的高可用主要可以从Producer、Consumer、Broker和NameServer出发来分析，本章旨在通过源码来简单分析其中Producer的高可用原理。其他部分在后续章节继续分析。

前言

消息存储是消息队列中最为重要的一部分，因为对其有高可靠性的要求，就要求数据进行持久化存储。作为数据的存储介质，无非就是数据库和文件系统两种，比如ActiveMQ就是将数据存储在DB中，而rocketMQ则是将数据存放在文件系统中。本篇主要从保证rocketMQ的读写性能出发，分析其中的原理。

前言

NameServer是RocketMQ中一个十分重要的概念，还记得上一篇中提到启动消息队列的步骤吗，就是先启动NameServer，然后再启动Broker。NameServer是一个简单的路由注册中心，也就是相当于之前dubbo中ZK的地位，在开始本篇之前，先提出几个问题：

• NameServer在整个架构中的作用是什么
• NameServer中存储了Broker中的哪些信息
• NameServer与Producer以及Consumer之前是什么关系

前言

最近打算开始学习消息队列相关内容，计划先从简单的整体框架出发宏观把握，再深入到源码层面。打算从rocketMQ出发进行展开，本篇先从基础的整体框架，消息生产方式和消息消费方式进行学习。

前言

此版本加入了ZooKeeper作为服务治理的方法。整体的流程很简单，服务者通过Zookeeper注册服务，消费者通过ZooKeeper来获取提供服务的服务者，从而实现对应方法调用。

前言

Dubbo中的SPI机制，全称为 Service Provider Interface，是一种服务发现机制。是提供给扩展者使用的一种机制，比方说可以载入Dubbo中的各种可配置组件，比如：动态代理方式（ProxyFactory）、负载均衡策略（LoadBalance）、RCP协议（Protocol）、拦截器（Filter）、容器类型（Container）、集群方式（Cluster）和注册中心类型（RegistryFactory）等，增强了JDK 的SPI，使得其在最大程度的解耦。比较类似于Spring中IoC的思想。关于Spring的IoC的具体分析留到后面学习Spring源码的时候再做分析，这边主要看的是Dubbo中SPI机制的实现。另外，我们知道jdk本身就有SPI，那么Dubbo中对SPI是如何实现的。另外补充一点，SPI是一种破坏双亲委派机制的做法，关于双亲委派机制可以看本篇第四节的部分，所以说一种机制的出现肯定有好也有坏，关键看的是在何种情况下的使用。

前言

前三篇博客已经总结完了集群容错的比较重要的三个部分，本篇是集群容错的最后一个部分，也就是负载均衡LoadBalance。负载均衡在任何分布式的项目中都或多或少的会遇见，解决的方法也大同小异，并且，dubbo中的负载均衡在面试中似乎也是一个经常被问到的点。本篇简单总结Dubbo中的集群容错部分。