topic

　　　　　　　　　　　　　　　　管理kafka 主题操作 1.在集群里创建一个主题需要用到3个参数。这些参数是必须提供的，尽管有些已经有broker级别的默认值。 主题名字，想要创建的主题的名字，主题名字可以包含字母，数字，下划线以及英文状态下破折号和句号。 复制系数，主题的副本数量 分区，主题的分区数量 指定主题配置 可以在创建时显式地指定复制系数或者对配置进行覆盖，通过向kafka-topic.sh 传递 --config参数来实现的。 主题创建的格式 kafka-topics.sh --zookeeper <zookeeper connect> --create --topic <string> --relipcation-fact <integer> -- partition <integer> 如果为集群指定了基于机架信息的副本分配策略，那么分区的副本会分布在不同的架构上。如果不需要基于架构信息的分配策略，可以指定参数 --disable-rack-aware 增加分区 kafak-topics.sh --zookeeper <zookeeper connect> --alter --topic <String> --partitions <integer> 只能增加分区，不能删除分区，如果删除分区，会导致数据不一致。 删除主题 如果一个主题不再使用，只要它还存在集群里面

一、基本概念 介绍 Kafka是一个分布式的、可分区的、可复制的消息系统。它提供了普通消息系统的功能，但具有自己独特的设计。 这个独特的设计是什么样的呢？ 首先让我们看几个基本的消息系统术语： Kafka将消息以topic为单位进行归纳。 将向Kafka topic发布消息的程序成为producers. 将预订topics并消费消息的程序成为consumer. Kafka以集群的方式运行，可以由一个或多个服务组成，每个服务叫做一个broker. producers通过网络将消息发送到Kafka集群，集群向消费者提供消息，如下图所示： 客户端和服务端通过TCP协议通信。Kafka提供了Java客户端，并且对多种语言都提供了支持。 Topics 和Logs 先来看一下Kafka提供的一个抽象概念:topic. 一个topic是对一组消息的归纳。对每个topic，Kafka 对它的日志进行了分区，如下图所示： 每个分区都由一系列有序的、不可变的消息组成，这些消息被连续的追加到分区中。分区中的每个消息都有一个连续的序列号叫做offset,用来在分区中唯一的标识这个消息。 在一个可配置的时间段内，Kafka集群保留所有发布的消息，不管这些消息有没有被消费。比如，如果消息的保存策略被设置为2天，那么在一个消息被发布的两天时间内，它都是可以被消费的。之后它将被丢弃以释放空间

类型 Topic Queue 概要 Publish Subscribe messaging 发布订阅消息 Point-to-Point 点对点 有无状态 topic数据默认不落地，是无状态的。 Queue数据默认会在mq服务器上以文件形式保存，比如Active MQ一般保存在$AMQ_HOME\data\kr-store\data下面。也可以配置成DB存储。 完整性保障 并不保证publisher发布的每条数据，Subscriber都能接受到。 Queue保证每条数据都能被receiver接收。 消息是否会丢失 一般来说publisher发布消息到某一个topic时，只有正在监听该topic地址的sub能够接收到消息；如果没有sub在监听，该topic就丢失了。 Sender发送消息到目标Queue，receiver可以异步接收这个Queue上的消息。Queue上的消息如果暂时没有receiver来取，也不会丢失。 消息发布接收策略 一对多的消息发布接收策略，监听同一个topic地址的多个sub都能收到publisher发送的消息。Sub接收完通知mq服务器 一对一的消息发布接收策略，一个sender发送的消息，只能有一个receiver接收。receiver接收完后，通知mq服务器已接收，mq服务器对queue里的消息采取删除或其他操作。 文章来源: Queue与Topic区别

# !/usr/bin/python # -*- coding:utf-8 -*- import numpy as np import matplotlib.pyplot as plt import matplotlib as mpl import lda import lda.datasets from pprint import pprint if __name__ == "__main__": # document-term matrix X = lda.datasets.load_reuters() print("type(X): {}".format(type(X))) print("shape: {}\n".format(X.shape)) print(X[:10, :10]) # the vocab vocab = lda.datasets.load_reuters_vocab() print("type(vocab): {}".format(type(vocab))) print("len(vocab): {}\n".format(len(vocab))) print(vocab[:10]) # titles for each story titles = lda.datasets.load_reuters_titles() print("type(titles):

RocketMQ提供有控制台及一系列控制台命令，用于管理员对主题，集群，broker等信息的管理； 使用步骤 进入rocketmq目录下的bin目录，可以看到该目录下有个mqadmin脚本 常用命令 查看帮助： sh mqadmin help 命令名称 例如，查看updateTopic的使用 sh mqadmin help updateTopic 创建（修改）topic 指令 updateTopic 类路径 com.alibaba.rocketmq.tools.command.topic.UpdateTopicSubCommand 参数 是否必填 说明 -b 如果 -c为空，则必填 broker地址，表示topic建在该broker -c 如果 -b为空，则必填 cluster名称，表示topic建在该集群（集群可通过clusterList查询） -h 否 打印帮助 -n 是 nameserve服务地址列表，格式ip:port;ip:port;... -p 否 指定新topic的权限限制( W|R|WR ) -r 否 可读队列数（默认为8） -w 否 可写队列数（默认为8） -t 是 topic名称（名称只能使用字符 ^[a-zA-Z0-9_-]+$ ） 举例 在集群DefaultCluster上创建主题ZTEExample，nameserve地址为10.45.47.168

