• Babel 插件通关秘籍
  • Git 原理详解及实用指南
  • Nest 通关秘籍
  • React 通关秘籍
  • TypeScript 全面进阶指南
  • TypeScript 类型体操通关秘籍
  • 现代CSS
  • Babel 插件通关秘籍
  • Git 原理详解及实用指南
  • Nest 通关秘籍
  • React 通关秘籍
  • TypeScript 全面进阶指南
  • TypeScript 类型体操通关秘籍
  • 现代CSS
  • Nest 通关秘籍

    • 1.开篇词
    • 2.给你 5 个学习 Nest 的理由,你会心动么
    • 3.Nest 基础概念扫盲
    • 4.快速掌握 Nest CLI
    • 5.五种HTTP数据传输方式
    • 6.IoC 解决了什么痛点问题?
    • 7.如何调试 Nest 项目
    • 8.使用多种 Provider,灵活注入对象
    • 9.全局模块和生命周期
    • 10.AOP 架构有什么好处?
    • 11.一网打尽 Nest 全部装饰器
    • 12.Nest 如何自定义装饰器
    • 13.Metadata 和 Reflector
    • 14.ExecutionContext:切换不同上下文
    • 15.Module 和 Provider 的循环依赖怎么处理?
    • 16.如何创建动态模块
    • 17.Nest 和 Express 的关系,如何切到 fastify
    • 18.Nest 的 Middleware
    • 19.RxJS 和 Interceptor
    • 20.内置 Pipe 和自定义 Pipe
    • 21.如何使用 ValidationPipe 验证 post 请求参数
    • 22.如何自定义 Exception Filter
    • 23.图解串一串 Nest 核心概念
    • 24.接口如何实现多版本共存
    • 25.Express 如何使用 multer 实现文件上传
    • 26.Nest 如何使用 multer 实现文件上传
    • 27.图书管理系统:需求分析和原型图
    • 28.图书管理系统:用户模块后端开发
    • 29.图书管理系统:图书模块后端开发
    • 30.图书管理系统:用户模块前端开发
    • 31.图书管理系统:图书模块前端开发--图书搜索
    • 32.图书管理系统:图书模块前端开发--图书增删改
    • 33.图书管理系统:项目总结
    • 34.大文件分片上传
    • 35.最完美的 OSS 上传方案
    • 36.Nest 里如何打印日志?
    • 37.为什么 Node 里要用 Winston 打印日志?
    • 38.Nest 集成日志框架 Winston
    • 39.通过 Desktop 学 Docker 也太简单了
    • 40.你的第一个 Dockerfile
    • 41.Nest 项目如何编写 Dockerfile
    • 42.提升 Dockerfile 水平的 5 个技巧
    • 43.Docker 是怎么实现的?
    • 44.为什么 Node 应用要用 PM2 来跑?
    • 45.快速入门 MySQL
    • 46.SQL 查询语句的所有语法和函数
    • 47.一对一、join 查询、级联方式
    • 48.一对多、多对多关系的表设计
    • 49.子查询和 EXISTS
    • 50.SQL 综合练习
    • 51.MySQL 的事务和隔离级别
    • 52.MySQL 的视图、存储过程和函数
    • 53.使用 Node 操作 MySQL 的两种方式
    • 54.快速掌握 TypeORM
    • 55.TypeORM 一对一的映射和关联 CRUD
    • 56.TypeORM 一对多的映射和关联 CRUD
    • 57.TypeORM 多对多的映射和关联 CRUD
    • 58.在 Nest 里集成 TypeORM
    • 59.TypeORM 如何保存任意层级的关系?
    • 60.为什么生产环境要用 TypeORM 的 migration 迁移功能?
    • 61.Nest 项目里如何使用 TypeORM 迁移
    • 62.如何动态读取不同环境的配置?
    • 63.快速入门 Redis
    • 64.在 Nest 里操作 Redis
    • 65.为什么不用 cache-manager 操作 Redis?
    • 66.两种登录状态保存方式:JWT、Session
    • 67.Nest 里实现 Session 和 JWT
    • 68.MySQL + TypeORM + JWT 实现登录注册
    • 69.基于 ACL 实现权限控制
    • 70.基于 RBAC 实现权限控制
    • 71.基于 access_token 和 refresh_token 实现登录状态无感刷新
    • 72.单 token 无限续期,实现登录状态无感刷新
    • 73.使用 passport 做身份认证
    • 74.passport 实现 GitHub 三方账号登录
    • 75.passport 实现 Google 三方账号登录
    • 76.为什么要使用 Docker Compose ?
    • 77.Docker 容器通信的最简单方式:桥接网络
    • 78.Docker 支持重启策略,是否还需要 PM2
    • 79.快速掌握 Nginx 的 2 大核心用法
    • 80.基于 Nginx 实现灰度系统
    • 81.基于 Redis 实现分布式 session
    • 82.Redis + 高德地图,实现附近的充电宝
    • 83.用 Swagger 自动生成 api 文档
    • 84.如何灵活创建 DTO
    • 85.class-validator 的内置装饰器,如何自定义装饰器
    • 86.序列化 Entity,你不需要 VO 对象
    • 87.手写序列化 Entity 的拦截器
    • 88.使用 compodoc 生成文档
    • 89.Node 如何发邮件?
    • 90.实现基于邮箱验证码的登录
    • 91.定时任务 + Redis 实现阅读量计数
    • 92.Nest 的 3 种定时任务
    • 93.Nest 里如何实现事件通信?
    • 94.HttpModule + pinyin 实现天气预报查询服务
    • 95.如何记录请求日志
    • 96.短链服务?自己写一个
    • 97.Nest 实现 Server Sent Event 数据推送
    • 98.用 minio 自己搭一个 OSS 服务
    • 99.前端如何直传文件到 Minio
    • 100.基于 sharp 实现 gif 压缩工具
    • 101.大文件如何实现流式下载?
    • 102.Puppeteer 实现爬虫,爬取 BOSS 直聘全部前端岗位
    • 103.实现扫二维码登录
    • 104.Nest 的 REPL 模式
    • 105.实现 Excel 导入导出
    • 106.如何用代码动态生成 PPT
    • 107.如何拿到服务器 CPU、内存、磁盘状态
    • 108.Nest 如何实现国际化?
    • 109.会议室预订系统:需求分析和原型图
    • 110.会议室预订系统:技术方案和数据库设计
    • 111.会议室预订系统:用户管理模块-用户注册
    • 112.会议室预订系统:用户管理模块-配置抽离、登录认证鉴权
    • 113.会议室预订系统:用户管理模块-interceptor、修改信息接口
    • 114.会议室预订系统:用户管理模块-用户列表和分页查询
    • 115.会议室预订系统:用户管理模块-swagger 接口文档
    • 116.会议室预订系统:用户管理模块-用户端登录注册页面
    • 117.会议室预订系统:用户管理模块-用户端信息修改页面
    • 118.会议室预订系统:用户管理模块-头像上传
    • 119.会议室预订系统:用户管理模块-管理端用户列表页面
    • 120.会议室预订系统:用户管理模块-管理端信息修改页面
    • 121.会议室预订系统:会议室管理模块-后端开发
    • 122.会议室预订系统:会议室管理模块-管理端前端开发
    • 123.会议室预订系统:会议室管理模块-用户端前端开发
    • 124.会议室预订系统:预定管理模块-后端开发
    • 125.会议室预订系统:预定管理模块-管理端前端开发
    • 126.会议室预订系统:预定管理模块-用户端前端开发
    • 127.会议室预订系统:统计管理模块-后端开发
    • 128.会议室预订系统:统计管理模块-前端开发
    • 129.会议室预订系统:后端项目部署到阿里云
    • 130.会议室预订系统:前端项目部署到阿里云
    • 131.会议室预定系统:用 migration 初始化表和数据
    • 132.会议室预定系统:文件上传 OSS
    • 133.会议室预定系统:Google 账号登录后端开发
    • 134.会议室预定系统:Google 账号登录前端开发
    • 135.会议室预定系统:后端代码优化
    • 136.会议室预定系统:集成日志框架 winston
    • 137.会议室预定系统:前端代码优化
    • 138.会议室预定系统:全部功能测试
    • 139.会议室预定系统:项目总结
    • 140.Nest 如何创建微服务?
    • 141.Nest 的 Monorepo 和 Library
    • 142.用 Etcd 实现微服务配置中心和注册中心
    • 143.Nest 集成 Etcd 做注册中心、配置中心
    • 144.用 Nacos 实现微服务配置中心和注册中心
    • 145.基于 gRPC 实现跨语言的微服务通信
    • 146.快速入门 ORM 框架 Prisma
    • 147.Prisma 的全部命令
    • 148.Prisma 的全部 schema 语法
    • 149.Primsa Client 单表 CRUD 的全部 api
    • 150.Prisma Client 多表 CRUD 的全部 api
    • 151.在 Nest 里集成 Prisma
    • 152.为什么前端监控系统要用 RabbitMQ?
    • 153.基于 Redis 实现关注关系
    • 154.基于 Redis 实现各种排行榜(周榜、月榜、年榜)
    • 155.考试系统:需求分析
    • 156.考试系统:技术方案和数据库设计
    • 157.考试系统:微服务、Lib 拆分
    • 158.考试系统;用户注册
    • 159.考试系统:用户登录、修改密码
    • 160.考试系统:考试微服务
    • 161.考试系统:登录、注册页面
    • 162.考试系统:修改密码、试卷列表页面
    • 163.考试系统:新增试卷、回收站
    • 164.考试系统:试卷编辑器
    • 165.考试系统:试卷回显、预览、保存
    • 166.考试系统:答卷微服务
    • 167.考试系统:答题页面
    • 168.考试系统:自动判卷
    • 169.考试系统:分析微服务、排行榜页面
    • 170.考试系统:整体测试
    • 171.考试系统:项目总结
    • 172.用 Node.js 手写 WebSocket 协议
    • 173.Nest 开发 WebSocket 服务
    • 174.基于 Socket.io 的 room 实现群聊
    • 175.聊天室:需求分析和原型图
    • 176.聊天室:技术选型和数据库设计
    • 177.聊天室:用户注册
    • 178.聊天室:用户登录
    • 179.聊天室:修改密码、修改信息
    • 180.聊天室:好友列表、发送好友申请
    • 181.聊天室:创建聊天室、加入群聊
    • 182.聊天室:登录、注册页面开发
    • 183.聊天室:修改密码、信息页面开发
    • 184.聊天室:头像上传
    • 185.聊天室:好友∕群聊列表页面
    • 186.聊天室:添加好友弹窗、通知页面
    • 187.聊天室:聊天功能后端开发
    • 188.聊天室:聊天功能前端开发
    • 189.聊天室:一对一聊天
    • 190.聊天室:创建群聊、进入群聊
    • 191.聊天室:发送表情、图片、文件
    • 192.聊天室:收藏
    • 193.聊天室:全部功能测试
    • 194.聊天室:项目总结
    • 195.MongoDB 快速入门
    • 196.使用 mongoose 操作 MongoDB 数据库
    • 197.GraphQL 快速入门
    • 198.Nest 开发 GraphQL 服务:实现 CRUD
    • 199.GraphQL + Primsa + React 实现 TodoList
    • 200.如何调试 Nest 源码?

