打造大促运营活动的全过程：四步走之研发与设计环节

需求的复杂度决定了研发设计的复杂度，满足业务场景的适度设计，在可预见需求变更的范围内支持可扩展和迭代即可。谁也无法做到一眼万年，不可能一下就设计和开发出绝对健壮、绝对扩展的程序。软件产品的生命周期非常短暂，在互联网产品中更甚，特别是这种运营活动类产品大多数是瞬间的烟火。相比来说，运营活动页面UI的变更频繁，服务端的核心功能较稳定，外部对接的业务需求变更较频繁。
分别从库表设计、系统架构、技术架构、核心流程几方面进行说明。

4.1 库表设计

库表规划

简单列举下表划分，不输出详细的字段定义了，可根据业务场景定制。

表名	功能概述	拆分方案	数据量分析
任务活动配置表	日&总库存，日&总参与次数，奖励资产	单库单表	小，依赖运营
任务奖励配置表	奖励资产额度，邀请&被邀请关系差异化奖励	单库单表	小，依赖运营
兑换奖品配置表	奖励类型、消耗额度、规则限制	单库单表	小，依赖运营
用户账户记录表	用户虚拟资产信息，账户额度	分库分表	中，依赖用户体量
任务活动领取表	用户任务领取关系记录	分库分表	中，依赖运营活动变更
任务活动参与表	用户任务完成日&总维度记录	分库分表	中，依赖运营活动变更
任务奖励流水表	用户参与任务活动记录明细，奖励状态，奖励额度等	分库分表	大，依赖用户参与度
奖励兑换流水表	用户兑换结果，外部交互存根，兑换状态，资产消耗等	分库分表	大，依赖用户参与度
账户明细流水表	虚拟资产动账记录，资金来源去向明细	分库分表	大，依赖入账、消耗

数据量评估

存放全局通用配置信息的表，数据量小，通用查询量是最大的，需要加入缓存抗量；存放用户个人业务信息的表，数据量增幅大，实时性要求高，一般不引入缓存，要做好数据库索引配置，关注数据库连接数、峰值qps数据。
互联网用户体量大，存储数据必然要对数据库进行分库分表。关于分库分表具体要分多少库多少表需要按照实际用户体量进行，比如评估当前业务场景下最多数据量的表应该就是任务奖励流水表，每个用户每完成一次任务则计入一条流水，若现存日活用户100W，运营每天配置10个任务，假设日活用户均完成10个任务，每天的数据量就是1000W，如果持续1年（365天）数据量就是36.5亿。如果项目的生命周期是5年，数据量将是182.5亿，然后我们根据历史经验尽量让数据库单表最大数据量保持在1000W水平，就是182.5亿除以1000W得到需要的分表数1825张，如果按照分库10个，每个单库200张就可以满足使用。以上只是一个举例和大概的推算方式，具体的数据存储和还要根据场景进行调整，况且日活百万的业务算是比较大的体量了，各方面挑战性、复杂性会指数级增长，要具体问题具体分析。

4.2 系统架构

基于微服务环境，通过RPC进行服务间通信。从调用链路由上到下依次是，前端、展示层、业务层、服务层、数据层，应用结构采用的是传统的贫血模型。

• 前端
  大多数为H5、客户端发起，通过API网关进行HTTP协议交互，通常普遍采用JSON格式进行报文传递。API网关的主要职责是将HTTP请求转换为RPC请求、过滤权限、处理用户登录态、限流控制等。
• 展示层
  展示层应用命名为FRONT，它是网关请求的第一道门闸，也是数据输出的最后一道程序，主要负责参数校验，统一的交互数据组装等。
• 业务层
  业务层应用有BIZ、PROC、WORKER。BIZ负责处理业务请求的核心、复杂、多样化逻辑，是所有业务请求的核心应用，负责服务数据的调度、编排。PROC负责处理异步消息，是内部、外部异步通信的应用。WORKER负责完成定时任务调度的应用。
• 服务层
  在微服务环境中，应用皆是服务载体，除了自身应用提供的数据存储、异步消息处理、定时任务调度等内联服务体系，还有外部应用输出的RPC服务，通过BIZ进行服务的发布和输出，业务与业务之间通过BIZ应用进行RPC通信。
• 数据层
  数据层分为持久化存储、缓存、大数据存储。持久化存储是业务主力军，通过关系型数据库承载，是业务查询的主要请求对象。缓存用来进行提高请求速度，通过KV存储，用以热点数据的抗量。大数据存储目前在业务线中只应用到分库分表的数据聚合，通过ElasticSearch索引进行大数据检索。

4.3 技术架构

4.4 核心流程

4.4.1 奖励入账

入账方式

入账提供两种方式，API可以提供内部任务奖励调用，也可以提供给外部进行任务奖励触发时调用，外部任务奖励触发也可以通过监听MQ进行异步入账。

方式	场景	示例
API	内部、外部	浏览XX页面、分享XX活动
MQ	外部	在XX消费一单、完成XX注册

奖励入账流程

奖励入账整体分为三个步骤，奖励记录落库、奖励结算、账户入账。

• 奖励记录落库确保奖励记录数据持久化，不丢失
• 奖励结算采用MQ异步驱动，WORKER补偿处理中间态数据最终一致
• 账户入账依赖奖励结算结果采用MQ异步触发，支持业务幂等

流程图如下：

4.4.2 抽奖兑换

奖励配置

根据奖品的价值划分了不同等级、不同消耗分值的兑换奖励配置。奖品价值越高的配置需要消耗的分值也越多，中奖的概率也越低，这是一种典型的赌徒博弈的玩法。保守的用户会倾向于消耗小分值开价值较低、中奖率较高的奖品，而*用户更倾向于积攒分值去放手一搏兑换价值高、中奖率低的奖品。不同的奖励配置利益点是吸引用户参与活动的根本，奖品的配置也要迎合平台业务人群，中奖概率在考虑成本的基础上合理配置，也要考虑用户的参与度和获得感，有效的正向反馈才可以保证活动的可持续性，正向反馈可通过用户自身参与中奖、实时滚动排行榜、奖励配置池的强文案（概率加倍、奖品上新、必得XXX）诱惑用户持续参与，持续活跃。
除此之外，还要关注用户账户的虚拟资产问题，获取的途径和方式一定要有意义，要达到运营目的才进行发放，消耗的方式就是通过兑换、抽奖等途径进行账户虚拟资产去存量。一定不要出现用户账户资产过多导致兑换率较高带来的成本负债，也不要因此调低中奖率令用户反感，导致后续用户参与意愿下降的问题。相反，也不要获取难度过大、兑换难度高、中奖率极低直接导致用户流失的问题。这是个运营策略问题，运营也不是神，需要可靠的数据支持，研发能做的就是各种维度的提供数据埋点支持，兑换率、中奖率、兑换奖励比率、兑换点击率、全盘账户资产入账与消耗明细，等等。

价值	中奖概率	奖池配置	利益点效果
高	低	高端数码，小轻奢，如MacBook、iPad	噱头、高频曝光点
中	中	大多为平价爆款，实用性较高，如日用品、手办、入门数码	留存硬通货，去存主力军
低	高	附加值较低，如低额优惠券、满减券、免息券	零&低成本活跃

抽奖兑换流程

抽奖兑换要考虑用户体验，实时性较高，但是处理逻辑的复杂性不可避免，一般可以前端加动画效果降低用户的等待体验。主要流程大致分为四个步骤，兑换校验、账户动账&入账记录写入、创建兑换流水、抽奖。

流程图如下：