The problem analysis of Redis as a database persistence substitution scheme

Currently Redis supports two persistence modes, one is snapshotting (snapshot) and the other is Append-only file (AOF).

Snapshotting (snapshot): The default persistence mode, which is to write in-memory data to a binary file in a snapshot (the default file is Dump.rdb).
Append-only file (AOF): This mode of Redis appends each received write command to a file (the default file is Appendonly.aof). When Redis restarts, the contents of the entire database are rebuilt in memory by re-executing the Write command saved in the file.
There are three ways to force write disks in AOF mode:
(1) Appendfsync always: Force write to disk as soon as you receive a write command, the slowest performance, but guaranteed full persistence (deprecated)
(2) Appendfsync everysec: Force write disk once per second, a good compromise in performance and persistence
(3) Appendfsync No: Full reliance on OS, best performance, no guarantee of persistence

The advantage of the snapshot is that the binary size is smaller than the AoF log file, but it loses data from the last successful backup time to the outage time; the AoF log file is large, but the file is not easy to lose relative to the snapshot. The current Redis check data file for errors can be supported for both snapshots and aof, but the fix is only valid for aof files.

Therefore, in order to ensure data integrity, we need to use the AOF mode, and the use of appendfsync always, but this performance is lower than the use of MySQL, if we choose Appendfsync everysec Way, Redis periodically flush the in-memory data into persistent storage, so that once the Redis server crash out, some of the data may not flush into the persisted storage.

In addition, Redis does not have an official cluster solution, the cluster support is not very good, for master-slave synchronization is also a master multi-slave.

Other aspects of the problem:

Application development issues
(1) need to convert all application-level relational data structures to key/value form
(2) Less data types supported
(3) Large data structure list,sorted set,hash set batch processing means waiting for other requests, so the use of Redis complex data structure needs to control the size of its single key-struct.

Data query problems
(1) Weak query function
(2) Efficiency of queries

Planning design issues that are used by the cache.
Detailed planning is needed before use. For example, how much data and what data needs to be stored in memory will directly affect the system-related design.
For example, historical data or data with less user access should not be put into memory to reduce memory pressure.

Data Recovery Issues
A large amount of data after the failure recovery will bring greater system pressure, and the use of additional memory, may lead to low system memory and other online failures.

Therefore, the ability to use Redis as an alternative to the database depends on how well we can handle persistence and other related issues.