Apache Kafka

线程与线程之间数据交互

问题1:长时间的消耗消息与发送速率不匹配,就会导致数据积压,导致资源消耗,导致系统不可用

进程与进程之间的数据交互

问题1:会增加逻辑判断标记数据具体是发送给谁的,消耗计算资源,降低系统相应速度

解决:

点对点模型:消息队列中的消息每个只能被消费一次

发布订阅模型(PS):

第一节

开发中消息中间件对比

特性	ActiveMQ	RabbitMQ	RocketMQ	Kafka
单机吞吐量	万级,比RocketMQ,Kafka低一个数量级	万级,比RocketMQ,Kafka低一个数量级	10万级,支持高吞吐	10万级,支持高吞吐
Topsic数量对于吞吐量的影响			Topic可以达到几百/几千量级	Topic可以达到几百量级.如果更多的话,吞吐量会大幅下降
时效性	ms级	微秒级别,延迟较低	ms级	ms级
可用性	高,基于主从架构实现高可用	高,基于主从架构实现高可用	非常高,分布式架构	非常高,分布式架构
消息可靠性	有较低概率丢失数据	基本不丢失	经过参数优化配置,可以做到0丢失	经过参数优化配置,可以做到0丢失
功能支持	MQ领域的功能极具完备	并发能力强,性能极好,延时很低	MQ功能较为完善,分布式,拓展性好	功能较简单,支持简单的MQ功能,再大数据领域被广泛使用
其他	再很早的软件,社区不是很活跃	开源,稳定社区活跃度高	阿里开发,社区活动不高	开源,高吞吐量,社区活跃度极高

Kafka-组件

Kafka代码-生产者

📎KafkaConsumerTest.java

Kafka代码-消费者

📎KafkaProducterTest.java

kafka-基础架构图形推演

问题:因为有很多的生产和和很多的消费者,导致大量的吞吐数据导致IO热点问题,导致单一的节点变成系统的瓶颈,降低系统稳定性

解决方案:

• 横向扩展:增加服务节点,搭建服务器集群,降低单点故障带来的风险
• 纵向扩展:增加系统的资源配置

注意:当前topic切换成多块,这样的话数据也会切割成多块,要给不同的数据库增加编号(分区:顺序号--partition:1)

问题提出:当其中一个Broker down掉之后会丢失一条数据,这样数据不安全,如何破局--互相备份

为了数据的可靠性,可以将数据文件进行备份,但是在kafka中没有备份的概念,在kafka中称之为副本

在kafka中多个副本只能由一个副本进行读写操作,其他副本只能做备份操作

具有读写的副本称为:leader副本

具有备份的副本称为:foolower副本

基础组件图形推演

为了防止某个服务节点因为某种原因导致down掉-但实际并没有down掉,为了监控集群各个节点的运行情况提高集群服务的可用性,会在集群中找一个节点做集群的管理者

但是此时又有一个问题,当一个管理者出现问题,此时他下边的所有Broker都有问题这时,如何破局

• 给管理者增加备份(存在问题-两个都down掉)

  

• 任何一个节点都可以做备份(存在问题--备份太多了,那个做管理者(ZppKeeper选举插件))