wr_java的博客

而 offset 的信息在 kafka0.8 版本之前保存在 zookeeper 中，在 0.8 版本之后保存到 topic 中，即使消费者在运行过程中挂掉了，再次启动的时候会找到 offset 的值，找到之前消费消息的位置，接着消费，由于 offset 的信息写入的时候并不是每条消息消费完成后都写入的，所以这种情况有可能会造成重复消费，但是不会丢失消息。可以采用一对多的方式，一个生产者发布消息，可以被多个订阅 topic 的服务消费到，供多个毫无关联的业务使用。可以简化代码的实现逻辑，减少出错的可能;

kafka和rocketMq都使用文件存储，但是kafka是一个分区一个文件，当topic过多，分区的总量也会增加，kafka中存在过多的文件，当对消息刷盘时，就会出现文件竞争磁盘，出现性能的下降。rocketMq所有的队列都存储在一个文件中，每个队列的存储的消息量也比较小，因此topic的增加对rocketMq的性能的影响较小。此时减少了网络io，从而提高了消息发送的性能，但是如果消息发送者宕机，会导致消息丢失，业务出错，所以理论上kafka利用此机制提高了io性能却降低了可靠性。

Kafka要严格意义上保证消息不丢失，需要从三个方面来设置，第一个服务器端持久化设置为同步刷盘、第二个生产者设置为同步投递，第三个消费端设置为手动提交。

这是系列文章，之前的文章如下： Telegraf监控客户端调研笔记（1）-介绍、安装、初步测试 Telegraf大家有了基本了解了，但是能否用好，未必喽，今天我着重调研了一下Telegraf对CPU、内存、硬盘相关指标的采集，大部分指标还算容易理解，硬盘IO相关的有点麻烦，好，下面开始介绍。CPUCPU相关的指标比较简单，配置也比较简单，在inputs.cpu这个section，具体如下：# Read metrics about cpu usage[[inputs.cpu]]

淘宝内部的交易系统使用了淘宝自主研发的Notify消息中间件，使用Mysql作为消息存储媒介，可完全水平扩容，为了进一步降低成本，我们认为存储部分可以进一步优化，2011年初，Linkin开源了Kafka这个优秀的消息中间件，淘宝中间件团队在对Kafka做过充分Review之后，Kafka无限消息堆积，高效的持久化速度吸引了我们，但是同时发现这个消息系统主要定位于日志传输，对于使用在淘宝交易、订单、充值等场景下还有诸多特性不满足，为此我们重新用Java语言编写了RocketMQ，定位于非日志的可靠消息传输（

每一个分区都是一个顺序的、不可变的消息队列，并且可以持续的添加。分区中的消息都被分配了一个序列号，称之为偏移量(offset),在每个分区中此偏移量都是唯一的。一个分区在文件系统里存储为一个文件夹。文件夹里包含日志文件和索引文件。其文件名是其包含的offset的最小的条目的offset。每个文件是一个segment。在broker的log存储文件下，除了存储这各个topic的文件夹，还存在这几个checkpoint文件。分别是 recovery-point-offset-check..

一、为什么需要消息系统1.解耦：　　允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。2.冗余：　　消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。3.扩展性：　　因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。4.灵活性

前提条件： 在启动broker时候开启删除topic的开关，即在server.properties中添加：delete.topic.enable=true命令：bin/kafka-topics.sh --zookeeper zk_host:port/chroot --delete --topic my_topic_name这条命令其实就是在zookeeper（假设你的chroot就是/）的/admin/delete_topics下创建一个临时节点，名字就是topic名称，比如如果执行命令：...

kafka迁移与扩容工具使用参考官网site:https://cwiki.apache.org/confluence/display/KAFKA/Replication+tools#Replicationtools-6.ReassignPartitionsTool说明:当我们对kafka集群扩容时，需要满足2点要求:将指定topic迁移到集群内新增的node上。 将topic的指定partition迁移到新增的node上。1. 迁移topic到新增的node上假如现在一个kafka集