生活中我们经常遇到需要短链的场景。

比如一段很长的 url:

分享出去很不方便。

这时候就可以通过短链服务把它缩短:

点击短链会跳转到原链接:

这种在短信里很常见:

因为短信是按照字数收费的,太长不但阅读体验不好,费用也高。

所以都会生成短链之后再加到短信里。

那短链是怎么实现的呢?

很容易想到的思路是这样的:

用 0、1、2、3、4、5 的递增 id 标识每个 url,把映射关系存到数据库里。

这样访问短链的时候从数据库中查出对应的长链接,返回 302 重定向即可。

比如刚才的短链服务就是通过 302 把短链重定向到长链:

这里也可以用 301。

301 是永久重定向,就是重定向一次之后,下次浏览器就不会再访问短链,会直接访问长链接。

302 是临时重定向,下次访问短链依然会先访问短链服务,返回 302 后再重定向到长链。

这两种都可以,301 的话,短链服务压力小,不过 302 每次都会先访问短链服务,这样可以记录链接的访问次数等数据。

比如刚才我们用的短链服务,就会记录这个链接的访问记录:

还可以做一些分析:

所以访问记录也挺有价值的。

一般短链服务都是用 302 来重定向。

每个 url 的 id 我们会用 Base64 或者 Base62 编码:

