在Redis @list组中有几个b开头的命令，利用这些命令可以用来实现阻塞式单播队列：一个list可以由10个客户端去阻塞着，此时当这个list中出现了元素之后，第1个阻塞的客户端拿到元素之后，剩余的客户端还在阻塞着，这叫阻塞式单播队列。
?但是很多时候，我们要保证客户端所接收到的消息是一样，比如当你在看小姐姐直播的时候，别的用户不可能一直阻塞着等你看完了再看，你在看小姐姐，别人也想看小姐姐，这时候就该Redis中的pubsub（消息订阅）大显身手的时候了。
老规矩，先用help @pubsub查看消息订阅组相关命令介绍。
?具体来看例子，我先往live1这个频道中发布一则消息hello
再用另一个客户端连上这个Redis，去订阅刚刚发布的这则消息
结果压根就没订阅到刚刚发布的hello，因为hello先发布，后订阅，那么订阅之前发布的消息就不会看到。
那么当我订阅以后，此时再发布消息
订阅者就可以看到发布的消息了
?那么，当我们使用QQ的时候，当进入一个聊天室之后，不仅能看到当前的消息，网上滑动的时候还可以看到历史消息记录，作为一个系统架构在驾驭整个项目的时候，一个聊天室中的所有消息，是存放在关系型数据库还是Redis中呢？如果全放在数据库，数据库全量可以保证，但是查询的时候成本就很高。
其实作为客户端来讲，数据的读取大致分为3类：
①需要实时地接受数据；
②查询近期的历史数据；
③查询更老的历史数据。
全量的数据肯定在数据库中，但直接查数据库中的数据，效率是个问题，所以我们可以使用Redis作为缓存来解决数据的读请求。那Redis要怎么来设计？
①需要实时地接受数据 -> 发布订阅解决
②查询近期的历史数据 -> 考虑到历史数据必须要按照时间顺序排序，Sorted Set解决
③直接查数据库，毕竟对于更老的历史数据查询不太会存在高并发的情况。
?