1.修改redis.conf文件將裏面的daemonize no 改成 yes，讓服務在後臺啓動
2./usr/local/bin目錄下運行redis-server，運行拷貝出存放了自定義conf文件目錄下的redis.conf文件
例如 cd /usr/local/bin
啓動 redis-server /myredis/redis.conf
3.關閉
單實例關閉：redis-cli shutdown
多實例關閉，指定端口關閉:redis-cli -p 6379 shutdown
4.簡單測試
默認16個數據庫，類似數組下表從零開始，初始默認使用零號庫
select命令切換數據庫
dbsize查看當前數據庫的key的數量
127.0.0.1:6379> dbsize
(integer) 0
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> dbsize
(integer) 1
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> set k3 v3
OK
127.0.0.1:6379> dbsize
(integer) 3
flushdb：清空當前庫
Flushall：通殺全部庫 這個一般自己測試的玩，生產時絕對不會這樣玩的
Redis的五大數據類型 命令官方網站http://redisdoc.com/
1.String
string是redis最基本的類型，你可以理解成與Memcached一模一樣的類型，一個key對應一個value。
string類型是二進制安全的。意思是redis的string可以包含任何數據。比如jpg圖片或者序列化的對象 。
string類型是Redis最基本的數據類型，一個redis中字符串value最多可以是512M
2.Hash 類似java裏的Map
Hash（哈希）
Redis hash 是一個鍵值對集合。
Redis hash是一個string類型的field和value的映射表，hash特別適合用於存儲對象。
類似Java裏面的Map<String,Object>
3.List 列表
Redis 列表是簡單的字符串列表，按照插入順序排序。
你可以添加一個元素導列表的頭部（左邊）或者尾部（右邊）。
它的底層實際是個鏈表
4.Set 集合
Redis的Set是string類型的無序集合。它是通過HashTable實現的，
5.Sorted Set 有序集合
Redis zset 和 set 一樣也是string類型元素的集合,且不允許重複的成員。
不同的是每個元素都會關聯一個double類型的分數。
redis正是通過分數來爲集合中的成員進行從小到大的排序。
zset的成員是唯一的,但分數(score)卻可以重複。
Units單位
# Redis configuration file example.
#
# Note that in order to read the configuration file, Redis must be
# started with the file path as first argument:
#
# ./redis-server /path/to/redis.conf
# Note on units: when memory size is needed, it is possible to specify
# it in the usual form of 1k 5GB 4M and so forth:
#
# 1k => 1000 bytes
# 1kb => 1024 bytes
# 1m => 1000000 bytes
# 1mb => 1024*1024 bytes
# 1g => 1000000000 bytes
# 1gb => 1024*1024*1024 bytes
#
# units are case insensitive so 1GB 1Gb 1gB are all the same.
單位是bytes 對1GB 1Gb 1gB大小寫不敏感，都一樣
Redis持久化rdb介紹
RDB（Redis DataBase）
官網介紹
在指定的時間間隔內將內存中的數據集快照寫入磁盤，
也就是行話講的Snapshot快照，它恢復時是將快照文件直接讀到內存裏
是什麼
Redis會單獨創建（fork）一個子進程來進行持久化，會先將數據寫入到
一個臨時文件中，待持久化過程都結束了，再用這個臨時文件替換上次持久化好的文件。
整個過程中，主進程是不進行任何IO操作的，這就確保了極高的性能
如果需要進行大規模數據的恢復，且對於數據恢復的完整性不是非常敏感，那RDB方
式要比AOF方式更加的高效。RDB的缺點是最後一次持久化後的數據可能丟失。
fork
fork的作用是複製一個與當前進程一樣的進程。新進程的所有數據（變量、環境變量、程序計數器等）
數值都和原進程一致，但是是一個全新的進程，並作爲原進程的子進程
rdb 保存的是dump.rdb文件
如何觸發RDB快照
命令save或者是bgsave
Save：save時只管保存，其它不管，全部阻塞
BGSAVE：Redis會在後臺異步進行快照操作，
快照同時還可以響應客戶端請求。可以通過lastsave
命令獲取最後一次成功執行快照的時間
執行flushall命令，也會產生dump.rdb文件，但裏面是空的，無意義
如何恢復
CONFIG GET dir獲取目錄
優勢
適合大規模的數據恢復
對數據完整性和一致性要求不高
劣勢
在一定間隔時間做一次備份，所以如果redis意外down掉的話，就
會丟失最後一次快照後的所有修改
fork的時候，內存中的數據被克隆了一份，大致2倍的膨脹性需要考慮
如何停止
動態所有停止RDB保存規則的方法：redis-cli config set save ""
Redis持久化之AOF
是什麼
以日誌的形式來記錄每個寫操作，將Redis執行過的所有寫指令記錄下來(讀操作不記錄)，
只許追加文件但不可以改寫文件，redis啓動之初會讀取該文件重新構建數據，換言之，redis
重啓的話就根據日誌文件的內容將寫指令從前到後執行一次以完成數據的恢復工作
Aof保存的是appendonly.aof文件
AOF啓動/修復/恢復
正常恢復
【
修改默認的appendonly no，改爲yes
將有數據的aof文件複製一份保存到對應目錄(config get dir)
恢復：重啓redis然後重新加載
】
異常恢復
【
備份被寫壞的AOF文件
redis-check-aof --fix進行修復
恢復：重啓redis然後重新加載
】
rewrite
是什麼
【AOF採用文件追加方式，文件會越來越大爲避免出現此種情況，新增了重寫機制,
當AOF文件的大小超過所設定的閾值時，Redis就會啓動AOF文件的內容壓縮，
只保留可以恢復數據的最小指令集.可以使用命令bgrewriteaof】
重寫原理【
AOF文件持續增長而過大時，會fork出一條新進程來將文件重寫(也是先寫臨時文件最後再rename)，
遍歷新進程的內存中數據，每條記錄有一條的Set語句。重寫aof文件的操作，並沒有讀取舊的aof文件，
而是將整個內存中的數據庫內容用命令的方式重寫了一個新的aof文件，這點和快照有點類似
】
觸發機制【
Redis會記錄上次重寫時的AOF大小，默認配置是當AOF文件大小是上次rewrite後大小的一倍且文件大於64M時觸發
當然，這個nb的運維人員肯定不會設置64M，最少來個5GB
】
優勢
每修改同步：appendfsync always 同步持久化 每次發生數據變更會被立即記錄到磁盤 性能較差但數據完整性比較好
每秒同步：appendfsync everysec 異步操作，每秒記錄 如果一秒內宕機，有數據丟失
不同步：appendfsync no 從不同步
劣勢
相同數據集的數據而言aof文件要遠大於rdb文件，恢復速度慢於rdb
aof運行效率要慢於rdb,每秒同步策略效率較好，不同步效率和rdb相同
總結(Which one)
RDB持久化方式能夠在指定的時間間隔能對你的數據進行快照存儲
AOF持久化方式記錄每次對服務器寫的操作,當服務器重啓的時候會重新執行這些
命令來恢復原始的數據,AOF命令以redis協議追加保存每次寫的操作到文件末尾.
Redis還能對AOF文件進行後臺重寫,使得AOF文件的體積不至於過大
只做緩存：如果你只希望你的數據在服務器運行的時候存在,你也可以不使用任何持久化方式.
同時開啓兩種持久化方式
在這種情況下,當redis重啓的時候會優先載入AOF文件來恢復原始的數據,
因爲在通常情況下AOF文件保存的數據集要比RDB文件保存的數據集要完整.
RDB的數據不實時，同時使用兩者時服務器重啓也只會找AOF文件。那要不要只使用AOF呢？
作者建議不要，因爲RDB更適合用於備份數據庫(AOF在不斷變化不好備份)，
快速重啓，而且不會有AOF可能潛在的bug，留着作爲一個萬一的手段。
性能建議【
因爲RDB文件只用作後備用途，建議只在Slave上持久化RDB文件，而且只要15分鐘備份一次就夠了，只保留save 900 1這條規則。
如果Enalbe AOF，好處是在最惡劣情況下也只會丟失不超過兩秒數據，啓動腳本較簡單隻load自己的AOF文件就可以了。代價一是帶來了持續的IO，二是AOF rewrite的最後將rewrite過程中產生的新數據寫到新文件造成的阻塞幾乎是不可避免的。只要硬盤許可，應該儘量減少AOF rewrite的頻率，AOF重寫的基礎大小默認值64M太小了，可以設到5G以上。默認超過原大小100%大小時重寫可以改到適當的數值。
如果不Enable AOF ，僅靠Master-Slave Replication 實現高可用性也可以。能省掉一大筆IO也減少了rewrite時帶來的系統波動。代價是如果Master/Slave同時倒掉，會丟失十幾分鐘的數據，啓動腳本也要比較兩個Master/Slave中的RDB文件，載入較新的那個。新浪微博就選用了這種架構】