const data = "123456";
const buff = Buffer.from(data);
const base64data = buff.toString("base64");

console.log(base64data);

base64 就是 26 个大写字母、26 个小写字母、10 个数字、2 个特殊字符,一共 64 个字符。

而 base62 则是去掉了两个特殊字符,一共 62 个字符。

做短链的话,我们用 base62 比较多。

安装用到的包:

npm install base62

测试下:

const base62 = require("base62/lib/ascii");

const res = base62.encode(123456);

console.log(res);

按照这个思路,我们就能实现一个短链服务。

在 mysql 里创建压缩码和长链接的对应关系的表,用 mysql 的自增 id 然后进行 base62 之后作为压缩码。

访问短链的时候,根据压缩码查询这个表,找到长链接,通过 302 重定向到这个链接,并且记录短链访问记录。

这样是可以的,但有个问题:

用自增 id 作为压缩码,那别人很容易拿到上一个、下一个压缩码,从而拿到别的短链,万一这个短链是用来兑奖之类的呢?

这样就会有安全问题。

所以自增 id 的方案不太好。

那如果我们对 url 做 hash 呢?

也就是这样:

const crypto = require("crypto");

function md5(str) {
    const hash = crypto.createHash("md5");
    hash.update(str);
    return hash.digest("hex");
}

