挖礦程序通過redis能夠干什麼

『壹』 Jedis干什麼用的

redis是key-value存儲系統。

key-value分布式存儲系統查詢速度快、存放數據量大、支持高並發，非常適合通過主鍵進行查詢，但不能進行復雜的條件查詢。

如果輔以Real-Time Search Engine（實時搜索引擎）進行復雜條件檢索、全文檢索，就可以替代並發性能較低的MySQL等關系型資料庫，達到高並發、高性能，節省幾十倍伺服器數 量的目的。

以MemcacheDB、Tokyo Tyrant為代表的key-value分布式存儲，在上萬並發連接下，輕松地完成高速查詢。而MySQL，在幾百個並發連接下，就基本上崩潰了。

在此基礎上，redis支持各種不同方式的排序。與memcached一樣，為了保證效率，數據都是緩存在內存中。區別的是redis會周期性的把更新的數據寫入磁碟或者把修改操作寫入追加的記錄文件，並且在此基礎上實現了master-slave(主從)同步。

(1)挖礦程序通過redis能夠干什麼擴展閱讀：

Jedis主存保護是存儲保護的重要環節。主存保護一般有存儲區域保護和訪問方式保護。存儲區域保護可採用界限寄存器方式，由系統軟體經特權指令給定上、下界寄存器內容，從而劃定每個用戶程序的區域，禁止越界訪問。

Jedis當兩鍵符合時才允許執行存取操作，從而保護別的程序區域不被侵犯，環狀保護是把系統程序和用戶程序按重要性分層，稱為環，對每個環都規定訪問它的級別，違反規定的存取操作是非法的，以此實現對正在執行的程序的保護。

『貳』 redis適合什麼場景

1、緩存。 緩存現在幾乎是所有中大型網站都在用的必殺技，合理的利用緩存不僅能夠提升網站訪問速度，還能大大降低資料庫的壓力。Redis提供了鍵過期功能，也提供了靈活的鍵淘汰策略，所以，現在Redis用在緩存的場合非常多。（推薦：《 Redis視頻教程 》）
2、排行榜。 很多網站都有排行榜應用的，如京東的月度銷量榜單、商品按時間的上新排行榜等。Redis提供的有序集合數據類構能實現各種復雜的排行榜應用。
3、計數器。 什麼是計數器，如電商網站商品的瀏覽量、視頻網站視頻的播放數等。為了保證數據實時效，每次瀏覽都得給+1，並發量高時如果每次都請求資料庫操作無疑是種挑戰和壓力。Redis提供的incr命令來實現計數器功能，內存操作，性能非常好，非常適用於這些計數場景。
4、分布式會話。 集群模式下，在應用不多的情況下一般使用容器自帶的session復制功能就能滿足，當應用增多相對復雜的系統中，一般都會搭建以Redis等內存資料庫為中心的session服務，session不再由容器管理，而是由session服務及內存資料庫管理。
5、分布式鎖。 在很多互聯網公司中都使用了分布式技術，分布式技術帶來的技術挑戰是對同一個資源的並發訪問，如全局ID、減庫存、秒殺等場景，並發量不大的場景可以使用資料庫的悲觀鎖、樂觀鎖來實現，但在並發量高的場合中，利用資料庫鎖來控制資源的並發訪問是不太理想的，大大影響了資料庫的性能。可以利用Redis的setnx功能來編寫分布式的鎖，如果設置返回1說明獲取鎖成功，否則獲取鎖失敗，實際應用中要考慮的細節要更多。

『叄』 redis是個單線程的程序，為什麼會這么快呢每秒10000

MongoDB不多說，不是一個類型的東西，Redis相對Memcached來說功能和特性上的優勢已經很明顯了。而對於性能，Redis作者的說法是平均到單個核上的性能，在單條數據不大的情況下Redis更好。為什麼這么說呢，理由就是Redis是單線程運行的。因為是單線程運行，所以和Memcached的多線程相比，整體性能肯定會偏低。因為是單線程運行，所以IO是串列化的，網路IO和內存IO，因此當單條數據太大時，由於需要等待一個命令的所有IO完成才能進行後續的命令，所以性能會受影響。而就內存使用上來說，目前Redis結合了tcmalloc和jemalloc兩個內存分配器，基本上和Memcached不相伯仲。如果是簡單且有規律的key value存儲，那麼用Redis的hash結構來做，內存使用上會驚人的變小，優勢是很明顯的。

『肆』 redis是什麼

Redis是一個開源的使用ANSI C語言編寫、支持網路、可基於內存亦可持久化的日誌型、Key-Value資料庫，並提供多種語言的API。從2010年3月15日起，Redis的開發工作由VMware主持。

