這篇文章主要介紹“redis的優(yōu)勢和特點有哪些”的相關(guān)知識，小編通過實際案例向大家展示操作過程，操作方法簡單快捷，實用性強，希望這篇“Redis的優(yōu)勢和特點有哪些”文章能幫助大家解決問題。
成都創(chuàng)新互聯(lián)是一家專注于網(wǎng)站建設(shè)、成都做網(wǎng)站與策劃設(shè)計,昂昂溪網(wǎng)站建設(shè)哪家好?成都創(chuàng)新互聯(lián)做網(wǎng)站,專注于網(wǎng)站建設(shè)十多年,網(wǎng)設(shè)計領(lǐng)域的專業(yè)建站公司;建站業(yè)務(wù)涵蓋:昂昂溪等地區(qū)。昂昂溪做網(wǎng)站價格咨詢:18980820575
Remote DIctionary Server(Redis) 是一個由 Salvatore Sanfilippo 寫的 key-value 存儲系統(tǒng)，是跨平臺的非關(guān)系型數(shù)據(jù)庫。
Redis 是一個開源的使用 ANSI C 語言編寫、遵守 BSD 協(xié)議、支持網(wǎng)絡(luò)、可基于內(nèi)存、分布式、可選持久性的鍵值對(Key-Value)存儲數(shù)據(jù)庫，并提供多種語言的 API。
Redis 通常被稱為數(shù)據(jù)結(jié)構(gòu)服務(wù)器，因為值（value）可以是字符串(String)、哈希(Hash)、列表(list)、集合(sets)和有序集合(sorted sets)等類型。
內(nèi)存數(shù)據(jù)庫，速度快，也支持?jǐn)?shù)據(jù)的持久化，可以將內(nèi)存中的數(shù)據(jù)保存在磁盤中，重啟的時候可以再次加載進行使用。
Redis不僅僅支持簡單的key-value類型的數(shù)據(jù)，同時還提供list，set，zset，hash等數(shù)據(jù)結(jié)構(gòu)的存儲。
Redis支持?jǐn)?shù)據(jù)的備份，即master-slave模式的數(shù)據(jù)備份。
支持事務(wù)
性能極高 – Redis能讀的速度是110000次/s,寫的速度是81000次/s 。
豐富的數(shù)據(jù)類型 – Redis支持二進制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 數(shù)據(jù)類型操作。
原子 – Redis的所有操作都是原子性的，同時Redis還支持對幾個操作合并后的原子性執(zhí)行。（事務(wù)）
豐富的特性 – Redis還支持 publish/subscribe, 通知, key 過期等等特性。
Redis有著更為復(fù)雜的數(shù)據(jù)結(jié)構(gòu)并且提供對他們的原子性操作，這是一個不同于其他數(shù)據(jù)庫的進化路徑。Redis的數(shù)據(jù)類型都是基于基本數(shù)據(jù)結(jié)構(gòu)的同時對程序員透明，無需進行額外的抽象。
Redis運行在內(nèi)存中但是可以持久化到磁盤，所以在對不同數(shù)據(jù)集進行高速讀寫時需要權(quán)衡內(nèi)存，因為數(shù)據(jù)量不能大于硬件內(nèi)存。在內(nèi)存數(shù)據(jù)庫方面的另一個優(yōu)點是，相比在磁盤上相同的復(fù)雜的數(shù)據(jù)結(jié)構(gòu)，在內(nèi)存中操作起來非常簡單，這樣Redis可以做很多內(nèi)部復(fù)雜性很強的事情。同時，在磁盤格式方面他們是緊湊的以追加的方式產(chǎn)生的，因為他們并不需要進行隨機訪問。
存儲方式 Memecache把數(shù)據(jù)全部存在內(nèi)存之中，斷電后會掛掉，數(shù)據(jù)不能超過內(nèi)存大小。 Redis有部份存在硬盤上，redis可以持久化其數(shù)據(jù)
數(shù)據(jù)支持類型 memcached所有的值均是簡單的字符串，redis作為其替代者，支持更為豐富的數(shù)據(jù)類型 ，提供list，set，zset，hash等數(shù)據(jù)結(jié)構(gòu)的存儲
使用底層模型不同 它們之間底層實現(xiàn)方式 以及與客戶端之間通信的應(yīng)用協(xié)議不一樣。 Redis直接自己構(gòu)建了VM 機制 ，因為一般的系統(tǒng)調(diào)用系統(tǒng)函數(shù)的話，會浪費一定的時間去移動和請求。
value 值大小不同：Redis 最大可以達到 512M；memcache 只有 1mb。
redis的速度比memcached快很多
Redis支持?jǐn)?shù)據(jù)的備份，即master-slave模式的數(shù)據(jù)備份。
1、完全基于內(nèi)存，絕大部分請求是純粹的內(nèi)存操作，非?？焖?。數(shù)據(jù)存在內(nèi)存中，類似于HashMap，HashMap的優(yōu)勢就是查找和操作的時間復(fù)雜度都是O(1)；
2、數(shù)據(jù)結(jié)構(gòu)簡單，對數(shù)據(jù)操作也簡單，Redis中的數(shù)據(jù)結(jié)構(gòu)是專門進行設(shè)計的；
3、采用單線程，避免了不必要的上下文切換和競爭條件，也不存在多進程或者多線程導(dǎo)致的切換而消耗 CPU，不用去考慮各種鎖的問題，不存在加鎖釋放鎖操作，沒有因為可能出現(xiàn)死鎖而導(dǎo)致的性能消耗；
4、使用多路I/O復(fù)用模型，非阻塞IO；
5、使用底層模型不同，它們之間底層實現(xiàn)方式以及與客戶端之間通信的應(yīng)用協(xié)議不一樣，Redis直接自己構(gòu)建了VM 機制 ，因為一般的系統(tǒng)調(diào)用系統(tǒng)函數(shù)的話，會浪費一定的時間去移動和請求；
6.多路 I/O 復(fù)用模型
多路I/O復(fù)用模型是利用 select、poll、epoll 可以同時監(jiān)察多個流的 I/O 事件的能力，在空閑的時候，會把當(dāng)前線程阻塞掉，當(dāng)有一個或多個流有 I/O 事件時，就從阻塞態(tài)中喚醒，于是程序就會輪詢一遍所有的流（epoll 是只輪詢那些真正發(fā)出了事件的流），并且只依次順序的處理就緒的流，這種做法就避免了大量的無用操作。
**這里“多路”指的是多個網(wǎng)絡(luò)連接，“復(fù)用”指的是復(fù)用同一個線程。**采用多路 I/O 復(fù)用技術(shù)可以讓單個線程高效的處理多個連接請求（盡量減少網(wǎng)絡(luò) IO 的時間消耗），且 Redis 在內(nèi)存中操作數(shù)據(jù)的速度非?？欤簿褪钦f內(nèi)存內(nèi)的操作不會成為影響Redis性能的瓶頸，主要由以上幾點造就了 Redis 具有很高的吞吐量。
我們首先要明白，上邊的種種分析，都是為了營造一個Redis很快的氛圍！官方FAQ表示，因為Redis是基于內(nèi)存的操作，CPU不是Redis的瓶頸，Redis的瓶頸最有可能是機器內(nèi)存的大小或者網(wǎng)絡(luò)帶寬。既然單線程容易實現(xiàn)，而且CPU不會成為瓶頸，那就順理成章地采用單線程的方案了（畢竟采用多線程會有很多麻煩?。?。
redis 127.0.0.1:6379> SET rediskey redis OK redis 127.0.0.1:6379> GET rediskey "redis"
Redis hash 是一個 string 類型的 field（字段） 和 value（值） 的映射表，hash 特別適合用于存儲對象。
Redis 中每個 hash 可以存儲 232 - 1 鍵值對（40多億）
Redis列表是簡單的字符串列表，按照插入順序排序。你可以添加一個元素到列表的頭部（左邊）或者尾部（右邊）
一個列表最多可以包含 232 - 1 個元素 (4294967295, 每個列表超過40億個元素)。
redis 127.0.0.1:6379> LPUSH rediskey redis (integer) 1 redis 127.0.0.1:6379> LPUSH rediskey MongoDB (integer) 2 redis 127.0.0.1:6379> LPUSH rediskey MySQL (integer) 3 redis 127.0.0.1:6379> LRANGE rediskey 0 10 1) "mysql" 2) "mongodb" 3) "redis"
Redis 的 Set 是 String 類型的無序集合。集合成員是唯一的，這就意味著集合中不能出現(xiàn)重復(fù)的數(shù)據(jù)。
集合對象的編碼可以是 intset 或者 hashtable。
Redis 中集合是通過哈希表實現(xiàn)的，所以添加，刪除，查找的復(fù)雜度都是 O(1)。
集合中最大的成員數(shù)為 232 - 1 (4294967295, 每個集合可存儲40多億個成員)。
redis 127.0.0.1:6379> SADD rediskey redis (integer) 1 redis 127.0.0.1:6379> SADD rediskey mongodb (integer) 1 redis 127.0.0.1:6379> SADD rediskey mysql (integer) 1 redis 127.0.0.1:6379> SADD rediskey mysql (integer) 0 redis 127.0.0.1:6379> SMEMBERS rediskey 1) "mysql" 2) "mongodb" 3) "redis"
Redis 有序集合和集合一樣也是 string 類型元素的集合,且不允許重復(fù)的成員。
不同的是每個元素都會關(guān)聯(lián)一個 double 類型的分?jǐn)?shù)。redis 正是通過分?jǐn)?shù)來為集合中的成員進行從小到大的排序。
有序集合的成員是唯一的,但分?jǐn)?shù)(score)卻可以重復(fù)。
集合是通過哈希表實現(xiàn)的，所以添加，刪除，查找的復(fù)雜度都是 O(1)。 集合中最大的成員數(shù)為 232 - 1 (4294967295, 每個集合可存儲40多億個成員)。
Redis 在 2.8.9 版本添加了 HyperLogLog 結(jié)構(gòu)。
Redis HyperLogLog 是用來做基數(shù)統(tǒng)計的算法，HyperLogLog 的優(yōu)點是，在輸入元素的數(shù)量或者體積非常非常大時，計算基數(shù)所需的空間總是固定 的、并且是很小的。
在 Redis 里面，每個 HyperLogLog 鍵只需要花費 12 KB 內(nèi)存，就可以計算接近 2^64 個不同元素的基 數(shù)。這和計算基數(shù)時，元素越多耗費內(nèi)存就越多的集合形成鮮明對比。
但是，因為 HyperLogLog 只會根據(jù)輸入元素來計算基數(shù)，而不會儲存輸入元素本身，所以 HyperLogLog 不能像集合那樣，返回輸入的各個元素。
比如數(shù)據(jù)集 {1, 3, 5, 7, 5, 7, 8}， 那么這個數(shù)據(jù)集的基數(shù)集為 {1, 3, 5 ,7, 8}, 基數(shù)(不重復(fù)元素)為5。 基數(shù)估計就是在誤差可接受的范圍內(nèi)，快速計算基數(shù)。
以下實例演示了 HyperLogLog 的工作過程：
//添加指定元素到 HyperLogLog 中。 redis 127.0.0.1:6379> PFADD rediskey "redis" 1) (integer) 1 redis 127.0.0.1:6379> PFADD rediskey "mongodb" 1) (integer) 1 redis 127.0.0.1:6379> PFADD rediskey "mysql" 1) (integer) 1 //添加指定元素到 HyperLogLog 中。 redis 127.0.0.1:6379> PFCOUNT rediskey (integer) 3
Redis 發(fā)布訂閱 (pub/sub) 是一種消息通信模式：發(fā)送者 (pub) 發(fā)送消息，訂閱者 (sub) 接收消息。
Redis 客戶端可以訂閱任意數(shù)量的頻道。
下圖展示了頻道 channel1 ， 以及訂閱這個頻道的三個客戶端 —— client2 、 client5 和 client1 之間的關(guān)系：
以下實例演示了發(fā)布訂閱是如何工作的，需要開啟兩個 redis-cli 客戶端。
在我們實例中我們創(chuàng)建了訂閱頻道名為 runoobChat:
redis 127.0.0.1:6379> SUBSCRIBE runoobChat Reading messages... (press Ctrl-C to quit) 1) "subscribe" 2) "runoobChat" 3) (integer) 1
現(xiàn)在，我們先重新開啟個 redis 客戶端，然后在同一個頻道 runoobChat 發(fā)布兩次消息，訂閱者就能接收到消息。
redis 127.0.0.1:6379> PUBLISH runoobChat "Redis PUBLISH test" (integer) 1 redis 127.0.0.1:6379> PUBLISH runoobChat "Learn redis by runoob.com" (integer) 1 # 訂閱者的客戶端會顯示如下消息 1) "message" 2) "runoobChat" 3) "Redis PUBLISH test" 1) "message" 2) "runoobChat" 3) "Learn redis by runoob.com"
gif 演示如下：
開啟本地 Redis 服務(wù)，開啟兩個 redis-cli 客戶端。
在第一個 redis-cli 客戶端輸入 SUBSCRIBE runoobChat，意思是訂閱 runoobChat 頻道。
在第二個 redis-cli 客戶端輸入 PUBLISH runoobChat “Redis PUBLISH test”往 runoobChat 頻道發(fā)送消息，這個時候在第一個 redis-cli 客戶端就會看到由第二個 redis-cli 客戶端發(fā)送的測試消息。
Redis 事務(wù)可以一次執(zhí)行多個命令， 并且?guī)в幸韵氯齻€重要的保證：
批量操作在發(fā)送 EXEC 命令前被放入隊列緩存。
收到 EXEC 命令后進入事務(wù)執(zhí)行，事務(wù)中任意命令執(zhí)行失敗，其余的命令依然被執(zhí)行。
在事務(wù)執(zhí)行過程，其他客戶端提交的命令請求不會插入到事務(wù)執(zhí)行命令序列中。
一個事務(wù)從開始到執(zhí)行會經(jīng)歷以下三個階段：
開始事務(wù)。
命令入隊。
執(zhí)行事務(wù)。
以下是一個事務(wù)的例子， 它先以 MULTI開始一個事務(wù)， 然后將多個命令入隊到事務(wù)中， 最后由 EXEC命令觸發(fā)事務(wù)， 一并執(zhí)行事務(wù)中的所有命令：
redis 127.0.0.1:6379> MULTI OK redis 127.0.0.1:6379> SET book-name "Mastering C++ in 21 days" QUEUED redis 127.0.0.1:6379> GET book-name QUEUED redis 127.0.0.1:6379> SADD tag "C++" "Programming" "Mastering Series" QUEUED redis 127.0.0.1:6379> SMEMBERS tag QUEUED redis 127.0.0.1:6379> EXEC 1) OK 2) "Mastering C++ in 21 days" 3) (integer) 3 4) 1) "Mastering Series" 2) "C++" 3) "Programming"
單個 Redis 命令的執(zhí)行是原子性的，但 Redis 沒有在事務(wù)上增加任何維持原子性的機制，所以 Redis 事務(wù)的執(zhí)行并不是原子性的。
事務(wù)可以理解為一個打包的批量執(zhí)行腳本，但批量指令并非原子化的操作，中間某條指令的失敗不會導(dǎo)致前面已做指令的回滾，也不會造成后續(xù)的指令不做。
這是官網(wǎng)上的說明 From redis docs on transactions:
It’s important to note that even when a command fails, all the other commands in the queue are processed – Redis will not stop the processing of commands.
比如：
redis 127.0.0.1:7000> multi OK redis 127.0.0.1:7000> set a aaa QUEUED redis 127.0.0.1:7000> set b bbb QUEUED redis 127.0.0.1:7000> set c ccc QUEUED redis 127.0.0.1:7000> exec 1) OK 2) OK 3) OK
如果在 set b bbb 處失敗，set a 已成功不會回滾，set c 還會繼續(xù)執(zhí)行。
Redis 腳本使用 Lua 解釋器來執(zhí)行腳本。 Redis 2.6 版本通過內(nèi)嵌支持 Lua 環(huán)境。執(zhí)行腳本的常用命令為 EVAL。
重慶分公司
重慶分公司
redis 127.0.0.1:6379> EVAL "return {KEYS[1],KEYS[2],ARGV[1],ARGV[2]}" 2 key1 key2 first second
1) "key1"
2) "key2"
3) "first"
4) "second"Redis GEO 主要用于存儲地理位置信息，并對存儲的信息進行操作，該功能在 Redis 3.2 版本新增。
Redis GEO 操作方法有：
geoadd：添加地理位置的坐標(biāo)。
geopos：獲取地理位置的坐標(biāo)。
geodist：計算兩個位置之間的距離。
georadius：根據(jù)用戶給定的經(jīng)緯度坐標(biāo)來獲取指定范圍內(nèi)的地理位置集合。
georadiusbymember：根據(jù)儲存在位置集合里面的某個地點獲取指定范圍內(nèi)的地理位置集合。
geohash：返回一個或多個位置對象的 geohash 值。
redis> GEOADD Sicily 13.361389 38.115556 "Palermo" 15.087269 37.502669 "Catania" (integer) 2 redis> GEODIST Sicily Palermo Catania "166274.1516" redis> GEORADIUS Sicily 15 37 100 km 1) "Catania" redis> GEORADIUS Sicily 15 37 200 km 1) "Palermo" 2) "Catania" redis>
Redis Stream 是 Redis 5.0 版本新增加的數(shù)據(jù)結(jié)構(gòu)。
Redis Stream 主要用于消息隊列（MQ，Message Queue），Redis 本身是有一個 Redis 發(fā)布訂閱 (pub/sub) 來實現(xiàn)消息隊列的功能，但它有個缺點就是消息無法持久化，如果出現(xiàn)網(wǎng)絡(luò)斷開、Redis 宕機等，消息就會被丟棄。
簡單來說發(fā)布訂閱 (pub/sub) 可以分發(fā)消息，但無法記錄歷史消息。
而 Redis Stream 提供了消息的持久化和主備復(fù)制功能，可以讓任何客戶端訪問任何時刻的數(shù)據(jù)，并且能記住每一個客戶端的訪問位置，還能保證消息不丟失。
Redis Stream 的結(jié)構(gòu)如下所示，它有一個消息鏈表，將所有加入的消息都串起來，每個消息都有一個唯一的 ID 和對應(yīng)的內(nèi)容：
每個 Stream 都有唯一的名稱，它就是 Redis 的 key，在我們首次使用 xadd 指令追加消息時自動創(chuàng)建。
上圖解析：
Consumer Group：消費組，使用 XGROUP CREATE 命令創(chuàng)建，一個消費組有多個消費者(Consumer)。
last_delivered_id：游標(biāo)，每個消費組會有個游標(biāo) last_delivered_id，任意一個消費者讀取了消息都會使游標(biāo) last_delivered_id 往前移動。
pending_ids：消費者(Consumer)的狀態(tài)變量，作用是維護消費者的未確認(rèn)的 id。 pending_ids 記錄了當(dāng)前已經(jīng)被客戶端讀取的消息，但是還沒有 ack (Acknowledge character：確認(rèn)字符）。
Redis是一種基于客戶端-服務(wù)端模型以及請求/響應(yīng)協(xié)議的TCP服務(wù)。這意味著通常情況下一個請求會遵循以下步驟：
客戶端向服務(wù)端發(fā)送一個查詢請求，并監(jiān)聽Socket返回，通常是以阻塞模式，等待服務(wù)端響應(yīng)。
服務(wù)端處理命令，并將結(jié)果返回給客戶端。
Redis 管道技術(shù)可以在服務(wù)端未響應(yīng)時，客戶端可以繼續(xù)向服務(wù)端發(fā)送請求，并最終一次性讀取所有服務(wù)端的響應(yīng)。
關(guān)于“Redis的優(yōu)勢和特點有哪些”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識，可以關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，小編每天都會為大家更新不同的知識點。
