使用Go语言开发一个短链接服务：二、架构设计
章节
Gitee https://gitee.com/alxps/short_link
Github https://github.com/1911860538/short_link
在上一篇中，我们介绍了短链接服务的应用场景、基本原理以及Go的基本代码实现。在这一篇，我们将讨论服务的技术选型和架构设计。
后端Web框架
就无脑用Go最流行的Web框架Gin。
数据库
备选方案包括MySQL、PostgreSQL、MongoDB。我们这里的数据存储，基本围绕短链接code和长链接url对应关系的保存和读取。这里我们选择MongoDB，理由有：
1、我们不需要用到关系型数据库的事务（MongoDB4.0后也支持事务，惊不惊喜、意不意外）、join查询等特性。绝大多数读写场景是围绕单条数据，短链接code和长链接url两个字段。
2、MongoDB支持分布式、横向扩展。有朝一日，当我们的短链接服务火得一塌糊涂时，数据量级指数增长，数据库读写性能出现瓶颈、磁盘空间不足，可以直接通过加机器节点解决，无需分库分表
3、在读取方面，MongoDB相对于MySQL、PostgreSQL具有更高的性能。主要因为MongoDB使用了面向文档的存储方式，可以将相关数据存储在一个文档中，从而减少了数据查询时的磁盘IO。
4、在适量级的内存的MongoDB的性能非常迅速的，它将热数据存储在物理内存中，热数据的读写十分快。
5、我们基本是单条数据读取，MongoDB索引（b树）b数相比Mysql索引（b+数）性能更高
Go的MongoDB驱动我们使用MongoDB官方维护的go.mongodb.org/mongo-driver/mongo 。
缓存
鲁迅说：“诸多策略，缓存为王。”
备选方案包括Redis、Memcached。我们的服务使用缓存需求，主要为保存和读取短链接code（作为key）和长链接url（作为value）。根据需求，Memcached可能是一个更好选择，但是我还是选择Redis。
应该选Memchached的理由：
1、不需要用到Redis丰富的数据类型、数据持久化、事务等特性，只需要简单的单key保存和读取
2、根据本人以往的认知，100k以上的数据中，Memcached性能要高于Redis
应该选择Redis的理由：
1、在新版的Redis 6.x版本中，支持多线程处理io，优化了过期算法和过期处理逻辑。上面说的，以往100k以上的数据中Memcached性能要高于Redis认知，如今不一定成立
2、更多人熟悉的是Redis
3、我不会Memcached
Go的Redis驱动我们使用MongoDB官方维护的github.com/redis/go-redis/v9 。
架构图
上一篇中，我们提到了短链接服务的基本原理是，服务维护了短链接和长链接一对一关系，客户端输入短链接，服务端获取到短链接code，到缓存、数据库获取对应的长链接，并http跳转到对应的长链接。
基本架构
流程图
总结
架构基本就设计如此，目前涉及到的组件版本信息如下：
1、Golang 1.22.0
2、Gin github.com/gin-gonic/gin v1.9.1
3、MongoDB 7.0.6； go.mongodb.org/mongo-driver/mongo v1.14
4、Redis 7.2.4；github.com/redis/go-redis/v9
下一篇我们将开始项目代码编写。