redis是一個key-value存儲系統。和Memcached類似，它支持存儲的value類型相對更多，包括string(字元串)、list(鏈表)、set(集合)、zset(sorted set --有序集合)和hash（哈希類型）。這些數據類型都支持push/pop、add/remove及取交集並集和差集及更豐富的操作，而且這些操作都是原子性的。在此基礎上，redis支持各種不同方式的排序。與memcached一樣，為了保證效率，數據都是緩存在內存中。區別的是redis會周期性的把更新的數據寫入磁碟或者把修改操作寫入追加的記錄文件，並且在此基礎上實現了master-slave(主從)同步。
Redis 是一個高性能的key-value資料庫。 redis的出現，很大程度補償了memcached這類key/value存儲的不足，在部 分場合可以對關系資料庫起到很好的補充作用。它提供了Python，Ruby，Erlang，PHP客戶端，使用很方便。[1]
Redis支持主從同步。數據可以從主伺服器向任意數量的從伺服器上同步，從伺服器可以是關聯其他從伺服器的主伺服器。這使得Redis可執行單層樹復制。從盤可以有意無意的對數據進行寫操作。由於完全實現了發布/訂閱機制，使得從資料庫在任何地方同步樹時，可訂閱一個頻道並接收主伺服器完整的消息發布記錄。同步對讀取操作的可擴展性和數據冗餘很有幫助。

『伍』 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是什麼，用來做什麼

Redis是一個nosql資料庫，可以存儲key-value值。因為其底層實現中，數據讀寫是基於內存，速度非常快，所以常用於緩存；進而因其為獨立部署的中間件，常用於分布式緩存的實現方案。

常用場景有：緩存、秒殺控制、分布式鎖。

雖然其是基於內存讀寫，但底層也有持久化機制；同時具備集群模式；不用擔心其可用性。

關於Redis的使用，可以參考《Redis的使用方法、常見應用場景》

『柒』 redis主要解決什麼問題

redis是內存資料庫，訪問速度非常快，所以能夠解決的也都是這些緩存類型的問題，如下：
1、會話緩存（Session Cache）
最常用的一種使用Redis的情景是會話緩存（session cache）。用Redis緩存會話比其他存儲（如Memcached）的優勢在於：Redis提供持久化。當維護一個不是嚴格要求一致性的緩存時，如果用戶的購物車信息全部丟失，大部分人都會不高興的，現在，他們還會這樣嗎？
幸運的是，隨著 Redis 這些年的改進，很容易找到怎麼恰當的使用Redis來緩存會話的文檔。甚至廣為人知的商業平台Magento也提供Redis的插件。
2、全頁緩存（FPC）
除基本的會話token之外，Redis還提供很簡便的FPC平台。回到一致性問題，即使重啟了Redis實例，因為有磁碟的持久化，用戶也不會看到頁面載入速度的下降，這是一個極大改進，類似PHP本地FPC。
再次以Magento為例，Magento提供一個插件來使用Redis作為全頁緩存後端。
此外，對WordPress的用戶來說，Pantheon有一個非常好的插件 wp-redis，這個插件能幫助你以最快速度載入你曾瀏覽過的頁面。
3、隊列
Reids在內存存儲引擎領域的一大優點是提供 list 和 set 操作，這使得Redis能作為一個很好的消息隊列平台來使用。Redis作為隊列使用的操作，就類似於本地程序語言（如Python）對 list 的 push/pop 操作。
如果你快速的在Google中搜索「Redis queues」，你馬上就能找到大量的開源項目，這些項目的目的就是利用Redis創建非常好的後端工具，以滿足各種隊列需求。例如，Celery有一個後台就是使用Redis作為broker，你可以從這里去查看。
排行榜/計數器
Redis在內存中對數字進行遞增或遞減的操作實現的非常好。集合（Set）和有序集合（Sorted Set）也使得我們在執行這些操作的時候變的非常簡單，Redis只是正好提供了這兩種數據結構。所以，我們要從排序集合中獲取到排名最靠前的10個用戶–我們稱之為「user_scores」，我們只需要像下面一樣執行即可：
當然，這是假定你是根據你用戶的分數做遞增的排序。如果你想返回用戶及用戶的分數，你需要這樣執行：
ZRANGE user_scores 0 10 WITHSCORES
Agora Games就是一個很好的例子，用Ruby實現的，它的排行榜就是使用Redis來存儲數據的，你可以在這里看到。
5、發布/訂閱
最後（但肯定不是最不重要的）是Redis的發布/訂閱功能。發布/訂閱的使用場景確實非常多。我已看見人們在社交網路連接中使用，還可作為基於發布/訂閱的腳本觸發器，甚至用Redis的發布/訂閱功能來建立聊天系統！（不，這是真的，你可以去核實）。
Redis提供的所有特性中，我感覺這個是喜歡的人最少的一個，雖然它為用戶提供如果此多功能。
等等？

『捌』 Redis和Memcache的區別分析

1. Redis中，並不是所有的數據都一直存儲在內存中的，這是和Memcached相比一個最大的區別。

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

3. Redis支持數據的備份，即master-slave模式的數據備份。

4. Redis支持數據的持久化，可以將內存中的數據保持在磁碟中，重啟的時候可以再次載入進行使用。

