所谓服务集群，实质就是对数据的演算。牵扯到数据的读取，写入，缓冲。
就拿游戏服务来举例：
玩家登录游戏，需要将玩家的数据读出来以便为这个玩家演算，玩家下线了需要持久化数据。但是现在的架构基本都是分布式的，特别是实时游戏会出现高频的消息反应（reactor，就是一个消息会造成很多计算量和IO，比如移动需要广播给周围的玩家，释放技能造成的连锁反应），而为了解决这种高频消息反应，一般有二种架构模式，1. 基于区块的集中式划分。 2. 基于功能的分布式划分。第一种就是大部分游戏采用的分场景，一根逻辑线程驱动一个场景，一个游戏计算进程包含若干个场景。第二种，像魔兽世界，ryzom，EVE等采用的，就是将一个功能放在一个或者若干个进程（可以通过hash的方式进行负载均衡）上来计算。第一种难度比较低，程序员不需要关注多线程数据竞争的问题，也不需要关注如何合理划分功能，也不需要关注数据同步的问题（一个功能输出的数据可能成为其他功能的输入），但是第二种带来了很多体验的好处，比如延迟低、不需要来回切换场景等等。对我来说，还没能力驾驭第二种，所以关于第二种也就不多说了。
关于第一种，玩家存在切景的情况，所以这个时候最好有个数据缓冲服务。因为有了数据缓冲，你在切景时就不需要一遍遍读取数据库，只需要在缓冲服务进程上取一份到新的游戏服务进程就行了（减少了数据库操作频率）。也可以避免像游戏服务进程宕机了，而造成玩家数据被破坏（因为数据缓冲服务业务模型单一，宕机的可能远远比业务逻辑复杂的游戏服务器小的多）。
关于这个数据缓冲要做的事情不多，使用LRU机制实现数据的缓冲，关键在于如何操作数据库？同步还是异步？我采用同步模型，也就是不区分逻辑跟数据库线程（减少数据交换的延迟，开销就不考虑了，因为同一进程多线程可以使用指针的方式传递数据），另外就是逻辑计算远远小于等待数据库的远程过程调用（因为数据库客户端是同步RPC机制），逻辑计算量可以忽略，而数据缓冲服务变成了一个个同步RPC的处理，而又采用多线程逻辑驱动的模式，所以不会阻塞后续的数据缓冲服务请求。
----------------------------------------------------------------------------
multithread-logic sync-db DBServer
WorkerThread WorkerThread WorkerThread
| | |
| | |
| | |
| handle message |
handle message | |
| acquire db connection |
... | handle message
| prepare mysql bind |
| | acquire db connection
| exec sql |
| | ...
| wait db return |
| | |
| handle data |
| | |
| handle message return |
| | |
----------------------------------------------------------------------------
singlethread-logic async-db DBServer
LogicThread(Producer) DBThread(Consumer) DBThread(Consumer)
| | |
| | |
| | |
request db operation(I) | |
| prepare mysql bind(I) |
request db operation(II) | |
| exec sql(I) |
| | |
| wait db return(I) prepare mysql bind(II)
| | |
... exchange(I) to Logic Thread exec sql(II)
| | |
| | wait db return (II)
on db return(I) | |
| | exchange(II) to Logic Thread
on db return(II) | |
| | |
| | |
阅读(1717) | 评论(0) | 转发(0) |
