如何设计一个扛住千万级流量的系统？

前面我们对 Kafka 的整体架构和一些关键的概念有了一个基本的认知本文主要介绍 Kafka 的一些配置参数。掌握这些参数的作用对我们的运维和调优工作还是非常有帮助的。写在前面Kafka 作为一个成熟的事件流平台有非常多的配置参数。详细的参数列表可以查看官方文档。本文我们列出一些个人认为比较重要的参数并对其进行详细的介绍。Broker 端参数第一个要介绍的参数是 log.dirs 它是 Broker 的一个最基本的参数用来指定数据存储的目录多个目录之间用逗号分隔。这个参数是必填参数且没有默认值。因此必须要手动配置。在生产环境中我们可以给这个目录配置挂载在多个不同磁盘的路径这样既可以提升读写性能又可以实现故障转移。Kafka 还提供了 log.dir 参数作为 log.dirs 的补充这个参数只能配置一个目录默认值是 /tmp/kafka-logs 通常情况下我们只需要配置 log.dirs 就好。第二个参数是 process.roles它用来指定 broker 的角色可以是 broker 或者 controller也可以同时指定为 broker,controller。第三个参数是 listeners它是 broker 的“耳朵”指定了 broker 如何监听外部连接。连接的配置是一个三元组包括协议名称主机名端口号。Kafka 目前支持四种安全协议PLAINTEXT明文传输SSL/TLS加密传输SASL_PLAINTEXT认证明文传输SASL_SSL认证加密传输为最高安全级别此外还可以自定义协议名称但需要配置 listener.security.protocol.map 参数。主机名可以指定为一个确定的主机名也可以是 0.0.0.0 这代表了 broker 会监听所有网卡。主机名也可以是空代表监听默认接口。第四个参数是 advertised.listeners 这组配置是 Broker 发布的监听也就是告诉别人“怎么找到我”。它的配置格式和 listeners 相同。再来看几个集群稳定性和元数据管理相关的参数。第五个是 auto.create.topics.enable表示是否允许自动创建 topic。在生产环境中一般设置为 false需要用户手动创建 topic方便管理。第六个是 unclean.leader.election.enable表示是否允许 unclean leader 选举。unclean 就是落后太多的副本如果允许这部分副本参与选举可能会造成数据丢失因此最好手动设置 false。在最新版本中它的默认值就是 false为什么还要手动设置呢因为不同的 Kafka 版本中这个参数的默认值是不一样的最开始是 false后来改成了 true现在又改回了 false。为了避免数据丢失我们还是手动设置成 false 比较放心。第七个参数是 auto.leader.rebalance.enable表示是否允许定期选举 leader这个参数最好也设置为 false如果设置为 true 的话即使当前 leader 一直运行的很稳定Kafka 也会重新选举出一个新的 leader 来替代它。替换 leader 的成本还是非常高的所有连接到旧 leader 的 client 都需要与新的 leader 重新建立连接。第八个参数是 min.insync.replicas 表示最小同步副本数它与生产者的 acksall 配合。如果存活的副本数小于这个值producer 在写入时会直接报错。这个配置可以保证我们在牺牲部分可用性的情况下确保数据的正确性。接下来我们再看几个数据生命周期相关的参数。第九个参数是 log.retention.hours / minutes / ms这其实是三个参数表示的意思一样都是数据留存时长只是时间单位不同。如果三个参数都配置了优先级是 ms minutes hours。第十个参数 log.retention.bytes它表示单个 broker 上存储的最大字节数默认是 -1也就是没有限制。在数据激增时它可以是保护磁盘不溢出的最后防线。第十一个参数是 log.segment.bytes它表示单个日志文件的大小默认是 1GB。Topic 参数Topic 级别的参数会覆盖 Broker 参数的值它的主要作用针对不同的 topic 灵活的配置参数。最常见的是我们在生产环境中针对不同的 topic 会配置不同的数据保留时长。这也是我们要介绍的第一个参数 retention.ms它对应的 broker 端的参数就是 log.retention.ms。第二个参数是 retention.bytes 它对应的是 log.retention.bytes。第三个参数是 cleanup.policy它对应的是 broker 端的 log.cleanup.policy这个参数代表了数据清理策略默认值是 delete即直接物理删除。也可以配置为 compact对每个 key 只保留最新的值这种策略比较适合一些状态保存的场景。第四个参数是 segment.bytes 与之对应的 broker 参数是 log.segment.bytes同样是控制 Log Segment 文件的大小默认是 1GB。调小可以让 Kafka 更及时的回收磁盘空间但容易产生大量小文件增大索引压力。一般保持默认值就好。第五个参数是 max.message.bytes 它限制了该 Topic 能接收的最大单条消息的大小默认是 1MB对个别业务可以适当调大。需要注意的是它和消费端参数 fetch.max.bytes 的大小应该合理配置。如果 max.message.bytes 设置为 10MBfetch.max.bytes 设置为 5MB当 Topic 中有超过 5MB 的消息时就会导致无法消费的问题。Producer 参数首先第一个参数是 acks它有几个值0不管是否写入成功1Leader 写入成功即可all / -1ISR 都要写入成功默认值是 all如果设置成 0 或 1 性能会提高但有可能丢失数据。第二个参数是 retries 它控制请求的重试次数默认是 2147483647约等于无限重试了。第三个参数是 batch.size默认是 16KB调大会提升吞吐量但是会增加内存占用。第四个参数是 linger.ms它用来控制发送等待时间也就是“攒批”的时间Kafka 4.0 把它的默认值从 0 调成了 5。它可以和 batch.size 配合使用同时调大会提高吞吐但数据会有一定的延迟。在生产环境中我们可以根据不同的场景对其进行调整如果数据量极大但对延迟要求不高则可以考虑调大这两个参数。最后第五个参数是 compression.type 生产端的压缩算法默认不开启压缩目前支持的值为none、gzip、snappy、lz4、zstd。Consumer 参数最后我们再来看几个 Consumer 端的参数。第一个是 group.id用来标识这个 consumer 属于哪个消费组。第二个是 auto.offset.reset它用来标识 offset 的重置策略。支持以下几个值earliest从最早的 offset 开始消费latest从最新的 offset 开始消费by_duration需要配置为 by_duration:ISO-8601 格式的时间例如 by_duration:PT1H 即从 1 小时前的位移开始消费none如果没找到消费组的 offset就会抛出异常第三个参数是 enable.auto.commit是否自动提交 offset默认是 true。在调用 poll 方法时会提交上一批次的 offset。也可以设置为 false这样就是手动提交自己控制在什么时候提交具体的细节我们以后再聊。第四个参数是 max.poll.records 表示单次拉取的消息条数默认是 500。如果单条数据的处理逻辑比较重可以调小这个值防止消费超时的情况。第五个参数是 session.timeout.ms表示心跳超时时间默认是 45000即 45 秒。如果 Broker 超过 45 秒没收到 Consumer 的心跳就认为这个 Consumer 挂了会将它踢出消费组然后进行 Rebalance。总结本文我们一起学习了涉及 Broker、Topic、Producer、Consumer 端的共 26 个配置参数这些都是我认为比较重要的。掌握之后可以对生产环境的调优有比较大的帮助。除了上面提到的这些你还知道有哪些比较重要的配置参数吗壬徘炒劫