kafka使用标准个人总结

选用标准

【推荐】高吞吐量

规定：在需要处理海量数据且要求高吞吐量时，选择使用Kafka。

原因：得益于其分布式架构、批量传输以及节点间负载均衡，Kafka能够处理更高的并发量和数据流量。

【推荐】大数据处理和日志收集

规定：对于需要进行实时数据分析和挖掘的大数据处理和日志收集，推荐使用Kafka。

原因：Kafka提供了强大的数据处理和存储能力，能够实现数据的实时收集、处理和分发。

【推荐】消息持久化

规定：当需要长期保留和随时查询历史消息时，应选择Kafka进行消息持久化。

原因：Kafka的消息持久化能力允许将消息存储到磁盘，支持高效的消息检索和管理。

【推荐】多语言支持

规定：在需要支持多种编程语言的开发环境中，推荐使用Kafka。

原因：Kafka提供了丰富的API，支持多种主流编程语言，便于实现跨平台开发和集成。

【强制】微服务间交互

规定：当系统间交互需要联机交易且必须实时返回时，不应使用消息队列，而应选择RPC。

原因：RPC提供了更快的响应时间，确保联机交易能够获得所需的即时反馈。

【强制】链路解耦

规定：必须对关键链路和非关键链路进行解耦，避免直接依赖。

原因：解耦可增强系统的灵活性和健壮性，减少故障传播，确保关键服务的连续性。

设计规范

【强制】必须配置密码登录

规定：使用Kafka时，必须配置密码登录以确保访问控制。

原因：密码登录是基本的安全措施，能够防止未授权用户访问Kafka集群。

【推荐】启用SSL/TLS加密

规定：在Kafka中启用SSL/TLS加密协议，保护数据在传输过程中的安全性和机密性。

原因：使用加密协议可以防止数据泄露，确保消息内容不被第三方截获或篡改。

【推荐】启用角色和权限管理

规定：实施角色和权限管理机制，以实现数据访问的精细化控制和安全审计。

原因：这样的机制有助于限制用户权限，仅允许他们访问必要的数据，同时促进安全合规性。

【推荐】Partition设置

规定：推荐设置Partition的个数与Consumer个数相等，且Consumer的个数不应超过Partition的个数。

原因：这样做可以使得消息负载均衡地分配给每个Consumer，避免某些Consumer空闲而其他的过载。

【推荐】Replica数量

规定：考虑到性能和可靠性，建议设置default.replication.factor为3。

原因：多副本可以在发生故障时提供数据的高可用性，并且平衡负载，提高系统的整体稳定性。

【推荐】Broker数量

规定：为了增强可靠性和容错能力，至少使用3个Broker组成的多副本多Broker模式。

原因：这有助于确保即使在单个或多个Broker失败时，Kafka集群仍然能够正常运行。

命名规范

【强制】使用小写字母和数字

规定：Topic名称只能使用小写字母和数字，不允许使用特殊字符（除了"-"分隔符）。

原因：统一的命名规则有助于避免混淆，确保系统的互操作性和易用性。

【推荐】使用"-"分隔单词

规定：使用"-“分隔单词来命名Topic，例如"my-topic-name”，并确保命名具有明确的意义。

原因：这种命名方式提高了可读性，同时有助于快速理解Topic的用途。

【推荐】命名长度控制

规定：Topic命名不应超过254个字符。

原因：较短的名称易于维护，同时防止因名称过长而引起的潜在问题。

【推荐】避免使用系统保留命名

规定：避免使用Kafka系统自带的命名空间，如"_consumer_offsets"和"_schemas"。

原因：这些命名空间是为Kafka内部使用而保畴的，使用这些命名空间可能会导致冲突或不可预见的行为。

使用规范

【强制】配置合理的acks参数

规定：必须配置合理的acks参数，以平衡消息的可靠性和系统性能；对于严格的可靠性要求，可设置为all；为了高吞吐量，可设置为1。

原因：acks参数控制生产者消息确认的行为，all确保所有副本都接收到消息，而1则在领导副本接收到消息后立即返回，提高吞吐量但降低了可靠性。

【强制】配置集群副本数和ISR阈值

规定：需要合理设置集群的副本数和ISR（In-Sync Replicas）阈值，以确保数据的高可用性和一致性。

原因：将ISR设置大于1确保至少有一个副本同步了消息，这样即使发生故障，消息也不会丢失，从而保证了数据的可靠性。

【强制】消费者消费信息幂等

规定：消费者在消费信息时必须实现幂等性，避免因重复处理消息而产生副作用。

原因：幂等性确保消息被处理一次且仅一次，即使在消息重复接收的情况下也能防止数据被污染。

【推荐】消息大小限制

规定：发送的消息大小不应超过1MB。

原因：控制消息大小有助于防止网络拥塞和Broker处理瓶颈，保持系统的稳定性和响应速度。

【推荐】可靠消费-错误重试策略

规定：根据业务需求合理设置消费者的错误重试策略，包括重试次数和间隔时间。

原因：合理的重试策略可以在处理失败时增强系统的鲁棒性，而不会导致消息的无限重试或系统资源的浪费。

【推荐】ack-mode设置

规定：当enable-auto-commit设置为false时，建议将ack-mode设置为MANUAL。

原因：MANUAL模式允许生产者更精确地控制消息的提交时机，确保消息被正确持久化，尽管可能略微降低吞吐量。

【推荐】异步提交偏移量

规定：建议关闭自动提交偏移量（enable.auto.commit=false），并定期手动提交偏移量。

原因：异步提交偏移量可以减少消息的重复消费和偏移量丢失的风险，同时允许更细粒度的控制消费过程。

【推荐】避免使用相同消费者组ID

规定：配置消费者组时应避免使用相同的消费者组ID，以防止消息的重复消费。

原因：不同的消费者组ID可以确保消息被适当地分发给不同的消费者，防止消息在多个消费者间被重复处理。

自建规范

1.【强制】新系统不允许自建kafka。

2.【推荐】打开JMX监控端口,接入监控平台。

3.【推荐】使用2.8.1以上版本,使用Scala2.13及以上版本,使用3.6.x版本的zookeeper。

4.【推荐】JVM参数配置:堆内存大小(Xmx和Xms)设置同一个值;垃圾回收机制选择G1。

5.【推荐】日志保留天数,请根据业务需求设置,做好备份策格,考虑到磁盘问题,推荐设置为72小

时,并对应做文件备份归档。