redis 從0 到 1 鍵值相關命令 服務器相關命令

keys * 獲取全部的key   忽略其數據類型 數據爲空   返回(empty list or set)

keys a* 、*b 獲取以a開頭 或者 以b結尾的key 返回(empty list or set)

exists key　　判斷key是否存在   存在返回1  不存在返回0

del key 刪除key   返回 受影響key的個數

expire key seconds  設置key的過時時間 單位爲秒

persist  key   消除key的過時時間設置 

move key db  數據移動到 另外的一個數據庫中

randomkey 在當前數據庫中隨機返回一個key  若是當前數據庫沒有key 則返回nil

rename key newKey  修改key的名稱

type key  返回key的類型

----------------------------服務器相關命令

ping  是否鏈接redis  已經鏈接返回 pong  未鏈接 返回 Connection refused

echo xxxx  向命令行 輸出xxxxx

select index  選擇數據庫。 Redis 數據庫編號從 0~15，咱們能夠選擇任意一個數據庫來進行數據的存取  越界則報錯(error) ERR invalid DB index

qiut 退出當前redis-cli鏈接

dbsize  返回當前數據庫的key數目

info [參數] 獲取redis 信息  不寫參數有默認返回

一種易於解釋（parse）且易於閱讀的格式，返回關於 Redis 服務器的各類信息和統計數值。
經過給定可選的參數 section ，可讓命令只返回某一部分的信息：
server : 通常 redis 服務器信息，包含如下域：
redis_version : Redis 服務器版本
redis_git_sha1 : Git SHA1
redis_git_dirty : Git dirty flag
os : Redis 服務器的宿主操做系統
arch_bits : 架構（32 或 64 位）
multiplexing_api : Redis 所使用的事件處理機制
gcc_version : 編譯 Redis 時所使用的 GCC 版本
process_id : 服務器進程的 PID
run_id : Redis 服務器的隨機標識符（用於 Sentinel 和集羣）
tcp_port : TCP/IP 監聽端口
uptime_in_seconds : 自 Redis 服務器啓動以來，通過的秒數
uptime_in_days : 自 Redis 服務器啓動以來，通過的天數
lru_clock : 以分鐘爲單位進行自增的時鐘，用於 LRU 管理
clients : 已鏈接客戶端信息，包含如下域：
connected_clients : 已鏈接客戶端的數量（不包括經過從屬服務器鏈接的客戶端）
client_longest_output_list : 當前鏈接的客戶端當中，最長的輸出列表
client_longest_input_buf : 當前鏈接的客戶端當中，最大輸入緩存
blocked_clients : 正在等待阻塞命令（BLPOP、BRPOP、BRPOPLPUSH）的客戶端的數量
memory : 內存信息，包含如下域：
used_memory : 由 Redis 分配器分配的內存總量，以字節（byte）爲單位
used_memory_human : 以人類可讀的格式返回 Redis 分配的內存總量
used_memory_rss : 從操做系統的角度，返回 Redis 已分配的內存總量（俗稱常駐集大小）。這個值和 top 、 ps 等命令的輸出一致。
used_memory_peak : Redis 的內存消耗峯值（以字節爲單位）
used_memory_peak_human : 以人類可讀的格式返回 Redis 的內存消耗峯值
used_memory_lua : Lua 引擎所使用的內存大小（以字節爲單位）
mem_fragmentation_ratio : used_memory_rss 和 used_memory 之間的比率
mem_allocator : 在編譯時指定的， Redis 所使用的內存分配器。能夠是 libc 、 jemalloc 或者 tcmalloc 。
在理想狀況下， used_memory_rss 的值應該只比 used_memory 稍微高一點兒。
當 rss > used ，且二者的值相差較大時，表示存在（內部或外部的）內存碎片。
內存碎片的比率能夠經過 mem_fragmentation_ratio 的值看出。
當 used > rss 時，表示 Redis 的部份內存被操做系統換出到交換空間了，在這種狀況下，操做可能會產生明顯的延遲。
Because Redis does not have control over how its allocations are mapped to memory pages, high used_memory_rss is often the result of a spike in memory usage.
當 Redis 釋放內存時，分配器可能會，也可能不會，將內存返還給操做系統。
若是 Redis 釋放了內存，卻沒有將內存返還給操做系統，那麼 used_memory 的值可能和操做系統顯示的 Redis 內存佔用並不一致。
查看 used_memory_peak 的值能夠驗證這種狀況是否發生。
persistence : RDB 和 AOF 的相關信息
stats : 通常統計信息
replication : 主/從複製信息
cpu : CPU 計算量統計信息
commandstats : Redis 命令統計信息
cluster : Redis 集羣信息
keyspace : 數據庫相關的統計信息
除上面給出的這些值之外，參數還能夠是下面這兩個：
all : 返回全部信息
default : 返回默認選擇的信息
當不帶參數直接調用 INFO 命令時，使用 default 做爲默認參數。
不一樣版本的 Redis 可能對返回的一些域進行了增長或刪減。
所以，一個健壯的客戶端程序在對 INFO 命令的輸出進行分析時，應該可以跳過不認識的域，而且妥善地處理丟失不見的域。
以上內容來自http://blog.csdn.net/lang_man_xing/article/details/38539057

