拼多多|电商营销体系建设的运营、产品和技术挑战( 四 ) 数据结构

有经验的工程师都知道，工程开发里底层模型的稳定性非常重要，良好的底层数据结构，可以预留扩展空间，好像杠杆一样，支持更多的业务发展。

文章插图
如果不能用一个相对稳定可扩展的模型去承接上层业务，开发很容易就陷入到无尽的需求调整中去。
那么在底层模型上，就需要进行一定的抽象，对于优惠券、活动等的数据模型设计，可以从以下方面展开：
各类营销工具的实体，是否需要落地数据模型？
各类促销规则，是否可以全部枚举出来？
不同的促销规则，规则之间的关系如何处理？
这里要避免一个误区，就是过度抽象和设计。
电商领域设计里，有一个抽象程度特别高的模块，就是风控。
在进行风控系统设计时，要考虑各类交易属性，对应触发的阈值，以及风控动作。但是营销和风控有一个很大的区别：
风控策略是由平台管理，而营销工具的使用者是商家。
也就是说，营销工具，不可能做成像风控一样，是字段和规则的自由组合。B 端产品的功能设计，就是营销模型抽象的一个边界，在设计数据结构时，要考虑到营销工具给商家操作时的易用性。
2. 性能营销系统的另外一个技术挑战是性能，例如各类促销活动的实时结算，秒杀系统的性能优化。
目前一类电商的营销玩法越来越复杂，特别是大促活动期间同一个商品可能叠加了七八个不同的营销。这些都需要在购物车里进行实时的计算，对整体的性能、并发量都有非常高的要求。
电商营销中秒杀系统的设计，是一个经典的高并发工程设计范例，各种极致优化手段基本上都应用上了。

文章插图
3. 选型最后盘一下，营销侧开发需要哪些技术组件？
完成了模型的拆解，以及对性能指标的要求，就可以进行具体的技术选型。
Web 框架，RPC 中间件，以及关系型数据库等组价，普适性比较高，这里就不展开了，说一些比较特殊的。

文章插图

优惠券都会有一个可用时间，超出之后，会被置为已超期，根据时间变化来调整状态，可以通过延迟队列来实现，Redis，MQ 都可以实现
对于不同的营销活动，可以在前端引入一个状态，比如优惠券超期失效，逆向生效，状态的流转，可以通过状态机去管理
不同的规则之间是兼容还是互斥，需要一个规则引擎的支持，根据业务规模，可以选择使用 Drools 或者 EasyRule，也可以自己开发
对于促销规则的表示，为了更灵活的进行抽象，可以使用脚本语言进行封装，比如阿里的 QLExpress，mvel 语言
在逆向流程里，会有比较多的异步任务，比如发生交易退款以后，退回优惠券，可以考虑使用消息队列等
促销的展示和促销价格的计算，对性能要求很高，需要各级缓存的支持，考虑 Guava 和 Redis
C 端接口需要考虑防刷，可以考虑添加限流降级功能实现稳定性，使用 Guava-RateLimiter 或者 Alibaba Sentinel 等
在优惠券领取时，需要避免超发，如果并发比较大，可以添加分布式锁实现

五、总结这篇文章对电商营销这件事情，做了一个自顶向下的思考，偏向 High-level。欢迎留言分享你的观点。
本文由 @邴越原创发布于人人都是产品经理。未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议