Shulou(Shulou.com)06/01 Report--

VIII. Security of redis

Because redis is quite fast, under a better server, an external user can try 15W passwords in a second, which means that a very strong password needs to be set to prevent brute force cracking.

You can do this by setting a password and logging in to redis. For more information, please see

IX. Brief introduction of redis master-slave replication 9 and 1

1. Master can have multiple slave.

2. Multiple slave can connect not only to the same master, but also to other slave.

3. Master-slave replication will not block master, and master can continue to process client requests when synchronizing data.

4. Provide scalability of the system.

9. 2 Master-Slave replication process

1. Slave establishes a connection with master and sends sync synchronization commands.

2. Master will start a background process to save the database snapshot to a file, and the master process will start collecting new write commands and caching them.

3. After the master background finishes saving, the file will be sent to slave.

4. Slave saves the received master file to disk.

9, 3 Master-Slave replication configuration # now uses different configurations of the same machine to simulate the master-slave replication scenario. Root@redis conf] # pwd / application/redis/conf [root@redis conf] # lsappendonly.aof dump.rdb redis.conf [root@redis conf] # cd.. [root@redis redis] # cp-a conf conf-slave# the following is the slave node [root@redis redis] # cd conf-slave/ [root@redis conf-slave] # lsappendonly.aof dump.rdb redis.conf # setting the slave node port port 638 setting the file name and path in the slave node to XX-slave In the form logfile / application/redis/logs/redis-slave.logdir / application/redis/conf-slave/ # configure the IP and port slaveof 10.0.0.11 637 configuration of the master node (the redis.conf of the redis4.0 master node is also configured) masterauth redis # sets the firewall shutdown state [root@redis conf-slave] # / etc/init.d/iptables stop [root@redis conf-slave] # / etc/init.d/iptables statusiptables: Firewall is not running. # you can use info to view the role role to know whether it is a master service or a slave service.

9 、 4 start redis master / slave node test # master node [root@redis ~] # redis-server/application/redis/conf/redis.conf [root@redis ~] # lsof-i:6379COMMAND PIDUSER FD TYPE DEVICE SIZE/OFF NODE NAMEredis-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] # lltotal 1780 root root RW Rafael-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 redis.log-rw-r--r-- M 08 Dec 02 redis.log-rw-r--r-- 08V 46.338-Accepted 10.0.11Vol 175862456Vol M 08 Dec 02VlV 08VV 47.345-Accepted 10.0.11Fr175872456 Fran M 08 Dec 02Fran 48.352-Accepted 10.0.0. 110slaves 175882456 Dec M 08 02R 08R 49.076-0 clients connected (0slaves) 758544 bytes in use # Slave Node [root@redis ~] # redis-server/application/redis/conf-slave/redis.conf [root@redis ~] # lsof-i:6380COMMAND PIDUSER FD TYPE DEVICE SIZE/OFF NODE NAMEredis-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] # lltotal 1724rwmerr- -root root-1 root root 1741206 Dec 8 02:06 redis.log-rw-r--r-- 1 root root 15808 Dec 8 02:06 redis-slave.log # Slave Node logs if the following occurs Then you need to comment out bind 127.0.0.1 in the redis.conf file. This situation will occur in multiple machines, but now single-machine simulation will not occur, because the security policy adopted by redis only allows local access by default, so there is no need to comment out the test on the same machine. For more information on redis.conf parameters, please see "4, 3, 4redis.conf File configuration instructions". [root@redis logs] # tailf redis-slave.log 2460 Dec S 08 Dec 02 Error condition on socketfor SYNC: Broken pipe2460:S 08 Dec 02 Error condition on socketfor SYNC: Broken pipe2460:S 08 Dec 02 V 09V 50.168-0 clients connected (0slaves), 758544 bytes in use2460:S 08 Dec 02 V 09V 50.180 * Connecting to MASTER10.0.0.11:63792460:S 08 Dec 02 V 09V 50.181 * MASTER SLAVE syncstarted2460:S 08 Dec 02 V 09V 50.181 * Non blocking connect forSYNC fired the event.# can find that the slave node is not connected successfully Then you need to set the bind value of the redis.conf file corresponding to the slave node. [root@redis conf-slave] # lsof-i:6380COMMAND PIDUSER FD TYPE DEVICE SIZE/OFF NODE NAMEredis-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-ii:6380COMMAND PIDUSER FD TYPE DEVICE SIZE/OFF NODE NAMEredis-ser 6380 [root@redis conf-slave] # pwd/application/redis/conf-slavebind 127.0.0.1 # Master node setting value [root@redis ~] # redis-cli-a redis- p 6379127.0.0.1redis- 6379 > keys * (empty list or set) 127.0.0.1redis- 6379 > set name namevalOK127.0.0.1:6379 > get name "nameval" [root@redis logs] # pwd/application/redis/logs [root@redis logs] # tailf redis.log2506:M 08 Dec 02VIE2133.242-Accepted 127.0.1Rich 363242506M08 Dec 02MUR 2133.584-1 clients connected 1848864 bytes in use2506:M 08 Dec 02 keys 21VV 38.616-DB 0: 1 keys (0 volatile) in4 slots HT.127.0.0.1:6379 > del name (integer) 1127.0.0.1 redis-cli 6379 > keys * 1) "name2" # get the value from the node [root@redis] # redis-cli-a redis- p 6380 127.0.16380 > keys * (empty list or set) 127.0.0.16380 > keys * 1) "name" 127. 0.0.1Background AOF rewritefinished successfully2512:S 6380 > get name "nameval" 2512 Dec 08 Dec 02 Dec 19V 28.089 * Background AOF rewritefinished successfully2512:S 08 Dec 02 19V 28.089-Background AOF rewritesignal handler took 236us2512:S 08 Dec 02 19V 32.915-1 clients connected (0slaves) 779440 bytes in use2512:S 08 Dec 02 DB 0: 1 keys (0 volatile) in4 slots HT.2512:S 08 Dec 02 DB 21 clients connected (0slaves), 800536 bytes in use

