@chengz 可以做到但没必要，不如说说是什么业务场景，MySQL 搞个好点得配置上个 SSD 代码合理差距不会超过 1ms，真的非得用这么复杂得方案吗

1. 自己解析 SQL 映射到 KV 数据，给查询条件建立映射作为索引，不能命中索引的用 SCAN 查找

@levineet 起码别错位呀……你乎 iPad 版真过分

项目整体的线程模型需要规划，一个部署实例里面的一个小模块不应该瞎起线程、这种往往反而不利于整体性能

正常算，带薪假日

现在还没曝光应该没了，明年直接上了 Apple Silicon 了吧

所以你明明需要的是 ES，为什么非要去用 MySQL 来实现呢

阿里系的产品普遍设计的反直觉，不好用

新加的“notion”连代码高亮都只有几种，还集中在前端，看当初 markdown 很怀疑后续能不能更新

@acainiao 主机亏钱卖的说法不成立，Switch 、PS4 、Xbox one 都没有亏钱卖。维护成本指啥，Switch 的软硬件研发成本得比 iPhone 差几个数量级吧。

@stoneabc 当然需要，没记错的话 30% 的抽成就是任天堂发明的，AppStore 只是模仿者

堡垒之夜同样要要像微软、索尼、任天堂交 30% 的抽成，但是 Epic 却只起诉了 Google 和 Apple，是这俩软柿子比较好捏吗。

因为早年阿里不知真假的选择和阿里的成功导致 MyBatis 获得了大量的早期用户，Hibernate 过高的学习成本错过了推广时机，然后用户到达一定规模就成为惯性了，很多人在做选型的根本不会考虑其他，这就进一步压缩了其他 ORM 的发展空间。

Mybatis 是真难用，导致大家又开发了一堆插件让他往蹩脚版 Hibernate 方向发展。

FastJson 都养活多少安全团队了，EasyExcel 由于长期不更新同样存在安全漏洞。
推广灌水公众号也不要坑别人啊。

默认最极端情况
定时清理任务 60s
3 个心跳周期 90s
消费端缓存 90s

这玩意儿应该在消费端做容错处理，不应该完全依赖注册中心来发现

RPC 是一种泛指，Http 只是一种协议，可以通过 http 协议来实现、比如 gRPC 。
REST 只是 Http 的一种设计风格，跟 RPC 没有必然的联系。
前后端分离跟 REST 和 RPC 更没有关系。
另外，虽然拥趸很多，但是 RESTful 风格的接口在国内几乎没有见过。

寒舟被喷的停止开发了吧

这次夏促太不给力了，还是等 epic 安排吧