Redis transaction understanding

Redis transaction understanding


1. Redis runs in the form of a single process, and commands are executed one after another.
2. In fact, there is no concurrency problem in redis, because it is a single process, no matter how many commands are one performed by one. When we apply, there
may be concurrency problems. (For example, after reading and then changing, if other applications write between reading and writing, there will be concurrency problems.)



Transactions
in redis There are also transactions in redis, but this transaction There is no improvement in mysql, only consistency and isolation are guaranteed, and atomicity and durability are not satisfied.
Edis transactions use multi and exec commands
1. Atomicity, if a command fails to be executed in a redis transaction, the subsequent commands will still be executed and will not be automatically rolled back.
The kill signal, host downtime, etc. cause transaction execution failure, and redis will not retry or roll back.
2. Persistence. The persistence of redis transactions depends on the persistence mode used by redis. Unfortunately, various persistence modes are not persistent (data may also be lost).
3. Isolation, redis is a single process. After the transaction is started, all the commands of the current connection will be executed until the exec command is encountered, and then the commands of other connections will be processed.



Persistence mode (AOF, RDB)
AOF
1.AOF persistently records all write commands executed by the server, and restores the dataset by re-executing these commands when the server starts.
2. The commands in the AOF file are all saved in the format of the Redis protocol, and new commands will be appended to the end of the file. Redis can also rewrite the AOF file in the background,
so that the size of the AOF file does not exceed the actual size required to save the state of the dataset.
3. This saving is performed by a background thread, the main thread will not block until the saving is successful, so there is still a very small interval between the successful execution of the command and the saving of the data to the hard disk, so the transaction in
this mode is also not durable.

Advantages of AOF:
1. Using AOF persistence will make Redis very durable (much more durable): you can set different fsync strategies, such as no fsync, fsync
once per second, or fsync every time a write command is executed .
2. The default policy of AOF is fsync once per second. Under this configuration, Redis can still maintain good performance, and even if there is a failure, only one second of data
will be ( fsync will be executed in a background thread , so the main thread can continue to work hard on the command request).
3. The AOF file is an append only log file, so writing to the AOF file does not require seek, even if the log contains incomplete commands
for some reason (such as writing full disk, write downtime, etc.), the redis-check-aof tool can
easily fix this too.
4. Redis can automatically rewrite AOF in the background when the size of the AOF file becomes too large: The new AOF file after rewriting contains the minimum command set
required .

Disadvantages of AOF:
1. For the same dataset, the volume of AOF files is usually larger than that of RDB files.
2. Depending on the fsync strategy used, AOF may be slower than RDB.


RDB
RDB persistence can generate point-in-time snapshots of datasets at specified time intervals.

Advantages of RDB:
1. RDB is a very compact file, which saves Redis at a certain time Dataset on point (how often to back up).
2. It's only one file, and the content is so compact that it can be sent (after encryption) to another data center.
3. RDB can maximize the performance of Redis: the only thing the parent process has to do when saving the RDB file is
to all the subsequent saving work, and the parent process does not need to perform any disk I. /O operation.
4. RDB is faster than AOF when recovering large data sets.

Disadvantages of RDB:
If you need to try to avoid losing data in the event of a server failure, then RDB is not for you. (There is a backup time interval)


The selection criteria of RDB and AOF are based
on whether the system is willing to sacrifice some performance in exchange for higher cache consistency (aof), or is willing to not enable backup in exchange for frequent write operations For
higher performance, do a backup (rdb) when manually running save.



Jedis connection pool
1. It is to build multiple connections at the beginning and put them in the pool. When the thread needs one, apply for one back from the pool, and release it back to the pool when it is used up.
2. A single Jedis instance is not thread-safe (Because there may be public parts in it).
3. To avoid these problems, you can use JedisPool, which is a thread-safe network connection pool. (because each thread is drawn from the connection pool
Get a Jedis instance, the thread has to be exclusive, so it is thread-safe)
4. Of course, each thread can also build a Jedis instance by itself, but each thread builds a Jedis instance by itself, which will establish many sokcet connections, which will affect performance.



Reference text: http://blog.csdn.net/jackpk/article/details/30073097
Reference text: http://www.cnblogs.com/iforever/p/5796902.html