topic

一、资料文档 Kafka：中。有kafka作者自己写的书，网上资料也有一些。rabbitmq：多。有一些不错的书，网上资料多。zeromq：少。没有专门写zeromq的书，网上的资料多是一些代码的实现和简单介绍。rocketmq：少。没有专门写rocketmq的书，网上的资料良莠不齐，官方文档很简洁，但是对技术细节没有过多的描述。activemq：多。没有专门写activemq的书，网上资料多。 二、开发语言 Kafka：Scala rabbitmq：Erlang zeromq：c rocketmq：java activemq：java 三、支持的协议 Kafka：自己定义的一套…（基于TCP） rabbitmq：AMQP zeromq：TCP、UDP rocketmq：自己定义的一套… activemq：OpenWire、STOMP、REST、XMPP、AMQP 四、消息存储 Kafka：内存、磁盘、数据库。支持大量堆积。 kafka的最小存储单元是分区，一个topic包含多个分区，kafka创建主题时，这些分区会被分配在多个服务器上，通常一个broker一台服务器。分区首领会均匀地分布在不同的服务器上，分区副本也会均匀的分布在不同的服务器上，确保负载均衡和高可用性，当新的broker加入集群的时候，部分副本会被移动到新的broker上。根据配置文件中的目录清单

不涉及专业解释，仅仅自我理解。 mqtt协议主要分为订阅和发布两块，在mqtt服务器启动时主要是运行订阅部分；订阅的topic可按层级划分，父级、子级；同级等等规则；关于订阅的topic解释较多不做记录。 mqtt发布感觉是不支持直接一对多发布，子级发布的父级可以看到，而父级发布的只能父级的父级查看，子级是接收不到的，也就是说不支持全局发布。 如果有大神看到可以指点下是否正确。 来源： CSDN 作者： -syso- 链接： https://blog.csdn.net/qq_27619637/article/details/103470112

Topic 主题，从逻辑上讲一个Topic就是一个Queue，即一个队列；从存储上讲，一个Topic存储了一类相同的消息，是一类消息的集合。比如一个名称为trade.order.queue的Topic里面存的都是订单相关的消息。 Partition 分区。分区是存在于服务端，内部保持顺序、且顺序不可变更的一个队列，用于存储消息。分区可能不应该出现在消息领域内，在使用消息中间件发送和消费时，实际上用户是感受不到分区这个概念的。下面这幅图便于大家去理解分区： 一个Topic存储消息时会分为多个Partition，每个Partition内消息是有顺序的。至于为什么需要将Topic划分成按照Partition存储，在以后设计和实现部分会解释。 Producer 生产者，消息的生产方，一般由业务系统负责产生消息。 Producer负责决定将消息发送到哪个Topic的那个Partition。 Consumer 消费者，消息的消费方，一般是后台系统负责异步消费消息。 Consumer订阅Topic，消费Topic内部的消息。 Broker 消息的存储者，一般也称为Server，在JMS中叫Provider，在RocketMQ（阿里开源的消息中间件）中叫Broker。 NameServer NameServer其实不是消息中间件的概念了

1、RocketMQ简单介绍 RocketMQ主要由NameServer、Broker、Producer以及Consumer四部分构成，如下图所示 所有的集群都具有水平扩展能力，无单点障碍。 NameServer以轻量级的方式提供服务发现和路由功能，每个NameServer存有全量的路由信息，提供对等的读写服务，支持快速扩缩容。 Broker负责消息存储，以Topic为纬度支持轻量级的队列，单机可以支撑上万队列规模，支持消息推拉模型，具备多副本容错机制（2副本或3副本）、强大的削峰填谷以及上亿级消息堆积能力，同时可严格保证消息的有序性。除此之外，Broker还提供了同城异地容灾能力，丰富的Metrics统计以及告警机制。这些都是传统消息系统无法比拟的。 Producer由用户进行分布式部署，消息由Producer通过多种负载均衡模式发送到Broker集群，发送低延时，支持快速失败。 Consumer也由用户部署，支持PUSH和PULL两种消费模式，支持集群消费和广播消息，提供实时的消息订阅机制，满足大多数消费场景。 2、RocketMQ中的专业术语 Topic topic表示消息的第一级类型，比如一个电商系统的消息可以分为：交易消息、物流消息...... 一条消息必须有一个Topic。 Tag Tag表示消息的第二级类型，比如交易消息又可以分为：交易创建消息，交易完成消息.....

