When to choose Redis

1. For complex data structures, it is more appropriate to choose redis

When the value is a complex data structure such as a hash, list, set, or ordered set, redis will be chosen because mc cannot meet these needs.

The most typical scenarios include user order list, user message, post comment list, etc.

2. Persistence, redis is more appropriate

mc cannot meet the persistence requirements, so it has to choose redis. However, one thing to note is, have you really ensured that you are using the persistence function of Redis correctly?

Never use redis as a database:

• Regular snapshots of redis cannot guarantee that data will not be lost;

• The AOF of redis will reduce efficiency and cannot support too large a volume of data;

Don't expect that redis will do better than mysql in solid storage. Different tools do what they are good at. Using redis as a database is probably wrong.

In caching scenarios, what are the pros and cons of turning on the curing function?

If it is just a caching scenario, the data is stored in the database and cached in redis. If you turn on the curing function at this time:

The advantage is that after redis hangs and then restarts, hot data can be quickly restored in the memory, without instant pressure on the database, and there is no cache preheating process.

The disadvantage is that during the process of redis hanging, if there are data modifications in the database, it may cause the database to be inconsistent with redis data after redis is restarted.

Therefore, for read-only scenarios, or to allow some inconsistent business scenarios, you can try to enable the solidification function of redis.

3. High availability, it is more appropriate to choose redis

redis naturally supports cluster functions and can achieve active replication and read-write separation.

Redis officially also provides sentinel cluster management tool, which can realize master-slave service monitoring and automatic failover. All of this is transparent to the client, without program changes or manual intervention.

Voiceover: Memcache, in order to achieve high availability, requires secondary development, such as dual reading and dual writing on the client side, or cluster synchronization on the server side.

However, what I want to remind you here is that in most business scenarios, does cache really need to be highly available?

• In caching scenarios, cache misses are often allowed;

• The cache is down, and data can often be read through DB;

Therefore, it is necessary to carefully analyze the business scenario, high availability, and whether it is true What is the main demand for caching?

Voiceover: In the instant messaging business, the user's online status has high availability requirements.

4. The stored content is relatively large, so it is more appropriate to choose redis.

The value storage of memcache is up to 1M. If the stored value is very large, only redis can be used. .

Of course, compared with memcache, redis also has some "disadvantages" due to differences in the underlying implementation mechanisms.

Scenario 1: Due to differences in memory allocation mechanisms, redis may cause memory fragmentation

memcache uses a pre-allocated memory pool to manage memory, which can save memory allocation time .

Redis temporarily applies for space, which may cause fragmentation.

From this point, mc will be faster.

Scenario 2: Due to the difference in virtual memory usage, redis may flush the disk and affect performance

memcache stores all data in physical memory.

Redis has its own VM mechanism, which can theoretically store more data than physical memory. When the data is exceeded, swap will be triggered to flush cold data to the disk. From this point, when the amount of data is large, mc will be faster.

Voiceover: The new version of redis has been optimized.

Case 3: Due to differences in network models, redis may affect IO scheduling due to CPU calculations

memcache uses a non-blocking IO multiplexing model, and redis also uses non-blocking IO reuse model.

But because redis also provides some sorting and aggregation functions other than KV storage, when executing these functions, complex CPU calculations will block the entire IO scheduling.

From this point, since redis provides more functions, mc will be faster.

Scenario 4: Due to differences in thread models, it is difficult for redis to use multi-core special effects to improve performance

memcache uses multi-threads, the main thread listens, and the worker sub-threads accept requests and execute During reading and writing, there may be lock conflicts.

Redis uses a single thread. Although there is no lock conflict, it is difficult to use the characteristics of multi-core to improve the overall throughput.

From this point, mc will be faster.

Scenario 5: Due to the lack of auto-sharding, redis can only be manually expanded horizontally

Whether it is redis or memcache, the server cluster does not naturally support horizontal expansion. It needs to be The client performs sharding, which is actually not friendly to the caller. It would be more perfect if the server cluster could support horizontal expansion.

Finally, this may be one of the reasons why many people like redis: the source code is highly readable and the code quality is very high.

I have seen the source code of redis and memcache. In terms of readability, redis is the software with the cleanest code I have ever seen, and there is no other software. Perhaps simplicity is the original intention of redis design. Compiling redis does not even require configure, there is no need to rely on third-party libraries, just make.

The memcache source code may have considered too much scalability and multi-system compatibility. The code is not clear and looks laborious.

For example, for the network IO part, only 1-2 files of the redis source code can be used. MC uses libevent. An FD is passed back and forth, through pipes and threads, which is particularly easy to confuse people.

The above is the detailed content of When to choose Redis. For more information, please follow other related articles on the PHP Chinese website!