在上篇博客中我们了解了RocketMQ的ACK机制，其中涉及到了消息消费重试，当重试次数达到默认的16次后（可以通过配置文件修改）如果对应的消息还没被成功消费的话，该消息 就会投递到DLQ死信队列。 不过，在使用控制台查询死信消息队列的时候会报错，具体如下图 org.apache.rocketmq.client.exception.MQClientException: Can not find Message Queue for this topic, %DLQ%consumer1 See http://rocketmq.apache.org/docs/faq/ for further details. 对应服务器进入相关的目录下，/usr/local/rocketmq/store/consumequeue，发现确实是存在%DLQ%consumer1 我们通过进入到，通过rocketmq的管理命令（先进入 /usr/local/rocketmq/bin）查看所有的topic，发现也确实能够找到 sh mqadmin topicList -n 192.168.140.129:9876;192.168.140.128:9876 查看该topic信息，发现perm为2 sh mqadmin topicRoute -n 192.168.140.129:9876 -t %DLQ

上一篇博文中，我们使用direct exchange 代替了fanout exchange，这次我们来看下topic exchange。 一、Topic Exchange介绍 topic exchange和direct exchange类似，都是通过routing key和binding key进行匹配，不同的是topic exchange可以为routing key设置多重标准。 direct路由器类似于sql语句中的精确查询；topic 路由器有点类似于sql语句中的模糊查询。 还记得吗？我们在《 RabbitMQ入门：发布/订阅（Publish/Subscribe） 》中对exchange的分类进行过介绍： Direct：完全根据key进行投递的，例如，绑定时设置了routing key为”abc”，那么客户端提交的消息，只有设置了key为”abc”的才会投递到队列。 Topic：对key进行模式匹配后进行投递，符号”#”匹配一个或多个词，符号” *”匹配正好一个词。例如”abc.#”匹配”abc.def.ghi”，”abc.* ”只匹配”abc.def”。 Fanout：不需要key，它采取广播模式，一个消息进来时，投递到与该交换机绑定的所有队列。 Headers:我们可以不考虑它。 下面是官网给出的工作模型（P代表生产者，X代表exhange，红色的Q代表队列

Pull消费者客户端(主动拉取消息的消费者)即构造了DefaultMQPullConsumer对象，DefaultMQPullConsumer继承了ClientConfig类。我们先看其构造方法 public DefaultMQPullConsumer(final String consumerGroup, RPCHook rpcHook) { this.consumerGroup = consumerGroup; defaultMQPullConsumerImpl = new DefaultMQPullConsumerImpl(this, rpcHook); } 这里只是简单设置了consumerGroup消费者组名，表示消费者属于哪个组。构造了DefaultMQPullConsumerImpl的实例，DefaultMQPullConsumerImpl的构造方法很简单，只是绑定了DefaultMQPullConsumer、配置了传入的rpcHook。 DefaultMQPullConsumer内部封装了DefaultMQPullConsumerImpl，其中还维护这一些配置信息。这里维护着消费者订阅的topic集合。 private Set<String> registerTopics = new HashSet<String>(); 整个消费者客户端的启动

有时在运行订阅者节点时希望该节点在接收到话题消息之后，能够将经过相应处理的消息发布给其他节点，这样就要求订阅者节点具备同时发送和接收消息的能力． 　　下面将编写一个用于解析CAN报文的功能包，其中的一个订阅者节点在解析完订阅到的CAN报文之后会将解析的内容发布出去． 功能包(can_analysis_topic)的package.xml文件: 功能包(can_analysis_topic)的CMakeLists.txt文件: 功能包(can_analysis_topic)的 msg文件： Control.msg文件 Frame.msg文件 功能包(can_analysis_topic)的发布者节点can_topic_publisher代码： 它负责将报文的ID和数据发布出去 功能包(can_analysis_topic)的订阅者节点can_topic_subscriber代码： 它负责将订阅到的CAN报文进行解析并将解析内容发布出去 功能包(can_analysis_topic)的测试节点can_topic_test代码： 这个节点主要用来测试can_topic_subscriber节点能否将报文解析内容成功发布出来 实验结果如下： 运行can_topic_publisher 运行can_topic_subscriber 运行can_topic_test 文章来源: ROS学习（四

什么是Kafka？ 分布式 、 流数据 平台，类似消息队列 流数据平台可以：1、发布和订阅流数据 用于暂存重要数据） Kafka通常用来做告诉输出的缓存，这是由于它变态的性能。另外它可以暂存重要数据，因为从Kafka消费（读取）数据后数据是不会立即删除的，而且这些数据可以设置备份。 Kafka的API Producer：用于向Kafka生产数据，单个producer可以对应多topics Consumer：用于从Kafka消费数据，单个consumer可以对应多topics Streams：用于做简单的流数据处理，可生产可消费，多topics Connector：用于创建运行多个producer和consumer 多语言：Java等主流语言都有对应的API Topic：records的分类，所有record都是发布到某一个topic的 Record：{key,value,timestamp} 可以把Kafka理解为不可修改的queue（of records），保存一段历史时间的数据eg.两天 每个consumer元数据只保存一个offset，可由consumer自由控制，也就是说offset不一定是简单递增的，如果有这个需要，可以返回读取两天前的数据，或者直接读取最新的数据 Partition 一个topic被分为多个partition，可存在不同机器上