kafka命令

日志是每个系统最为头疼的地方，杂乱，还多，没有还不行，想管理好的话，得经得起考验，要解决的问题总结如下： （1）高并发 （2）高吞吐量 （3）支持分布式集群 （4）检索要快 简介： 1.Zoomkeeper Kafka的通道 2. Kafka Kafka主要是解决大量日志的处理的分布式发布订阅消息系统，拥有高吞吐量，相比Redis而言，可能存在数据丢失的情况，速度更快，仅支持topic模式，更适合做日志系统 3.Logstash Logstash是一个写入工具，可以说是一个桥梁，实现将kafka的consumer端和Elasticsearch数据连通有很大作用，另外也可以将文件写入到Elasticsearch中，还可以将历史的日志也转存到Elasticsearch中，还是个多功能的工具，官方最新版本中已经默认支持了对Kafka和Elasticsearch的配置 4.Elasticsearch Elasticsearch是可以分布式集群部署的全文搜索引擎服务器（NoSQL数据存储），既拥有Lucene的全文检索功能，同时还能进行分布式储存，检索速度快，与Hadoop联合作数据分析，稳健性高，可以在一个集群宕机后，使用备用集群，一样可以工作，缺点：需要足够的内存和CPU资源 5.Kibana Kibana主要用于对Elasticsearch数据的展示和分析 方案：

kafka运维常用查询操作总结以下几点： kafka生产和消费消息测试 发送：bin/kafka-console-producer.sh --broker-list 10.46.200.165:9092 --topic contentApprove 接收：bin/kafka-console-consumer.sh --bootstrap-server 10.46.200.165:9092 --topic contentApprove --from-beginning 创建topic命令参考 .bin/kafka-topics.sh --create --zookeeper localhost:2181 --partitions 6 --replication-factor 2 --topic test ### --partition：创建分区数，一般可以是服务器数量的双倍 ### --replication-factor：副本数默认为1，表示没有副本。保证冗余必须最少2 kafka修改副本数 bin/kafka-reassign-partitions.sh --zookeeper 10.124.77.41:2181 --reassignment-json-file test.json –execute 将分区数3修改为9 bin/kafka-topics.sh -

前言 最近在用kafka做项目，所以本地搭建下kafka，但是又嫌java安装和安装kafka太麻烦，所以想到用docker来部署。 镜像 wurstmeister/kafka 维护较为频繁的一个Kafka镜像。只包含了Kafka，因此需要另行提供ZooKeeper，推荐使用同一作者提交的wurstmeister/zookeeper。 现在已经提供较新的1.1.0版本。 搭建开发环境 1 ZooKeeper &1 Kafka 这里以我自己最常用的wurstmeister/kafka为例，使用docker-compose运行一个只有一个ZooKeeper node和一个Kafka broker的开发环境： docker-compose.yml version: '2' services: zoo1: image: wurstmeister/zookeeper restart: unless-stopped hostname: zoo1 ports: - "2181:2181" container_name: zookeeper # kafka version: 1.1.0 # scala version: 2.12 kafka1: image: wurstmeister/kafka ports: - "9092:9092" environment: KAFKA_ADVERTISED

架构、分布式、日志队列，标题自己都看着唬人，其实就是一个日志收集的功能，只不过中间加了一个Kafka做消息队列罢了。 kafka介绍 Kafka是由Apache软件基金会开发的一个开源流处理平台，由Scala和Java编写。Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。 这种动作（网页浏览，搜索和其他用户的行动）是在现代网络上的许多社会功能的一个关键因素。 这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。 特性 Kafka是一种高吞吐量的分布式发布订阅消息系统，有如下特性： 通过O(1)的磁盘数据结构提供消息的持久化，这种结构对于即使数以TB的消息存储也能够保持长时间的稳定性能。 高吞吐量：即使是非常普通的硬件Kafka也可以支持每秒数百万的消息。 支持通过Kafka服务器和消费机集群来分区消息。 支持Hadoop并行数据加载。 主要功能 发布和订阅消息流，这个功能类似于消息队列，这也是kafka归类为消息队列框架的原因 以容错的方式记录消息流，kafka以文件的方式来存储消息流 可以再消息发布的时候进行处理 使用场景 在系统或应用程序之间构建可靠的用于传输实时数据的管道，消息队列功能 构建实时的流数据处理程序来变换或处理数据流，数据处理功能 消息传输流程 相关术语介绍 Broker Kafka集群包含一个或多个服务器

Kafka kafka是什么？kafka仅仅是属于消息 中间件吗？ kafka在设计之初的时候 开发人员们在除了消息中间件以外，还想吧kafka设计为一个能够存储数据的系统，有点像 常见的非关系型数据库，比如说NoSql等。除此之外 还希望kafka能支持持续变化，不断增长的数据流, 可以发布 和订阅数据流，还可以对于这些数据进行保存 也就是说kafka的本质 是一个数据存储平台，流平台 ， 只是他在做消息发布，消息消费的时候我们可以把他当做 消息中间件来用。 而且kafka在设计之初就是采用分布式架构设计的， 基于集群的方式工作，且可以自由伸缩，所以 kafka构建集群 非常简单 基本概念： Broker : 和AMQP里协议的概念一样， 就是消息中间件所在的服务器 Topic(主题) : 每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。（物理上不同Topic的消息 分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消 费数据而不必关心数据存于何处） Partition(分区) : Partition是物理上的概念，体现在磁盘上面，每个Topic包含一个或多个Partition. Producer : 负责发布消息到Kafka broker Consumer : 消息消费者，向Kafka

