重复消费问题：
为了解决消费端因为种种原因而造成的消息丢失问题，我们都知道根源在于因为RabbitMQ的自动ack机制，所以为了避免以上问题，我们会选中手动ack，以确保消息不会因为某些原因而丢失。
但随之而来的也有一个问题：如果忘记ack，或者又因为种种原因消费者端没能给RabbitMQ对应ack，无法确认消息已经被消费完了，那这条未被“约束”的消息也许就会被另一个消费者消费，就会造成重复消费问题
如果是进行增加，或者一些非幂等性操作，比如扣费业务，那可就完犊子了
而其中用Redis似乎是对解决重复消费问题的一个比较好的方案：
思路如下：
在消费者消费消息之前，先将消息的id放到Redis中
最明了的方式：设置id为0时为正在执行业务，id为1是为业务执行成功，消费完毕
若手动ack失败，在RabbitMQ将消息交给其他的消费者时，先执行setnx，若key已经存在，则获取他的值，如果值为0，即当前消息还没消费完，当前消费者就什么都不做，如果值为1，则直接ack操作。
当然，这也会有一种非常严重的隐患：
若第一个消费者在执行业务时，出现了死锁问题，便会无法获取key的资源
为此我们应该在将消息id放入Redis时，为它设置一个生存时间，也可以叫过期时间，避免在极端情况下的死锁问题。
