redispubsub命令

Ⅰ redis jedispubsub怎麼銷毀

用一致性哈希演算法(consistent hashing)，將key和節點name同時hashing，然後進行映射匹配，採用的演算法是MURMUR_HASH。
採用一致性哈希而不是採用簡單類似哈希求模映射的主要原因是當增加或減少節點時，不會產生由於重新匹配造成的rehashing。一致性哈希隻影響相鄰節點key分配，影響量小。

Ⅱ 如何使用redis實現訂閱發布模式

從上面的官方解釋上來看，它的玩法有一點像現實生活中我們聽收音機一個道理，要想聽收音機，我們要做什麼？肯定就是調頻啦，只有在正
確的頻道上面，我們才能聽得到好聽的節目，所以說subscribe首先要訂閱一個頻道（channel），下面我舉個例子，開兩個client，分別訂閱著
msg 這個頻道，比如下面這樣：

2.publish
到現在為止，這兩個subscibe都在監視著msg這個頻道，接下來，如果msg頻道有消息傳出，必定會被subscribe接收到，先我們還是看看
redis手冊上怎麼用這個命令。
PUBLISH channel message

將信息 message 發送到指定的頻道 channel 。

看到上面命令的用法，我也就放心了。

看到么有，publish在msg這個頻道上面發送消息後，被subscribe監視到了，然後就被分別列印輸出了，好了，到現在為止，最基本的發布
訂閱模式就是這樣，是不是很簡單哈。。。其實呢？？？ 也就是這么簡單吶，但是呢，有時候我們還有這樣一個需求，就是我能不能模糊匹
配key呢？？？舉了例子，就是要求訂閱china為前綴的所有頻道，如果這樣也可以做到的話，那確實是很牛逼啦。。。我要是回答的話，當
然啦，強大的redis自然會做到這一點，它提供了的命令就是：Psubscribe。

3. Psubscribe
PSUBSCRIBE pattern [pattern ...]

訂閱一個或多個符合給定模式的頻道。

每個模式以 * 作為匹配符，比如 it* 匹配所有以 it 開頭的頻道( it.news 、 it.blog 、 it.tweets 等等)， news.* 匹配所有以 news. 開頭的頻道( news.it 、 news.global.today 等等)，諸如此類。

看到上面的解釋，你心裡可能就在想，這不就是正則匹配么。。。而且前綴「P」就是Pattern的意思，對吧，接下來我就訂閱一下所有china為
前綴的channel。

好了，最常用的也就是這三個命令，接下來我們簡單分析一下代碼。

二： 源碼簡單分析
其實redis的發布訂閱模式，使用RedisServer下面的 pubsub_channels字典 和 pubsub_patterns數組存放的，所有的操作代碼都
在pubsub.c文件下，如下圖：

1. pubsub_channels
可以看到，它是一個字典結構，通過注釋你應該明白，它的key為channel，value為list。

2. pubsub_patterns
同樣從注釋中，你可以看到，其實它就是存放模式匹配的subscribe的clients列表，對吧，用一個list數組實現。

3. subcribeCommand
通過下面的代碼，你是不是在腦子裡面很有輪廓了？？？其實這個pubsub_channels果然就是key=channel，value=list的存放模式，
這個list就是所謂的clients列表，這樣的話，你就知道了哪些key掛了哪些clients，對吧，如果再publish的話，只需要遍歷一下這個list就知
道結果了。

4. publishCommand
先前也說了，publish的原理很簡單，就是找到字典中的channel這個key，獲取到clients之後，遍歷client的來發送信息。

同樣的道理，pubsub_patterns也是差不多的實現，只要大家簡單看一下pubsub.c這個源代碼文件，差不多都會懂得，沒啥好說的，
希望這篇對你有用~

Ⅲ 如何查看redis中消息

redis-cli連接伺服器後，使用info命令查看Redis信息和狀態：

redis>INFO
#Server
redis_version:2.9.11
redis_git_sha1:937384d0
redis_git_dirty:0
redis_build_id:8e9509442863f22
redis_mode:standalone
os:Linux3.13.0-35-genericx86_64
arch_bits:64
multiplexing_api:epoll
gcc_version:4.8.2
process_id:4716
run_id:
tcp_port:6379
uptime_in_seconds:362
uptime_in_days:0
hz:10
lru_clock:1725349
config_file:

#Clients
connected_clients:1
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0

#Memory
used_memory:508536
used_memory_human:496.62K
used_memory_rss:7974912
used_memory_peak:508536
used_memory_peak_human:496.62K
used_memory_lua:33792
mem_fragmentation_ratio:15.68
mem_allocator:jemalloc-3.2.0

#Persistence
loading:0
rdb_changes_since_last_save:6
rdb_bgsave_in_progress:0
rdb_last_save_time:1411011131
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:-1
rdb_current_bgsave_time_sec:-1
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok

#Stats
total_connections_received:2
total_commands_processed:4
instantaneous_ops_per_sec:0
rejected_connections:0
sync_full:0
sync_partial_ok:0
sync_partial_err:0
expired_keys:0
evicted_keys:0
keyspace_hits:0
keyspace_misses:0
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:0
migrate_cached_sockets:0

#Replication
role:master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

