数新网络官网已全新上线，欢送点击拜访
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相似的分布式事务须要额定开发性能。
本期分享就到这里，欢送关注咱们理解更多精彩内容~