一、KafkaOffsetMonitor简述KafkaOffsetMonitor是Kafka的一款客户端消费监控工具，用来实时监控Kafka服务的Consumer以及它们所在的Partition中的Offset，我们可以浏览当前的消费者组，并且每个Topic的所有Partition的消费情况都可以一目了然。二、KafkaOffsetMonitor下载KafkaOffsetMonitor托管在Github上，可以通过Github下载。下载地址：https://github.com/quanti.

通过研究，发现主流的三种kafka监控程序分别为：Kafka Web Conslole Kafka Manager KafkaOffsetMonitor现在依次介绍以上三种工具Kafka Web Conslole使用Kafka Web Console，可以监控： Brokers列表 Kafka 集群中 Topic列表，及对应的Partition、LogSiz e等信息 点击Topic，可以浏览对应的Consumer Groups、Offset、Lag等信息

kafak安装与使用1、前言学习kafka的基础是先把kafka系统部署起来，然后简单的使用它，从直观上感觉它，然后逐步的深入了解它。本文介绍了kafka部署方法，包括配置，安装和简单的使用。2、Kafka的安装与配置准备三台虚拟机，分别是node01，node02，node03，并且修改hosts文件如下：2.1、基础环境配置2.1.1、JDK环境由于Kafka 是用Scala 语言开发的，运行在JVM上，因此在安装Kafka 之前需要先安装JDK 。安装..

具体请参考：apache kafka中server.properties配置文件参数说明配置优化都是修改server.properties文件中参数值1.网络和io操作线程配置优化#broker处理消息的最大线程数num.network.threads=xxx#broker处理磁盘IO的线程数num.io.threads=xxx建议配置：一般num.network.threads主要处理网络io，读写缓冲区数据，基本没有io等待，配置线程数量为cpu核数加1.nu..

1.kafka高性能的特点及条件kafka是一个高吞吐量分布式消息系统，并且提供了持久化。其高性能的有两个重要特点：（1）利用了磁盘连续读写性能远远高于随机读写的特点；（2）并发，将一个topic拆分多个partition。要充分发挥kafka的性能，就需要满足这两个条件。linkedin的测试，就把这两个方面发挥到极致（参考http://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2-million-writes-second

1.设计目标提供可配置，需要保障强可用性可以enable这个功能，如果想要更高的效率而不太在乎数据丢失的话，可以disable这个功能自动replica管理，当cluster发生变化时，即broker server增加或减少时，可以自动的管理和调整replicas2.问题如何将partition的replicas均匀的分配到各个broker servers上面？ 如何进行replicas同步？2.1 如何均匀的分配partition的replicas呢例子如下：有15...

有这么几种可能的delivery guarantee：At most once 消息可能会丢，但绝不会重复传输 At least one 消息绝不会丢，但可能会重复传输 Exactly once 每条消息肯定会被传输一次且仅传输一次，很多时候这是用户所想要的。　当Producer向broker发送消息时，一旦这条消息被commit，因数replication的存在，它就不会丢。但是如果Producer发送数据给broker后，遇到网络问题而造成通信中断，那Producer就无法判断该条消息是否已经

1、背景针对Kafka进行测试的结果中出现的ack为0消费时延比ack为1、-1情况下反而要长，异步生产消费时延较大等疑点，都非常有必要一番配置和代码的梳理。2、核心配置以下所有默认参数是针对kafka 0.9，且主要针对时延这块涉及的核心参数做分析：producer端：buffer.memory：默认32m，每个producer实例可用来存储消息的最大内存空间（在实例中作为一个内存池存在）。retries：kafka默认0次，mafka默认3次，异步发送失败重试次数。batch.s

Kafka基于高吞吐率和效率考虑，并没有使用第三方网络框架，而且自己基于java nio封装的，总体网络模型如下：Broker的内部处理流水线化，分为多个阶段来进行(SEDA)，以提高吞吐量和性能，尽量避免Thead盲等待，以下为过程说明。Accept Thread负责与客户端建立连接链路，然后把Socket轮转交给Process Thread Process Thread负责接收请求和响应数据，Process Thread每次基于Selector事件循环，首先从Response ..

从图中我们可以看出HA的缓存分为生产缓存事件池和拉取缓存事件池两块结构相同的缓存区，分别缓存生产和拉取请求2个缓存事件池的作用：生产缓存事件池：当生产者设置了等待从partition的同步选项(requiredAcks为-1)时才会启动生产缓存。因为每一批生产的消息，需要等待所有的处于同步状态的从partition（in-sync）同步成功，在所有follow partition上报自己的水位线追上leader partition之前，生产请求会一直保留在生产缓存中，等待直到超时。拉取缓存事件池..

