如何从业务场景看消息中间件
这篇文章主要介绍“如何从业务场景看消息中间件”,在日常操作中,相信很多人在如何从业务场景看消息中间件问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”如何从业务场景看消息中间件”的疑惑有所帮助!接下来,请跟着小编一起来学习吧!
成都创新互联坚信:善待客户,将会成为终身客户。我们能坚持多年,是因为我们一直可值得信赖。我们从不忽悠初访客户,我们用心做好本职工作,不忘初心,方得始终。十余年网站建设经验成都创新互联是成都老牌网站营销服务商,为您提供成都网站建设、网站建设、网站设计、H5建站、网站制作、成都品牌网站建设、微信小程序服务,给众多知名企业提供过好品质的建站服务。
MQ的三大作用
MQ的三大作用:业务解耦、异步调用、流量削峰。
在介绍消息中间件之前,我们先想一下,如果不用MQ,业务之间最常用的调用方式是什么?比较常见的是RPC和REST方式。两种简单的对比如下:
因为REST灵活度高、性能低;而RPC性能高而灵活度低,因此我们可以对外接口用REST,内部通讯用RPC。
内部采用RPC的架构如下所示:
如果是核心应用,上面架构没有问题。但如果业务逻辑被加入了有时效性的运营活动逻辑,频繁修改代码逻辑显然不靠谱。
借助于MQ,我们将运行活动业务逻辑单拎出来,放到MQ后面。客户端的发起的请求,都发到MQ一份,后面的业务逻辑根据自己的需求进行消费。这样,通过MQ,我们实现了业务解耦(运营活动与核心业务)
上面我们提到很多时候内部业务调用是RPC。在一些场景下,我们可以通过MQ替换RPC,实现业务异步调用。
那么,MQ能否完全替代RPC?理论上可以替代RPC。但是在这种情况下,整个系统的稳定性都靠MQ,存在一定的风险。而PRC是个独立的框架,业务节点有问题,对全局没有影响。所以不建议把RPC都换成MQ。
接下来,我们看一个具体的场景(电商场景),如何通过MQ实现业务异步调用。
在下图中,不使用MQ之前,交易服务向卖家推送服务、记录交易数据等都是通过RPC实现。实际上,这与核心业务逻辑无关。因此可以改造成第二张图的模式。
在介绍了MQ实现业务逻辑拆分和异步调用后,接下来我们查看MQ实现流量削峰的场景。
京东经常举办秒杀的活动。在秒杀开始那一刻,很多用户发起请求,访问量突增。此时为了保证业务逻辑层的平稳运行,需要在API网关和业务员逻辑之间增加一个MQ。客户端请求都被堆积在MQ,然后业务逻辑处理。此时,我们可以给用户开放一个秒杀结果的查询接口,通过RPC调用业务逻辑层。
MQ虽然能够实现流量削峰、业务解耦、异步调用,但引入MQ也有一切缺点,例如增加了故障诊断的复杂度、增加了架构的复杂度。因此MQ不能完全替代RPC,两者要结合使用。在微服务的场景中,MQ通常放在API网关和业务逻辑层之间,如上图所示。
几种MQ的对比
接下来,我们对比一下几种主流MQ的优劣势:
从上图中,我们可以看到,RocketMQ在功能上是有一定的优势的。Rocket目前是一个很受欢迎的MQ开源项目:
如果要对比Kafka和RocketMQ的应用场景,简单而言:Kafka做的不是业务的事情,它不保证业务的一致性,它是系统间的数据流通道;RocketMQ做的是业务相关的事情,它保证业务的一致性,它实现高性能可靠信息传输。
正常的消息会负载均衡发送。一个Topic会跨多个队列。如果想要顺序消息,就必须发到一个队列,并且只有一个线程消费消息。
RocketMQ被广泛使用的几个核心原因是:支持事务消息、支持延迟消息、支持消息重发、支持customer端tag过滤、支持消息回放。
RocketMQ的拓扑与逻辑图
RocketMQ的拓扑图如下。
RocketMQ的Name Server集群中每个节点都是相互独立的,负责MQ集群的服务注册发现。
逻辑图如下:
由于RocketMQ不能实现主从切换,因此消息生产者只连接到主上,消费者连接到主和从上。
结合RockerMQ的可靠性和可用性,我们通常的使用方式如下图所示,即多Master多Salve+异步复制。
在RockerMQ中,消息生产者在写消息是以顺序追加的方式,写在commitlog中的。commitlog是消息主体。然后dispatch线程把消息的偏移量和大小从commitlog中读出来,放到按主题、以队列的形式消费队列。也就是说,队列放的不是消息主体。而是消息的索引信息。
CommitLog以物理文件的方式存放,每台Broker上的CommitLog被本机器所有ConsumeQueue共享。为了提升消息读取的性能,RocketMQ默认会把commitlog以1G大小进行拆分。此外,对于MQ系统,尽量使用SDD或NVRAM。
RocketMQ的消息传递方式
我们知道,服务之间消息传递主要有两种模式:队列(Queue)和主题(Topic)。
Queue 模式是一种一对一的传输模式。在这种模式下,消息的生产者(Producer)将消息传递的目的地类型是 Queue。Queue 中一条消息只能传递给一个消费者(Consumer),如果没有消费者在监听队列,消息将会一直保留在队列中,直至消息消费者连接到队列为止,消费者会从队列中请求获得消息--->消费者pull方式。
Topic 模式是一种一对多的消息传输模式。在这种模式下,消息的生产者(Producer)将消息传递的目的地类型是 Topic。消息到达 Topic 后,消息服务器将消息发送至所有订阅此主题的消费者。--->push给消费者模式。
在RocketMQ中,Topic是个抽象的概念,每个Topic底层对应N个queue,而数据也真实存在queue上的。Queue是Topic在一个Broker上的分片等分为指定份数后的其中一份,是负载均衡过程中资源分配的基本单元。也就是说,一个topic跨多个queue,每个queue在一个broker上,因此topic可以跨多个broker。
实际上,push和pull方式都各优缺点。
push方式:消息实时性高,但没有考虑客户端的消费能力、即消息处理速度。
pull方式:消息实时性低,可能造大量无效请求。
为了取长补短,RocketMQ采用LongPoll方式,即长轮询方式。在这种方式下,消费者主动发送pull消息,然后broker hold住请求,直到有消息才返回。请求的超时时间是30s。当请求超时后,消费端再度发起请求。
RocketMQ的消费者消费方式
关于消费者消费消息的方式,主要有两种:
集群消费:单条消息只消费一次,各阶段均匀消费Topic的消息。
广播消费:各集群消费全量的消息,单条消息在每个集群都被消费一次。
到此,关于“如何从业务场景看消息中间件”的学习就结束了,希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习,快去试试吧!若想继续学习更多相关知识,请继续关注创新互联网站,小编会继续努力为大家带来更多实用的文章!
当前文章:如何从业务场景看消息中间件
标题来源:http://pwwzsj.com/article/jehdss.html