系统间通信方式之(Kafka的集群方案介绍结束3)(二十二)
来源:互联网 发布:最新课件制作软件 编辑:程序博客网 时间:2024/05/21 05:20
4-5、Kafka原理:消费者
作为Apache Kafka消息队列,它的性能指标相当一部分取决于消费者们的性能——只要消息能被快速消费掉不在Broker端形成拥堵,整个Apache Kafka就不会出现性能瓶颈问题。
4-5-1、基本使用
我们首先使用Kafka Client For JAVA API为各位读者演示一下最简单的Kafka消费者端的使用。以下示例代码可以和上文中所给出的生产者代码相对应,形成一个完整的消息创建——接收——发送过程:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
以上代码片段有几个关键点需要进行一下说明:
- “map.put(“my_topic2”, 1);” 这句代码表示将会为名叫“my_topic2”的队列创建数量为1的消费者。在一个进程的连接中,您可以指定创建多个topic的消费者数量。例如:
- 1
- 2
- 3
- 4
- 5
- 6
- 每一个消费者都需要一个独立的线程进行工作。您可以将工作任务放入已经创建好的线程池(推荐这样做),也可以像以上代码示例中那样创建一个线程并运行任务。
- 1
- 2
- 3
- 4
- 5
- 6
- 在开发过程中,消费者端无需知道任何一个Broker的位置。但是必须至少知道一个zookeeper服务节点的位置。通过这个位置,消费者端首先会去zookeeper服务上查找指定的topic的分区情况和已有的消费者情况。
4-5-2、分区与消费者负载
Apache Kafka集群中的消费者以线程为单位,如在上一小节代码段所示:我们在一个进程中,为Topic为“my_topic2”的队列创建了一个线程,这个线程就是一个消费者——属于名为“group2”的用户组。这时,Topic中所有分区的消息都会交给这个消费线程进行消费。如下图所示:
虽然一个消费者可以同时消费Topic中多个分区(Partition)的消息,但在生产环境下为了获得更优的消费性能并不建议这样做。由于单个消费者线程的处理能力是有限的,一旦出现数据洪峰,消息就会堆积在Broker端无法被处理(如果消费者端使用了线程池,则可能堆积在消费者端,这要看您怎么编写代码)。所以上一个小节那样的消费者编码方式,最多就是用来做做“Hello World”那样的示例,没有更多的使用价值了。
4-5-3、优化 一:
第一种改进方法,就是让一个消费者只消费一个分区(Partition)中的消息,且整个系统中的消费者大于等于Topic中的分区数量。设计方案如下:
如上图所示,这个Topic下一共有四个分区(Partition),对应的消费者数量也有四个,但是这四个消费者同属于一个进程,存在于同一个物理节点上。我们根据这个设计方案,更改之前消费者端的代码,如下(为了节约篇幅,只给出主要的更改位置):
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
4-5-4、优化 二:
显然“优化方案一”中的做法虽然实现了4消费者分别对应4个分区的负载均衡方案,但是受限于单个物理节点的处理性能,所以这种方案的处理性能还有进一步优化的可能。我们可以在多个节点物理节点上均匀散步这些消费者,对Topic分区中的消息进行一一对应的消费,如下图所示:
上图所示的设计思路中,我们使用了2个物理节点完成消息的消费任务,每个服务节点上开启的消费进程上有两个消费者线程。这样Topic中4个分区的消息就会被均匀分布到2个物理节点中,且每一个物理节点处理两个分区中的消息。
注意:可能您在分别启动这些消费进程的时候,由于时间上存在差异,某一台服务节点上的消费进程将暂时被分配多个分区进行消息接收。但没有关系,当这个消费者性能到达瓶颈,分区中的消息出现拥堵的时候,这个分区就会被新的消费者所代替,直到10个消费者线程分别和10个分区建立一一对应关系为止
来源:http://blog.csdn.net/yinwenjie(未经允许严禁用于商业用途!)
- 系统间通信方式之(Kafka的集群方案介绍结束3)(二十二)
- 系统间通信方式之(Kafka的集群方案介绍1)(二十)
- 系统间通信方式之(Kafka的集群方案介绍2)(二十一)
- 系统间通信方式之(ActiveMQ的集群方案介绍结束)(十八)
- 系统间通信方式之(ActiveMQ的集群方案介绍结束2之高潮部分了【(1master+2slave)*cluster】)(十九)
- 系统间通信方式之(ActiveMQ的集群方案介绍上)(十七)
- 系统间通信方式之(Kafka的实际使用场景和使用方案二)(二十四)
- 系统间通信方式之(Kafka的实际使用场景和使用方案)(二十三)
- 系统间通信方式之(Kafka的实际使用场景和使用方案三)(二十五)
- 系统间通信方式之(ActiveMQ的基础使用详细介绍1)(十二)
- 系统间通信方式之(基于DUBBO的详细介绍)(十一)
- kafka系列之集群部署使用(二)
- ActiveMQ的集群方案(二)
- 架构设计:系统间通信(25)——ActiveMQ集群方案(上)
- 架构设计:系统间通信(26)——ActiveMQ集群方案(下)
- 架构设计:系统间通信——ActiveMQ集群方案(上)
- 进程间的通信方式(二)
- 系统间通信方式之(ActiveMQ的使用性能优化3)(十四)
- 常见sql注入原理详解!
- 深度学习最全优化方法总结比较(SGD,Adagrad,Adadelta,Adam,Adamax,Nadam)
- caffe python接口:mnist
- 织梦手机端文章页图片被拉长解决方式
- MySQL触发器
- 系统间通信方式之(Kafka的集群方案介绍结束3)(二十二)
- Fiori2.0学习笔记-controller
- win10下安装使用pytorch以及cuda9、cudnn7.0
- 插入排序
- EMAC
- iOS开发- clang -rewrite-objc的使用
- NestedScrollView嵌套RecycleView的问题
- springCloud入门(二)eureka分布式注册中心
- XMLHttpRequest对象详解