topic

一，问题描述 搭建的用来测试的单节点Kafka集群（Zookeeper和Kafka Broker都在 同一台Ubuntu 上），在命令行下使用： ./bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 3 --topic topicForTest 创建了一个3个分区的Topic如下：（Topic名称为 topicForTest） 使用 Console producer/consumer都能够正常地向topicForTest发送和接收消息： bin/kafka-console-producer.sh --broker-list localhost:9092 --topic topicForTest bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic topicForTest --from-beginning 但是在自己的windows 机器的开发环境下，使用kafka client JAVA API （0.10版本）中的KafkaConsumer 却无法接收消息，表现为：在poll()方法中阻塞了。 更具体一点地，是在：org.apache.kafka

概述 听到这个名字是不是很熟悉，没错这个名字就是文学家卡夫卡的英文，传说中国的王小波也被誉为东方的乔伊斯+卡夫卡，哈哈哈，当然这篇文章不是谈论文学家卡夫卡的，那为什么一个消息中间件叫kafka呢？很简单就是这个中间件的作者喜欢卡夫卡，所以就这么命名了，如果有一天你也写出来一个牛逼的软件，而且你也很喜欢王小波，那你可以命名为xiaobo，没人可以拦得住你。 kafka架构 先上图（开篇一张图，内容全靠编） kafka broker : 从图中可以看出，这家伙是喜欢搞黄色的^_^，其实broker是kafka的基础存储单位，kafka所谓的分布式完全由多个broker一起组成的。 Topic ：这个图中没有体现，不过很简单，所谓的Topic就是消息，每个种类的消息都有一个topic，这就像你在数据库中要给学生建立一张表，给老师建立一张表一样。 Partition ：这个图中也没有体现，不过也很简单，有了Topic，你肯定要把Topic存储到broker中吧，既然broker有好多，那你不可能把一个Topic都存到一个broker里面吧，就像一个皇帝，怎么说也要做到雨露均沾，当然了，真实的原因并不是因为Topic喜欢瞎搞，而是因为这样可以提高吞吐量，一个节点肯定没有多个节点一起处理处理的快啊。那既然要分开存储就有了partition的概念

性能测试及集群监控工具 Kafka提供了非常多有用的工具，如 Kafka设计解析（三）- Kafka High Availability （下） 中提到的运维类工具——Partition Reassign Tool，Preferred Replica Leader Election Tool，Replica Verification Tool，State Change Log Merge Tool。本章将介绍Kafka提供的性能测试工具，Metrics报告工具及Yahoo开源的Kafka Manager。 Kafka性能测试脚本 $KAFKA_HOME/bin/kafka-producer-perf-test.sh 该脚本被设计用于测试Kafka Producer的性能，主要输出4项指标，总共发送消息量（以MB为单位），每秒发送消息量（MB/second），发送消息总数，每秒发送消息数（records/second）。除了将测试结果输出到标准输出外，该脚本还提供CSV Reporter，即将结果以CSV文件的形式存储，便于在其它分析工具中使用该测试结果 $KAFKA_HOME/bin/kafka-consumer-perf-test.sh 该脚本用于测试Kafka Consumer的性能，测试指标与Producer性能测试脚本一样。 Kafka Metrics Kafka使用

kafka 架构Terminology(术语) broker（代理） 　　Kafka集群包含一个或多个服务器，这种服务器被称为broker Topic 　　每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic（可以理解为队列queue或者 目录 ）。物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处。　　 Partition 　　Parition是物理上的概念（可以理解为 文件夹 ），每个Topic包含一个或多个Partition。 Producer　　 　　生产者，负责发布消息到Kafka broker。 Consumer 　　消息消费者，向Kafka broker读取消息的客户端。 Consumer Group 　　每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group）。 Kafka拓扑结构 Topic & Partition 　topic可以看成不同消息的类别或者信息流，不同的消息根据就是通过不同的topic进行分类或者汇总，然后producer将不同分类的消息发往不同的topic。对于每一个topic，kafka集群维护一个分区的日志

SpringBoot整合ActiveMQ 点对点（P2P） 　　创建springboot项目 　　　　 　　导入依赖 　　　　<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-activemq</artifactId> </dependency> 　　生产者 　　　　步骤一：applicationContext.properties文件 spring.activemq.broker-url=tcp://127.0.0.1:61616 spring.activemq.user=admin spring.activemq.password=admin server.port=8080 　　　　步骤二：创建生产者 package com.wn.p2p; import org.apache.activemq.command.ActiveMQQueue; import org.springframework.jms.core.JmsTemplate; import org.springframework.stereotype.Component; import javax.annotation.Resource; @Component public class

