1. 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。
常用命令: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。
常用命令:lpush/rpush/lpop/rpop/lrange等;
應用場景:Redis list的應用場景非常多,也是Redis最重要的數據結構之一,比如twitter的關注列表,粉絲列表等都可以用Redis的list結構來實現;
實現方式:Redis list的實現為一個雙向鏈表,即可以支持反向查找和遍歷,更方便操作,不過帶來了部分額外的內存開銷,Redis內部的很多實現,包括發送緩沖隊列等也都是用的這個數據結構。
常用命令:sadd/spop/smembers/sunion等;
應用場景:Redis set對外提供的功能與list類似是一個列表的功能,特殊之處在於set是可以自動排重的,當你需要存儲一個列表數據,又不希望出現重復數據時,set是一個很好的選擇,並且set提供了判斷某個成員是否在一個set集合內的重要介面,這個也是list所不能提供的;
實現方式:set 的內部實現是一個 value永遠為null的HashMap,實際就是通過計算hash的方式來快速排重的,這也是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,使用跳躍表的結構可以獲得比較高的查找效率,並且在實現上比較簡單。
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,所以其性能也會受到影響。
2)Hash
3)List
4)Set
5)Sorted Set
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的三個設置項,安全強度逐漸變強。
對於一般性的業務需求,建議使用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節點。
2. redis 的持久化策略有幾種
Redis是一種高級key-value資料庫。它跟memcached類似,不過數據可以持久化,而且支持的數據類型很豐富。有字元串,鏈表,集 合和有序集合。支持在伺服器端計算集合的並,交和補集(difference)等,還支持多種排序功能。所以Redis也可以被看成是一個數據結構伺服器。
Redis的所有數據都是保存在內存中,然後不定期的通過非同步方式保存到磁碟上(這稱為「半持久化模式」);也可以把每一次數據變化都寫入到一個append only file(aof)裡面(這稱為「全持久化模式」)。
第一種方法filesnapshotting:默認redis是會以快照的形式將數據持久化到磁碟的(一個二進制文件,mp.rdb,這個文件名字可以指定),在配置文件中的格式是:save N M表示在N秒之內,redis至少發生M次修改則redis抓快照到磁碟。當然我們也可以手動執行save或者bgsave(非同步)做快照。
工作原理簡單介紹一下:當redis需要做持久化時,redis會fork一個子進程;子進程將數據寫到磁碟上一個臨時RDB文件中;當子進程完成寫臨時文件後,將原來的RDB替換掉,這樣的好處就是可以-on-write
還有一種持久化方法是Append-only:filesnapshotting方法在redis異常死掉時,最近的數據會丟失(丟失數據的多少視你save策略的配置),所以這是它最大的缺點,當業務量很大時,丟失的數據是很多的。Append-only方法可以做到全部數據不丟失,但redis的性能就要差些。AOF就可以做到全程持久化,只需要在配置文件中開啟(默認是no),appendonly yes開啟AOF之後,redis每執行一個修改數據的命令,都會把它添加到aof文件中,當redis重啟時,將會讀取AOF文件進行「重放」以恢復到redis關閉前的最後時刻。
3. 三分鍾讀懂redis資料庫
redis是一個key-value存儲系統。和Memcached類似,它支持存儲的value類型相對更多,包括string(字元串)、list(鏈表)、set(集合)、zset(sorted set --有序集合)和hash(哈希類型)。這些數據類型都支持push/pop、add/remove及取交集並集和差集及更豐富的操作,而且這些操作都是原子性的。在此基礎上,redis支持各種不同方式的排序。與memcached一樣,為了保證效率,數據都是緩存在內存中。區別的是redis會周期性的把更新的數據寫入磁碟或者把修改操作寫入追加的記錄文件,並且在此基礎上實現了master-slave(主從)同步。
1. 使用Redis有哪些好處?
(1) 速度快,因為數據存在內存中,類似於HashMap,HashMap的優勢就是查找和操作的時間復雜度都是O(1)
(2) 支持豐富數據類型,支持string,list,set,sorted set,hash
(3) 支持事務,操作都是原子性,所謂的原子性就是對數據的更改要麼全部執行,要麼全部不執行
(4) 豐富的特性:可用於緩存,消息,按key設置過期時間,過期後將會自動刪除
2. redis相比memcached有哪些優勢?
(1) memcached所有的值均是簡單的字元串,redis作為其替代者,支持更為豐富的數據類型
(2) redis的速度比memcached快很多
(3) redis可以持久化其數據
3. redis常見性能問題和解決方案:
(1) Master最好不要做任何持久化工作,如RDB內存快照和AOF日誌文件
(2) 如果數據比較重要,某個Slave開啟AOF備份數據,策略設置為每秒同步一次
(3) 為了主從復制的速度和連接的穩定性,Master和Slave最好在同一個區域網內
(4) 盡量避免在壓力很大的主庫上增加從庫
(5) 主從復制不要用圖狀結構,用單向鏈表結構更為穩定,即:Master <- Slave1 <- Slave2 <- Slave3...
這樣的結構方便解決單點故障問題,實現Slave對Master的替換。如果Master掛了,可以立刻啟用Slave1做Master,其他不變。
4. Mysql里有2000w數據,redis中只存20w的數據,如何保證redis中的數據都是熱點數據
相關知識:redis 內存數據集大小上升到一定大小的時候,就會施行數據淘汰策略。redis 提供 6種數據淘汰策略:
voltile-lru:從已設置過期時間的數據集(server.db[i].expires)中挑選最近最少使用的數據淘汰
volatile-ttl:從已設置過期時間的數據集(server.db[i].expires)中挑選將要過期的數據淘汰
volatile-random:從已設置過期時間的數據集(server.db[i].expires)中任意選擇數據淘汰
allkeys-lru:從數據集(server.db[i].dict)中挑選最近最少使用的數據淘汰
allkeys-random:從數據集(server.db[i].dict)中任意選擇數據淘汰
no-enviction(驅逐):禁止驅逐數據
相關推薦:《Python視頻教程》
5. Memcache與Redis的區別都有哪些?
1)、存儲方式
Memecache把數據全部存在內存之中,斷電後會掛掉,數據不能超過內存大小。
Redis有部份存在硬碟上,這樣能保證數據的持久性。
2)、數據支持類型
Memcache對數據類型支持相對簡單。
Redis有復雜的數據類型。
3),value大小
redis最大可以達到1GB,而memcache只有1MB
6. Redis 常見的性能問題都有哪些?如何解決?
1).Master寫內存快照,save命令調度rdbSave函數,會阻塞主線程的工作,當快照比較大時對性能影響是非常大的,會間斷性暫停服務,所以Master最好不要寫內存快照。
2).Master AOF持久化,如果不重寫AOF文件,這個持久化方式對性能的影響是最小的,但是AOF文件會不斷增大,AOF文件過大會影響Master重啟的恢復速度。Master最好不要做任何持久化工作,包括內存快照和AOF日誌文件,特別是不要啟用內存快照做持久化,如果數據比較關鍵,某個Slave開啟AOF備份數據,策略為每秒同步一次。
3).Master調用BGREWRITEAOF重寫AOF文件,AOF在重寫的時候會佔大量的CPU和內存資源,導致服務load過高,出現短暫服務暫停現象。
4). Redis主從復制的性能問題,為了主從復制的速度和連接的穩定性,Slave和Master最好在同一個區域網內
7. redis 最適合的場景
Redis最適合所有數據in-momory的場景,雖然Redis也提供持久化功能,但實際更多的是一個disk-backed的功能,跟傳統意義上的持久化有比較大的差別,那麼可能大家就會有疑問,似乎Redis更像一個加強版的Memcached,那麼何時使用Memcached,何時使用Redis呢?
如果簡單地比較Redis與Memcached的區別,大多數都會得到以下觀點:
1.Redis不僅僅支持簡單的k/v類型的數據,同時還提供list,set,zset,hash等數據結構的存儲。
2.Redis支持數據的備份,即master-slave模式的數據備份。
3.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,你可以從這里去查看。
(4)排行榜/計數器
Redis在內存中對數字進行遞增或遞減的操作實現的非常好。集合(Set)和有序集合(Sorted Set)也使得我們在執行這些操作的時候變的非常簡單,Redis只是正好提供了這兩種數據結構。所以,我們要從排序集合中獲取到排名最靠前的10個用戶–我們稱之為「user_scores」,我們只需要像下面一樣執行即可:
當然,這是假定你是根據你用戶的分數做遞增的排序。如果你想返回用戶及用戶的分數,你需要這樣執行:
ZRANGE user_scores 0 10 WITHSCORES
Agora Games就是一個很好的例子,用Ruby實現的,它的排行榜就是使用Redis來存儲數據的,你可以在這里看到。
(5)發布/訂閱
最後(但肯定不是最不重要的)是Redis的發布/訂閱功能。發布/訂閱的使用場景確實非常多。我已看見人們在社交網路連接中使用,還可作為基於發布/訂閱的腳本觸發器,甚至用Redis的發布/訂閱功能來建立聊天系統!(不,這是真的,你可以去核實)。
4. redis怎麼持久化
redis是一個支持持久化的內存資料庫,也就是說redis需要經常將內存中的數據同步到磁碟來保證持久化。redis支持四種持久化方式,一是 Snapshotting(快照)也是默認方式;二是Append-only file(縮寫aof)的方式;三是虛擬內存方式;四是diskstore方式。下面分別介紹之。
5. redis的數據是存在內存里嗎
Redis就是基於內存可持久化的key-value資料庫。
1、性能問題,Hashmap存儲大量數知據時需要不斷擴容,Redis支持2的32次方個key,每個key或者value大小最大512M。
2、Hashmap是線程不安道全的,redis因為操作原子性不需要考慮這個。
3、Redis可持久化,Hashmap雖然也可以序列專化,但是Java的序列化因為安全問題說是要廢除了,效率也沒有Redis高,而且Redis有多屬種持久化策略。
4、Redis可擴展可分布式部署。
(5)redis內存資料庫持久化擴展閱讀:
redis的存儲分為內存存儲、磁碟存儲和log文件三部分,配置文件中有三個參數對其進行配置。
save seconds updates,save配置,指出在多長時間內,有多少次更新操作,就將數據同步到數據文件。這個可以多個條件配合,比如默認配置文件中的設置,就設置了三個條件。
appendonly yes/no ,appendonly配置,指出是否在每次更新操作後進行日誌記錄,如果不開啟,可能會在斷電時導致一段時間內的數據丟失。因為redis本身同步數據文件是按上面的save條件來同步的,所以有的數據會在一段時間內只存在於內存中。
6. redis數據持久化到到磁碟還是資料庫
redis本身數據存儲在內存中,如果斷電,數據
會都
沒有,所以需要把數據保存在磁碟中,才能保存長久,這個就是
持久化
了,是保存在磁碟中呢
7. 剛剛問我,redis持久化數據到資料庫是怎麼操作的
1、 快照的方式持久化到磁碟
自動持久化規則配置
save 900 1
save 300 10
save 60 10000
上面的配置規則意思如下:
# In the example below the behaviour will be to save:
# after 900 sec (15 min) if at least 1 key changed
# after 300 sec (5 min) if at least 10 keys changed
# after 60 sec if at least 10000 keys changed
redis也可以關閉自動持久化,注釋掉這些save配置,或者save 「」
如果後台保存到磁碟發生錯誤,將停止寫操作.
stop-writes-on-bgsave-error yes
使用LZF壓縮rdb文件,這會耗CPU, 但是可以減少磁碟佔用.
rdbcompression yes
保存rdb和載入rdb文件的時候檢驗,可以防止錯誤,但是要付出約10%的性能,可以關閉他,提高性能。
rdbchecksum yes
導出的rdb文件名
dbfilename mp.rdb
設置工作目錄, rdb文件會寫到該目錄, append only file也會存儲在該目錄下.
dir ./
Redis自動快照保存到磁碟或者調用bgsave,是後台進程完成的,其他客戶端仍然和可以讀寫redis伺服器,後台保存快照到磁碟會佔用大量內存。調用save保存內存中的數據到磁碟,將阻塞客戶端請求,直到保存完畢。
調用shutdown命令,Redis伺服器會先調用save,所有數據持久化到磁碟之後才會真正退出。
對於數據丟失的問題:
如果伺服器crash,從上一次快照之後的數據將全部丟失。所以在設置保存規則的時候,要根據實際業務設置允許的范圍。
如果對於數據敏感的業務,在程序中要使用恰當的日誌,在伺服器crash之後,通過日誌恢復數據。
2、 Append-only file 的方式持久化
另外一種方式為遞增的方式,將會引起數據變化的操作, 持久化到文件中, 重啟redis的時候,通過操作命令,恢復數據.
每次執行寫操作命令之後,都會將數據寫到server.aofbuf中。
# appendfsync always
appendfsync everysec
# appendfsync no
當配置為always的時候,每次server.aofbuf中的數據寫入到文件之後,才會返回給客戶端,這樣可以保證數據不丟,但是頻繁的IO操作,會降低性能。
everysec每秒寫一次,這可能會丟失一秒內的操作。
aof最大的問題就是隨著時間append file會變的很大,所以我們需要bgrewriteaof命令重新整理文件,只保留最新的kv數據。
8. redis 本身有持久化,為什麼還要寫進 mysql
本身的持久化,會可能丟失數據,因為本身的持久化,不是實時的,是數據先在內存,再定時的保存到硬碟來達到持久化,當然,這個定時的時間相隔,是可以配置的。
這個配置的時間,如果太短,那麼使用redis的效率就低,如果長了,那麼可能丟失的數據就會多,所以,要根據自己的業務來取得一個均衡。
保存到資料庫的,可以理解為比較保險,redis出現問題,還可以從資料庫中恢復過來
從兩者的擅長角度來看,資料庫擅長的是存儲和檢索
redis相當於內存資料庫,擅長的地方是讀
結合兩個的擅長點來使用,才是王道。
海楓科技
9. redis 兩種持久化分別叫什麼
Redis是一種高級key-value資料庫。它跟memcached類似,不過數據可以持久化,而且支持的數據類型很豐富。有字元串,鏈表,集
合和有序集合。支持在伺服器端計算集合的並,交和補集(difference)等,還支持多種排序功能。所以Redis也可以被看成是一個數據結構伺服器。
Redis的所有數據都是保存在內存中,然後不定期的通過非同步方式保存到磁碟上(這稱為「半持久化模式」);也可以把每一次數據變化都寫入到一個append
only
file(aof)裡面(這稱為「全持久化模式」)。
第一種方法filesnapshotting:默認redis是會以快照的形式將數據持久化到磁碟的(一個二進制文件,mp.rdb,這個文件名字可以指定),在配置文件中的格式是:save
N
M表示在N秒之內,redis至少發生M次修改則redis抓快照到磁碟。當然我們也可以手動執行save或者bgsave(非同步)做快照。
工作原理簡單介紹一下:當redis需要做持久化時,redis會fork一個子進程;子進程將數據寫到磁碟上一個臨時RDB文件中;當子進程完成寫臨時文件後,將原來的RDB替換掉,這樣的好處就是可以-on-write
還有一種持久化方法是Append-only:filesnapshotting方法在redis異常死掉時,最近的數據會丟失(丟失數據的多少視你save策略的配置),所以這是它最大的缺點,當業務量很大時,丟失的數據是很多的。Append-only方法可以做到全部數據不丟失,但redis的性能就要差些。AOF就可以做到全程持久化,只需要在配置文件中開啟(默認是no),appendonly
yes開啟AOF之後,redis每執行一個修改數據的命令,都會把它添加到aof文件中,當redis重啟時,將會讀取AOF文件進行「重放」以恢復到redis關閉前的最後時刻。
LOG
Rewriting隨著
10. linux上怎麼配置redis的aof持久化
Redis 持久化和配置文件
Reids 持久化
Redis提供了兩種持久化的方式,分別是RDB(Redis DataBase)和AOF(Append Only File)。
RDB,簡而言之,就是在不同的時間點,將redis存儲的數據生成快照並存儲到磁碟等介質上。
AOF,則是換了一個角度來實現持久化,那就是將redis執行過的所有寫指令記錄下來,在下次redis重新啟動時,只要把這些寫指令從前到後再重復執行一遍,就可以實現數據恢復了。
其實RDB和AOF兩種方式也可以同時使用,在這種情況下,如果redis重啟的話,則會優先採用AOF方式來進行數據恢復,這是因為AOF方式的數據恢復完整度更高。
如果你沒有數據持久化的需求,也完全可以關閉RDB和AOF方式,這樣的話,redis將變成一個純內存資料庫,就像memcache一樣。
redis配置文件
daemonize no # 默認情況下,redis並不是以daemon形式來運行的。通過daemonize配置項可以控制redis的運行形式
pidfile /path/to/redis.pid #當以daemon形式運行時,redis會生成一個pid文件,默認會生成在/var/run/redis.pid
bind 192.168.1.2 10.8.4.2 # 指定綁定的ip,可以有多個
port 6379 #指定監聽埠
unixsocket /tmp/redis.sock #也可以監聽socket
unixsocketperm 755 #當監聽socket時可以指定許可權為755
timeout 0 #當一個redis-client一直沒有請求發向server端,那麼server端有權主動關閉這個連接,可以通過timeout來設置「空閑超時時限」,0表示永不關閉。
Redis通用配置
tcp-keepalive0 #TCP連接保活策略,可以通過tcp-keepalive配置項來進行設置,單位為秒,假如設置為60秒,則server端會每60秒向連接空閑的客戶端發起一次ACK請求,以檢查客戶端是否已經掛掉,對於無響應的客戶端則會關閉其連接。如果設置為0,則不會進行保活檢測。
loglevelnotice #日誌級別,有四種debug, verbose, notice, warning
logfile「」 #定義日誌路徑,
syslog-identredis #如果希望日誌列印到syslog中,通過syslog-enabled來控制。另外,syslog-ident還可以讓你指定syslog里的日誌標志。
syslog-facility local0 #指定syslog的設備,可以是USER或者local0-local7
databases 16 #設置資料庫的總數量
Redis快照配置(rdb持久化)
save 900 1 #表示每15分鍾且至少有1個key改變,就觸發一次持久化
save 300 10 #表示每5分鍾且至少有10個key改變,就觸發一次持久化
save 60 10000 #表示每60秒至少有10000個key改變,就觸發一次持久
save 「」 #這樣可以禁用rdb持久化
stop-writes-on-bgsave-error yes #rdb持久化寫入磁碟避免不了會出現失敗的情況,默認一旦出現失敗,redis會馬上停止寫操作。如果你覺得無所謂,那就可以使用該選項關閉這個功能。
rdbcompressionyes #是否要壓縮
rdbchecksumyes #是否進行數據校驗
dbfilenamemp.rdb #定義快照文件的名字
dir ./ #定義快照文件儲存路勁
Redis安全相關配置
requirepassaminglinux
#設置redis-server的密碼
rename-command CONFIG aminglinux.config
#將CONFIG命令更名為aminglinux.config,這樣可以避免誤操作,但如果使用了AOF持久化,建議不要啟用該功能
rename-command CONFIG 「」
#也可以後面定義為空,這樣就禁掉了該CONFIG命令
Redis限制相關配置
maxclients10000 #限制最大客戶端連接數
maxmemory<bytes> #設定最大內存使用數,單位是byte
maxmemory-policy volatile-lru#指定內存移除規則
maxmemory-samples 3 #LRU演算法和最小TTL演算法都並非是精確的演算法,而是估算值。所以你可以設置樣本的大小。假如redis默認會檢查三個key並選擇其中LRU的那個,那麼你可以改變這個key樣本的數量。
Redis AOF持久化相關配置
appendonlyno #如果是no,則開啟aof持久化
appendfilename「appendonly.aof」 #指定aof文件名字
appendfsynceverysec#指定fsync()調用模式,有三種no(不調用fsync),always(每次寫都會調用fsync),everysec(每秒鍾調用一次fsync)。第一種最快,第二種數據最安全,但性能會差一些,第三種為這種方案,默認為第三種。
no-appendfsync-on-rewrite no #使用no,可以避免當寫入量非常大時的磁碟io阻塞
auto-aof-rewrite-percentage 10 #規定什麼情況下會觸發aof重寫。該值為一個比例,10表示當aof文件增幅達到10%時則會觸發重寫機制。
auto-aof-rewrite-min-size 64mb #重寫會有一個條件,就是不能低於64Mb
Redis 慢日誌相關配置
針對慢日誌,你可以設置兩個參數,一個是執行時長,單位是微秒,另一個是慢日誌的長度。當一個新的命令被寫入日誌時,最老的一條會從命令日誌隊列中被移除。