消息队列

互联网架构实践心得:屡试不爽的架构三马车

这里所说的三架马车是指微服务消息队列定时任务。如下图所示,这里是一个三驾马车共同驱动的一个立体的互联网项目的架构。不管项目是大是小,这个架构模板的形态一旦定型了之后就不太会变,区别只是我们有更多的服务有更复杂的调用,更复杂的消息流转,更多的Job,整个架构整体是可扩展的,而且不会变形,这个架构可以在很长的一段时间内无需有大的调整。…

消息总线真的能保证幂等?

一、缘起

如《消息总线消息必达》所述,MQ消息必达,架构上有两个核心设计点:

(1)消息落地

(2)消息超时、重传、确认

再次回顾消息总线核心架构,它由发送端、服务端、固化存储、接收端四大部分组成。

为保证消息的可达性,超时、重传、确认机制可能导致消息总线、或者业务方收到重复的消息,从而对业务产生影响。

举个栗子:

购买会员卡,上游支付系统负责给用户扣款,下游系统负责给用户发卡,通过MQ异步通知。不管是上半场的ACK丢失,导致MQ收到重复的消息,还是下半场ACK丢失,导致购卡系统收到重复的购卡通知,都可能出现,上游扣了一次钱,下游发了多张卡。

消息总线的幂等性设计至关重要,是本文将要讨论的重点。

二、上半场的幂等性设计

MQ消息发送上半场,即上图中的1-3

1,发送端MQ-client将消息发给服务端MQ-server

2,服务端MQ-server将消息落地

3,服务端MQ-server回ACK给发送端MQ-client

如果3丢失,发送端MQ-client超时后会重发消息,可能导致服务端MQ-server收到重复消息。

此时重发是MQ-client发起的,消息的处理是MQ-server,为了避免步骤2落地重复的消息,对每条消息,MQ系统内部必须生成一个inner-msg-id,作为去重和幂等的依据,这个内部消息ID的特性是:

(1)全局唯一

(2)MQ生成,具备业务无关性,对消息发送方和消息接收方屏蔽

有了这个inner-msg-id,就能保证上半场重发,也只有1条消息落到MQ-server的DB中,实现上半场幂等。

三、下半场的幂等性设计

MQ消息发送下半场,即上图中的4-6

4,服务端MQ-server将消息发给接收端MQ-client

5,接收端MQ-client回ACK给服务端

6,服务端MQ-server将落地消息删除

需要强调的是,接收端MQ-client回ACK给服务端MQ-server,是消息消费业务方的主动调用行为,不能由MQ-client自动发起,因为MQ系统不知道消费方什么时候真正消费成功。

如果5丢失,服务端MQ-server超时后会重发消息,可能导致MQ-client收到重复的消息。

此时重发是MQ-server发起的,消息的处理是消息消费业务方,消息重发势必导致业务方重复消费(上例中的一次付款,重复发卡),为了保证业务幂等性,业务消息体中,必须有一个biz-id,作为去重和幂等的依据,这个业务ID的特性是:

(1)对于同一个业务场景,全局唯一

(2)由业务消息发送方生成,业务相关,对MQ透明

PHP高级编程之消息队列

PHP高级编程之消息队列

 

摘要

2015-10-19 第一版

2016-11-31 第二版

目录

1. 什么是消息队列

消息队列(英语:Message queue)是一种进程间通信或同一进程的不同线程间的通信方式

大型网站架构系列:分布式消息队列

以下是消息队列以下的大纲,本文主要介绍消息队列概述,消息队列应用场景和消息中间件示例(电商,日志系统)。

本次分享大纲

  1. 消息队列概述
  2. 消息队列应用场景
  3. 消息中间件示例
  4. JMS消息服务(见第二篇:大型网站架构系列:分布式消息队列(二)
  5. 常用消息队列(见第二篇:大型网站架构系列:分布式消息队列(二)
  6. 参考(推荐)资料(见第二篇:大型网站架构系列:分布式消息队列(二)
  7. 本次分享总结(见第二篇:大型网站架构系列:分布式消息队列(二)

一、消息队列概述

消息队列中间件是分布式系统中重要的组件,主要解决应用耦合,异步消息,流量削锋等问题。实现高性能,高可用,可伸缩和最终一致性架构。是大型分布式系统不可缺少的中间件。

目前在生产环境,使用较多的消息队列有ActiveMQ,RabbitMQ,ZeroMQ,Kafka,MetaMQ,RocketMQ等。

二、消息队列应用场景

以下介绍消息队列在实际应用中常用的使用场景。异步处理,应用解耦,流量削锋和消息通讯四个场景。

2.1异步处理

场景说明:用户注册后,需要发注册邮件和注册短信。传统的做法有两种1.串行的方式;2.并行方式。

(1)串行方式:将注册信息写入数据库成功后,发送注册邮件,再发送注册短信。以上三个任务全部完成后,返回给客户端。(架构KKQ:466097527,欢迎加入)

(2)并行方式:将注册信息写入数据库成功后,发送注册邮件的同时,发送注册短信。以上三个任务完成后,返回给客户端。与串行的差别是,并行的方式可以提高处理的时间。

假设三个业务节点每个使用50毫秒钟,不考虑网络等其他开销,则串行方式的时间是150毫秒,并行的时间可能是100毫秒。

因为CPU在单位时间内处理的请求数是一定的,假设CPU1秒内吞吐量是100次。则串行方式1秒内CPU可处理的请求量是7次(1000/150)。并行方式处理的请求量是10次(1000/100)。

 

小结:如以上案例描述,传统的方式系统的性能(并发量,吞吐量,响应时间)会有瓶颈。如何解决这个问题呢?

引入消息队列,将不是必须的业务逻辑,异步处理。改造后的架构如下:

按照以上约定,用户的响应时间相当于是注册信息写入数据库的时间,也就是50毫秒。注册邮件,发送短信写入消息队列后,直接返回,因此写入消息队列的速度很快,基本可以忽略,因此用户的响应时间可能是50毫秒。因此架构改变后,系统的吞吐量提高到每秒20 QPS。比串行提高了3倍,比并行提高了两倍。

2.2应用解耦

场景说明:用户下单后,订单系统需要通知库存系统。传统的做法是,订单系统调用库存系统的接口。如下图:(架构KKQ:466097527,欢迎加入)

传统模式的缺点:

大型网站架构系列:消息队列

一、消息队列概述

消息队列中间件是分布式系统中重要的组件,主要解决应用耦合,异步消息,流量削锋等问题。实现高性能,高可用,可伸缩和最终一致性架构。是大型分布式系统不可缺少的中间件。

目前在生产环境,使用较多的消息队列有ActiveMQ,RabbitMQ,ZeroMQ,Kafka,MetaMQ,RocketMQ等。

二、消息队列应用场景

以下介绍消息队列在实际应用中常用的使用场景。异步处理,应用解耦,流量削锋和消息通讯四个场景。…