做到可控

1. 需要显示总数的活动，要注意总数显示多少，以一个什么样程度增长是符合预期的。
2. 要有一个固定的曝光位置，这个是最基本的。
3. 运营活动目标UV，目标获奖人数。可能多，也可能少。要防止完成用户过多，不可控，通过一些关键资源来控制，比如集卡活动中的稀有卡个数。用户过少，达不到预期。分为两部分：1. 没达到增长指标 2. 没达到奖励用户数预期 没达到增长指标，可能是活动入口曝光不够，也可能是活动不够有吸引力/可玩性。 没达到奖励用户预期数，可能是因为对用户数预期过高，或者是获取奖励的任务设置太难。
4. 稀有卡控制和实际总数之间会有出入，不能预设所有用户都是参与度非常高的用户，可能有些用户获取到稀有卡，就不继续参与活动了，也有可能。
5. 一般来说，即使达不到运营预算人数，也不会给每个用户更多的钱。因为ARPU不能过高，要算账的。所以，其实除了极少数活动，大多数活动，平均到每个人都上也就几块钱，要不然，获客成本过高了。
6. 运营经费是固定的。一定要严格控制运营经费不能超，否则，没办法向老板交代的。
7. 一般一个活动开始之后，只能通过调节曝光资源或者发push之类的来提升用户使用，需要改配置的地方，主要就是控制预算。

数据存在哪里

活动按照时间分，可以分为两种：短期活动和长期活动。

• 短期活动：项目型活动。一般一周左右，最长不会超过两周。对于这种活动，数据一般使用redis之类的内存存储就好（当然也要注意数据持久化），速度快。
• 长期活动：运营型活动。一般为几个月以上，甚至一年两年。需要用户长期参与的活动，需要将数据存档到mysql之类的数据库中。在过程中可能会有一些新增的历史数据分析需求，最重要的用户参与数据最好能够持久化存储。当然，一些短时间有效的数据，存放缓存即可。

重要参数配置化

活动过程中，一些关键参数很有可能会发生变化。
比如抽奖活动的抽奖概率，会根据活动数据进行变化，因此，最好做成可配置的。

流量预期

要根据运营或者产品提供的目标数据，结合自己的经验，预估QPS及对存储和第三方服务的要求。活动的流量具有波动大，峰值高的特点。尤其是一些关键时间点，要注意，必要情况下使用MQ进行削峰，或者使用熔断器拒绝部分请求。当然这些值，一般来说都是吃一堑长一智的，具体多少值会出问题，只有出了问题才能知道。所以，最好是有全链路压测。但是全链路压测，
对很多公司和团队来说，门槛太高，而且投入产比低。因此，可快速扩容缩容就显得尤为重要。

任何人想要转载我的文章，无需和我联系，请转载后把链接私信贴给我，谢谢！