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

【新手累计充值】

OS：老板也不多给时间做“系统”管理，催着出初版，反正也能满足需求，分开各做一套独立系统好了，后期有空再改吧！！！(￣▽￣)"

【新手七天任务】

新增【拼图活动】，需要一个控制系统控制开启条件。

可能会引入【控制系统】，新增如下配置来控制活动的开启关闭。

OS：新系统咱们就并入【控制系统】吧，反正都是新做，目前的需求代码量也还好。

不过已有的

【新手累计充值】

【新手七天任务】

再改没排期 / 前人做的改不动，真心改不动！就这几个需求，不影响大局，旧的先不接入【控制系统】了。(●'◡'●)

新增【元旦三天任务】

与【新手七天任务】类似。

但需求上不需【控制系统】控制。

OS：是改造【新手七天任务】使其方便扩展？

还是完全按独立玩法新做一套？

好纠结≧ ﹏ ≦

新增【月初七天任务】

与【新手七天任务】不共存

与【元旦三天任务】共存

OS：同样的代码结构，要是能分开存储不同活动数据改动最小，不想再重新写一套了😭

新增【老兵回归五天任务】

【离线n天】后再上线可进入此活动

OS:改改表加个字段，代码接口再扩充传入个角色id，针对这个字段写个逻辑，反正现有活动都不影响，先不想以后的兼容问题了，就这样干吧（能跑没BUG就行），排期有限

新增【国庆普天同庆】系列活动

包含【国庆大转盘抽奖】【拼图】【每日签到祝福】【国庆累计充值】

新增【中秋普天同庆】系类活动

包含【中秋老虎机抽奖】【“月饼”商店】【中秋累计充值】

OS：两次活动，分别写两套逻辑？看起来重复的挺多，但不同的也挺多，是模块化还是独立区分呢？≧ ﹏ ≦

复刻去年【国庆普天同庆】

但不包含【国庆累计充值】

增加【国庆商店】

OS：copy一份代码改改？很直接，但明年复刻时再copy一份改么？想想就头大つ﹏⊂

按天分组配置任务

可自由定义每个活动的天数和包含任务

1（n）

只配置一组任务

7天任务，由7条此类型活动共同拼接实现

7(1)

两个方案都是在降低业务实现粒度！

考虑实现效果：都可以。

考虑策划人员的表格维护成本：方案B将增加更多关联性配置，不是很友好。

考虑实现中如何表示这是一个活动内的：一般大家会用活动ID来做区分，方案B逻辑成本增加。

不足：方案A因限制了按天配置，有些活动没有天数的需求，也要额外配置个天数1作为默认配置。有冗余，但个人依然推荐。

缺点：

1. 每次刷新频率不可能特别段，业务层一般建议10~60s刷新缓存一次活动状态。更新活动状态多少会有延迟。
2. 分布式多服架构下，即使linux本地时间同步，每个服tick时机大概率不同，互相有偏差。

优点：

1. 可利用tick抛出活动状态变化事件，方便代码书写方式解耦。
2. 大幅度减少计算开销，在线人少时无所谓，在线人多时也不会增加负担。
3. 因有缓存，可直接获取活动状态。

缺点：

1. 每次都所有活动计算，后期运营活动表中成百上千条活动时，压力变大。
2. 活动状态变化（开启或关闭）需要主动访问查询才可知。

优点：

1. 用时计算，准确无误，无需缓存活动状态。
2. 无定时器/线程等额外维护逻辑。

方案B是常见的一种实现方式，保守、安全。

如果对活动状态变化能接受1分钟以内误差的，可以考虑方案A，解耦、集中、效率。

下次这个活动再开

清除旧数据，新一轮数据记入

相同活动类型，根据活动id（类型重复id不同）分别存储

同一个活动id循环开启，用时间再做区分

优点：

1. 无冗余数据

缺点：

1. 同类型活动，不可多开
2. 覆盖前必须处理好上一期所有逻辑（只能通过查BI记录或快照查询往期数据）

优点：

1. 每个活动id对应的活动数据互不影响
2. 近期往期数据可直接获得，灵活结算时间点，方便排查问题
3. 基本可随意多开、重开活动

缺点：

1. 容易有冗余数据，越久冗余越多，需有清理机制
2. 实现逻辑相对覆盖存储复杂

