11/6 Add notes
modify redis-6379.conf Inside save10 second 2 Data changes (save 10 2)
Once the data is modified, the data does not change , modify 2 It's only when the data changes
Continue to modify the data , The discovery is still the same pattern
All additions and deletions should be changed , Besides checking .
save Configuration principle
Return results , To have an impact on the data , The data has changed , Or the variable meets the setting requirements ,rdb Will change .save The configuration should be set according to the real scene , Otherwise, there may be performance problems ,save After configuration, the execution is bgsave operation .
RDB2 Comparison of different starting modes
save Instructions are synchronized in the process of reading and writing , And dare not save It's asynchronous ,save The command blocks the customer service ,bgsave The process of reading and writing is asynchronous , Will create child threads ( It's like starting a new process ), It will not cause customer service congestion , But it will cause extra memory consumption .
rdb Special start command
Restart the server while it is running
debug reload
To shut down the server is to specify the data to be saved
shutdown save( Whether it's open enough , Automatic execution bgsave)
RDB Advantages and disadvantages
advantage :
RDB It's a compact compression Binary system file , representative Redis stay Some point in time Data snapshot on . Ideal for backup , Full scale replication and other scenarios . Like every 2 Hours to perform bgsave Backup , And put RDB Copy files to a remote machine or file system （ Such as hdfs）, For disaster recovery .RDB Recover data much faster than AOF The way .
shortcoming :
RDB Mode data can't be done Real time persistence / Second persistence , Maybe the data saved is not very complete . because bgsave Run every time fork Action create subprocess , Meeting Additional consumption performance , Frequent execution cost is too high .RDB Files are saved in a specific binary format ,Redis There are multiple formats in the version update process RDB edition , There is an old version Redis Service data format Not compatible new edition RDB Format The problem of .
AOF
Use AOF Why : in the light of RDB Problems that are not suitable for real-time persistence ,Redis Provides AOF Persistent way to solve .
Concept
AOF（append only file） Persistence ： Log the process of data generation ( Command every time you write ), Reexecute on reboot AOF The command in the file restores the data .AOF The main effect It solves the real-time problem of data persistence , So far Redis persistent Main stream The way
AOF Three strategies for writing data (appendfsync)
always( Every time ), Synchronize write operations to AOF In file , Data integrity , Low performance .
everysec( Per second ), Synchronize buffers to... Per second AOF In file , High data accuracy and performance , This command is usually used , Is also the default configuration
no( System control ), The operating system controls each synchronization to AOF in , The whole thing is out of control
Practice :
To configure :appendfilename Configure to appendonly.aof, If it's a multi port number , Recommended configuration is appendonly- Port number .aof
1. Get into conf Directory configuration redis-6379 Of conf file
2. Add the following command , Turn on persistence (appendonly yes|no), Configure write data policy (appendfsync always |everysec|no)
3. Kill the original service process first , Restart with the configuration file
4. Get into data, Check to see if there is one more in the document aof The file of
5. Add data and find that the file is getting bigger
6. In the use of everysec Instructions , Restart the server , Check the file size before modifying the data
7. After writing data , View file size , and cat file .aof journal , It was found that the data log was modified successfully
AOF rewrite
With AOF The files are getting bigger , It needs to be done regularly AOF File rewriting , Achieve the purpose of compression .
It is to convert the execution results of several commands of the same data into the corresponding instructions of the final result data .
Purpose :AOF Rewriting saves file space , Improve data recovery efficiency , Smaller AOF Files can be made faster by Redis load .
AOF Override method : Manual and automatic
Manual :bgrewriteaof( Background rewriting aof)
Automatically : auto-aof-rewrite-min-size size
`auto-aof-rewrite-percentage` *percentage*
Modify the configuration file
Start the customer service to modify the data
View files and view aof Document data
After the modification , start-up bgrewriteaof The following prompt appears
Again, the file size is significantly smaller
When I look at aof Data processing is garbled , Anyway, the file is compressed .
AOF Manual rewriting :bgrewriteaof How commands work
And bgsave The instructions are similar , The first is to send instructions ( The console will feed back Background append only file rewriting started), call fork Function generation subprocess , rewrite .aof file , Return message .
AOF Automatic override
Automatically override trigger condition settings auto-aof-rewrite-min-size size Automatically rewrite minimum volume , The default is 64MB.
auto-aof-rewrite-percentage percent On behalf of the current AOF File space And after the last rewrite AOF The ratio of file space .
aof_current_size AOF File space aof_base_size After the last rewrite AOF File space
Auto override trigger time
aof_current_size>auto-aof-rewrite-min-size &&（aof_current_size-aof_base_size）/aof_base_size>=auto-aof-rewrite-percentage
Enter... On the customer service side info, You can see Persistence( Persistence ), Something about persistence ,
AOF Rewrite process
RDB And AOF difference
RDB The resulting file has a higher compact compression ratio , It takes up less storage space , So read RDB Faster recovery . Because every time I generate RDB It's expensive , Storage is slow , Data may be lost ,RDB The consumption of resources is heavy , be relative to AOF Start priority is low .
AOF Persistence is achieved by appending write commands to files , adopt appendfsync Parameters can be controlled in real time / Second persistence . Because you need to keep adding commands , therefore AOF The volume of the file is getting larger , You need to perform rewriting operations on a regular basis to reduce the file size . Because of its large size , So it takes up a lot of storage space , And RDB comparison , It's the opposite , It takes up a lot of storage space , Storage speed is very fast , Recovery is slow , Because it's the storage of recorded data , It will be smaller after rewriting ,AOF It's lightweight in terms of resource consumption , Changing policies in different scenarios can improve data security .
RDB And AOF The electors of
Sensitive to the process of data , And if you don't ask for recovery speed , It is recommended to use AOF,
Data integrity is required , It is recommended to use RDB Persistence scheme , It's fast to recover .
If you can tolerate data loss within a few minutes , And pursue recovery speed , choose RDB
If you can't afford to lose data within a few minutes , Very sensitive to business data , choose AOF
Or both , priority of use AOF Restore data , Reduce the amount of data loss .
Persistent application scenarios
It's applied to rush buying , Limited purchase 、 A limited number of coupons will be issued 、 Data storage design of activation code and other services , Applied to data control with sequence of operations , Apply to the latest news display , Service control applied to control blacklist settings , Applied to the ranking of the counter combination sorting function .