溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
因為redis速度相當快，所以在一臺比較好的服務器下，一個外部用戶在一秒內可以進行15W次的密碼嘗試，這意味著需要設定非常強大的密碼來防止暴力破解。
可以通過設置密碼以及登錄redis方式來操作，具體參考
1、Master可以擁有多個slave。
2、多個slave可以連接同一個master外，還可以連接到其他的slave。
3、主從復制不會阻塞master，在同步數據時，master可以繼續處理client請求。
4、提供系統的伸縮性。
1、slave與master建立連接，發送sync同步命令。
2、master會開啟一個后臺進程，將數據庫快照保存到文件中，同時master主進程會開始收集新的寫命令并緩存。
3、master后臺完成保存后，就把文件發送給slave。
4、slave將接收到的master文件保存到磁盤上。
#現在使用同一臺機器的不同配置模擬主從復制場景。 root@redis conf]# pwd /application/redis/conf [root@redis conf]# ls appendonly.aof dump.rdb redis.conf [root@redis conf]# cd .. [root@redis redis]# cp -a conf conf-slave #下述為從節點 [root@redis redis]# cd conf-slave/ [root@redis conf-slave]# ls appendonly.aof dump.rdb redis.conf #設置從節點端口 port 6380 #設置從節點中的文件名和路徑配置為XX-slave的形式 logfile /application/redis/logs/redis-slave.log dir /application/redis/conf-slave/ #配置主節點的IP和端口 slaveof 10.0.0.11 6379 #配置主節點的密碼(redis4.0主節點的redis.conf也要配置) masterauth redis #設置防火墻關閉狀態 [root@redis conf-slave]# /etc/init.d/iptables stop [root@redis conf-slave]# /etc/init.d/iptables status iptables: Firewall is not running. #可使用info查看role角色，即可知道是主服務或從服務。
#主節點 [root@redis ~]# redis-server/application/redis/conf/redis.conf [root@redis ~]# lsof -i:6379 COMMAND PIDUSER FD TYPE DEVICE SIZE/OFF NODE NAME redis-ser 2456 root 4u IPv6 16205 0t0 TCP *:6379 (LISTEN) redis-ser 2456 root 5u IPv4 16207 0t0 TCP *:6379 (LISTEN) [root@redis ~]# cd /application/redis/logs/ [root@redis logs]# ll total 1780 -rw-r--r-- 1 root root 1751493 Dec 8 02:09 redis.log -rw-r--r-- 1 root root 59765 Dec 8 02:09 redis-slave.log [root@redis logs]# tailf redis.log 2456:M 08 Dec 02:08:46.338 - Accepted 10.0.0.11:17586 2456:M 08 Dec 02:08:47.345 - Accepted 10.0.0.11:17587 2456:M 08 Dec 02:08:48.352 - Accepted 10.0.0.11:17588 2456:M 08 Dec 02:08:49.076 - 0 clients connected (0slaves), 758544 bytes in use #從節點 [root@redis ~]# redis-server/application/redis/conf-slave/redis.conf [root@redis ~]# lsof -i:6380 COMMAND PIDUSER FD TYPE DEVICE SIZE/OFF NODE NAME redis-ser 2460 root 4u IPv6 16216 0t0 TCP *:6380 (LISTEN) redis-ser 2460 root 5u IPv4 16218 0t0 TCP *:6380 (LISTEN) [root@redis ~]# cd /application/redis/logs/ [root@redis logs]# ll total 1724 -rw-r--r-- 1 root root 1741206 Dec 8 02:06 redis.log -rw-r--r-- 1 root root 15808 Dec 8 02:06 redis-slave.log #從節點日志如果出現下述情況的話，那么需要把redis.conf文件中的bind 127.0.0.1注釋掉。這種情況在多臺機器中會出現，現在單臺機器模擬是不會出現的，因為redis采用的安全策略是默認只允許本地訪問，所以現在在同一臺機器中測試就不用注釋掉，redis.conf的具體參數參考“4、3、4redis.conf文件配置說明”。 [root@redis logs]# tailf redis-slave.log 2460:S 08 Dec 02:09:49.164 # Error condition on socketfor SYNC: Broken pipe 2460:S 08 Dec 02:09:50.168 - 0 clients connected (0slaves), 758544 bytes in use 2460:S 08 Dec 02:09:50.180 * Connecting to MASTER10.0.0.11:6379 2460:S 08 Dec 02:09:50.181 * MASTER <-> SLAVE syncstarted 2460:S 08 Dec 02:09:50.181 * Non blocking connect forSYNC fired the event. #可以發現從節點沒有連接成功，那么需要設置從節點對應的redis.conf文件的bind值。 [root@redis conf-slave]# lsof -i:6380 COMMAND PIDUSER FD TYPE DEVICE SIZE/OFF NODE NAME redis-ser 2460 root 4u IPv6 16216 0t0 TCP *:6380 (LISTEN) redis-ser 2460 root 5u IPv4 16218 0t0 TCP *:6380 (LISTEN) [root@redis conf-slave]# redis-cli -a shutdown -p 6380shutdown [root@redis conf-slave]# lsof -i:6380 [root@redis conf-slave]# pwd /application/redis/conf-slave bind 127.0.0.1 #主節點設置值 [root@redis ~]# redis-cli -a redis -p 6379 127.0.0.1:6379> keys * (empty list or set) 127.0.0.1:6379> set name nameval OK 127.0.0.1:6379> get name "nameval" [root@redis logs]# pwd /application/redis/logs [root@redis logs]# tailf redis.log 2506:M 08 Dec 02:21:33.242 - Accepted 127.0.0.1:36324 2506:M 08 Dec 02:21:33.584 - 1 clients connected (1slaves), 1848864 bytes in use 2506:M 08 Dec 02:21:38.616 - DB 0: 1 keys (0 volatile) in4 slots HT. 127.0.0.1:6379> del name (integer) 1 127.0.0.1:6379> keys * 1) "name2" #從節點獲取值 [root@redis ~]# redis-cli -a redis -p 6380 127.0.0.1:6380> keys * (empty list or set) 127.0.0.1:6380> keys * 1) "name" 127.0.0.1:6380> get name "nameval" 2512:S 08 Dec 02:19:28.089 * Background AOF rewritefinished successfully 2512:S 08 Dec 02:19:28.089 - Background AOF rewritesignal handler took 236us 2512:S 08 Dec 02:19:32.915 - 1 clients connected (0slaves), 779440 bytes in use 2512:S 08 Dec 02:21:38.716 - DB 0: 1 keys (0 volatile) in4 slots HT. 2512:S 08 Dec 02:21:38.717 - 2 clients connected (0slaves), 800536 bytes in use
#注意從節點是沒有寫操作的，只有讀操作
127.0.0.1:6380> del name (error) READONLY You can't write against a read onlyslave. 127.0.0.1:6380> keys * 1) "name2" #通過監控查看 #主節點做監控 [root@redis logs]# redis-cli -a redis -p 6379 monitor OK 127.0.0.1:6379> flushall OK 127.0.0.1:6379> keys * (empty list or set) [root@redis logs]# redis-cli -a redis -p 6379 monitor OK 1481135598.941742 [0 127.0.0.1:36324]"flushall" 1481135634.460910 [0 127.0.0.1:36324]"keys""*" 127.0.0.1:6379> set name nameval OK 127.0.0.1:6379> get name "nameval" [root@redis logs]# redis-cli -a redis -p 6379 monitor OK 1481135697.418957 [0 127.0.0.1:36324]"set""name""nameval" 1481135698.642795 [0 127.0.0.1:36324]"get""name" #從節點做監控 [root@redis conf-slave]# redis-cli -a redis -p 6380monitor OK 127.0.0.1:6380> keys * (empty list or set) [root@redis conf-slave]# redis-cli -a redis -p 6380monitor OK 1481135598.306657 [0 10.0.0.11:6379] "PING" 1481135598.947041 [0 10.0.0.11:6379] "flushall" 1481135608.370998 [0 10.0.0.11:6379] "PING" 1481135618.428639 [0 10.0.0.11:6379] "PING" 1481135628.493744 [0 10.0.0.11:6379] "PING" 1481135638.562807 [0 10.0.0.11:6379] "PING" 1481135648.730527 [0 10.0.0.11:6379] "PING" 1481135658.800544 [0 10.0.0.11:6379] "PING" 1481135663.809136 [0 127.0.0.1:62476]"keys""*" 1481135668.860633 [0 10.0.0.11:6379] "PING" [root@redis conf-slave]# redis-cli -a redis -p 6380monitor OK 1481135688.972458 [0 10.0.0.11:6379] "PING" 1481135697.422176 [0 10.0.0.11:6379]"set""name""nameval" 1481135699.036100 [0 10.0.0.11:6379] "PING" 127.0.0.1:6380> keys * 1) "name" 127.0.0.1:6380> get name "nameval" [root@redis conf-slave]# redis-cli -a redis -p 6380monitor OK 1481135747.385987 [0 127.0.0.1:62476]"keys""*" 1481135749.378369 [0 10.0.0.11:6379] "PING" 1481135750.203089 [0 127.0.0.1:62476]"get""name" 1481135759.444582 [0 10.0.0.11:6379] "PING"
#主節點 127.0.0.1:6379> info Replication # Replication role:master connected_slaves:1 slave0:ip=127.0.0.1,port=6380,state=online,offset=2256,lag=0 master_repl_offset:2256 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:2 repl_backlog_histlen:2255 # Replication是通過info查看節點信息中的一部分 #從節點 127.0.0.1:6380> info Replication # Replication role:slave master_host:10.0.0.11 master_port:6379 master_link_status:up master_last_io_seconds_ago:6 master_sync_in_progress:0 slave_repl_offset:2326 slave_priority:100 slave_read_only:1 connected_slaves:0 master_repl_offset:0 repl_backlog_active:0 repl_backlog_size:1048576 repl_backlog_first_byte_offset:0 repl_backlog_histlen:0
有了主從復制以后，如果想對主從復制服務器進行監控，那么在redis2.6以后提供了一個“哨兵”的機制，在2.6版本中的哨兵為1.0版本并不穩定，會出現各種各種的問題，在redis2.8版本以后的哨兵功能才穩定起來。
顧名思義，哨兵的含義就是監控redis系統的運行狀況，其功能主要有兩點：
監控主數據庫和從數據庫是否正常運行。
2、主數據庫出現故障時，可以自動將從數據庫轉換為主數據庫，實現自動切換。
一個節點可以被多個哨兵去監控。哨兵跟所有redis節點是沒有直接關系的，哨兵只是一個監控程序而已。
(可以使用keepalived(配合nginx使用)代替哨兵，實現高可用。)
#(只配主節點即可)
#配置sentinel.conf
[root@redis redis-3.2.5]# pwd /home/lly/tools/redis-3.2.5 #拷貝到從節點目錄下 [root@redis redis-3.2.5]# cp sentinel.conf/application/redis/conf-slave/ [root@redis redis-3.2.5]# cp /application/redis/conf-slave/sentinel.conf/application/redis/conf-slave/sentinel.conf.ori [root@redis redis-3.2.5]# vim/application/redis/conf-slave/sentinel.conf sentinel monitor mymaster 127.0.0.1 6379 1 #名稱，IP，端口，投票選舉次數建議為1，多臺機器記得設置master的內網IP（內部系統交互用內網IP，外部訪問提供外網IP）。 sentinel down-after-milliseconds mymaster 5000 #設置5000毫秒檢測一次，默認1秒 sentinel failover-timeout mymaster 900000 sentinel parallel-syncs mymaster 2 sentinel auth-pass mymaster redis #主節點密碼（節點redis.conf中未配置密碼，那么此步省略）
#測試第一步
#啟動哨兵模式，注意下面的命令中不要加-a redis –p 6380 [root@redis conf-slave]# redis-server sentinel.conf--sentinel & [root@redis ~]# lsof -i:26379 COMMAND PIDUSER FD TYPE DEVICE SIZE/OFF NODE NAME redis-ser 2650 root 4u IPv6 19430 0t0 TCP *:26379 (LISTEN) redis-ser 2650 root 5u IPv4 19432 0t0 TCP *:26379 (LISTEN) #查看哨兵相關信息 [root@redis ~]# redis-cli -p 26379 info Sentinel # Sentinel sentinel_masters:1 sentinel_tilt:0 sentinel_running_scripts:0 sentinel_scripts_queue_length:0 sentinel_simulate_failure_flags:0 master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=1,sentinels=1 #主節點日志 [root@redis ~]# tailf /application/redis/logs/redis.log 1481137928.553897 [0 127.0.0.1:36329] "PING" 1481137929.589836 [0 127.0.0.1:36329] "PING" 1481137929.763963 [0 127.0.0.1:36329]"PUBLISH""__sentinel__:hello""127.0.0.1,26379,a14563baa663afc1c2e06ee3cb07f222c220fd7b,0,mymaster,127.0.0.1,6379,0"
#測試第二步
#關閉主節點 [root@redis ~]# redis-cli -a redis -p 6379 shutdown #從節點日志 [root@redis conf-slave]# tailf/application/redis/logs/redis-slave.log 2574:S 08 Dec 03:15:16.629 * MASTER <-> SLAVE syncstarted 2574:S 08 Dec 03:15:16.629 # Error condition on socketfor SYNC: Connection refused 2574:M 08 Dec 03:15:17.016 * Discarding previously cachedmaster state. 2574:M 08 Dec 03:15:17.016 * MASTER MODE enabled (userrequest from 'id=5 addr=127.0.0.1:62481 fd=7 name=sentinel-a14563ba-cmd age=320idle=0 flags=x db=0 sub=0 psub=0 multi=3 qbuf=0 qbuf-free=32768 obl=36 oll=0omem=0 events=r cmd=exec') 2574:M 08 Dec 03:15:17.020 # CONFIG REWRITE executed withsuccess. 2574:M 08 Dec 03:15:17.048 * 1 changes in 900 seconds.Saving... 2574:M 08 Dec 03:15:17.050 * Background saving started bypid 2712 2712:C 08 Dec 03:15:17.067 * DB saved on disk 2712:C 08 Dec 03:15:17.068 * RDB: 6 MB of memory used bycopy-on-write 2574:M 08 Dec 03:15:17.150 * Background saving terminatedwith success 2574:M 08 Dec 03:15:17.980 - Client closed connection 2574:M 08 Dec 03:15:17.981 - Client closed connection 2574:M 08 Dec 03:15:18.069 - Accepted 127.0.0.1:62499 2574:M 08 Dec 03:15:18.070 - Accepted 127.0.0.1:62500 2574:M 08 Dec 03:15:20.671 - DB 0: 1 keys (0 volatile) in4 slots HT. 2574:M 08 Dec 03:15:20.672 - 2 clients connected (0slaves), 800816 bytes in use 2574:M 08 Dec 03:15:25.705 - DB 0: 1 keys (0 volatile) in4 slots HT. 2574:M 08 Dec 03:15:25.705 - 2 clients connected (0slaves), 800800 bytes in use #查看此時的哨兵信息 [root@redis ~]# redis-cli -p 26379 info Sentinel # Sentinel sentinel_masters:1 sentinel_tilt:0 sentinel_running_scripts:0 sentinel_scripts_queue_length:0 sentinel_simulate_failure_flags:0 master0:name=mymaster,status=ok,address=127.0.0.1:6380,slaves=1,sentinels=1 #原從節點info信息（現在是主節點） 127.0.0.1:6380> info Replication # Replication role:master connected_slaves:0 master_repl_offset:0 repl_backlog_active:0 repl_backlog_size:1048576 repl_backlog_first_byte_offset:0 repl_backlog_histlen:0 #原主節點info信息（現在是從節點） 127.0.0.1:6379> info Replication Could not connect to Redis at 127.0.0.1:6379: Connectionrefused not connected>
#測試第三步
#啟動原主節點（現在是從節點） [root@redis ~]# redis-server/application/redis/conf/redis.conf #查看哨兵切換日志，從節點切換到了原主節點6379 [root@redis conf-slave]# redis-server sentinel.conf--sentinel & 2650:X 08 Dec 03:15:17.980 #+failover-end master mymaster 127.0.0.1 6379 2650:X 08 Dec 03:15:17.980 #+switch-master mymaster 127.0.0.1 6379 127.0.0.1 6380 2650:X 08 Dec 03:15:17.981 *+slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380 2650:X 08 Dec 03:18:07.759 *+convert-to-slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380 #原主節點日志（現在是從節點） [root@redis ~]# tailf /application/redis/logs/redis.log 2574:M 08 Dec 03:18:08.674 * Background saving terminatedwith success 2574:M 08 Dec 03:18:08.679 * Synchronization with slave127.0.0.1:6379 succeeded 2574:M 08 Dec 03:18:11.903 - DB 0: 1 keys (0 volatile) in4 slots HT. 2574:M 08 Dec 03:18:11.903 - 3 clients connected (1slaves), 1891152 bytes in use 2574:M 08 Dec 03:18:16.932 - DB 0: 1 keys (0 volatile) in4 slots HT. 2574:M 08 Dec 03:18:16.932 - 3 clients connected (1slaves), 1891136 bytes in use #原主節點info信息（現在是從節點）變成從節點信息 not connected> info Replication # Replication role:slave master_host:127.0.0.1 master_port:6380 master_link_status:up master_last_io_seconds_ago:0 master_sync_in_progress:0 slave_repl_offset:2061 slave_priority:100 slave_read_only:1 connected_slaves:0 master_repl_offset:0 repl_backlog_active:0 repl_backlog_size:1048576 repl_backlog_first_byte_offset:0 repl_backlog_histlen:0 #原從節點info信息（現主節點），變成了主節點信息 127.0.0.1:6380> info Replication # Replication role:master connected_slaves:1 slave0:ip=127.0.0.1,port=6379,state=online,offset=5736,lag=0 master_repl_offset:5736 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:2 repl_backlog_histlen:5735
首先是使用multi打開事務，然后進行設置，這時設置的數據都會放入隊列里進行保存，最后使用exec執行，把數據依次存儲到redis中，可以使用discard方法取消事務。
#multi 標記一個事務塊的開始。隨后的指令將在執行EXEC時作為一個原子執行。 返回值 simple-string-reply: 始終為OK #exec 執行事務中所有在排隊等待的指令并將鏈接狀態恢復到正常當使用WATCH 時，只有當被監視的鍵沒有被修改，且允許檢查設定機制時，EXEC會被執行 返回值 multi-bulk-reply: 每個元素與原子事務中的指令一一對應當使用WATCH時，如果被終止，EXEC 則返回一個空的應答集合 #discard 刷新一個事務中所有在排隊等待的指令，并且將連接狀態恢復到正常。 如果已使用WATCH，DISCARD將釋放所有被WATCH的key。 返回值 status-reply：所有返回都是 OK #watch(鎖定key，直到執行了multi/exec命令) 標記所有指定的key 被監視起來，在事務中有條件的執行（樂觀鎖）。 返回值 simple-string-reply: 總是 OK。 #unwatch(取消事務命令) 刷新一個事務中已被監視的所有key。 如果執行EXEC 或者DISCARD， 則不需要手動執行UNWATCH 。 返回值 simple-string-reply: 總是 OK。 127.0.0.1:6379> keys * 1) "age" 127.0.0.1:6379> get age "11" 127.0.0.1:6379> multi OK 127.0.0.1:6379> incr age QUEUED 127.0.0.1:6379> exec 1) (integer) 12 127.0.0.1:6379> get age "12" 127.0.0.1:6379> multi OK 127.0.0.1:6379> incr age QUEUED 127.0.0.1:6379> discard OK 127.0.0.1:6379> get age "12" 127.0.0.1:6379> keys * 1) "age" 127.0.0.1:6379> get age "13" 127.0.0.1:6379> multi OK 127.0.0.1:6379> incr age QUEUED 127.0.0.1:6379> get age QUEUED 127.0.0.1:6379> exec 1) (integer) 14 2) "14" 127.0.0.1:6379> unwatch OK 127.0.0.1:6379> get age "14" 127.0.0.1:6379> get age "14" 127.0.0.1:6379> multi OK 127.0.0.1:6379> incr age QUEUED 127.0.0.1:6379> unwatch QUEUED 127.0.0.1:6379> get age QUEUED 127.0.0.1:6379> exec 1) (integer) 15 2) OK 3) "15" 127.0.0.1:6379> watch age OK 127.0.0.1:6379> multi OK 127.0.0.1:6379> incr age QUEUED 127.0.0.1:6379> unwatch QUEUED 127.0.0.1:6379> discard OK 127.0.0.1:6379> get age "15"
Redis的事務不能保證同時成功或失敗進行提交或回滾，所以redis的事務目前還是比較簡單的（程序中一般是不會使用redis事務的）。
127.0.0.1:6379> keys * 1) "age" 127.0.0.1:6379> get age "15" 127.0.0.1:6379> set name nameval OK 127.0.0.1:6379> multi OK 127.0.0.1:6379> incr age QUEUED #注意incr name并沒報錯，是在執行exec命令時報錯，這個incr命令在java中調用是報錯的。 127.0.0.1:6379> incr name QUEUED #下述雖然報錯，但是事務已提交，name沒有改變。如果下述執行discard命令中斷事務的話，對所有的值都不會有影響。 127.0.0.1:6379> exec 1) (integer) 16 2) (error) ERR value is not an integer or out of range 127.0.0.1:6379> get age "16" 127.0.0.1:6379> get name "nameval"
Redis是一個支持持久化的內存數據庫，也就是說redis需要經常將內存中的數據同步到硬盤來保證持久化。Redis持久化的方式有以下兩種。
snapshotting(快照)默認方式，將內存中以快照的方式寫入到二進制文件中，默認為dump.rdb，可以通過配置設置自動做快照持久化的方式，我們可以配置redis在N秒內如果超過M個key修改，那么就自動做快照。
快照設置：
save 900 1 #900秒內如果超過1個key被修改，則發起快照保存。下述同理。
save 300 10
save 60 10000
append-only file(縮寫aof)的方式(有點類似于oracle日志)，由于快照方式是在一定時間間隔做一次，所以可能發生redis意外down的清苦康就會丟失最后一次快照后的所有修改的數據，aof比快照方式有更好的持久化性，是由于在使用aof時，redis會將每一個收到的寫命令都通過write函數追加到命令中，當redis重啟啟動時會重新執行文件中保存的寫命令來在內存中重建這個數據庫的內容。Aof文件不是立即寫到磁盤上，可以通過配置文件修改強制寫到硬盤中。
aof設置：
# appendonly yes //啟動aof持久化方式有三種修改方式。
# appendfsync always //受到寫命令就立即寫入到磁盤中，效率最慢，但是保證完全的持久化。（比如頁面寫入慢，可能就是這種造成的，可加服務器處理）
# appendfsync everysec //每秒鐘寫入磁盤一次，在性能和持久化方面做了很好的折中。
# appendfsync no //完全依賴操作系統，性能最好，不進行同步，系統去操作，持久化沒保證。
RDB文件和AOF文件只開其中一種即可
上述內容都是在redis.conf文件中配置的，redis.conf的參數解釋詳情參考“4、3、4redis.conf配置文件說明”。
Redis提供了簡單的發布訂閱功能。
使用subscribe [頻道] 進行訂閱監聽。
使用publish [頻道] [發布內容] 進行發布消息廣播。
為了解耦發布者(publisher)和訂閱者(subscribe)之間的關系，redis使用了channel(頻道)作為兩者的中介，發布者將信息直接發布給channel，而channel負責將信息發送給適當的訂閱者，發布者和訂閱者直接沒有相互關系，也不知道對方的存在。
參考網站(包括場景和源碼分析)：
“http://blog.csdn.net/clh704/article/details/19754939”
“http://www.cnblogs.com/huangxincheng/p/5002794.html”
#開啟兩個窗口，一個做發布，一個做監聽。
#注意事項：發布窗口的publish后面的名稱channel1一定要跟監聽窗口中subscribe后面的名稱channel1保持一致，不然不能監聽到消息。
#發布窗口 [root@redis logs]# redis-cli 127.0.0.1:6379> publish channel1 testmessage1 (integer) 1#接收到發布信息的監聽個數 127.0.0.1:6379> publish channel1 testmessage2 (integer) 1 127.0.0.1:6379> publish channeltest testmessage (integer) 0 #監聽窗口 127.0.0.1:6379> subscribe channel1 Reading messages... (press Ctrl-C to quit) 1) "subscribe" 2) "channel1" 3) (integer) 1 #注意監聽的信息是3個一組 1) "message" 2) "channel1" 3) "testmessage1" #注意監聽的信息是3個一組 1) "message" 2) "channel1" 3) "testmessage2"
#發布部分 [root@redis logs]# redis-cli 127.0.0.1:6379> publish channel1 message1 (integer) 2 127.0.0.1:6379> publish channel1 message2 (integer) 2 #監聽部分 [root@redis ~]# redis-cli 127.0.0.1:6379> subscribe channel1 Reading messages... (press Ctrl-C to quit) 1) "subscribe" 2) "channel1" 3) (integer) 1 1) "message" 2) "channel1" 3) "message1" 1) "message" 2) "channel1" 3) "message2" [root@redis conf]# redis-cli 127.0.0.1:6379> subscribe channel1 Reading messages... (press Ctrl-C to quit) 1) "subscribe" 2) "channel1" 3) (integer) 1 1) "message" 2) "channel1" 3) "message1" 1) "message" 2) "channel1" 3) "message2"
#發布部分 [root@redis logs]# redis-cli 127.0.0.1:6379> publish channel1 message11 (integer) 2 127.0.0.1:6379> publish channel1 message12 (integer) 2 [root@redis ~]# redis-cli 127.0.0.1:6379> publish channel2 message21 (integer) 2 127.0.0.1:6379> publish channel2 message22 (integer) 2 #監聽部分 [root@redis ~]# redis-cli 127.0.0.1:6379> subscribe channel1 channel2 Reading messages... (press Ctrl-C to quit) 1) "subscribe" 2) "channel1" 3) (integer) 1 1) "subscribe" 2) "channel2" 3) (integer) 2 1) "message" 2) "channel1" 3) "message11" 1) "message" 2) "channel2" 3) "message21" 1) "message" 2) "channel1" 3) "message12" 1) "message" 2) "channel2" 3) "message22" [root@redis conf]# redis-cli 127.0.0.1:6379> subscribe channel1 channel2 Reading messages... (press Ctrl-C to quit) 1) "subscribe" 2) "channel1" 3) (integer) 1 1) "subscribe" 2) "channel2" 3) (integer) 2 1) "message" 2) "channel1" 3) "message11" 1) "message" 2) "channel2" 3) "message21" 1) "message" 2) "channel1" 3) "message12" 1) "message" 2) "channel2" 3) "message22"
下述內容參考文檔
“http://ifeve.com/redis-mem/”
“http://blog.csdn.net/xinguimeng/article/details/43884893”
“http://www.cnblogs.com/stephen-liu74/archive/2012/04/04/2366803.html”
和大多數NoSql數據庫一樣，redis同樣遵循了key/values數據存儲模型。在有些情況下，redis會將key/values保存在內存中以提高數據查詢和數據修改的效率，然而這樣的做法并非總是很好的選擇。鑒于此，我們可以將之進一步優化，即盡量在內存中只保留keys的數據，這樣可以保證數據檢索的效率，而values數據在很少使用的時候可以被換出到磁盤。
redis未使用linux的虛擬內存機制，而是實現了自己的虛擬內存機制，主要原因有以下兩點：
1、linux虛擬內存粒度過大，在linux中使用4KB的頁面，對于redis來說太大了，而redis中的絕大多數對象都遠遠小于這個數值。
2、redis可以把數據交換到磁盤上的時候進行適當的操作，比如壓縮，通常保存到磁盤上的對象可以去除指針和對象元數據信息，一般壓縮后的對象可以比內存中的對象小10倍，這樣可以節省很多的IO操作。
在實際應用中，如果內存中有一個10W條記錄的key數據集，而只有10%被經常使用，那么開啟虛擬內存的redis將把與較少使用的key相對應的value轉移到磁盤上。當客戶端請求獲取這些value時，他們將被從swap文件中讀回，并載入到內存中。也就是說，如果你的數據庫中有大量的keys，其中每個key僅僅關聯很小的value，那么這種場景就不是非常適合使用虛擬內存。如果數據庫中只是包含很少的keys，而每一個key所關聯的value確非常大，那么這種場景就適合使用虛擬內存。
1、在配置文件中添加以下配置項，以使當前Redis服務器在啟動時打開虛存功能。
vm-enabled yes
2、在配置文件中設定Redis最大可用的虛存字節數。如果內存中的數據大于該值，則有部分對象被換出到磁盤中，其中被換出對象所占用內存將被釋放，直到已用內存小于該值時才停止換出。
vm-max-memory (bytes)
Redis的交換規則是盡量考慮"最老"的數據，即最長時間沒有使用的數據將被換出。如果兩個對象的age相同，那么Value較大的數據將先被換出。需要注意的是，Redis不會將Keys交換到磁盤，因此如果僅僅keys的數據就已經填滿了整個虛存，那么這種數據模型將不適合使用虛存機制，或者是將該值設置的更大，以容納整個Keys的數據。在實際的應用，如果考慮使用Redis虛擬內存，我們應盡可能的分配更多的內存交給Redis使用，以避免頻繁的換入換出。
3、在配置文件中設定頁的數量及每一頁所占用的字節數。為了將內存中的數據傳送到磁盤上，我們需要使用交換文件。這些文件與數據持久性無關，Redis會在退出前會將它們全部刪除。由于對交換文件的訪問方式大多為隨機訪問，因此建議將交換文件存儲在固態磁盤上，這樣可以大大提高系統的運行效率。
vm-pages 134217728
vm-page-size 32
在上面的配置中，Redis將交換文件劃分為vm-pages個頁，其中每個頁所占用的字節為vm-page-size，那么Redis最終可用的交換文件大小為：vm-pages * vm-page-size。由于一個value可以存放在一個或多個頁上，但是一個頁不能持有多個value，鑒于此，我們在設置vm-page-size時需要充分考慮Redis的該特征。
4、在Redis的配置文件中有一個非常重要的配置參數，即：
vm-max-threads 4
該參數表示Redis在對交換文件執行IO操作時所應用的最大線程數量。通常而言，我們推薦該值等于主機的CPU cores。如果將該值設置為0，那么Redis在與交換文件進行IO交互時，將以同步的方式執行此操作。
對于Redis而言，如果操作交換文件是以同步的方式進行，那么當某一客戶端正在訪問交換文件中的數據時，其它客戶端如果再試圖訪問交換文件中的數據，該客戶端的請求就將被掛起，直到之前的操作結束為止。特別是在相對較慢或較忙的磁盤上讀取較大的數據值時，這種阻塞所帶來的影響就更為突兀了。然而同步操作也并非一無是處，事實上，從全局執行效率視角來看，同步方式要好于異步方式，畢竟同步方式節省了線程切換、線程間同步，以及線程拉起等操作產生的額外開銷。特別是當大部分頻繁使用的數據都可以直接從主內存中讀取時，同步方式的表現將更為優異。
如果你的現實應用恰恰相反，即有大量的換入換出操作，同時你的系統又有很多的cores，有鑒于此，你又不希望客戶端在訪問交換文件之前不得不阻塞一小段時間，如果確實是這樣，我想異步方式可能更適合于你的系統。
至于最終選用哪種配置方式，最好的答案將來自于不斷的實驗和調優。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
