topic

实现原理 观察者模式 即 → 订阅者模式 例子: 1 . 微博博主给粉丝发送动态 2 . 每次狼出门之前先给人打个电话 , 通知人们自己要去吃羊 . 生产者和消费者(消息) 传统模式 - 生产者直接将消息传递给指定的消费者 - 耦合性特别高，当生产者或者消费者发生变化，都需要重写业务逻辑 新型模式 - 生产者和消费者之间建立一个共享的缓冲区 - 生产者负责向里面添加数据 - 消费者负责从里面取出数据 - 一般遵循先进先出的原则 缓冲区 - 一个工作组只能对某一条消息消费一次 - 缓冲区的消息可以被多个工作组消费 - 内部肯定有一定的机制来管理或者维护不同的数 据 - 缓冲区的数据需要放在多个节点上，让更多的节点参与到计算 - 每个节点持有消息的一个分区 , 属于数据的一部分 - 当生产者产生消息之后，需要先计算对应的分区 架构图 Broker – 代理 - 集群的节点，用于处理数据 Topic – 主题 - 不同的数据消息交给不同的Topic管理 - 类似于Table或者 Type - 存储数据可以去指定的主题去操作 producer – 生产者 - 往broker中某个topic里面生产数据 consumer – 消费者 - 从broker中某个topic获取数据 Partition – 分区 - 一个Topic下可以有多个分区，数据真实存放的位置 - 当生产者产生数据的时候

ActiveMQ 扩展出： API 接受发送 MQ 的高可用 MQ 的集群容错配置 MQ 的持久化 延时发送 签收机制 Spring/SpringBoot 整合 等 // MQ 都需要满足的技术 MQ ： 消息中间件/消息队列 为什么要使用 MQ ？ 解决了耦合调用、异步模型、抵御洪峰流量，保护了主业务，消峰。 二、安装ActiveMQ docker环境下安装 [ root@linksys ~ ] # docker pull docker.io/webcenter/activemq Using default tag: latest latest: Pulling from webcenter/activemq 7dcf5a444392: Pull complete 9eebba75a87f: Pull complete 1f0440d87cc7: Pull complete dacd0555c1b4: Pull complete b0f19aa05a94: Pull complete 4796f64423b2: Pull complete 5d994b710cb9: Pull complete 313a84c05d3c: Pull complete 1d6a562461f1: Pull complete e25558998b21: Pull complete

1、原理图 2、原理描述 一个topic 可以配置几个partition，produce发送的消息分发到不同的partition中，consumer接受数据的时候是按照group来接受，kafka确保每个partition只能同一个group中的同一个consumer消费，如果想要重复消费，那么需要其他的组来消费。Zookeerper中保存这每个topic下的每个partition在每个group中消费的offset 新版kafka把这个offsert保存到了一个__consumer_offsert的topic下 这个__consumer_offsert 有50个分区，通过将group的id哈希值%50的值来确定要保存到那一个分区. 这样也是为了考虑到zookeeper不擅长大量读写的原因。 所以，如果要一个group用几个consumer来同时读取的话，需要多线程来读取，一个线程相当于一个consumer实例。当consumer的数量大于分区的数量的时候，有的consumer线程会读取不到数据。 假设一个topic test 被groupA消费了，现在启动另外一个新的groupB来消费test，默认test-groupB的offset不是0，而是没有新建立，除非当test有数据的时候，groupB会收到该数据，该条数据也是第一条数据

