活动系统通常结合充值构建项目的商业化节奏,系统的设计方案:
定义不同类型用于区分活动,定义不同ID用于唯一标识一期特定类型的活动;
每个玩家节点开启单例的活动排期管理服务(activity_manager),负责管理活动排期相关的数据;
活动排期源数据通过配置和中央数据后台获取,由服务负责维护更新,对玩家提供查询获取接口;- schedule_cache = {
- activity_type = {
- activity_id = {
- bt,
- et,
- version,
- },
- ...
- },
- ...
- }
- ---@description 重新构建排期缓存。缓存服务启动时构建,当配置更新时通知重新构建
- local function onload(raw_schedule) end
- ---@description 获取当前进行中的活动排期信息
- function getActInfo() end
复制代码 玩家登录和跨天会请求服务获取最新的排期信息,与本地活动数据做校验,对应增删改活动;
btw,活动管理服务不单独进程的原因:
1)避免跨进程调用;玩家的代理服务跟活动管理应该是同生共死的,避免处理不可靠通信的复杂问题;
2)优化并发问题;单点服务总是需要考虑服务过载的问题;(量级:在线玩家数量(不可控) ==> 单台user承载的agent数量(可控))
优化设计:
排期热更问题:排期配置热更新完成需要触发服务内的缓存重新构建(可能有各种反查表),构建缓存可能有时序要求,时序问题可能造成缓存数据失效;
优化方案:sharetable支持预定义反查表;
玩家代理服务中:
设计玩家活动管理模块:- local activity_mgr = {}
- -- 获取排期配置对本地活动做更新
- function activity_mgr.check_update() end
- -- 删除活动
- function activity_mgr.delete_activity(type) end
- -- 新增活动
- function activity_mgr.accept_activity(type) end
- -- 创建活动类型对象
- function activity_mgr.new_activity_object(type) end
- -- 充值接入
- function activity_mgr.oncharge_finish(type) end
复制代码 抽象活动基类,基于活动类型设计活动模版;- -- 一个通用的活动模块包括:管理接口、数据管理接口、充值接入
- local activity_base = { type }
- -- 增
- function activity_base:can_accept() end
- function activity_base:pre_accept() end
- function activity_base:accept() end
- -- 删
- function activity_base:can_delete() end
- function activity_base:pre_delete() end
- function activity_base:delete() end
- -- 改
- function activity_base:onupdate() end -- virtual func
- function activity_base:update() end
- -- 数据管理
- function activity_base:new_activity_data(schedule) end
- function activity_base:del_activity_data() end
- function activity_base:get_extra_data() end -- custom data
- function activity_base:sync_activity_data()
-
- -- 充值接入
- function activity_base:create_charge_order(productId) end
- function activity_base:oncharge_finish() end
复制代码 来源:程序园用户自行投稿发布,如果侵权,请联系站长删除
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作! |