背景

1. 命令行脚本只能运行在控制台上，在应用程序、运维框架或者监控平台中集成它们，会非常困难
2. 很多命令行脚本都是通过连接ZK来提供服务的，这会存在潜在的问题，即绕过Kafka的安全设置
3. 运行这些命令行脚本需要使用Kafka内部的类实现，也就是Kafka服务端的代码
   • 社区是希望用户使用Kafka客户端代码，通过现有的请求机制来运维管理集群
4. 基于上述原因，社区于0.11版本正式推出Java客户端版的KafkaAdminClient

脚本列表

1
2
3
4
5
6
7
8

connect-distributed              kafka-consumer-perf-test         kafka-reassign-partitions        kafka-verifiable-producer
connect-standalone               kafka-delegation-tokens          kafka-replica-verification       trogdor
kafka-acls                       kafka-delete-records             kafka-run-class                  zookeeper-security-migration
kafka-broker-api-versions        kafka-dump-log                   kafka-server-start               zookeeper-server-start
kafka-configs                    kafka-log-dirs                   kafka-server-stop                zookeeper-server-stop
kafka-console-consumer           kafka-mirror-maker               kafka-streams-application-reset  zookeeper-shell
kafka-console-producer           kafka-preferred-replica-election kafka-topics
kafka-consumer-groups            kafka-producer-perf-test         kafka-verifiable-consumer

背景

1. Kafka和传统的消息引擎在设计上有很大的区别，Kafka消费者读取消息是可以重演的
2. 像RabbitMQ和ActiveMQ等传统消息中间件，处理和响应消息的方式是破坏性
   • 一旦消息被成功处理，就会从Broker上被删除
3. Kafka是基于日志结构（Log-based）的消息引擎
   • 消费者在消费消息时，仅仅是从磁盘文件中读取数据而已，是只读操作，因为消费者不会删除消息数据
   • 同时，由于位移数据是由消费者控制的，因此能够很容易地修改位移值，实现重复消费历史数据的功能
4. Kafka Or 传统消息中间件
   • 传统消息中间件：消息处理逻辑非常复杂，处理代价高、又不关心消息之间的顺序
   • Kafka：需要较高的吞吐量、但每条消息的处理时间很短，又关心消息的顺序

背景

1. Kafka安装目录的config路径下，有server.properties文件
   • 通常情况下，会指定server.properties来启动Broker
   • 如果要设置Broker端的任何参数，必须要显式修改server.properties，然后重启Broker，让参数生效
   • 但在生产环境，不能随意重启Broker，因此需要能够动态修改Broker端参数
2. 社区于1.1.0正式引入了动态Broker参数
   • 动态指的是修改参数后，无需重启Broker就能立即生效，而之前server.properties中配置的参数称为静态参数
3. 并非所有Broker端参数都可以动态调整的，官方文档中有Dynamic Update Mode一列
   • read-only
     • 与原来的参数行为一样，只有重启Broker，才能令修改生效
   • per-broker
     • 动态参数，修改之后，只会在对应的Broker上生效
   • cluster-wide
     • 动态参数，修改之后，会在整个集群范围内生效

慢SQL诱因

1. 无索引、索引失效
2. 锁等待
   • InnoDB支持行锁，MyISAM支持表锁
   • InnoDB支持行锁更适合高并发场景，但行锁有可能会升级为表锁
     • 一种情况是在批量更新时
     • 行锁是基于索引加的锁，如果在更新操作时，条件索引失效，那么行锁会升级为表锁
   • 基于表锁的数据库操作，会导致SQL阻塞等待，影响执行速度
     • 在写大于读的情况下，不建议使用MyISAM
   • 行锁相对于表锁，虽然粒度更细，并发能力提升，但也带来了新的问题，那就是死锁
3. 不恰当的SQL
   • SELECT *
   • SELECT COUNT(*)
   • 大表中使用LIMIT M,N
   • 对非索引字段进行排序

日常管理

创建主题

1

$ kafka-topics --bootstrap-server localhost:9092 --create --topic t1 --partitions 1 --replication-factor 1

1. 从Kafka 2.2版本开始，推荐使用--bootstrap-server代替--zookeeper（标记为已过期）
2. 原因
   • 使用--zookeeper会绕过Kafka的安全体系，不受认证体系的约束
   • 使用--bootstrap-server与集群交互是未来的趋势

生产者消费者模式

实现方式

Object的wait/notify/notifyAll

1. 基于Object的wait/notify/notifyAll与对象监视器（Monitor）实现线程间的等待和通知
2. 这种方式实现的生产者消费者模式是基于内核实现的，可能会导致大量的上下文切换，性能不是最理想的

线程上下文模式

1. 线程上下文指的是贯穿线程整个生命周期的对象中的一些全局信息，如Spring中的ApplicationContext
2. 可以使用ThreadLocal实现上下文
   • ThreadLocal是线程本地变量，可以实现多线程的数据隔离，每个线程只能访问各自内部的副本变量

高水位

水位的定义

原型模式

1. 原型模式：通过给出一个原型对象来指明所创建的对象的类型，然后使用自身实现的克隆接口来复制这个原型对象
2. 使用这种方式创新的对象的话，就无需再通过new实例化来创建对象了
   • Object类的clone方法是一个Native方法，可以直接操作内存中的二进制流，所以相对new实例化来说，性能更佳