对于只可能重复开的活动可以考虑覆盖存储方式，毕竟实现相对容易。

但如果想方便后续扩展，例如活动是一组任务，不同活动之间任务可能重复，需用区分存储。

对于有同时多开需求的活动，例如活动是一组任务的组合，需用区分存储。

通过玩家主动领取等特别行动点发奖

个人的活动记录中会记录有无领奖的状态

通过再登录、跨天时检查状态，发邮件给予奖励

一般不推荐活动结束时立即处理离线玩家，因为可能数量很多，集中处理可能造成服务器卡顿。

若玩家数量很少，比如只有百十人的榜单活动，可考虑直接统一立即发奖。

一般这三种领奖方式都会同时存在，覆盖玩家的各种在线情况

• A方案保证了实时在线玩家的体验
• B方案满足策划对玩家的体验需求
• C方案采用邮件方式，保证不漏发奖励的同时，通过登录、跨天等方式分散服务器压力

1. 每种活动特殊道具，大概率不一样
2. 活动结束后失效，不删除长期积累占用玩家背包
3. 一般这种特殊道具还伴随商店兑换等数值产出，不可使用玩家有损失

1. 可在活动结束后，与玩家领奖的时机一起处理
2. 道具的处理可转为金币等，通过邮件告知玩家（不要偷偷的只删除）

• 哪些地方需要红点？——页面层级表现

例如：

1. 活动入口按钮
2. 各个活动标签
3. 可领奖按钮
4. 装备可升级
5. 宝石可合成

• 什么时间点更新红点状态？

例如：

1. 登录
2. 打开活动界面
3. 跨天
4. 战斗后回到主界面

• 要做到什么程度？——实现复杂度不同
• 哪些做在服务端，哪些做在前端？——实现方式不同，后台消耗不同

例如：

1. 活动最外层页签推荐服务器提供红点信息：因为此时前端不一定有活动数据
2. 细节红点更推荐前端本地实现：装备可升级，推荐前端实现，因为背包、装备数据登陆后一定推送给前端。如果道具变化频繁，每次获取或道具变更都需计遍历算红点状态，消耗服务器性能不划算。
3. 大页签下包含多个红点，最外层的红点，只需内部一个满足条件立即停止遍历
4. 利用事件机制，监听变化从而刷新红点状态结构更清晰

优点：

统一管理，维护代码结构的统一

缺点：

需要考虑兼容所有的活动

优点：

仅对本活动生效，不干扰其他，不用考虑兼容问题

缺点：
其他活动想用相同控制时，需单独开发，需要的类型多了，开发还好，后续的维护及统一修改很慢发

例如一个刷副本关卡类活动：

条件1：每周一、三、开放（一般这种级别的时间周期会设计再活动表中）

条件2：每天上午8点到17点才可进入关卡战斗

这里的时间周期，放哪里控制更合适呢？

条件1其他活动共用的可能性较大，且时间规律，配置上可用例如“1,3,5”类似这样的配置实现，方便策划填写，推荐方案A

条件2本身单独看是个有规律的固定时间段，同条件1，依然推荐方案A

但我们需要条件1、2同时生效，设计表格时，可做一些冗余配置设计，方便策划配置多个条件。例如下图

例如查看好友信息，通过非法手段向服务器发送不存在的id

会导致：

1. 频繁访问数据
2. 导致数据库假死
3. 阻塞新玩家登录

1. 限制访问频率
2. 缓存访问结果
3. 增加id规则过滤
4. 对非法访问数值监控，熔断访问响应
5. 数据库读写分离

缓存访问一般流程

• 多线程阻塞，其他业务执行也被卡住
• 界面等待严重超时

• 每个红包一个队列，异步投送请求，不阻塞线程，队列处理保证数据正确，且可直接拒绝超出数量上限的访问
• 提前划分好红包分布，不每次都随机，只随机编号，分散压力

• 单价较高时，总价出现负值
• 玩家刷道具
• 玩家刷金币、钻石等

• 不可仅仅校验参数正负
• 限制单次购买数量
• 使用大数方法编程
• 校验计算结果

• 内网流量瞬时极高
• Redis响应超时，同步失败
• 阻塞其他Redis访问
• 初始化失败导致起服失败

• 削峰处理，分散拉取数据时间点
• Redis设立多个只读从库
• 避免玩家业务层直接从DB拉取大量数据