redis数据库 发布订阅的疑问

@yakczh 哈哈，经验就是老司机啊

@haozxuan 请留下qq,或者支付宝或者加我q，1711126123。感谢您用心的解答。

知识就是金钱 到今天才明白这个道理

@fangker 这个你大可不必担心，之前曾经说到redis是内存级别操作，如果你认为redis中的数据实时更新要求很高的话，就要考虑缓存的刷新频率问题，可以在用户触发更新信息时发送两条请求同时到mysql和redis，只要mysql更新完毕，redis肯定更新完成；这样就能保证redis中数据实时性；而且从你的考虑角度出发，其实你是把redis当成了存储，只是不承认他是一个数据库，如果作为一个demo或学习项目来讲，你并不需要mysql，只需要对redis做持久化处理就能实现redis既当存储，又当快速缓存的作用；

123

我并不这样认为，因为http客户端可能在被更改的同时，redis并没有更改，这时候正好赶上get岂不是把之前的数据给弄上去了？毕竟默认先请求数据库中的数据。

@fangker 对于问题1，离线状态的确可以接收到数据，但是肯定个pub/sub机制无关，因为该机制是无状态的，即pub方不需要知道有谁或哪些sub方，所以如果要缓存离线数据，肯定是在此之前有依据来判定，进而存储下来。 对于问题3，其实是逻辑性误区。正常情况下，我们会将用户信息等数据存在数据库mysql中，而他的更新顺序理论上是更新mysql，然后同步到redis中，因为即使redis有持久化，他也仅仅是一份缓存，我们要保证数据库中用户真实信息被更新，所以优先级是mysql > redis。而且，同步过程可以做成异步，用户等待时间也仅仅更新mysql的时间，不会很长。至于订阅key值进行通知事件，不太合适在这里使用。如果很喜欢这个模式的话，想尝鲜的话，举个栗子：mysql存储用户信息及好友信息，redis中缓存一份好友信息，可以对redis中的用户ID做事件监听，如果有mysql到redis的同步事件发生，可以根据这个事件来做一些通知、同步客户端本地数据等操作，当然可能这个栗子不太恰当；实际应用中还是有很多类似的需求；

@haozxuan 谢谢您的解答 问题1离线后是无法接收到消息的是么，我试了试是这样，但在别的地方看到，貌似离线也可以。问题3，这种应用场景会貌似都有设定临时订单表，我仍然需要往数据库中写入，只能优化读取，而这时从数据库中读取到redis然后订单上跟用户有关联，这种情况最好把大部分表作为缓存，否则可能出现过度设计。另外比如用户信息api 用户可能被更改，这时候的处理方法是更新redis后更新mysql。我看了订阅和发布后突然异想天开，我可以用订阅加一个事件来更新对应的mysql值 然后封装方法。这属不属于脑残，或者过度设计。另外留下q,thanks

针对于问题： 1、redis的pub/sub机制的确可以发布信息，但是对于你的具体场景，客户离线操作其实是一个unsub状态，消息发送方还是会继续向channel中pub消息，理论上不会监听sub端状态，所以你就不知道离线时间节点； 2、不知道你要表达什么； 3、临时订单属于缓存类，只需要存储在redis中，等到变成正式订单后再写入mongodb等数据库中即可，而另一个问题对API的提升，我只能说数据库数据是读磁盘，redis是读内存，哪个效率高不言而喻； 4、首先redis队列可以做任务队列、FIFO堆栈等等，共享数据、进程间通信只是一个很小的功能，其核心价值在于他是基于内存的，其高效的IO性能是选用他的最大目的；