正在生成
详细信息:
检测到您已登录华为云国际站账号,为了您更好的体验,建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
truststore文件可以用PEM格式的吗? 使用Java语言连接实例时,只能使用JKS格式的证书,不支持转成PEM格式。 父主题: 连接问题
中的消息可继续消费,待源实例的消息数据全部被消费完或老化后,业务可迁移到新的Kafka实例。具体请参考Kafka业务迁移。 父主题: 实例问题
Kafka监控显示消息堆积数跟实例里的消息数不一致? 问题现象:监控显示消息堆积数为8.1亿+,Kafka控制台显示实例中6个Topic的消息数总和为1亿+,两者不一致。 问题结论:两者统计方式不同,Kafka控制台显示的消息数为实例中未消费的消息个数,而监控显示的消息堆积数=Topic中的消息积压数*消费组数。
通过以下任意一种方法解决此问题: 重启Kafka Manager。 Kafka Manager只显示14天内有消费记录的消费组,如果您不想重启Kafka Manager,可以等待14天后Kafka Manager自动清除此消费组。 父主题: 消费组问题
ets将会被删除。Kafka判定消息组中没有在线的消费者(如empty状态),且没有offsets时,将会删除此消费组。 父主题: 消费组问题
nterprise_project Try again. 问题原因:Topic分区超过限制,不能继续创建Topic。 处理方法:建议扩大实例规格,实例规格增加,分区数也会相应增加。 父主题: Kafka Manager问题
海量消息堆积与弹性扩容 内建的分布式集群技术,使得服务具有高度扩展性。分区数可配置多达200个,存储空间、代理数量和代理规格支持弹性扩展,保证在高并发、高性能和大规模场景下的访问能力,轻松实现百亿级消息的堆积和访问能力。 多规格灵活选择 Kafka实例的带宽与存储资源可灵活配置,并且自定义Topic的分区数、副本数。
响,可继续使用扩容等功能。 如您有任何问题,可随时通过工单或者服务热线(4000-955-988或950808)与我们联系。 常见问题 已经购买Kafka 2.3.0的用户能否继续使用?Kafka 2.3.0与Kafka 2.7的功能和性能是否存在差异? 已购买Kafka 2.3
Manager创建Topic 登录Kafka Manager后,在页面顶部选择“Topic > Create”,然后按照界面参数填写即可。出于性能考虑,建议单个Topic的分区数设置为200以内。 图2 在Kafka Manager中创建Topic Topic名称开头包含特殊字符,例如“#”号时,监控数据无法展示。
例(假设当前权限仅包含DMS ReadOnlyAccess),表示“DMS ReadOnlyAccess”已生效。 在“服务列表”中选择云硬盘(假设当前策略仅包含DMS ReadOnlyAccess),若提示权限不足,表示“DMS ReadOnlyAccess”已生效。 在“服务
认证,数据通过明文传输,性能更好。 2020年7月以及之后购买的实例,Kafka实例的每个代理允许客户端单IP连接的个数默认为1000个,在此之前购买的实例,Kafka实例的每个代理允许客户端单IP连接的个数默认为200个,如果超过了,会出现连接失败问题。您可以通过修改Kafka
在导航栏选择Topic,并在下拉列表中选择List。页面如图6所示,展示了队列列表以及分区数等。 列表中以“__”开头的队列为内部队列,严禁操作,否则可能导致业务问题。 图6 查看实例的Topic 队列详情页 单击具体的Topic名称,进入如图7所示页面。 图中①区域表示队列基本信息,包括副本数(Rep
分区、副本和代理的关系如下图所示: 在实际业务过程中可能会遇到各节点间或分区之间业务数据不均衡的情况,业务数据不均衡会降低Kafka集群的性能,降低资源使用率。 业务数据不均衡原因 业务中部分Topic的流量远大于其他Topic,会导致节点间的数据不均衡。 生产者发送消息时指定了
ance过程中是无法正常消费的,只有在rebalance动作完成才可以进行消费。 该现象与问题现象描述的偶现长时间时延行为相吻合,问题确定。 详细分析 查看用户消费组行为日志文件,文件中存在以下三种日志: Preparing to rebalance group 1 表示消费组开
单机和集群Kafka实例差异概述 单机版实例是分布式消费服务Kafka版提供的单代理实例,只适用体验和业务测试场景,无法保证性能和可靠性。如果需要在生产环境使用Kafka实例,建议购买集群实例。 单机实例在除“华北-北京一”、“亚太-雅加达”、“拉美-圣保罗一”和“拉美-圣地亚哥”以外区域均已上线。
当CPU使用率过高时,系统的运行速度会降低,并有加速硬件损坏的风险。 当磁盘写满时,相应磁盘上的Kafka日志目录会出现offline问题。此时,该磁盘上的分区副本不可读写,降低了分区的可用性和容错能力。同时由于Leader分区迁移到其他节点,会增加其他节点的负载。 CPU使用率高的原因
storage.high.v2", "available_zones" : [ "xxx" ], "type" : "evs", "unavailable_zones" : [ ] }, { "io_spec" : "dms.physical
本方案为业界通用的迁移方案,操作步骤简单,迁移过程由业务侧自主控制,整个过程中消息不会存在乱序问题,适用于对消息顺序有要求的场景。但是该方案中需要等待消费者业务直至消费完毕,存在一个时间差的问题,部分数据可能存在较大的端到端时延。 将生产客户端的Kafka连接地址修改为新Kafka实例的连接地址。
用被压垮,可在前后端系统间使用Kafka消息队列传递请求。 图3 消息队列应对秒杀大流量场景 日志同步 在大型业务系统设计中,为了快速定位问题,全链路追踪日志,以及故障及时预警监控,通常需要将各系统应用的日志集中分析处理。 Kafka设计初衷就是为了应对大量日志传输场景,应用通过
{ "io_spec" : "dms.physical.storage.high.v2", "type" : "evs", "available_zones" : [ "xxx", "xxx" ], "unavailable_zones"