🐿️短网址系统搭建思路与实践历程

起因

有了宝宝后，拍照纪念成了日常，为了随时查看照片，我搭建了一个相册网站。选用 emlog 系统作为相册平台，最初采用一篇文章对应一个生活小事的思路，文章内嵌入单张或多张相关照片，照片直接上传到 emlog 后台存储。

第一次问题与解决

问题

随着照片数量不断增加，发现将高质量、大数量的照片直接保存到网站后台，会大量占用服务器空间。

解决方法

为减轻服务器压力，同时尽量避免额外付费并保证操作便捷性，我搭建了 alist 系统。用 alist 系统生成的外链替代 emlog 的直链。但此次更新需要手动打开每一篇文章，对对应的照片逐一进行操作更新，是一项庞大的工程。

第二次问题与解决

问题

起初 alist 系统的运行还算稳定，然而某天 alist 系统突然崩溃，导致所有外链瞬间失效，照片全部无法显示。

解决方法

当时恰逢阿里云开展活动，10 元一年的资源包可存储 40G 内容。考虑到大厂的服务更有保障，我决定先使用这个方案，将照片上传到 oss 系统。和之前一样，这次更新依旧需要手动打开每篇文章，对照片逐个进行操作更新，同样是一项浩大的工程。

第三次问题与解决

问题

某天我发现阿里云账户欠费了。经排查，原因是我只购买了存储资源包，却没有购买下行资源包，导致下行流量一直直接扣除账户余额。

解决方法

由于阿里云后续还要使用，我先补缴了欠费。同时决定放弃相册网站的阿里云 OSS 方案，另寻其他解决办法。

我梳理了自己的需求：需要一个存储空间相对较大的地方来存储尽可能多的照片，并且要保持照片的原图质量；还需要能够直接访问图片。经过筛选，我发现有些免费网盘支持预览图，而且理论上预览图可以永久保存。

于是开启了第三次更新，和前两次一样，需要手动打开文章，对照片逐个进行操作更新，这无疑又是一次巨大的工程。

第四次问题与解决

问题

预览图链接存在潜在风险，可能会失效，而且预览图链接的获取是否方便、是否唯一也存在疑问。经过观察发现，目前预览图链接超过 30 天未失效，获取可以通过抓包方式，但链接不唯一。

鉴于预览图链接不唯一且不确定何时会失效，这必然会给以后的维护工作带来麻烦，因为一旦链接失效，就需要打开对应的文章，找到照片位置进行补录，这会耗费大量的时间和精力。

解决方法

为解决上述问题，我进行了深入思考。若想减少相册系统更新维护的工作量，就需要相册系统里的照片链接固定，但实际上又可以修改。也就是说，可以设置一个固定的短链接，而生成这个短链接的长链接是可以更新的。

那么，如何让照片和这个固定的短链接产生联系呢？我注意到存储在网盘里的照片名称是固定的，于是想到可以选取照片名称中的固定字段作为短链接里的固定短码。例如，照片名字是 “kjghaghuasege.jpg”，就可以选择 “kjghaghuasege” 这部分作为短链接的短码，这个方法看起来是可行的。

潜在问题与解决

问题

假如我想用的短网址短码已经被其他人使用了，那么在更新短网址系统时，就无法与照片名字完美契合，这显然不是我想要的结果。而且，短网址系统如何识别不同的用户呢？目前来看，短网址里的短码数量是有限的，遵循谁先用谁占有的原则。如果我和其他人都需要使用相同的字段作为短码，总不能一直守在电脑旁抢短码吧。

解决方法

在短网址中加入用户识别字段 uid，通过这种方式来区分不同的用户，这样就能有效解决短码争抢的问题。

终极实现

将生成的短链接配置到网站中。如果需要更新，只需用固定短码对照照片名字生成新的长链接，然后重新生成短链接即可。也就是说，把之前旧的失效长链接替换成新的可用长链接。

潜在问题应对

如果短网址系统不幸崩溃，或者短网址系统的域名到期，只需按照需求重新搭建一个短网址系统。然后通过数据库批量替换短网址域名，再利用 api 重新生成所有短链接，就可以让系统恢复正常。

对照规则

照片的名字（去掉格式后缀）即为短链接的短码。