The advantages and disadvantages of MemCache and Redis are compared
| MemCache | Redis | |
|---|---|---|
| type of data | key/walue | hash、string、lists、sets、zsets、sorted |
| distributed storage | support | Multiple ways, master-slave, sentinel, cluster, etc. |
| multithreading support | support | not support |
| memory management | have | none |
| transaction support | not support | limited support |
Memcache does not have a persistent function, so all data will be lost after power failure, and cannot be directly restored, which has reliability problems.
Memcache does not support transactions, so data inconsistency may occur during operations.
Redis synchronization scheme
When reading data, read the data in Redis first. If Redis does not have it, read it from the original database and update the data in Redis synchronously. When writing back, write it into the original database and update it to Redis synchronously. .
Centralized common solutions for Redis distributed storage
There are three common solutions for redis distributed storage:
1. Master/Slave mode;
2. Sentinel mode;
3. Cluster mode
The common ways of redis cluster slicing are:
1. The client implements sharding. The partition logic is implemented on the client, and the client uses consistent hashing to determine the redis node.
2. The middleware implements sharding. Between the application software and redis, such as Twemproxy, Codis, etc., the middleware realizes the route assignment from the service to the background redis node.
3. Client and server collaborate on sharding. Redis cluster cluster mode, the client uses consistent hashing, and the server provides redirection services for wrong nodes.
Redis persistence method
RDB
RDB is a persistence mechanism that stores snapshots supporting current data as a data file.
1. When generating a snapshot, fork the current process into a sub-process.
2. Then loop all the data in the sub-process and write the data into a binary file.
3. After the child process finishes writing the snapshot into the temporary file, replace the original snapshot file with the temporary file, and then the child process exits.
AOF
AOF: Redis is not enabled by default. It appears to make up for the insufficiency of RDB (data inconsistency), so it uses the form of a log to record each write operation and append it to the file. When Redis is restarted, the write command will be executed from front to back according to the content of the log file to complete the data recovery work. The working principle of AOF is to append write operations to the file, and the redundant content of the file will become more and more. So Redis has added a rewriting mechanism. When the size of the AOF file exceeds the set maximum value, Redis will compress the content of the AOF file
| AOF | RDB | |
|---|---|---|
| Data Disk Update Frequency | High frequency | low frequency |
| Data Security | higher | lower |
| data consistency | good consistency | poor |
| restart performance | poor | better |
| Data file size | big | Small |
Redis expiration clearing strategy
1. Periodically delete
Periodic deletion is similar to a daemon thread, which is executed every interval (100ms by default, you can adjust the number of times by modifying the hz option in the configuration file redis.conf), and delete the expired Key
2. Lazy deletion
Lazy deletion means that when a key is queried, it is judged whether the key has expired. If it has expired, it is deleted from the cache and returns empty.
3. Memory elimination
In the configuration file redis.conf, the maximum memory can be set through the parameter maxmemory. When the data memory reaches maxmemory, the redis memory elimination strategy will be triggered (we generally set this parameter to three quarters of the physical memory) .
When the memory of Redis exceeds the maximum allowed memory, Redis will trigger the memory elimination strategy. (The expiration strategy refers to clearing expired keys under normal circumstances, and memory elimination refers to the protection strategy when the memory exceeds the maximum value). The memory elimination strategy can be configured through maxmemory-policy. At present, Redis provides the following types (the strategy of 2 LFUs appeared after 4.0): volatile-
lru, for keys with an expiration time set, use the lru algorithm to eliminate them.
allkeys-lru, use the lru algorithm for all keys to eliminate.
volatile-lfu, for keys with expiration time set, use the lfu algorithm to eliminate them.
allkeys-lfu, use the lfu algorithm to eliminate all keys.
volatile-random, use random elimination from all keys with expiration time set.
allkeys-random, use the random elimination mechanism for all keys to be eliminated.
volatile-ttl, for the key with an expiration time set, the earlier the expiration time, the earlier it will be eliminated.
noeviction, no data will be eliminated, and when the used memory space exceeds the maxmemory value, an error will be returned when there is a write request.