江晓龙的博客

集群模式下会有很多个Broker，创建Topic主题时可以指定主题的分区有多少个，将消息数据拆分到不同的分区中进行存储，增加读写的吞吐量，然后还可以将分区创建出多个副本节点，不同的副本节点存放在不同的Broker里，副本之间进行数据上的同步，保证消息数据的高可靠性。所谓的副本类似于备份，在创建Topic主题时，需要指定该Topic主题的副本数量，这个副本数量一般是按照集群中Broker的节点数量为依据的，如果集群中有三台节点，那么就存在3个Broker，创建Topic主题时，就指定副本数为3。

可以看到集群中zookeeper-1节点是Follower角色，zookeeper-2节点是Leader角色，zookeeper-3节点是Follower角色，正就验证了我们起那么说的那句话，当ServerID大并且投票超过半数则当选Leader节点，zookeeper-2节点启动后，ServerID最大，并且zookeeper-1和zookeeper-2都投了投票，票数也超过了集群数量的半数以上，因此当选成功。到此为止每个节点都配置完成了，下面进行集群模式的配置。

一个业务Topic中保存了100条消息数据，消费者1从Topic中消费消息数据，同时会定期将消费数据的偏移量写入到kafka内部的Consumer_offset主题上，如果消费者1在消费到第50条消息数据时，异常宕机不可用，此时消费者2启动后，就可以通过消费者1写入到Consumer_offset主题中的消息偏移量，根据偏移量就可以计算出消费者是在那条消息消费时宕机的，紧接着从这条消息处开始消费，从而避免消息长期不被消费的问题。故而将其设置了50个分区。其实是有公式计算的，如下所示。

消息生产者Producer产生消息数据，发送到Kafka消息队列中，一台Kafka节点只有一个Broker，消息会存储在Kafka的Topic（主题中），不同类型的消息数据会存储在不同的Topic中，可以利用Topic实现消息的分类，消息消费者Consumer会订阅消息存储的Topic，从Topic中读取/接收消息数据，不同的消费者可以订阅不同的Topic。命令可以模拟消费者Consumer接收消息数据，将接收到的消息数据打印在终端，默认情况下消费的是Topic中最新的消息数据。

当系统架构中引入了消息队列，用户下单完成后向消息队列中发送一条消息数据后，就会返回给用户订单创建完成，此时仅仅花费50毫秒的时间，消息数据进入到消息队列后，会被分配到某一个队列中，需要与订单系统联动的系统，就会去消息队列中订阅这个队列，然后消费订单系统产生的消息数据，进行相应的业务逻辑处理。无Broker的消息队列中间件典型代表就是ZeroMQ，这个MQ消息队列就是为解决通信问题而诞生，就把MQ当做一个库，而并非一个中间件，在这种消息队列中，每个节点既是消费者又是生产者，直接读取和消费数据，不进行存储。

在上一步中，RabbitMQ集群已经搭建完成了，但是并不能保证消息队列的高可用，尽管交换机和队列都可以绑定和复制到任何一个节点中，在每个节点都会显示，但是数据时不会复制的，当我们在rabbitmq-1节点上创建的队列，产生的消息数据，在第二个节点上只能看到这个队列的状态，当第一个节点挂了之后，数据就无法读取了，仅显示有这个队列存在并且状态是down。可以看到所有队列中的节点列表，都已经变成了rabbitmq-2，并且没有了+1的展示，这是因为第一个节点挂了，现在一个。在哪一个节点上添加都可以，都会复制。

如果消费者接收消息出现了异常，接收失败了，第三步发送延迟消息就起到了保证消息可靠性的重要环节，生产者会发生一个延迟消息到Q3队列中，回调系统也会从Q3队列中读取延迟消息，延迟消息和正常消息是一模一样的，回调检查系统会把延迟消息的ID与MQ数据库中的消息ID进行比对，如果存在数据那么久不会再做任何处理，如果发现数据库中不存在这个消息ID，回调检查系统此时就会调用生产者重新发送消息，来保证消息传递的可靠性。RabbitMQ中的消息可靠性也称为消息补偿，如下图所示，可以保证消息的可靠性。

