转转商品到手价

1 布景介绍

1.1 问题

• 查找成果落地页，依照价格筛选及排序，成果不太精确；

• 用户依照价格筛选后的产品与实际存在的产品不符，可能会缺失部分产品，影响到用户购物体会。

1.2 到手价模块在促销架构中所处的位置

在整体架构中，产品的到手价触及红包，活动等模块的协同工作。经过将产品售价、红包、活动等要素纳入综合考虑，核算出最终的到手价，为顾客供给良好的购物体会。

2 规划目标

• 体会：用户及时看到产品的最新到手价，提高用户购物体会；
• 实时性：由本来的半小时看到产品的最新到手价，提高到３分钟内。

3 技术计划中心点

3.1 影响要素

影响产品到手价的主要要素:

1. 产品，发布或改价；

2. 红包，新增/删去或过期；

3. 活动/会馆，参加或踢出。

3.2 核算公式

如图所示，产品详情页到手价的优惠项明细可用公式总结如下：

产品的到手价 = 产品原价 - 活动促销金额 - 红包最大优惠金额

4 落地进程及作用

跟着事务需求的改变，体系也需求不断地添加新功用或许对现有功用进行改进，经过版本演进，能够逐渐引进新的功用模块或优化现有模块，以满足事务的需求。

产品的到手价规划也是遵从这样规矩，从开端的v1.0快速开发上线，响应事务； 到v2.0，v3.0进行功能优化，晋级改造，运用户体会更佳，更及时。

4.1 v1.0流程

v1.0流程一共分为两步：

1. 定时使命拉取拉取特定事务线的全量产品，将这批产品全量推送给各个接入方；

2. 促销体系供给回查接口，依据产品id等参数，查询产品的到手价；

4.2 v1.0使命及接口

1. v1.0使命履行时间长，偶尔还会出现履行失利的状况；而在正常状况下用户大约需求半小时左右才能感知到最新的产品到手价；

2. 需求供给额定的单产品及批量产品接口查询到手价，无疑会对体系发生额定的查询压力，跟着接入方的添加，接口qps会成份额添加；

4.3 v2.0规划

针对v1.0版本长达半个小时更新一次到手价问题，v2.0解决计划如下：

• 实时处理部分

产品上架/产品改价；

产品参加/踢出活动；

产品参加/踢出会馆；

这部分数据的特点是，上述这些操作是能实时拿到产品的infoId，基于这些产品的infoId，能够当即核算这些产品的到手价并更新出去。

产品发布/改价，参加活动/会馆，踢出活动/会馆；接纳这些状况下触发的mq音讯，带着产品infoId，直接核算到手价。

• 3min使命，核算特定事务线的全量产品到手价

红包: 新增/更新/删去/过期；

这部分数据的特点是，一是不能很容易能圈出受到影响的这批产品infoIds，二是有些红包的领取和运用规模可能会触及绝大部分的产品，乃至有些时候大型促销会配置一些全渠道红包，影响规模便是全量产品。

综上，结合这两种状况，以及现有的接口及才能完结v2.0；

推送产品的到手价，音讯体格式如下，包括产品id，渠道类型，到手价：

[
{"infoId":"16606xxxxxxx174465"，
"ptType":"10"，"
realPrice":"638000"}
]

首先在Redis保护全量产品，依据产品上架/下架音讯，新增或删去行列中的产品；其次将全量产品保存在10000行列中，每个行列只存一部分产品：

queue1=[infoId...]
queue2=[infoId...]
...
queue9999=[infoId...]

右图显示的是每个行列存储的产品数，行列产品数使其能坚持在同一个量级。

多线程并发核算，每个线程只核算自己行列的产品到手价即可；同时添加监控及告警，查看每个线程的核算耗时，右图能够看到大约在120s内各线程核算完结。

注意事项:

1. 避免无意义的核算: 将每次改变的红包保护在一个行列中，使命履行时判别是否有红包更新；

2. 并发问题: 当使命正在履行中时，此时恰巧产品有改变(改价，参加活动等)，将此次产品放入补偿行列中，推迟履行；

综上，结合这两种场景能够做到:

1. 某些场景影响产品的到手价(如改价等)，带着了产品infoId，能做到实时核算并当即推送最新的到手价；

2. 拆分多个产品行列，并发核算； 各司其职，每个线程只核算自己行列产品的到手价；

3. 下降促销体系压力，接入方只需求监听到手价音讯即可。

4.4 v3.0规划

能够看到跟着产品数的添加，核算耗时也成份额添加。

解决办法:

1. 运用分片，v2.0是将一个大使命，由jvm多线程并发履行各自行列的产品； v3.0则是将这个大使命，由多个分片去履行各自行列中的产品，使其分布式履行来提高使命的履行功率和可靠性；

2. 扩展性及稳定性强，跟着产品的增多，能够适当添加分片数，下降核算耗时。

5 总结

• 体系扩展性 数据量日渐增大，体系要能做晋级扩展；

• 体系稳定性 事务迭代，架构晋级，坚持体系稳定；

• 完备的监控告警 及时的监控告警，快速发现问题，解决问题；

• 演进准则 前期不过度规划，不同时期采用不同架构，持续迭代。

---

关于作者

熊先泽，转转买卖营销技术部研发工程师。代码创造未来，勇于应战，不断学习，不断生长。

转转研发中心及业界小伙伴们的技术学习沟通渠道，定期共享一线的实战经验及业界前沿的技术话题。 关注公众号「转转技术」（综合性）、「大转转FE」（专注于FE）、「转转QA」（专注于QA），更多干货实践，欢迎沟通共享~