消息在kafka保留多长时间？
消息保存72小时，超过72小时的消息将会被删除。
Kafka可以创建多少个主题？
Kafka基础版可以创建50个主题、Kafka高级版可以创建100个主题。
如果想消费已经被消费过的数据？
consumer是底层采用的是一个阻塞队列，只要一有producer生产数据，那consumer就会将数据消费。当然这里会产生一个很严重的问题，如果你重启一消费者程序，那你连一条数据都抓不到，但是log文件中明明可以看到所有数据都好好的存在。换句话说，一旦你消费过这些数据，那你就无法再次用同一个groupid消费同一组数据了。针对这种情况，你可在控制台重置消费组消费点（3天内）。
是否需要预先创建消费组
消费组和消费组订阅主题关系虽然业务应用客户端接入时可自动创建，但建议都先预先创建做好管理。
出现“Not authorized to access group”的错误信息
没有创建消费组时会遇到此报错信息，创建消费组可解决此问题。
为什么PHP发送延时比较长？
PHP发送延时比较长是PHP的语言特性导致的。PHP每次发送时，都会重新初始化一个KafkaProducer对象，这个初始化会进行各种操作，包括连接各个Broker、更新元数据等，在VPC内耗时100ms以上，在公网可能耗时500ms以上。相比之下，Java会复用KafkaProducer，发送延迟较低。
哪里可以找到生产消费消息的示例
最佳实践 - 生产者实践、消费者实践。
如何进行发送消息的测试？
可以直接在Kafka控制台进行发送消息的测试。在控制台的Topic管理页面，单击目标Topic右侧的生产拨测，进行消息发送测试，以验证集群是否运转正常。
使用客户端发送消息后，如何确定是否发送成功？
如果回调成功则说明消息发送成功。大部分客户端在发送之后，会返回Callback或者Future，如果回调成功，则说明消息发送成功。
此外，还可以在控制台通过以下方式确认消息发送是否正常：
查看“监控信息”，实例消息生产条数。
查看“消息查询”，可按时间查询消息。
发送消息的回调是否会影响发送速度？
Java客户端设置回调是否会影响消息发送的速度取决于如下两点：
（1）回调的处理耗时：为减少回调的处理耗时，不要过于频繁地在回调做耗时较长的处理。可以积累一定量Ack后再做批量的回调处理，或者在另一个异步的线程去处理，从而不阻塞回调的完成。
（2）max.in.flight.requests.per.connection：该参数指定了生产者在收到服务器响应之前可以发送多少个消息。它的值越高，就会占用越多的内存，不过也会提升吞吐量。
实例支持哪些开源版本？
当前服务端支持的版本为2.3.1和2.8.2。实例创建后，服务端版本不支持升级，不支持定制版本。
如何选择实例硬盘大小？
磁盘大小：流量均值×存储时长×3（备份），建议在迁移上云过程中优化Topic以降低成本。
升级Broker可能产生哪些影响？
升级Broker可能产生消息乱序、客户端连接中断、消息量不均衡等影响。
升级Broker包含以下影响：
升级过程中，会逐个重启云消息队列 Kafka 版集群中所有的Broker。在重启Broker的过程中服务不会中断，但是从每个Broker重启完成之后的5分钟内消费的分区消息可能会发生乱序。
- 重启过程中已有的客户端连接可能会中断。客户端要有自动重连功能，服务端的其他Broker会自动接替服务。
- 此外，升级和重启Broker期间，各个分区处理的消息量也会出现一定的不均衡，需要评估一下升级变更对业务可能产生的影响。
升级所有Broker大概需要5分钟~15分钟。如果有多个实例，可以考虑先升级测试集群，验证通过后再升级生产集群。
实例的地域无法变更？
实例购买部署之后，其地域与物理资源紧密结合，无法变更。如需变更实例的地域，请释放实例，并重新购买。
如何快速测试分布式消息服务Kafka服务端是否正常？
前提条件
已创建并部署分布式消息服务Kafka实例，且实例处于服务中状态。
操作流程
快速测试分布式消息服务Kafka服务端的流程如下：
（1）新建Topic
（2）在主题管理页面，生产拨测，体验发送消息
（3）在主题管理页面，查看分区状态
（4）在消息查询页面，按时间或位点查询消息
是否支持延迟消息？
和开源Apache Kafka一样，分布式消息服务Kafka同样不支持延迟消息。
是否支持压缩消息？
分布式消息服务Kafka服务端支持收发压缩消息。
如需使用压缩消息，需要在分布式消息服务Kafka的客户端进行设置。在分布式消息服务Kafka客户端进行消息压缩的说明如下：
压缩格式：支持Snappy、LZ4、GZIP等压缩格式。其中，GZIP对CPU的消耗较高，因此不建议选择GZIP，建议选择Snappy或LZ4。
适用场景：一般来说，CPU的价格比流量和存储要高。对于日志类等压缩比较高的场景，可以考虑使用压缩。其余场景，不建议使用压缩。
CPU消耗：压缩会消耗额外的CPU，平均在20%以上。具体额外CPU消耗，需要根据实际场景进行测试。
如何释放实例？
若不再需要使用实例，可以在控制台上退订实例。
为什么限制Topic总数（分区总数）？
Topic总数（分区总数）太多会使集群性能和稳定性能急剧下降。
分布式消息服务Kafka的存储和协调机制是以分区为粒度的，分区数太多，会导致存储碎片化严重，集群性能和稳定性都会急剧下降。
为什么Topic不能减分区？
Topic减分区会造成数据丢失，这是Apache Kafka自身设计所限制的。
是否支持Compact的日志清理策略？
开源版本为2.2.0或以上的分布式消息服务Kafka实例支持Compact的日志清理策略。
如何查看哪些IP在消费消息？
在控制台消费组管理页面，查看消费实例。
哪里可以找到消费最佳实践？
最佳实践 - 消费者实践。
如何在修改Consumer的offset？
提交消费位点的机制取决于客户端SDK，一般支持以下两种机制：
自动提交：按照时间间隔，SDK把消费过的最新消息的位点+1提交上去。
手动提交：应用程序里，把消费过的最新消息的位点+1提交上去。
在控制台的消费组管理页面，可以重置消费位置。
为什么在控制台看不到Group的订阅关系？
问题现象
已启动某个Group的消费线程，但在分布式消息服务Kafka控制台的消费组管理页面，查不到该Group订阅的Topic信息。
可能原因
客户端的配置错误或者所处的网络环境异常导致无法成功订阅消息。
采用assign方式手动指定消费者订阅某个Topic分区的消息，并未提交消费位点。
解决方案
排查客户端配置问题
排查客户端网络问题
需提交消费位点
为什么同一个分区被多个消费线程消费了？
消费客户端使用“StickyAssignor”分配模式消费消息时，发现同一个分区被多个消费线程消费，出现数据错乱的情况。
可能原因
客户端低于2.3版本。2.3版本以前的客户端有可能将同一个分区分配给多个消费线程进行消费。
解决方案
建议您升级客户端至2.3或以上版本，或者换成其他分区分配策略。
使用建议：“StickyAssignor”分配策略目前在一些情况下会产生分配偏差，比如分区重复分配问题。如果不是业务特殊需求，不建议使用该分配策略。
为什么Group的状态一直处于“删除中”？
当前删除Group采用的是异步删除方式，一般情况下，删除一个Group大概需要耗时1-2分钟。
问题现象
在分布式消息服务Kafka控制台的消费组管理页面删除Group后，此Group的状态一直处于删除中。删除中
可能原因
Group中存在活跃的订阅关系。
Group上有消费线程在提交新的消费位点。
解决方案
登录分布式消息服务Kafka控制台，查看Group的订阅关系。
若查询到Group订阅了Topic或者有消费线程在提交新的消费位点，请先取消订阅关系再删除Group。
为什么消费组的消息堆积量为“0”或者未显示
查看Group的消费状态时，消费位点不等于最大位点，但Group的堆积量显示为“0”，或者未显示。
可能原因
未曾提交过消费位点，或者消费位点已过期。
提交过消费位点并且未过期，但由于部分消息数据过期被删除，导致消费位点小于或者等于最小位点。
为什么不能登录部署分布式消息服务Kafka的机器？
分布式消息服务Kafka提供全托管免运维服务，您无需登录机器，集群的一些基础信息会通过监控告警进行透传。
修改企业项目，是否会导致Kafka重启？
修改企业项目不会导致Kafka重启。
Kafka实例支持批量导入Topic功能么？
支持批量创建Topic，可下载批量创建模板填写信息后导入。见操作指南批量创建Topic。
消息被消费后，没有删除，导致Kafka存储空间占满？
当消息被消费后，Kafka默认情况下并不会立即删除它们，而是将其保留在磁盘上。这可能会导致Kafka存储空间占满的问题。
Kafka可以删除消费组下不用的Topic吗？
可以。操作步骤如下：
（1）登录管理控制台。
（2）进入Kafka管理控制台。
（3）在实例列表页在操作列，目标实例行点击“管理”。
（4）点击“主题管理”后进入主题管理页面后点击“更多”，出现如下图弹窗。
（5）在Topic所在行，单击“删除”，并选择确定。
Kafka实例是否需要创建消费组、生产者和消费者？
不需要额外创建，支持创建消费组，操作步骤如下：
（1）登录管理控制台。
（2）进入Kafka管理控制台。
（3）在实例列表页在操作列，目标实例行点击“管理”。
（4）点击“消费组管理”后进入消费组管理页面。
（5）点击“新建消费组”后，输入消费组名称，点击创建。
注：消费组业务应用接入使用时客户端也可自动创建。
Kafka生产消息的最大长度是多少？
Kafka生产消息的最大长度默认情况下为1MB。
消息超过老化时间，消息仍存在的原因
消息超过老化时间（message retention time）仍然存在的原因可能有以下几种情况：
- 消息存储配置错误：可能是由于配置错误导致消息的老化时间没有按照预期进行清理。您可以检查Kafka的配置文件中log.retention.ms或log.retention.hours参数，确保其设置正确。
- 消费者组延迟或故障：如果消息被分发给了一个消费者组，但消费者组中的某个消费者出现延迟或故障，导致消息无法及时消费，那么这些消息可能会超过老化时间而仍然存在。
- 消息处理逻辑问题：在消费者端的消息处理逻辑中可能存在问题，导致消息无法被及时处理或消费。这可能是由于代码bug、处理逻辑错误或其他原因引起的。
- 多个分区或主题的不一致：如果您的消息被分布在多个分区或主题中，而某些分区或主题的老化时间设置与其他分区或主题不一致，那么消息可能会在某些分区或主题中超过老化时间而仍然存在。
为了解决这个问题，您可以采取以下措施：
- 检查Kafka的配置文件，确保消息的老化时间设置正确。
- 检查消费者组的消费情况，确保消费者能够及时消费消息。
- 检查消费者端的消息处理逻辑，确保消息能够被正确处理和消费。
- 检查分区或主题的配置，确保它们的老化时间设置一致。