Kafka【第一篇】Kafka集群搭建 Kafka初识 1、Kafka使用背景 在我们大量使用分布式数据库、分布式计算集群的时候，是否会遇到这样的一些问题： 我们想分析下用户行为（pageviews），以便我们设计出更好的广告位 我想对用户的搜索关键词进行统计，分析出当前的流行趋势 有些数据，存储数据库浪费，直接存储硬盘效率又低 这些场景都有一个共同点： 数据是由上游模块产生，上游模块，使用上游模块的数据计算、统计、分析，这个时候就可以使用消息系统，尤其是分布式消息系统！ 2、Kafka的定义 What is Kafka：它是一个分布式消息系统，由linkedin使用scala编写，用作LinkedIn的活动流（Activity Stream）和运营数据处理管道（Pipeline）的基础。具有高水平扩展和高吞吐量。 3、Kafka和其他主流分布式消息系统的对比 定义解释： 1、Java 和 scala都是运行在JVM上的语言。 2、erlang和最近比较火的和go语言一样是从代码级别就支持高并发的一种语言，所以RabbitMQ天生就有很高的并发性能，但是 有RabbitMQ严格按照AMQP进行实现，受到了很多限制。kafka的设计目标是高吞吐量，所以kafka自己设计了一套高性能但是不通用的协议，他也是仿照AMQP（ Advanced Message Queuing

原创文章，转载请务必将下面这段话置于文章开头处。（已授权 InfoQ中文站发布 ） 　　本文转发自 Jason's Blog ， 原文链接 　 http://www.jasongj.com/2015/08/09/KafkaColumn4 摘要 本文主要介绍了Kafka High Level Consumer，Consumer Group，Consumer Rebalance，Low Level Consumer实现的语义，以及适用场景。以及未来版本中对High Level Consumer的重新设计--使用Consumer Coordinator解决Split Brain和Herd等问题。 High Level Consumer 很多时候，客户程序只是希望从Kafka读取数据，不太关心消息offset的处理。同时也希望提供一些语义，例如同一条消息只被某一个Consumer消费（单播）或被所有Consumer消费（广播）。因此，Kafka Hight Level Consumer提供了一个从Kafka消费数据的高层抽象，从而屏蔽掉其中的细节并提供丰富的语义。 Consumer Group High Level Consumer将从某个Partition读取的最后一条消息的offset存于Zookeeper中( Kafka从0.8.2版本

3 月，跳不动了？>>> 上次的 Kafka 重启失败事件，对为什么重启失败的原因似乎并没有解释清楚，那么我就在这里按照我对 Kafka 的认识，从源码和日志文件结构去尝试寻找原因。 从源码中定位到问题的根源 首先把导致 Kafka 进程退出的异常栈贴出来： 注：以下源码基于 kafka 0.11.0.2 版本。 我们直接从 index 文件损坏警告日志的位置开始： kafka.log.Log#loadSegmentFiles 从前一篇文章中已经说到，Kafka 在启动的时候，会检查kafka是否为 cleanshutdown，判断依据为 ${log.dirs} 目录中是否存在 .kafka_cleanshutDown 的文件，如果非正常退出就没有这个文件，接着就需要 recover log 处理，在处理中会调用 。 在 recover 前，会调用 sanityCheck() 方法用于检验每个 log sement 的 index 文件，确保索引文件的完整性 ，如果发现索引文件损坏，删除并调用 recoverSegment() 方法进行索引文件的重构，最终会调用 recover() 方法： kafka.log.LogSegment#recover 源码中相关变量说明： log：当前日志 Segment 文件的对象； batchs：一个 log segment 的消息压缩批次；

kafka 相关术语： 术语 含义 producer，产生消息 消息生产者，发布消息到 kafka 集群的终端或服务。 consumer，消费消息 从 kafka 集群中消费消息的终端或服务。 topic，主题，在主题里分布消息 每条发布到 kafka 集群的消息属于的类别，即 kafka 是面向 topic 的。 broker，服务器 kafka 集群中包含的服务器。 Consumer group high-level consumer API 中，每个 consumer 都属于一个 consumer group，每条消息只能被 consumer group 中的一个 Consumer 消费，但可以被多个 consumer group 消费。 partition partition 是物理上的概念，每个 topic 包含一个或多个 partition。kafka 分配的单位是 partition。 replica partition 的副本，保障 partition 的高可用。 leader replica 中的一个角色， producer 和 consumer 只跟 leader 交互。 follower replica 中的一个角色，从 leader 中复制数据。 controller kafka 集群中的其中一个服务器，用来进行 leader election 以及 各种

Kafka主要构成： 1、Broker：集群中的每一个对应的服务器被称之为broker。 2、Topic 用于区别消息的类别，每个topic中包含多个 Partition； Partition主要可以减少每个日志的数据量，也可以增加请求的并发量。 3、Producer 消息的生产者，可通过配置partitioner.class设置消息发送到那个 Partition上。 4、Consumer 消息的消费者，可以订阅需要的topics。 其中更多的其他术语可以参考 kafka官方文档 。 Kafka配置：通过官网下载并安装，通过文件config下的相关properties进行配置； server.properties启动服务时的相关配置，可拷贝多个配置多个broker服务(单台服务器上配置多个broker服务的方式)，如 server-1.properties console-xxxx .properties启动相关控制台的配置。 1、 server.properties配置文件，启动命令 kafka：bin/kafka-server-start.sh config/server.properties # broker_id，集群环境下不能重复 broker.id=0 # broker 开放的端口 port=9092 # broker 绑定的主机名 host.name