发布与订阅模式命令
psubscribe 订阅一个或者多个channel，使用正则方式匹配多个
publish 发布消息到指定channel
pubsub 查看订阅与发布系统状态
pubsub channels pattern 列出当前活跃的channel
pubsub numsub channel-1 channel-n 获取指定频道的订阅者数量
pubsub numpat 获取订阅模式的数量
subscribe 订阅一个或者多个channel消息，使用一个或者多个准确的channel名实现订阅
unsubscribe 客户端退订channel
订阅和发布的使用限制：
终端模拟分析
在终端模拟发布与订阅时，由一个客户端A模拟发布消息，另一个客户端B模拟接收消息。假如接收消息客户端B后启动，而消息先发布，则接收端B无法获取B启动之前，A发布的的消息
代码实现分析
一般获取消息的客户端（订阅者）会通过while循环不断的向redis服务器请求发布者获取消息，假如发布者在订阅者退出订阅状态时发布了消息，则该消息会丢失。
关于这个订阅者退出状态，值得探讨，这里做一个分析。使用终端模拟时，假如订阅者断开连接后，又重新连接，在这个断开的时间段内，如果存在数据发布，则重新连接的客户端是无法获取到消息的，因为redis服务器认为它是一个纯新的客户端。因此在程序里，必须小心使用redis的订阅连接，当订阅的连接没有主动释放时，也没有执行退出订阅时，数据会源源不断的写入内存，直到所有订阅者取走消息。
订阅和发布的缺点：
redis客户端在订阅消息时，要求订阅在发布之前，否则无法订阅到客户端订阅前，已经发布的消息。
redis的消息发布与订阅，无法实现高并发和大数据量。前者受限于redis本身的并发量限制和内存大小；后者是因为redis发布消息时，会先将数据推送到每个客户端的连接缓冲区，如果单个消息过大会撑爆缓冲区，导致redis错误，就算redis没有撑爆缓冲区，如果消费者（订阅方）没有及时取走消息，也会因为数据积累而撑爆内存。
示例：
假设在某个CS环境中，有1000个客户端同时发布消息，且发布较为密集，数据也比较达。
存在一个server开启了一个线程，或者进程专门负责消息订阅。此时server在连接redis服务器时一次订阅会接收到大量的消息发布者发布的消息，假如出现server无法及时取走本该取走的消息，则会导致redis内存大量增长，最终redis奔溃，所有消息丢失。因此redis的消息订阅必须保证并发数目不能过高，导致内存大量增长。
使用考虑点：
1、消费者并发数
2、消费者消费的速度，以及发布者生成的数据量级
2、数据是否需要保证可靠消费
3、