@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 度这种，不是过家家的七八十度）

上面说得没错，非蠢即坏

@ghostheaven 楼主这些内容和数据结构与算法，有什么联系吗

bytedance-hire.me
路过看看～～

拆分开的后果就是要分别更新，分别读取
放在一起的后果就是 Update 的时候会对这张表频繁操作，静态数据本来不需要经常变但是行数据还是经常有锁在上面阻塞

TL;DR:
看业务和数据量，未来 1 年内如果还是小业务、数据量少（没到上百万千万上亿）实际上就放一起最方便；
预估到未来 1 年内数据量增长比较大的话提前垂直拆分开，动静数据分离比较合适

夯实基础，多陪家人