monitor  此命令用與監控redis 將接收到的命令 在控制檯打印出來  演示效果 secureCRT克隆一個鏈接  clone session 執行增刪 改 查

 

monitor命令監控到的命令請求

 

config set [參數]  config get [參數]   設置系統參數  獲取系統參數   實時生效  無需重啓

flushdb 刪除當前數據庫中全部的key

flushall  刪除redis 服務器上全部的key

--------------redis主從複製--------------------------

開啓另一臺 虛擬機  主機地址爲192.168.1.5  從服務器爲 192.168.1.6

在從服務器上的redis.conf文件中

設置 slaveof 192.168.1.5 6379 便可

修改後啓動 從服務器 ，出現如下信息 說明配置 成功

注意要修改主服務器的bind  IP  不然從服務器鏈接不上 將bind 0.0.0.0 表示全部網絡均可以鏈接

此時分別打開從服務器的 redis-cli   在從服務器 192.168.1.6 上 輸入monitor  用與監聽同步信息

--------------主服務器redis-cli---------------------------------------

-----------------從服務器 redis-cli監聽到的命令----------------------------------

 退出監聽器獲取name key的值

 

 查看 info + 參數 查看信息  

 

裏面有一個角色標識 ,來判斷是主庫仍是從庫 ,對於本例是一個從庫，同時還有一個
master_link_status 用於標明主從是否異步，若是此值=up，說明同步正常；若是此值=down，說明同步異步；

db0:keys=1,expires=0， 用於說明數據庫有幾個 key,以及過時 key 的數量 ；

 

---------------------簡單事物處理---------------------------------------------

redis 對事務的支持目前還比較簡單。 redis 只能保證一個 client 發起的事務中的命令能夠連
續的執行，而中間不會插入其餘 client 的命令。 因爲 redis 是單線程來處理全部 client 的請
求的因此作到這點是很容易的。通常狀況下 redis 在接受到一個 client 發來的命令後會當即
處理並 返回處理結果，可是當一個 client 在一個鏈接中發出 multi 命令有，這個鏈接會進入
一個事務上下文，該鏈接後續的命令並非當即執行，而是先放到一個隊列中。當今後鏈接
受到 exec 命令後， redis 會順序的執行隊列中的全部命令。並將全部命令的運行結果打包到
一塊兒返回給 client.而後此鏈接就 結束事務上下文。

 

--------------------樂觀鎖事物處理 ------------------------------

 樂觀鎖原理 對key 進行 版本標記（watch key） 標識這個key 是樂觀鎖  複製一個 session  

完成樂觀鎖的測試

 

----------------------持久化機制-----------------------------------

默認方式  在conf文件中的默認配置

save 900 1 #900 秒內若是超過 1 個 key 被修改，則發起快照保存
save 300 10 #300 秒內容如超過 10 個 key 被修改，則發起快照保存
save 60 10000

redis-cli端 能夠主動設置 保存快照文件到磁盤  使用 

save 或者 bgsave 命令通知 redis 作一次快照持久化。 save 操做是在主線程
中保存快照的，因爲 redis 是用一個主線程來處理全部 client 的請求，這種方式會阻塞全部
client 請求。因此不推薦使用。另外一點須要注意的是，每次快照持久化都是將內存數據完整
寫入到磁盤一次，並非增量的只同步變動數據。若是數據量大的話，並且寫操做比較多，
必然會引發大量的磁盤 io 操做，可能會嚴重影響性能

查看log日誌  設置logfile的路徑 和日誌級別 info （查看全部信息  開發模式使用）

 

 

------------------aof方式  --------------------

aof 比快照方式有更好的持久化性，是因爲在使用 aof 持久化方式時,redis 會將每個收到
的寫命令都經過 write 函數追加到文件中(默認是 appendonly.aof)。當 redis 重啓時會經過重
新執行文件中保存的寫命令來在內存中重建整個數據庫的內容

appendonly yes //啓用 aof 持久化方式
# appendfsync always //收到寫命令就當即寫入磁盤，最慢，可是保證徹底的持久化
appendfsync everysec //每秒鐘寫入磁盤一次，在性能和持久化方面作了很好的折中
# appendfsync no //徹底依賴 os，性能最好,持久化沒保證

 

 

 此方式下redis調用fork  產生 父子進程  

