Redis 发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。 Redis 客户端可以订阅任意数量的频道。
//问题： 1.redis发布订阅可以做一个类似于发布信息的东东，当客户离线，我把客户id和信息当做key-value存在redis上，上线后推送。这种思路正确么？或者有其他的方法么？ 2.redis的发布订阅模式还可以做什么事情，比如在修改键值的时候触发一个事件。在node这边可以写event订阅事件。我这个想法是不是没有意义。 3.都说结合redis可以打造高性能的api，当我对一些信息进行缓存，我请求先请求redis若不存在则访问数据库。那么问题来了，可能我数据库的数据修改了但缓存却没有改变，如果我只用缓存，每次更新操作直接更新缓存貌似又不太合适，对于临时订单这种东西。 请问：redis对api的提升具体表现在哪里。 4.node对redis队列的应用有什么呢？是不是多个node线程之间共享一个事物处理的状态，这样能提升性能？
学生狗一只，10元付费解答，本人会选择最满意的答案索要QQ，发红包。就是个心意…感谢各位大神路过解答观摩，以及鄙视…
针对于问题： 1、redis的pub/sub机制的确可以发布信息，但是对于你的具体场景，客户离线操作其实是一个unsub状态，消息发送方还是会继续向channel中pub消息，理论上不会监听sub端状态，所以你就不知道离线时间节点； 2、不知道你要表达什么； 3、临时订单属于缓存类，只需要存储在redis中，等到变成正式订单后再写入mongodb等数据库中即可，而另一个问题对API的提升，我只能说数据库数据是读磁盘，redis是读内存，哪个效率高不言而喻； 4、首先redis队列可以做任务队列、FIFO堆栈等等，共享数据、进程间通信只是一个很小的功能，其核心价值在于他是基于内存的，其高效的IO性能是选用他的最大目的；
@haozxuan 谢谢您的解答 问题1离线后是无法接收到消息的是么，我试了试是这样，但在别的地方看到，貌似离线也可以。问题3，这种应用场景会貌似都有设定临时订单表，我仍然需要往数据库中写入，只能优化读取，而这时从数据库中读取到redis然后订单上跟用户有关联，这种情况最好把大部分表作为缓存，否则可能出现过度设计。另外比如用户信息api 用户可能被更改，这时候的处理方法是更新redis后更新mysql。我看了订阅和发布后突然异想天开，我可以用订阅加一个事件来更新对应的mysql值 然后封装方法。这属不属于脑残，或者过度设计。另外留下q,thanks
@fangker 对于问题1，离线状态的确可以接收到数据，但是肯定个pub/sub机制无关，因为该机制是无状态的，即pub方不需要知道有谁或哪些sub方，所以如果要缓存离线数据，肯定是在此之前有依据来判定，进而存储下来。 对于问题3，其实是逻辑性误区。正常情况下，我们会将用户信息等数据存在数据库mysql中，而他的更新顺序理论上是更新mysql，然后同步到redis中，因为即使redis有持久化，他也仅仅是一份缓存，我们要保证数据库中用户真实信息被更新，所以优先级是mysql > redis。而且，同步过程可以做成异步，用户等待时间也仅仅更新mysql的时间，不会很长。至于订阅key值进行通知事件，不太合适在这里使用。如果很喜欢这个模式的话，想尝鲜的话，举个栗子：mysql存储用户信息及好友信息，redis中缓存一份好友信息，可以对redis中的用户ID做事件监听，如果有mysql到redis的同步事件发生，可以根据这个事件来做一些通知、同步客户端本地数据等操作，当然可能这个栗子不太恰当；实际应用中还是有很多类似的需求；
@fangker 这个你大可不必担心，之前曾经说到redis是内存级别操作，如果你认为redis中的数据实时更新要求很高的话，就要考虑缓存的刷新频率问题，可以在用户触发更新信息时发送两条请求同时到mysql和redis，只要mysql更新完毕，redis肯定更新完成；这样就能保证redis中数据实时性；而且从你的考虑角度出发，其实你是把redis当成了存储，只是不承认他是一个数据库，如果作为一个demo或学习项目来讲，你并不需要mysql，只需要对redis做持久化处理就能实现redis既当存储，又当快速缓存的作用；
