redis persistence
redis master-slave replication
Jedis connection
redis Sentinel architecture:
------------------
RDP Snapshot:
By default, Redis database snapshots stored in the memory as a binary file name in dump.rdb.
You can set the Redis, when it "N seconds dataset has at least M changes" this condition is satisfied, automatically save a data set. For example, the following settings Redis will meet "within 60 seconds there have been at least 1000 key changes" when this condition, automatically save a data set: # save 60 1000 Close RDB only need to save all commented retention policy you can;
You can also manually execute the command to generate a snapshot of RDB, enter the redis client can execute commands save or generate dump.rdb bgsave file, each command will execute all redis memory snapshots to a new rdb file and overwrite the original file Snapshot rdb . save a synchronous command, bgsave is an asynchronous command, bgsave will (linux is a function fork ()) from the main process redis fork a child process designed to generate rdb snapshot file save and bgsave comparison: command save bgsave IO type synchronous asynchronous is blocked redis whether other commands (there will be a brief blockage in the generation of child process calls the fork function) complexity of O (n) O (n) advantage does not consume extra memory does not block client command drawback blocking client command needs to fork child process, consume memory configuration automatically generate rdb file back using bgsave way.
AOF（append-only file）
The snapshot feature is not very durable (durable): If for some reason Redis caused downtime, the server will lose the most recently written, and those data are not yet saved to the snapshot. From version 1.1, Redis adds a completely durable persistent way: AOF persistence, the modified file into the record every instruction in appendonly.aof.
From now on, whenever a change Redis execute command data sets (such as SET), this command will be appended to the end AOF file. In this case, when Redis is restarted, the program can achieve the purpose of reconstruction data sets by re-executing commands in the file AOF. How long before you can configure Redis will fsync data to disk once
Fsync on the implementation of a command each time a new file is added to the AOF, very slow, very safe: there are three options: appendfsync always. appendfsync everysec: fsync once per second, fast enough (and almost persistent use RDB), and only one second of data loss in case of failure. appendfsync no: Never fsync, the data to the operating system to handle. Faster and less safe choice. Recommended (and also the default) measures to fsync once per second, this strategy can take into account the fsync speed and security.
When mixed Redis 4.0 persistence restart Redis, we rarely use RDB to recover memory state, as it will lose large amounts of data. We usually use the AOF log replay, but replay log AOF performance RDB is relatively much slower, so that in a lot of cases Redis instance, start it takes a long time. Redis 4.0 To solve this problem, has brought a new persistence options - mixed persistence. Can be turned on by setting mixing persistence: # aof-use-rdb-preamble yes if turned mixed persistence, AOF when rewriting, no longer a mere memory write data conversion AOF file RESP command, but will before rewriting the memory of this moment to do RDB snapshot processing, and there will be a snapshot of the contents of RDB and incremental AOF modify memory data commands together, have written a new AOF file, start a new file is not called appendonly.aof, until AOF re-written the new file will be renamed atoms AOF overwrite the original file, complete the replacement of old and new AOF files. So when Redis reboot, you can load content RDB, and then replay log replay on incremental AOF AOF full amount before the file can be completely replaced, so the reboot efficiency significantly raised.
from redis master copy;
Build:
principle:
1, Slave service starts, active connection Master, and send SYNC command, the synchronization initialization request
2, Master after receiving SYNC, a write command BGSAVE command generates RDB files and caches that time period
3, after the completion of Master RDB file, send it to all the Slave server
4, Slave server after receiving the RDB file, delete the old cache data in memory, and loads the RDB file
5, Master after sending RDB, instantly send buffer write command to all Slave servers
6, this point completion of initialization, subsequent incremental synchronization
2. Partial replication:
Jedis connection:
https://blog.csdn.net/xiamaocheng/article/details/83277201
3.redis Sentinel architecture:
Sentinel is a special sentinel redis and does not provide service to read and write, is mainly used to monitor redis instance node. client-side for the first time to find the next sentry sentry architecture from the master node redis, direct access to follow-up on the primary node redis will not always by the master node sentinel proxy access redis when the master node redis changes, Sentinel will the first time perceived, and will inform the new master node redis assigned to the client (client-side there redis generally realized subscriptions, subscription news sentinel node changes published)
Increase from the foundation of the copy in the main:
4. Deploy Sentinel
enter just copy the good Redis-x64-Sentinel catalog
New sentinel.conf file
editor and add the following
Port 26379
#MASTER
Sentinel Monitor Master 127.0.0.1 6380 1
Sentinel Down-the After-Master 5000 milliseconds
Sentinel failover-timeout Master 180000
Parallel Master 1-syncs sentinel
cd to the directory Redis-x64-Sentinel
start sentinel service: redis-server.exe sentinel.conf --sentinel
Part of the reference Bowen:
https://www.cnblogs.com/cang12138/p/9132288.html#_label0
https://www.runoob.com/redis/redis-install.html
https://blog.csdn.net/tomy123456123456/article/details/81169665
