❶ redis如何理解呢，在哪些方面有應用呢
您好，這樣的：
毫無疑問，Redis開創了一種新的數據存儲思路，使用Redis，我們不用在面對功能單調的資料庫時，把精力放在如何把大象放進冰箱這樣的問題上，而是利用Redis靈活多變的數據結構和數據操作，為不同的大象構建不同的冰箱。希望你喜歡這個比喻。
Redis比較適合的一些應用場景，簡單列舉在這里，供大家一覽：
1.取最新N個數據的操作
比如典型的取你網站的最新文章，通過下面方式，我們可以將最新的5000條評論的ID放在Redis的List集合中，並將超出集合部分從資料庫獲取
使用LPUSH latest.comments<ID>命令，向list集合中插入數據
插入完成後再用LTRIM latest.comments 0 5000命令使其永遠只保存最近5000個ID
然後我們在客戶端獲取某一頁評論時可以用下面的邏輯（偽代碼）
FUNCTION get_latest_comments(start,num_items):
id_list = redis.lrange("latest.comments",start,start+num_items-1)
IF id_list.length < num_items
id_list = SQL_DB("SELECT ... ORDER BY time LIMIT ...")
END
RETURN id_list
END
如果你還有不同的篩選維度，比如某個分類的最新N條，那麼你可以再建一個按此分類的List，只存ID的話，Redis是非常高效的。
2.排行榜應用，取TOP N操作
這個需求與上面需求的不同之處在於，前面操作以時間為權重，這個是以某個條件為權重，比如按頂的次數排序，這時候就需要我們的sorted set出馬了，將你要排序的值設置成sorted set的score，將具體的數據設置成相應的value，每次只需要執行一條ZADD命令即可。
3.需要精準設定過期時間的應用
比如你可以把上面說到的sorted set的score值設置成過期時間的時間戳，那麼就可以簡單地通過過期時間排序，定時清除過期數據了，不僅是清除Redis中的過期數據，你完全可以把Redis里這個過期時間當成是對資料庫中數據的索引，用Redis來找出哪些數據需要過期刪除，然後再精準地從資料庫中刪除相應的記錄。
4.計數器應用
Redis的命令都是原子性的，你可以輕松地利用INCR，DECR命令來構建計數器系統。
5.Uniq操作，獲取某段時間所有數據排重值
這個使用Redis的set數據結構最合適了，只需要不斷地將數據往set中扔就行了，set意為集合，所以會自動排重。
6.實時系統，反垃圾系統
通過上面說到的set功能，你可以知道一個終端用戶是否進行了某個操作，可以找到其操作的集合並進行分析統計對比等。沒有做不到，只有想不到。
7.Pub/Sub構建實時消息系統
Redis的Pub/Sub系統可以構建實時的消息系統，比如很多用Pub/Sub構建的實時聊天系統的例子。
8.構建隊列系統
使用list可以構建隊列系統，使用sorted set甚至可以構建有優先順序的隊列系統。
9.緩存
這個不必說了，性能優於Memcached，數據結構更多樣化。
❷ 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節點。
❸ 查看redis資料庫實例對應的配置文件。
查看redis資料庫實例對應的配置文件
執行 ps -ef | grep redis-server ，確定redis的安裝目錄，一般配置文件都是 安裝目錄/etc/redis.conf ；
❹ 如何用Redis緩存改善資料庫查詢性能
因為Redis具有在數據存儲中快速讀寫數據的能力，所以它比關系型資料庫更具有性能優勢。但是，關鍵值數據存儲是簡單的;它們沒有一個類似於
SQL的查詢語言或者結構化的數據模型。相反，它們有一個把鍵值作為與數值相關的標識符來使用的簡單字典或哈希模式。管理員使用這些鍵來進行數值的存儲和
檢索。
鍵值存儲是簡單快速的，它可用於實現豐富數據模型和關系型資料庫查詢功能的良好匹配。但是，有時候還是使用鍵值與關系型資料庫的組合為好。此外，還有很多商業支持的鍵值資料庫，包括Redis、Riak和Areospike等。
為了運行一個優化熱門查詢性能的Redis緩存，首先應確定你希望緩存的查詢結果。其中，應重點關注最常用的和最耗時的查詢，然後確定應緩沖查詢中的數據。為簡便起見，緩存查詢返回的所有列值。
為鍵值定義一個命名約定;可以使用行主鍵和列名的組合來構造密鑰。例如，其主鍵ID為 198278的 產品描述可以『198278:descry』的鍵值進行存儲。確保你的命名規則是簡單和規則驅動的，以便於使用最少的代碼來實現鍵的程序化創建。
接下來，確定是運行Redis緩存作為自助管理服務還是運行亞馬遜的ElastiCache。運行用戶自己的Redis實例將賦予管理人員對緩存的完全控制權。而這一控制權意味著靈活性，例如當有超出容量的情況出現時，管理人員有使用現有保留實例的權力。
此外，當用戶想要把應用程序從一家雲計算供應商遷移至另一家時，他們會發現完整的管理控制許可權是非常有用的。
如果用戶選擇運行一個自助管理的Redis實例，可下載伺服器。Redis的客戶端支持30種以上編程語言——從Java和Python到Prolog和Smalltalk。
已經使用AWS環境的企業可能會想要使用ElastiCache。除了諸如託管打補丁這樣的優點之外，亞馬遜ElastiCache支持一系列高速
緩存優化的節點類型，具體包括從中型到2X的m3節點、從大型到8X的r3節點以及從微型到中型的t2節點。ElastiCache還支持一些上一代的節
點類型，例如選擇m1、m2、t1和c1節點。
ElastiCache還支持多個可用區。如果有一個節點發生故障，一個讀操作復制節點將取代故障節點。任何需要確保應用程序運行的DNS變更都是
自動完成的，同時會創建一個新的讀操作副本。ElastiCache允許基於單位時間使用率的按需定價模式，以及一年期或三年期預付費的節點使用條款。完
整定價清單可以在這里找到。
如果使用Redis緩存和亞馬遜ElastiCache，那麼就可以從AWS管理控制台啟動一個集群。除了設置Redis服務外，還需要修改應用程
序代碼以便於能夠使用緩存。一個常用的模式就是，檢查緩存中是否存在有一個鍵值，如果沒有就執行一個SQL查詢以檢索數據，然後將其存儲在緩存中。當緩沖
存滿時，可以配置Redis刪除舊數據，這樣就不需要用戶使用專門的代碼來處理緩存存滿的情況了。
❺ Redis 都有哪些應用場景
緩存：這應該是 Redis 最主要的功能了，也是大型網站必備機制，合理地使用緩存不僅可以加 快數據的訪問速度，而且能夠有效地降低後端數據源的壓力。
共享Session：對於一些依賴 session 功能的服務來說，如果需要從單機變成集群的話，可以選擇 redis 來統一管理 session。
消息隊列系統：消息隊列系統可以說是一個大型網站的必備基礎組件，因為其具有業務 解耦、非實時業務削峰等特性。Redis提供了發布訂閱功能和阻塞隊列的功 能，雖然和專業的消息隊列比還不夠足夠強大，但是對於一般的消息隊列功 能基本可以滿足。比如在分布式爬蟲系統中，使用 redis 來統一管理 url隊列。
分布式鎖：在分布式服務中。可以利用Redis的setnx功能來編寫分布式的鎖，雖然這個可能不是太常用。
當然還有諸如排行榜、點贊功能都可以使用 Redis 來實現，但是 Redis 也不是什麼都可以做，比如數據量特別大時，不適合 Redis，我們知道 Redis 是基於內存的，雖然內存很便宜，但是如果你每天的數據量特別大，比如幾億條的用戶行為日誌數據，用 Redis 來存儲的話，成本相當的高。
------------------------------------------------
緩存：這應該是 Redis 最主要的功能了，也是大型網站必備機制，合理地使用緩存不僅可以加 快數據的訪問速度，而且能夠有效地降低後端數據源的壓力。
共享Session：對於一些依賴 session 功能的服務來說，如果需要從單機變成集群的話，可以選擇 redis 來統一管理 session。
消息隊列系統：消息隊列系統可以說是一個大型網站的必備基礎組件，因為其具有業務 解耦、非實時業務削峰等特性。Redis提供了發布訂閱功能和阻塞隊列的功 能，雖然和專業的消息隊列比還不夠足夠強大，但是對於一般的消息隊列功 能基本可以滿足。比如在分布式爬蟲系統中，使用 redis 來統一管理 url隊列。
分布式鎖：在分布式服務中。可以利用Redis的setnx功能來編寫分布式的鎖，雖然這個可能不是太常用。 當然還有諸如排行榜、點贊功能都可以使用 Redis 來實現，但是 Redis 也不是什麼都可以做，比如數據量特別大時，不適合 Redis，我們知道 Redis 是基於內存的，雖然內存很便宜，但是如果你每天的數據量特別大，比如幾億條的用戶行為日誌數據，用 Redis 來存儲的話，成本相當的高。
❻ Redis資料庫在哪些場景可以應用的到
redis開創了一種新的數據存儲思路，使用redis，我們不用在面對功能單調的資料庫時，把精力放在如何把大象放進冰箱這樣的問題上，而是利用redis靈活多變的數據結構和數據操作，為不同的大象構建不同的冰箱。
redis常用數據類型
redis最為常用的數據類型主要有以下五種：
string
hash
list
set
sorted set
在具體描述這幾種數據類型之前，我們先通過一張圖了解下redis內部內存管理中是如何描述這些不同數據類型的：
首先redis內部使用一個redisobject對象來表示所有的key和value,redisobject最主要的信息如上圖所示：type代表一
個value對象具體是何種數據類型，encoding是不同數據類型在redis內部的存儲方式，比如：type=string代表value存儲的是
一個普通字元串，那麼對應的encoding可以是raw或者是int,如果是int則代表實際redis內部是按數值型類存儲和表示這個字元串的，當然
前提是這個字元串本身可以用數值表示，比如:"123"
"456"這樣的字元串。
這里需要特殊說明一下vm欄位，只有打開了redis的虛擬內存功能，此欄位才會真正的分配內存，該功能默認是關閉狀態的，該功能會在後面具體描述。通過
上圖我們可以發現redis使用redisobject來表示所有的key/value數據是比較浪費內存的，當然這些內存管理成本的付出主要也是為了給
redis不同數據類型提供一個統一的管理介面，實際作者也提供了多種方法幫助我們盡量節省內存使用，我們隨後會具體討論。
下面我們先來逐一的分析下這五種數據類型的使用和內部實現方式：
string
常用命令：
set,get,decr,incr,mget 等。
應用場景：
string是最常用的一種數據類型，普通的key/value存儲都可以歸為此類，這里就不所做解釋了。
實現方式：
string在redis內部存儲默認就是一個字元串，被redisobject所引用，當遇到incr,decr等操作時會轉成數值型進行計算，此時redisobject的encoding欄位為int。
hash
常用命令：
hget,hset,hgetall 等。
應用場景：
我們簡單舉個實例來描述下hash的應用場景，比如我們要存儲一個用戶信息對象數據，包含以下信息：
用戶id為查找的key，存儲的value用戶對象包含姓名，年齡，生日等信息，如果用普通的key/value結構來存儲，主要有以下2種存儲方式：
第一種方式將用戶id作為查找key,把其他信息封裝成一個對象以序列化的方式存儲，這種方式的缺點是，增加了序列化/反序列化的開銷，並且在需要修改其中一項信息時，需要把整個對象取回，並且修改操作需要對並發進行保護，引入cas等復雜問題。
第二種方法是這個用戶信息對象有多少成員就存成多少個key-value對兒，用用戶id+對應屬性的名稱作為唯一標識來取得對應屬性的值，雖然省去了序列化開銷和並發問題，但是用戶id為重復存儲，如果存在大量這樣的數據，內存浪費還是非常可觀的。
那麼redis提供的hash很好的解決了這個問題，redis的hash實際是內部存儲的value為一個hashmap，並提供了直接存取這個map成員的介面，如下圖：
也就是說，key仍然是用戶id,
value是一個map，這個map的key是成員的屬性名，value是屬性值，這樣對數據的修改和存取都可以直接通過其內部map的key(redis里稱內部map的key為field),
也就是通過 key(用戶id) + field(屬性標簽)
就可以操作對應屬性數據了，既不需要重復存儲數據，也不會帶來序列化和並發修改控制的問題。很好的解決了問題。
這里同時需要注意，redis提供了介面(hgetall)可以直接取到全部的屬性數據,但是如果內部map的成員很多，那麼涉及到遍歷整個內部map的
操作，由於redis單線程模型的緣故，這個遍歷操作可能會比較耗時，而另其它客戶端的請求完全不響應，這點需要格外注意。
實現方式：
上面已經說到redis
hash對應value內部實際就是一個hashmap，實際這里會有2種不同實現，這個hash的成員比較少時redis為了節省內存會採用類似一維數組的方式來緊湊存儲，而不會採用真正的hashmap結構，對應的value
redisobject的encoding為zipmap,當成員數量增大時會自動轉成真正的hashmap,此時encoding為ht。
list
常用命令：
lpush,rpush,lpop,rpop,lrange等。
應用場景：
redis
list的應用場景非常多，也是redis最重要的數據結構之一，比如twitter的關注列表，粉絲列表等都可以用redis的list結構來實現，比較好理解，這里不再重復。
實現方式：
redis
list的實現為一個雙向鏈表，即可以支持反向查找和遍歷，更方便操作，不過帶來了部分額外的內存開銷，redis內部的很多實現，包括發送緩沖隊列等也都是用的這個數據結構。
set
常用命令：
sadd,spop,smembers,sunion 等。
應用場景：
redis
set對外提供的功能與list類似是一個列表的功能，特殊之處在於set是可以自動排重的，當你需要存儲一個列表數據，又不希望出現重復數據時，set是一個很好的選擇，並且set提供了判斷某個成員是否在一個set集合內的重要介面，這個也是list所不能提供的。
實現方式：
set 的內部實現是一個
value永遠為null的hashmap，實際就是通過計算hash的方式來快速排重的，這也是set能提供判斷一個成員是否在集合內的原因。
sorted set
常用命令：
zadd,zrange,zrem,zcard等
使用場景：
redis sorted set的使用場景與set類似，區別是set不是自動有序的，而sorted
set可以通過用戶額外提供一個優先順序(score)的參數來為成員排序，並且是插入有序的，即自動排序。當你需要一個有序的並且不重復的集合列表，那麼可以選擇sorted
set數據結構，比如twitter 的public
❼ Redis資料庫適合使用於哪些應用場景
redis開創了一種新的數據存儲思路，使用redis，我們不用在面對功能單調的資料庫時，把精力放在如何把大象放進冰箱這樣的問題上，而是利用redis靈活多變的數據結構和數據操作，為不同的大象構建不同的冰箱。
redis常用數據類型
redis最為常用的數據類型主要有以下五種：
string
hash
list
set
sorted set
在具體描述這幾種數據類型之前，我們先通過一張圖了解下redis內部內存管理中是如何描述這些不同數據類型的：
首先redis內部使用一個redisobject對象來表示所有的key和value,redisobject最主要的信息如上圖所示：type代表一
個value對象具體是何種數據類型，encoding是不同數據類型在redis內部的存儲方式，比如：type=string代表value存儲的是
一個普通字元串，那麼對應的encoding可以是raw或者是int,如果是int則代表實際redis內部是按數值型類存儲和表示這個字元串的，當然
前提是這個字元串本身可以用數值表示，比如:"123"
"456"這樣的字元串。
這里需要特殊說明一下vm欄位，只有打開了redis的虛擬內存功能，此欄位才會真正的分配內存，該功能默認是關閉狀態的，該功能會在後面具體描述。通過
上圖我們可以發現redis使用redisobject來表示所有的key/value數據是比較浪費內存的，當然這些內存管理成本的付出主要也是為了給
redis不同數據類型提供一個統一的管理介面，實際作者也提供了多種方法幫助我們盡量節省內存使用，我們隨後會具體討論。
下面我們先來逐一的分析下這五種數據類型的使用和內部實現方式：
string
常用命令：
set,get,decr,incr,mget 等。
應用場景：
string是最常用的一種數據類型，普通的key/value存儲都可以歸為此類，這里就不所做解釋了。
實現方式：
string在redis內部存儲默認就是一個字元串，被redisobject所引用，當遇到incr,decr等操作時會轉成數值型進行計算，此時redisobject的encoding欄位為int。
hash
常用命令：
hget,hset,hgetall 等。
應用場景：
我們簡單舉個實例來描述下hash的應用場景，比如我們要存儲一個用戶信息對象數據，包含以下信息：
用戶id為查找的key，存儲的value用戶對象包含姓名，年齡，生日等信息，如果用普通的key/value結構來存儲，主要有以下2種存儲方式：
第一種方式將用戶id作為查找key,把其他信息封裝成一個對象以序列化的方式存儲，這種方式的缺點是，增加了序列化/反序列化的開銷，並且在需要修改其中一項信息時，需要把整個對象取回，並且修改操作需要對並發進行保護，引入cas等復雜問題。
第二種方法是這個用戶信息對象有多少成員就存成多少個key-value對兒，用用戶id+對應屬性的名稱作為唯一標識來取得對應屬性的值，雖然省去了序列化開銷和並發問題，但是用戶id為重復存儲，如果存在大量這樣的數據，內存浪費還是非常可觀的。
那麼redis提供的hash很好的解決了這個問題，redis的hash實際是內部存儲的value為一個hashmap，並提供了直接存取這個map成員的介面，如下圖：
也就是說，key仍然是用戶id,
value是一個map，這個map的key是成員的屬性名，value是屬性值，這樣對數據的修改和存取都可以直接通過其內部map的key(redis里稱內部map的key為field),
也就是通過 key(用戶id) + field(屬性標簽)
就可以操作對應屬性數據了，既不需要重復存儲數據，也不會帶來序列化和並發修改控制的問題。很好的解決了問題。
這里同時需要注意，redis提供了介面(hgetall)可以直接取到全部的屬性數據,但是如果內部map的成員很多，那麼涉及到遍歷整個內部map的
操作，由於redis單線程模型的緣故，這個遍歷操作可能會比較耗時，而另其它客戶端的請求完全不響應，這點需要格外注意。
實現方式：
上面已經說到redis
hash對應value內部實際就是一個hashmap，實際這里會有2種不同實現，這個hash的成員比較少時redis為了節省內存會採用類似一維數組的方式來緊湊存儲，而不會採用真正的hashmap結構，對應的value
redisobject的encoding為zipmap,當成員數量增大時會自動轉成真正的hashmap,此時encoding為ht。
list
常用命令：
lpush,rpush,lpop,rpop,lrange等。
應用場景：
redis
list的應用場景非常多，也是redis最重要的數據結構之一，比如twitter的關注列表，粉絲列表等都可以用redis的list結構來實現，比較好理解，這里不再重復。
實現方式：
redis
list的實現為一個雙向鏈表，即可以支持反向查找和遍歷，更方便操作，不過帶來了部分額外的內存開銷，redis內部的很多實現，包括發送緩沖隊列等也都是用的這個數據結構。
set
常用命令：
sadd,spop,smembers,sunion 等。
應用場景：
redis
set對外提供的功能與list類似是一個列表的功能，特殊之處在於set是可以自動排重的，當你需要存儲一個列表數據，又不希望出現重復數據時，set是一個很好的選擇，並且set提供了判斷某個成員是否在一個set集合內的重要介面，這個也是list所不能提供的。
實現方式：
set 的內部實現是一個
value永遠為null的hashmap，實際就是通過計算hash的方式來快速排重的，這也是set能提供判斷一個成員是否在集合內的原因。
sorted set
常用命令：
zadd,zrange,zrem,zcard等
使用場景：
redis sorted set的使用場景與set類似，區別是set不是自動有序的，而sorted
set可以通過用戶額外提供一個優先順序(score)的參數來為成員排序，並且是插入有序的，即自動排序。當你需要一個有序的並且不重復的集合列表，那麼可以選擇sorted
set數據結構，比如twitter 的public
❽ Redis在企業中都做什麼用，用大白話講，說明白了就行
Redis是由義大利人Salvatore Sanfilippo（網名：antirez）開發的一款內存高速緩存資料庫。Redis全稱為：Remote Dictionary Server（遠程數據服務），該軟體使用C語言編寫，Redis是一個key-value存儲系統，它支持豐富的數據類型，如：string、list、set、zset(sorted set)、hash。眾多語言都支持Redis，因為Redis交換數據快，所以在伺服器中常用來存儲一些需要頻繁調取的數據，這樣可以大大節省系統直接讀取磁碟來獲得數據的I/O開銷，更重要的是可以極大提升速度
拿大型網站來舉個例子，比如a網站首頁一天有100萬人訪問，其中有一個板塊為推薦新聞。要是直接從資料庫查詢，那麼一天就要多消耗100萬次資料庫請求。上面已經說過，Redis支持豐富的數據類型，所以這完全可以用Redis來完成，將這種熱點數據存到Redis（內存）中，要用的時候，直接從內存取，極大的提高了速度和節約了伺服器的開銷。
❾ redis的基本數據結構有哪些，都有什麼應用
1. String——字元串
String 數據結構是簡單的 key-value 類型，value 不僅可以是 String，也可以是數字（當數字類型用 Long
可以表示的時候encoding 就是整型，其他都存儲在 sdshdr 當做字元串）。使用 Strings 類型，可以完全實現目前 Memcached
的功能，並且效率更高。還可以享受 Redis 的定時持久化（可以選擇 RDB 模式或者 AOF 模式），操作日誌及 Replication 等功能。除了提供與
Memcached 一樣的 get、set、incr、decr 等操作外，Redis 還提供了下面一些操作：
2. Hash——字典
在 Memcached 中，我們經常將一些結構化的信息打包成 hashmap，在客戶端序列化後存儲為一個字元串的值（一般是 JSON
格式），比如用戶的昵稱、年齡、性別、積分等。這時候在需要修改其中某一項時，通常需要將字元串（JSON）取出來，然後進行反序列化，修改某一項的值，再序列化成字元串（JSON）存儲回去。簡單修改一個屬性就干這么多事情，消耗必定是很大的，也不適用於一些可能並發操作的場合（比如兩個並發的操作都需要修改積分）。而
Redis 的 Hash 結構可以使你像在資料庫中 Update 一個屬性一樣只修改某一項屬性值。
3. List——列表
List 說白了就是鏈表（redis 使用雙端鏈表實現的 List），相信學過數據結構知識的人都應該能理解其結構。使用 List
結構，我們可以輕松地實現最新消息排行等功能（比如新浪微博的 TimeLine ）。List 的另一個應用就是消息隊列，可以利用 List 的 *PUSH
操作，將任務存在 List 中，然後工作線程再用 POP 操作將任務取出進行執行。Redis 還提供了操作 List 中某一段元素的
API，你可以直接查詢，刪除 List 中某一段的元素。
4. Set——集合
Set 就是一個集合，集合的概念就是一堆不重復值的組合。利用 Redis 提供的 Set
數據結構，可以存儲一些集合性的數據。比如在微博應用中，可以將一個用戶所有的關注人存在一個集合中，將其所有粉絲存在一個集合。因為 Redis
非常人性化的為集合提供了求交集、並集、差集等操作，那麼就可以非常方便的實現如共同關注、共同喜好、二度好友等功能，對上面的所有集合操作，你還可以使用不同的命令選擇將結果返回給客戶端還是存集到一個新的集合中。
1.共同好友、二度好友
2.利用唯一性，可以統計訪問網站的所有獨立 IP
3.好友推薦的時候，根據 tag 求交集，大於某個
threshold 就可以推薦
5. Sorted Set——有序集合
和Sets相比，Sorted Sets是將 Set 中的元素增加了一個權重參數 score，使得集合中的元素能夠按 score
進行有序排列，比如一個存儲全班同學成績的 Sorted Sets，其集合 value 可以是同學的學號，而 score
就可以是其考試得分，這樣在數據插入集合的時候，就已經進行了天然的排序。另外還可以用 Sorted Sets 來做帶權重的隊列，比如普通消息的 score
為1，重要消息的 score 為2，然後工作線程可以選擇按 score 的倒序來獲取工作任務。讓重要的任務優先執行。