@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，既然是小白那就算了吧= =不争了

@kokutou 真是个 ETC...死活不认 算了= =可能你觉得 3950x 和 3900x 差太远吧 你觉得你看法没错就行= =或者你还是自己找找资料和测评吧

https://www.youtube.com/watch?v=J69aiJJEHzQ&t=670s

https://wx2.sinaimg.cn/mw1024/006I4VFqgy1gavtxs3gauj30vy0i144i.jpg

而且我建议你们多了解一下...不是盲目在这里给楼主省
@kokutou
@hjc4869

@kokutou 按你的说法建议 AMD 不要出 5 系主板了，x370 和 b350 不买，花冤枉钱买 4 系？

@kokutou 如果你说的超频不包含 PBO，那其实不行的，供电如果开了 PBO 会非常热（个人实测，已经换掉了）
如果你说的是 PBO 关掉直接按默认频率运行那确实是可以的，但是这样已经没有任何升级空间了

按照用 5 年算，如果楼主现在买个好一点的旗舰 x470 或者正常水准的 x570，可以过 4 年升级 16c32t 的 3950x，非常理想的路线....不要为了主板几百块锁死自己的扩展升级

@hjc4869 建议去 CHH 看看各主板供电规格的分析，还 3950x，如果住北极可能可以吧，供电模块会非常热的（ 120 度这种，不是过家家的七八十度）

上面说得没错，非蠢即坏