1. encrypt and store user IDs in cookies
1. Store user IDs in cookies in reversible encryption mode. When the user logs in successfully, the ID is encrypted and stored. The user visits page a for the first time and obtains user information by decrypting the ID. If the decryption is successful, the user can call SOA (or other distributed service implementation, which can achieve arbitrary expansion without changing the caller, then, the user information is stored in the session. If the user jumps from page a to page B, the user information can also be obtained through decryption. The problem is that a large number of login services are accessed, reducing the session utilization. If the same user's fixed load is balanced to the same server, high session utilization can be achieved.
2. You can change the key at any time, but all servers must use the same key; otherwise, confusion may occur.
3. If the client disables cookies, a fatal problem occurs.
4. The cookie capacity is limited. The data volume stored must be strictly controlled and a set of information must be written to the same cookie to avoid excessive cookies.
2. Write sessions to distributed shared caches such as memcache and redis.
1. The disaster recovery mechanism of distributed cache must be implemented. Otherwise, a machine will fail and a large number of users will not be able to log on.
2. horizontal scaling will increase the maintenance cost of distributed cache.
3. Store sessions in the database.
1. High reliability, process failure, and handling.
2. SeparateProgramDatabase overhead.
3. The database is a single point and can be solved using hash.
4. NET provides the ability to store sessions in the memory.
1. it can be the memory of the server that stores sessions separately, or the memory of the same machine as IIS. clustering is difficult. If the session is stored on a separate machine, it is also a single point, with risks. If it is stored on the same machine as IIS, clustering is not easy to implement, and load balancing is restricted, you must ensure that the same user has been accessing the same machine to ensure session.
5. Net also provides session storage in IIS processes.
1. The problem is that the session is stored in the memory.
2. At the same time, due to a common process with IIS, the session may not be used due to IIS problems, and the chance of a crash increases.
6. bored with the idea of a custom session solution.
1. encrypt and store user IDs in cookies, decrypt the user IDs through "method 1", and store user information on memcache/redis, take more user information from the distributed cache first. If the user information is not obtained from the database, the user information is cached asynchronously and the distributed cache is eliminated.AlgorithmIs the least recently used method. The implementation method is encapsulated in the base class and stored in the distributed cache based on ID key/value data. You can recover the user's main information from the database even if the user fails.
2. This method is a combination of encryption algorithms and distributed cache.
7. Share the session value of net. You must configure the machinekey.
1. Configure sessionstate to set nodes and use StateServer or sqlserver to share sessions.
To achieve cross-server sharing, you must configure in Web. config:
<Machinekey decryptionkey = "partition" validationkey = "partition" validation = "sha1" decryption = "Auto"/>; that is, the cluster must have the same value.