网游中如何管理运营活动？（服务器业务框架设计）

活动设计千变万化，好的设计事半功倍！

上图这些问题都怎么来的？

常见开发流程：时间资源有限，市场不停变化、需求不断更新、叠加（敏捷开发），代码经常更改、扩展。

如果初期没有计划，到后面需求越来越多，可能会有冲突、也可能会有交织，后期维护越来越难。

模拟复现下需求变化

初版需求——几个独立活动，新号都有
【新手累计充值】 OS：老板也不多给时间做“系统”管理，催着出初版，反正也能满足需求，分开各做一套独立系统好了，后期有空再改吧！！！(￣▽￣)"	【新手七天任务】

新增需求1——引入【控制系统】
新增【拼图活动】，需要一个控制系统控制开启条件。 可能会引入【控制系统】，新增如下配置来控制活动的开启关闭。	OS：新系统咱们就并入【控制系统】吧，反正都是新做，目前的需求代码量也还好。 不过已有的 【新手累计充值】 【新手七天任务】 再改没排期 / 前人做的改不动，真心改不动！就这几个需求，不影响大局，旧的先不接入【控制系统】了。(●'◡'●)

新增需求2——要不要复用？
新增【元旦三天任务】 与【新手七天任务】类似。 但需求上不需【控制系统】控制。 OS：是改造【新手七天任务】使其方便扩展？ 还是完全按独立玩法新做一套？ 好纠结≧ ﹏ ≦

新增需求3——“相同”活动共存
新增【月初七天任务】 与【新手七天任务】不共存 与【元旦三天任务】共存 OS：同样的代码结构，要是能分开存储不同活动数据改动最小，不想再重新写一套了😭

新增需求4——新增个人开启活动条件
新增【老兵回归五天任务】 【离线n天】后再上线可进入此活动 OS:改改表加个字段，代码接口再扩充传入个角色id，针对这个字段写个逻辑，反正现有活动都不影响，先不想以后的兼容问题了，就这样干吧（能跑没BUG就行），排期有限

新增需求5——活动要成组出现
新增【国庆普天同庆】系列活动 包含【国庆大转盘抽奖】【拼图】【每日签到祝福】【国庆累计充值】 新增【中秋普天同庆】系类活动 包含【中秋老虎机抽奖】【“月饼”商店】【中秋累计充值】 OS：两次活动，分别写两套逻辑？看起来重复的挺多，但不同的也挺多，是模块化还是独立区分呢？≧ ﹏ ≦

新增需求6——活动复刻
复刻去年【国庆普天同庆】 但不包含【国庆累计充值】 增加【国庆商店】 OS：copy一份代码改改？很直接，但明年复刻时再copy一份改么？想想就头大つ﹏⊂

界面需求——前端展示
每个活动页面内包含多个玩法、功能
左侧列表切换不同活动
主界面有特殊活动的额外入口
OS：前端小伙伴更苦，每套活动都不一样，资源基本不能复用~ 如何给前端区分这些活动呢，配置？消息？

排期不够，计划来凑

刚才模拟需求变化暴露出的问题，其中提到最多的是“排期不够”。

不可否认，极致的压缩开发时间和人力成本，还想保证质量不太可能。

但咱还得积极向上讲道理，通过科学的规划设计手段，能尽可能让我们的产品更健壮，维护成本更低。

推荐《Thinking in UML》(第二版) 谭云杰 / 著，不必过多关注UML的具体格式，多注意方式方法。

个人写这篇文章的时候，受这本书很大的影响，虽然书中的示例与我不是同一行业，但其思想是教大家如何科学的分析需求，从而确定合理明确的业务代码框架。

明确目标

基本原则：

1. 策划没提的业务需求不要自作主张去做，后期可能不需要或需求不符还得重做！！！
2. 不要追求一口气实现一个完善的系统框架，预留扩展空间即可！！！

常见具体需求实现方案

经过一顿需求分析、用例提取、业务边界划分、系统分析、系统设计......整理出了一些常见需求实现

