前言

  对于多数同学来说，可能只是用过Redis的缓存。但这只是其中小小的一部分，其他的例如非精准去重的计数，活跃量计算，延时队列等都可以用redis实现。
  假设有一个业务场景，需要用到Redis的队列，有哪些特点是需要我们关心的呢？

业务场景

问题一： 消费频率

  假设使用Redis List作为队列的实现，这时候需要使用while循环消费：
`

while(true){    
    getMessageFromList()    
    sleep(time)    
}

`
复制代码  如果 time变量时间设置过小，当list中无数据时，会导致Redis qps过高。而时间设置太长，消息的延迟性就会很长。所以我们需要设置一个合适的时间。
  上述的方法看似解决了问题，但是不够灵活。有没有什么更好的办法，能够在消息进入队列时才去消费呢？有想到吗？
  Redis阻塞读就是一个解决的方法。当队列中没有数据时，会一直阻塞，直到生产者发送消息到队列。但是一直阻塞，Redis服务端一般会断开连接，所以需要在客户端捕获Redis抛出的异常。

问题二：数据的正确性

  在RabbitMq中，生产者发送消息到交换机中时，Exchange会有Ack机制，通知生产者已经收到消息。在消费者消费到消息时，也有ack机制通知生产者，并且生产者还能进行重试。而使用Redis作为队列时，无法确保消息被消费者正确消费到。当你的业务能允许消息的丢失时，可以尝试着使用它。

问题三： 消费模式

  在RocketMq或者kafka中有着消费者组和消费者的概念。

一条消息可以被多个消费者消费：广播模式
一条消息只能被一个消费者消费：集群模式
而Redis的队列只有集群模式。

结尾

  其实除了上述的部分，Redis作为队列还有其他的不足之处，当然有些问题可以通过某些技巧解决，像kafka这些内部也只是队列而已，它们能解决，我们当然也能。
  当我们在使用某种技术时，要充分考虑到这些不足之处，而不是作为面试题去考虑。

作者：聆听的车辙