What about the Memcache and Redis replacement session? Is there a redis that doesn't need a memcache?

Looking at the architecture of the Segmentfault, Redis is used, but is this session storage also used for Redis?

Reply content:

Looking at the architecture of the Segmentfault, Redis is used, but is this session storage also used for Redis?

Memcached Creator Dormando wrote two articles early on, warning developers not to store sessions with memcached.

http://mp.weixin.qq.com/s?__biz=MjM5NjQ4MjYwMQ==&mid=202805903&idx=2&sn= 94d0c60d0f86672aac527b658b7e1bcd#rd

1) First of all Redis and Memcache (abbreviated MC) trade-offs.
Redis is also a viable solution for many MC applications. MC has better performance when the key is larger. When the MC has a size limit of key (the default parameter is the maximum allowed to save 1MB of string, the default value of the-I parameter).
The performance of Redis is very inefficient in the case of large key. and choosing MC has better performance and throughput .
The following is the production test, 200 concurrent case, a single key is 500kB case.

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

The advantages of Redis are mainly reflected in two aspects:
1) Rich array structure, undoubtedly improve the development efficiency. List (queue), Set/zset, HashMap, hyperloglog are very useful.
Redis is a data structure server. Build a simple message queue, set deduplication, HashMap store simple relational data, Hyperloglog do a unique count, and so on.
2) Redis supports master-slave replication, providing the necessary conditions--multi replicas to build ha scenarios that support auto-failover. For example, the simple KeepAlive + VIP way.
3) In addition, the advent of Twemproxy,redis Sentinel and Redis-cluster allows operations or DBAs to build large-scale distributed cache systems. (I am a DBA myself)
For a specific comparison, see [http://segmentfault.net/q/1010000002588088?_ea=147671][1].

2) About session storage.
Session is the Web server side of the user behavior data stored in many ways. For example, the NFS shared file system, the Tomcat cluster provides shared session storage. Other storage in db (RDBMS) is also available.
After the advent of nosql, the common choices are Redis, MC, MongoDB. Redis, MC PHP directly provide the calling module (function), are very convenient to use.
Although many people say that session storage crash, the impact is not big, the user re-login. But I think the session data must not be lost.
1) First, the session data is lost, the user needs to re-login, the user experience is very poor.
2) for some shopping sites, session data is more important. Session data is important for tracking user behavior, such as recommending systems, Web site anti-brush systems (whether robots are crawling data).
Therefore, I personally agree with the idea of MC Development, do not use MC as session storage. With Redis, you can do data replication and HA scenarios.

Landlord should say is to replace the default file of the session.
Generally, it is better to use Memcache.
Unless Redis is used elsewhere in the project, you can also save Redis.

With Redis you don't need memcache, and with memcache you don't need redis.
Not necessarily not, but not necessarily so complicated.

1.SESSION is a storage mechanism, not a software
2. Although there are many areas of Redis and Memcache. But the storage of temporary data, or memcache more appropriate. Redis is primarily data in memory, timed or quantitatively written, so reads and writes are fast
The 3.SESSION can be stored in memcache or in Redis. But given the temporary nature of the session, it is considered more suitable for storage in memcache.

One of the most important reasons for using Redis for session sharing is that Redis supports hash structures (a session is essentially a hash table maintained by the server).

Suppose a scene to illustrate, now in session to deposit User ID, user picture two field information, if using memcached storage, there are two ways to store:

1. Use two keys to store user ID, user avatar, key1 = #userId, Key2 = #avatar

2. Use a map structure to wrap the user ID and user picture two fields so that the user ID and avatar information can be stored as an object, key = {userId: #userId, Avatar: #avatar}

Existing a business, need to remove #userid information from the session, the first storage method, you can directly use Key1 to find #userid, the second need to use key to package the user information to take out the whole, and then take out the #userid information, it is not difficult to see, The second way is to compare waste of network resources. The first way seems to be usable, but it is also a pit ~
There is another business that needs to remove the #userid and #avatar two field information from the session at the same time, the first way is to use Key1 and Key2 for two network interactions to obtain the required information (the more the number of fields, the greater the network overhead), instead use the second type, More cost-effective. This shows that it is not appropriate to use Memcached to achieve session sharing.
The same business scenario, using Redis, can store user information in a hash structure, as well as storing user information as a whole:

# 将用户信息作为一个整体写入RedisHMSET key userId #userId avatar #avatar name #name# 一次取出全部字段信息HGETALL key# 只取出其中一个或多个字段HGET key nameHMGET key name avatar...

It can be seen from the example that the network overhead is only needed once, whether it is to take out some or all of the information, and the same is true for the write, which proves that Redis is more suitable for session sharing than memcached.

