ByteCoding

调优目标 主要目标：高吞吐量、低延时 吞吐量 即TPS，指的是Broker端进程或Client端应用程序每秒能处理的字节数或消息数 延时，可以有两种理解 从Producer发送消息到Broker持久化完成之间的时间间隔 端到端的延时，即从Producer发送消息到Consumer成功消费该消息的总时长 优化漏斗优化漏斗是调优过程中的分层漏斗，层级越靠上，调优的效果越明显 操作系统层 mount -o noatime 在挂载文件系统时禁用atime（Access Time）更新，记录的是文件最后被访问的时间 记录atime需要操作系统访问inode资源，禁用atime可以避免inode访问时间的写入操作 文件系统选择ext4、XFS、ZFS 将swappiness设置成一个很小的值（1~10，默认是60），防止Linux的OOM Killer开启随机杀掉进程 swappiness=0，并不会禁止对swap的使用，只是最大限度地降低使用swap的可能性 因为一旦设置为0，当物理内存耗尽时，操作系统会触发OOM Killer OOM Killer会随机挑选一个进程然后kill掉，不会给出 ...

主机监控 主机监控：监控Kafka集群Broker所在的节点机器的性能 常见的主机监控指标 机器负载 CPU使用率 内存使用率，包括空闲内存和已使用内存 磁盘IO使用率，包括读使用率和写使用率 网络IO使用率 TCP连接数 打开文件数 inode使用情况 JVM监控 重点指标 Full GC发生频率和时长 活跃对象大小 应用线程总数 设置堆大小 经历一次Full GC后，堆上存活的活跃对象大小为S，可以安全地将老年代堆大小设置为1.5S或者2S 从0.9.0.0版本开始，社区将默认的GC收集器设置为G1，而G1的Full GC是由单线程执行的，速度非常慢 一旦发现Broker进程频繁Full GC，可以开启G1的**-XX:+PrintAdaptiveSizePolicy，获知引发Full GC的原因** 集群监控 查看Broker进程是否启动，端口是否建立 在容器化的Kafka环境，容器虽然启动成功，但由于网络配置有误，会出现进程已经启动但端口未成功监听的情形 查看Broker端关键日志 Broker端服务器日志server.log – 最重要 控制器日志controller.l ...

背景 命令行脚本只能运行在控制台上，在应用程序、运维框架或者监控平台中集成它们，会非常困难 很多命令行脚本都是通过连接ZK来提供服务的，这会存在潜在的问题，即绕过Kafka的安全设置 运行这些命令行脚本需要使用Kafka内部的类实现，也就是Kafka服务端的代码 社区是希望用户使用Kafka客户端代码，通过现有的请求机制来运维管理集群 基于上述原因，社区于0.11版本正式推出Java客户端版的KafkaAdminClient 功能 主题管理 主题的创建、删除、查询 权限管理 具体权限的配置和删除 配置参数管理 Kafka各种资源（Broker、主题、用户、Client-Id等）的参数设置、查询 副本日志管理 副本底层日志路径的变更和详情查询 分区管理 创建额外的主题分区 消息删除 删除指定位移之前的分区消息 Delegation Token管理 Delegation Token的创建、更新、过期、查询 消费者组管理 消费者组的查询、位移查询和删除 Preferred领导者选举 推选指定主题分区的Preferred Broker为领导者 工作原理 KafkaA ...

脚本列表12345678connect-distributed kafka-consumer-perf-test kafka-reassign-partitions kafka-verifiable-producerconnect-standalone kafka-delegation-tokens kafka-replica-verification trogdorkafka-acls kafka-delete-records kafka-run-class zookeeper-security-migrationkafka-broker-api-versions kafka-dump-log kafka-server-start zookeeper-server-startkafka-configs ...

背景 Kafka和传统的消息引擎在设计上有很大的区别，Kafka消费者读取消息是可以重演的 像RabbitMQ和ActiveMQ等传统消息中间件，处理和响应消息的方式是破坏性 一旦消息被成功处理，就会从Broker上被删除 Kafka是基于日志结构（Log-based）的消息引擎 消费者在消费消息时，仅仅是从磁盘文件中读取数据而已，是只读操作，因为消费者不会删除消息数据 同时，由于位移数据是由消费者控制的，因此能够很容易地修改位移值，实现重复消费历史数据的功能 Kafka Or 传统消息中间件 传统消息中间件：消息处理逻辑非常复杂，处理代价高、又不关心消息之间的顺序 Kafka：需要较高的吞吐量、但每条消息的处理时间很短，又关心消息的顺序 重设位移策略 位移维度 直接把消费者的位移值重设成给定的位移值 时间维度 给定一个时间，让消费者把位移调整成大于该时间的最小位移 维度 策略 含义 位移维度 Earliest 把位移调整到当前最早位移处 Latest 把位移调整到当前最新位移处 Current 把位移调整到当前最新提交位移处 Specified-Of ...

