建议评估滴滴开源的kafka-manager，项目地址：https://github.com/didi/KnowStreaming   官网为https://doc.knowstreaming.com   Know Streaming 是一套云原生的Kafka管控平台，专注于Kafka运维管控、监控告警、资源治理、多活容灾等核心场景。在用户体验、监控、运维...

对象的内存开销非常高，通常是要存储的数据的两倍甚至更高随着堆内数据的增加，GC的速度越来越慢

1. Broker− CPU 和内存比例建议设置为 1:4 ，比如 4C/16GB 、 8C/32GB 、 16C/64GB 。如果开启 TLS 和数据压缩功能，建议将比例提升至 1:2 。 2. Topic ：单个 Topic 分区数建议控制在 10 个以内。 3. Replicas ：Kafka 应用对于可靠性要求较高的场景常采用 3 副本； 4. ...

1，常见套路就是要么应用层自己做，就是Kafka的一主多从能力，要么容器平台体系支撑，就是靠容器平台自身的漂移能力解决可靠性和恢复能力。2，两种方案各有优劣，一主多从结合本地盘，就是当前的常规套路，但是有几个问题，服务器自身的可靠性，3年寿命的周期替换，数据迁移；RAID卡的抖动问题，本...

Kafka的存储需求，在功能面是存储的数据是消息流，数据量级非常大；数据CRUD操作足够简单，主要为并发非常高和百万级TPS的追加写、无需更改、能根据消费位移offset和时间戳timestamp查询消息、能定期删除过期的消息；在非功能性面是高性能要求、高可用的稳定性要求、高扩展性要求...

kafka容器化以后性能和虚拟化之间没有任何变化，因为容器化技术本身是个进程级别的隔离技术，机器还是那个机器，网络还是那个网络，运行的程序，容器也只是个进程。

建议先分析和评估业务需求，再决策是否有必要引入消息平台。确定应用场景后，再做消息平台的选型。譬如KAFKA适合用在以下场景：日志处理场景：使用Kafka收集各种业务系统的日志数据，通过Kafka以统一接口服务的方式开放给下游系统消费，进行实时处理和分析。用户数据采集和分发场景：...

 建议先梳理清楚交易的业务特征，和数据流向，现根据需求选择合适的MQ，譬如Kafka和RabbitMQ的功能差异如下图所示： 应用场景确定后，譬如确定合适使用KAFKA，则对此交易数据流的流向、各关联系统的角色进行分析，确认是消息的生产者、还是消费者角色。再根据数据的特征和处理需求，对...

出现消息丢失的现象，是KAFKA参数配置失当的问题。譬如：（1） Producer 参数：如果想保证数据绝对不丢失， Producer 需要开启重试逻辑，并且设置 ACKS=all ，如果需要增大吞吐量，可以考虑设置较大的 batch.size （默认为 16K ）。 （2）Partition参数：分区副本数建议为 2 或 3 ，从可靠性考虑，非常...

 目前暂没有安排。与开源可视化工具Kafdrop去结合下，形成一套可视化管理控制系统？： 请问此需求背景是贵单位要自研KAFKA服务？ 还是出自个人兴趣，要有一个指引？