初期活动表设计（参考示例）

随需求增加而完善的活动表（参考示例）

• 界定合适的最小活动单元

方案A	每过一天解锁一天的任务	方案B
按天分组配置任务 可自由定义每个活动的天数和包含任务 1（n）		只配置一组任务 7天任务，由7条此类型活动共同拼接实现 7(1)
两个方案都是在降低业务实现粒度！ 考虑实现效果：都可以。 考虑策划人员的表格维护成本：方案B将增加更多关联性配置，不是很友好。 考虑实现中如何表示这是一个活动内的：一般大家会用活动ID来做区分，方案B逻辑成本增加。 不足：方案A因限制了按天配置，有些活动没有天数的需求，也要额外配置个天数1作为默认配置。有冗余，但个人依然推荐。

• 活动状态更新

方案A	方案B
一个定时器/线程集中刷新所有活动的系统开启状态	提供一个接口，玩家每次拉去活动列表都计算一遍所有活动的时间范围，是否处于开启或已经结束
缺点： 每次刷新频率不可能特别段，业务层一般建议10~60s刷新缓存一次活动状态。更新活动状态多少会有延迟。 分布式多服架构下，即使linux本地时间同步，每个服tick时机大概率不同，互相有偏差。 优点： 可利用tick抛出活动状态变化事件，方便代码书写方式解耦。 大幅度减少计算开销，在线人少时无所谓，在线人多时也不会增加负担。 因有缓存，可直接获取活动状态。	缺点： 每次都所有活动计算，后期运营活动表中成百上千条活动时，压力变大。 活动状态变化（开启或关闭）需要主动访问查询才可知。 优点： 用时计算，准确无误，无需缓存活动状态。 无定时器/线程等额外维护逻辑。
方案B是常见的一种实现方式，保守、安全。 如果对活动状态变化能接受1分钟以内误差的，可以考虑方案A，解耦、集中、效率。

• 类型相同活动重开、同时多开，数据管理

覆盖存储	区分存储
下次这个活动再开 清除旧数据，新一轮数据记入	相同活动类型，根据活动id（类型重复id不同）分别存储 同一个活动id循环开启，用时间再做区分
优点： 无冗余数据 缺点： 同类型活动，不可多开 覆盖前必须处理好上一期所有逻辑（只能通过查BI记录或快照查询往期数据）	优点： 每个活动id对应的活动数据互不影响 近期往期数据可直接获得，灵活结算时间点，方便排查问题 基本可随意多开、重开活动 缺点： 容易有冗余数据，越久冗余越多，需有清理机制 实现逻辑相对覆盖存储复杂
对于只可能重复开的活动可以考虑覆盖存储方式，毕竟实现相对容易。 但如果想方便后续扩展，例如活动是一组任务，不同活动之间任务可能重复，需用区分存储。 对于有同时多开需求的活动，例如活动是一组任务的组合，需用区分存储。

• 活动结束后奖励如何领取

理论上，需要玩家明确感知到结果，一般不会后台“偷偷”发奖，偷偷的结果就是客服核对道具获得查询率升高（客服小姐姐会在心里diss你们的(╯▔皿▔)╯）

A玩家在线时主动推送	B玩家行为被动触发	C玩家离线时等线被动获取
遍历在线玩家，直接发奖	通过玩家主动领取等特别行动点发奖	个人的活动记录中会记录有无领奖的状态 通过再登录、跨天时检查状态，发邮件给予奖励 一般不推荐活动结束时立即处理离线玩家，因为可能数量很多，集中处理可能造成服务器卡顿。 若玩家数量很少，比如只有百十人的榜单活动，可考虑直接统一立即发奖。
一般这三种领奖方式都会同时存在，覆盖玩家的各种在线情况 A方案保证了实时在线玩家的体验 B方案满足策划对玩家的体验需求 C方案采用邮件方式，保证不漏发奖励的同时，通过登录、跨天等方式分散服务器压力

• 活动结束后特殊道具自动回收

