Redis Pipeline原来是这么用的

抛出，问题

最近项目碰到这么一个技术上的需求：

前端通过长轮询的机制（http long polling），获取服务端的消息数据。而服务端是需要订阅所有业务方的业务消息，再通知到给前端。

长轮询，其实简单来说，就是前端发起一个http请求，服务端把当前的请求 hang 住，直到超时或者有需要返回的内容，才return。 Apollo 配置中心就是使用这个机制实现配置的更新通知。

但有这么一种情况，假如服务端消费到消息，但此时前端与服务端的连接刚好断开了，那这个消息就没法通知到前端。

所以，我们得需要把服务端消费的消息保存下来，保证前端的每次发起长轮询的时候，都能拿到消息数据。

如果说，前端能直接订阅业务方的消息队列的话，那其实就没服务端什么关系了。当然，这是不允许的，前端不能连接咱们的消息中间件，并且业务方的消息数据也需要清洗处理后才能给到前端。

思考，方案

Apollo 的实现机制是，所有的配置都会写入数据库。每次请求过来，会去数据库获取是否有数据变更。

考虑到我们实际的业务场景，我们的业务消息其实时候时效性的，也就是说消息如果过期了，那其实也没用了。

要考虑轻量，我第一想到的就是 Redis Lists，利用其可以实现队列的特性，所以综合考虑最终采用 Redis 作为消息的存储模型。

</