小米公司网站前建设分析wordpress开发环境搭建

当前位置： 首页 > news >正文

小米公司网站前建设分析,wordpress开发环境搭建,网站建设回龙观,网站开发的任务要求阿伟开始学Kafka 概述 人生若只如初见#xff0c;阿伟心里回想起了第一次和Kafka见面的场景#xff0c;记忆虽然已经有些模糊#xff0c;但是感觉初次见面是美好的。积累了一些实战经验之后#xff0c;阿伟感觉不能再是面对百度开发了#xff0c;于是决心系统的学习一下Ka…阿伟开始学Kafka 概述 人生若只如初见阿伟心里回想起了第一次和Kafka见面的场景记忆虽然已经有些模糊但是感觉初次见面是美好的。积累了一些实战经验之后阿伟感觉不能再是面对百度开发了于是决心系统的学习一下Kafka。本文将作为开篇开启Kafka系列学习心得总结文章。 一、基本概念 本节将汇总讲解一下Kafka的核心概念对于初学者来说学习一项技术先要做一些整体的了解于是阿伟对Kafka核心概念进行了梳理. 核心概念 1、Topic Kafka根据topic对消息进行归类发布到Kafka集群的每条消息都需要指定一个topic 2、Parition 物理上的概念一个topic可以分为多个partition每个partition的内部时有序的 3、Broker 消息中间件处理节点一个Kafka节点就是一个broker一个或者多个Broker可以组成一个Kafka集群 4、ConsumerGroup 每个Consumer属于一个特定的ConsumerGroup一条消息可以被多个不同的ConsumerGroup消费到那时一个ConsumerGroup中只能有一个Consumer能够消费该消息 5、Consumer 消息消费者从Broker读取消息的客户端 6、Producer 消息生产者向Broker发送消息的客户端 消息类型 普通消息、顺序消息、延时消息 消费模式 集群消费、广播消费 二、市面上流行的消息中间件特性对比 如下将市面上流行的几款消息中间件Kafka、RocketMQ、RabbitMQ进行了多维度的对方分析 三、Kafka难题 1、为什么要对topic下数据进行分区存储? 1.commit log文件会受到所在机器的文件系统大小的限制分区之后可以将不同的分区放在不同的机器上相当于对数据做了分布式存储理论上一个topic可以处理任意数量的数据 2.提高并行度 2、如何在多个partition中保证顺序消费? 方案一:首先将需要保证顺序的消息收集起来然后交给一个consumer去进行处理然后内部维护一个线程池让其中某一个线程去顺序执行这些消息eg:用户下单流程支付成功消息 - 库存消息 方案二:让多个消息构造一个特殊结构的顺序消息,当consumer收到时在一个线程中依次进行消费 3、消息丢失 1、生产者 1.1、acks0,表示producer不需要等待任何broker确认收到消息的回复就可以发送下一条消息性能最高但是最容易丢消息大数据统计报表场景对性能要求很高对数据丢失不敏感的情况可以用这种 1.2、acks1,表示至少要等待leader已经成功将数据写入本地log,但是不需要等待所有follower是否成功写入就可以继续发送下一条消息这种情况下如果follower没有成功备份数据而此时leader又挂掉则消息会丢失 1.3、ack-1或者all,这意味着leader需要等待所有备份(min.insync.replicas配置的备份个数)都成功写入日志这种策略会保证只要由一个备份存活就不会丢失数据这是最强的数据保证一般除非是金融级别或跟钱打交道的场景才会使用这种配置当然如果min.insync.replicas配置的是1则也可能丢消息跟acks1情况类似 2、消费者 如果消费这边配置的是自动提交万一消费到数据还没处理完就自动提交offset了但是此时consumer直接宕机了未处理完的数据丢失了下次也消费不到了 4、消费重复 1、生产者 发送消息如果配置了重试机制比如网络抖动事件过长导致发送端发送超时实际broker可能已经接收到消息但发送方会重新发送消息 2、消费者 如果消费这边配置的是自动提交刚拉取了一批数据处理了一部分但还没来得及提交服务挂了下次重启又会拉取相同的一批数据重复处理一般消费端都是要做消息幂等处理的 5、消息乱序 1、如果发送端配置了重试机制Kafka不会等之前那条消息完全成功了才去发送下一条消息这样就可能出现发送了123条2消息第一条超时了后面两条发送成功再重试发送第一条消息这时消息在broker端的顺序就是231了所以是否一定要配置重试要根据业务情况而定。也可以用同步发送的模式取发消息当然acks不能设置为0这样也能保证消息从发送端到消费端全链路有序kafka保证全链路消息顺序消费需要从发送端开始将所有有序消息发送到同一个分区然后用一个消费者去消费但是这种性能比较低可以在消费者端接收到消息后将需要保证顺序消费的几条消息发到内存队列(可以多搞几个)一个内存队列开启一个线程顺序消费处理。 2、一个parition同一时刻在一个consumer group中只能有一个consumer实例在消费 ,从而保证消费顺序。consumer group中的consumer数量不能比一个topic中的partion数量还要多否则多出来的consumer消费不到消息。Kafka只在parition的范围内保证消息消费的局部顺序性不能在同一个topic中的多个partition中保证总的消费性如果有在总体上保证消费顺序的需求那么我们可以通过将topic的partition数量设置为1将consumer group中的consumer instance数量也设置为1但是这样会影响性能所以kafka的顺序消费很少用。 6、消息积压 1.线上有时因为发送方发送消息速度过快或者消费放处理消息过慢可能会导致broker挤压大量未消费消息此种情况如果挤压了上百万未消费消息需要紧急处理可以修改消费端程序让其将收到地消息快速转发到其他topic(可以设置很多分区),然后再启动多个消费者同时消费新主题地不同分区。 2.由于消息数据格式变动或者消费者程序有bug导致消费者一直消费不成功也可能导致broker积压大量未消费消息.此种情况可以将这些消费不成功地消息转发到其他队列里去(类似死信队列),后面再慢慢分析死信队列里地消息处理问题。 总结 本文阿伟结合自己的理解从几个方面梳理了Kafka其中讲到了基本概念市面上消息中间件的对比以及Kafka在实际应用中会遇到一些问题点和处理思路。