关于后端:ToC业务用户弹窗的技术方案

当初很多 ToC 客户端，比方：滴滴、美团、携程等等，都有很多的弹窗，那后端怎么设计更正当、更不便、老本更低呢？

我这里说的弹窗是说一级页面的弹窗，比方客户端的首页、集体核心页面、订单页面等。这种一级页面个别都有专门的部门负责，其余业务方须要接入弹窗，须要通过这个部门来接入。这里定义两种角色：

• 接入方，是须要在首页等页面投放弹窗的业务部门。
• 公共，负责首页等公共页面的部门。

这里是咱们的设计方案：

1 弹窗后端接口设计

1.1 弹窗类型很重要

首先要束缚弹窗类型，

| 序号 | 弹窗类型 | 类型阐明 |
| :- | :- | :- |
| 1 | 单图片 | 弹出一张图片，点击图片跳转 |
| 2 | 单 Lottie | 弹出一个动图，点击动图或者按钮跳转 |
| 3 | 双 Lottie | 弹出一个动图，点击或者主动跳转第二个动图，点击第二个动图跳转 |
| 4 | 其余弹窗 1 | 比方，须要前端拼接展现残缺图片的类型 |
| 5 | 其余弹窗 | 须要不同组合字段组合弹窗资源的都算一种类型 |

1.2 弹窗接口设计

比方图片弹窗 popInfo

其余类型弹窗按需设计字段即可

2 配置即弹窗

规范类型的弹窗要反对配置即可，不必反复开发，要反对配置，能够有两种类型：

• 是所有人都出的弹窗，间接配置动态资源即可。
• 种是依据各个接入方本人的条件判断是否出，弹窗资源接入方本人管制，这种须要接入方提供一个接口，这个接口是一个标准接口。

第一种形式比较简单，就不说了。间接说第二种，间接制订一个标准接口，接入方间接实现即可。

对立入参，仅供参考，按需设计即可：

对立出参，这里以单图片弹窗为例：

接入的时候，公共方配置接入方的接口地址即可。

3 频控的两种技术计划

基本上除了某些 APP 之外，所有 APP 的弹窗都不会无限度的弹，都须要频控，否则可能导致用户体验的降落和用户的散失。

3.1 redis setex 弹出缓存主动过期

用户每次弹窗都应用 redis 的 setex 设置过期工夫，这个工夫就是业务容许两次弹窗之间的最小间隔时间。

key 设计：popName + userId

长处：

1. 所有弹窗频控后端可控。
2. 有问题，可操作性强，能够操作 redis，去除某些用户的频控限度。

毛病：

1. 须要 redis，造成架构复杂度回升，如果其余性能不须要应用 redis 的状况下，造成老本上涨。
2. 用户量大的状况，比方上亿：redis 的 key 会十分大，造成 redis 压力。

3.2 前端缓存每个弹窗的最近一次弹出工夫

前端存储每个用户弹窗的工夫，申请后端的时候，把所有弹窗的上次弹出工夫带给后端，由后端计算是否在频控工夫范畴内。

新弹窗弹出工夫，由后端返给前端，前端存储，下次申请的时候带给后端。

长处：

1. 不须要额定的存储，弹窗上次弹出工夫存储在用户的客户端中。
2. 架构简略。
3. 问题好排查，间接看申请参数即可。

毛病：

1. 用户卸载重装客户端的时候，会导致数据失落，造成频控生效；
2. 整个频控须要前后端配合能力实现，任何一方有问题，都有可能导致性能出问题。

4 怎么保障速度

异步执行所有弹窗，按程序返回第一个有数据的弹窗，
参考：Reactor 之 多任务并发执行，后果按程序返回第一个

欢送大家提供更好的实现