rocketmq架构设计与实现原理,rocketmq结构图

　　RocketMQ消息模型和其他消息队列一样，是生产者-主题-消费者。

　　生产者产生一个信息，也就是发送者。

　　主题消息subject:消息按照主题发送后，消息的存储片段全部按照主题进行处理。

　　消费者消息消费者还支持基于主题的消息消费的推和拉模式(实际上，它们在内部都是拉模式的变体)。

　　为了支持高并发，提高可扩展性和消息积累能力，扩展了集群消息模型。

　　一个主题可以有多个队列，可以在不同的物理机上，这为高吞吐量和水平扩展支持奠定了基础。

　　在消费者方面，消费者支持群体的概念。一群消费者中有很多消费实例，一群消费者消费某个话题，所以消费力是横向扩大的。

　　消费群体支持集群消费模式和广播消费模式。

　　集群中同一个组中的消费者实例将从相应主题的不同队列中提取数据进行消费。广播模式是每个消费者都会拉取主题中所有队列对应的消息进行消费。总的来说，RocketMQ设计的大部分组件是名称服务器、代理、生产者和消费者。

　　名称服务器名称服务名称服务器，类似于Zookeeper，负责管理集群组件。简单地说，NameServer可以发现有哪些代理，以及主题队列是如何分布在哪些代理机器上的。它就像一个大脑管理器收集器。相当于一个话题路由管理中心。名称服务器可以由多个实例独立部署，它们之间没有数据交换。每个代理在启动时都会向所有名称服务器报告信息，所以它们可以相互独立，完全无状态。即使一个挂起，集群也不会受到影响。

　　消息存储代理服务Broker是真正托管消费存储和交付查询的服务。这是一个非常核心的服务，大部分性能优化都是针对这个服务的。分为主从角色。在配置文件中，Broker id=0表示主设备不为0，从设备表示。

　　代理启动后，它已经与名称服务器建立了长连接，并定期向名称服务器报告主题信息本身。

　　生产者生产者生产者生产/发送消息服务，一般是程序自己编写的发送消息端的业务。启动后，它将首先与名称服务器建立连接，定期从名称服务器获取主题路由信息，并定期查询Broker服务信息，同时与Broker master角色建立长连接。生产者也是无国籍的。

　　消费者消费者消费者服务一般是通过自己的业务程序实现的。启动后，与名称服务器建立连接，定期从名称服务器获取话题信息和经纪人信息。获得代理信息后，您还将与代理中的主从角色建立一个长连接。所有消费者都可以订阅主服务器和从服务器。

　　只有非常了解IO的人才能写出这么优秀的框架，里面包含了太多有价值的设计和想法，需要学习和借鉴，然后再去仔细研究。

　　版权归作者所有：原创作品来自博主小二上九8，转载请联系作者取得转载授权，否则将追究法律责任。

郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。