用户在订单系统下单后，会发送一条消息数据到RabbitMQ的Exchange交换机，Exchange交换机将数据写入到队列中，这个队列设置TTL过期时间为30分钟，并且不允许消费者读取数据，30分钟后消息成为死信消息，此时队列将死信消息发送到DLX死信交换机，死信交换机再将消息数据传递给死信队列，然后由消费者从死信队列中读取数据并进行处理。当有消息数据成为死信消息时，消息所在的队列会将消息传递到DLX死信交换机上，由死信交换机再将消息数据存放在死信交换机，等待消费者读取数据。

使用Routing路由模式时，Exchange与队列也不再进行绑定了，而是通过声明一个RoutingKey，通过这个key将消息路由到特定的队列中，因此在消息发送方发消息时，就需要指定消息的RoutingKey，Routing根据消息中的RoutingKey进行判断，当消息中的RoutingKey与队列中的RoutingKey完全一致时，消息才能正常存储到队列中，最后被消费者处理。简而言之，使用Topic模式后，可以对消息数据中的RoutingKey进行通配符匹配，将满足条件的消息数据分发到特定的队列中。

RocketMQ有一个对其扩展的开源项目，这个项目中有一个子模块叫，这个便是管理控制台项目了，先将拉到本地，因为我们需要自己对进行编译打包运行。GitHub地址：https://github.com/apache/rocketmq-externals。

