redis pub/sub 聊天

基本相关的命令：

SUBSCRIBE channel [channel ...]             订阅给定的一个或多个频道的信息。

PSUBSCRIBE pattern [pattern ...]             订阅一个或多个符合给定模式的频道。  P表示正则式。 与SUBSCRIBE相比， 就是多了个正则式功能、参数可为正则式。

UNSUBSCRIBE [channel [channel ...]]     指示客户端退订给定的频道。

PUNSUBSCRIBE [pattern [pattern ...]]     指示客户端退订所有给定模式。      P含义同上

PUBLISH channel message                       将信息 message 发送到指定的频道 channel 。 向频道发布消息

PUBSUB           统计信息， 目前支持如下3个子COMMAND

• PUBSUB CHANNELS [pattern]                                  列出活跃的channel；  其中前两个是特定的关键字， patten才是参数
  
• PUBSUB NUMSUB [channel-1 ... channel-N]         列出给定channel的订阅数
  
• PUBSUB NUMPAT                                                        所有频道的订阅总和
  

notes, channel不需要创建。 只需要订阅， 订阅后， 如果没有该频道， 会自动创建， 有就加入； 退订后，订阅数减1、到0时就"去掉"频道。

redis在subscribe/psubscribe之后， 该context就只能接受数据或者再 订阅/退订 了。不能发送其他的COMMAND，比如pubsub, publish等。

因此对于一个聊天应用的客户端而言， 需要两个context：

--------------  一个context用于subscribe sometopic， 然后不停等待接受其他人发出的消息（包括“自己”发出的）；

--------------  一个context用于publish  sometopic "words.."， 用于发出消息。

将发送和接受分开了。

游戏服务器通常有个Gate服务器负责与客户端的连接、请求/应答的转发， Gate再负责与后台的logic/match/auth等服务器通讯。因此，redis的pub/sub功能并不能直接适用于COC的聊天功能。 原因大概有：

1） COC删游戏、再下载进入， 或者退出公会再加入公会后， 能得到此前一段时间/固定条数的历史聊天记录。  这和pub/sub的定义冲突：pub只保证发给现在已经sub上的。

2）如上的游戏后端设计，gate需要充当客户端的代理。 客户端发送文本给gate，gate作为redis-cli 与redis server通讯； 但一个gate只能充当一个客户端代理； 除非对redis-server进行改造。            或者聊天服务不通过gate。