EDITORIAL words
On a talk about some simple installation and operation Redis five basic data types, this chapter is mainly to see some additional features of Redis, although it may not be common, but still need to know. For us in terms of operation and maintenance personnel, to expand the knowledge of these things like, maybe we are not used to work for many years, but when you need to develop slowly toward the direction of development of operation and maintenance, these things will become your problem-solving another program. Another idea.
Publish and subscribe
Redis announced that there are two ways, message queues, and publish and subscribe.
For message queues, their role includes: Producer -> Message Queue -> Consumers
Producers say the task to be processed into the queue, the consumer then continue reading from the queue and then execute the task. The advantage is that the coupling solution, easy to scale.
For publication subscriptions, as we can broadcast FM, we have only one channel, you can listen to the radio, tuned to this process is the subscription channel.
And the principle of similar broadcast, subscribers need to first open channel to the designated channel and then start another window announced:
SUBSCRIBE fm110
The results are shown:
At this point another window began to fm110 channel news release:
PUBLISH fm110 "hello"
The results are shown:
Subscribers window view at this time:
It's a bit like QQ group chat, speak only allows the main group, the other may be more than one person to receive.
# Unsubscribe specified channel, if you do not specify a channel, all channels will unsubscribe UNSUBSCRIBE [channel ...] # Subscribe to one or more channels match a given pattern, as to match the symbol *, it * as it matches the beginning of the channel (it.news, it.blog etc.) PSUBSCRIBE pattern [pattern ...] # Unsubscribe specified rules, if no parameters will unsubscribe from all the rules PUNSUBSCRIBE [pattern [pattern ...]] # View subscription and publishing system state PUBSUB subcommand [argument [argument ...] ]
Of course, Redis publish-subscribe message queue is actually very rough, if you really need such content, you can choose RabbitMQ, Kafka and so on.
Transaction Processing
Knowing start a transaction in MySQL, if you do not commit, then does not modify the brush is written to disk, there are also such operations in Redis.
In MySQL start transaction begin or start a transaction, using multi in Redis.
In MySQL canceled rollback can use the rollback, Redis use discard to cancel, do not call rollback, operation and maintenance Redis is not running.
Filing a commit in MySQL, Redis is used in the exec.
Redis is used in the optimistic locking, you can buy a ticket to the test by simulating online:
1 execution in the window:
127.0.0.1:6379> set ticket 1 OK 127.0.0.1:6379> watch ticket OK 127.0.0.1:6379> multi OK 127.0.0.1:6379> set ticket 0 QUEUED
Temporarily execute it, and then taking the window 2 to execute:
127.0.0.1:6379> get ticket "1" 127.0.0.1:6379> multi OK 127.0.0.1:6379> set ticket 0 QUEUED 127.0.0.1:6379> exec 1) OK
At this point go to the window to perform 1:
127.0.0.1:6379> exec (nil)
And I found the ticket was bought by others! Which role is to watch a monitor (or more) Key, if this (or these) are altered Key command before another transaction execution, the transaction will be interrupted.
Other global operations
Commonly used commands are as follows:
# Show client connections CLIENT LIST # Kill Client CLIENT KILL id 10 # Get all system configuration CONFIG GET * # Obtain matching configuration CONFIG GET log* # Online modify the configuration CONFIG SET requirepass helloworld # Login AUTH helloworld # The modified configuration write redis.conf CONFIG REWRITE # Display the current library key number DBSIZE # Print command redis received MONITOR # Delete all current library Key FLUSHDB # Delete key all libraries FLUSHALL # Current time TIME # Manual persistence SAVE # Asynchronous execution of a AOF (AppendOnly File) file-overwrite operation BGREWRITEAOF # Save the current database in the background asynchronous data to disk BGSAVE
The results are as follows:
127.0.0.1:6379> CLIENT LIST id=5 addr=127.0.0.1:48567 fd=8 name= age=15091 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client id=8 addr=127.0.0.1:48573 fd=9 name= age=660 idle=600 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=exec id=10 addr=127.0.0.1:48577 fd=10 name= age=14 idle=14 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=keys 127.0.0.1:6379> CLIENT KILL id 10 (integer) 1 127.0.0.1:6379> CONFIG GET log* 1) "logfile" 2) "/data/services/redis/logs/redis-6379.log" 3) "loglevel" 4) "notice" 127.0.0.1:6379> CONFIG SET requirepass helloworld OK 127.0.0.1:6379> keys * (error) NOAUTH Authentication required. 127.0.0.1:6379> AUTH helloworld OK 127.0.0.1:6379> CONFIG GET requirepass 1) "requirepass" 2) "helloworld" 127.0.0.1:6379> CONFIG REWRITE OK 127.0.0.1:6379> DBSIZE (integer) 1 127.0.0.1:6379> FLUSHDB OK 127.0.0.1:6379> FLUSHALL OK 127.0.0.1:6379> TIME 1) "1573022355" 2) "256540" 127.0.0.1:6379> MONITOR OK 1573022218.974627 [0 127.0.0.1:48573] "AUTH" "helloworld" 1573022226.451991 [0 127.0.0.1:48573] "keys" "*" 1573022268.293698 [0 127.0.0.1:48573] "FLUSHDB" 1573022292.090727 [0 127.0.0.1:48573] "FLUSHALL" 1573022355.256531 [0 127.0.0.1:48573] "TIME"
This, we learned the simple command about the same, with a real will in fact not many, what follows is what we care more about the operation and maintenance of things! That is the design and architecture of tuning.