1.Redis自带的PUB/SUB机制，即发布-订阅模式（推模型）。这种模式生产者(producer)和消费者(consumer)是1-M的关系，即一条消息会被多个消费者消费，当只有一个消费者时即可以看做一个1-1的消息队列，但这种方式并不适合题主的场景。首先，数据可靠性无法保障，题主的数据最终需要落库，如果消息丢失、Redis宕机部分数据没有持久化甚至突然的网络抖动都可能带来数据的丢失，应该是无法容忍的。这种方案适合对于数据可靠性要求不高，比如一些统计日志大点。
2.Redis的push/pop机制，利用redis的列表数据结构。比较号的使用模式是，生产者lpush消息，消费者brpop消息，并设定超时时间，可以减少redis的压力。这种方案相对于第一种方案数据可靠性是提高了，只有在redis宕机且数据没有持久化的情况下丢失数据，可以根据业务通过AOF和缩短持久化时间间隔来保证很高的可靠性，而且也可以通过多个client来提高消费速度。但相对于专业的消息队列来说，这种方案消息的状态过于简单，没有ack机制，消息取出后消费失败依赖于client记录日志或者重新push到队列里面。
3.最好还是用现有的比较流行的rabbitmq，更加符合现有的项目需求
Quoted by https://www.zhihu.com/question/20795043
http://mp.weixin.qq.com/s?__biz=MzAxMjgyMTY1NA==&mid=401601934&idx=1&sn=f87768708cdfe54fb6c302f203f3af44#rd