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-pages
134217728 )會占用 16M 內存用來記錄頁面空閑狀態。 vm-max-threads 表示用做交換任務的
線程數量。如果大於 0 推薦設為服務器的 cpu 內核的數量，如果是 0 則交換過程在主線程進行

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