云消息队列
涵盖 RocketMQ、Kafka、RabbitMQ、MQTT、轻量消息队列(原MNS) 的消息队列产品体系，全系列产品 Serverless 化。RocketMQ 中文社区：https://rocketmq-learning.com/
基于 EventBridge 构建 SaaS 应用集成方案
事件源是事件驱动的基石，如何获取更多事件源也是 EventBridge 一直在探索和尝试的方向。针对市场上其他云厂商和垂直领域的 Saas 服务，EventBridge 发布了 HTTP Source 能力，提供简单且易于集成的三方事件推送 ，帮助客户更加高效、便捷地实现业务上云。
消息队列 RocketMQ 遇上可观测：业务核心链路可视化
本篇文章主要介绍 RocketMQ 的可观测性工具在线上生产环境的最佳实践。RocketMQ的可观测性能力领先业界同类产品，RocketMQ 的 Dashboard 和消息轨迹等功能为业务核心链路保驾护航，有效应对线上大规模生产使用过程中遇到的容量规划、消息收发问题排查以及自定义监控等场景。
重新定义分析 - EventBridge实时事件分析平台发布
为了解决事件领域中针对流式事件做分析的难题，EventBridge 近日发布了针对事件/消息领域的全新分析工具--EventBridge 实时事件分析平台。下面简要对 EventBridge 实时事件分析平台的内容进行介绍。
十五、.net core（.NET 6）搭建RabbitMQ消息队列生产者和消费者的简单方法
搭建RabbitMQ简单通用的直连方法 如果还没有MQ环境，可以参考上一篇的博客： https://www.cnblogs.com/weskynet/p/14877932.html
全面升级 —— Apache RocketMQ 5.0 SDK 的新面貌
长久以来，RocketMQ 易于部署、高性能、高可用的架构，支撑了数十年来集团内外海量的业务场景。时至今日，为了迎接如今云原生时代的新挑战，我们重磅推出了 RocketMQ 5.0 新架构。
如何在 Spring 生态中玩转 RocketMQ？
RocketMQ 作为业务消息的首选，在消息和流处理领域被广泛应用。而微服务生态 Spring 框架也是业务开发中最受欢迎的框架，两者的完美契合使得 RocketMQ 成为 Spring Messaging 实现中最受欢迎的消息实现。本文展示了 5 种在 Spring 生态中文玩转 RocketMQ 的方式，并描述了每个项目的特点和使用场景。
ThinkPHP5-消息队列
在这个例子当中，我们是手动指定的 $jobHandlerClassName ，更合理的做法是先定义好消息名称与消费者类名的映射关系，然后由某个可以获取该映射关系的类来推送这个消息。这样，生产者只需要知道消息的名称，而无需指定哪个消费者类来处理。
2021-Java后端工程师面试指南-(消息队列）（上）
前言 文本已收录至我的GitHub仓库，欢迎Star：github.com/bin39232820… 种一棵树最好的时间是十年前，其次是现在
PHP+Laravel+RabbitMQ实现异步延迟消息队列(库存归还)
一、前言 需求：电商秒杀场景中，如果用户下单10分钟未支付，需要进行库存归还 本篇是用PHP+Laravel+RabbitMQ来实现异步延迟消息队列
大数据场景下的消息队列：Kafka3.0快速入门
Kafka是一个分布式的基于发布/订阅模式的消息队列，同时它又是一个分布式的事件流平台。既可作为消息队列，又可作为数据管道、流分析的应用。目前Kafka的最大应用还是消息队列。 市面上主流的消息队列有RabbitMQ，ActiveMQ、Kafka等等，其中RabbitMQ，ActiveMQ这些主要是Java应用中的队列，而Kafka主要在大数据场景下使用。 消息队列主要应用场景有如下几种：削峰、限流、解耦、异步通信等。
Redis消息队列发展历程
Redis消息队列功能一直在发展和完善，从list、pubsub、stream到Tair持久内存版stream，这篇文章盘点Redis消息队列不同实现的优缺点以及Tair持久内存版对消息队列功能的改进和未来发展方向。
【Android 异步操作】手写 Handler ( 消息队列 MessageQueue | 消息保存到链表 | 从链表中获取消息 )
【Android 异步操作】手写 Handler ( 消息队列 MessageQueue | 消息保存到链表 | 从链表中获取消息 )
分布式消息队列RocketMQ
说到分布式事务，就会谈到那个经典的”账号转账”问题：2个账号，分布处于2个不同的DB，或者说2个不同的子系统里面，A要扣钱，B要加钱，如何保证原子性？ 一般的思路都是通过消息中间件来实现“最终一致性”：A系统扣钱，然后发条消息给中间件，B系统接收此消息，进行加钱。 但这里面有个问题：A是先update DB，后发送消息呢？ 还是先发送消息，后update DB？ 假设先update DB成功，发送消息网络失败，重发又失败，怎么办？ 假设先发送消息成功，update DB失败。消息已经发出去了，又不能撤回，怎么办？ 所以，这里下个结论： 只要发送消息和update DB这2个操作不是原子