#CPU
used_cpu_sys:0.21
used_cpu_user:0.17
used_cpu_sys_children:0.00
used_cpu_user_children:0.00

#Cluster
cluster_enabled:0

#Keyspace
db0:keys=2,expires=0,avg_ttl=0

Ⅳ redis常用命令是什麼

1、連接操作相關命令：

type(key)：返值類型。

使用的注意事項

1、 Redis和Memcache都是將數據存放在內存中，都是內存資料庫。不過memcache還可用於緩存其他東西，例如圖片、視頻等等。

2、Redis不僅僅支持簡單的k/v類型的數據，同時還提供list，set，hash等數據結構的存儲。

3、虛擬內存–Redis當物理內存用完時，可以將一些很久沒用到的value 交換到磁碟 。

4、過期策略–memcache在set時就指定，例如set key1 0 0 8,即永不過期。Redis可以通過例如expire 設定，例如expire name 10 。

Ⅳ redis 集群支持pubsub嗎

Redis本質上也是一種鍵值資料庫的，但它在保持鍵值資料庫簡單快捷特點的同時，又吸收了部分關系資料庫的優點。從而使它的位置處於關系資料庫和鍵值數 據庫之間。Redis不僅能保存Strings類型的數據，還能保存Lists類型（有序）和Sets類型（無序）的數據，而且還能完成排序（SORT） 等高級功能，在實現INCR，SETNX等功能的時候，保證了其操作的原子性，除此以外，還支持主從復制等功能。

Redis支持 publish/subscribe, 通知, key 過期等等特性。

Ⅵ Redis和Memcached的區別

Redis的作者Salvatore Sanfilippo曾經對這兩種基於內存的數據存儲系統進行過比較：

1、Redis支持伺服器端的數據操作：Redis相比Memcached來說，擁有更多的數據結構和並支持更豐富的數據操作，通常在Memcached里，你需要將數據拿到客戶端來進行類似的修改再set回去。這大大增加了網路IO的次數和數據體積。在Redis中，這些復雜的操作通常和一般的GET/SET一樣高效。所以，如果需要緩存能夠支持更復雜的結構和操作，那麼Redis會是不錯的選擇。

2、內存使用效率對比：使用簡單的key-value存儲的話，Memcached的內存利用率更高，而如果Redis採用hash結構來做key-value存儲，由於其組合式的壓縮，其內存利用率會高於Memcached。

3、性能對比：由於Redis只使用單核，而Memcached可以使用多核，所以平均每一個核上Redis在存儲小數據時比Memcached性能更高。而在100k以上的數據中，Memcached性能要高於Redis，雖然Redis最近也在存儲大數據的性能上進行優化，但是比起Memcached，還是稍有遜色。

具體為什麼會出現上面的結論，以下為收集到的資料：

1、數據類型支持不同

與Memcached僅支持簡單的key-value結構的數據記錄不同，Redis支持的數據類型要豐富得多。最為常用的數據類型主要由五種：String、Hash、List、Set和Sorted Set。Redis內部使用一個redisObject對象來表示所有的key和value。redisObject最主要的信息如圖所示：

type代表一個value對象具體是何種數據類型，encoding是不同數據類型在redis內部的存儲方式，比如：type=string代表value存儲的是一個普通字元串，那麼對應的encoding可以是raw或者是int，如果是int則代表實際redis內部是按數值型類存儲和表示這個字元串的，當然前提是這個字元串本身可以用數值表示，比如:」123″ 「456」這樣的字元串。只有打開了Redis的虛擬內存功能，vm欄位欄位才會真正的分配內存，該功能默認是關閉狀態的。

1）String

• 常用命令：set/get/decr/incr/mget等；

• 應用場景：String是最常用的一種數據類型，普通的key/value存儲都可以歸為此類；

• 實現方式：String在redis內部存儲默認就是一個字元串，被redisObject所引用，當遇到incr、decr等操作時會轉成數值型進行計算，此時redisObject的encoding欄位為int。

2）Hash

• 常用命令：hget/hset/hgetall等

• 應用場景：我們要存儲一個用戶信息對象數據，其中包括用戶ID、用戶姓名、年齡和生日，通過用戶ID我們希望獲取該用戶的姓名或者年齡或者生日；

• 實現方式：Redis的Hash實際是內部存儲的Value為一個HashMap，並提供了直接存取這個Map成員的介面。如圖所示，Key是用戶ID, value是一個Map。這個Map的key是成員的屬性名，value是屬性值。這樣對數據的修改和存取都可以直接通過其內部Map的Key(Redis里稱內部Map的key為field), 也就是通過 key(用戶ID) + field(屬性標簽) 就可以操作對應屬性數據。當前HashMap的實現有兩種方式：當HashMap的成員比較少時Redis為了節省內存會採用類似一維數組的方式來緊湊存儲，而不會採用真正的HashMap結構，這時對應的value的redisObject的encoding為zipmap，當成員數量增大時會自動轉成真正的HashMap,此時encoding為ht。

3）List

• 常用命令：lpush/rpush/lpop/rpop/lrange等；

• 應用場景：Redis list的應用場景非常多，也是Redis最重要的數據結構之一，比如twitter的關注列表，粉絲列表等都可以用Redis的list結構來實現；

