Redis的基本操做

打開一個 cmd 窗口 使用cd命令切換目錄到 C:\redis 運行 redis-server.exe redis.windows.conf 。

若是想方便的話，能夠把 redis 的路徑加到系統的環境變量裏，這樣就免得再輸路徑了，後面的那個 redis.windows.conf 能夠省略，若是省略，會啓用默認的。輸入以後，會顯示以下界面：

這時候另啓一個cmd窗口，原來的不要關閉，否則就沒法訪問服務端了。

切換到redis目錄下運行 redis-cli.exe -h 127.0.0.1 -p 6379 。

設置鍵值對 set myKey abc

取出鍵值對 get myKey

 

 

基本操做

NoSql概述

爲何須要NoSql

高併發讀寫

海量數據的高效率存儲和訪問

高可擴展性和高可用性

二:NoSql數據庫的四大分類

鍵值(Key-Value)存儲

列存儲

文檔數據庫

圖形數據庫

NoSql的特色

易擴展

靈活的數據模型

大數據量，高性能

高可用

Redis概述

高性能鍵值對數據庫，支持的鍵值數據類型:

字符串類型 散列類型 列表類型 集合類型 有序集合類型

Redis經常使用場景

緩存 任務隊列 網站訪問統計 數據過時處理 應用排行榜

分佈式集羣架構中的session分離

Jedis介紹

Jedis是redis 官方首選的Java客戶端開發包

http://github.com/xetorthio/jedis

Jedis-jar url

下載地址：　https://mvnrepository.com/artifact/redis.clients/jedis

#Redis 的數據結構

五種數據類型:

字符串(String) , 哈希(hash) ,字符串列表(list) , 字符串集合(set),有序字符串集合(sorted set) 
經常使用的是字符串和哈希

Key的定義注意點：

不要過長

不要太短

統一的命名規範

存儲String

經常使用命令:

賦值: set company imooc ,取值就能夠經過 get company 得到 imooc

getset命令: getset company baidu 結果:imooc 而後 get company 結果: baidu .getset key value 就是先得到key後更改value

刪除 del key ,好比: 先設置 key 和value set person jack ，del person 返回數字1,若是再去得到get person 結果: nil 表明不存在

擴展命令

取值

數值增減

遞增 incr num 默認就是0，而get num 的結果就是 1 。

同理 decr num2 默認也是0 而get num 的結果即便 -1 。

incrby num 5 就是經過 num+5的結果。通常num默認是0，如今應該就是5

同理decrby num2 5 結果就是-5

存儲Hash

String key和value的map容器

每個Hash能夠存儲4294967295個鍵值對

hset key field value 命令:

例子:

賦值 
hset myhash username jack

hset myhash age 18

其中 myhash 就是key 而username 和age都是字段名稱，然後面的值局勢字段裏的值。這和map的集合有一點區別

hset myhash2 username jack age 18

刪除： hdel myhash2 結果就是: empty list or set

若是在接着去刪除 hdel myhash2 username 結果 0 
刪除沒有的字段就返回0

存儲list:

ArrayList使用數組方式

LinkedList使用雙向連接方式

雙向鏈表中增長數據

雙向鏈表中刪除數據

存儲list經常使用命令:

兩端添加 查看列表 兩端彈出 獲取列表元素個數 擴展命令

命令: lpush key value[value] 
lpush mylist3 a b c 1 2 3

命令: lrange key start stop 
取出: lrange mylist3 0 5 結果就是 3 2 1 c b a 這和java 中list集合有一點區別 
固然也能夠這樣取值 lrange mylist3 0 -1 ，結果和上面仍是同樣的。0表明第一個元素，而-1 表明最後一個元素

命令： 
lpop key 移出並獲取列表的第一個元素

llen key 獲取列表長度

rpop key 移出並獲取列表的最後一個元素

lpush key value 插入到已存在列表頭部，

rpush key value 插入到已存在列表尾部

lpushx key value 同理也是插入到列表頭部

rpushx key value 同理也是插入到列表尾部

lpushx mylist3 x ，經過查看 lrange mylist 0 -1 得 x 3 2 1 a b c

存儲set

和list類型不一樣的是,set集合中不容許出現重複的元素

set可包含的最大元素數量是4294967295

存儲set經常使用命令

添加/刪除元素 得到集合中的元素 擴展命令

集合中的差集運算 集合中的交集運算 集合中並集運算

元素添加:

sadd myset a b c 結果爲 3

sadd myset a 結果爲0

sadd myset 1 2 3

刪除元素 ：

srem myset 1 2 結果就是: a b 3 c

判斷元素是否存在 
sismember myset a 存在返回 1 不存在就返回0

差集運算: sdiff key[key]

交集運算 sinner key [key ]

顯示集合中全部的元素 SMEMBERS key

顯示集合中成員數量 SCARD key

返回集合中的一個或多個成員 srandmember key[count]

存儲Set使用場景

跟蹤一些惟一性數據

用於維護數據對象之間的關聯關係

Redis的Keys的經過操做

keys * 查看全部的key 
del my1 my2 my3 刪除某些key

exists my1 查看key是否存在 返回0是存在，1不存在

rename company newcompany 重命名爲newcompany

expire key 1000 爲key設置過時時間

TTL key 
以秒爲單位，返回給定 key 的剩餘生存時間(TTL, time to live)。

Redis特性

相關特性

多數據庫

redis事務

多數據: 
默認是0號數據庫

