从这个流程中也可看出，这个处理过程必须是在用户发起请求时处理。需要注意的是，这个过程会需要考虑并发，即便是单个用户访问。假设一个用户访问页面，该页面同时发起4个请求。服务端同时处理这4个请求，都发现session的ip过多，于是删除旧session重新生成，造成一个问题：4个请求删除同一个旧session，然后生成了4个不同的session。为防止这种情况，使用了Redis对该session id加锁，并设置30秒自动过期，只有第一个获取锁的人执行重新生成，其他没获得锁的请求不处理。然后锁不用释放，自然过期即可。
正常而言，session已经被重新生成了，旧session id是走不到加锁session id这一步的。如果有，那一定是在重新生成之前就进来的请求，而这些请求本来就应该被忽略。反之，如果删除锁，这些请求将再次加锁并重新生成session，仍然会造成刚才说的问题，因此直接让锁自动过期即可。
如何手动测试假设IP数量限制为1个，打开A``B两台电脑，在A电脑上先登陆，打开Chrome开发者工具,复制laraval_session的值；然后传到B电脑，打开Chrome开发者工具，设置laravel_session的值，然后刷新下将发现变为登陆状态。再刷新下A电脑，将发现处于未登陆状态。
这个值则很主观，同时多个用户共享一个Session的问题实际是可避免的，具体参考《Remember Me的问题》的说明。因此不建议设置得太小，建议在5以上。
remember me的问题如果一个账号在线的存活期只有几个小时，那么上面说的问题影响范围都有限。为提高用户体验，用户一次登陆后可存活好几天甚至永久存活。提高存活时间有两种方法：
修改Session的过期时间
使用Remember Me的机制
上面管理Session的方案，在第1种方法下能顺利工作，但是在第2种方法下则没法工作。所以使用了Remember Me的方案，在管理机制上需要重新设计。
要理解这个问题所在，我们需要理解Remember Me的机制：用户登陆后，如果设置了Remember Me，服务器会生成remember me token，保存在数据库中，并将该token写入到cookie中。用户Session过期后，再次访问浏览器，服务端发现cookie中的remember me信息与数据库中的一致，就重新生成新的Session（见流程图）。
在了解上述机制后，即可发现,当remember me的用户超过session限制数量后，最早的session被删除，但由于该用户有remember me，所以会重新生成session自动恢复，也就说，删除session对remember me用户无效，会立刻重新生成。所以上述的session管理方案不应该开启remember me，否则是有问题的。
那为什么不直接Remember Me的方案呢？主要原因在于它的设计比较复杂，最终我们会切换成Remember Me的机制，将会另开一篇专门讨论。
附录 知识点Q:Session与登陆用户的关系？
A:严格来说，只要用户打开浏览器访问网站，就会产生Session标识一个会话，跟是否登陆无关。但是一般情况下，我们只关心登陆用户的Session，因此这里讨论上不做区分，只要产生Session就认为有登陆用户。
参考Chrome插件:SessionBox
redis加锁性能问题