• 實現方式：Redis list的實現為一個雙向鏈表，即可以支持反向查找和遍歷，更方便操作，不過帶來了部分額外的內存開銷，Redis內部的很多實現，包括發送緩沖隊列等也都是用的這個數據結構。

4）Set

• 常用命令：sadd/spop/smembers/sunion等；

• 應用場景：Redis set對外提供的功能與list類似是一個列表的功能，特殊之處在於set是可以自動排重的，當你需要存儲一個列表數據，又不希望出現重復數據時，set是一個很好的選擇，並且set提供了判斷某個成員是否在一個set集合內的重要介面，這個也是list所不能提供的；

• 實現方式：set 的內部實現是一個 value永遠為null的HashMap，實際就是通過計算hash的方式來快速排重的，這也是set能提供判斷一個成員是否在集合內的原因。

5）Sorted Set

• 常用命令：zadd/zrange/zrem/zcard等；

• 應用場景：Redis sorted set的使用場景與set類似，區別是set不是自動有序的，而sorted set可以通過用戶額外提供一個優先順序(score)的參數來為成員排序，並且是插入有序的，即自動排序。當你需要一個有序的並且不重復的集合列表，那麼可以選擇sorted set數據結構，比如twitter 的public timeline可以以發表時間作為score來存儲，這樣獲取時就是自動按時間排好序的。

• 實現方式：Redis sorted set的內部使用HashMap和跳躍表(SkipList)來保證數據的存儲和有序，HashMap里放的是成員到score的映射，而跳躍表裡存放的是所有的成員，排序依據是HashMap里存的score,使用跳躍表的結構可以獲得比較高的查找效率，並且在實現上比較簡單。

2、內存管理機制不同

在Redis中，並不是所有的數據都一直存儲在內存中的。這是和Memcached相比一個最大的區別。當物理內存用完時，Redis可以將一些很久沒用到的value交換到磁碟。Redis只會緩存所有的key的信息，如果Redis發現內存的使用量超過了某一個閥值，將觸發swap的操作，Redis根據「swappability = age*log(size_in_memory)」計算出哪些key對應的value需要swap到磁碟。然後再將這些key對應的value持久化到磁碟中，同時在內存中清除。這種特性使得Redis可以保持超過其機器本身內存大小的數據。當然，機器本身的內存必須要能夠保持所有的key，畢竟這些數據是不會進行swap操作的。同時由於Redis將內存中的數據swap到磁碟中的時候，提供服務的主線程和進行swap操作的子線程會共享這部分內存，所以如果更新需要swap的數據，Redis將阻塞這個操作，直到子線程完成swap操作後才可以進行修改。當從Redis中讀取數據的時候，如果讀取的key對應的value不在內存中，那麼Redis就需要從swap文件中載入相應數據，然後再返回給請求方。 這里就存在一個I/O線程池的問題。在默認的情況下，Redis會出現阻塞，即完成所有的swap文件載入後才會相應。這種策略在客戶端的數量較小，進行批量操作的時候比較合適。但是如果將Redis應用在一個大型的網站應用程序中，這顯然是無法滿足大並發的情況的。所以Redis運行我們設置I/O線程池的大小，對需要從swap文件中載入相應數據的讀取請求進行並發操作，減少阻塞的時間。

對於像Redis和Memcached這種基於內存的資料庫系統來說，內存管理的效率高低是影響系統性能的關鍵因素。傳統C語言中的malloc/free函數是最常用的分配和釋放內存的方法，但是這種方法存在著很大的缺陷：首先，對於開發人員來說不匹配的malloc和free容易造成內存泄露；其次頻繁調用會造成大量內存碎片無法回收重新利用，降低內存利用率；最後作為系統調用，其系統開銷遠遠大於一般函數調用。所以，為了提高內存的管理效率，高效的內存管理方案都不會直接使用malloc/free調用。Redis和Memcached均使用了自身設計的內存管理機制，但是實現方法存在很大的差異，下面將會對兩者的內存管理機制分別進行介紹。

Memcached默認使用Slab Allocation機制管理內存，其主要思想是按照預先規定的大小，將分配的內存分割成特定長度的塊以存儲相應長度的key-value數據記錄，以完全解決內存碎片問題。Slab Allocation機制只為存儲外部數據而設計，也就是說所有的key-value數據都存儲在Slab Allocation系統里，而Memcached的其它內存請求則通過普通的malloc/free來申請，因為這些請求的數量和頻率決定了它們不會對整個系統的性能造成影響Slab Allocation的原理相當簡單。 如圖所示，它首先從操作系統申請一大塊內存，並將其分割成各種尺寸的塊Chunk，並把尺寸相同的塊分成組Slab Class。其中，Chunk就是用來存儲key-value數據的最小單位。每個Slab Class的大小，可以在Memcached啟動的時候通過制定Growth Factor來控制。假定圖中Growth Factor的取值為1.25，如果第一組Chunk的大小為88個位元組，第二組Chunk的大小就為112個位元組，依此類推。





