.net 的 SortSet 用红黑树实现的，相当于 Java 里的 TreeMap 、TreeSet 。
LinkedHashSet 相比 HashSet 每个 entry 多维护了两个指针，开销不大。

3L 的这位，不懂还爱装 X 。'我没有义务告诉你为什么'，很久没见过这么爱装 X 的人了。

“这严格意义上来讲是错的，所以对此抱有怀疑态度(dog)”
没什么好怀疑的，在这种场景下 hash 碰撞的概率几乎没有。如果还有疑虑，可以用两个不同的摘要算法。

kotlin 协程和 JEP425 这个还差挺远的

没听说这个 case 有解决方案了啊，有方案踢我一脚。
用 redis 时做好业务兜底，用 zk 时别要求效率。

漏桶就是一个定长队列，入队列时无限制可以猛入，下游慢慢消费。请求峰值时队列写满，后续请求被丢弃，表现为服务不可用。
令牌桶也有最大容量，可以理解为每秒增加 m 个直到达到桶的最大值 n 。和漏桶的区别主要是两点: 1.即使桶未满，qps 超过令牌入桶流速时部分丢弃，表现为服务限流，达到了类似滑动窗口的限流功能。2.桶的最大值起到一个蓄水池效果，和漏桶一个意思。

企业家不怕打脸。这句话不是贬义。

这个设计没法用，换方案吧。

1L 说的不准确，redis 的定期删除和惰性删除能保证在第二次 get 时确定是否删除。但 redis 过期是在 redis 服务写入成功后开始算的，不包含你的服务远程发送到 redis + redis 接收执行 的时延。

定时任务的时间间隔没那么准，和 redis 没啥关系。你这个方案问题也蛮多的，redis 执行延迟、定时任务阻塞都会导致不可靠。

赞！

不要被自己的技术栈局限了视野。

@atytaop7

哈哈哈哈你说的有几分道理，但 OP 说的也没啥错，人身攻击实属无必要。
技术是为业务服务的，更贴近业务核心才能有更好的技术视野。
你列举的东西其实是属于前端“体验优化”部分，但体验优化再好也算不上一个产品的核心竞争力，顶多是个锦上添花。

OP 的想法是想让自己更贴近业务核心，你的想法是深挖前端细节。都没有错，但前者价值更高。

这不就是连接池的适用场景么

两个都用过，都很优秀。
用 React 会强迫使用者有工程化组件化的思维，写大项目会更舒服一些。
Vue 上手更简单，想怎么写都行，也很舒服。
但不是一种舒服，Vue 是一种随心所欲的舒服，React 是鳞次栉比的舒服。

为了查找方便，就算是 kafka 这种 MQ 的 offset 也有索引，不然 seed 一个 offset 得从头遍历到尾，多傻啊。

@qW7bo2FbzbC0 你说的不就是 scala 、kotlin 、grovvy 之流么？可以在 JVM 上跑，可以用 JDK ，还可以和 Java 混合编译。

这么多点击没人回答，估计是懒得回答吧，有点基础···
搜索下什么是“回表”。有 idx （`data_type`, `is_deleted` ）时，where is_deleted = 0 AND data_type != 1 的 count(*)不需要回表，只通过索引就能完成统计。
区分度低的索引查询慢说的是有回表的情况。

double 类型的 IEEE 754 标准，十进制可以精确表示的数在二进制下可能无法在有限位数内精确表示。
你在 chrome 控制台打印下 0.1 + 0.2 就知道了。