消息中间件学习资料获取地址,请关注我私信“08”就可以领取!!!记住一定要私信
一、kafka
1、不完全符合jms规范,注重吞吐量,类似udp 和 tcp
2、一般做大数据吞吐的管道 我们现在的用途就是负责在各个idc之间通信
3、量大对数据不是百分之百保证的,会有数据丢失,不是百分百送达(amq和rmq等有重发机制,而kafka没有);在吞吐量有提升 ,在这方面就得有牺牲, 所以kafka适合大数据量流转, 比如日志数据 比如用作统计的数据。
二、activeMQ
ActiveMQ居于两者之间,类似于ZemoMQ,它可以部署于代理模式和P2P模式。类似于RabbitMQ,它易于实现高级场景,而且只需付出低消耗。它被誉为消息中间件的“瑞士军刀”。
三:RocketMQ(阿里官方指定消息中间件)
RocketMQ 是一款开源的分布式消息系统,基于高可用分布式集群技术,提供低延时的、高可靠的消息发布与订阅服务。同时,广泛应用于多个领域,包括异步通信解耦、企业解决方案、金融支付、电信、电子商务、快递物流、广告营销、社交、即时通信、移动应用、手游、视频、物联网、车联网等。
消息中间件使用的典型场景优四个
-
1.典型的异步处理
-
2.应用解耦
-
3.流量削锋
-
4.消息通讯四个场景
比如:今日头条的私信就是一个典型的消息通讯场景,因为消息通讯的数据不需要即使立即同步回来,不算是核心数据,可以延时通过异步的消息发送,这样可以降低系统的负荷。
所以,我们在架构设计的时候,有一个原则就是:消息原则上都是异步消息发送,除非涉及到交易的情况才考虑数据即使同步,否则能异步的都采用异步消息设计。
再比如:流量削锋的典型场景就有阿里的双11秒杀、团购抢购活动等。
应用场景:秒杀活动,一般会因为流量过大,导致流量暴增,应用挂掉。为解决这个问题,一般需要在应用前端加入消息队列。
-
a、可以控制活动的人数
-
b、可以缓解短时间内高流量压垮应用
用户的请求,服务器接收后,首先写入消息队列。假如消息队列长度超过最大数量,则直接抛弃用户请求或跳转到错误页面。
秒杀业务根据消息队列中的请求信息,再做后续处理。
总结:
1.消息中间件的四个典型场景:典型的异步处理、应用解耦、流量削锋、消息通讯四个场景。
2.能异步就不要同步:能异步的消息原则都尽量采用异步的方式。
3.如果消息性能要求高,用rocketMQ与kafka可以更优,rocketMQ与kafka 比较就看技术选型了,各有利弊,看业务需要。
4.实现语言来看,RabbitMQ(阿里官方指定消息中间件)最高,原因是它的实现语言是天生具备高并发高可用的erlang语言。综合来看,RabbitMQ是首选。
5.典型的秒杀活动、抢购、消息通讯、邮件发送、电话短信等都是典型的采用消息中间件的业务场景。
共同学习,写下你的评论
评论加载中...
作者其他优质文章