console.log(md5("111222"));

这样太长了,有 32 位呢:

倒是可以每 4 位取一个数字,然后组成一个 8 位的压缩码。

但是,这样是有碰撞的可能的。

也就是两个不同的 url 生成的压缩码一样。

所以,hash 的方案也不行。

还有一种方案,就是通过随机数的方式生成压缩码。

比如这样:

const base62 = require("base62/lib/ascii");

function generateRandomStr(len) {
    let str = "";
    for (let i = 0; i < len; i++) {
        const num = Math.floor(Math.random() * 62);
        str += base62.encode(num);
    }
    return str;
}

console.log(generateRandomStr(6));

随机生成 0-61 的数字,然后转成字符。

62 的 6 次方,范围有 580 亿,足够用了:

当然,随机数也是有碰撞的可能的,这个可以在生成之后查下表,看下是否有重复的,有的话就再重新生成。

不过每次生成都查表的话性能会不好,那有啥优化的方案呢?

我们可以提前生成一批压缩码,用的时候直接取!

可以用个定时任务来跑,每天凌晨 4 点生成一批。

这样,生成压缩码的方案就完美了。

小结下:

用递增 id + base62 作为压缩码,可以保证唯一,但是容易被人拿到其它短码,不安全。

用 url 做 hash 之后取一部分然后 base62 做为压缩码,有碰撞的可能,不唯一。

随机生成字符串再查表检测是否重复,可以保证唯一且不连续,但是性能不好。用提前批量生成的方式可以解决。

有的同学可能提到 uuid、雪花 id 之类的,那些都太长了,不适合用来做压缩码:

思路理清了,我们来写下代码。

创建个 nest 项目:

npm install -g @nestjs/cli

nest new short-url

先进入项目,把它跑起来:

npm run start:dev

浏览器看到 hello world,代表 nest 服务跑成功了:

然后我们用 docker 把 mysql 跑起来:

从 docker 官网下载 docker desktop,这个是 docker 的桌面端:

跑起来后,搜索 mysql 镜像(这步需要科学上网),点击 run:

输入容器名、端口映射、以及挂载的数据卷,还要指定一个环境变量:

端口映射就是把宿主机的 3306 端口映射到容器里的 3306 端口,这样就可以在宿主机访问了。

数据卷挂载就是把宿主机的某个目录映射到容器里的 /var/lib/mysql 目录,这样数据是保存在本地的,不会丢失。

而 MYSQL_ROOT_PASSWORD 的密码则是 mysql 连接时候的密码。

跑起来后,我们用 GUI 客户端连上,这里我们用的是 mysql workbench,这是 mysql 官方提供的免费客户端:

连接上之后,点击创建 database:

指定名字、字符集为 utf8mb4,然后点击右下角的 apply。

创建成功之后在左侧就可以看到这个 database 了:

当然,现在还没有表。

我们在 Nest 里用 TypeORM 连接 mysql。

安装用到的包:

npm install --save @nestjs/typeorm typeorm mysql2

mysql2 是数据库驱动,typeorm 是我们用的 orm 框架,而 @nestjs/tyeporm 是 nest 集成 typeorm 用的。

在 AppModule 里引入 TypeORM,指定数据库连接配置:

TypeOrmModule.forRoot({
  type: "mysql",
  host: "localhost",
  port: 3306,
  username: "root",
  password: "guang",
  database: "short-url",
  synchronize: true,
  logging: true,
  entities: [],
  poolSize: 10,
  connectorPackage: 'mysql2',
  extra: {
      authPlugin: 'sha256_password',
  }
}),

然后创建个 entity:

src/entities/UniqueCode.ts

import { Column, Entity, PrimaryGeneratedColumn } from "typeorm";

@Entity()
export class UniqueCode {
    @PrimaryGeneratedColumn()
    id: number;

    @Column({
        length: 10,
        comment: "压缩码",
    })
    code: string;

    @Column({
        comment: "状态, 0 未使用、1 已使用",
    })
    status: number;
}

在 AppModule 引入:

保存之后,TypeORM会自动建表:

表创建好了,接下来插入一些数据:

nest g service unique-code --flat --no-spec

生成 service 类,--flat 是不生成目录 --no-spec 是不生成测试代码:

然后创建 src/utils.ts 来放生成随机压缩码的代码:

import * as base62 from "base62/lib/ascii";

export function generateRandomStr(len: number) {
    let str = "";
    for (let i = 0; i < len; i++) {
        const num = Math.floor(Math.random() * 62);
        str += base62.encode(num);
    }
    return str;
}

安装用到的包:

npm install base62

然后在 UniqueCodeService 添加下插入压缩码的方法:

import { Injectable } from "@nestjs/common";
import { InjectEntityManager } from "@nestjs/typeorm";
import { EntityManager } from "typeorm";
import { generateRandomStr } from "./utils";
import { UniqueCode } from "./entities/UniqueCode";

@Injectable()
export class UniqueCodeService {
    @InjectEntityManager()
    private entityManager: EntityManager;

    async generateCode() {
        let str = generateRandomStr(6);

        const uniqueCode = await this.entityManager.findOneBy(UniqueCode, {
            code: str,
        });

        if (!uniqueCode) {
            const code = new UniqueCode();
            code.code = str;
            code.status = 0;

            return await this.entityManager.insert(UniqueCode, code);
        } else {
            return this.generateCode();
        }
    }
}

就是生成随机的长度为 6 的字符串,查下数据库,如果没查到,就插入数据,否则重新生成。

我们用定时任务的方式来跑:

安装用到的包:

npm install --save @nestjs/schedule

在 AppModule 注册下:

然后在 service 方法上声明,每 5s 执行一次:

@Cron(CronExpression.EVERY_5_SECONDS)

然后就可以看到一直在打印 insert 语句:

数据库中也可以看到插入的未使用的压缩码:

当然,一个个这么插入可太费劲了。

我们一般是在凌晨 4 点左右批量插入一堆,比如一次性插入 10000 个。

@Cron(CronExpression.EVERY_DAY_AT_4AM)
async batchGenerateCode() {
    for(let i = 0; i< 10000; i++) {
        this.generateCode();
    }
}

这里我们是每次 insert 一个,你也可以每次 insert 10 个 20 个这种。

批量插入性能会好,因为执行的 sql 语句少。这里我们就先不优化了。

压缩码有了,接下来生成 url 和压缩码的对应关系就好了。

同样需要创建 entity:

src/entities/ShortLongMap.ts

import {
    Column,
    CreateDateColumn,
    Entity,
    PrimaryGeneratedColumn,
} from "typeorm";

@Entity()
export class ShortLongMap {
    @PrimaryGeneratedColumn()
    id: number;

    @Column({
        length: 10,
        comment: "压缩码",
    })
    shortUrl: string;

    @Column({
        length: 200,
        comment: "原始 url",
    })
    longUrl: string;

    @CreateDateColumn()
    createTime: Date;
}

在 entities 引入:

同样会自动建表:

