源码分析RocketMQ ACL实现机制
有关RocketMQ ACL的使用请查看上一篇《RocketMQ ACL使用指南》，本文从源码的角度，分析一下RocketMQ ACL的实现原理。
备注：RocketMQ在4.4.0时引入了ACL机制，本文代码基于RocketMQ4.5.0版本。
阿里云MQ消息重试机制验证
1 测试概述
1.1 测试目的
阿里云mq消息逻辑消费失败之后的处理方式如官方文档https://help.aliyun.com/document_detail/43490.html
本文的目的是确认阿里公共云MQ产品的消息消费重试机制是否如文档描述。
高并发架构系列：Redis缓存和MySQL数据一致性方案详解
一、需求起因
在高并发的业务场景下，数据库大多数情况都是用户并发访问最薄弱的环节。所以，就需要使用redis做一个缓冲操作，让请求先访问到redis，而不是直接访问MySQL等数据库。
这个业务场景，主要是解决读数据从Redis缓存，一般都是按照下图的流程来进行业务操作。
RocketMQ消息轨迹-设计篇
RocketMQ 消息轨迹主要包含两篇文章：设计篇与源码分析篇，本节将详细介绍RocketMQ消息轨迹-设计相关。
RocketMQ消息轨迹，主要跟踪消息发送、消息消费的轨迹，即详细记录消息各个处理环节的日志，从设计上至少需要解决如下三个核心问题：
消费轨迹数据格式
记录消息轨迹(消息日志)
消息轨迹数据存储在哪？
1、消息轨迹数据格式
RocketMQ4.5版本消息轨迹主要记录如下信息：
traceType跟踪类型，可选值：Pub(消息发送)、SubBefore(消息拉取到客户端，执行业务定义的消费逻辑之前)、SubAfter(消费后)。
高可用服务 AHAS 在消息队列 MQ 削峰填谷场景下的应用
在消息队列中，当消费者去消费消息的时候，无论是通过 pull 的方式还是 push 的方式，都可能会出现大批量的消息突刺。如果此时要处理所有消息，很可能会导致系统负载过高，影响稳定性。但其实可能后面几秒之内都没有消息投递，若直接把多余的消息丢掉则没有充分利用系统处理消息的能力。