重要名词解释：log end offset (logEndOffset)，表示log中最后的message的offst位置.high watermark (HW)，表示Partition各个replicas数据间同步且一致的offset位置，即表示allreplicas已经commit位置，每个Broker缓存中维护此信息,并不断更新。Kafka中replication复制数据Kafka的复制机制既不是完全的同步复制，也不是单纯的异步复制。完全同步复制要求All Alive Follower.

如果MQ没有类似数据库事务结构和保证，是不可能达到消息投递100%可靠的，极端情况下消息投递要么丢失或重复。下面咋们从producer，broker，consumer的角度分析一下Kafka中会出现哪些情况：1.producer发送消息到Broker目前生产者发送消息(request.required.acks)有三种方式。acks =0: producer不会等待broker发送ack ，因为发送消息网络超时或broker crash(1.Partition的Leader还没有com.

(1)(2)当集群中新增2节点，Partition增加到6个时分布情况如下：副本分配逻辑规则如下： 在Kafka集群中，每个Broker都有均等分配Partition的Leader机会。 上述图Broker Partition中，箭头指向为副本，以Partition-0为例:broker1中parition-0为Leader，Broker2中Partition-0为副本。 上述图种每个Broker(按照BrokerId有序)依次分配主Partition,下一个Broker...

1.Partition Recovery机制每个Partition会在磁盘记录一个RecoveryPoint, 记录已经flush到磁盘的最大offset。当broker fail 重启时,会进行loadLogs。 首先会读取该Partition的RecoveryPoint,找到包含RecoveryPoint的segment及以后的segment, 这些segment就是可能没有 完全flush到磁盘segments。然后调用segment的recover,重新读取各个segment的msg,并重建索引

Kafka是什么、Kafka是最初由Linkedin公司开发，是一个分布式、分区的、多副本的、多订阅者，基于zookeeper协调的分布式日志系统(也可以当做MQ系统)，常见可以用于web/nginx日志、访问日志，消息服务等等，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。一个商业化消息队列的性能好坏，其文件存储机制设计是衡量一个消息队列服务技术水平和最关键指标之一。 下面将从Kafka文件存储机制和物理结构角度，分析Kafka是如何实现高效文件存储，及实际应用效果

Kafka副本同步机制理解Apache Kafka的流行归功于它设计和操作简单、存储系统高效、充分利用磁盘顺序读写等特性、非常适合在线日志收集等高吞吐场景。Apache Kafka特性之一是它的复制协议。对于单个集群中每个Broker不同工作负载情况下，如何自动调优Kafka副本的工作方式是比较有挑战的。它的挑战之一是要知道如何避免follower进入和退出同步副本列表(即ISR)。从用户的角度来看，如果生产者发送一大批海量消息，可能会引起Kafka Broker很多警告。这些警报表明一些topic

apache kafka官网参考http://kafka.apache.org/documentation.html不同消息队列分类：点对点：消息生产者生产消息发送到queue中，然后消息消费者从queue中取出并且消费消息。这里要注意：消息被消费以后，queue中不再有存储，所以消息消费者不可能消费到已经被消费的消息。Queue支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。发布/订阅消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅）.

##背景知识JMS一个在 Java标准化组织（JCP）内开发的标准（代号JSR 914）。2001年6月25日，Java消息服务发布JMS 1.0.2b，2002年3月18日Java消息服务发布 1.1.Java消息服务（Java Message Service，JMS）应用程序接口是一个Java平台中关于面向消息中间件（MOM）的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。点对点与发布订阅最初是由JMS定义的。这两种模式主要区别或解决的问题就是发送到队列的消息能否重复消费(

解耦 在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。消息系统在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口。这允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。 冗余 有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理...

活动数据网站用户行为相关数据，例如PV、UV等。运营数据监控系统性能指标(cpu利用率、负载，内存使用率，磁盘利用率，IO性能)以上这些数据的特点：数据不可变海量数据需要实时处理传统消息系统并不能很好的支持...