1. Kafka 　　 1. 简介 　　　　Kafka 是一种分布式的、分区的、多副本的基于发布／订阅的消息系统。它是通过 zookeeper 进行协调，常见可以用于 web/nginx 日志、访问日志、消息服务等。主要应用场景为：日志收集系统和消息系统。 　　　　Kafka 的主要设计目标如下： 　　　　　　1. 以时间复杂度为 O(1) 的方式提供持久化能力，即使对 TB 级别以上的数据也能保证常数时间的访问性能。 　　　　　　2. 高吞吐率，即使在十分廉价的机器上也能实现单机支持每秒 100K 条消息的传输。 　　　　　　3. 支持 Kafka Server (即 Kafka 集群的服务器)间的消息分区，及分布式消费，同时保证每个 partition 内的消息顺序传输。 　　　　　　4. 同时支持离线数据处理和实时数据处理 　 　2. Kafka 架构 　　　　如上图所示，一个 Kafka 集群由若干producer、若干consumer、若干broker，以及一个zookeeper集群所组成。Kafka通过zookeeper管理集群配置，选举leader，以及在consumer group发生变化时进行rebalance。producer使用push模式将消息发布到broker，consumer使用pull模式从broker订阅并消费消息。 　　　　Kafka名词解释： 　

文章转载于 https://www.cnblogs.com/hayasi/p/7792191.html 我们已经把相关的连接报文搞定了。笔者想来想去还是决定先讲解一下订阅报文(SUBSCRIBE )。如果传统的通信方式是客户端和服务端之间一般就直接传输信息。但是MQTT的通信方式是通过发布/订阅的方式进行的。笔者不知道他是否跟设计模式中的发布订阅模式有没有关系。可是他们思想却有一点相似之处。 客户端知道服务上有很多个主题。就好比如说有很多消息的分类一样子。有社会新闻、体育讲坛等。那么客户端只要找到自己感兴趣的进行订阅就可以了。一个客户端可以向服务器订阅多个主题。而所谓的发布就是客户端对不同的主题进行发布信息。即好比如新闻的发布者一样子。这个时候只要订阅这个主题的客户端就可以接收到来自服务端的新闻。我们的手机常常会接收到一些推送的信息。事实上有很多App应用都是用MQTT协议来进行的。所以不难看出服务端主要是负责客户端和客户端的之间信息的传输和信息管理。大至如图下 注意：发布者也是客户端。订阅者也是客户端 主题(Topic ) 如果主题只是一个字符串值的话，那么显然会比较单调。这样子功能也显得比较无力。所以在主题上面就了所谓的分隔符和通配符的说法(个人想法)。分隔符的意思就是让主题可以分层次。就好如说主题“体育讲坛/篮球/NBA”。看到这样子的主题，请问一下你还有什么不明白的话

集群安装 1、解压 2、修改server.properties broker.id=1 zookeeper.connect=zjgm01:2181,zjgm02:2181,zjgm03:2181 3、将zookeeper集群启动 4、在每一台节点上启动broker bin/kafka-server-start.sh config/server.properties 5、在kafka集群中创建一个topic bin/kafka-topics.sh --create --zookeeper zjgm01:2181 --replication-factor 3 --partitions 1 --topic order 6、用一个producer向某一个topic中写入消息 bin/kafka-console-producer.sh --broker-list zjgm01:9092 --topic order 7、用一个comsumer从某一个topic中读取信息 bin/kafka-console-consumer.sh --zookeeper zjgm01:2181 --from-beginning --topic order 8、查看一个topic的分区及副本状态信息 bin/kafka-topics.sh --describe --zookeeper zjgm01:2181 -

自己写的网上商城项目中使用了ActiveMQ，虽然相比于RabbitMQ，kafka，RocketMQ等相比，ActiveMQ可能性能方面不是最好的选择，不过消息队列其实原理区别不大，这里对学过的关于消息队列的知识进行一下总结，并结合自己面试中关于这方面遇到的问题做一个整理，为后面秋招找工作做准备。这一篇主要介绍一下JMS，ActiveMQ安装及其常用接口，两种队列模式，如何集成到Spring项目，面试总结等。 Java Message Service，Java消息服务应用程序接口，是一个Java平台中关于面向消息中间件（MOM）的API，用于在两个程序之间，或分布式系统中发送消息，进行异步通信，JMS是一个与具体平台无关的API，绝大多数MOM提供商都对JMS提供支持。这是比较详细的关于JMS的定义，而比较直观的说，JMS是一组消息服务的API，也就是说JMS只有接口，其具体实现类交给了各种MOM厂家来做。 JMS使用场景，应用程序A部署在北京，应用程序B部署在上海，每当A触发某个事件之后，B向获取A中的一些信息，也可能有很多个B都想获取A中的信息。这种情况下，Java提供了最佳的解决方案-JMS。JMS同样适用于基于事件的应用程序，如聊天服务，他需要一种发布事件机制向所有与服务器连接的客户端发送消息。JMS与RMI不同，不需要接受者在线。也就是服务器发送完消息

