Which of the following is better if Session is stored in Redis and memcache?

Who can make a comprehensive evaluation of the shortcomings? it would be better to provide relevant information. For example, under what circumstances is memcache suitable for redis? Who can make a comprehensive evaluation of the shortcomings? it would be better to provide relevant information.
For example, under what circumstances is memcache suitable for redis?

Reply content:

Who can make a comprehensive evaluation of the shortcomings? it would be better to provide relevant information.
For example, under what circumstances is memcache suitable for redis?

Well, I am not here to answer the question... I am from the destruction of the image... so let's start it...

Although memcache and redis are often compared with each other, these two are not actually the same...

Memcache... is a cache... and redis... is a database...

For this question... in my limited scope of knowledge and one-sided practical observation... my answer is...

InSuitable for storing in memcache when the ultimate perfection is pursued and the application logic is simple...Applicable to redis in any other circumstances...

More specifically... in 99.99%, php sessions are suitable for redis...

Okay, I know this answer is very hurtful... more answers are welcome to provide different opinions...

As the first batch of people in China who use memcache... I basically gave up memcache shortly after using redis...

Memcache is not useless... it is the only advantage compared with the current redis... it is fast...

In the same environment, the same load, the same k/v structure data...

When a single piece of data is relatively small... whether it's reading or writing... memcache is always dozens of μs faster than redis...

Although the gap is negligible, redis never won...

If you really care about the time gap... well... you have the potential to become 0.01%... but not...

Now let's look at your application scenario... to be the 0.01%... you can only store one unit in your session...

For example, only store the user name to obtain the corresponding key to username... instead of an array...

Because both serialize/set and get/unserialize are slower than hSet and hGet...

We had a hard time fighting for dozens of μs... and the result was wasted...

If you can do a good job in this architecture... the 0.01% club door is opening for you...

But wait... let alone performance... imagine two more scenarios...

Scenario 1... if the machine storing the session is restarted...

The consequence of using memcache is that all users must re-obtain the session... the instantaneous database pressure will be high...

Redis won't be used. at best, it's just about losing sessions that haven't been saved...

Scenario 2... if a large number of users suddenly generate a large amount of data to fill up the memory of the machine storing the session...

Memcache will strike... if all the keys do not expire, they will constantly overwrite the last written data...

Redis will only slow down... it will not affect the logic of the program...

If you confirm that none of these will happen... welcome to use memcache to meet your pursuit of extreme perfect efficiency...

Basically, I still use memcache to store Sessions. as far as I know, there are only two types of users...

The first category is to pursue perfection and dazzling technologies... that is, 0.01%...

The second type is outdated or the code is too complex to be replaced...

If you are not in these two categories... welcome to the mainstream redis...

This is basically the case... I don't know how much I have written while thinking about writing...

In fact, this topic is not very well answered... if you want to expand it, it can be expanded to a very large scale... all you need to do is to generate a thesis...

This is where I want to write... some points can be thought of, but I don't know how to describe it when it comes to text...

For example, memory management... distributed applications for multi-core CPUs...

The more you think about it, the less clear it will be. The text may be a bit messy...

Anyway, I am here to destroy the image... welcome to the Battle of the memcache party...

For a single k-v cache, memcache is the best choice. its advantage lies in its simplicity and speed.

However, if you need to store ing or fields, or if you want to store a sorted list or sortable set, Redis is the most suitable.

I personally think there are still a lot of deficiencies in Redis database, at least in data persistence. Therefore, Redis and memcache are the same, and the main application scenarios are cache.

If you only want to store sessions, I personally suggest using Memcached, which is fast and simple to use. but if you need to do something persistent, you still need to use Redis. My suggestion is that you reserve the two interfaces when designing the system, and you can switch between them at any time.