topic

新建maven工程，我的工程名叫SpringBootActiveMQTopicProducer。 pom.xml，application.yml参考这篇博客： https://blog.csdn.net/qq_36059561/article/details/103834916 注意需要修改的一个地方，在application.yml中spring.jms.pub-sub-domain的值要设置成true，表示topic，下面的myqueue: boot-activemq-queue改成mytopic: boot-activemq-topic。 创建ConfigBean.java，编写代码，代码如下。 package com.wsy.boot.activemq.config; import org.apache.activemq.command.ActiveMQTopic; import org.springframework.beans.factory.annotation.Value; import org.springframework.context.annotation.Bean; import org.springframework.jms.annotation.EnableJms; import org.springframework.stereotype

Spring boot + kafka kafka安装 http://kafka.apache.org/downloads kafka官网下载 1、解压下载的tgz tar xvf kafka_2.13-2.4.0.tgz 2、配置kafka vi kafka_2.13-2.4.0/config/server.properties host.name=192.168.139.136（kafka所在服务器IP） listeners=PLAINTEXT://192.168.139.136:9092 advertised.listeners=PLAINTEXT://192.168.139.136:9092（kafka所在服务器IP） 3、运行kafka 运行kafka之前，需要先运行zookeeper ./bin/zookeeper-server-start.sh -daemon config/zookeeper.properties 运行kafka ./bin/kafka-server-start.sh config/server.properties 4、创建kafka Topic ./bin/kafka-topics.sh --create --bootstrap-server 192.168.139.136:9092 --topic test-topic --partitions

转载自：https://www.cnblogs.com/xifenglou/p/7251112.html 一、为什么需要消息系统 1.解耦：　　允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。 2.冗余： 　　消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。 3.扩展性： 　　因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。 4.灵活性 & 峰值处理能力： 　　在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。 5.可恢复性： 　　系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。 6.顺序保证： 　　在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。（Kafka 保证一个

mirror功能介绍可查看其他资源，本次只介绍实际部署案例，hostA和hostB上分别有两套单节点kafka集群，配置数据由hostA的topic同步至hostB的topic 1.配置两边的/etc/hosts，互通 2.在hostA节点创建mirror-consumer.properties mirror-producer.properties mirror-consumer.properties内容： bootstrap.servers=hostA:9092 group.id=mirror mirror-producer.properties内容： bootstrap.servers=hostB:9092 3.在hostB节点创建相同mirror-consumer.properties mirror-producer.properties文件 4.在hostA和hostB Kafka集群中都存在topic test_demo 5.在hostA启动mirror maker kafka-mirror-maker.sh --consumer.config ~/mirror-consumer.properties --producer.config ~/mirror-producer.properties --whitelist "test_demo" 5

一、RocketMQ简介   RocketMQ作为一款纯 java 、分布式、队列模型的开源消息中间件，支持事务消息、顺序消息、批量消息、定时消息、消息回溯等。 二、RocketMQ架构   如图所示为RocketMQ基本的部署结构，主要分为NameServer集群、Broker集群、Producer集群和Consumer集群四个部分。   Broker在启动的时候会去向NameServer注册并且定时发送心跳，Producer在启动的时候会到NameServer上去拉取Topic所属的Broker具体地址，然后向具体的Broker发送消息 1、NameServer   NameServer的作用是Broker的注册中心。   每个NameServer节点互相之间是独立的，没有任何信息交互，也就不存在任何的选主或者主从切换之类的问题，因此NameServer是很轻量级的。单个NameServer节点中存储了活跃的Broker列表（包括master和slave），这里活跃的定义是与NameServer保持有心跳。 2、Topic、Tag、Queue、GroupName   Topic 与 Tag 都是业务上用来归类的标识，区分在于 Topic 是一级分类，而 Tag 可以理解为是二级分类 1) Topic（话题）   Topic是生产者在发送消息和消费者在拉取消息的类别