當Memcached接收到客戶端發送過來的數據時首先會根據收到數據的大小選擇一個最合適的Slab Class，然後通過查詢Memcached保存著的該Slab Class內空閑Chunk的列表就可以找到一個可用於存儲數據的Chunk。當一條資料庫過期或者丟棄時，該記錄所佔用的Chunk就可以回收，重新添加到空閑列表中。從以上過程我們可以看出Memcached的內存管理制效率高，而且不會造成內存碎片，但是它最大的缺點就是會導致空間浪費。因為每個Chunk都分配了特定長度的內存空間，所以變長數據無法充分利用這些空間。如圖 所示，將100個位元組的數據緩存到128個位元組的Chunk中，剩餘的28個位元組就浪費掉了。





Redis的內存管理主要通過源碼中zmalloc.h和zmalloc.c兩個文件來實現的。Redis為了方便內存的管理，在分配一塊內存之後，會將這塊內存的大小存入內存塊的頭部。如圖所示，real_ptr是redis調用malloc後返回的指針。redis將內存塊的大小size存入頭部，size所佔據的內存大小是已知的，為size_t類型的長度，然後返回ret_ptr。當需要釋放內存的時候，ret_ptr被傳給內存管理程序。通過ret_ptr，程序可以很容易的算出real_ptr的值，然後將real_ptr傳給free釋放內存。

Redis通過定義一個數組來記錄所有的內存分配情況，這個數組的長度為ZMALLOC_MAX_ALLOC_STAT。數組的每一個元素代表當前程序所分配的內存塊的個數，且內存塊的大小為該元素的下標。在源碼中，這個數組為zmalloc_allocations。zmalloc_allocations[16]代表已經分配的長度為16bytes的內存塊的個數。zmalloc.c中有一個靜態變數used_memory用來記錄當前分配的內存總大小。所以，總的來看，Redis採用的是包裝的mallc/free，相較於Memcached的內存管理方法來說，要簡單很多。

3、數據持久化支持

Redis雖然是基於內存的存儲系統，但是它本身是支持內存數據的持久化的，而且提供兩種主要的持久化策略：RDB快照和AOF日誌。而memcached是不支持數據持久化操作的。

1）RDB快照

Redis支持將當前數據的快照存成一個數據文件的持久化機制，即RDB快照。但是一個持續寫入的資料庫如何生成快照呢？Redis藉助了fork命令的 on write機制。在生成快照時，將當前進程fork出一個子進程，然後在子進程中循環所有的數據，將數據寫成為RDB文件。我們可以通過Redis的save指令來配置RDB快照生成的時機，比如配置10分鍾就生成快照，也可以配置有1000次寫入就生成快照，也可以多個規則一起實施。這些規則的定義就在Redis的配置文件中，你也可以通過Redis的CONFIG SET命令在Redis運行時設置規則，不需要重啟Redis。

Redis的RDB文件不會壞掉，因為其寫操作是在一個新進程中進行的，當生成一個新的RDB文件時，Redis生成的子進程會先將數據寫到一個臨時文件中，然後通過原子性rename系統調用將臨時文件重命名為RDB文件，這樣在任何時候出現故障，Redis的RDB文件都總是可用的。同時，Redis的RDB文件也是Redis主從同步內部實現中的一環。RDB有他的不足，就是一旦資料庫出現問題，那麼我們的RDB文件中保存的數據並不是全新的，從上次RDB文件生成到Redis停機這段時間的數據全部丟掉了。在某些業務下，這是可以忍受的。

2）AOF日誌

AOF日誌的全稱是append only file，它是一個追加寫入的日誌文件。與一般資料庫的binlog不同的是，AOF文件是可識別的純文本，它的內容就是一個個的Redis標准命令。只有那些會導致數據發生修改的命令才會追加到AOF文件。每一條修改數據的命令都生成一條日誌，AOF文件會越來越大，所以Redis又提供了一個功能，叫做AOF rewrite。其功能就是重新生成一份AOF文件，新的AOF文件中一條記錄的操作只會有一次，而不像一份老文件那樣，可能記錄了對同一個值的多次操作。其生成過程和RDB類似，也是fork一個進程，直接遍歷數據，寫入新的AOF臨時文件。在寫入新文件的過程中，所有的寫操作日誌還是會寫到原來老的AOF文件中，同時還會記錄在內存緩沖區中。當重完操作完成後，會將所有緩沖區中的日誌一次性寫入到臨時文件中。然後調用原子性的rename命令用新的AOF文件取代老的AOF文件。

AOF是一個寫文件操作，其目的是將操作日誌寫到磁碟上，所以它也同樣會遇到我們上面說的寫操作的流程。在Redis中對AOF調用write寫入後，通過appendfsync選項來控制調用fsync將其寫到磁碟上的時間，下面appendfsync的三個設置項，安全強度逐漸變強。

• appendfsync no 當設置appendfsync為no的時候，Redis不會主動調用fsync去將AOF日誌內容同步到磁碟，所以這一切就完全依賴於操作系統的調試了。對大多數Linux操作系統，是每30秒進行一次fsync，將緩沖區中的數據寫到磁碟上。

• appendfsync everysec 當設置appendfsync為everysec的時候，Redis會默認每隔一秒進行一次fsync調用，將緩沖區中的數據寫到磁碟。但是當這一次的fsync調用時長超過1秒時。Redis會採取延遲fsync的策略，再等一秒鍾。也就是在兩秒後再進行fsync，這一次的fsync就不管會執行多長時間都會進行。這時候由於在fsync時文件描述符會被阻塞，所以當前的寫操作就會阻塞。所以結論就是，在絕大多數情況下，Redis會每隔一秒進行一次fsync。在最壞的情況下，兩秒鍾會進行一次fsync操作。這一操作在大多數資料庫系統中被稱為group commit，就是組合多次寫操作的數據，一次性將日誌寫到磁碟。

