文章目录加载中

二维码生成服务

# 前端动态生成

利用qrcode.js就可以在前端动态生成二维码。

好处:所有二维码动态生成,不用存储静态文件。

不足:

  • 在不对链接做处理的情况下,如果链接很长,二维码信息多,会造成生成的二维码图片“密密麻麻”,在远距离/弱光环境下无法扫
  • 因为不是二维码图片,所以只能截图分享,操作成本高

# 前端动态生成 + 短链接服务

利用短链接服务,可以将长链接转换为短链接,再生成二维码。

用户扫码后,会进入短链接,进行一次查询,得到对应的长链接,再跳转到长链接。

好处:

  • 所有二维码动态生成,不用存储静态文件
  • 由于是短链接,信息少,所以二维码非常清晰

不足:

  • 因为不是二维码图片,所以只能截图分享,操作成本高
  • 短链接作为中台服务,域名通常不会变动。当其它业务使用短链接,不合规造成域名被封,那么二维码就无法使用

# 前端动态生成 + 存储参数

不同于短链接服务,利用另一种思路缩短链接,来降低二维码复杂度。

将长链接的参数存储到 DB 中,并且给此条记录分配一个 param_id。在生成二维码的时候,只需要使用path+param_id拼接的 url 即可。

不足:

  • 用户在扫码二维码的时候,需要根据 param_id 做多一次查询
  • 参数千变万化,虽然可以利用字段排序来减少重复参数的数量,但是存储的记录依然非常多。并且随着业务发展,这些参数含义可能过时,浪费存储。

# 静态生成 + 存储参数

动态生成的问题

不论哪种动态生成,都不能既保证 CDN 缓存命中率(链接都不相同),又保证低成本分享门槛(用户需要截屏)。

如果只是单纯的静态生成,也就是说生成二维码图片,存储到 cdn,用户可以直接访问 cdn,得到二维码图片。虽然这个分享,但是存在以下几个问题:

  • 不同业务、不同参数、不同链接。二维码都是不相同的,要存储很多资源。
  • 过期业务、过期接口,生成的二维码都是没用的,浪费存储资源。
  • 对于高峰期或者热点业务,新的参数和 API 会有新的二维码生成,导致无法预热缓存。

怎么解决以上问题?就是借助在 DB 中“存储参数”的思路解决。解决思路的本质是创建个 Pool(池),里面囤积的是 param_id。

假设 Pool 大小是 10w,假设业务的 path 是相对固定的,二维码的信息是:path+param_id

那么可以先针对 Pool 中 param_id,生成对应的 10w 个二维码,并且进行缓存。

在给用户生成二维码的时候,就从 Pool 中找到没有对应参数的 param_id,为其设置记录,并且返回其二维码图片地址(已经在 CDN 了)。

当参数没用的时候,比如交易完成,那么将 param_id 记录对应的参数设为空,此 param_id 被释放,重回 db。但是对应的二维码还是在 cdn,等 param_id 有对应参数的时候,可以再次使用。

二维码囤积方式

1、夜间生成,白天复用

2、工作日生成,周末高峰期复用

3、白天捡漏

# 问题的价值

问题的价值在于如何生成命中率高的静态资源,并且静态资源能复用,代表不同的业务含义。

# 参考链接

本文来自心谭博客:xin-tan.com,经常更新web和算法的文章笔记,前往github查看目录归纳:github.com/dongyuanxin/blog