redis也可以作为消息队列来使用，而且具备搭建简单，使用简易快捷的特点
适合的场景:
1.数据场景简单且单一
2.对数据的丢失是有容忍度的
3.对消费数据的正确消费是有容忍度的
目前实现redis消息队列有三种方式
List 队列
如果你的业务需求足够简单，使用 List 这个数据类型。作为消息队列再合适不过
模式如下：
lpush/rpush(推送消息)
rpop/lpop(拉取消息 非阻塞)
brpop/blpop(拉取消息 支持阻塞)
这种模式的特点：
1.简单易用且高效
2.多个消费端可以同时分摊消费、且不受消费者宕机影响
3.消息可支持持久化，但若消费力弱，必然会导致内存消耗
pub/sub 发布/订阅
redis支持发布订阅模式，该模式只是简单的传递消息，无法支持持久化
使用方式如下
#先一个或多个消费者订阅队列（必须先订阅，且默认阻塞等待） 127.0.0.1:6379> SUBSCRIBE queue1 Reading messages... (press Ctrl-C to quit) 1) "subscribe" 2) "queue1" 3) (integer) 1
#一个或多个生产消息 publish queue1 abcd
该模式特点：
1.每个消费者可以消费一份完整的队列数据，不是分摊的
2.消费者宕机 消息会错失
3.消费不支持持久化
4.如果消费能力肉，超过每个消费者缓冲区最大空间，会被直接踢下线，且缓冲区数据清除
stream模式
支持发布订阅，且能持久化，基本具备传统mq系统的特性了，但是不推荐使用，与其用这个相对复制的stream模式的消息队列，还不如使用老字号的rabbitMQ、kafka等专业级的
综上，来个使用场景小总结
1.不希望消费者宕机丢失数据，又有足够的消费能力，同时希望一个或多个消费者分摊消费，推荐list模式
2.希望多方消费者，能完整消费一份数据（发布一条消息，多个消费者能同时拿到这条数据）适合pub/sub模式
3.其他请绕道专业的mq中间件