1-子進程根據內存中的數據庫快照，往臨時文件中寫入重建數據庫狀態的命令

2-父進程繼續處理client請求 除了把命令寫入到原來的aof文件中之外，同時把收到的命令緩存起來

4-當子進程把快照內容寫入已命令方式寫到臨時文件中後，子進程發信號通知父進程。然
後父進程把緩存的寫命令也寫入到臨時文件。
5-如今父進程可使用臨時文件替換老的 aof 文件，並重命名，後面收到的寫命令也開始
往新的 aof 文件中追加。

須要注意到是重寫 aof 文件的操做，並無讀取舊的 aof 文件，而是將整個內存中的數據庫
內容用命令的方式重寫了一個新的 aof 文件  這樣會致使文件愈來愈大   須要手動 清理

client 端  能夠執行 bgrewriteaof  命令 剔除 aof文件中重複的內容

 

----------------------------------發佈及訂閱消息 ---------------

發佈訂閱(pub/sub)是一種消息通訊模式，主要的目的是解耦消息發佈者和消息訂閱者之間的耦合訂閱者能夠經過 subscribe 和 psubscribe 命令向 redis
server 訂閱本身感興趣的消息類型， redis 將消息類型稱爲通道(channel)。當發佈者經過
publish 命令向 redis server 發送特定類型的消息時。訂閱該消息類型的所有 client 都會收到
此消息。這裏消息的傳遞是多對多的。一個 client能夠訂閱多個 channel,也能夠向多個 channel發送消息

訂閱以後 線程是阻塞狀態 意味這不能接受其餘的命令 

 

---------------Pipeline 批量發送請求  處理  --redis-jar  爲jedis-2.9.0.jar

package com.swb.redis;
import org.junit.Test;
import redis.clients.jedis.Connection;
import redis.clients.jedis.Jedis;
import redis.clients.jedis.Pipeline;
public class RedisTest {
    // 採用 pipeline 方式發送指令
    @Test
    public  void usePipeline() {
        long start = System.currentTimeMillis();
        try {
            Jedis jredis = new Jedis("192.168.1.5", 6379);
            Pipeline  pi=jredis.pipelined();
            for (int i = 0; i < 10000; i++) {
                pi.incr("test");
            }
            jredis.quit();
        } catch (Exception e) {
        }
        long end = System.currentTimeMillis();
        System.out.println("用 pipeline 方式耗時： " + (end - start) + "毫秒");
    }
    // 普通方式發送指令
    @Test
    public  void withoutPipeline() {
        long start = System.currentTimeMillis();
        try {
            Jedis jredis = new Jedis("192.168.1.5", 6379);
            for (int i = 0; i < 10000; i++) {
                jredis.incr("test");
            }
            jredis.quit();
        } catch (Exception e) {
        }

        long end = System.currentTimeMillis();
        System.out.println("用 普通方式耗時： " + (end - start) + "毫秒");
    }
    @Test
    public void testConnection(){
        this.withoutPipeline();
        this.usePipeline();
        /** 用 普通方式耗時： 2038毫秒
        用 pipeline 方式耗時： 56毫秒
        */    
    }
}

 

 

 --------------------------redis 虛擬內存---------------

vm-enabled yes #開啓 vm 功能
vm-swap-file /tmp/redis.swap #交換出來的 value 保存的文件路徑
vm-max-memory 1000000 #redis 使用的最大內存上限
vm-page-size 32 #每一個頁面的大小 32 個字節
vm-pages 134217728 #最多使用多少頁面
vm-max-threads 4 #用於執行 value 對象換入換出的工做線程數量

redis 的虛擬內存在設計上爲了保證 key 的查找速度，只會將 value 交換到 swap 文件中。所以若是是內存問題是因爲太多 value 很小的 key 形成的，那麼虛擬內存並不能解決，和操做系統同樣 redis 也是按頁面來交換對象的。 redis 規定同一個頁面只能保存一個對象。可是一個對象能夠保存在多個頁面中。在 redis 使用的內存沒超過 vm-max-memory 以前是不會交換任何 value 的。當超過最大內存限制後， redis 會選擇較過時的對象。若是兩個對象同樣過時會優先交換比較大的對象，精確的公式 swappability = age*log(size_in_memory)。對於vm-page-size 的設置應該根據本身的應用將頁面的大小設置爲能夠容納大多數對象的大小，太大了會浪費磁盤空間，過小了會形成交換文件出現碎片。對於交換文件中的每一個頁面， redis會在內存中對應一個 1bit 值來記錄頁面的空閒狀態。因此像上面配置中頁面數量(vm-pages134217728 )會佔用 16M 內存用來記錄頁面空閒狀態。 vm-max-threads 表示用作交換任務的線程數量。若是大於 0 推薦設爲服務器的 cpu 內核的數量，若是是 0 則交換過程在主線程進行