# Note that there is no write operation on the slave node, only read operation

127.0.0.1 READONLY You can't write against a read onlyslave.127.0.0.1:6380 6380 > del name (error) READONLY You can't write against a read onlyslave.127.0.0.1:6380 > keys * 1) "name2" # check through monitoring # Master node monitors [root@redis logs] # redis-cli-a redis- p 6379 monitorOK127.0.0.1:6379 > flushallOK127.0.0.1:6379 > keys * (empty list or set) [root@redis logs] # redis-cli-a redis- p 6379 monitorOK1481135598.941742 [0 127.0.0.1 flushall 36324] "flushall" 1481135634.460910 [0 127.0.0.1 set name namevalOK127.0.0.1:6379 > get name "nameval" [root@redis logs] # redis-cli-a redis- p 6379 monitorOK1481135697.418957 [0 127.0.0.1 set name namevalOK127.0.0.1:6379 36324] "set"name"nameval" 1481135698.642795 [0 127.0.1 set name namevalOK127.0.0.1:6379] "get" name " # Monitoring from the node [root@redis conf-slave] # redis-cli-a redis- p 6380monitorOK127.0.0.1:6380 > keys * (empty list or set) [root@redis conf-slave] # redis-cli-a redis- p 6380monitorOK1481135598.306657 [0 10.0.0.11 redis- 6379] "PING" 1481135598.947041 [0 10.0.0.11 redis- 6379] "flushall" 1481135608.370998 [0 10.0.0.11keys 6379] "PING" 1481135618.428639 [ 0 10.0.0.11 PING 6379] "PING" 1481135628.493744 [010.0.0.11 PING "1481135638.562807 [010.0.0.11]" PING "1481135648.730527 [010.0.0.11 PING 6379]" PING "1481135658.800544 [010.0.0.11 PING]" PING "1481135663.809136 [0 127.0.0.1R 62476]" keys "*" 1481135668.860633 [010.0 .0.11 redis- 6379] "PING" [root@redis conf-slave] # redis-cli-a redis- p 6380monitorOK1481135688.972458 [0 10.0.0.11 6380monitorOK1481135688.972458 6379] "PING" 1481135697.422176 [0 10.0.0.11 6380monitorOK1481135688.972458 6379] "set"name"nameval" 1481135699.036100 [0 10.0.0.11 6380monitorOK1481135688.972458 6379] "PING" 127.0.0.16380monitorOK1481135688.972458 6380 > keys * 1) "name" 127.0.0.16380monitorOK1481135688.972458 6380 > get name "nameval" "[root@redis conf-slave] # redis-cli-a redis- p 6380monitorOK1481135747.385987 [0 127.0.0.1 redis- 62476]" keys "" * "1481135749.378369 [0 10.0.0.11 redis- 6379]" PING "1481135750.203089 [0 127.0.0.1 redis- 62476]" get "" name "1481135759.444582 [0 10.0.0.11 redis- 6379]" PING "