• appednfsync always 當設置appendfsync為always時，每一次寫操作都會調用一次fsync，這時數據是最安全的，當然，由於每次都會執行fsync，所以其性能也會受到影響。

對於一般性的業務需求，建議使用RDB的方式進行持久化，原因是RDB的開銷並相比AOF日誌要低很多，對於那些無法忍數據丟失的應用，建議使用AOF日誌。

4、集群管理的不同

Memcached是全內存的數據緩沖系統，Redis雖然支持數據的持久化，但是全內存畢竟才是其高性能的本質。作為基於內存的存儲系統來說，機器物理內存的大小就是系統能夠容納的最大數據量。如果需要處理的數據量超過了單台機器的物理內存大小，就需要構建分布式集群來擴展存儲能力。

Memcached本身並不支持分布式，因此只能在客戶端通過像一致性哈希這樣的分布式演算法來實現Memcached的分布式存儲。下圖給出了Memcached的分布式存儲實現架構。當客戶端向Memcached集群發送數據之前，首先會通過內置的分布式演算法計算出該條數據的目標節點，然後數據會直接發送到該節點上存儲。但客戶端查詢數據時，同樣要計算出查詢數據所在的節點，然後直接向該節點發送查詢請求以獲取數據。





相較於Memcached只能採用客戶端實現分布式存儲，Redis更偏向於在伺服器端構建分布式存儲。最新版本的Redis已經支持了分布式存儲功能。Redis Cluster是一個實現了分布式且允許單點故障的Redis高級版本，它沒有中心節點，具有線性可伸縮的功能。下圖給出Redis Cluster的分布式存儲架構，其中節點與節點之間通過二進制協議進行通信，節點與客戶端之間通過ascii協議進行通信。在數據的放置策略上，Redis Cluster將整個key的數值域分成4096個哈希槽，每個節點上可以存儲一個或多個哈希槽，也就是說當前Redis Cluster支持的最大節點數就是4096。Redis Cluster使用的分布式演算法也很簡單：crc16( key ) % HASH_SLOTS_NUMBER。






為了保證單點故障下的數據可用性，Redis Cluster引入了Master節點和Slave節點。在Redis Cluster中，每個Master節點都會有對應的兩個用於冗餘的Slave節點。這樣在整個集群中，任意兩個節點的宕機都不會導致數據的不可用。當Master節點退出後，集群會自動選擇一個Slave節點成為新的Master節點。

Ⅶ redis的subscribe怎麼用

發布訂閱(pub/sub)是一種消息通信模式，主要的目的是解耦消息發布者和消息訂閱者之間的耦合，這點和設計模式中的觀察者模式比較相似。pub /sub不僅僅解決發布者和訂閱者直接代碼級別耦合也解決兩者在物理部署上的耦合。redis作為一個pub/sub server，在訂閱者和發布者之間起到了消息路由的功能。訂閱者可以通過subscribe和psubscribe命令向redis server訂閱自己感興趣的消息類型，redis將消息類型稱為通道(channel)。當發布者通過publish命令向redis server發送特定類型的消息時。訂閱該消息類型的全部client都會收到此消息。這里消息的傳遞是多對多的。一個client可以訂閱多個 channel,也可以向多個channel發送消息。
參考下這個吧：http://www.oschina.net/question/123890_56301

Ⅷ 如何高效深入的閱讀Redis的源碼

