一、前言
消息队列（Message Queue）是分布式系统必不可少的中间件，大部分消息队列产品（如RocketMQ/RabbitMQ/Kafka等）要求团队有比较强的技术实力，不适用于中小团队，并且对.NET技术的支持力度不够。而Redis实现的轻量级消息队列很简单，仅有Redis常规操作，几乎不需要开发团队掌握额外的知识！
说到Redis不得不推荐我基于新生命研发的高性能Redis组件 NewLife.Redis 二次封装的组件库Shiny.Redis,支持.net core3,.net5,.net6。该组件在原来的基础上封装成了单例模式，只需一句话即可完成组件注册，通过构造函数直接注入就行。
写这篇文档的目的，是因为在最近开发过程中，需要用到多端订阅的功能，之前设计的时候用的是rockemq，最近又重新整理了一遍项目架构，把orm替换成了二次封装的shinysqlsugar,redis也替换成了shiny.redis，正好看到newlife.redis已经实现了多端消费的redis队列，所以试着把rockemq改成redis队列，但是在使用过程中，发现官方的文档还是比较难懂的，有些地方没写明白，还好方法又注释，连蒙带猜终于弄懂了，觉得还是有必要把这部分写成文档以供后面新人学习使用。
二、什么是消息队列
消息队列就是消息在传输过程中保存消息的容器，其核心功用是削峰和解耦！
早高峰，快递公司的货车前来各驿站卸货，多名站点工作人员使用PDA扫描到站，大量信息进入系统（1000tps），而通知快递公司的接口只有400tps的处理能力。
通过增加MQ来保存消息，让超过系统处理能力的消息滞留下来，等早高峰过后，系统即可完成处理。此为削峰！
在快递柜业务流程中，快递员投柜后需要经历扣减系统费、短信通知用户和推送通知快递公司三个业务动作。传统做法需要依次执行这些业务东西，如果其中某一步异常（例如用户手机未开机或者快递公司接口故障），将会延迟甚至中断整个投柜流程，严重影响用户体验。
如果接口层收到投柜数据后，写入消息到MQ，后续三个子系统各自消费处理，将可以完美解决该问题，并且子系统故障不影响上游系统！此为解耦！