Kafka工作流程分析 写入方式 producer采用推（push）模式将消息发布到broker，每条消息都被追加（append）到分区（patition）中，属于顺序写磁盘（顺序写磁盘效率比随机写内存要高，保障kafka吞吐率）。 分区（Partition） Kafka集群有多个消息代理服务器（broker-server）组成，发布到Kafka集群的每条消息都有一个类别，用主题（topic）来表示。通常，不同应用产生不同类型的数据，可以设置不同的主题。一个主题一般会有多个消息的订阅者，当生产者发布消息到某个主题时，订阅了这个主题的消费者都可以接收到生成者写入的新消息。 Kafka集群为每个主题维护了分布式的分区（partition）日志文件，物理意义上可以把主题（topic）看作进行了分区的日志文件（partition log）。主题的每个分区都是一个有序的、不可变的记录序列，新的消息会不断追加到日志中。分区中的每条消息都会按照时间顺序分配到一个单调递增的顺序编号，叫做偏移量（offset），这个偏移量能够唯一地定位当前分区中的每一条消息。 消息发送时都被发送到一个topic，其本质就是一个目录，而topic是由一些Partition Logs(分区日志)组成，其组织结构如下图所示： 下图中的topic有3个分区，每个分区的偏移量都从0开始，不同分区之间的偏移量都是独立的

kafka启动 bin/kafka-server-start.sh -daemon config/server.properties 创建topic bin/kafka-topics.sh -zookeeper localhost:2181 --create --partitions 1 --replication-factor 1 --topic test --partitions 指定分区数， --replication-factor 表示副本数 查看topic列表 bin/kafka-topics.sh --list --zookeeper localhost:2181 bin/kafka-topics.sh --list --bootstrap-server localhost:9092 -- 查看集群描述 bin/kafka-topics.sh --describe --zookeeper localhost:2181 删除topic ./bin/kafka-topics --delete --zookeeper localhost:2181 --topic test 生产消息 bin/kafka-producer-perf-test.sh --topic test --throughput -1 --record-size 10 --num-records 500000

关于大疆雷达的通讯问题 这部分比较主要,因为当时卡在这个问题上了好久,主要问题是大疆雷达在rviz实时显示的时候,livox/lidar这个topic的数据其实是很全的,但是我在转发的时候(单纯的转发,没做任何处理操作),这个时候就发现,我转发的数据会丢失,效果图如下: 彩色的部分是/livox/lidar原话题的数据,白色的是我直接转发的数据,但是发现有的时候有个雷达的数据没有,而且是闪烁性的,随机性的.不是真完整的源数据,花了好长时间在搞这个问题,为了方便转发过程,写的是简单的代码,如下: point_date_sub = n . subscribe ( "/livox/lidar" , , & callback ) ; raw_point_pub = n . advertise < sensor_msgs :: PointCloud2 > ( "/raw_Point" , 1 ) ; 因为我们在平时对回调函数处理的时候都是将回调函数的队列长度设置为1,这样才能处理队列缓存中最新的消息.所以开始我也是按照这么处理的,但是实际上确实产生了数据丢失的问题,我查看了下/livo/lidar和我转发的数据的topic的频率,如下: 上面的图是我转发数据topic的p频率,大约26,下面的是源数据的topic,大约30,从图上我们可以看出其实数据是有丢失的,所以才产生了最开始图的现象