發布與訂閱模式命令
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、