1.概述 本篇文章会尽力全面的介绍RocketMQ和Kafka各个关键点的比较，希望大家读完能有所收获。 RocketMQ前身叫做MetaQ, 在MeataQ发布3.0版本的时候改名为RocketMQ，其本质上的设计思路和Kafka类似，但是和Kafka不同的是其使用Java进行开发，由于在国内的Java受众群体远远多于Scala，所以RocketMQ是很多以Java语言为主的公司的首选。同样的RocketMQ和Kafka都是Apache基金会中的顶级项目，他们社区的活跃度都非常高，项目更新迭代也非常快。 2.入门实例 2.1 生产者 public class Producer { public static void main(String[] args) throws MQClientException, InterruptedException { DefaultMQProducer producer = new DefaultMQProducer("ProducerGroupName"); producer.start(); for (int i = 0; i < 128; i++) try { { Message msg = new Message("TopicTest", "TagA", "OrderID188", "Hello world".getBytes

1、 Topics 　　　　1.1、Topic 就是 数据主题 ； 　　　　1.2、作用： 数据记录 发布的地方，用来 区分 业务系统 ； 　　　　1.3、 每个Topic 可以有 多个 消费者 订阅它的数据； 　　　　1.4、 每个Topic ， Kafka集群 都会 维持 一个分区日志 ； 　　　　1.5、 每个分区 都是 有序 且 顺序不可变 的 记录集 ，并且 不断地追加到结构化的commit log中 ； 　　　　　　　　 每个分区 中 的 每个记录 都会 分配 一个id号 来 表示顺序 ，称为 offset （用来 唯一标识 分区中的每条记录）； 　　　　1.6、 Kafka集群 保留 所有发布的记录 （ 无论 是否被消费过 ）； 　　　　　　　　　　可通过 一个可配置的参数（保留期） 来控制， 过期后 记录会被抛弃并释放 磁盘空间 ； 　　　　　　 Kafka的性能 和 数据大小无关 ，所以长时间存储没有问题； 来源： https://www.cnblogs.com/anpeiyong/p/12028108.html

简单介绍： 因为Kafka集群是把状态信息保存在Zookeeper中的，并且Kafka的动态扩容是通过Zookeeper来实现的，所以需要优先搭建Zookeerper集群，建立分布式状态管理。开始准备环境，搭建集群： zookeeper是基于Java环境开发的所以需要先安装Java 然后这里使用的zookeeper安装包版本为zookeeper-3.4.14，Kafka的安装包版本为kafka_2.11-2.2.0。 AMQP协议：Advanced Message Queuing Protocol （高级消息队列协议）是一个标准开放的应用层的消息中间件协议。AMQP定义了通过网络发送的字节流的数据格式。因此兼容性非常好，任何实现AMQP协议的程序都可以和与AMQP协议兼容的其他程序交互，可以很容易做到跨语言，跨平台。 一、首先做好kafka 1、准备三台服务器,推荐每台2个G，记得关闭防火墙 server1：10.0.0.41 server2：10.0.0.42 server3：10.0.0.43 2、三台都得配置jdk环境，1.8以上，修改主机名并且配置主机名 10.0.0.41 hostname kafka01 10.0.0.42 hostname kafka02 10.0.0.43 hostname kafka03 cat /etc/hosts 10.0.0.41

1、配置文件 1、yml配置文件 rocketmq: #mq配置 producer: iseffect: true type: default # (transaction,default) transaction:TransactionMQProducer; default:DefaultMQProducer groupName: testzjlGroup topicName: test_topic namesrvAddr: 192.168.244.128:9876 consumer: iseffect: true type: default # (transaction,default) transaction:TransactionMQProducer; default:DefaultMQProducer groupName: testzjlGroup topicName: test_topic namesrvAddr: 192.168.244.128:9876 2、对应的java类 package com.gofun.customer.mq; import org.springframework.boot.context.properties.ConfigurationProperties; @ConfigurationProperties(prefix =

参考资料： https://blog.csdn.net/gongxinju/article/details/72672375 以后继续深入总结。 Kafka中的Message是以topic为基本单位组织的，不同的topic之间是相互独立的。每个topic又可以分成几个不同的partition(每个topic有几个partition是在创建topic时指定的)，每个partition存储一部分Message。借用官方的一张图，可以直观地看到topic和partition的关系。 partition是以文件的形式存储在文件系统中，比如，创建了一个名为page_visits的topic，其有5个partition，那么在Kafka的数据目录中(由配置文件中的log.dirs指定的)中就有这样5个目录: page_visits-0， page_visits-1，page_visits-2，page_visits-3，page_visits-4，其命名规则为<topic_name>-<partition_id>，里面存储的分别就是这5个partition的数据。 接下来，本文将分析partition目录中的文件的存储格式和相关的代码所在的位置。 3.1、Partition的数据文件 Partition中的每条Message由offset来表示它在这个partition中的偏移量

一、现象 mqcloud持续发送topic为digg-topic的消费者digg-group发生偏移量错误的预警邮件，详细预警如下： 即：digg-group请求从偏移量 156798 开始消费，但是broker上最小的消息偏移量是 172289 ，也就是说， 消费者想请求消费的消息，在broker上已经不存在了。 解释：rocketmq会将此种情况当做一个事件消息发送到内置的topic：OFFSET_MOVED_EVENT中，mqcloud会订阅并消费该topic，并会以固定频率进行预警。 二、mqcloud监控情况 顺着预警邮件的链接，到mqcloud里看下消费者的具体情况，发现digg-group消费有堆积，详细如下： 点开查看每个客户端的消费情况，定位到某个机器消费有堆积： 三、broker表现 找到对应的broker的某个实例，查看broker.log日志，发现很多类似如下的日志： 2019-01-18 19:24:01 INFO PullMessageThread_49 - the request offset too small. group=digg-group, topic=digg-topic, requestOffset=156798, brokerMinOffset=172289, clientIp=/10.*.*.*:54437 2019-01-18 19