另外特别感谢 @PanJiaChen 大佬的内推，整个等待过程都不断被我骚扰进度 Orz 继续努力～再接再厉～

帮忙顶一下帖子，楼主 wx 解答问题很耐心～

@yoyos base62 方案号段会影响输出的长度，如果你要做成一次性分配完的话不方便在固定长度短链（也就是业务要求的 7 位）下水平扩容，而且复杂度并没有降低，还是要实现扩容发号那一套东西。。。

@mrlmh00 嗯看到确实是这样，但是这个问题还是非常好解决，只需要想办法将 base62 生成的信息按照特定规则编码出来增加破解难度就可以了？至于其他的生成方案，主楼已经讲过为什么不打算使用了。

当然如果有所谓的''完美''方案，也欢迎提出来交流学习～

@daquandiao2 hhhh 是的特地注册的～ me 后缀还不让备案

@mengzhuo 随机数和 mac 地址做异或，如何保证唯一性能解释下吗，个人认为这种生成器里面出现随机数的话思路就已经错掉了。。。不同 mac 地址+随机数可以保证不发生冲突吗？

@levelworm 虽然听起来可行，首先你的中心节点 /或者说生成器需要做成单实例的，因为不能多个实例同时生成，否则就会有冲突，其次中心节点分发生成后的 ID，也就是一段字符串，会有额外的流量开销（比如分发 1000w 个长度为 7 的字符串），不管大还是小，肯定是不如按号段分发计数器（只需要传输[0, 10000000]这样的范围数据），单点的服务再生成 ID 的

@sdjl show full processlist 只能查看当前用户的 process，并不是全部 mysql 连接

@jason0916 这个不是业务需求，是系统设计的一些学习和思考笔记吧（自嗨行为 hhh ），不过问题多一点的话可以多了解一些知识也是很好的。

在我看来因为查询的时候如果按照 unique_id 查询，如果改用 mysql 存储的话，因为数据总量会比较大可能我会考虑按时间分表，这时候 Unique_id 的设计可能会从纯 base62 改为时间前缀标识+base62 来做，切分单表或者库的数据量，也是一种方案。

整个系统都是假设的，需求也是假设的，不过讨论可以学习到东西，thx

@jason0916 zk 分段是 1 的形式，app 崩溃确实会导致分段浪费，可以看 app 内是否能解决这个问题，例如现在 app 持有某个分段，服务重启后看是否能继续使用；另外也可以优化分段区间，减少浪费的区间长度，具体两个都是业务方案的实现

使用 redis 集群来存储长短链映射关系主要是考虑性能和 Cluster 易于横向扩展，Cluster 的模型主节点如果失效，会切换至从节点（当然抖动是不可避免的），可以一定程度降低风险，但是确实会有丢失写入，以及持久化 buffer 未写进磁盘的问题，这个再想一想好了，没有覆盖到这个问题

如果直接用例如 MySql 这类，性能上可能会需要更大的成本来满足？不同方案各有优劣，可以看业务来定，谢谢建议，很有帮助

@jason0916 我的理解是因为设想里面 ZK 是负责号码段的分发，按照预定的请求（如 1000/秒）只要业务上将号码段划分得合理，App （也就是生成短链的服务）实际上并不需要特别频繁地向 ZK 索取新号段，得到的号段是由 App 自行管理的（比如丢在 Redis 持续自增到>上限再进行获取）。

假如我划分的号段，每段长度是 10w，按照请求速度预计可以支撑后续的 100 秒内的 ID 生成，如果我的 App 服务一共部署了 20 个，也就是 100 秒内大约只会有 20 次 App 向 ZK 索取号段的请求，这样是否可以忽略 ZK 的问题？

ZK 这块新学，还有很多不懂望多指教

@pytth 你不能拿到完整路径，如果你要上传，浏览器会发起请求将文件本身（ binary ） POST 给服务端，但是浏览器不会给你这个路径，不管你怎么修改代码你都拿不到路径

@willhunger 不了解他说的那个 up 主，不过我前几天看到 youtube 上有个 up 主（其实是个网站）有发布过一些 mock interview 的实录，觉得非常有收获 interviewing.io
也可以在 youtube 上直接搜 mock interview 看一下

xpath 直接从源码中右键，copy xpath 获取比手写靠谱一点？

https://pypi.org/project/html2markdown/
随手搜的 不知道是否能够满足你的需求，个人感觉把你的问题转成英文在 Google 上搜索会比较快

dp[i] = dp[i-1] + dp[i-5+1] - dp[i-10+1]

TCPB 向 TCPA 发送 Last ACK，抵达需要 1 个 MSL，抵达后 TCPA 从 FIN_WAIT_2 变成 TIME_WAIT 状态，并且返回 ACK 对 TCPB 进行响应，如果一切正常，那么再过 1 个 MSL 之后就会抵达 B

假如 TCP A 的这个 ACK 没有抵达 B，那么对于 B 来说，B 发送了一个 Last ACK 出去，处于 CLOSE_WAIT 状态，等待 A 的 ACK 回来，如果 B 在发了 ACK 后过了 2 个 MSL 后没有收到 A 的 ACK，那么就会重新发这个 FIN 报文

A 等待两个 ACK 的目的是在于防止 ACK 在传输过程中丢失，那么对于 B 来说会在 A 等待 1 个 MSL （这时 B 已经等待了两个 MSL ）后重发报文，这个报文过 1MSL 之后内会抵达 A，所以 A 可以在 2 个 MSL 内确认到 B 是否没有接到自己的 ACK

@cst4you 老哥多少钱出啊～

@kokutou 是的 3950x 在发热上甚至还比 3900x 略好，看来你确实没有了解过 Ryzen，既然是小白那就算了吧= =不争了