topic

Guide哥答应大家的 Kafka系列的第2篇原创文章。为了保证内容实时更新，我将相关文章也发送到了Gihub上！地址 ：https://github.com/Snailclimb/springboot-kafka 相关阅读： 入门篇！大白话带你认识 Kafka！ 前置条件：你的电脑已经安装 Docker 主要内容： 使用 Docker 安装 使用命令行测试消息队列的功能 zookeeper和kafka可视化管理工具 Java 程序中简单使用Kafka 使用 Docker 安装搭建Kafka环境 单机版 下面使用的单机版的Kafka 来作为演示，推荐先搭建单机版的Kafka来学习。 以下使用 Docker 搭建Kafka基本环境来自开源项目： https://github.com/simplesteph/kafka-stack-docker-compose 。当然，你也可以按照官方提供的来： https://github.com/wurstmeister/kafka-docker/blob/master/docker-compose.yml 。 新建一个名为 zk-single-kafka-single.yml 的文件，文件内容如下： version: '2.1' services: zoo1: image: zookeeper:3.4.9 hostname: zoo1 ports

 这节介绍Producer发送消息的流程。  接上一节开头的Demo，发送消息的写法如下： public class SyncProducer { public static void main (String[] args) throws Exception { // 实例化消息生产者Producer DefaultMQProducer producer = new DefaultMQProducer ("GroupTest"); // 设置NameServer的地址 producer.setNamesrvAddr ("localhost:9876"); // 启动Producer实例 producer.start (); for (int i = 0; i < 100; i++) { // 创建消息，并指定Topic，Tag和消息体 Message msg = new Message ("TopicTest" /* Topic */, "TagA" /* Tag */, ("Hello RocketMQ " + i).getBytes (RemotingHelper.DEFAULT_CHARSET) /* Message body */ ); // 发送消息到一个Broker SendResult sendResult = producer.send (msg); //

一、Kafka 概述 Kafka 是一个分布式的基于发布/订阅模式的消息队列（Message Queue），主要应用于 大数据实时处理领域。 二、消息队列的两种模式 （1）点对点模式（一对一 ，消费者主动拉取数据，消息收到后消息清除） 消息生产者生产消息发送到Queue中，然后消息消费者从Queue中取出并且消费消息。 消息被消费以后，queue 中不再有存储，所以消息消费者不可能消费到已经被消费的消息。 Queue 支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。 （2）发布/订阅模式（一对多 ，消费者消费数据之后不会清除消息） 消息生产者（发布）将消息发布到 topic 中，同时有多个消息消费者（订阅）消费该消 息。和点对点方式不同，发布到 topic 的消息会被所有订阅者消费。 三、kafka下载和环境准备 kafaka下载地址： http://kafka.apache.org/downloads.html 选择自己需要对应的scala版本进行下载。 3.1 集群规划 准备三台虚拟机这三台虚拟机也完成了zookeeper的集群规划，没有完成的可以参考这一篇 Zookeeper集群部署 。 四、配置环境 4.1 解压安装包，并修改解压后的文件名称 tar - zxvf kafka_2 . 12 - 2.3 .0 . tgz mv kafka_2 . 12 -

Kafka集群升级（2.11-0.10.1.0）升级（2.11-0.10.2.2） 官网升级说明： 一、系统环境 Zookeeper集群： 172.16.2.10 172.16.2.11 172.16.2.12 Kafka集群： 172.16.2.10 172.16.2.11 172.16.2.12 现Kafka版本： 2.11-0.10.1.0，安装目录：/usr/local/kafka 计划升级至版本：2.11-0.10.2.2，安装目录：/usr/local/kafka_2.11-0.10.2.2 二、创建测试topic 1.创建测试topic /usr/local/kafka/bin/kafka-topics.sh --zookeeper 172.16.2.10:2181,172.16.2.11:2181,172.16.2.12:2181 --create --replication-factor 3 --partitions 2 --topic first /usr/local/kafka/bin/kafka-topics.sh --zookeeper 172.16.2.10:2181,172.16.2.11:2181,172.16.2.12:2181 --create --replication-factor 2 --partitions 1 --topic

文章目录 一.入门 1.1 简介 Topics/logs Distribution Producers Consumers Guarantees 1.2 Use cases Messaging Websit activity tracking Log Aggregation 二. 设计原理 1.Persistence 2.Efficiency 3. Producer Load balancing Asynchronous send 4.Consumer 5.Message Delivery Semantics 6. Replication 7.Log 8.Distribution 总结: 三.主要配置 1.Broker主要配置 2.Consumer主要配置 3.Producer主要配置 前言: Kafka是一个轻量级的/分布式的/具备replication能力的日志采集组件,通常被集成到应用系统中,收集"用户行为日志"等,并可以使用各种消费终端(consumer)将消息转存到HDFS等其他结构化数据存储系统中.因为日志消息通常为文本数据,尺寸较小,且对实时性以及数据可靠性要求不严格,但是需要日志存储端具备较高的数据吞吐能力,这种"宽松"的设计要求,非常适合使用kafka。 一.入门 1.1 简介 Kafka是一个"分布式的"/“可分区的(partitioned)”/“基于备份的

Kafka 创建背景 Kafka 是一个消息系统，原本开发自 LinkedIn，用作 LinkedIn 的活动流（Activity Stream）和运营数据处理管道（Pipeline）的基础。现在它已被多家不同类型的公司 作为多种类型的数据管道和消息系统使用。 活动流数据是几乎所有站点在对其网站使用情况做报表时都要用到的数据中最常规的部分。活动数据包括页面访问量（Page View）、被查看内容方面的信息以及搜索情况等内容。这种数据通常的处理方式是先把各种活动以日志的形式写入某种文件，然后周期性地对这些文件进行统计分析。运营数据指的是服务器的性能数据（CPU、IO 使用率、请求时间、服务日志等等数据)。运营数据的统计方法种类繁多。 近年来，活动和运营数据处理已经成为了网站软件产品特性中一个至关重要的组成部分，这就需要一套稍微更加复杂的基础设施对其提供支持。 Kafka 简介 Kafka 是一种分布式的，基于发布 / 订阅的消息系统。 主要设计目标如下： 以时间复杂度为 O(1) 的方式提供消息持久化能力，即使对 TB 级以上数据也能保证常数时间复杂度的访问性能。 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒 100K 条以上消息的传输。 支持 Kafka Server 间的消息分区，及分布式消费，同时保证每个 Partition 内的消息顺序传输。

NB-IoT 学习开发和应用 第四讲 阿里云物联网平台中的CoAP协议学习和分析 CoAP协议：CoAP协议的底层协议是 UDP (比喻：打电话，单方通信，无需保持链接) 应用范围： NB-IoT、超低功耗应用、野外数据采集监控系统、远程抄表等 特点 ：只能数据上报（注：在CoAP协议的定义中，非底层的UDP协议），服务器无法对数据进行下发控制指令。 CoAP协议报文（一共只有4个） 分别是： 1、CON报文（连接请求报文），给服务器发报文，并且发送完以后，服务器必须要发送ACK报文给设备端(即响应报文) 2、NON报文（发送给服务器，服务器无需回复） 3、ACK报文 （响应报文） 4、RST报文（代表数据发送错误，提醒用户重新发送正确的数据给服务区） 注：且在阿里云物联网平台中的的CoAP协议中，只支持 CON 报文的数据类型。其他数据格式或者协议，服务器均不支持。 同时，在阿里云物联网服务器中，上传的数据有两种形式（CON的两种形式） 1、设备认证报文 2、数据上传报文 CoAP协议报文的格式组成形式： Ver+T+TKL+Code+Messige ID+Token+Options+0xff(分隔字符)+Payload 拆分分析： Ver ： 版本号 2bit T : 报文类型 2bit （CON : 00 NON : 01 ACK : 10 RST : 11 ） TKL :

消息队列 为什么要用消息队列，都有什么优缺点？ 要问的是消息队列都有哪些场景，然后项目里具体实现的什么场景，你在这个场景里用的什么消息队列？ 期望的回答是， 你们公司有个什么业务，这个业务场景有什么技术挑战，如果不用MQ可能会很麻烦，但是你现在用了MQ带给你什么好处？ 场景比较多，但是比较核心的是3个： 解耦、异步、削峰 解耦 ​ 需要去考虑你负责的系统中是否有类似的场景，一个系统调用了多个系统和模块，互相之间的调用很复杂，维护起来很麻烦。但是这个调用并不需要直接同步调用接口，如果用MQ给它异步化解耦，也是可以的，你就需要 考虑在你的项目中，是不是可以运用这个MQ去进行解耦。在简历中体现出来 异步化 异步化可以大幅度提升高延迟接口的性能 削锋： 未使用MQ的时候： 使用MQ以后： 系统架构中引入MQ后可能存在的缺陷： 系统可用性降低：系统引入的外部依赖越多，越容易挂掉。 系统的复杂性更高：需要考虑的问题越多 一致性问题 问题2：kafka,activeMq,rabbitMq,rocketMq 都有什么优缺点？ 特性 ACTIVEMQ RABBITMQ ROCKETMQ KAFKA 单击吞吐量 万级吞吐量，相比RocketMq和Kafka要第一个数量级 万级，吞吐量相比RocketMq和 Kafka要低一个数量级 10万级，RocketMq也是可以支撑高吞吐的一种MQ 10万级别

转载，原文地址 https://www.cnblogs.com/liuwei6/p/6900686.html 一、 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，而是没有新建立

上图中一个topic配置了3个partition。Partition1有两个offset：0和1。Partition2有4个offset。Partition3有1个offset。副本的id和副本所在的机器的id恰好相同。 如果一个topic的副本数为3，那么Kafka将在集群中为每个partition创建3个相同的副本。集群中的每个broker存储一个或多个partition。多个producer和consumer可同时生产和消费数据。 一 。Broker Kafka 集群包含一个或多个服务器，服务器节点称为broker。 broker存储topic的数据。如果某topic有N个partition，集群有N个broker，那么每个broker存储该topic的一个partition。 如果某topic有N个partition，集群有(N+M)个broker，那么其中有N个broker存储该topic的一个partition，剩下的M个broker不存储该topic的partition数据。 如果某topic有N个partition，集群中broker数目少于N个，那么一个broker存储该topic的一个或多个partition。在实际生产环境中，尽量避免这种情况的发生，这种情况容易导致Kafka集群数据不均衡。 二。Topic 每条发布到Kafka集群的消息都有一个类别