Shulou(Shulou.com)05/31 Report--

This article mainly explains the "publishing subscriptions and transactions in Redis knowledge collation", the content of the explanation is simple and clear, easy to learn and understand, the following please follow the editor's ideas slowly in-depth, together to study and learn "publishing subscriptions and transactions in Redis knowledge collation" bar!

1. Redis publish and subscribe

Redis publish subscription (pub/sub) is a mode of message communication: the sender (pub) sends the message and the subscriber (sub) receives the message.

Open two windows: session1 and session2

Subscribe to messages in session1:

Subscribe xbqChannel client subscribes to messages, and xbqChannel is the corresponding channel

Post a message in session2:

Publish xbqChannel testMessge publishes a message, and clients that subscribe to the channel can receive the message

II. Redis transaction

Like many other databases, Redis as a NoSQL database also provides a transaction mechanism. In Redis, the four commands MULTI/EXEC/DISCARD/WATCH are the cornerstones of our transactions.

Redis transactions have the following important characteristics:

All commands in the transaction will be executed sequentially, and during the transaction execution, Redis will not provide any service for the requests of other clients, thus ensuring that all commands in the transaction will be executed by atoms.

Compared with transactions in a relational database, if a command fails in a Redis transaction, subsequent commands will continue to be executed.

We can start a transaction with the MULTI command, which can be interpreted as a "BEGIN TRANSACTION" statement by people with experience in serial database development. Commands executed after this statement will be treated as operations within the transaction, and finally we can commit / roll back all operations within the transaction by executing the EXEC/DISCARD command. These two Redis commands can be considered equivalent to COMMIT/ROLLBACK statements in a relational database.

Before the transaction starts, if there is a communication failure between the client and the server and the network is disconnected, all subsequent statements to be executed will not be executed by the server. However, if the network outage event occurs after the client executes the EXEC command, then all commands in the transaction are executed by the server.

When using Append-Only mode, Redis writes all writes within the transaction to disk in this call by calling the system function write. However, if a system crash occurs during the writing process, such as downtime caused by a power failure, only part of the data may be written to disk, while the other part of the data may have been lost. The Redis server performs a series of necessary consistency checks when it restarts, and once a similar problem is found, it exits immediately and gives the appropriate error prompt. At this point, we need to make full use of the redis-check-aof tool provided in the Redis toolkit, which can help us locate data inconsistencies and roll back some of the data that has been written. After the repair, we can restart the Redis server again.

From the beginning to the execution of a transaction, it will go through the following three stages: start the transaction, order to join the queue, and execute the transaction.

III. Safety

1. Check the password of redis: config get requirepass

two。 How to set a password for redis:

Configure in redis.conf: requirepass xbqpass

Set it from the command line: redis > config set requirepass xbqpass

3. Authorization is required when operating on redis: redis > auth xbqpass

4. Persistence 1. RDB (Snapshotting snapshot persistence)

Snapshots are the default persistence method. This way is to write the in-memory data to the binary file as a snapshot, and the default file name is dump.rdb. You can configure how snapshots are persisted automatically. We can configure redis to take snapshots automatically if more than m key are modified within n seconds. The following is the default snapshot save configuration:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

Save 9001 # 900s if more than one key is modified, initiate snapshot save

Save 30010 # 300s if more than 10 key are modified, initiate snapshot save

Save 60 10000 # after 60 seconds (1 minute), if at least 10000 key changes, the dump memory snapshot

Client can also use the save or bgsave command to tell redis to persist a snapshot. Each snapshot persistence is a complete write of memory data to disk, rather than incremental synchronous dirty data. If there is a large amount of data and a lot of write operations, it will inevitably cause a large number of disk io operations, which may seriously affect performance. In addition, because the snapshot method is done at regular intervals, if the redis accidentally down, all changes since the last snapshot will be lost.

2. AOF (Append-only)

Redis appends every write command received to the file through the write function (default is appendonly.aof). When redis restarts, it rebuilds the contents of the entire database in memory by re-executing the write command saved in the file.

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

Appendonly yes # enable aof persistence mode

# appendfsync always # Force to write to disk every time you receive a write command, the slowest, but guaranteed to be fully persistent, not recommended

Appendfsync everysec # is forced to write to disk once per second, which makes a good tradeoff between performance and persistence. It is recommended

# appendfsync no # totally dependent on os, with the best performance and no guarantee of persistence

3. The advantages and disadvantages of RDB mechanism:

1.RDB advantages:

Once this approach is adopted, the entire Redis database will contain only one file, which is perfect for file backup. For example, you might plan to archive data for the last 24 hours every hour, as well as data for the last 30 days once a day. Through this backup strategy, in the event of a catastrophic failure of the system, we can recover very easily.

RDB is a very good choice for disaster recovery. Because we can easily compress a single file and then transfer it to other storage media.

Maximize performance. For the Redis service process, at the beginning of persistence, the only thing it needs to do is to fork the child process, and then the child process completes the persistence work, which can greatly prevent the service process from performing IO operations.

Compared with the AOF mechanism, if the dataset is large, the RDB startup efficiency will be higher.

2.RDB disadvantages:

If you want to ensure high availability of data, that is, to avoid data loss as much as possible, then RDB will not be a good choice. Because once the system goes down before timing persistence, data that has not been written to disk before will be lost.

Because RDB assists in data persistence through the help child process, if the dataset is large, it may cause the entire server to go out of service for hundreds of milliseconds, or even 1 second.

4. The advantages and disadvantages of AOF mechanism:

1.AOF advantages:

1)。 This mechanism can bring higher data security, that is, data persistence. Three synchronization strategies are provided in Redis, that is, synchronization per second, synchronization per modification, and async. In fact, synchronization per second is also done asynchronously, and its efficiency is also very high. The only difference is that once the system downtime occurs, then the modified data within this second will be lost. Every time we modify synchronization, we can think of it as synchronous persistence, that is, every data change that occurs is immediately recorded to disk. It can be predicted that this approach is the least efficient.

2)。 Because this mechanism uses append mode to write log files, even if there is a downtime in the writing process, it will not destroy the content that already exists in the log file. However, if we only write half the data this time and the system crashes, don't worry, we can use the redis-check-aof tool to help us solve the data consistency problem before the next startup of Redis.

3)。 If the log is too large, Redis can automatically enable the rewrite mechanism. That is, Redis constantly writes the modified data to the old disk file in append mode, and Redis also creates a new file to record which modification commands were executed during this period. Therefore, data security can be better guaranteed when rewrite switching is carried out.

4)。 AOF contains a clearly formatted, easy-to-understand log file for recording all changes. In fact, we can also complete the reconstruction of the data through this file.

2.AOF disadvantages:

For the same number of datasets, AOF files are usually larger than RDB files. Depending on the synchronization strategy, AOF tends to be slower than RDB in terms of efficiency. In short, the efficiency of synchronization per second policy is relatively high, and the efficiency of synchronization disable policy is as efficient as that of RDB.

3. How to repair corrupted AOF files:

1)。 Make an extra copy of the existing corrupted AOF file.

2)。 Execute the "redis-check-aof-- fix" command to repair the corrupted AOF file.

3)。 Restart the Redis server with the repaired AOF file.

Thank you for your reading, the above is the content of "publishing subscriptions and transaction knowledge points in Redis". After the study of this article, I believe you have a deeper understanding of the issue of publishing subscriptions and transaction knowledge points in Redis, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.