在這篇文章中， 我將向大家介紹一種我認為比較合理的 Redis 源碼閱讀順序， 希望可以給對 Redis 有興趣並打算閱讀 Redis 源碼的朋友帶來一點幫助。
第 1 步：閱讀數據結構實現
剛開始閱讀 Redis 源碼的時候， 最好從數據結構的相關文件開始讀起， 因為這些文件和 Redis 中的其他部分耦合最少， 並且這些文件所實現的數據結構在大部分演算法書上都可以了解到， 所以從這些文件開始讀是最輕松的、難度也是最低的。
下表列出了 Redis 源碼中， 各個數據結構的實現文件：
文件 內容
sds.h 和 sds.c Redis 的動態字元串實現。
adlist.h 和 adlist.c Redis 的雙端鏈表實現。
dict.h 和 dict.c Redis 的字典實現。
redis.h 中的 zskiplist 結構和 zskiplistNode 結構， 以及 t_zset.c 中所有以 zsl 開頭的函數， 比如 zslCreate 、 zslInsert 、 zslDeleteNode ，等等。 Redis 的跳躍表實現。
hyperloglog.c 中的 hllhdr 結構， 以及所有以 hll 開頭的函數。 Redis 的 HyperLogLog 實現。
第 2 步：閱讀內存編碼數據結構實現
在閱讀完和數據結構有關的文件之後， 接下來就應該閱讀內存編碼（encoding）數據結構了。
和普通的數據結構一樣， 內存編碼數據結構基本上是獨立的， 不和其他模塊耦合， 但是區別在於：
上一步要讀的數據結構， 比如雙端鏈表、字典、HyperLogLog， 在演算法書上或者相關的論文上都可以找到資料介紹。
而內存編碼數據結構卻不容易找到相關的資料， 因為這些數據結構都是 Redis 為了節約內存而專門開發出來的， 換句話說， 這些數據結構都是特製（adhoc）的， 除了 Redis 源碼中的文檔之外， 基本上找不到其他資料來了解這些特製的數據結構。
不過話又說回來， 雖然內存編碼數據結構是 Redis 特製的， 但它們基本都和內存分配、指針操作、位操作這些底層的東西有關， 讀者只要認真閱讀源碼中的文檔， 並在有需要時， 畫圖來分析這些數據結構， 那麼要完全理解這些內存編碼數據結構的運作原理並不難， 當然這需要花一些功夫。
下表展示了 Redis 源碼中， 各個內存編碼數據結構的實現文件：
文件 內容
intset.h 和 intset.c 整數集合（intset）數據結構。
ziplist.h 和 ziplist.c 壓縮列表（zip list）數據結構。
第 3 步：閱讀數據類型實現
在完成以上兩個閱讀步驟之後， 我們就讀完了 Redis 六種不同類型的鍵（字元串、散列、列表、集合、有序集合、HyperLogLog）的所有底層實現結構了。
接下來， 為了知道 Redis 是如何通過以上提到的數據結構來實現不同類型的鍵， 我們需要閱讀實現各個數據類型的文件， 以及 Redis 的對象系統文件， 這些文件包括：
文件 內容
object.c Redis 的對象（類型）系統實現。
t_string.c 字元串鍵的實現。
t_list.c 列表鍵的實現。
t_hash.c 散列鍵的實現。
t_set.c 集合鍵的實現。
t_zset.c 中除 zsl 開頭的函數之外的所有函數。 有序集合鍵的實現。
hyperloglog.c 中所有以 pf 開頭的函數。 HyperLogLog 鍵的實現。
第 4 步：閱讀資料庫實現相關代碼
在讀完了 Redis 使用所有底層數據結構， 以及 Redis 是如何使用這些數據結構來實現不同類型的鍵之後， 我們就可以開始閱讀 Redis 裡面和資料庫有關的代碼了， 它們分別是：
文件 內容
redis.h 文件中的 redisDb 結構， 以及 db.c 文件。 Redis 的資料庫實現。
notify.c Redis 的資料庫通知功能實現代碼。
rdb.h 和 rdb.c Redis 的 RDB 持久化實現代碼。
aof.c Redis 的 AOF 持久化實現代碼。
選讀
Redis 有一些獨立的功能模塊， 這些模塊可以在完成第 4 步之後閱讀， 它們包括：
文件 內容
redis.h 文件的 pubsubPattern 結構，以及 pubsub.c 文件。 發布與訂閱功能的實現。
redis.h 文件的 multiState 結構以及 multiCmd 結構， multi.c 文件。 事務功能的實現。
sort.c SORT 命令的實現。
bitops.c GETBIT 、 SETBIT 等二進制位操作命令的實現。
第 5 步：閱讀客戶端和伺服器的相關代碼
在閱讀完資料庫實現代碼， 以及 RDB 和 AOF 兩種持久化的代碼之後， 我們可以開始閱讀客戶端和 Redis 伺服器本身的實現代碼， 和這些代碼有關的文件是：
文件 內容
ae.c ，以及任意一個 ae_*.c 文件（取決於你所使用的多路復用庫）。 Redis 的事件處理器實現（基於 Reactor 模式）。
networking.c Redis 的網路連接庫，負責發送命令回復和接受命令請求， 同時也負責創建/銷毀客戶端， 以及通信協議分析等工作。
redis.h 和 redis.c 中和單機 Redis 伺服器有關的部分。 單機 Redis 伺服器的實現。
如果讀者能完成以上 5 個閱讀步驟的話， 那麼恭喜你， 你已經了解了單機的 Redis 伺服器是怎樣處理命令請求和返回命令回復， 以及是 Redis 怎樣操作資料庫的了， 這是 Redis 最重要的部分， 也是之後繼續閱讀多機功能的基礎。
選讀
Redis 有一些獨立的功能模塊， 這些模塊可以在完成第 5 步之後閱讀， 它們包括：
文件 內容
scripting.c Lua 腳本功能的實現。
slowlog.c 慢查詢功能的實現。
monitor.c 監視器功能的實現。
第 6 步：閱讀多機功能的實現
在弄懂了 Redis 的單機伺服器是怎樣運作的之後， 就可以開始閱讀 Redis 多機功能的實現代碼了， 和這些功能有關的文件為：
文件 內容
replication.c 復制功能的實現代碼。
sentinel.c Redis Sentinel 的實現代碼。
cluster.c Redis 集群的實現代碼。
注意， 因為 Redis Sentinel 用到了復制功能的代碼， 而集群又用到了復制和 Redis Sentinel 的代碼， 所以在閱讀這三個模塊的時候， 記得先閱讀復制模塊， 然後閱讀 Sentinel 模塊， 最後才閱讀集群模塊， 這樣理解起來就會更得心應手。
如果你連這三個模塊都讀完了的話， 那麼恭喜你， 你已經讀完了 Redis 單機功能和多機功能的所有代碼了！
下圖總結了本文介紹的閱讀順序：
digraph {
node [shape = plaintext]

datastruct [label = "數據結構\n（sds、adlist、dict、t_zset、hyperloglog）"]

encoding_datastruct [label = "內存編碼數據結構\n（intset、ziplist）"]

object [label = "數據類型\n（object、t_string、t_list、t_hash、t_set、t_zset、hyperloglog）"]

db [label = "資料庫相關\n（db、notify、rdb、aof）"]

client_and_server [label = "客戶端與伺服器相關\n（ae、networking、redis）"]

multi_server [label = "多機功能\n（replication、sentinel、cluster）"]

//

datastruct -> encoding_datastruct -> object -> db -> client_and_server -> multi_server

}
結語
Redis 的設計非常簡潔、優美、精巧和高效， 任何人只要願意去閱讀它的代碼的話， 應該都會有所收獲的。
希望這篇文章能夠給想要閱讀 Redis 代碼的朋友們帶來一些幫助， 也歡迎各位隨時和我討論 Redis 源碼方面的問題， 或者跟我分享各位閱讀 Redis 源碼的心得和經驗。
另外我的 Redis 源碼注釋 項目以及 《Redis 設計與實現》 一書對於理解 Redis 的源代碼應該也會有所幫助， 有興趣的朋友可以自行了解該項目/書本。
黃健宏（huangz）
2014.7.28

