现在提到多服务器的共享session，几乎都是回答用redis。
对于redis实现几台服务器共享session，不是很理解。
假如一个网站分别部署在A B C 3 台服务器上，他们的代码都是相同的。用户在访问的过程中是随机切换到其他服务器，使用redis来共享session，那么是这3台服务器是如何实现session 实时共享的？
方案一：
A B C 三台服务器上每台服务器都部署session，PHP 直接连本台服务器的 127.0.0.1 的REDIS进行操作SESSION，通过本地REDIS进程他们相互的配置好了相互的共享机制？所以就实现了三台服务器SESSION实时共享
方案二：
将REDIS 另外的部署到第四台服务器D, A B C 三台服务器上的PHP配置连接的REDIS是这台D服务器。那么就实现了统一的SESSION 实时共享，这样貌似不正确。
很疑惑Redis SESSION 实时共享到底是如何实现的？
这三台服务器的PHP 都是连接到本地的127.0.0.1 6379 的REDIS 还是？
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
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