9. 5 View Master / Slave Node Information # Master Node 127.0.0.1 Lag=0master_repl_offset:2256repl_backlog_active:1repl_backlog_size:1048576repl_backlog_first_byte_offset:2repl_backlog_histlen:2255 # Replication is a part of viewing node information through info # slave node 127.0.0.1 info > info Replication# Replicationrole:slavemaster_host:10.0.0.11master_port:6379master_link_status:upmaster_last_io_seconds_ago:6master_sync_in_progress:0slave_repl_offset:2326slave_priority:100slave _ read_only:1connected_slaves:0master_repl_offset:0repl_backlog_active:0repl_backlog_size:1048576repl_backlog_first_byte_offset:0repl_backlog_histlen:0

Brief introduction of Sentinel Mode 10 and 1

After master-slave replication, if you want to monitor the master-slave replication server, a "Sentinel" mechanism is provided after redis2.6. Sentinel 1.0 in version 2.6 is unstable, and there will be all kinds of problems. After the redis2.8 version, the Sentinel function becomes stable.

As the name implies, the meaning of Sentinel is to monitor the operation of the redis system, and its main functions are as follows:

Monitor whether the master database and slave database are running properly.

2. When the master database fails, the slave database can be automatically converted to the master database to realize automatic switching.

A node can be monitored by multiple sentinels. Sentinel is not directly related to all redis nodes, Sentinel is just a monitoring program.

(you can use keepalived (with nginx) instead of Sentinel for high availability.)

10, 2 operation steps

# (only the master node can be allocated)

# configure sentinel.conf

[root@redis redis-3.2.5] # pwd/home/lly/tools/redis-3.2.5# copy to the slave node directory [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.confsentinel monitor mymaster 127.0.0.1 6379 1 # name IP, port, the number of votes is recommended to be 1. Multiple machines remember to set the private network IP of master (internal system interaction uses private network IP, external access provides public network IP). Sentinel down-after-milliseconds mymaster 5000 # sets 5000 millisecond detection. Default is 1 second sentinel failover-timeout mymaster 900000sentinel parallel-syncs mymaster 2sentinel auth-pass mymaster redis # master node password (no password is configured in the node redis.conf, so this step is omitted)

# the first step of testing

# start Sentinel mode Note that the following command does not add-a redis- p 6380 [root@redis conf-slave] # redis-server sentinel.conf--sentinel & [root@redis ~] # lsof-i:26379COMMAND PIDUSER FD TYPE DEVICE SIZE/OFF NODE NAMEredis-ser 2650 root 4U IPv6 19430 0t0 TCP *: 26379 (LISTEN) redis-ser 2650 root 5u IPv4 19432 0t0 TCP *: 26379 (LISTEN) # View Sentinel related information [root@redis ~] # redis-cli-p 26379 info Sentinel # Sentinelsentinel_masters:1sentinel_tilt:0sentinel_running_scripts:0sentinel_scripts_queue_length:0sentinel_simulate_failure_flags:0master0:name=mymaster Status=ok,address=127.0.0.1:6379,slaves=1,sentinels=1 # Master Node Log [root@redis ~] # tailf / application/redis/logs/redis.log1481137928.553897 [0 127.0.0.1 application/redis/logs/redis.log1481137928.553897 36329] "PING" 1481137929.589836 [0 127.0.0.1V 36329] "PING" 1481137929.763963 [0 127.0.0.1V 36329] "PUBLISH"_ sentinel__:hello"127.0.0.1mu 260.0.1Magi 14563baa663afc1c2e06ee3cb07f222c220fd7b013 Mymastery 127.0.0.1Magi 6379L0"

# Test step 2