定时任务,在很多业务场景中都会存在.一般,我们简单解决的话,就是使用数据库来存储数据供服务端周期获取执行.显然,对于数据库处理,如果多线程或者多机器处理,就会存在扩展的问题.比如:现在一个任务记录到时间了需要执行,同时被多个executor抓取来执行,就会浪费不必要的资源;并且,这种场景还非常常见. 因此, 需要额外状态处理,或者其他分库分表策略保证尽量一个executor来操作一个记录,并且如果executor失败了,其他的executor才会去执行分配给失败executor的任务. 整个设计相对而言,就相当复杂了. 基于上面的一些原因,这里我们设计了一个简单的基于kafka消息队列的定时任务方案. 这里，首先定义一下定时消息。所谓定时消息，就是业务方根据自己的业务需求，指定在接下来的大概某个时间点来发送某条消息，从而保证该消息在某个时间点之后可接受的时间区间内消费该消息。所以这里需要指出： Note: 消息机制都是异步的，所以如果存在大量消息累积未消费，则无法保证定时消息指定的时间区间。因此，使用的时候，必须预计定时消息服务提供的服务能否满足业务的QPS要求。定时消息服务设计保证支持水平扩展，因此，可以根据业务性能需求，部署足够的服务。 kafka消息队列，所有触发都是基于消息机制的。所以，定时任务的设计必须要有定时消息服务来提供基础核心功能。首先

RocketMQ简介 1.RocketMQ是一款分布式、队列模型的消息中间件，是阿里巴巴集团自主研发的专业消息中间件，借鉴参考了JMS规范的MQ实现，更参考了优秀的开源消息中间件KAFKA,实现了业务消峰、分布式事务的优秀框架。 2.其底层代码编写清晰优秀，采用 Netty NIO 框架进行数据通信 3.摒弃了Zookeeper,内部使用更轻量级的NameServer进行网络路由，提高服务性能，并且 支持消息失败重试 机制。 4.天然支持集群模型，消费者负载均衡、水平扩展能力，支持广播模式和集群模式。 5.采用零拷贝的原理、顺序写盘、支持亿级消息堆积能力。 6.提供丰富的消息机制，如顺序消息、事务消息等 MQ基本概念： Message :消息，消息队列中信息传递的载体。 Message ID :消息的全局唯一标识，由 MQ 系统自动生成，唯一标识某条消息。 Message Key :消息的业务标识，由消息生产者（Producer）设置，唯一标识某个业务逻辑。 Topic :消息主题，一级消息类型，通过 Topic 对消息进行分类。 Tag :消息标签，二级消息类型，用来进一步区分某个 Topic 下的消息分类。 Producer :消息生产者，也称为消息发布者，负责生产并发送消息。 Producer ID ：一类 Producer 的标识，这类 Producer

消息轨迹 1. 消息轨迹数据关键属性 Producer端 Consumer端 Broker端 生产实例信息 消费实例信息 消息的Topic 发送消息时间 投递时间,投递轮次 消息存储位置 消息是否发送成功 消息是否消费成功 消息的Key值 发送耗时 消费耗时 消息的Tag值 2. 支持消息轨迹集群部署 2.1 Broker端配置文件 这里贴出Broker端开启消息轨迹特性的properties配置文件内容： brokerClusterName=DefaultCluster brokerName=broker-a brokerId=0 deleteWhen=04 fileReservedTime=48 brokerRole=ASYNC_MASTER flushDiskType=ASYNC_FLUSH storePathRootDir=/data/rocketmq/rootdir-a-m storePathCommitLog=/data/rocketmq/commitlog-a-m autoCreateSubscriptionGroup=true ## if msg tracing is open,the flag will be true traceTopicEnable=true listenPort=10911 brokerIP1=XX.XX.XX.XX1 namesrvAddr

上篇文章 《ActiveMQ系列（二）》 中实现了消息队列模式，本文开始实现主题消息的发布和订阅。 maven依赖 新建springboot的过程不再赘述，这里在pom文件中直接以用maven依赖： < dependency > < groupId > org . springframework . boot < / groupId > < artifactId > spring - boot - starter - activemq < / artifactId > < / dependency > yml配置 spring : activemq : broker - url : tcp : / / 192.168 .17 .101 : 61616 user : admin password : admin jms : pub - sub - domain : true #默认 false = Queue true = Topic #自己定义的主题名称 mytopic : boot - activemq - topic 配置bean @Component @EnableJms public class ActiveMqConfigBean { @Value ( "${mytopic}" ) private String myTopic ; @Bean public Topic

特性(features) 1 订阅与发布 消息的发布是指某个生产者向某个topic发送消息；消息的订阅是指某个消费者关注了某个topic中带有某些tag的消息，进而从该topic消费数据。 2 消息顺序 消息有序指的是一类消息消费时，能按照发送的顺序来消费。例如：一个订单产生了三条消息分别是订单创建、订单付款、订单完成。消费时要按照这个顺序消费才能有意义，但是同时订单之间是可以并行消费的。RocketMQ可以严格的保证消息有序。 顺序消息分为全局顺序消息与分区顺序消息，全局顺序是指某个Topic下的所有消息都要保证顺序；部分顺序消息只要保证每一组消息被顺序消费即可。 全局顺序 对于指定的一个 Topic，所有消息按照严格的先入先出（FIFO）的顺序进行发布和消费。 适用场景：性能要求不高，所有的消息严格按照 FIFO 原则进行消息发布和消费的场景 分区顺序 对于指定的一个 Topic，所有消息根据 sharding key 进行区块分区。 同一个分区内的消息按照严格的 FIFO 顺序进行发布和消费。 Sharding key 是顺序消息中用来区分不同分区的关键字段，和普通消息的 Key 是完全不同的概念。 适用场景：性能要求高，以 sharding key 作为分区字段，在同一个区块中严格的按照 FIFO 原则进行消息发布和消费的场景。 3 消息过滤