Game snake-join session to tornado-Cross-primary domain-cross-application server farm Principle

Warning!

Reading this article requires the ability to use Python programming and web programming experience. At least you should know what python is and what session is. Beginners should be careful when entering, some descriptions are not detailed, be careful when going astray, and welcome experts to make bricks. This articleCodeIt is used only as an example to describe the process and method of implementing session in tornado. It has not been compiled or run. Do not copy it to the project directly, I am not responsible for the consequences of this behavior. (This article is intended for commercial projects and cannot provide source code directly)

 

The so-called warm thinking YY, yesterday we solved the problem of using session in tornado, so further, when we need to split the application horizontally, if you want to maintain the data in sessions and sessions, you need to do some additional work to deploy some functions separately on different servers under different domain names. Many websites use the method of forcibly specifying the cookie domain name to the primary domain, but this poses a security risk, so we do not intend to do so. According to yesterday's analysis, we can know that the session depends on cookies to maintain its sessionid. Therefore, if we need to enable cross-Origin Cross-Server session, we need to solve two problems, the first is the cross-domain Cross-server storage, and the second is that sessionid should be securely transmitted to different application servers. The storage solution is better, and all session data should be consistent with their own applications, therefore, all servers are accessible. You can deploy memcached on a single session server to share the access, or MySQL, or other network databases (SQL or nosql ). The second is to share the sessionid. Session sessions are mainly used to record the information of logged-on users. Therefore, we assume that the session used to log on to the server is the main one. The process of synchronizing sessionid is similar to that of SSO. The process is as follows:

We use the encrypted token to synchronize the sessionid. This process is almost the same as the SSO process. In this way, even if each application is in a different primary domain, the application can use the session normally. This method is easier to exit than SSO. You only need to delete the data items in memcached so that all applications can naturally exit. Because each module has a sessionid after synchronization, therefore, you can exit any application by deleting the session.

 

The specific code will be further discussed in the next chapter.