# close the master node [root@redis ~] # redis-cli-a redis- p 6379 shutdown# Slave Node Log [root@redis conf-slave] # tailf/application/redis/logs/redis-slave.log2574:S 08 Dec 03VlV 15Rd 16.629 * MASTER SLAVE syncstarted2574:S 08 Dec 03VlV 15Rd 16.629 # Error condition on socketfor SYNC: Connection refused2574:M 08 Dec 03VlV 15Rd 17.016 * Discarding previously cachedmaster state.2574:M 08 Dec 0315Rd 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 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' M 08 Dec 03 Dec 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 7. 050 * Background saving started bypid 2712 2712 12 7 7 12 12 12 7 7 12 12 7 7 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, Background saving started bypid, and so on. 068 * RDB: 6 MB of memory used bycopy-on-write2574:M 08 Dec 03 Dec 1515 Dec 17.150 * Background saving terminatedwith success2574:M 08 Client closed connection2574:M 08 Dec 03 Dec 1515 Dec 17.981-Client closed connection2574:M 08 Dec 03 15 18.069-Accepted 127.0.0.1azo 624992574 M 08 Dec 07415 15 Accepted 127.0.0.1 Accepted 127.0.1The 625002574M08 Dec 03Switzerland 1520.671-DB 0: 1 Keys (0 volatile) in4 slots HT.2574:M 08 Dec 03 Freight 20.672-2 clients connected (0slaves) 800816 bytes in use2574:M 08 Dec 03 volatile 1515 redis-cli 25.705-DB 0: 1 keys (0 volatile) in4 slots HT.2574:M 08 Dec 03 volatile 1525.705-2 clients connected (0slaves), 800800 bytes in use # View Sentinel information [root@redis ~] # redis-cli-p 26379 info Sentinel # Sentinelsentinel_masters:1sentinel_tilt:0sentinel_running_scripts:0sentinel_scripts_queue_length:0sentinel_simulate_failure_flags:0master0:name=mymaster,status=ok,address=127.0.0.1:6380,slaves=1 Sentinels=1 # former slave node info information (now master node) 127.0.0.1 info Replication# Replicationrole:masterconnected_slaves:0master_repl_offset:0repl_backlog_active:0repl_backlog_size:1048576repl_backlog_first_byte_offset:0repl_backlog_histlen:0 6380 > info Replication# Replicationrole:masterconnected_slaves:0master_repl_offset:0repl_backlog_active:0repl_backlog_size:1048576repl_backlog_first_byte_offset:0repl_backlog_histlen:0 # former master node info information (now slave node) 127.0.0.1 info ReplicationCould not connect to Redis at 127.0.0.1 info 6379: Connectionrefusednot connected >

# Test step 3

# start the original master node (now the slave node) [root@redis ~] # redis-server/application/redis/conf/redis.conf # View the Sentinel switch log Switch from the node to the original master node 6379 [root@redis conf-slave] # redis-server sentinel.conf--sentinel & 2650 Dec 08 Dec 03 Dec 15 17.980 # + failover-end master mymaster 127.0.0.1 63792650 Dec 03 15 17.980 # + switch-master mymaster 127.0.0.1 6379 127.0.0.1 63802650 Dec 0515 17.981 * + slave slave 127.0.1 @ mymaster 127.0.0.1 63802650 mymaster X 08 Dec 03 convert-to-slave slave 18mymaster 07.759 * + Background saving terminatedwith success2574:M 127.0.0.1 convert-to-slave slave 127.0.0.1 @ mymaster 127.0.0.1 6380 # the original master node log (now a slave node) [root@redis ~] # tailf / application/redis/logs/redis.log2574:M 08 Dec 03 convert-to-slave slave 08.674 * Background saving terminatedwith success2574:M 08 Dec 03 18lane 08.679 * Synchronization with slave127. 0.0.1 keys 6379 succeeded2574:M 08 Dec 03 succeeded2574:M 08 18 volatile 11.903-DB 0: 1 keys (0 volatile) in4 slots HT.2574:M 08 Dec 03 Fraser 18 Fringe 11.903-3 clients connected (1slaves) 1891152 bytes in use2574:M 08 Dec 03 volatile 18 bytes in use2574:M 16.932-DB 0: 1 keys (0 volatile) in4 slots HT.2574:M 08 Dec 03 Freud 16.932-3 clients connected (1slaves) 1891136 bytes in use # original master node info information (now slave node) becomes slave node information not connected > info Replication# Replicationrole:slavemaster_host:127.0.0.1master_port:6380master_link_status:upmaster_last_io_seconds_ago:0master_sync_in_progress:0slave_repl_offset:2061slave_priority:100slave_read_only:1connected_slaves:0master_repl_offset:0repl_backlog_active:0repl_backlog_size:1048576repl_backlog_first_byte_offset: 0repl_backlog_histlen:0 # original slave node info information (now master node) It becomes the primary node information 127.0.0.1 info Replication# Replicationrole:masterconnected_slaves:1slave0:ip=127.0.0.1,port=6379,state=online,offset=5736,lag=0master_repl_offset:5736repl_backlog_active:1repl_backlog_size:1048576repl_backlog_first_byte_offset:2repl_backlog_histlen:5735 6380 >

