关于分布式系统共享session数据的方式的问题

[高性能网络编程邮件列表]

网络处理的接入层模型基本上已经确定，主要的难点在于业务逻辑的处理，业务逻辑并发量大的时候单机处理不过来就需要多机分布，平行扩展，这样就带来
一个共享session数据的问题。
简单的session可以采用集中式的，比如memcached之类组件，业务逻辑server访问集中的session server获取
session处理逻辑，但是如果session数据多而复杂，而且一次业务逻辑请求需要访问多次，多个不同session数据时就会有性能问题，比如
网络游戏类的应用，怎么样的数据共享方式比较好些。

[sunway]

session server负责生成session其他业务逻辑服务器收到以后缓冲起来过期删除。

[stephen liu]

 

就目前经历过的情况来说，关于分布式 session 管理用到 memcached 算是一个比较适中的解决方案。

如果设计的架构要求的 session 管理超过 memcached 能处理的情况，

那么下一步要做的可能并不是寻求更复杂完善的 session 管理机制，

而是考虑改善架构，使得对于 session 管理的复杂度降低。

 

由于没有具体的案例，所以上面也是泛泛而谈，:)

 

在07-8-3，高性能网络编程邮件列表 <otto...@gmail.com> 写道：

[高性能网络编程邮件列表]

假定一个场景把, host_a, host_b 两台业务逻辑server, user_a, user_b两个session,使用
memcached存session，
如果一个请求到host_a，涉及到user_a,user_b两个session的数据和更新
这样就有至少四次host_a到memcached server的数据请求
getsession(user_a)
getsession(user_b)
updatesession(user_a)
updatesession(user_b)
memcached势必成为瓶颈

sunway说的那种方式我理解为
host_a 和 host_b 均持有user_a,user_b两个session，这样的情景如果session更新不多应该
ok,session更新
多的话网络io也没有减少，而且还有不同host的session数据同步的问题。

stephen liu说的改善架构，降低session 管理复杂度，能否深入一下，举个例子什么的，
可能不同应用不同解决

[xMan]

MMORPG网络游戏传统分布式架构对游戏逻辑的处理效率不可避免是最低的。

看来只有另寻出路才有前途。

[sunway]

MMO里一般session的每次登陆可能更新，其他时候不更新。而且session也就是一个key，作为
合法性检查。更新用户的数据有单独的服务器进行。

[stephen.nil]

Hi,

>>>假定一个场景把, host_a, host_b 两台业务逻辑server, user_a, user_b两个session,使用
>memcached存session，
>如果一个请求到host_a，涉及到user_a,user_b两个session的数据和更新

不知道这里提到的 session 是一个什么概念？
我通常是按 jsp 里面的 session 来理解的。
按 jsp 的 session 的含义，通常是不可能在一个请求中更新两个 session 的。

通常在两个 user 之间交换的是 message ，难道上面提到的 session 包含了一个 message queue ？


Best regards，

stephen.nil
2007-08-05

[stephen.nil]

Hi,

>>>假定一个场景把, host_a, host_b 两台业务逻辑server, user_a, user_b两个session,使用
>memcached存session，
>如果一个请求到host_a，涉及到user_a,user_b两个session的数据和更新

[xMan]

On 8月5日, 下午5时20分, sunway <sunhui...@gmail.com> wrote:
> MMO里一般session的每次登陆可能更新，其他时候不更新。而且session也就是一个key，作为
> 合法性检查。更新用户的数据有单独的服务器进行。

单是服务器与服务器之间的通信效率和消耗的时间成本就够让人头疼不已，不要说消耗在其他处理上的时间损耗了。

所以10多台服务器组成的传统分布式MMO服务器群，也就撑死才能支撑1500人同时在线，这类架构的服务器效率确实太低了点。

[sunway]

MMO 一组服务器带多少人和业务逻辑的复杂程度有关系，而且一般说来一组服务器绝对不只带1500人，
就我了解的MMO 单台地图服务器就可以带2K人，如果一组服务器3台地图服务器的话带6K人问题不大。

[高性能网络编程邮件列表]

我所说的session实际上是个比较广义的概念，可能是一个用户登录后的
所有的上下文信息。如果只是一个简单的用户标示，用单点的memcached
应该就没有问题了。

我没有做过mmo,sunway说的mmo的分布形式好像是用地图来分布服务器的。
整个地图划分成a,b,c,d四块的话用四台服务器A,B,C,D来实现，如果用户
从a过图到b,则把用户数据从A传到B, 不知道我的理解有没有问题。如果是
这样的结构，实际上服务器之间还是独立的，没有用户数据的共享，而且
一块地图上的人数受到单台服务器处理能力的限制。

其实我是想讨论一下用户数据在分布式系统中共享的方案，如果能够有好
的解决的话，应用到mmo，就不用有分区什么的，理论上几十万人在同一
个区，甚至同一个地图，没有限制。

[sunway]

ABCD4台服务器只是持有数据同时可以更新数据， 但是真正的数据由后台的
DB来保存，ABCD4台服务器定时保存用户数据而已，跨地图地图服务器之间根
据需要交换数据。
关于你提出的巨大容量的MMO之前已经讨论过了，由于用户的请求很难被分解
到不同的服务器，所以目前条件下很难实现巨量用户的MMO。

[xMan]

不知道sunway能否详细解释一下你所说的"ABCD4台服务器只是持有数据"都是持有了那些数据？能对用户行为做到什么样深度的支持？

[sunway]

MMO的主逻辑数据当然是持有用户的全部属性数据，比如装备，经验值等数据，
用户的大部分行为以及用户间的互动是主逻辑服务器都使用这些属性数据进行
逻辑处理。

On 8月6日, 上午11时20分, xMan <MESSAGE...@163.COM> wrote:
> 不知道sunway能否详细解释一下你所说的"ABCD4台服务器只是持有数据"都是持有了那些数据？能对用户行为做到什么样深度的支持？

[xMan]

请问，你所说的实现方式里即MMO的主逻辑数据里包括用户的同步数据吗？

请sunway详细解释一下，你上面所描述的方式能对用户行为做到什么样深度的支持？

另外，"...提出的巨大容量的MMO之前已经讨论过了，由于用户的请求很难被分解
到不同的服务器..."
意思是用户请求是被一台服务器集中处理的吗？为什么不能或者说很难被分解到不同的服务器中去？这样的架构所导致的直接后果都有些什么？

[sunway]

您可以搜索一下以前本邮件列表的帖子，很多具体细节需要亲自去做了以后才能体会。

[xMan]

都看了一遍，基本无解。

按sunway所说的MMO架构，ABCD4台服务器之间的用户是处于割裂状态，A服务器上的玩家不能实时与D服务器上的玩家进行买卖交易，虽然号
称"同时在线"却不能发生直接的交互行为，真是令玩家沮丧。

[关中刀客]

没办法的，想要同时多人在线，就要把人都分摊到各个服务器中去运动，这样子必然服务器之间信息交流回很麻烦

[BB.Case]

On 8月6日, 下午12时49分, xMan <MESSAGE...@163.COM> wrote:

分布式的系统毕竟是有局限性的，毕竟用双交线代替系统总线是个相当有技术难度的活。真正沮丧的不是玩家，想帮Intel完成这些工作，才要沮丧。

[xMan]

呵呵，怪不得采用传统分布式服务器端架构的牛头《魔兽WOW Online》也只能支持区区的1,500人。

采用LZ的方法就算能支持多一些的人，却不能完成WOW Online里的相应功能，算是短斤少两吧，呵呵