select 0 ，固然也能夠移動數據庫 move myset 1 就是將0中的myset移動到myset

MULTI 
標記一個事務塊的開始。

EXEC 
執行全部事務塊內的命令。

DISCARD 
取消事務，放棄執行事務塊內的全部命令。

Redis持久化

RDB方式

AOF方式

持久化使用方式: 
RDB持久化 AOF持久化 無持久化 同時使用RDB和AOF

RDB

優點:

RDB 是一個很是緊湊（compact）的文件，它保存了 Redis 在某個時間點上的數據集。 這種文件很是適合用於進行備份： 好比說，你能夠在最近的 24 小時內，每小時備份一次 RDB 文件，而且在每月的每一天，也備份一個 RDB 文件。 這樣的話，即便趕上問題，也能夠隨時將數據集還原到不一樣的版本。RDB 很是適用於災難恢復（disaster recovery）：它只有一個文件，而且內容都很是緊湊，能夠（在加密後）將它傳送到別的數據中心，或者亞馬遜 S3 中。RDB 能夠最大化 Redis 的性能：父進程在保存 RDB 文件時惟一要作的就是 fork 出一個子進程，而後這個子進程就會處理接下來的全部保存工做，父進程無須執行任何磁盤 I/O 操做。RDB 在恢復大數據集時的速度比 AOF 的恢復速度要快

劣勢:

若是你須要儘可能避免在服務器故障時丟失數據，那麼 RDB 不適合你。 雖然 Redis 容許你設置不一樣的保存點（save point）來控制保存 RDB 文件的頻率， 可是， 由於RDB 文件須要保存整個數據集的狀態， 因此它並非一個輕鬆的操做。 所以你可能會至少 5 分鐘才保存一次 RDB 文件。 在這種狀況下， 一旦發生故障停機， 你就可能會丟失好幾分鐘的數據。每次保存 RDB 的時候，Redis 都要 fork() 出一個子進程，並由子進程來進行實際的持久化工做。 在數據集比較龐大時， fork() 可能會很是耗時，形成服務器在某某毫秒內中止處理客戶端； 若是數據集很是巨大，而且 CPU 時間很是緊張的話，那麼這種中止時間甚至可能會長達整整一秒。 雖然 AOF 重寫也須要進行 fork() ，但不管 AOF 重寫的執行間隔有多長，數據的耐久性都不會有任何損失

AOF

優點:

使用 AOF 持久化會讓 Redis 變得很是耐久（much more durable）：你能夠設置不一樣的 fsync 策略，好比無 fsync ，每秒鐘一次 fsync ，或者每次執行寫入命令時 fsync 。 AOF 的默認策略爲每秒鐘 fsync 一次，在這種配置下，Redis 仍然能夠保持良好的性能，而且就算髮生故障停機，也最多隻會丟失一秒鐘的數據（ fsync 會在後臺線程執行，因此主線程能夠繼續努力地處理命令請求）。AOF 文件是一個只進行追加操做的日誌文件（append only log）， 所以對 AOF 文件的寫入不須要進行 seek ， 即便日誌由於某些緣由而包含了未寫入完整的命令（好比寫入時磁盤已滿，寫入中途停機，等等）， redis-check-aof 工具也能夠輕易地修復這種問題。 
Redis 能夠在 AOF 文件體積變得過大時，自動地在後臺對 AOF 進行重寫： 重寫後的新 AOF 文件包含了恢復當前數據集所需的最小命令集合。 整個重寫操做是絕對安全的，由於 Redis 在建立新 AOF 文件的過程當中，會繼續將命令追加到現有的 AOF 文件裏面，即便重寫過程當中發生停機，現有的 AOF 文件也不會丟失。 而一旦新 AOF 文件建立完畢，Redis 就會從舊 AOF 文件切換到新 AOF 文件，並開始對新 AOF 文件進行追加操做。AOF 文件有序地保存了對數據庫執行的全部寫入操做， 這些寫入操做以 Redis 協議的格式保存， 所以 AOF 文件的內容很是容易被人讀懂， 對文件進行分析（parse）也很輕鬆。 導出（export） AOF 文件也很是簡單： 舉個例子， 若是你不當心執行了 FLUSHALL 命令， 但只要 AOF 文件未被重寫， 那麼只要中止服務器， 移除 AOF 文件末尾的 FLUSHALL 命令， 並重啓 Redis ， 就能夠將數據集恢復到 FLUSHALL 執行以前的狀態。

劣勢: 
對於相同的數據集來講，AOF 文件的體積一般要大於 RDB 文件的體積。根據所使用的 fsync 策略，AOF 的速度可能會慢於 RDB 。 在通常狀況下， 每秒 fsync 的性能依然很是高， 而關閉 fsync 可讓 AOF 的速度和 RDB 同樣快， 即便在高負荷之下也是如此。 不過在處理巨大的寫入載入時，RDB 能夠提供更有保證的最大延遲時間（latency）。AOF 在過去曾經發生過這樣的 bug ： 由於個別命令的緣由，致使 AOF 文件在從新載入時，沒法將數據集恢復成保存時的原樣。 （舉個例子，阻塞命令 BRPOPLPUSH 就曾經引發過這樣的 bug 。） 測試套件裏爲這種狀況添加了測試： 它們會自動生成隨機的、複雜的數據集， 並經過從新載入這些數據來確保一切正常。 雖然這種 bug 在 AOF 文件中並不常見， 可是對比來講， RDB 幾乎是不可能出現這種 bug 的。