【消息队列面试】15-17:高性能和高吞吐、pull和push、各种MQ的区别
十五、kafka高性能、高吞吐的原因
1、应用
日志收集(高频率、数据量大)
2、如何保证
(1)磁盘的顺序读写-pagecache关联
rabbitmq基于内存读写,而kafka基于磁盘读写,但却拥有高性能
传统磁盘读写都是随机读写,数据没有存到一起,浪费了寻址时间和旋转时间
如果是顺序读写:无需寻址 ,一次往后读,同时还有按page预读到内存的机制
容量大,消息堆积能力比内存更强大
(2)零拷贝技术-Linux支持(kafka高性能的原因)
传统方式:用户访问网卡
需要将用户态切换到内核态,由内核线程操作磁盘
使CPU存在上下文切换
此外,读取数据是将文件读到内核缓冲区,并拷贝到用户缓冲区,最后拷贝到内核态的socket缓冲区,将数据发到网卡,响应到客户端(用户态和内核态的两次切换)
零拷贝方式:
磁盘文件--内核缓冲区--网卡接口--消费者进程(不存在CPU的切换,直接在内核态完成消息的读取)
(原因:消息没有必要读到用户,消息只负责传递,无需读到用户缓冲区)【与java应用程序进行数据传递不同】
(3)分区分段+索引
partition可以保证topic的消息堆积,分区可以分散到多个broker,减轻了消息堆积
partition也是逻辑概念,实际存储:多个segment文件存储,针对segment又包含索引文件,提升读取效率,提高了读取数据的并行度(分段加锁)
(4)批量压缩
把多条消息使用gzip压缩,对压缩后的数据进行传输
(5)批量读写
堆积到一定的数量再进行发送,可以节省带宽,并提高效率
(6)直接操作页存
直接操作pagecache(页存),而不是jvm-不需要创建对象等操作
避免了对象创建及GC的耗时,读写速度会更快,进程重启时,数据也不会丢失【堆中的数据会丢失】
pagecache的刷盘时间由操作系统完成,基于内存,效率高
十二、kafka的pull和push各有什么优缺点
1、pull-主动拉取
由消费者根据处理能力,自己控制
按需所取,但不实时
2、push-推送
实时发送消息
缺点:可能会导致消费者压力大,可能会压垮
十三、Kafka、ActiveMQ、RabbitMQ、RocketMQ对比
1、ActiveMQ-半死不活
生产环境中较少,支持的数据量较小
遵循JMS消息中间件的规范,支持事务的ACID特性
支持XA协议(两段式提交,MySQL也支持)
官方维护少,社区不活跃
万级别吞吐量
2、RabbitMQ
基于AMQP协议
使用erlang开发,性能比较好,支持高并发
客户端支持多种语言
社区活跃、文档全面
但erlang语言对java不友好,不利于二次开发
学习成本高、架构复杂
万级别吞吐量,不适用于高并发
3、kafka-高性能、高并发
高可用
生产环境大量使用
ELK使用kafka收集日志
缺陷:单机容量有限,一台broker能放的partition数量有限,64以内最好
社区更新慢,部分代码使用java开发,二次开发有限制
吞吐量百万级别,Apache大数据标配
4、RocketMQ-基于阿里-火箭
性能和吞吐较高,高可用
基于java,利于二次开发
☆高可靠,消息零丢失(适用于互联网金融)
已经被捐赠给阿帕奇,社区活跃度一般
支持语言比较少-java、c++
吞吐量十万级别
【消息队列面试】15-17:高性能和高吞吐、pull和push、各种MQ的区别的更多相关文章
- RabbitMQ消息队列(十一)-如何实现高可用
在前面讲到了RabbitMQ高可用集群的搭建,但是我们知道只是集群的高可用并不能保证应用在使用消息队列时完全没有问题,例如如果应用连接的RabbitMQ集群突然宕机了,虽然这个集群时可以使用的,但是应 ...
- 【消息队列】kafka是如何保证高可用的
一.kafka一个最基本的架构认识 由多个broker组成,每个broker就是一个节点:创建一个topic,这个topic可以划分为多个partition,每个partition可以存在于不同的br ...
- kafka高吞吐量的分布式发布订阅的消息队列系统
一:kafka介绍kafka(官网地址:http://kafka.apache.org)是一种高吞吐量的分布式发布订阅的消息队列系统,具有高性能和高吞吐率. 1.1 术语介绍BrokerKafka集群 ...
- kafka消息队列、环境搭建与使用(.net framework)
一:kafka介绍 kafka(官网地址:http://kafka.apache.org)是一种高吞吐量的分布式发布订阅的消息队列系统,具有高性能和高吞吐率. 1.1 术语介绍 BrokerKafka ...
- .NET中 kafka消息队列、环境搭建与使用
前面几篇文章中讲了一些关于消息队列的知识,就每中消息队列中间件,我们并没有做详细的讲解,那么,今天我们就来详细的讲解一下消息队列之一kafka的一些基本的使用与操作. 一.kafka介绍 kafka: ...
- 高性能、高可用、高扩展ERP系统架构设计
ERP之痛 曾几何时,我混迹于电商.珠宝行业4年多,为这两个行业开发过两套大型业务系统(ERP).作为一个ERP系统,系统主要功能模块无非是订单管理.商品管理.生产采购.仓库管理.物流管理.财务管理等 ...
- 深入剖析 RabbitMQ —— Spring 框架下实现 AMQP 高级消息队列协议
前言 消息队列在现今数据量超大,并发量超高的系统中是十分常用的.本文将会对现时最常用到的几款消息队列框架 ActiveMQ.RabbitMQ.Kafka 进行分析对比.详细介绍 RabbitMQ 在 ...
- 消息队列高手课,带你从源码角度全面解析MQ的设计与实现
消息队列中间件的使用并不复杂,但如果你对消息队列不熟悉,很难构建出健壮.稳定并且高性能的企业级系统,你会面临很多实际问题: 如何选择最适合系统的消息队列产品? 如何保证消息不重复.不丢失? 如果你掌握 ...
- [Java] 分布式消息队列(MQ)
概述 场景 服务解耦 削峰填谷 异步化缓冲:最终一致性/柔性事务 MQ应用思考点 生产端可靠性投递 消费端幂等:消息只能消费一次 高可用.低延迟.可靠性 消息堆积能力 可扩展性 业界主流MQ Acti ...
- rabbitmq学习(九) —— 关于消息队列的选型
转自http://cmsblogs.com/?p=3846 在IM这种讲究高并发.高消息吞吐的互联网场景下,MQ消息中间件是个很重要的基础设施,它在IM系统的服务端架构中担当消息中转.消息削峰.消息交 ...
随机推荐
- Containerd教程
文档是从B站有关视频上对应找到的,具体视频地址是:https://www.bilibili.com/video/BV1XL4y1F7QB?p=21&spm_id_from=333.880.my ...
- EFK-2:ElasticSearch高性能高可用架构
转载自:https://mp.weixin.qq.com/s?__biz=MzUyNzk0NTI4MQ==&mid=2247483811&idx=1&sn=a413dea65f ...
- kubernetes kubectl 命令自动补全
yum install -y bash-completion source /usr/share/bash-completion/bash_completion source <(kubectl ...
- 在Portainer上管理其他docker主机(这只是其中一种方式),另一种方式看这个文档:使用Portainer管理其他主机的docker应用有两种方式
其他主机开启远程连接docker端口 需要设置一下2375端口的监听.通过修改docker配置文件方式进行监听. 修改配置文件修改监听端口 使用Centos7安装的docker,所以下面的配置是适用于 ...
- ATT&CK系列一 知识点总结
一.环境搭建1.环境搭建测试2.信息收集二.漏洞利用3.漏洞搜索与利用4.后台Getshell上传技巧5.系统信息收集6.主机密码收集三.内网搜集7.内网--继续信息收集8.内网攻击姿势--信息泄露9 ...
- 《吐血整理》高级系列教程-吃透Fiddler抓包教程(26)-Fiddler如何抓取Android7.0以上的Https包-上篇
1.简介 众所周知,假如设备是android 7.0+的系统同时应用设置targetSdkVersion >= 24的话,那么应用默认是不信任安装的Fiddler用户证书的,所以你就没法抓到应用 ...
- Windows Socket 接口简介
Windows Socket接口是Windows下网络编程的接口,在介绍Windows Socket接口之前,首先要简单介绍一下TCP/IP协议和描述网络系统架构的 OSI模型,以及TCP/IP模型 ...
- vivo互联网机器学习平台的建设与实践
vivo 互联网产品团队 - Wang xiao 随着广告和内容等推荐场景的扩展,算法模型也在不断演进迭代中.业务的不断增长,模型的训练.产出迫切需要进行平台化管理.vivo互联网机器学习平台主要业务 ...
- Docker | 发布镜像到镜像仓库
本文记录发布镜像到 DockerHub 和 阿里云镜像仓库.工作中使用的是JFrog Artifactory 和 Harbor,没有太大差别. 发布镜像到DockerHub https://hub.d ...
- 聊一聊被 .NET程序员 遗忘的 COM 组件
一:背景 1.讲故事 最近遇到了好几起和 COM 相关的Dump,由于对 COM 整体运作不是很了解,所以分析此类dump还是比较头疼的,比如下面这个经典的 COM 调用栈. 0:044> ~~ ...