Transaction 10, 1redis simple transaction 1

First, use multi to open the transaction, then set it, and then save the set data in the queue, and finally use exec to execute, store the data in redis in turn, and use the discard method to cancel the transaction.

# multi marks the beginning of a transaction block. Subsequent instructions will be executed as an atom when the EXEC is executed. Return value simple-string-reply: always execute all queued instructions in the transaction for OK # exec and restore the link state to normal when using WATCH, EXEC will be executed only if the monitored key has not been modified and the setting mechanism is allowed to be checked, EXEC will be executed return value multi-bulk-reply: if WATCH should be used for each element and instruction in an atomic transaction, if terminated EXEC returns an empty response set # discard to refresh all queued instructions in a transaction and restore the connection state to normal. If WATCH,DISCARD has been used, all key that has been WATCH will be released. Return value status-reply: all returns are OK # watch (lock key until the multi/exec command is executed) to mark that all specified key is monitored and conditionally executed in the transaction (optimistic lock). Return value simple-string-reply: always OK. # unwatch (cancel transaction command) refresh all key that have been monitored in a transaction. If you execute EXEC or DISCARD, you do not need to perform UNWATCH manually. Return value simple-string-reply: always OK. 127.0.0.1 get age 6379 > multiOK127.0.0.1:6379 > incr ageQUEUED127.0.0.1:6379 > exec1) (integer) 12127.0.1 > get age "12" 127.0.0.16379 > multiOK127.0.0.1:6379 > incr ageQUEUED127.0.0.1:6379 > discardOK127.0.0.1:6379 > get age "12 "age" 127.0.0.1 get age > get age "13" 127.0.0.1 multiOK127.0.0.1:6379 > incr ageQUEUED127.0.0.1:6379 > get ageQUEUED127.0.0.1:6379 > exec1) (integer) 142) "14" 127.0.0.1 multiOK127.0.0.1:6379 > unwatchOK127.0.0.1:6379 > get age "14" 127.0.0.1 > get age "14" .0.0.1: 6379 > multiOK127.0.0.1:6379 > incr ageQUEUED127.0.0.1:6379 > unwatchQUEUED127.0.0.1:6379 > get ageQUEUED127.0.0.1:6379 > exec1) (integer) 152) OK3) "15" 127.0.0.1) incr ageQUEUED127.0.0.1:6379 > incr ageQUEUED127.0.0.1:6379 > unwatchQUEUED127.0.0.1:6379 > discardOK127.0.0.1:6379 > get age "15"

10. 2redis simple transaction II

Redis transactions cannot guarantee success or failure to commit or rollback at the same time, so redis transactions are relatively simple at the moment (redis transactions are generally not used in programs).

127.0.0.1 keys * 1) "age" 127.0.0.1 get age 6379 > set name namevalOK127.0.0.1:6379 > multiOK127.0.0.1:6379 > incr ageQUEUED# note that incr name did not report an error, it was a time error when executing the exec command, and the call of this incr command in java reported an error. 127.0.0.1 incr nameQUEUED# 6379 > although the following error is reported, the transaction has been committed and the name has not changed. If the following discard command interrupts the transaction, all values will not be affected. 127.0.1 exec1 > exec1) (integer) 162) (error) ERR value is not an integer or out of range127.0.0.1:6379 > get age "16" 127.0.1 purl 6379 > get name "nameval"

XII. Persistence mechanism

Redis is an in-memory database that supports persistence, which means that redis needs to frequently synchronize the data in memory to the hard disk to ensure persistence. There are two ways to persist Redis.

12. 1 Snapshot RDB file mode

Snapshotting (Snapshot) defaults to writing snapshots in memory to binary files. The default is dump.rdb. You can configure redis to automatically persist snapshots by configuring them. If there are more than M key modifications in N seconds, snapshots will be taken automatically.

Snapshot settings:

If more than one key is modified within save 9001 # 900s, a snapshot save is initiated. The following is the same.

Save 300 10

Save 60 10000

12. 2AOF file mode

