哪家做网站的公司比较好,网站被k文章修改,oppo软件商店下载官方,个人网站建设的花费目录 1 可靠的数据传递1.1 Kafka的可靠性保证1.2 复制1.3 Broker配置1.3.1 复制系数1.3.2 broker的位置分布1.3.3 不彻底的首领选举1.3.4 最少同步副本1.3.5 保持副本同步1.3.6 持久化到磁盘 1.2 在可靠的系统中使用生产者1.2.1 根据需求配置恰当的acks1.2.2 配置重试参数1.2.3… 目录 1 可靠的数据传递1.1 Kafka的可靠性保证1.2 复制1.3 Broker配置1.3.1 复制系数1.3.2 broker的位置分布1.3.3 不彻底的首领选举1.3.4 最少同步副本1.3.5 保持副本同步1.3.6 持久化到磁盘 1.2 在可靠的系统中使用生产者1.2.1 根据需求配置恰当的acks1.2.2 配置重试参数1.2.3 处理不可重试错误 1.3 在可靠的系统中使用消费者1.3.1 消费者的可靠性配置1.3.2 自动提交偏移量1.3.3 手动提交偏移量1. 总是在处理完消息后提交偏移量2. 提交频率时性能和重复消息数量之间的权衡3. 在正确的时间点提交正确的偏移量4. 消费者再均衡5. 消费者重试6. 消费者可能需要维护状态 1.4 验证系统可靠性1.4.1 验证配置1.4.2 验证应用程序 1.5 监控系统可靠性 2 精确一次性语义 1 可靠的数据传递
1.1 Kafka的可靠性保证
分区中的消息时有序的一条消息只有被写入分区所有的同步副本时才被认为是“已提交”只要还有一个副本是活动的已提交的消息就不会丢失消费者只能读取已提交的消息
1.2 复制
同步副本需满足的条件
与ZooKeeper之间有一个活跃的会话在过去的6秒内向ZooKeeper发送过消息在过去的10秒内从首领那里复制过消息在过去的10秒内从首领那里复制过最新消息
1.3 Broker配置
1.3.1 复制系数
broker级别配置default.replication.factor1 topic级别配置replication.factor1 建议非关键数据小于3
1.3.2 broker的位置分布
建议把broker分布在多个不同的机器上
1.3.3 不彻底的首领选举
unclean.leader.election.enablefalse 指示是否启用非同步副本可以被选为首领作为首领选举的最后手段即使这样做可能会导致数据丢失
1.3.4 最少同步副本
min.insync.replicas1 最小同步副本数。min.insync.replicas(默认值为1)代表了正常写入生产者数据所需要的最少ISR个数, 当ISR中的副本数量小于min.insync.replicas时Leader停止写入生产者生产的消息并向生产者抛出NotEnoughReplicas异常阻塞等待更多的 Follower 赶上并重新进入ISR, 因此能够容忍min.insync.replicas-1个副本同时宕机。当与min.insync.replicas和acks一起使用时可以实现更大的耐用性保证。一个典型的场景是创建一个复制因子为3的主题将min.insync.replicas设置为2并使用acks “all”进行生产。
1.3.5 保持副本同步
replica.lag.time.max.ms30000 (30 seconds) 如果一个follower这段时间内没有发送任何fetch请求或者没有消费leader最新偏移量的消息那么leader将从isr中删除该follower。 zookeeper.session.timeout.ms18000 (18 seconds) 允许broker不向ZooKeeper发送心跳的时间间隔。如果超过这个时间不向ZK发送心跳ZK会认为broker已经死亡会将其移除出集群。
1.3.6 持久化到磁盘
Kafka会在重启之前和关闭日志片段的时候将消息冲刷到磁盘上或者等Linux系统页面缓存被填满时冲刷。拥有不同机架上的副本的多个磁盘比只写入首领磁盘更加安全。不过也可以让broker更频繁的写入磁盘。 flush.messages9223372036854775807 此设置允许指定一个间隔在该间隔我们将强制对写入日志的数据进行fsync。例如如果将其设置为1我们将在每条消息之后进行fsync如果是5我们将在每5条消息之后进行fsync。通常我们建议您不要设置此项并使用复制以提高耐用性并允许操作系统的后台刷新功能因为它更高效。此设置可以在每个主题的基础上覆盖请参阅每个主题配置部分。 flush.ms9223372036854775807 此设置允许指定一个时间间隔在该时间间隔内我们将强制对写入日志的数据进行fsync。例如如果将其设置为1000我们将在1000毫秒后进行fsync。通常我们建议您不要设置此项并使用复制以提高耐用性并允许操作系统的后台刷新功能因为它更高效。
1.2 在可靠的系统中使用生产者
1.2.1 根据需求配置恰当的acks
acks参数指定了生产者在多少个分区副本收到消息的情况下才会认为消息写入成功。允许以下设置 acks0。如果设置为零则生产者根本不会等待来自服务器的任何确认。该记录将立即添加到套接字缓冲区并被视为已发送。在这种情况下无法保证服务器已收到记录重试配置也不会生效因为客户端通常不会知道任何故障。为每条记录返回的偏移量将始终设置为-1。 acks1。表示只要首领收到消息并将记录成功写入其本地日志就返回成功响应不等待所有追随者的确认。在这种情况下如果首领在确认成功后追随者复制之前崩溃则记录将会丢失。 acksall。表示首领将等待同步复制集合中所有的副本都确认收到了记录。这保证了只要至少有一个同步复制副本保持活动状态记录就不会丢失。这是最有力的保证。这相当于acks-1的设置。 请注意启用幂等性要求此配置值为“all”。如果设置了冲突的配置并且没有显式启用幂等性则会禁用幂等性。
1.2.2 配置重试参数
设置自动重试并使用默认重试次数。 将delivery.timeout.ms设置成愿意等待的时长生产者会在这段时间内重试。
1.2.3 处理不可重试错误
例如
不可重试的broker错误消息大小身份验证在将消息发送给broker之前发生的错误比如序列化错误在生产者道道重试次数上限或重试消息占用的内存达到上限时发生的错误超时
1.3 在可靠的系统中使用消费者
1.3.1 消费者的可靠性配置
group.id auto.offset.reset
1.3.2 自动提交偏移量
如果所有的处理逻辑都是在轮询里进行的并且不需要维护轮询之间的状态比如为了聚合数据那么就很简单可以使用自动提交在轮询结束时提交偏移量。 enable.auto.commit 无法控制应用应用程序可能重复处理的消息的数量 如果应用程序把消息交给另一个后台线程处理那么只能使用手动提交了 auto.commit.interval.ms 自动提交的频率过大会增加重复的概率过小会增加额外开销
1.3.3 手动提交偏移量
手动提交偏移量增加了灵活性但也增加了复杂度并且有可能对性能产生影响所以可能需要考虑如下事项
1. 总是在处理完消息后提交偏移量
如果所有的处理逻辑都是在轮询里进行的就很简单选择一个合适的提交频率 如果涉及额外线程该如何呢
2. 提交频率时性能和重复消息数量之间的权衡
3. 在正确的时间点提交正确的偏移量
一定要在处理完后在提交偏移量
4. 消费者再均衡
如何在分区被撤销之前提交偏移量 如何在应用程序被分配到新分区并清理状态时提交偏移量
5. 消费者重试
如果遇到批次中的部分消息需要稍后处理。因为消费者不能针对每一条消息提交偏移量而是提交最后一条成功的偏移量所以需要借助额外的工具来处理。 有两种模式来解决这个问题
在遇到可重试错误时提交最后一条处理成功的消息的偏移量然后把还未处理好的消息保存到缓冲区这样下一个轮询就不会把他们覆盖掉并调用消费者的pause()方法确保其他轮询不会返回数据之后继续处理缓冲区里的消息。在遇到可重试错误时把消息写到另一个重试主题并继续处理其他消息。另一个消费者群组负责处理重试主题中的消息或者让一个消费者同时订阅主主题和重试主题。这种模式有点像其他消息系统中的死信队列。
6. 消费者可能需要维护状态
1.在提交偏移量的同时状态存入另一个主题中可以开启事务来保证一致性。当一个线程重新启动时就可以读取状态和从偏移量处读取消息。 2. 使用流式处理框架
1.4 验证系统可靠性
1.4.1 验证配置
测试场景
首领选举控制器选举滚动重启不彻底的首领选举
1.4.2 验证应用程序
测试场景
客户端与服务器断开连接客户端与服务器之间存在高延迟磁盘被填满磁盘被挂起首领选举滚动重启broker滚动启动消费者滚动重启生产者
1.5 监控系统可靠性
生产者
错误率重试率
消费者
消费者滞后
broker
kafka.server:typeBrokerTopicMetrics,nameFailedProduce-RequestsPerSeckafka.server:typeBrokerTopicMetrics,nameFailedFetch-RequestsPerSec
2 精确一次性语义
To be continued …
