共计 2935 个字符，预计需要花费 8 分钟才能阅读完成。
数新网络官网已全新上线，欢送点击拜访
www.datacyber.com 数新网络_让每个人享受数据的价值
Kafka 介绍
Kafka 是最后由 Linkedin 公司开发，是一个分布式、反对分区的（partition）、多正本的（replica），基于 zookeeper 协调的分布式音讯零碎，它的最大的个性就是能够实时的解决大量数据以满足各种需要场景：比方基于 hadoop 的批处理零碎、低提早的实时零碎、Storm/Spark 流式解决引擎，web/nginx 日志、拜访日志，音讯服务等等，用 scala 语言编写，Linkedin 于 2010 年奉献给了 Apache 基金会并成为顶级开源我的项目。
Kafka 的应用场景
日志收集：一个公司能够用 Kafka 收集各种服务的 log，通过 kafka 以对立接口服务的形式凋谢给各种 consumer，例如 hadoop、Hbase、Solr 等。
音讯零碎：解耦和生产者和消费者、缓存音讯等。
用户流动跟踪：Kafka 常常被用来记录 web 用户或者 app 用户的各种流动，如浏览网页、搜寻、点击等流动，这些流动信息被各个服务器公布到 kafka 的 topic 中，而后订阅者通过订阅这些 topic 来做实时的监控剖析，或者装载到 hadoop、数据仓库中做离线剖析和开掘。
经营指标：Kafka 也常常用来记录经营监控数据。包含收集各种分布式应用的数据，生产各种操作的集中反馈，比方报警和报告。
Kafka 优化
Kafka 作为一款高性能消息中间件被广泛应用于各大零碎中，然而同其余中间件一样，也会存在一些问题。
音讯失落状况
音讯在发送端和生产端都有可能会产生数据失落的状况。
音讯发送端：
acks= 0 时，示意 producer 不须要期待任何 broker 确认收到音讯的回复，就能够持续发送下一条音讯。如果此时 broker 宕机，就会导致音讯失落。
acks= 1 时，至多要期待 leader 曾经胜利将数据写入本地 log，然而不须要期待所有 follower 是否胜利写入。作为集群应用时，如果 follower 还未胜利写入，在 leader 写入后，follow 还没有来得及 fetch 到 leader 的最新消息，leader 宕机了，follower 拉取失败，并开始进行 leader 选举，新的 leader 因为没有同步最新的音讯，导致该音讯失落。
acks=- 1 或 all 时，这意味着 leader 须要期待所有备份都胜利写入日志。这种策略会保障只有有一个备份存活就不会失落数据。然而须要 min.insync.replicas 配置的备份个数大于等于 2，当 leader 宕机之后，会从新进行 leader 选举，选举 lsr 列表中的第一个 broker 作为 leader，而 lsr 列表中的 broker 都是同步数据最多的，会保证数据不失落。
音讯生产端：
如果音讯是主动提交，万一生产到数据还没解决完，就主动提交 offset 了，然而此时你 consumer 间接宕机了，未解决完的数据失落了，下次也生产不到了。
音讯反复生产
音讯反复生产与音讯失落一样，在发送端和生产端都会产生数据反复生产的状况。
音讯发送端：
发送音讯如果配置了重试机制，服务端收到了音讯，并进行 ack 的时候，因为网络问题导致发送端始终没有收到服务端发送的返回音讯，就会启动重试机制再次发送。
音讯生产端：
如果生产端配置了主动提交，刚拉取了一批数据处理了一部分，还没来得及提交，服务挂了，下次重启又会拉取雷同的一批数据反复解决。
个别生产端都要进行生产幂等解决。
音讯乱序
如果发送端配置了重试机制，Kafka 不会等之前那条音讯齐全发送才去发送下一条音讯，这样可能会呈现，发送时程序为 1，2，3 的音讯，第一条超时后从新发送，前面两条发送胜利，最终生产端生产的程序是 2，3，1。
Kafka 要保障全链路音讯程序生产，须要从发送端开始，将所有音讯有序发送到同一个分区，而后用一个消费者去生产，然而这种性能比拟低，能够在消费者端接管到音讯后将须要保障程序生产的几条生产发到内存队列，一个内存队列开启一个线程程序解决音讯。
如果须要将音讯发送到不同分区并保障程序生产。个别不倡议这么做。发送端在发送音讯时，在音讯中增加一个排序号，消费者端在接管时定义一个 CountDownLatch，确保将须要程序生产的音讯收齐，依据排序号排序后再解决。
音讯积压
线上有时因为发送端发送音讯速度过快，或者生产端解决音讯过慢，导致 broker 积压大量未生产音讯。这种状况能够批改生产端程序，让其将收到的音讯疾速转发到其余 topic，而后再启动多个消费者同时生产新主题的不同分区。
因为音讯数据格式变动或生产端程序有 bug，导致消费者统一生产不胜利，也会导致 broker 积压大量未生产音讯。这种状况能够配置一个 topic 作为死信队列，将生产不胜利的的音讯放入到死信队列，之后再缓缓剖析死信队列里的音讯解决问题。
延时队列
延时队列存储的对象是延时音讯。指音讯被发送当前，并不想让消费者立即获取，而是期待特定的工夫后，消费者能力获取这个音讯进行生产，延时队列的应用场景有很多，比方：
在订单零碎中，一个用户下单之后通常有 30 分钟的工夫进行领取，如果 30 分钟之内没有领取胜利，那么这个订单将进行异样解决，这时就能够应用延时队列来解决这些订单了。
订单实现 1 小时后告诉用户进行评估。
实现思路：发送延时音讯时先把音讯依照不同的延迟时间段发送到指定的队列中（topic_5s,topic30s…,topic_n，这个个别不能反对任意时间段的延时），而后通过定时器进行轮询生产这些 topic，查看音讯是否到期，如果到期就把这个音讯发送到具体业务解决的 topic 中，队列中音讯越靠前的到期工夫越早，具体来说就是定时器在一次生产过程中，对音讯的发送工夫做判断，看下是否提早到对应工夫了，如果到了就转发，如果还没到这一次定时工作就能够提前结束了。
音讯回溯
如果某段时间对已生产音讯计算的后果感觉有问题，可能是因为程序 bug 导致的计算错误，当程序 bug 修复后，须要对之前已生产的音讯从新生产，能够指定从多久之前的音讯回溯音讯，这种能够用 consumer 的 offsetForTimes、seek 等办法制订从某个 offset 偏移的音讯开始生产。
消息传递保障
at most once（消费者最多收到一次音讯）：acks= 0 能够实现
at least once（消费者至多收到一次音讯）：acks=all 能够实现
exactly once（消费者刚好收到一次音讯）：at least once 加上消费者幂等性能够实现，还能够用 Kafka 生产者的幂等性来实现。
Kafka 事务
Kafka 的事务不同于 Rocketmq，Rocketmq 是保障本地事务与 mq 音讯发送的事务一致性，Kafka 的事务次要是保障一次发送多条音讯的事务一致性，个别在 Kafka 的流式计算场景用得多一点，比方，Kafka 须要对一个 topic 里的音讯做不同的流式计算解决，解决完别离发到不同的 topic 里，这些 topic 别离被不同的上游零碎生产，这种咱们必定心愿零碎发送到多个 topic 的数据放弃事务一致性。Kafka 要实现相似 Rocketmq 相似的分布式事务须要额定开发性能。
本期分享就到这里，欢送关注咱们理解更多精彩内容~