Redis在很多方面具備資料庫的特徵，或者說就是一個資料庫系統，而Memcached只是簡單的K/V緩存

來看下Redis作者對比redis和memcache

來源：《Is memcached a dinosaur in comparison to Redis?》(相比Redis，Memcached真的過時了嗎？)

You
should not care too much about performances. Redis is faster per core
with small values, but memcached is able to
use multiple cores with a single executable and TCP port without help
from the client. Also memcached is faster with big values in the order
of 100k. Redis recently improved a lot about big values (unstable
branch) but still memcached is faster in this use
case. The point here is: nor one or the other will likely going to be
your bottleneck for the query-per-second they can deliver.

沒
有必要過多的關心性能，因為二者的性能都已經足夠高了。由於Redis只使用單核，而Memcached可以使用多核，所以在比較上，平均每一個核上
Redis在存儲小數據時Memcached性能更高。而在100k以上的數據中，Memcached性能要高於Redis，雖然Redis最近也在存儲

大數據的性能上進行優化，但是比起Memcached，還是稍有遜色。說了這么多，結論是，無論你使用哪一個，每秒處理請求的次數都不會成為瓶頸。（比如
瓶頸可能會在網卡）

You should care about memory usage. For simple key-value pairs memcached is more memory efficient. If you use Redis hashes,
Redis is more memory efficient. Depends on the use case.

如果要說內存使用效率，使用簡單的key-value存儲的話，Memcached的內存利用率更高，而如果Redis採用hash結構來做key-value存儲，由於其組合式的壓縮，其內存利用率會高於Memcached。當然，這和你的應用場景和數據特性有關。

You should care about persistence and replication, two features only available in Redis. Even if your goal is to build
a cache it helps that after an upgrade or a reboot your data are still there.

如果你對數據持久化和數據同步有所要求，那麼推薦你選擇Redis，因為這兩個特性Memcached都不具備。即使你只是希望在升級或者重啟系統後緩存數據不會丟失，選擇Redis也是明智的。

You
should care about the kind of operations you need. In Redis there are a
lot of complex operations, even just considering
the caching use case, you often can do a lot more in a single
operation, without requiring data to be processed client side (a lot of
I/O is sometimes needed). This operations are often as fast as plain GET
and SET. So if you don't need just GET/SET but more
complex things Redis can help a lot (think at timeline caching).

當

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

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

5、分布式--設定memcache集群，利用magent做一主多從;redis可以做一主多從。都可以一主一從

6、存儲數據安全--memcache掛掉後，數據沒了；redis可以定期保存到磁碟（持久化）

7、災難恢復--memcache掛掉後，數據不可恢復; redis數據丟失後可以通過aof恢復

8、Redis支持數據的備份，即master-slave模式的數據備份。

==================

Redis和Memcache，測試伺服器是一個個人PC:配置一般(2CPU\2G內存)，操作系統安裝的CentOS。

1、redis memcache都是空的時候

redis設置100000個值開始時間:1311742106

redis設置100000個值時間:1311742123 耗時:16.8817

memcache設置100000個值開始時間:1311742123

memcache設置100000個值結束時間:1311742138 耗時:15.2574

2、redis和memcache有數據時：

redis設置100000個值開始時間:1311742721

redis設置100000個值時間:1311742738 耗時:17.3401

memcache設置100000個值開始時間:1311742738

memcache設置100000個值結束時間:1311742753 耗時:15.6892

3、分別測試redis和memcache獲取數據速度：

redis數組獲取100000個值開始時間:1311742144

redis數組獲取100000個值時間:1311742398 耗時:253.9285

redis逐個獲取100000個值開始時間:1311742398

redis逐個獲取100000個值時間:1311742414 耗時:16.339

memcache數組獲取100000個值開始時間:1311742414

memcache數組獲取100000個值結束時間:1311742415 耗時:0.8022

memcache逐個獲取100000個值開始時間:1311742415

memcache逐個獲取100000個值結束時間:1311742428 耗時:13.38

就以上測試結果，Redis和Memcache在寫入性能上面差別不大，讀取性能上面尤其是批量讀取性能上面Memcache全面勝出，當然Redis也有自己的優點：比如數據持久化、支持更多的數據結構（Set List ZSet）等。

『玖』 redis除了緩存還可以做什麼

1、緩存僅僅是redis的一個小的方面
2、你要明白redis是非關系型內存資料庫，他有著豐富的數據類型：string，list，hash，set，zset
3、有足夠的money，你完全可以將redis作為主存
4、redis可以做的很多，比如：投票系統，用戶登錄session，購物車，網頁緩存，日誌系統，搜索引擎，消息隊列。

『拾』 redis desktop manager可以做什麼

一、新建連接
輸入redis主機host，埠號port，再起個生動形象，簡明達意的別名。
二、該工具支持根據篩選條件查詢key，add new key，reload等。
三、支持常用redis操作
針對目標key執行rename，delete，addrow，reload value操作。
四、命令控制台操作 ！