做项目了，NetCL今天开工了，在这些日子里，我会将自己研究的内容写下来。做个记录，以下是我在网上搜到的。关于管理用户状态的解决方案，当然，我都有一个方案。不过对客户端的任务有点重吧，我方法是客户端从服务器端获到一个用户在线状态后，接着就与服务器无关了。好友离线在线都在客户端维护(向自己的好友发送保活包)，呵呵。我这种架构有点吓人吧~~好，我们来看看下面是怎样说了。

以下的内容不是原创，版权归原作者所有。

首先做以下假设:
(1)维护100万在线用户的状态需要多大的内存空间?
(2)从100万在线用户中检索出自己需要的数据需要多少时间?


第一个问题我们可以这样来定性:
设每用户占用的内存空间为:
SessionID会话标识(int)+AccountID用户账号ID(int)+loginTime登录时间(long)+其它状态(假设用4个byte型­来标明4个状态)=20字节
100万用户*20字节=20,000,000(字节)=19,531.25K==19M(约)
注:一条记录就表示一个在线用户；


(我靠,我的计算是不是有错误,一台386的内存都够了.....)
看上去,似乎用一台服务器做状态服务器是没有什么问题的；


第二个问题,我们这样来定性:
假设在服务器端的内存中使用如hashTable这样的存储结构来保存用户的会话状态,hashTable的读操作为0/m复杂度,从100万个记录中读取一条­记录的寻址时间那是相当的快的,快到无法用毫秒来计算,只能用tick(一个CPU的时钟滴答)来计算。1个毫秒=10,000个tick(毫微秒),（has­hTable的操作平均值是多少我没有统计过不好意思。我就猜个值吧：假设平均为100个tick)，如果每次存取hashtable要花费100Tick,另­外在加上一些业务处理的时间，就按操作一次数据表要1个毫秒来计算吧。
那么1秒钟的时间内就可以处理1000次用户的查询操作；
问题是如果100万用户同时来查询我们该怎么办？
我想可以做负载均衡及服务器集群，当然还要涉汲到网络接口的流量限制，说来就话很长了。
总之，第二个问题看起来，似乎是我们可以通过其它的手段将单台服务器无法处理的工作量分摊到多台服务器中去进行；


于是可以得出第一个背景结论：
设置一台服务器将其做为用户状态服务器，用于记录系统中所有用户是否在线等状态信息；通过对服务器制作集群来分摊访问压力；


现在我们就可以做以下比较形象的结论和假设了：
(1)一个用户要查询自己所有好友的在线状态，那么这个用户向刚才所说到的状态服务器发送一条查询消息，服务器可以很快的返回用户的状态给客户；
(2)用户在登录系统后通知状态服务器自己已经登陆了。
(3)用户如果从某台具体的功能服务器掉线后，则由这台服务器通知状态服务器用户掉线；
(4)用户可能会在多台功能服务器中来回切换，由客户端与服务器端共同协作以判断用户是为否掉线;
(5)用户定期向状态服务器报告自己的存活状态，如果长时间不报告，则状态服务器把用户从自己的内存状态表中删除；


以上我的瞎解，不一定对，必竞自己没有做过,仅供参考。

-----------------------------------------------------------

呵呵，他这种思路让我认识到服务器的加入有必要性。加入了服务器，一切都好办。另外他维持用户状态时，方法是可行的。向每个好友发一个保活包（俺的方法），还是给服务器发一个保活包（他的方法）那要看你的了。我还在思考呢！！！