What if memcache and redis replace session? Is memcache unnecessary for redis?

After reading the architecture of zhihu and segmentfault, redis is used. But is redis used for session storage? After reading the architecture of zhihu and segmentfault, redis is used. But is redis used for session storage?

Reply content:

After reading the architecture of zhihu and segmentfault, redis is used. But is redis used for session storage?

Memcached creator dormano wrote two articles very early [1] [2], telling developers not to use memcached to store sessions.

Http://mp.weixin.qq.com? _ Biz = MjM5NjQ4MjYwMQ ==& mid = 202805903 & idx = 2 & sn = 94d0c60d0f86672aac527b658b7e1bcd # rd

1) First, the redis and memcache (hereinafter abbreviated as mc) should be selected.
Redis is also a feasible solution in many mc application scenarios. When the key is relatively large, mc has better performance. If mc has a key size limit (the default parameter allows up to 1 MB of strings to be stored, the default value of-I parameter ).
Redis has very low read/write performance when the key is large.The choice of mc has better performance and throughput.
The following is a production test. The 200 concurrency is the case where a single key is kb.

     redis-benchmark -d 500000 -t get,set -n 1000 -c  200 -q      SET: 306.84 requests per second     GET: 1449.28 requests per second

Redis has two advantages:
1) The Rich Array Structure undoubtedly improves the development efficiency. List (queue), set/zset, hashmap, and HyperLogLog are very useful.
Redis is a data structure server. Create a simple message queue, set deduplication, hashmap to store simple relational data, and HyperLogLog to perform unique counting.
2) redis supports master-slave replication and provides the necessary conditions for building an ha solution that supports auto-failover-multi replicas. For example, the simple keepalive + vip method.
3) In addition, the emergence of twemproxy, redis sentinel, and redis-cluster allows O & M or DBA to build a large-scale distributed cache system. (I am a DBA)
For more information, see [http://segmentfault.net/q/1010000002588088? _ Ea = 147671] [1].

2) about session storage.
Session is the user behavior data stored on the web server. There are many storage methods. For example, in the nfs shared file system, the tomcat cluster provides shared session storage. Others are also stored in db (RDBMS.
After the emergence of nosql, common options include redis, mc, and mongodb. Php of redis and mc directly provides call modules (functions), which are easy to use.
Although many people say that the session storage crash has little impact, it is a big deal for users to log on again. However, I think session data cannot be lost.
1) First, session data is lost and users need to log on again. The user experience is very poor.
2) session data is more important for some shopping websites. Session data is very important for tracking user behaviors, such as recommendation systems and website anti-click farming systems (whether robots are crawling data ).
Therefore, I personally agree with mc development and do not use mc as session storage. Redis can be used for data replication and ha solutions.

What the landlord should say is to replace the default file session.
Generally, memcache is enough,
Unless redis is used elsewhere in the project, save it as well,

Memcache is not required for redis, but redis is not required for memcache.
Not necessarily not, but not so complicated.

1. SESSION is a storage mechanism, not software.
2. Although redis and memcache are the same in many places. However, it is more appropriate for memcache to store temporary data. Redis is mainly used to write data in memory at regular or quantitative intervals, so reading and writing are fast.
3. sessions can be stored in both memcache and redis. However, considering the temporary nature of the SESSION, I personally think it is more suitable for storing it in memcache.

The most important reason for using Redis for Session sharing is that Redis supports the Hash structure (Session is essentially a Hash table maintained by the server ).

Assume that the user ID and user profile information should be stored in the Session. If Memcached is used for storage, there are two ways to store the information:

1. Store the user ID and user avatar with two keys respectively. key1 = # userId and key2 = # avatar

2. Use a Map structure to package the user ID and user avatar fields, so that the user ID and profile information can be stored as an object. key = {userId: # userId, avatar: # avatar}

An existing business needs to retrieve # userId information from the Session. The first storage method can be found directly using key1 # userId, in the second method, you need to use the key to retrieve the encapsulated user information and then extract the # userId information. It is not difficult to see that the second method is a waste of network resources. The first method seems to be available, but it is actually a pitfall ~
For another business, you need to retrieve the information of the # userId and # avatar fields from the Session simultaneously, the first method requires two network interactions using key1 and key2 respectively to obtain the required information (the more fields, the larger the network overhead). Instead, the second method is more cost-effective. Therefore, it is inappropriate to use memcached for Session sharing.
In the same business scenario, Redis can store user information in a Hash structure and store user information as a whole:

# Write user information as a whole into RedisHMSET key userId # userId avatar # avatar name # retrieve all field information at a time HGETALL key # retrieve only one or more of the fields HGET key namehmet key name avatar...

From the example, we can see that the network overhead is only required once, whether it is to retrieve part of the information or all of the information. The same principle is true for writing, it can also prove that Redis is more suitable for Session sharing than Memcached.