短网址系统设计

HK_意境:
我做了一个开源的短链接生产系统，里面有我实现的多种核心生产算法，五种生产算法，测试通过百万数据最差碰撞率0.02，已经开发对外的web API，欢迎来参考，核心生产包已经发布在 Github了，来呀来搜索 Short-URL 我写了详细的说明文档，目前官网正在制作中，maven仓库审核通过

【回复】[点赞][点赞][点赞][点赞][点赞]
硬核课堂:
全部内容集合: https://hardcore.feishu.cn/wiki/wikcn9i4sfdTkxVX0DYrMMbNBpd

长恨安歌:
长域名重复的判断是否有必要？甲设置长域名，过期时间1秒，乙设置相同长域名，过期时间1年。如果使用相同短域名会矛盾吧。

行者阿金:
短网址核心，不是短id生成算法么？ id不是定长，从1~n位。 第二是淘汰算法。

【回复】作者重点讲 性能 可用性 之类的东西了 大厂人士
hx-2948:
直接学哔站的id算法 币v1UB4y1s7iZ，hash解决起来麻烦

【回复】bv号是av号套壳得到的，算是自增主键的实现方法
【回复】也是一个二进制的编码哈，和视频中将的其实一样。
reserveword:
如果极端一点，完全抛弃数据库，把短网址的命名空间看成一个环形队列，数据写入只可能发生在队头、数据删除只可能发生在队尾（除了自定义短网址的情况，这些情况用hash或者索引判断和排除），这样设计有什么问题吗？

【回复】回复 @硬核课堂 :那就往上叠缓存和索引呗，比如我预估有200G条数据，每62条数据有一个索引，每个索引（用偏移量表示）是64bit=8字节，结果就是大约32G的内存；这个机器可以完全不负责缓存，缓存交给专门的机器处理
【回复】如果有人重复用同一个长网址生成短网址，我们可以在较短时间内返回同一个网址，而相隔较长时间后再申请就返回一个新的条目。维护一个比如一天或一周内长网址的列表，判断的时候比对一下就行
超级达哥:
我感觉是lark core的员工，我怀疑就是lark im的同事，估计在唯实

【回复】回复 @硬核课堂 : 因为我之前在lark的隔壁部门，看你也用seal和飞书，还做im，我就猜了下
bili57272128:
啥时候换头像了 感觉原来的更朴素些[doge]

深蓝加菲猫:
一般这种系统, 在跨地域情况下, 写延迟没有那么高要求

Python爬虫教学直播:
新建了一个Python交流群，想学Python的朋友私聊我拉你呀[打call][打call]

小路路01号:
自定义ID可以在ID空间里每隔一段距离保留一些给用户，或者像CIDR那样按前缀保留，这样自动生成ID的时候就不需要多查一次表看是否被用户占用，直接按约定的规则跳过一整块保留给用户的范围。不过这样对性能有多少优化就不知道了，可能在高并发创建ID的时候会有些区别吧[辣眼睛]

reserveword:
如果一个域名在过期之后十几年都没有一次访问，那么这个数据不就永远不会被删除了吗？这样的情况应该比较常见吧？

熊猫拍板砖:
如果有瞬时生成大量短链接呢？我看你这个就没有做这个处理，就是某一时间有人生成几十万或者几百万条短链接怎么办？

【回复】回复 @熊猫拍板砖 :嗯嗯你说的是的，这块 首先 风控问题，一个正常人怎么能允许瞬间生成上万的短链呢？ 所以我觉得首先从需求来看，就不合理，可以直接限流按用户维度(账户ID，设备ID)，其次是后端生成短链这块跟分布式ID生成差不多，这块后单独讲，大量生成短链过来，预分配，分组等等思想都可以解决。
【回复】带了一嘴，这种就要做过载保护，这块可以看 分布式限流系统设计 https://www.bilibili.com/video/BV19a411v7Mh/?vd_source=442f1caea55e6e096da17e8366c2c513
【回复】回复 @硬核课堂 :我说的瞬时生成大量的短链接，单用户批量生成，压力不是在你接口，而是在你生成短链接这里
pig-lu-lu-lu:
请问为什么短域名不能靠随机生成呢？

【回复】会冲突，量足够大了，会冲突明显