The way of append-only file (abbreviated aof) (somewhat similar to oracle log), because the snapshot mode is done once at a certain time interval, so it is possible that redis accident occurs. Down Qingyukang will lose all the modified data after the last snapshot. Aof has better persistence than snapshot method, because when using aof, redis appends every write command received to the command through the write function. When redis restart starts, the write command saved in the file is re-executed to rebuild the contents of the database in memory. The Aof file is not immediately written to disk, but can be forced to be written to the hard disk through configuration file modification.

Aof settings:

# appendonly yes / / there are three ways to start aof persistence.

# appendfsync always / / is written to disk immediately by the write command, which is the slowest, but ensures complete persistence. (for example, slow page writing may be caused by this, which can be processed by the server.)

# appendfsync everysec / / writes to disk once per second, making a good tradeoff between performance and persistence.

# appendfsync no / / is completely dependent on the operating system, with the best performance, no synchronization, no system operation, and no guarantee of persistence.

Only one of RDB files and AOF files can be opened.

The above contents are configured in the redis.conf file. The parameters of redis.conf are explained in "4, 3, 4redis.conf configuration file instructions".

XIII. Brief introduction to publish and subscribe messages 13 and 1

Redis provides a simple publish and subscribe function.

Use subscribe [Channel] for subscription monitoring.

Broadcast the release message using publish [Channel] [post].

In order to decouple the relationship between the publisher (publisher) and the subscriber (subscribe), redis uses the channel (channel) as the intermediary between the two. The publisher publishes the information directly to the channel, while the channel is responsible for sending the information to the appropriate subscriber. The publisher and the subscriber are not related to each other and do not know the existence of each other.

Reference website (including scenario and source code analysis):

"http://blog.csdn.net/clh704/article/details/19754939"

"http://www.cnblogs.com/huangxincheng/p/5002794.html"

13, 2 operations 13, 2, 1 a release, a monitor

# Open two windows, one for publishing and one for listening.

# Note: the name channel1 after the publish of the publishing window must be the same as the name channel1 after the subscribe in the listening window, otherwise the message cannot be listened to.

# the number of listeners received by the release window [root@redis logs] # redis-cli127.0.0.1:6379 > publish channel1 testmessage1 (integer) > publish channel1 testmessage2 (integer) 1127.0.0.1 > publish channeltest testmessage (integer) 0 # listener window 127.0.0.1 publish channel1 testmessage1 6379 > subscribe channel1Reading messages... (press Ctrl-C to quit) 1) "subscribe" 2) "channel1" 3) (integer) 1) "message" 2) "channel1" 3) "testmessage1" # Note the message monitored is a group of 3) "message" 2) "channel1" 3) "testmessage2"

13, 2, 2 one release, multiple listeners # release part [root@redis logs] # redis-cli127.0.0.1:6379 > publish channel1 message1 (integer) 2127.0.0.1 publish channel1 message1 6379 > publish channel1 message2 (integer) 2 # listening part [root@redis ~] # redis-cli127.0.0.1:6379 > subscribe channel1Reading messages... (press Ctrl-C to quit) 1) "subscribe" 2) "channel1" 3) (integer) 11) "message" 2) "channel1" 3) "message1" 1) "message" 2) "channel1" 3) "message2" [root@redis conf] # redis-cli127.0.0.1:6379 > subscribe channel1Reading messages... (press Ctrl-C to quit) 1) "subscribe" 2) "channel1" 3) (integer) 11) "message" 2) "channel1" 3) "message1" 1) "message" 2) "channel1" 3) "message2"

13, 2, 3 multiple releases, multiple listeners # release part [root@redis logs] # redis-cli127.0.0.1:6379 > publish channel1 message11 (integer) 2127.0.0.1 publish channel2 message22 6379 > publish channel1 message12 (integer) 2 [root@redis ~] # redis-cli127.0.0.1:6379 > publish channel2 message21 (integer) 2127.0.1purl 6379 > publish channel2 message22 (integer) 2 # listening part [root@redis] # redis-cli127.0.0.1:6379 > subscribe channel1 channel2Reading messages... (press Ctrl-C to quit) 1) "subscribe" 2) "channel1" 3) (integer) 11) "subscribe" 2) "channel2" 3) (integer) 21) "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-cli127.0.0.1:6379 > subscribe channel1 channel2Reading messages... (press Ctrl-C to quit) 1) "subscribe" 2) "channel1" 3) (integer) 11) "subscribe" 2) "channel2" 3) (integer) 21) "message" 2) "channel1" 3) "message11" 1) "message" 2) "channel2" 3) "message21" 1) "message" 2) "channel1" 3) "message12" 1) "message" 2) "channel2" 3) "message22"

