@house600 举个例子，比如在编写大批量数据导出接口的时候
数据一次性加载到内存中再写入磁盘或者 HTTP Response 都是不合适的，因为数据量可能超过内存总量，这时候就必然要使用流式处理。

1. 这个场景中上游的 Source 是 JDBC connection ，设定 fetchSize 以后每次只会加载这个 batch 到内存中，也就是 Source(connection.selectWithFetchSize(用户列表))
2. 根据业务决定是否需要 filter 或 transform ，是否还需要经过其他第三方微服务接口处理，也就是 Flow.filter(过滤隐藏用户).map(隐藏真实姓名).mapAsync(从其他服务获取用户额外信息)
3. 打包写入磁盘或通过 HTTP Response 发送，甚至还可以插入一些编解码与压缩算法，也就是 Sink.map(toJson).transducer(gzip).toFile(文件名)

整个过程编写下来是声明式编程，而不是传统命令式，同时也具备 Reactive 的基本优点，比如异步+背压，不会导致 OOM 。

@house600 随时随地都可以使用，任何可以流式处理的场景都可以用 reactive 来处理。
建议先把 map 、filter 、reduce 用熟练，然后根据你用的语言生态选 RxJS 、akka-stream 、kotlin flow api 、tokio stream 中的任意主流方案。
我在 kotlin compose 桌面项目中就在用 flow api
在 rust 写 cli 的时候就用 tokio stream
在写前端或者浏览器插件的时候就用 rxjs
但我主业是写 Scala 的，所以我对 Scala 生态的 Akka-stream 、fs2 、zio-stream 都比较熟悉，可以随意切换。

基本上你用熟了任何一个 stream 库以后，迁移到其他语言、生态都不会花太大功夫，因为基本语义上大家都是一样的。

找公有云买 Serverless k8s 集群，练的时候创建，练完了直接销毁。
一般管理是按小时收费的，计算资源是按量付费的。
只要你不是搞的规模很大，每小时几块钱，可能跟去网咖打游戏差不多成本。

@ximigou007 谢谢捧场。
全球范围内有不少，国内确实很少，Hulu 、TubiTV 有在国内招人，摩根也有不少 Scala 代码，北京也有位清华教授在用纯函数式做一些大数据医疗方面的项目。但总体看下来国内 fp 生存环境挺差的。

@wdwwtzy
朋友推荐面过腾讯，薪资没谈拢，加面后定级薪资还是比现在低就没去。
另一个朋友推过字节，一轮游，lc medium 写不出来 + 默写字典树有瑕疵最后挂了。
自己面过几家初创外企全栈，这个倒是薪资有涨。

总之，圈子过于小众也不好，大佬们都在国外，要么我润出去，要么留在国内接受现状。

@wdwwtzy 不存在的，该八股文+lc 伺候一项也不会落下

@chaleaochexist
@ebony0319
谢谢捧场

@fyooo 目前也是主攻口语，在积极看外企机会，之前也拿过另一家外企 offer ，全程英文面试的，和老外尬聊俩小时

@NathanInMac 过奖了，最近几年的这份工作离着年薪百万，达成率只有 50%多一点。

@unregister 我是几乎不加班的，其他同事按需加班，做业务的同事可能加班挺多的。

@Hilong 十分不想带团队，就想写一辈子代码，然后不挑语言平台。
我对自己的定位就是软件工程师，而不是特定语言的码农。

@roundgis 有用过一段时间，后来没再采用，因为要给每个用到的库编写 reflection 和 proxy 表，太费精力了，也不可持续。
后来还撞到了 native image 编译器的 bug ，回退到 20.x 可以编译，升级到 21.x 编译就会异常终止。

@roundgis
GraalVM 有 G1GC 的
你说的应该是 native-image 当前只能用 serial gc 吧

@Vaspike kotlin 版随手写的，其实不安全，没有错误处理。按照生产级代码规范，应该多加 5 行的 data class 定义，做严格 ser/deser 。
同样的逻辑用 Scala 写会安全很多，Option/Either 签名的方法都是默认实现了，flatMap/getOrElse 过去就好。

上大学时候我也曾迷信设计模式，还专门买了几本书学这个。结果每本书都没看过一半
现在工作十年了，对设计模式的需求几乎降到 0 了，反正没什么是现代函数式语言做不到的，硬套设计模式反而让代码变得难以维护。

😏
https://i.imgur.com/60DWcf3.png

建议理论部分可以参考《 SICP 》，实战部分多写点 RxJS 之类的。
以及不要讲 Monad ，就像现在这样

再就是拿实际业务举例，怎么用 map/filter/reduce 等替换掉 loop 部分，我觉得就足够了。
https://www.zhihu.com/question/570165038/answer/2784350974

Promise 模式
任务开始时创建 Promise 和标识句柄，收到来自下游的任务结束，根据句柄找到 Promise 并标记为 Resolve/Completed
这样业务里看到 Promise 状态变更时，自动进入 then 逻辑继续后面的处理

我觉得业务层还是需要按照业务层的思路去解决，这和基础设施取舍不同。
比如按照做基础设施的思路来搞，那应该每一步都不可以出错，如果出错了就应该停在当前位置无限重试下去，以保证数据最终一致性。
但按照业务思路来做，因为一条数据出错而导致整个系统数据同步停机是不可接受的。

所以必然是以业务行（ row ）为单位，多次重试后记录错误并跳过，ES 也仅供搜索，业务事务依然由 RDBMS 保证，如此则需要引入就死信队列（ DLQ ）与纠错机制。

DLQ 能弥补一部分错误，但无法处理某些内部错误被当作正确处理跳过的场景。例如上游有 BUG ，请求账户积分失败时返回了 0 ，虽然锅是上游的，但修数据依然是下游要处理的。

所以还是需要有一种纠错机制来保证数据的最终一致性。我最近在考虑哈希树（ merkle tree ）不错，它是区块链用于校准的数据结构，可以快速对比不一致的数据块。
https://i.imgur.com/b4ccaPd.png

比如我们可以定时在闲暇对数据库做全量或部份 merkel tree 计算并对比两侧结果，最近数据多算，历史数据少算。这样对比出的不一致结果再通知给开发，找一下是哪里出的问题，以及手工对数据做补偿等等。