九月发年终奖，这本身就不是很靠谱啊

@ChristopherY 你好，好久没登录，我们用了 arishem

@Ico945 开始动手了 ，感觉你说的对

@wxf666 你问的这个问题说明了多问题，文件系统、数据库、计算引擎等，我水平有限，没办法给你讲清楚

@Xrall 用 ck 、doris ，数仓随便找一个也比 es 对口啊

@wxf666 还是你牛逼，楼主快把数据存固态硬盘里。。。。。。。

@Xrall between 大范围捞数据，引擎判断大量的回表很慢就自己优化不走索引了

mysql 单表 200W ？不考虑换种数据库么？业务 db 和 olap 的要分开才好。
非要用 mysql ，时间都是 yyyy-MM-dd HH:mm:ss 吗 /抽出来 yyyy-MM-dd 、yyyy-MM 的加上索引？然后不要用 between 了，我记得 between 大范围捞不走索引了。

分布式环境？ request_1 打到 pod_1,request_2 打到 pod_2 ，这种合并起来？
你这合并的规则不清晰。。。
1 、前端限制达到相同的请求只发一次达到“合并”效果
2 、不同的 c 端发来的请求，假设你的规则是参数一样就合并？那直接套一层缓存是不是能达到类似的效果呢？
3 、缓存不行，就要合并，那就在网关搞事情喽、统一、快捷。
4 、singleflight 防止击穿？加上呗、几行代码

imei 设备 id 呗

@kaiccc 这个只适用于 java 生态？

@singer 听上去不错

@aqweq 现在太卷了，最后都是几轮面试筛选出几个人给大佬挑。到这一层技术都没啥大问题，就看项目背景了。

@Johnathan 野猪书是不错的，但是有点偏大数据了

高并发简单，找个秒杀题背一下。预热、前端拦截、分布式缓存、静态资源的处理、项目解耦、代码性能、中间件雪峰、异步、再扯点分布式事务，要是有经验能扯点异地多活、跨机房同步啥的也行。
但是，针对我多年的面试经验，你这样只是基本合格，我也不一定让你过。还是看你项目不

就像你思考的这个问题，咱们的国情下没人会从这个角度思考的，自然规律让步领导意志。什么软件危机、什么技术债，干不出来就是菜。

解决？以现在的状况过来看是加剧了。每换一个 leader ，方向变一次，技术栈换一套，系统重做一遍。问问现在的中台天天都在干啥？都是从重构到重做。拉屎谁都会，吃屎可就难了，吃屎还能在屎中汲取营养的就是高手高高手了。

@wqhui 深度用了一阵子，折腾了了几个 flowise 、coze ，我觉得最大的问题就是他的很多回答你如果不是很懂这个话，就不知道对错，直接拿来用就傻眼了。但是辅助优化，给一点建议还是不错的。