在线甘特图|横道图|项目管理|计划管理 zz-plan
人员、任务、进度、工时、周期、依赖关系 一目了然。无论项目大小、简单复杂都能轻松管理
一次CPU sys上涨引发对kafka PageCache的思考
1.CPU sys 上涨背景配置机型 A机型 BCPU48C48CMEM8*32G12*16GDATA DISK12*960G SSD12*4T SSD线上某个kafka集群由于种种原因，从 24 * 机型 A 置换迁移为 12 * 机型 B。从集群总资源维度看，排除其他客观因素，置换后，CPU总核数少了一半，使用率上升其实也是预期之内的。事实上置换后，集群CPU使用率确实也由原有的 20%提升至 40%，上升了约 1 倍多。但置换后，cpu sys使用率均值约达到了 12%
kafka消费组及重平衡的影响
消费组应该算是kafka中一个比较有特色的设计模式了，而他的重平衡机制也是我们在实际生产使用中，无法避免的一个问题。消费组Consumer Group为kafka提供了可扩展、高容错特性的消费者机制。简单介绍下，大致有以下特点：一个Consumer Group内可以有多个Consumer实例，该实例可以是一个进程，也可以是进程下的多线程每个Consumer Group有一个唯一标识的Group ID不同Consumer Group之间相互独立，互不影响Consumer Gro
kafka生产者的幂等和事务处理
之前和大家聊过kafka是如何保证消息不丢失的，今天再讲讲在不丢消息的同时，如何实现精确一次处理的语义实现。消息组件对消息的可靠性保障，常见的模式有3种：最多一次(at most once)：消息可能会丢失，但不会重复至少一次(at least once)：消息不会丢失，但有可能重复精确一次(exactly once)：消息不会丢失，且不会重复，精准一次发送kafka默认情况下，提供的是至少一次的可靠性保障。即broker保障已提交的消息的发送，但是遇上某些意外情况，如：网络
kafka是如何保证消息不丢失的
今天和大家聊一下，kafka对于消息的可靠性保证。作为消息引擎组件，保证消息不丢失，是非常重要的。那么kafka是如何保证消息不丢失的呢？前提条件任何消息组件不丢数据都是在特定场景下一定条件的，kafka要保证消息不丢，有两个核心条件。第一，必须是已提交的消息，即committed message。kafka对于committed message的定义是，生产者提交消息到broker，并等到多个broker确认并返回给生产者已提交的确认信息。而这多个broker是由我们自己来
kafka的发行版选择
今天继续和大家聊一下，kafka的各种发行版。kafka历经数年的发展，从最初纯粹的消息引擎，到近几年开始在流处理平台生态圈发力，衍生出了各种不同特性的版本。你了解几种kafkakafka的确有好几种，这里我不是指他的版本，是指存在多个组织或公司发布不同特性的kafka。你应该听说过Linux发行版，比如我们熟知的CentOS、RedHat、Ubuntu等，它们都是Linux系统，其实就是因为它们是不同公司发布的Linux系统，即不同的发行版。kafka也同样有多个发行版。A
kafka分区数和吞吐量的关系
分区(partition)概念要讲kafka分区数和吞吐量的关系，首先得理解什么是分区(partition)。Partition是作用于具体的Topic而已的，而不是一个独立的概念。Partition能水平扩展客户端的读写性能，是高吞吐量的保障。通俗的讲，Partition就是一块保存具体数据的空间，本质就是磁盘上存放数据的文件夹，所以Partition是不能跨Broker存在的，也不能在同一个Broker上跨磁盘。对于一个Topic，可以根据需要设定Partition的个数
kafka分区数过多的弊端
上篇文章我们了解到，如果一个topic分区越多，理论上整个集群所能达到的吞吐量就越大。那么，分区数越多就越好吗？显然不是。今天我们来聊下kafka在分区数过多的情况下，会带来哪些弊端。内存开销客户端producer有个参数batch.size默认为16KB。它会为每个分区缓存消息，一旦批次数满了后，将消息批量发出。一般来说，这个设计是用于提升吞吐性能的。但是由于这个参数是partition级别的，如果分区数越多，这部分缓存所需的内存占用也会越多。假如有10000个分区，按照默
kafka数据存储目录间迁移
生产环境kafka集群，在数据量大的情况下，会出现单机各个磁盘间的占用不均匀情况，经常出现“一边倒”的情形。原因探究这是因为kafka只保证分区数量在各个磁盘上均匀分布，但它无法统计每个分区实际占用磁盘空间。因此很有可能出现某些分区消息数量巨大导致占用大量磁盘空间的情况。在1.1版本之前，用户对此基本没有优雅的处理方法，即便手动迁移日志文件和offset信息，也需要重启生效，风险极高。因为1.1之前kafka只支持分区数据在不同broker间的重分配，而无法做到在同一个bro
kafka集群扩容后的数据均衡
生产环境的kafka集群扩容，是一个比较常见的需求和操作。然而kafka在新增节点后并不会像elasticsearch那样感知到新节点加入后，自动将数据reblance到整个新集群中，因此这个过程需要我们手动分配。分区重分配方案扩容后的数据均衡，其本质就是对topic进行分区重分配，数据迁移的过程。在执行分区重分配的过程中，对集群的影响主要有两点：分区重分配主要是对topic数据进行Broker间的迁移，因此会占用集群的带宽资源；分区重分配会改变分区Leader所在的Brok
Dr.Elephant实战常见问题及解决方法
通过之前一系列的文章叙述，想必大家都对dr.elephant有了一个较为清晰的了解。通过自己线上经验的积累，以及和一些读者的交流，我汇总了一些大家在实战中遇到的问题和解决方案。常规问题由于在和读者交流的过程中，发现大家技术水平参差不齐，本着科普性文章的初衷，这里先讲一些比较基础的要点，大佬们可以忽略，直接跳过。在打包时，需要对照自己的Hadoop或者Spark版本，修改compile.conf文件中的版本号。否则有可能出现采集不到集群作业信息的情况。最好将自己Hadoop集群