生成短链就是往这个表里添加记录。

我们加一个生成短链的 service:

nest g service short-long-map --flat --no-spec

实现生成短链的方法:

import { UniqueCodeService } from "./unique-code.service";
import { Inject, Injectable } from "@nestjs/common";
import { InjectEntityManager } from "@nestjs/typeorm";
import { EntityManager } from "typeorm";
import { ShortLongMap } from "./entities/ShortLongMap";
import { UniqueCode } from "./entities/UniqueCode";

@Injectable()
export class ShortLongMapService {
    @InjectEntityManager()
    private entityManager: EntityManager;

    @Inject(UniqueCodeService)
    private uniqueCodeService: UniqueCodeService;

    async generate(longUrl: string) {
        let uniqueCode = await this.entityManager.findOneBy(UniqueCode, {
            status: 0,
        });

        if (!uniqueCode) {
            uniqueCode = await this.uniqueCodeService.generateCode();
        }
        const map = new ShortLongMap();
        map.shortUrl = uniqueCode.code;
        map.longUrl = longUrl;

        await this.entityManager.insert(ShortLongMap, map);
        await this.entityManager.update(
            UniqueCode,
            {
                id: uniqueCode.id,
            },
            {
                status: 1,
            }
        );
        return uniqueCode.code;
    }
}

这里就是先从 unique-code 表里取一个压缩码来用,如果没有可用压缩码,那就生成一个。

然后在 short-long-map 表里插入这条新的短链映射,并且把用到的压缩码状态改为 1。

我们在 AppController 里添加一个接口:

import { ShortLongMapService } from "./short-long-map.service";
import { Controller, Get, Inject, Query } from "@nestjs/common";
import { AppService } from "./app.service";

@Controller()
export class AppController {
    constructor(private readonly appService: AppService) {}

    @Inject(ShortLongMapService)
    private shortLongMapService: ShortLongMapService;

    @Get()
    getHello(): string {
        return this.appService.getHello();
    }

    @Get("short-url")
    async generateShortUrl(@Query("url") longUrl) {
        return this.shortLongMapService.generate(longUrl);
    }
}

在浏览器里测试下:

可以看到,打印了 4 条 sql:

首先 select 查出一个压缩码来,然后 insert 插入压缩码和 url 的映射,之后再把它 select 出来返回。

最后 update 更新压缩码状态。

看 sql 来说,是符合我们的预期的。

然后看下数据:

也是对的。

那剩下的事情就很简单了,只要加一个重定向就好:

首先在 service 里添加根据压缩码查询 longUrl 的方法:

async getLongUrl(code: string) {
    const map = await this.entityManager.findOneBy(ShortLongMap, {
        shortUrl: code
    });
    if(!map) {
        return null;
    }
    return map.longUrl;
}

然后在 AppController 里添加一个重定向的接口:

image.png

@Get(':code')
@Redirect()
async jump(@Param('code') code) {
    const longUrl = await this.shortLongMapService.getLongUrl(code);
    if(!longUrl) {
      throw new BadRequestException('短链不存在');
    }
    return {
      url: longUrl,
      statusCode: 302
    }
}

测试下:

image.png

2023-12-01 14.32.03.gif

这样,我们的短链服务就完成了。

其他的非核心功能,比如记录每次访问记录,做一些分析:

这些比较简单,就不实现了。

案例代码上传了 github: https://github.com/QuarkGluonPlasma/nestjs-course-code/tree/main/short-url

总结

我们经常用短链服务把长的 url 缩短,在短信里的链接一般都是这种。

我们用 Nest 自己实现了一个。

核心是压缩码的生成,我们分析了自增 id + base62,这样容易被人拿到其它短链,不安全。hash + base62 会有冲突的可能,所以最终用的是自己生成随机数 + base62 的方案。

当然,这个随机字符串最好是提前生成,比如用定时任务在低峰期批量生成一堆,之后直接用就好了。

短链的重定向使用 302 临时重定向,这样可以记录短链访问记录,做一些分析。

市面上的短链服务,基本都是这样实现的。

上次更新: 6/21/25, 9:42 AM
贡献者: YNight
Prev
95.如何记录请求日志
Next
97.Nest 实现 Server Sent Event 数据推送