导语 | 近日，云+社区技术沙龙“腾讯开源技术”圆满落幕。本次沙龙邀请了多位腾讯技术专家围绕腾讯开源与各位开发者进行探讨，深度揭秘了腾讯开源项目TencentOS tiny、TubeMQ、Kona JDK、TARS以及MedicalNet。本文是对张国成老师演讲的整理。 本文要点： Message Queue 的原理和特点； TubeMQ相关实现原理及使用介绍； TubeMQ后续的发展和探讨。 一、Message Queue 简介 对于Message Queue(以下简称MQ)，Wiki百科上的定义指：不同进程之间或者相同进程不同线程之间的一种通讯方式，它是一种通讯方式。 那我们为什么要采用MQ呢？这是由MQ的特点来决定的。第一是因为它可以整合多个不同系统共同协作；第二是它可以解耦，进行数据传递和处理；第三是它可以做峰值的缓冲处理，我们平常接触到的像Kafka、RocketMQ、Pulsar等基本上也都有这样的特点。 那作为大数据场景下的MQ又有什么特点呢？从我个人的理解来说，就是 高吞吐低延时，系统尽可能地稳定，成本尽可能地低，协议也不需要特别地复杂，特别是水平扩展能力要尽可能的高。 因为像海量数据基本上都是到百亿、千亿、万亿，比方说我们自己的生产环境可能一个月、一年的时间就会翻一番，如果没有横向的扩展能力，系统就很容易出现各种问题。 二、TubeMQ实现原理及使用介绍 1

第一步：查看 kafka/config/server.properties 文件 delete.topic.enable=true #这一项必须为true 再查看 #这一项如果为false，就可以直接进行下面的操作 #如果为true，则必须将生产者停了，再进行下面的操作 auto.create.topics.enable = false 第二步： 进入到kafka的安装目录下 #查看topic是否存在 ./bin/kafka-topics.sh --list --zookeeper 【zookeeper server:port】|grep 【topic名称】 #删除topic ./bin/kafka-topics --delete --zookeeper 【zookeeper server:port】 --topic 【topic name】 #再次查看topic ./bin/kafka-topics.sh --list --zookeeper 【zookeeper server:port】|grep 【topic名称】 此时会看到 topic-marked for deletion 的情况 第三步： 进入到zookeeper的安装目录: $ cd bin/ #启动zzookeeper的客户端 $ ./zkCli.sh (1) 找到topic所在的目录：ls /brokers

什么是消息队列？ 为什么要用消息队列？ 即，应用场景是什么，也就是用了有什么好处 解耦 多应用间通过消息队列对同一消息进行处理，避免调用接口失败导致整个过程失败 异步 多应用对消息队列中同一消息进行处理，应用间并发处理消息，相比串行处理，减少处理时间 削峰／限流 避免流量过大导致应用系统挂掉的情况 使用消息队列需要注意什么？ 系统复杂性增加 如何保证消息队列是高可用，即做到集群高可用 如何保证消费的可靠性传输，即不丢消息 如何保证消息不被重复消费，即保证消费的幂等性 如何保证消息的顺序性，即保证数据的逻辑正确性 简单分析RocketMQ的原理 高可用 上架构 NameServer ： 维持心跳和提供Topic-Broker的关系数据，多个Namesrv之间相互没有通信，单台Namesrv宕机不影响其他Namesrv与集群；即使整个Namesrv集群宕机，已经正常工作的Producer，Consumer，Broker仍然能正常工作，但新起的Producer, Consumer，Broker就无法工作，nameserver不会有频繁的读写，所以性能开销非常小，稳定性很高 Broker ： Broker与Namesrv的心跳机制：单个Broker跟所有Namesrv保持心跳请求，心跳间隔为30秒，心跳请求中包括当前Broker所有的Topic信息 高可靠并发读写服务

Topic可以理解为对消息的分类，或者打标签。Topic与Message之间的关系是一对多的关系，即多个Message可以属于同一Topic，但是一个Message只能属于一个Topic。 Topic与Group的关系是多对多，即一个Topic可以由多个生产者发送消息，反过来一个生产者也可以发送多个Topic消息。一个Topic可以由多个消费者消费，反过来一个消费者可以消费多个Topic消息。 Message封装了消息内容本身，一个Message必须有一个Topic。一个Message可以打上标签或KV对，以进行更细的区分。实际开发中，一个系统只分配一个Topic，但是一个系统可能有多个任务，一个Topic显然粒度太大了，通过标签或KV对可以进行更细划分。 来源： https://www.cnblogs.com/stronger-brother/p/12163466.html

创建topic sh bin/kafka-topics.sh --create --zookeeper hadoop000:2181/kafka --topic test --partitions 1 --replication-factor 1 查看topic sh bin/kafka-topics.sh --describe --zookeeper hadoop000:2181/kafka --topic test 启动生产者 sh bin/kafka-console-producer.sh --broker-list hadoop000:9092 --topic test 启动消费者 sh bin/kafka-console-consumer.sh --bootstrap-server hadoop000:9092 --topic test 来源： CSDN 作者： 游九河 链接： https://blog.csdn.net/qq_40337206/article/details/103877212