Ⅸ php怎麼使用 redis pub/sub

一.場景介紹
最近的一個項目需要用到發布/訂閱的信息系統，以做到最新實時消息的通知。經查找後發現了redis pub/sub(發布/訂閱的信息系統)可以滿足我的開發需求,而且學習成本和使用成本也比較低。 :grin:
二.什麼是redis pub/sub
資料查看
大家在看我的blog的同時可以打開redis官方對於redis pub/sub的介紹，感覺看英文文檔吃力的話 :cry: ，可以看redis中文網的翻譯介紹.
Pub/Sub功能（means Publish, Subscribe）即發布及訂閱功能
1> 基於事件的系統中，Pub/Sub是目前廣泛使用的通信模型，它採用事件作為基本的通信機制，提供大規模系統所要求的鬆散耦合的交互模式：訂閱者(如客戶端)以事件訂閱的方式表達出它有興趣接收的一個事件或一類事件；發布者(如伺服器)可將訂閱者感興趣的事件隨時通知相關訂閱者。
2> 消息發布者，即publish客戶端，無需獨占鏈接，你可以在publish消息的同時，使用同一個redis-client鏈接進行其他操作（例如：INCR等）
3> 消息訂閱者，即subscribe客戶端，需要獨占鏈接，即進行subscribe期間，redis-client無法穿插其他操作，此時client以阻塞的方式等待「publish端」的消息；這一點很好理解，因此subscribe端需要使用單獨的鏈接，甚至需要在額外的線程中使用。
三.redis pub/sub的使用
下面我將配著實圖(用我的本地機器環境)來為大家講解redis的pub/sub怎麼去使用 .
沒有安裝phpredis擴展的或者沒有redis服務的，請參考我的另一篇blog，有詳細的安裝介紹，這里不再贅述了。
1、啟動redis服務端:
[caption id="attachment_1777" align="alignnone" width="300"] php redis pub/sub(消息訂閱系統)經驗總結之一[/caption]
2、新開一個終端,啟動redis客戶端，並做為subscribe客戶端(消息訂閱者)，訂閱一個名字叫test的頻道的頻道信息：
3、啟動redis客戶端，並做為publish客戶端(消息發布者)，發布一個名字叫test的頻道,信息是:hello,world
4、再切換到2步驟中的redis客戶端窗口，會發現，已經訂閱到了剛才發布的 'hello,world'消息:
5、模式匹配訂閱
Redis 的Pub/Sub實現支持模式匹配。客戶端可以訂閱全風格的模式以便接收所有來自能匹配到給定模式的頻道的消息。
比如,將接收所有發到 test.name,test.phone,test.address...等等的消息，該這樣寫:
[shell]PUBSCRIBE test.*[/shell]
在終端回車後，同時再新的窗口裡分別發布兩個頻道的消息，名字分別為:test.name和test.phone,然後切換到訂閱端的窗口裡，結果如下圖所示:
由上圖可以看出,在訂閱了test.*頻道後,一共收到了 test.name和test.phone兩個頻道的消息，這就是模式匹配訂閱。
那麼取消訂閱匹配該模式的客戶端也比較簡單：
[shell]PUNSUBSCRIBE test.*[/shell]
6、好，以上的這些簡單的demo，就是關於redis pub/sub(Publish/Subscribe,發布/訂閱的信息系統)的最基本使用。說了這么多，跟php也沒有掛上什麼鉤，別著急，重要的都往往最後出場。 :lol:
四.php使用redis的pub/sub(發布/訂閱的信息系統)
這里我列出一些常用的命令:
phpredis的安裝
redis的客戶端連接支持多種語言。這里我用的是php的phpredis，它是用c語言編寫的,目前已經作為php的一個模塊擴展，沒有安裝的可以參考我的另一篇blog，已經安裝的可以忽略此步驟.
命令手冊
這里我列出一些常用的:
[shell]Redis::__construct構造函數
$redis = new Redis();
connect, open 鏈接redis服務
參數
host: string，服務地址
port: int,埠號
timeout: float,鏈接時長 (可選, 默認為 0 ，不限鏈接時間)
注: 在redis.conf中也有時間，默認為300
pconnect, popen 不會主動關閉的鏈接
參考上面
setOption 設置redis模式
getOption 查看redis設置的模式
ping 查看連接狀態
get 得到某個key的值（string值）
如果該key不存在，return false
set 寫入key 和 value（string值）
如果寫入成功，return ture
setex 帶生存時間的寫入值
$redis->setex('key', 3600, 'value'); // sets key → value, with 1h TTL.
setnx 判斷是否重復的，寫入值<br />$redis->setnx('key', 'value');
$redis->setnx('key', 'value');
delete 刪除指定key的值
返回已經刪除key的個數（長整數）
$redis->delete('key1', 'key2');
$redis->delete(array('key3', 'key4', 'key5'));
<span style="font-size: 16px; line-height: 24px;">
[/shell]
更詳細的使用請參考這里，我就不寫太多，因為我要直接摞代碼了. :lol:
publish(消息發布端):pub.php
[php]
/**
* redis sub(消息訂閱端)
* @ blog: phping.sinaapp.com
* @date 2016-04-24 15:00
*/
$redis = new Redis();
// 第一個參數為redis伺服器的ip,第二個為埠
$res = $redis->connect('127.0.0.1', 6379);
// test為發布的頻道名稱,hello,world為發布的消息
$res = $redis->publish('test','hello,world');
[/php]
subscribe(消息訂閱端): sub.php
[php]
/**
* redis sub(消息訂閱端)
* @ blog: phping.sinaapp.com
* @date 2016-04-24 15:00
*/
$redis = new Redis();
$res = $redis->pconnect('127.0.0.1', 6379,0);
$redis->subscribe(array('test'), 'callback');
// 回調函數,這里寫處理邏輯
function callback($instance, $channelName, $message) {
echo $channelName, "==>", $message,PHP_EOL;
}
[/php]
開始訂閱redis消息
前面已經提到過，消息訂閱者，即subscribe客戶端，需要獨占鏈接，即進行subscribe期間，redis-client無法穿插其他操作，此時client以阻塞的方式等待「publish端」的消息，所以我們用命令行來執行:
則 訂閱消息的redis客戶端已經啟動，隨時等待發布過來的消息並訂閱該消息.
發布redis消息
同樣，命令行執行消息發布端的腳本即可:
[shell]
php pub.php
[/shell]
切換到消息訂閱端的窗口發現終端有輸出,如下圖:
哈哈，是不是 收到了發布端發布的'hello,world'這條消息呢。
五.總結
在命令執行redis訂閱端腳本時，發現在終端會輸出:
[shell]
PHPFatalerror: Uncaughtexception'RedisException'withmessage'readerroronconnection'in…
[/shell]
這樣的錯誤是什麼原因呢？請看我下一篇blog，本篇主要是講一些基本的語法，在下一篇我會著重講解一些在實際開發中遇到過的哪些問題和跳過的哪些坑。。。 :mrgreen:
碼字不易，望轉載註明出處哈 ;)

