1、有了分区，可以多个client消费一个topic，有了分区，可以将一个topic 分散在多个broker
2、kafka通过复制实现可靠，通过横向扩展提高性能（如增加分区、客户端、增加broker）
3、消费者占用网络流量，而复制、镜像也会占用网络流量。如果网络接口出现饱和，那么集群的复制出现延时就在所难免，从而让集群不堪一击。
4、如果服务器返回错误， get （）方怯会抛出异常
5、因为生产者会自动进行重试，所以就没必要在代码逻辑里处理那些可重试的错误。你只需要处理那些不可重试的错误或重试次数超出上限的情况。
6、Kafka 把所有消息都保存在磁盘上，存放这些日志片段的目录是通过 log. dirs 指定的
7、
kafka实战笔记
1 kafkatop ics.sh(bat）脚本负责 topi c 的创建与删除， kafka-configs.sh(bat）脚本负责 topic 参数的修改和查询
2 认证就是证明你是谁的过程 。 当访问 Kafka 服务时你必须显式地提供身份信息来证明你的身份是合法的，而授权则是验证你能访问哪些服务的过程
3 它的吞吐量就是每秒能够处理的消息数或者每秒能够处理的字节数
4 延时可以表示客户端发起请求与服务器处理请求并发送响应给客户端之间的这一段时间
5 为啥写的快：
Kafka 会持久化所有数据到磁盘，但本质上每次写入操作其实都只是把数据写入到操作系统的页缓存（ page cache ）中，然后由操作系统自行决定什么时候把页缓存中的数据写回磁盘上 。
Kafka 在设计时采用了追加写入消息的方式，即只能在日志文件末尾追加写入新的消息，且不允许修改己写入的消息，因此它属于典型的磁盘顺序访问型操作操作系统页缓存是在内存中分配的，所以消息写入的速度非常快。
6 为啥读的快：
Kafka 在读取消息时会首先尝试从 OS的页缓存中读取，如果命中便把消息经页缓存直接发送到网络的 Socket 上
7 kafka负载均衡的实现：
可以在集群的所有机器上以均等机会分散各个partition 的 leader，从而整体上实现了负载均衡 。
8 故障转移：
kafka通过会话机制将自己注册到zookeeper，若会话中断，则转移
9 kafka中key的作用：对消息做 partition 时使用，即决定消息被保存在某 topic 下的哪个 partitionfollowerreplica 是不能提供服务给客户端的，也就是说不负 责响应客户端发来的消息写入和消息消费请求。
10 Kafka 的服务器端代码是由 Scala 语言编写的，而新版本客户端代码是由 Java语言编写的。
11 Kafka 不属于计算密 集型（ CPU-bound ）的系统 ，so 追求多核而非高时钟频率
12 Java 安装可以使用 java -version 命令来进行验证。
13 从本质上来说，多节点 Kafka 集群由一套多节点 ZooKeeper 集群和一套多节点 Kafka 集群组成
14 zookeeper若由2n+1台组成，则允许n台机器挂掉
15 判断topic是否被真正的删除：
执行 kafka-topics 脚本来列出当前的 topic 列表，如果 test-topic 不在该列表中，则表明该 topic 被删除成功
16 broker的参数不支持动态修改，若参数被修改了，要重启broker才生效
17 如果要使用 一套 ZooKeeper环境管理多套 Kafka 集群，那么设置该参数的时候就必须指定 ZooKeeper 的 chroot,比如 zkl :218 l ,zk2:2181,zk3:2181/kafka_clusterl o 结尾的/kafka_cluster 1 就是 chroot，它
是可选的配置，如果不指定则默认使用 ZooKeeper 的根路径
18 min.insync.replicas 也只有在 acks=-1 时才有意义。举一个例子，假设某个topic 的每个分区的副本数是 3 ，那么推荐设置该参数为 2 ，这样我们就能够容忍 一 台broker 窑机而不影响服务：若设置参数为 3 ，那么只要任何一
台 broker 岩机，
整个Kafka 集群将无法继续提供服务。因此用户需要在高可用和数据一致性之间取得平衡 。
19 用户可以设置advertised.listeners绑定公网 IP 供外部 clients 使用，然后配置 listeners 来绑定私网 IP 供 broker 间通信使用
20 Kafka broker 主要使用的是堆外内存，即大量使用操作系统的页缓存，因此其实并不需要为JVM分配太多的内存
21 如果 Kafka 集群中机器数很多，那么只需要指定部分 broker 即可，不需要列出所有的机器。因为不管指定几台机器， producer 都会通过该参数找到井发现集群中所有的 broker。为该参数指定多台机器只是为了故障转移使用。这样即使某一台 broker 挂掉了， producer 重启
后依然可以通过该参数指定的其他 broker 连入 Kafka 集群。
22 producer 程序结束时一定要关闭 producer ！这一 点怎么强调都不为过
23 对于这种可重试的异常，如果在 producer 程序中配置了重试次数，那么只要在规定的重试次数内自行恢复了，便不会出现在 onCompletion 的 exception 中。
24 Java 版本 producer 启动时会首先创建一块内存缓冲区用于保存待发送的消息，然后由另 一个专属线程负责从缓冲区中读取消息执行真正的发送。这部分 内存空间的大小即是由 buffer.memory 参数指定的
25 Kafka 的 producer 端引入压缩后可以显著地降低网络 I/O 传输开销从而提升整体吞吐量，但也会增加 producer 端机器的 CPU 开销 。另外，如果 broker 端的压缩参数设置得与 producer 不同， broker 端在写入消息时也会额外使用 CPU 资源对消息进行对应的解压缩－重压缩操作。
26 现在使用 Kafka提供的 GetOffsetShell 工具类帮助我们查询 test-topic 每个分区的消息数
27 重试可能造成消息的重复发送;重试可能造成消息的乱序;
producer 两次重试之间会停顿一段时间，以防止频繁地重试对系统带来冲击,这段时间是可以配置的，由参数目retry.backoff.ms 指定，默认是 100 毫秒 。
linger.ms 参数就是控制消息发送延时行为的 。 该参数默认值是 0，表示消息需要被立即发送，无须关心 batch 是否己被填满
28 序列化器（ serializer ）负责在 producer 发送前将消息转换成字节数组：而与之相反，解序列化
器（ deserializer ）则用于将 consumer 接收到的字节数组转换成相应的对象。
29 max.in.flight.requests.per.connection = 1
设置该参数为 1 主要是为了防止 topic 同分区下的消息乱序问题。如果设置成 l ,则 producer 在某个 broker 发送响应之前将无法再给该 broker 发送 PRODUCE 请求 。
30
