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

你们有 Scala 业务？

上班要求穿西装么？

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

然后问第二句，你是否真的理解 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 在任何优化下都可以生成迭代指令
毕竟过于复杂的非尾递归循环，谁也不敢保证编译器是否认得出来

https://i.imgur.com/cEKgX24.png
从汇编结果看，对于你这个函数，O2 级别的优化足以替换成尾递归（迭代）实现了。
你可以手动改成尾递归，让它在任何优化下都能正常工作，或者甩手交给编译器去做

我选方案 5 ，把国家列表缓存到内存中，性能起码吊打 Redis 100 条街