背景 Kafka安装目录的config路径下，有server.properties文件 通常情况下，会指定server.properties来启动Broker 如果要设置Broker端的任何参数，必须要显式修改server.properties，然后重启Broker，让参数生效 但在生产环境，不能随意重启Broker，因此需要能够动态修改Broker端参数 社区于1.1.0正式引入了动态Broker参数 动态指的是修改参数后，无需重启Broker就能立即生效，而之前server.properties中配置的参数称为静态参数 并非所有Broker端参数都可以动态调整的，官方文档中有Dynamic Update Mode一列 read-only 与原来的参数行为一样，只有重启Broker，才能令修改生效 per-broker 动态参数，修改之后，只会在对应的Broker上生效 cluster-wide 动态参数，修改之后，会在整个集群范围内生效 使用场景 动态调整Broker端各种线程池大小，实时应对突发流量 – 比较常用 动态调整Broker端连接信息或安全配置信息 动态更新SSL ...

慢SQL诱因 无索引、索引失效 锁等待 InnoDB支持行锁，MyISAM支持表锁 InnoDB支持行锁更适合高并发场景，但行锁有可能会升级为表锁 一种情况是在批量更新时 行锁是基于索引加的锁，如果在更新操作时，条件索引失效，那么行锁会升级为表锁 基于表锁的数据库操作，会导致SQL阻塞等待，影响执行速度 在写大于读的情况下，不建议使用MyISAM 行锁相对于表锁，虽然粒度更细，并发能力提升，但也带来了新的问题，那就是死锁 不恰当的SQL SELECT * SELECT COUNT(*) 大表中使用LIMIT M,N 对非索引字段进行排序 SQL诊断EXPLAIN id：每个执行计划都有一个id，如果是一个联合查询，会有多个id select_type SIMPLE：普通查询，即没有联合查询、子查询 PRIMARY：主查询 UNION：UNION中后面的查询 SUBQUERY：子查询 table：当前执行计划查询的表，如果表有别名，则显示别名 partitions：分区表信息 type 从表中查询到行所执行的方式 由好到坏：_**system > const > eq_re ...

日常管理创建主题1$ kafka-topics --bootstrap-server localhost:9092 --create --topic t1 --partitions 1 --replication-factor 1 从Kafka 2.2版本开始，推荐使用--bootstrap-server代替--zookeeper（标记为已过期） 原因 使用--zookeeper会绕过Kafka的安全体系，不受认证体系的约束 使用--bootstrap-server与集群交互是未来的趋势 查询主题列表12345$ kafka-topics --bootstrap-server localhost:9092 --list__consumer_offsets_schemast1transaction 查询单个主题1234567$ kafka-topics --bootstrap-server localhost:9092 --describe --topic __consumer_offsetsTopic:__consumer_offsets PartitionCount:50 Replica ...

生产者消费者模式实现方式Object的wait/notify/notifyAll 基于Object的wait/notify/notifyAll与对象监视器（Monitor）实现线程间的等待和通知 这种方式实现的生产者消费者模式是基于内核实现的，可能会导致大量的上下文切换，性能不是最理想的 Lock中Condition的await/signal/signalAll 相对于Object的wait/notify/notifyAll，更推荐JUC包提供的Lock && Condition实现的生产者消费者模式 Lock && Condition实现的生产者消费者模式，是基于Java代码层实现的，在性能和扩展性方面更有优势 BlockingQueue 简单明了 限流算法漏桶算法通过限制容量池大小来控制流量，而令牌桶算法则通过限制发放令牌的速率来控制流量 漏桶算法 请求如果要进入业务层，就必须经过漏桶，而漏桶出口的请求速率是均衡的 如果漏桶已经满了，请求将会溢出，不会因为入口的请求量突然增加而导致系统 ...

线程上下文模式 线程上下文指的是贯穿线程整个生命周期的对象中的一些全局信息，如Spring中的ApplicationContext 可以使用ThreadLocal实现上下文 ThreadLocal是线程本地变量，可以实现多线程的数据隔离，每个线程只能访问各自内部的副本变量 Thread-Per-Message模式 一个消息一个线程 在Socket通信中，一个线程监听IO事件，每当监听到一个IO事件，就交给另一个处理线程执行IO操作 如果遇到高并发，就会出现严重的性能问题，因为线程在操作系统中也是昂贵的资源，不能无限制地创建 如果针对每个IO请求都创建一个线程来处理，在有大量请求同时进来时，就会创建大量线程 每次请求都需要创建和销毁线程，性能开销很大 可以使用线程池来代替线程的创建和销毁 ServerHandler1234567891011121314151617181920212223242526272829303132333435363738@AllArgsConstructorpublic class ServerHandler implements Runnable { ...