有些话，哪一篇博客上也不会说的。可能是因为这些话实在是太愚蠢了，不值得一提，更不可能有人去这样做。但是我恰恰成为了这个愚蠢的人。这些愚蠢事迹应该好好记录一下，吃一堑长一智。
今天的话题是，有一个网站，由若干个Application组成，这个网站需要一个登录服务：
（1）每一个人只能够登录一次，第二次登录的人会将第一次登陆人Kick掉；
（2）如果这个人已经登陆了，需要提示第二次登录的人是否要继续登录；
（3）如果这个人没有按“注销”就闪人了（例如关闭了浏览器），那么一天之后，这个人会自动被Kick；
（4）执行该网站的任意操作都将验证用户是否已经登录，如果他注销了，抑或被提出了，那么Kick。
从需求上看，这个登录服务需要维持用户的登录状态…那么你会如何设计和部署这个服务呢？OK，我将他作为登录应用程序的一部分部署在了IIS中。
这造成了严重的问题：网络应用程序（池）的生命周期和登录服务期望的生命周期是不一致的。
错误：认为登录网站启动时，在线用户登录服务（保存了登录用户状态信息的列表）也启动了，当网站销毁时，在线用户登录服务也销毁了
这就是我愚蠢的观点。OK，以IIS为例，（6.0之后）网络应用程序运行在指定的应用程序池中，应用程序池为了保证应用程序的可靠性，有自主回收的机制（可设置）。例如：每x小时回收，内存占用到x回收，请求数达到x回收。另外还有空闲释放机制：空闲时间x自动关闭工作进程。
你说这不是害人吗，这样不是会出现莫名其妙的用户被踢出的问题吗？Yeah，你答对了。但是做网站的人都知道，网站，是没有状态的。所以应用程序池即使回收再启动了也不会影响到用户的使用，他们会觉得速度突然快了。这个太愚蠢了，不值得一提。
那怎么解决呢？有一个好方法，也有一个残喘方法；
可能是好方法：登录网站仅仅负责UI上的用户交互和Cookie信息的存取，至于在线用户状态的保持，则Host在系统服务中（对于MS 平台的，例如Windows服务），自主控制资源和生命周期；
苟延残喘的方法：将IIS中相关的设置全部都关掉，然后告诉网站管理员：如果你觉得你的网站越来越慢以至于无法接受了的时候，自行重新启动网站吧。
希望没有别人再步后尘。