乐趣区

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

jiezi

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

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

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

这里是咱们的设计方案：

1 弹窗后端接口设计

1.1 弹窗类型很重要

首先要束缚弹窗类型，

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

1.2 弹窗接口设计

字段名称 二级字段 字段类型 阐明
status int 成功失败状态码
message String 成功失败信息
data
popName String 弹窗名称，能够用来埋点和弹窗辨别
popInfo Object 弹窗资源资源，每个类型弹窗外面字段不统一

比方图片弹窗 popInfo

字段名称 字段类型 阐明
imgaeUrl String 图片 url
imageWidth int 图片宽度
imageHeight 图片高度
jumpUrl String 跳转 url
popType int 弹窗类型

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

2 配置即弹窗

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

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

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

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

字段名称 字段类型 阐明
userId String 用户 id
userName String 用户昵称
deviceId String 设施 id
lat String 纬度
lon String 经度

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

字段名称 二级字段 字段类型 阐明
status int 成功失败状态码
message String 成功失败信息
data
imgaeUrl String 图片 url
imageWidth int 图片宽度
imageHeight int 图片高度
jumpUrl String 跳转地址
其余通用字段 String 埋点等通用字段

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

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 之 多任务并发执行，后果按程序返回第一个

欢送大家提供更好的实现

退出移动版