Event Streams 可用性的服务级别协议 (SLA)
标准套餐
Event Streams 标准套餐通过多专区区域部署提供高可用性体系结构。 在多区域中,Event Streams 服务分布在三个可用区域,这意味着集群能够抵御单个区域或该区域中任何组件的故障。
Event Streams 服务在标准计划中可用性为 99.99 %。 有关 IBM Cloud®中高可用性服务的 SLA 的更多信息,请参阅 IBM Cloud(公共云)的服务级别协议。
企业套餐
Event Streams 企业套餐通过多专区区域部署提供高可用性体系结构。 在多区域中,Event Streams 服务分布在三个可用区域,这意味着集群能够抵御单个区域或该区域中任何组件的故障。
在多专区区域部署中,Event Streams 服务在企业套餐上的可用性为 99.99%。 有关 IBM Cloud中高可用性服务的 SLA 的更多信息,请参阅 IBM Cloud(公共云)的服务级别协议。
当 Event Streams 服务在非高可用性配置 (例如,单专区位置) 中运行时,可用性为 99.9%。 有关 IBM Cloud中非高可用性服务的 SLA 的更多信息,请参阅 IBM Cloud(公共云)的服务级别协议。
我们如何度量可用性?
服务实例的性能、错误率及其对合成操作的响应会受到持续监视。 中断会进行记录。 有关更多信息,请参阅 Event Streams。
可用性是指应用程序生成和消耗 Kafka 主题中的消息的能力。
要实现此可用性,您需要考虑什么?
要从应用程序角度实现高级别的可用性,您应考虑连接性、 吞吐量以及消息的一致性和耐久性。 用户负责设计其应用程序以优化其业务的这三个元素。
连接
因为云的性质是动态的,所以应用程序一定会发生连接中断情况。 连接中断并不会视为服务故障。
重试次数
Kafka 客户端提供重新连接逻辑,但您必须为生产者明确启用重新连接。 欲了解更多信息,请查看 retries
属性。 60 秒内再次进行连接。
重复项
启用重试可能会导致信息重复。 根据连接丢失的时间,生产者可能无法确定服务器是否成功处理消息,因此必须在重新连接时再次发送消息。 设计应用程序以期望重复消息。
如果无法容忍重复,您可以使用 idempotent
生产者功能(来自 Kafka 1.1 ),以防止在重试时出现重复。 欲了解更多信息,请查看 enable.idempotence
属性。
吞吐量
吞吐量以集群中每秒可以发送和接收的字节数表示。
标准计划的具体指导
有关吞吐量指导信息,请参阅“限制和配额——标准”。
企业计划的具体指导
有关吞吐量指导信息,请参阅限制和配额 - 企业。
度量
检测应用程序以了解它们的执行情况。 例如,发送和接收的消息数、消息大小和返回码。 了解应用程序的使用情况可帮助您恰当地配置其资源,例如有关主题的消息的保留时间。
饱和度
当集群可容纳的流量接近上限时,生产者的速度开始变慢,延迟增加,最终出现超时错误等错误。 消息一致性和耐久性可能也会受到影响,具体取决于配置。 有关更多信息,请参阅 消息的一致性和耐久性。
消息的一致性和耐久性
Kafka 通过在集群中的其他节点上复制其接收到的消息来实现其可用性和耐久性,然后可以在发生故障时使用这些消息。Event Streams 使用三个副本 (default.replication.factor = 3),这意味着节点接收的每条消息都将复制到不同可用性区域中的其他两个节点。 这样,在不丢失数据或功能的情况下,可以容忍丢失节点或可用性专区。
生产者 acks
方式
虽然所有消息都是复制的,但应用程序可以通过使用生产者的 acks
模式属性来控制它们生成的消息传输到服务的稳健性。 此属性提供有关速度和消息丢失风险的选项。 对于 Kafka 3.0,缺省客户机设置为 acks=all
(在此版本之前为 acks=1
)。 设置 acks=all
表示生产者成功返回,只要它所连接的代理和集群中至少还有一个代理都已确认接收消息。 使用 acks=all
的优点是它提供了最高级别的耐久性,因此可防止消息数据丢失。
同步副本
在 Event Streams 使用的配置中,Kafka 选择一个代理作为每个分区副本的引导者,并选择另外两个代理作为追随者。 来自客户机的消息数据将发送到分区的引导者,并复制到追随者。 如果追随者与领导者保持同步,那么他们将被视为“同步”副本。 根据定义,领导者始终被视为处于同步状态。
如果分区的引导者变得不可用 (可能是因为对代理程序应用了维护),那么 Kafka 会自动选择另一个同步副本以成为新的引导者。 此过程会快速执行,并由 Kafka 客户机自动处理。
不干净的领导人选举
Event Streams 禁用不干净的引导者选择。 此设置无法更改。
术语 不干净的引导者选择 描述在分区的所有同步副本变为不可用时 Kafka 如何响应。 启用不干净的引导者选择后,Kafka 将通过使第一个副本成为可供分区使用的引导者来恢复,而不考虑它是否处于同步状态。 如果选取为引导者的副本未从先前引导者复制所有消息数据,那么这可能会导致消息数据丢失。 禁用不干净的引导者选择 (如 Event Streams的情况) 时,Kafka 会等待同步副本变为可用,并选择它作为分区的新引导者。 这可避免在启用不干净的领导者选择时可能发生的消息数据丢失。 权衡是恢复可能需要更长时间,因为 Kafka 可能必须等待特定代理程序恢复联机,然后才能使分区可供客户机生成和使用消息数据。
单专区位置部署
为实现最高可用性,我们建议使用我们的高可用性公共环境,这些环境是在我们的多专区位置中构建的。 在多专区位置,我们的 Kafka 集群分发到 3 个可用性专区,这意味着集群可从单专区或该专区内任何组件的故障中恢复。 某些客户需要地理区域,因此希望在地理上本地的单一专区位置中供应 Event Streams 集群。Event Streams 支持此部署模型,但是请注意以下可用性权衡:
-
在单专区位置中,有些类别的单个故障可能导致集群脱机一段时间。 例如,整个数据中心的故障或者共享组件(例如底层系统管理程序、SAN 或网络)的更新或故障。 这些故障反映为单专区位置的 SLA 减少。
-
将 Kafka 分散到多个区域的好处是可以将导致整个集群瘫痪的故障几率降到最低。 相反,单个故障可能会导致一个区域内的整个集群瘫痪,这种可能性很小。 在极端情况下也可能导致数据丢失。 例如,即使生产者使用
acks=all
,如果所有 Kafka 节点同时关闭,可能会出现一些邮件,经纪人已经确认收到,但基础文件系统尚未完成向磁盘的刷新。 这些未发送的消息可能会丢失。
有关更多信息,请参阅消息确认。 在许多用例中,这不一定是问题。 但是,如果在任何情况下消息丢失都不可接受,请考虑其他策略,例如使用多可用性专区集群、跨区域复制或生产者端消息检查点操作。