In my previous blog, I talked about the session sharing issue, which is about Web farm and Web garden Two cases of session processing. The following four modes are available in the session processing method provided by ASP:
1. InProc mode
This is the default session management mode of the ASP, which maintains the session within the application process.
2. StateServer mode
This is installed on the server. NET environment after a StateServer service, in the application process management session, can be multi-application session sharing, in my opinion this model is most suitable for the Web garden mode. This has been said in previous blogs.
3. SQL Server Mode
This is the hosting of the session using SQL Server. The advantage is that SQL Server can be used to deal with the massive session, outside the application process, durable, high security advantages. SQL Server mode is ideal for Web farm environments
4. Custom Mode
This is a custom mode, play a large space, in the case of owning provider, can use this mode to play, using a variety of data storage procedures for session management. Today's blog focuses on the application of the Redis hosted session under this model.
In the use of StateServer, SQL Server mode, I have encountered a very difficult problem: Session name control problem. When ASP. NET handles this problem, in order to ensure the unification of the application, ASP. NET hashes each app ID hosted on IIS and serves as a prefix stored in the database for SessionID. This leaves a problem, if there are multiple applications on a single server, you must ensure that each app's ID is exactly the same on different servers, or there will be a tragedy that the session cannot share. While we are deploying applications in order to tolerate disaster, it is entirely possible to put multiple applications on a single server, so be sure to note the consistency of the app IDs in IIS. A more troublesome usage is to use reflection to modify the SessionID generation rules or modify the database stored procedures, forcing the unification of the prefix, this method is more cumbersome, and to a certain extent, reduce the performance of the application, it is not recommended.
Today I recommend using a third-party provider escrow session. A lot of third party provider, such as Oracle,memecache,redis,mongodb, have a lot of provider, if you trust in your own technology, you can inherit System.Web.SessionState. Sessionstatestoreproviderbase this class for expansion.
And I'm using this Provider:Harbour.RedisSessionStateStore,
Github:https://github.com/thecloudlesssky/harbour.redissessionstatestore
This provider was developed on the basis of Servicestack.redis as a Redis driver.
It's very easy to use, first of all, to build your Redis environment, add Harbour.redissessionstatestore, Servicestack.redis, and then modify the configuration of Web. config as follows:
<system.web>
<sessionstate mode= "Custom" customprovider= "Redissessionstateprovider" >
<providers>
<clear/>
<add name= "Redissessionstateprovider"
Type= "Harbour.RedisSessionStateStore.RedisSessionStateStoreProvider"
Host= "localhost:6379" clienttype= "Pooled"/>
</providers>
</sessionState>
</system.web>
The most critical of these is the host property, which points to the ip/port of your Redis service. In Redis, you can also configure a password for Redis, and the configuration file needs to be modified with the host property: [Email protected]:6379. ClientType is set to pooled connection pool mode by default. If you do not use the connection pooling mode, modify to a different string (empty is also considered pooled mode).
This provider has a feature that does not prefix the session with the app ID, which is exactly what I need, which is more convenient for session sharing between multiple systems. Next, configure the cookie domain to have all the apps that need to share the session under the same top-level domain:
<system.web>
This is done with the Redis hosted session.
Asp. NET cross-app sharing session and using Redis for session hosting Introduction