Memcahed distributed cache service replaces Session Solution

 Requirements:

There is an ASP.. NET Website System, including the first-level domain name, second-level domain name, and third-level domain name. Each function module of the system is distributed across different domain names, servers of the same domain name may also be distributed in different provinces or different servers of the same province. servers of the same province can be accessed through the internal LAN. In the system, all function modules need to share the private data in the same session of the user.

The common method is to enable the Session persistent Session mode to meet the above requirements (not tried). Now we need to use the Memcached distributed cache service to save user Session data, in addition, each function module can share private data in this session across provinces and servers.

Solution:

Each province uses one server as the Memcached server to store session data. Of course, multiple servers can also be used, but the number of Memcached servers in each province must be consistent, in this way, the Memcached client can operate on the same data and ensure data consistency.

Add, delete, and modify session data:

When you add, delete, and modify session information data on the Memcached client, you must not only add, delete, or modify the data of the local Memcached server, in addition, you must perform the same operation on the Memcahed servers of other provinces. In this way, the user can access the function modules of the servers of other provinces to read the same session data. The Memcached Client Server LIST uses the Intranet IP address of the local area network (for example, 192.168.1.179) to operate the local Memcahed server, and uses the public IP address (for example, 202.183.62.210) to operate the Memcahe server in other provinces.

Read session data

The Memcached Client Server list of all modules in the system that read session data is set as the Intranet IP address of the local Memcached server address to read session data from the Memcahed server.

 

As shown in, Province A has four servers, and province B also has four servers. Both three servers have three Web servers and one Memcached server, in addition, the four servers in province A may access each other through the Intranet IP address in the same LAN, as in province B. Assume that one of the three Web servers A1, B1, and C1 in province A needs to add, modify, or delete session data, it first requests the Memcached client to enable the Intranet IP address of the D1 server to add or modify or delete session data to or from the D1 server. After the operation is completed, the Memcache client is also called to make the public IP address of the server D2 perform the same operation on the D2 server. This is a complete operation process and can also be processed as a transaction. Assume that one of the three Web servers A1, B1, and C1 in province A wants to read the session data, you only need to call the Memcached client to read the data from the Intranet IP address of the D1 server, if the data does not exist, it is used to add data to the Memcached server. The processing logic of province B is the same as that of province.

 Confirmation of the same session:

Use cookies to maintain contact between customers and the server. At the beginning of each session, a GUID is generated as the SessionID and saved in the Cookie of the client. The scope is the top-level domain name, so that the second-level and third-level domain names can share the Cookie, the SessionID is used in the system to check whether it is the same session.

Unique ID of session data

The unique Key of session data stored on the Memcached server, that is, the unique ID of session data, is defined as SessionID_Name. SessionID is the SessionID stored in the client Cookie, and Name is the Name of session data, the Name of each session data in the same session must be unique; otherwise, the new session data will overwrite the old session data.

Session expiration time:

Session invalidation is achieved by controlling the Cookie validity period. The session time is set to SessionID or the Cookie's validity period, and the Cookie validity period needs to be reset for each access to SessionID, in this way, the validity period of the session is the maximum time of the SessionID value in the Cookie for two accesses. If the interval between the two accesses exceeds the validity period, the Cookie stored in SessionID will expire and a new SessionID will be generated and stored in the Cookie. The session will end when the SessionID changes.

MemcachedSession data failure on the server

Each time session data is added to the Memcache server, the validity period is set to one day, that is, 24 hours, so that the Memcached service can use its internal mechanism to clear it, you do not have to delete session data in a program. The validity period of data in the Memcache server is logical. Even after 24 hours, if the memory allocated to the Memcached service is sufficient, the data is stored in the memory, but the Memcache client cannot read it. Only when the memory allocated to the Memcached service is insufficient will it clean up useless or old data, that is, lazy cleanup.

It's time to go to bed! I hope you can give me some advice!