Ⅹ redis 的 pubsub 有什麼作用

Redis 是什麼？
通常而言目前的資料庫分類有幾種，包括 SQL/NSQL,，關系資料庫，鍵值資料庫等等 等，分類的標准也不以，Redis本質上也是一種鍵值資料庫的，但它在保持鍵值資料庫簡單快捷特點的同時，又吸收了部分關系資料庫的優點。從而使它的位置處於關系資料庫和鍵值數 據庫之間。Redis不僅能保存Strings類型的數據，還能保存Lists類型（有序）和Sets類型（無序）的數據，而且還能完成排序（SORT） 等高級功能，在實現INCR，SETNX等功能的時候，保證了其操作的原子性，除此以外，還支持主從復制等功能。
更為詳細的描述請參考如下：
http://code.google.com/p/redis/wiki/index
Redis官方也同樣提供了一個名為Retwis的項目代碼，可以對照著官方學習。
2 Redis用來做什麼？
通常局限點來說，Redis也以消息隊列的形式存在，作為內嵌的List存在，滿足實時的高並發需求。而通常在一個電商類型的數據處理過程之中，有關商品，熱銷，推薦排序的隊列，通常存放在Redis之中，期間也包擴Storm對於Redis列表的讀取和更新。
一個詳細的示範用例，還請參考本ID的另外一篇博文： Storm 【topN】 排序。期間使用的是：Storm-redis-pubsub的介面
3 Redis的優點
性能極高 – Redis能支持超過 100K+ 每秒的讀寫頻率。
豐富的數據類型 – Redis支持二進制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 數據類型操作。
原子 – Redis的所有操作都是原子性的，同時Redis還支持對幾個操作全並後的原子性執行。
豐富的特性 – Redis還支持 publish/subscribe, 通知, key 過期等等特性。
4 Redis的缺點
是資料庫容量受到物理內存的限制,不能用作海量數據的高性能讀寫,因此Redis適合的場景主要局限在較小數據量的高性能操作和運算上。
總結： Redis受限於特定的場景，專注於特定的領域之下，速度相當之快，目前還未找到能替代使用產品。