MQ消息队列(2) 消息中间件介绍、典型使用场景、以及使用原则

大型分布式架构里一定会涉及到消息中间件,今天先谈谈消息中间件。

常用的消息队列有ActiveMQ,RabbitMQ,ZeroMQ,Kafka,MetaMQ,RocketMQ。

一、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.典型的秒杀活动、抢购、消息通讯、邮件发送、电话短信等都是典型的采用消息中间件的业务场景。

你可能感兴趣的:(消息队列,使用场景)