活动道具一般仅用一期	回收处理
每种活动特殊道具，大概率不一样 活动结束后失效，不删除长期积累占用玩家背包 一般这种特殊道具还伴随商店兑换等数值产出，不可使用玩家有损失	可在活动结束后，与玩家领奖的时机一起处理 道具的处理可转为金币等，通过邮件告知玩家（不要偷偷的只删除）

• 活动红点提示同步

执行内容	执行时间	优化实现
哪些地方需要红点？——页面层级表现 例如： 活动入口按钮 各个活动标签 可领奖按钮 装备可升级 宝石可合成	什么时间点更新红点状态？ 例如： 登录 打开活动界面 跨天 战斗后回到主界面	要做到什么程度？——实现复杂度不同 哪些做在服务端，哪些做在前端？——实现方式不同，后台消耗不同 例如： 活动最外层页签推荐服务器提供红点信息：因为此时前端不一定有活动数据 细节红点更推荐前端本地实现：装备可升级，推荐前端实现，因为背包、装备数据登陆后一定推送给前端。如果道具变化频繁，每次获取或道具变更都需计遍历算红点状态，消耗服务器性能不划算。 大页签下包含多个红点，最外层的红点，只需内部一个满足条件立即停止遍历 利用事件机制，监听变化从而刷新红点状态结构更清晰

• 活动特殊时间周期处理

方案A	方案B
活动表统一控制	该活动内部自己控制
优点： 统一管理，维护代码结构的统一 缺点： 需要考虑兼容所有的活动	优点： 仅对本活动生效，不干扰其他，不用考虑兼容问题 缺点： 其他活动想用相同控制时，需单独开发，需要的类型多了，开发还好，后续的维护及统一修改很慢发
例如一个刷副本关卡类活动： 条件1：每周一、三、开放（一般这种级别的时间周期会设计再活动表中） 条件2：每天上午8点到17点才可进入关卡战斗 这里的时间周期，放哪里控制更合适呢？ 条件1其他活动共用的可能性较大，且时间规律，配置上可用例如“1,3,5”类似这样的配置实现，方便策划填写，推荐方案A 条件2本身单独看是个有规律的固定时间段，同条件1，依然推荐方案A 但我们需要条件1、2同时生效，设计表格时，可做一些冗余配置设计，方便策划配置多个条件。例如下图

设计方案时要考虑安全+性能

有了具体业务的实现需求，接下来要考虑安全与性能问题。忽略的方面最终都会表现为BUG体现出来！

• 缓存访问（性能）

高频访问不存在的玩家数据	预防方法
例如查看好友信息，通过非法手段向服务器发送不存在的id 会导致： 频繁访问数据 导致数据库假死 阻塞新玩家登录	限制访问频率 缓存访问结果 增加id规则过滤 对非法访问数值监控，熔断访问响应 数据库读写分离
缓存访问一般流程

• 线程阻塞（性能）

例如全服抢红包活动

要保证线程安全，数值正确 如果只用一个自旋锁、互斥锁	预防方法
多线程阻塞，其他业务执行也被卡住 界面等待严重超时	每个红包一个队列，异步投送请求，不阻塞线程，队列处理保证数据正确，且可直接拒绝超出数量上限的访问 提前划分好红包分布，不每次都随机，只随机编号，分散压力

• 数值边界（安全）

单次购买道具数量未作限制	预防方法
单价较高时，总价出现负值 玩家刷道具 玩家刷金币、钻石等	不可仅仅校验参数正负 限制单次购买数量 使用大数方法编程 校验计算结果

• 压力集中（安全+性能）

滚服架构 几十上百个服定时从同一个redis同步大量榜单数据	预防方法
内网流量瞬时极高 Redis响应超时，同步失败 阻塞其他Redis访问 初始化失败导致起服失败	削峰处理，分散拉取数据时间点 Redis设立多个只读从库 避免玩家业务层直接从DB拉取大量数据

总结

---

欢迎大家留言讨论！