https://juejin.cn/post/6844904090602848270
岗位是“后端高级开发工程师”，二面的时候问到的。一开始，面试官笑眯眯地让我做个自我介绍，然后聊了聊项目。
当完美无瑕（吞吞吐吐）地聊完项目，并写了一道算法题之后。
面试官就开始发问了：小伙子，简历里面写到了熟悉架构设计是吧，那你知道程序设计的‘三高’指什么吗？
我心想，那不是由于程序员的系统不靠谱，领导不当人，天天加班改 BUG，导致年纪轻轻都高血脂、高血压和高血糖嘛！
但是，既然是面试，那领导肯定不愿意听这，于是我回答：程序三高，就是系统设计时需要考虑的高并发、高性能和高可用：
- 高并发就是在系统开发的过程中，需要保证系统可以同时并行处理很多请求；
- 高性能是指程序需要尽可能地占用更少的内存和 CPU，并且处理请求的速度要快；
- 高可用通常描述系统在一段时间内不可服务的时候很短，比如全年停机不超过 31.5 秒，俗称 6 个 9，即保证可用的时间为 99.9999%。
于是，面试官微微点头，心想小伙子还行，既然这难不住你，那我可得出大招了，就来道系统设计题吧！
今天，我们来谈谈如何设计一个高性能短链系统，短链系统设计看起来很简单，但每个点都能展开很多知识点，也是在面试中非常适合考察侯选人的一道设计题，本文将会结合我们生产上稳定运行两年之久的高性能短链系统给大家简单介绍下设计这套系统所涉及的一些思路，希望对大家能有一些帮助。
本文将会从以下几个方面来讲解，每个点包含的信息量都不少，相信大家看完肯定有收获
- 短链有啥好处，为啥要设计它，用长链不香吗
- 短链跳转的基本原理
- 短链生成的几种方法
- 短链的架构支撑
注：里面涉及到不少布隆过滤器，snowflake 等技术，由于不是本文重点，所以建议大家看完后再自己去深入了解，不然展开讲篇幅会很长
来看下以下极客时间发我的营销短信，点击下方蓝色的链接（短链）
3、链接太长在有些平台上无法自动识别为超链接
- 301，代表 永久重定向，也就是说第一次请求拿到长链接后，下次浏览器再去请求短链的话，不会向短网址服务器请求了，而是直接从浏览器的缓存里拿，这样在 server 层面就无法获取到短网址的点击数了，如果这个链接刚好是某个活动的链接，也就无法分析此活动的效果。所以我们一般不采用 301。
- 302，代表 临时重定向，也就是说每次去请求短链都会去请求短网址服务器（除非响应中用 Cache-Control 或 Expired 暗示浏览器缓存）,这样就便于 server 统计点击数，所以虽然用 302 会给 server 增加一点压力，但在数据异常重要的今天，这点代码是值得的，所以推荐使用 302！
- 此外 某些场景 可以使用web中间页的形式，特别是app跳转与小程序跳转
推荐MurmurHash算法
如何缩短域名？
画外音：6 位 62 进制数可表示 568 亿的数，应付长链转换绰绰有余
为什么是62进制而非64进制？因为64进制包含2位不可见或者因操作系统不同的不可见控制字符
如何解决哈希冲突的问题？
既然是哈希函数，不可避免地会产生哈希冲突（尽管概率很低），该怎么解决呢。
我们知道既然访问访问短链能跳转到长链，那么两者之前这种映射关系一定是要保存起来的，可以用 Redis 或 Mysql 等，这里我们选择用 Mysql 来存储。表结构应该如下所示
于是我们有了以下设计思路。
将长链（lurl）经过 MurmurHash 后得到短链。
再根据短链去 short_url_map 表中查找看是否存在相关记录，如果不存在，将长链与短链对应关系插入数据库中，存储。
如果存在，说明已经有相关记录了，此时在长串上拼接一个自定义好的字段，比如「DUPLICATE」，然后再对接接的字段串「lurl + DUPLICATE」做第一步操作，如果最后还是重复呢，再拼一个字段串啊，只要到时根据短链取出长链的时候把这些自定义好的字符串移除即是原来的长链。
PS 如果语言的murmurhash没有直接的实现 请用：
如何优化以减少sql次数？
以上步骤显然是要优化的，插入一条记录居然要经过两次 sql 操作（根据短链查记录，将长短链对应关系插入数据库中），如果在高并发下，显然会成为瓶颈。
画外音：一般数据库和应用服务（只做计算不做存储）会部署在两台不同的 server 上，执行两条 sql 就需要两次网络通信，这两次网络通信与两次 sql 执行是整个短链系统的性能瓶颈所在！（但是一般 读写分离的话 也还好）
所以该怎么优化呢？
唯一索引直接插入法
首先我们需要给短链字段 surl 加上唯一索引
当长链经过 MurmurHash 得到短链后，直接将长短链对应关系插入 db 中，如果 db 里不含有此短链的记录，则插入，如果包含了，说明违反了唯一性索引，此时只要给长链再加上我们上文说的自定义字段「DUPLICATE」,重新 hash 再插入即可，看起来在违反唯一性索引的情况下是多执行了步骤，但我们要知道 MurmurHash 发生冲突的概率是非常低的，基本上不太可能发生，所以这种方案是可以接受的。
但是 一些语言或者框架 不是以异常出现的 而是直接报错 好像用不了这个
布隆过滤器法
当然如果在数据量很大的情况下，冲突的概率会增大，此时我们可以加布隆过滤器来进行优化。
用所有生成的短网址构建布隆过滤器，当一个新的长链生成短链后，先将此短链在布隆过滤器中进行查找，如果不存在，说明 db 里不存在此短网址，可以插入！
画外音：布隆过滤器是一种非常省内存的数据结构，长度为 10 亿的布隆过滤器，只需要 125 M 的内存空间。
设计思路总结
综上，如果用哈希函数来设计，总体的设计思路如下
我们可以维护一个 ID 自增生成器，比如 1，2，3 这样的整数递增 ID，当收到一个长链转短链的请求时，ID 生成器为其分配一个 ID，再将其转化为 62 进制，拼接到短链域名后面就得到了最终的短网址，那么这样的 ID 自增生成器该如何设计呢。如果在低峰期发号还好，高并发下，ID 自增生成器的的 ID 生成可能会系统瓶颈，所以它的设计就显得尤为重要。
四种方案介绍
主要有以下四种获取 id 的方法
-
Mysql 自增主键
这种方式使用简单，扩展方便，所以我们使用 Mysql 的自增主键来作为短链的 id。由于简单 后续内容以它为模板讲解 -
类 uuid
简单地说就是用 UUID uuid = UUID.randomUUID(); 这种方式生成的 UUID，UUID(Universally Unique Identifier)全局唯一标识符,是指在一台机器上生成的数字，它保证对在同一时空中的所有机器都是唯一的，但这种方式生成的 id 比较长，且无序，在插入 db 时可能会频繁导致页分裂，影响插入性能。
ps 雪花id加入了时间参数 是有序的
-
Snowflake雪花id
用 Snowflake 也是个不错的选择，不过 Snowflake 依赖于系统时钟的一致性。如果某台机器的系统时钟回拨，有可能造成 ID 冲突，或者 ID 乱序。 -
Redis
用 Redis 是个不错的选择，性能好，单机可支撑 10 w+ 请求，足以应付大部分的业务场景，但有人说如果一台机器扛不住呢，可以设置多台嘛，比如我布置 10 台机器，每台机器分别只生成尾号0，1，2，… 9 的 ID, 每次加 10即可，只要设置一个 ID 生成器代理随机分配给发号器生成 ID 就行了。
自增id的高并发方案（后续可考虑和redis结合）
那么问题来了，如果用 Mysql 自增 id 作为短链 ID，在高并发下，db 的写压力会很大，这种情况该怎么办呢。
考虑一下，一定要在用到的时候去生成 id 吗，是否可以提前生成这些自增 id ?
方案如下：
不同机器设置不同区间的发号器
当然了，数据量如果很大的话，后期就需要分区或分库分表了。
1）加入缓存
并且，短链接和长链接的对应关系一般不会频繁修改，所以数据库和缓存的一致性通过简单的旁路缓存模式来保证：
- 读（Read）数据时，若缓存未命中，则先读 DB，从 DB 中取出数据，放入缓存，同时返回响应；
- 写（Write）数据时，先更新 DB，再删除缓存。
当用户需要生成短链接时，先到这个映射表中看一下有没有对应的短链接地址。有就直接返回，并将这个 key-value 的过期时间增加一小时；没有就重新生成，并且将对应关系存入这个映射表中。
缓存的淘汰策略可以选用：
- LRU：Least Recently Used，最近最少使用算法，最近经常被读写的短链地址作为热点数据可以一直存在于缓存，淘汰那些很久没有访问过的短链 key；
- LFU：Least Frequently Userd，最近最不频繁使用算法，最近访问频率高的短链地址作为热点数据，淘汰那些访问频率较低的短链 key。
2）缓存穿透
但是，使用缓存也防止不了一些异常情况，比如“缓存穿透”。所谓缓存穿透，就是查询一个缓存和数据库中都不存在的短链接，如果并发量很大，就会导致所有在缓存中不存在的请求都打到 MySQL 服务器上，导致服务器处理不了这么多请求而阻塞，甚至崩溃。
所以，为了防止不法分子通过类似“缓存穿透”的方式来攻击服务器，我们可以采用两种方法来应对：
- 对不存在的短链地址加缓存，key 为短链接地址，value 值为空，过期时间可以设置得短一点；
- 采用布隆过滤器将已有的短链接多次哈希后存起来，当有短链接请求时，先通过布隆过滤器判断一下该地址是否存在数据库中；如果不在，则说明数据库中不存在该地址，就直接返回。
由于缓存和数据库持久化依赖于 Redis 和 MySQL，因此 MySQL 和 Redis 的高可用性必须要保证。
1）MySQL 高可用
MySQL 数据库采用主从复制，进行读写分离。Master 节点进行写操作，Slave 节点用作读操作，并且可以用 Keepalived 来实现高可用。
Keepalived 的原理是采用虚拟 IP，检测入口的多个节点，选用一台热备服务器作为主服务器，并分配给它一个虚拟 IP，外部请求都通过这个虚拟 IP 来访问数据库。
同时，Keepalived 会实时检测多个节点的可用状态，当发现一台服务器宕机或出现故障时，会从集群中将这台服务器踢除。如果这台服务器是主服务器，keepalived 会触发选举操作，从服务器集群中再选出一个服务器充当 master 并分配给它相同的虚拟 IP，以此完成故障转移。
并且，在 Keepalived 的支持下，这些操作都不需要人工参与，只需修复故障机器即可。
2）Redis 高可用
由于在大数据高并发的场景下，写请求全部落在 Redis 的 master 节点上，压力太大。如果一味地采用增加内存和 CPU 这种纵向扩容的方式，那么一台机器所面临的磁盘 IO，网络等压力逐渐增大，也会影响性能。
所以 Redis 采用集群模式，实现数据分片。并且，加入了哨兵机制来保证集群的高可用。它的基本原理是哨兵节点监控集群中所有的主从节点，当主节点宕机或者发生故障以后，哨兵节点会标记它为主观下线；当足够多的哨兵节点将 Redis 主节点标记为主观下线，就将其状态改为客观下线。
此时，哨兵节点们通过选举机制选出一个领头哨兵，对 Redis 主节点进行故障转移操作，以保障 Redis 集群的高可用，这整个流程都不需要人工干预。
3）系统容错
服务在上线之前，需要做好充分的业务量评估，以及性能测试。做好限流、熔断和服务降级的逻辑，比如：采用令牌桶算法实现限流，hystrix 框架来做熔断，并且将常用配置放到可以热更新的配置中心，方便对其实时更改。
当业务量过大时，将同步任务改为异步任务处理。通过这些服务治理方案，让系统更加稳定。