Redis是时下比较火的内存数据库，以简单高效著称，常用于缓存数据。它支持以string, hash, list, set等数据结构存储数据，并供提了丰富的API以操作这些数据结构。
有趣的是，利用这些数据结构，我们可以将Redis作为message broker，而不仅仅是key-value store。这也正是Redis的目标之一，如其官网所言：
Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker.
— redis.io
说起message broker，大家可能更容易想到Kafka、ActiveMQ或RabbitMQ等功能全面的应用。相比于它们，Redis目前只能实现简单的消息队列功能。那为什么我们还会想用Redis呢？在我看来，它有如下几个优点：
- 极低延迟：得益于Redis本身的高效，消息可以极低延迟传递
- 上手容易：只需组合使用两三个命令，即可完成消息传递
- 查看便利：可以便利地查看队列内容；利用
MONITOR命令甚至可以实时监控消息入队和出队
如果应用场景只需要简单的消息传递，不妨尝试使用Redis。
通过组合不同的数据结构和命令，我们可以用Redis实现多种消息队列：
- FIFO队列
- 可靠队列
- 延迟队列
下文将介绍其中最简单的FIFO队列的实现和使用，其余消息队列会在以后的文章中一一记述。
FIFO（先进先出）队列是队列的基本形式，也是最简单的消息队列。使用一个列表和LPUSH、RPOP两个命令即可实现一条FIFO队列。
生产者通过LPUSH将消息发送到Redis：
127.0.0.1:6379> LPUSH queue "message-1"
127.0.0.1:6379> LPUSH queue "message-2"消费者使用RPOP从队列中依次获取消息：
127.0.0.1:6379> RPOP queue
"message-1"
127.0.0.1:6379> RPOP queue
"message-2"当队列为空时，RPOP会直接返回空。如果希望在队列为空时能够阻塞连接等待消息，直到队列接收到新的消息或超时，可以使用BRPOP。
RPOP或BRPOP之后，消息就会从队列中删除。因此，当有多个消费者时，一条消息只能传递给其中一个消费者。我们不用担心在并发下同一条消息会传递给多个消费者，因为Redis本身是一个单线程的程序，相当于所有操作都有一把天然的排他锁。
