先明确下查询是 AP 还是 TP. 如果根据经过 filter 后, join 的数据量比较少是 TP 否则为 AP. AP 的话用 Doris 之类的 MPP 数据库吧

如果是 TP, 明确下为啥查询慢, join 顺序不对还是没加索引, 如果是前者的话, 通过 join hint 指定下 join 顺序

写业务感觉还是 java, ts 最方便. go 擅长写重网络 IO 的应用, 用同步的方式写异步比较舒服

MySQL 中的表发生 DDL 你是咋处理的 ? MySQL8 之前的 binlog 里头没列名, binlog 中元素对应的表结构可能跟当前 MySQL 那边的表结构不一样

打个火焰图看看 ?

@w568w 1 这点没得洗. 但 2 这点, 带 gc 的语言一般都没有用 raii 这套的 (对象销毁时机不确定), try 这一套不太好表达把 ownership move 到其他函数这一点. defer 这玩意只能说有优点也有缺点

@hez2010 另外 java9 中已经废弃 finalize 了

@hez2010 这玩意真没法兜底. 可能会出现没触发 gc 资源就因为没有及时释放就耗尽的情况
cpp/rust 里头的 RAII 能保证这个 obj 离开作用域就销毁

@kxct 似乎只有不带 gc 的语言才有析构函数, 带 gc 的语言里头, gc 的时机不确定, 导致析构函数调用时机不确定. 没 gc 的话, 又一堆操心事

能先说出在你们这种场景下, 为啥两套集群不合适比一套集群更合理吗 ?
实际上, 也有人主张用多个小规模 K8s 集群的联邦代替一个大 K8s. 比如: https://www.infoq.cn/article/lgzz3duliciczvoibpxh

ps: 想起了罗素的一句话: 未受哲学熏陶的人，一生都被禁锢在种种偏见中，这些偏见来自常识，来自他那个时代或民族的习惯性信念，来自未经审慎理性的合作或同意而在其心灵中形成的信念。对这样的人来说，世界往往变得明确、有限、显而易见；寻常的事物不会引出问题，**陌生的可能性会被轻蔑地拒绝**。

动手实现一遍, 之后压测试试呗

感觉可以并行来跑, 充分利用 CPU 多核. 启动多个线程, 每个线程同时做 topK, 最后 merge 成一个

直接用 adblock/uBlock 之类的东西屏蔽了呗

瞎翻了下, 感觉没提到啥设计哲学. 比如可以说说以下问题. 如何实现是一个有意思的问题, 但在语言设计上选择要实现 X 这种特性而非 Y 特性也是个有意思的问题.
+ 为什么 go 没有 Java 中的异常机制, 出现异常的时候选择返回 err 而非抛出异常 ? 这是不是一个好的设计 ? 异常有啥问题
+ 为啥 go 没有一般意义上的继承 ? 如果没有继承, 如何实现多态 ? embedded struct 算不算继承 ? 一般意义上的继承又有啥问题 ?
+ channel 跟 Java 中 BlockingQueue 又有啥区别 ? 通过共享内存实现的并发跟通过 channel 实现的并发在哪种场景下更好 ?
+ 为啥 channel 会有 close 这个操作, 在哪些场景下会用到这个操作 ?

另外讲闭包的时候, 可以提下如何让函数实现一个接口.

你为啥实际试试呢 ?

@gdfsjunjun 有时会要求双击电源键确认, 起码 appstore 是这么处理的

如果向 master 内写了 x=1, 写成功之后 master 挂了(其它节点, 拿不到最新的 binlog). 这时候从其它节点读 x, 能读到 1 还是之前的值 ?

raft 能提供这种线性一致性的保证

@AoEiuV020JP 我仅仅说你提供的这个封装不适合处理这种情况, 没说 golang 没提供这种处理. io.Reader 就是一个流

@AoEiuV020JP
> 高级一点的现代语言都有封装一些方便的方法，比如直接把 body 完整读取转成字符串并 close
我的意思是, 这种封装挪到第三方库就行了, 没必要放到标准库, 这东西的使用场景很有限. 流式读取的应用场景更广泛, []byte, string 都可以看作是流


ps: **请你好好说话**

我觉得很合理. `resp.Body` 就是个 reader 跟 fileReader 类似, 区别就是这是别人帮你 open 然后把 ownership move 给你, 负责 close 是用户的事, 你觉得 fileReader 必须 close 是不是合理的 ?
虽然对于大部分调用 rest api 的情况, 是把 reader 内的读出来, 之后 close. 但是对于需要流式获取的场景并不合适(比如: 实时视频流, 大文件), 按我的理解, 进入标准库的东西, 得适配普遍的场景, 而非 rest api 这种单一场景