项目背景:
对于一些需要大量图片或文件的存储业务,需要提供一个图片存储的服务,用来保存大量的图片。除此之外,存储图片时图片的 URL 链接往往会非常长,还需要提供原始链接到短链接编解码的服务。
短链接业务场景:在做营销短信业务时,一条短信可能只有短短的 70 个字。如果短信附带的链接地址特别长,导致一条短信发不完。对于企业来说,想要发送一条信息,但分割成了两条短信,成本会增加,同时还有链接被切分失效的风险。对于用户来说,不想读多条短信,可能丢失重要信息。
综上所述,对于图片存储业务,短链接是重要的一环。
系统架构:

其中 Gateway 网关采用的是 Nginx,注册中心服务发现采用的是 Docker,对象存储 Object Storage 采用的是腾讯云的对象存储 COS,缓存 Cache 采用的是 Redis,数据库存储 DB 采用的是 MySQL。
开发模块:

业务流程图:


数据库表设计:
本次业务一共需要两个表,一个是负责存储未登录用户数据的公用表 url_map,一个是负责存储登录用户数据的个人表 url_map_user。SQL 语句如下:
CREATE TABLE `url_map` (
`id` BIGINT(64) NOT NULL AUTO_INCREMENT,
`short_key` VARCHAR(45) NOT NULL DEFAULT '',
`original_url` VARCHAR(512) NOT NULL DEFAULT '',
`times` INT NOT NULL DEFAULT 0,
`create_at` BIGINT(64) NOT NULL DEFAULT 0,
`update_at` BIGINT(64) NOT NULL DEFAULT 0,
PRIMARY KEY (`id`),
INDEX `index_original_url` USING BTREE (`original_url`) VISIBLE,
INDEX `index_short_key` USING BTREE (`short_key`) VISIBLE,
UNIQUE INDEX `unique_original_url` USING BTREE (`original_url`) VISIBLE)
ENGINE = INNODB
DEFAULT CHARACTER SET = utf8mb4;
CREATE TABLE `url_map_user` (
`id` BIGINT(64) NOT NULL AUTO_INCREMENT,
`user_id` BIGINT(64) NOT NULL DEFAULT 0,
`short_key` VARCHAR(45) NOT NULL DEFAULT '',
`original_url` VARCHAR(512) NOT NULL DEFAULT '',
`times` INT NOT NULL DEFAULT 0,
`create_at` BIGINT(64) NOT NULL DEFAULT 0,
`update_at` BIGINT(64) NOT NULL DEFAULT 0,
PRIMARY KEY (`id`),
INDEX `index_user_id` USING BTREE (`user_id`) VISIBLE,
INDEX `index_original_url` USING BTREE (`original_url`) VISIBLE,
INDEX `index_short_key` USING BTREE (`short_key`) VISIBLE,
UNIQUE INDEX `unique_original_url` USING BTREE (`original_url`) VISIBLE)
ENGINE = INNODB
DEFAULT CHARACTER SET = utf8mb4;
可以看到,在 user_map 表中对 original_url 和 short_key 这两个字段加了索引,同时 original_url 还设置成了唯一索引。在 user_map 中除了 original_url 和 short_key 两个索引,还对 user_id 字段加入了索引。
对象存储COS配置:

COS 的存储桶的访问权限设置为公有读私有写。多 AZ 特性是指提供同城容灾功能,本项目作为个人使用,不用过于考虑数据恢复,为了防止多余流量费用消耗,这里关闭多 AZ 特性。


可以看到,最后创建了一个名为 mediahubdev-1340784356 的桶,后面的数字是用户的 APPID。


对COS对象存储配置自定义 CDN 加速域名,最终状态如上图所示。

No responses yet