XIV. Use of virtual memory

Reference documentation for the following

"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"

14, 1 introduction

Like most NoSql databases, redis follows the key/values data storage model. In some cases, redis keeps key/values in memory to improve the efficiency of data queries and data modifications, but this is not always a good choice. In view of this, we can further optimize it, that is, try to keep only keys data in memory, so as to ensure the efficiency of data retrieval, and values data can be swapped out to disk when it is rarely used.

Instead of using linux's virtual memory mechanism, redis implements its own virtual memory mechanism for two main reasons:

1. The granularity of linux virtual memory is too large. Pages that use 4KB in linux are too large for redis, and most objects in redis are much smaller than this value.

2. Redis can perform appropriate operations when exchanging data to disk, such as compression. Objects saved to disk can usually remove pointers and object metadata information. Generally, compressed objects can be 10 times smaller than objects in memory, which can save a lot of IO operations.

14, 2 application scenarios

In practical applications, if there is a 10W record key dataset in memory, and only 10% is frequently used, then the redis that opens the virtual memory will transfer the value corresponding to the less used key to disk. When the client requests to get these value, they are read back from the swap file and loaded into memory. That is, if you have a large number of keys in your database, and each key is associated with only a very small value, then this scenario is not very suitable for using virtual memory. If the database contains only a small amount of keys, and the value associated with each key is indeed very large, then this scenario is suitable for the use of virtual memory.

14, 3 Virtual memory configuration

1. Add the following configuration item to the configuration file to enable the current Redis server to turn on the virtual memory feature when it starts.

Vm-enabled yes

2. Set the maximum number of virtual memory bytes available for Redis in the configuration file. If the data in memory is greater than this value, some objects are swapped out to disk, and the memory occupied by the swapped object is freed until the used memory is less than this value.

Vm-max-memory (bytes)

Redis's exchange rule is to take into account the "oldest" data as much as possible, that is, data that has not been used for the longest time will be swapped out. If the age of the two objects is the same, the data with larger Value will be swapped out first. It is important to note that Redis does not swap Keys to disk, so if the data of keys alone has filled the entire virtual memory, then this data model will not be suitable for using virtual memory mechanism, or set the value higher to accommodate the data of the entire Keys. In practical applications, if we consider using Redis virtual memory, we should allocate as much memory as possible to Redis to avoid frequent swapping in and out.

3. Set the number of pages and the number of bytes occupied by each page in the configuration file. In order to transfer data from memory to disk, we need to use swap files. These files have nothing to do with data persistence, and Redis deletes them all before exiting. Since most of the access to the swap file is random, it is recommended that the swap file be stored on the solid-state disk, which can greatly improve the running efficiency of the system.

Vm-pages 134217728

Vm-page-size 32

In the above configuration, Redis divides the swap file into vm-pages pages, where each page occupies vm-page-size, so the final available swap file size for Redis is: vm-pages * vm-page-size. Because a value can be stored on one or more pages, but a page cannot hold more than one value, we need to fully consider this feature of Redis when setting up vm-page-size.

4. There is a very important configuration parameter in the configuration file of Redis, namely:

Vm-max-threads 4

This parameter represents the maximum number of threads applied by Redis when performing IO operations on the swap file. Generally speaking, we recommend that this value be equal to the CPU cores of the host. If this value is set to 0, Redis will do this synchronously when it interacts with the swap file for IO.

For Redis, if the operation of the swap file is done synchronously, then when a client is accessing the data in the swap file, and if another client tries to access the data in the swap file, the client's request will be suspended until the end of the previous operation. The impact of this blocking is even more abrupt, especially when reading large data values on relatively slow or busy disks. However, synchronous operation is not useless. In fact, from the perspective of global execution efficiency, synchronous mode is better than asynchronous mode. After all, synchronous mode saves extra overhead caused by thread switching, inter-thread synchronization, and thread pull-up. Especially when most of the frequently used data can be read directly from the main memory, the performance of synchronization will be better.

If your real application is just the opposite, that is, there are a lot of swap operations, while your system has a lot of cores, in view of this, you do not want the client to have to block for a short period of time before accessing the swap file, if that is the case, I think asynchronous mode may be more suitable for your system.

As to which configuration mode to choose in the end, the best answer will come from constant experiment and tuning.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.