个人猜想的方案

First of all, we must clarify the difference between session and cookie. The browser side stores cookies. Every time the browser sends a request to the server, the HTTP header will automatically add your cookie information. The server uses the user's cookie as a key to find the corresponding value (session) in the storage.

Websites under the same domain name have the same cookies. Therefore, no matter how many servers there are, the cookie of the same user on which server the routeless request is distributed to is
unchanged. In other words, the session corresponding to the cookie is also unique.

Just ensure that multiple business servers access the same redis server (or cluster). This will achieve your goal. So your plan 2 is right

Since it is shared, of course it must be stored in the same Redis, which is your second option.

Use Redis to share the Session. The key is that the Session is deployed on Redis and stored in Redis. The file Session is no longer deployed locally.

Since you use redis to share sessions, it essentially means that there is only one instance of redis for you, but whether this instance only starts a redis service or deploys a redis cluster on multiple servers has nothing to do with your application layer. .

For applications with high reliability requirements, redis must be deployed into clusters, similar to the solution 1 you mentioned, but these redis are not isolated. There will be corresponding internal communication mechanisms between them to achieve sharding, redundant storage, etc. , there is no need to limit the location of redis when accessing. For example, you can access redis on B on server A, and the actual data storage of redis on B may be located on server C. All of this is fine for the application (client). It's a black box, no need to care.

php.ini contains session configuration. Change the configuration to redis or memcache, and don’t worry about anything else

Personally, I feel that sharing sessions is just a concept of sharing data. The data that originally needs to be saved in the session is migrated to redis for storage. Of course, it is also necessary to generate a unique sessionID like the session, and then pass it to the client and save it in a cookie. Every time the client makes a request, it needs to send the modified cookie together, and then obtain the corresponding data from redis.
In fact, when it comes to shared session, it is actually just a shared cache.

Of course I am talking about the concept. Maybe there are tools that can directly save the real session on the server to redis, but I think the concept is like this.

In fact, both of the above solutions are feasible. First of all, the first one can build a redis cluster to improve the stability and performance of the service and avoid single points of failure, which may lead to the loss of session cache data. The second option is to open a redis service on an additional machine. In order to improve the stability of the service, you can build a master-slave service. Cookies and sessions are similar to your key-value on redis