从完备性角度讲 object 的 key 顺序也是信息
当然一般业务开发中应当避免依赖顺序，如果需要在页面展示 table column ，也建议在对象内放一个排序或权重值。

才 1000 次，说白了就是 1000 次 mul + add + mod ，暴力算也不过几微秒的事，这还要什么优化？
就算是一百万次也不值得优化

现役 1000XM3 用户
还用过 900N / AirPods Pro / 1000XM2 等，不差钱建议直接 AirPods Max ，差钱建议 1000XM5

你们有 Scala 业务？

上班要求穿西装么？

毕业后才开始学英语的表示，你想学什么时候都不晚。亲身经历：

2012 年大专毕业时词汇量大约 400 个吧，我上学那会儿就喜欢背一句诗“堂堂正正中国人，为何要学英国文”
还傻乎乎的认为未来机器翻译会发展到能替代人类翻译的程度，直到从事了机器学习相关行业后我才知道，这一目标有生之年都不可能实现。

毕业后我硬是靠着机器翻译啃英文文档度过了开始的 4 年，积攒了大约 1500 词汇，其中绝大部分是编程语言关键词和技术术语。

2016 年决定要把英语补回来，买了套初中英语教材，从初一开始看，看到初中毕业熟悉语法。后来自己在百词斩+扇贝坚持背单词，2020 年左右我词汇量已经接近 1 万了。

2021 年开始发现虽然我词汇量很多，但是不经常用遗忘的也很快，不懂语法依然啃不动 medium 技术文章。然后我开始看 Youtube 视频，开着字幕连快速阅读，慢慢的关闭字幕练听感。

我知道我英语水平和 V 站平均水平没法比，但至少看英文原版技术书籍和听技术演讲已经问题不大了。我的补救路线楼主可以参考一下

一般对于缓存问题，我都会先问一句，缓存服务是必须引入的组件吗？
你的业务量在可预见的未来，会增长到单机数据库难以支撑的程度吗？

然后问第二句，你是否真的理解 CAP 。不要试图去挑战 CAP ，这里面水太深，你把握不住。

据我观察除了头部公司几个流量业务外，99% 项目的并发量直到项目死掉都没有超出单机数据库的承载范围，引入 Redis 对你们是否真的有必要？

如果真的有必要，请熟读 1 楼帖子

没用过 async-db ，r2dbc 等方案，只用过 hikaricp 链接池 + 异步的响应式。我说下我的经验：

事务：因为背后还是 jdbc ，所以事务必定发生在同一个 jdbc connection 当中，业务编码的时候会把整个异步代码块打上一个 transaction 标记作为边界，表示在边界内的 sql 都处于同一个事务中。

一致性：和传统并无二致

性能提升：业务代码部分只需要一个 n = cores 的线程池作为纤程的运行时就够了，所以几乎没有上下文切换。jdbc 部分都交给 hikaricp 管理，iowait 的线程对操作系统没什么消耗，可能会在跨线程（核心）数据交换上会浪费一点资源，但和传统阻塞式比可以忽略不计了。所以首先要满足的条件是你自己的应用也需要遵守响应式开发，不然的话可以说没有性能提升。

别动态线程池了，还不如把 CompletableFuture 用对用好，动态线程池纯粹是先把代码写屎，再在屎上雕花的不必要方案。
JVM 往保守了说有 fiber ，CompletableFuture 可以用，往激进了说还有 kotlin suspend ，展望未来还可以上 loom ，不管哪条路都没有动态线程池的活路。

substr 解君忧

函数式风格的基本上 console.log 就够用了，读一遍以后脑子里就形成执行模式，然后在几个点位插入 console.log
命令式风格的得反复 debug ，盯着变量看，一不小心就被改飞了

在这个基础上再实现一个 fallback 机制，极端情况下，前一个 instance 凑巧被杀死了，后一个缓存里读不到 Promise 的时候还是需要走全流程

建议负载均衡层面根据 token 做 sticky session ，这样就能保证客户端短时间请求始终转发到同一个 instance 中去了。
内存里用 Map 简单缓存一下这个 Promise ，记得把时间也记录下来，定期清理掉过期的 Promise 防止泄漏

懂了，结论：别用垃圾 mysql 。
起码 postgresql 的 enum 只要不改顺序，新增类型都是瞬间完成的。

mysql / postgresql 都原生支持 enum type ，可以结贴了吧

1. 选一个 reactive stream 库（比如 akka-stream ）
2. 数据源（例如 jdbc ）包装为 stream source （一般 reactive stream 已经有包装好的）
3. 在 mapAsync(parallelism = <根据你的网络与综合性能设定的并行度>) 中实现你的 http download （推荐 akka-http ） 逻辑
4. 把它润起来

优点是不需要管理线程池，全程异步，如果网速不快的话，那 CPU 会很低。如果网速足够快，CPU 也不会浪费在无意义的上下文切换

分布式系统的严格一致性是很难保证的，因为你不可能全局开锁，把更新操作都串行化。
唯一低成本的实现方式是超短 TTL ，比如如果业务允许的前提下，TTL 设置到 10 秒，甚至 5 秒或更短。这样依然可以大幅度减少频繁的重复请求。

write-ahead log ，按事务给你分割好了都变更了什么

@andyJado llvm 能把非尾递归优化成尾递归也吓到我了。
当然实际应用中更建议手动写成尾递归形式，以保证 llvm 在任何优化下都可以生成迭代指令
毕竟过于复杂的非尾递归循环，谁也不敢保证编译器是否认得出来