消息队列系列一:消息队列应用

[TOC]

消息队列

以下内容为异步队列介绍

what

  • 消息是两个服务之间沟通的媒介
  • 消息可以有很多种,简单到字符串(如短信信息),也可以是对象
  • 队列就是两个服务之间进行沟通的消息的容器或者载体
  • 队列就是排队中的一组消息数据
  • 队列就是一组有序的消息数据
  • 队列可以是数组array,也可以是链表list,也可以是有序集合,只要该数据能承载消息并且有顺序
  • 常见的队列大部分是基于链表的list

why

  • 常用于解决并发系统中的资源一致性问题(如超卖)
  • 提升峰值的处理能力,同时保证消息的顺序性、可恢复性、必送达性

who

  • mysql
  • redis
    • 基于list的lpush+rpop实现的生产/消费模式
    • 基于pub/sub的发布/订阅模式
    • 基于SortedSet有序集合的实现
    • 基于 Stream 类型的实现
  • 专业消息中间件
    • RabbitMQ
    • Kafka

when

  • 高并发,大流量
  • 耗时特别长同时还不需要立即返回处理结果(异步处理)

where

  • 流量削峰(如秒杀)
  • 应用解耦(如订单系统和库存系统)
  • 异步通信(发送短信、邮件)
  • 顺序性(热点数据排序)

How

How feel

指标 比较
可靠性 rabbitMq > mysql > redis
性能 redis> rabbitMq > mysql
复杂度 rabbitMq > mysql > redis

因此,我们常用选型如下

  • 如果对性能要求较高或者对安全可靠性要求不高的情形下,优先考虑基于redis实现队列
  • 如果对消息的可靠性要求较高并且对性能兼顾的情况下,优先考虑专业消息中间件
  • mysql消息中间件很少用到

redis实现异步消息分析

基于list的lpush+rpop实现的生产/消费模式

优点:

  • 低延迟(消息几乎无延迟)

缺点:

  • 做消费者确认ACK麻烦,不能保证消费者消费消息后是否成功处理的问题(宕机或处理异常等),通常需要维护一个Pending列表,保证消息处理确认。
  • 不能做广播模式,如pub/sub,消息发布/订阅模型
  • 不能重复消费,一旦消费就会被删除
  • 不支持分组消费

基于pub/sub的发布/订阅模式

此模式允许生产者只生产一次消息,由中间件负责将消息复制到多个消息队列,每个消息队列由对应的消费组消费。
优点

  • 典型的广播模式,一个消息可以发布到多个消费者
  • 多信道订阅,消费者可以同时订阅多个信道,从而接收多类消息
  • 消息即时发送,消息不用等待消费者读取,消费者会自动接收到信道发布的消息

缺点

  • 消息一旦发布,不能接收。换句话就是发布时若客户端不在线,则消息丢失,不能寻回
  • 不能保证每个消费者接收的时间是一致的
  • 若消费者客户端出现消息积压,到一定程度,会被强制断开,导致消息意外丢失。通常发生在消息的生产远大于消费速度时

可见,Pub/Sub 模式不适合做消息存储,消息积压类的业务,而是擅长处理广播,即时通讯,即时反馈的业务。

基于SortedSet有序集合的实现

优点

  • 可以自定义消息ID,在消息ID有意义时,比较重要。

缺点

  • 不允许重复消息(因为是集合),同时消息ID确定有错误会导致消息的顺序出错。

基于 Stream 类型的实现

TODO

本作品采用《CC 协议》,转载必须注明作者和本文链接
《L05 电商实战》
从零开发一个电商项目,功能包括电商后台、商品 & SKU 管理、购物车、订单管理、支付宝支付、微信支付、订单退款流程、优惠券等
《G01 Go 实战入门》
从零开始带你一步步开发一个 Go 博客项目,让你在最短的时间内学会使用 Go 进行编码。项目结构很大程度上参考了 Laravel。
讨论数量: 1

可以可以,总结的还不错。

2年前 评论

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!