游戏服务器开发如何组织业务逻辑的处理结构?

服务器
每个用户的每个模块的Manager实例存储在当前用户业务逻辑处理的线程的LocalThread中的HashMap中,这样方便管理又避免使用锁了。使用一个ManagerFactory对象统一管理Manager对象的创建和获取。

 游戏服务器就是对游戏数据的处理及逻辑验证,一般的步骤就是:

1,接收客户端请求的数据

2,根据请求的数据找出是哪个业务的请求

3,处理业务的请求

4,更新被修改的数据。

5,返回数据给客户端。

所以按照以上的步骤,我们现在只关心业务逻辑的处理流程,这里设置一个前题,就是服务器的数据都是在内存中的。内存中的数据与数据库的同步由底层的其它系统处理。在内存中,我们创建并缓存一个对象Player,它包括所有模块的数据,比如背包,个人商店(Shop),技能(Skill),武将,副本 等等,Player只是数据类,里面不应该包括任何逻辑方法,所有的逻辑方法操作应该在Manager中处理。比如ShopManager。

[[252648]]

 

业务处理流程

比如我们使用netty做为网络层的通信框架,在Channel的Handler中收到客户端请求的数据,根据请求的消息号,调用处理业务的Handler。在业务的Handler中验证参数的合法性,然后再调用业务逻辑的Service层,Service层负责的业务流程的处理,比如购买商品,***步判断商品是否已卖完,第二步判断剩余数量是否足够,第三步判断是否已购买过,第四步判断钱是否足够,第五步是付钱,第六步是发送购买获得的道具。这里面应该都是方法的调用,而没有任何数据的处理,数据的处理由第三层的Manager管理。Manager对应中声明一个参数Player,在创建Manager对象时传入,不同的模块数据之间交互都由Manager处理,Manager中的方法职责单一,只负责处理一件事情。每个用户的每个模块Manager对象各一个。用户之间不共享,这样可以减少参数的传入。这样更加方便面向对象的设计。方便对业务逻辑进行单元测试。

 

Service层

每个用户的每个模块的Manager实例存储在当前用户业务逻辑处理的线程的LocalThread中的HashMap中,这样方便管理又避免使用锁了。使用一个ManagerFactory对象统一管理Manager对象的创建和获取。

责任编辑:武晓燕 来源: 游戏技术网
相关推荐

2020-03-02 17:49:40

大型游戏服务器

2019-09-16 15:30:51

2018-09-19 09:17:13

2018-05-18 10:22:39

冲突游戏服务器

2017-07-19 08:30:31

2016-08-09 19:36:48

2018-06-04 10:30:47

游戏服务器框架

2016-01-08 10:24:32

Docker容器容器技术

2019-02-20 13:57:48

游戏服务器框架

2019-09-10 09:40:11

游戏服务器框架

2018-11-28 09:53:50

游戏服务器线程

2018-06-28 09:38:16

2014-04-10 09:51:36

2017-07-19 16:17:53

2017-07-20 10:35:51

2017-11-30 12:39:06

2019-12-27 11:13:24

高并发服务器逻辑

2013-03-07 10:08:04

模拟城市游戏服务器服务器忙

2009-02-10 15:35:00

网络游戏服务器网络游戏

2022-12-19 15:04:21

点赞
收藏

51CTO技术栈公众号