Redis learning experience
Before reading this book, I learned about redis through other people’s blogs and manuals. I got a lot of knowledge from reading this book in the last two weeks, so I plan to share a learning note.
Can you really name the key of redis?
It is suggested that redis has no mandatory requirement for key naming, but a better practice is to use “object type: object ID: object attribute” to name a key, such as using key user:1 : friends to store the list of friends of the user with ID 1. For multiple words, it is recommended to use “.” to separate them. On the one hand, it follows the old habit (the key names of previous versions of redis cannot contain special characters such as spaces). On the other hand, it is easy to enter in redis cli without using double quotation marks. In addition, for the convenience of future maintenance, key naming must be meaningful. For example, the readability of U: 1: F is obviously not as good as that of U: 1: F user:1 Good friends
For example: how to name the viewing amount of this article with Article ID 1?
$key = "article:1:view";
PS: Although using a shorter name can save storage space, because the length of the key value is often much longer than the length of the key name, the saving of this part is not as important as readability in most cases.
How to ensure atomicity when several redis commands are executed together?
A transaction in redis is a set of commands. Like commands, transactions are the smallest execution unit of redis. Commands in a transaction are either executed or not executed. Transaction applications are very common. For example, in the process of bank transfer, a remits money to B. first, the system transfers the money from a’s account, and then increases the corresponding amount to B’s account. These two steps must belong to the same transaction, either all or none. Otherwise, only the first step, the money will disappear, which is obviously unacceptable.
redis> MULTI OK redis> SADD "user:1:following" 2 QUEUED redis> SADD "user:2:followers" 1 QUEUED redis> EXEC 1) (integer) 1 2) (integer) 1
The above code demonstrates how transactions are used. First of all, use the multi command to tell redis: “the commands I send you belong to the same transaction. You should not execute them first, but save them temporarily.” Redis replied, “OK.”
After that, we send two Sadd commands to implement the following and being followed operations. We can see that redis abides by its promise and does not execute these commands. Instead, it returns Queed to indicate that the two commands have entered the transaction queue waiting to be executed.
After sending all the commands to be executed in the same transaction to redis, we use the exec command to tell redis to execute all the commands in the transaction queue waiting to be executed (that is, all the commands that just returned queued) in order of sending. The return value of the exec command is a list of the return values of these commands. The order of the return values is the same as that of the commands.
Redis ensures that all commands in a transaction are either executed or not executed. If the client is disconnected before sending the exec command, redis will clear the transaction queue and all commands in the transaction will not be executed. Once the client sends the exec command, all the commands will be executed, even if the client is disconnected later, because redis has recorded all the commands to be executed.
In some cases, it is not suitable to use transactions to ensure the atomicity of data operations. In this case, we need to use scripts.
The advantages of using scripts are as follows:
(1) Reduce network overhead: if five commands need to send up to five requests to redis, and use the script function to complete the same operation, only one request needs to be sent, reducing the network round-trip delay.
(2) Atomic operation: redis will execute the whole script as a whole, and will not be inserted by other commands. In other words, there is no need to worry about race conditions in the process of scripting, and there is no need to use transactions. All functions that can be completed by transaction can be realized by script.
(3) Reuse: scripts sent by clients will be permanently stored in redis, which means that other clients (which can be projects developed in other languages) can reuse this script without using code to complete the same logic.
Persistence of redis
When redis is used to store non temporary data, it is generally necessary to turn on AOF persistence to reduce the data loss caused by process termination. Aof can append every write command executed by redis to the hard disk file. This process obviously reduces the performance of redis, but in most cases, this effect is acceptable. In addition, using a faster hard disk can improve the performance of AOF.
Although AOF records commands in the AOF file every time it changes the contents of the database, in fact, due to the caching mechanism of the operating system, the data is not really written to the hard disk, but enters the system’s hard disk cache. By default, the system will perform a synchronization operation every 30 seconds in order to write the contents of the hard disk cache to the hard disk. In this 30 second process, if the system exits abnormally, the data in the hard disk cache will be lost. Generally speaking, AOF enabled applications can’t tolerate such a loss, which requires redis to actively ask the system to synchronize the cache contents to the hard disk after writing AOF files. In redis, we can set the synchronization time through the appendfsync parameter
# appendfsync always appendfsync everysec # appendfsync no
By default, redisec performs the synchronization once per second. Always means that every write is synchronized, which is the safest and slowest way. No means that it does not take the initiative to synchronize, but completely leaves it to the operating system (that is, once every 30 seconds), which is the fastest but the most insecure way. Generally, it is enough to use the default value everysec, which not only gives consideration to the performance but also ensures the security.
After reading the book of redis internal coding optimization, I was quite puzzled, until I saw a blog.
This work adoptsCC agreementReprint must indicate the author and the link of this article