执行命令时如果使用`-b指定了Broker的地址，又使用-c指定了集群的名称，那么优先以Broker地址获取命令的结果，如果不指定Broker，默认会对集群中所有主机执行命令。：指定Cluster名称，表示topic所在集群（集群可通过 clusterList 查询），-b优先，如果没有-b，则对集群中所有Broker执行命令。：Broker 名称，（这里需要注意 填写的是Broker的名称，不是Broker的地址，Broker名称可以在clusterList查到）

同步模式下的多Master多Slave模式比异步模式效率略低，并且性能也比异步模式消耗要高，因为同步模式Broker收到一条消息，首先会落盘然后同步给Slave，最后再反馈给发送者，而异步模式下，Broker在收到消息的一瞬间就会反馈给发送者消息已收到。同步模式下可以保证消息的可靠性，会保证每一条消息丢失成功进行存储的，而异步模式下，虽然Broker收到消息可以立即反馈，但是数据落盘时如果MQ宕机，发送者已经收到确认的消息的，但是消息其实并没有存储到Broker中，就会导致消息数据存在丢失的现象。

RocketMQ是阿里巴巴开源的一个消息中间件，在阿里内部历经了双十一等很多高并发场景的考验，能够处理亿万级别的消息。2016年开源后捐赠给Apache,现在是Apache的一个顶级项目。目前RocketMQ在阿里云上有一个购买即可用的商业版本，商业版本集成了阿里内部一些更深层次的功能及运维定制。RocketMQ的官网地址: http://rocketmq.apache.orgGithub地址是https://github.com/apache/rocketmq。

1）当ZKServer-1节点启动后，会比较自身的ServerID，目前集群中没有其他节点，因此该节点就认为自己的ServerID是集群中最大的，给自己投一票，但是Leader的选举条件必须是票数超过集群中半数节点，例如三个节点必须至少有2个同意才可以，两个节点的集群中有2票也才可以选举为Leader，由于票数不够的问题，ZkServer-1节点就会处于Follower节点。4）剩下的其余节点在加入集群后，发现已经有Leader节点了，就不会再选举，而是成为Follower节点。

基于分布式的场景，JVM锁已经远远无法满足了，这时就需要一种统一配置的锁，那就是分布式锁的组件，让所有的程序副本都连接到这个分布式锁组件，由分布式锁提供一个唯一的锁，比如第一个请求到达APP1节点上了，此时APP1就会去分布式锁中取一个锁，让这个请求线程安心处理数据，当数据处理完成后，再将锁还回去，第二个请求进来如果发现锁已经被APP1使用了，那么就会处于等待的状态，当APP1处理完成后，APP2再拿到锁去处理数据。用于所有客户端创建的子节点间进行比较，如果发现自己的子节点编号比较小，那么就获取锁。

简而言之：Zookeeper的数据结构就是一大堆子节点组成的树形结构，就好比是Unix操作系统，根目录中存在子目录，子目录中包含子文件，数据都在子文件中存储，而Zookeeper是在根节点下包含很多子节点，但是每一个节点都可以存储自己的一些数据和当前节点的信息，允许存储的数据大小为1M。注意：如果要删除的节点中包含子节点，那么会删除失败，会提示节点不为空，只有当节点中不包含任何子节点时，才可以被删除。顺序编号在集群中通用，即使另外名称的节点也会按照当前的编号顺序往下创建。

Zookeeper是分布式协调服务，Zookeeper是Apache Hadoop项目下的一个子项目，是树形目录服务结构，可以理解为Zookeeper就是来管理分布式应用程序的，简称ZK。Zookeeper自身就是一种分布式的架构，主要为分布式应用程序提供一种协调性服务。Zookeeper公开了一组简单的原语，分布式应用程序可以基于这些原语实现更高级别的同步、配置维护、组和命名服务。它被设计为易于编程，并使用一种数据模型，该模型以熟悉的文件系统目录树结构为样式。

ActiveMQ主从高可用集群，需要使用Zookeeper集群注册所有的ActiveMQ节点，由Zookeeper实现主备切换时的选举，在主从高可用集群中，只有一个ActiveMQ节点处于工作状态，被视为Master节点，其他的ActiveMQ节点处于待机状态，当主节点挂掉后，Zookeeper会通过选举机制将集群中的某个ActiveMQ节点提升为Master，继续提供服务。模拟ActiveMQ主节点宕机，观察是否会由集群中另外的从节点，升级为主节点。每个节点都有单独的通信地址，故障切换后可以直接切换。

MQ有时候会因为某种情况宕机，如果没有进行消息持久化，就会造成数据的丢失，当ActiveMQ进行了消息持久化后，可以保证数据的不丢失。消费者从ActiveMQ中接收消息，然后通知ActiveMQ消息已经收到，ActiveMQ会从持久化存储中将消息移除。生产者产生消息后发生到ActiveMQ，ActiveMQ将消息持久化到存储中，然后通知生产者消息已经收到。JAVA开启消息持久化，根据ActiveMQ默认的KahaDB进行持久化数据。ActiveMQ的消息持久化方式在JAVA程序的配置文件中进行配置。

ActiveMQ 是Apache出品，最流行的，能力强劲的开源消息总线。ActiveMQ 是一个完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现,尽管JMS规范出台已经是很久的事情了,但是JMS在当今的J2EE应用中间仍然扮演着特殊的地位。支持来自Java，C，C ++，C＃，Ruby，Perl，Python，PHP的各种跨语言客户端和协议。完全支持JMS客户端和Message Broker中的企业集成模式。支持许多高级功能，如消息组，虚拟目标，通配符和复合目标。

Message Queue消息队列简称MQ，消息队列从字面的含义来看就是消息的发生和接收保持排队顺序。消息队列可以简单的理解为把要传输的数据放在队列中一一发送。**消息：**要传输的数据。**队列：**先进先出的数据结构。在消息队列中，数据放到消息队列叫做生产者，从消息队列中获取数据叫做消费者。消息队列是一种异步的服务通信方式，是分布式系统中重要的组件，主要解决的问题包含：应用解耦、异步消息、流量削锋等问题，实现高可用、高性能、可伸缩和最终一致性的架构。