数据进缓存无论你什么数据类型都不会有什么性能问题。按 key 读取数据也没什么问题。问题是按条件查询，这个不是 redis 的菜。

缺点什么的根本不重要，Java 缺点多了去了，每每被人吐槽、鄙视、嘲讽……但这又怎样，还不是用的飞起。

Rust 全面好评，但就是用的人少。

当小组长就两件事，做好就行。
1 、打样，自己先做个标准化的样板出来，让手下依葫芦画瓢。
2 、分配任务，公平公正，合情合理就行，不要顾忌太多。

这么便宜？你这是哪家的证书？

能者多劳，但多劳未必多得

很简单，在接口内部第一行和返回前打印一下 start/end 日志，如果是 start，start，end，end，就是内部问题。start，end，start，end，这就是外部阻塞了。

@airqj 应该会有这种需求的，不然打标签做咩？就是看看有个毛意思。

一个人要不要努力是完全主观的事。所以评判一个人有没有努力也是完全主观的，因为完全没有客观标准嘛，你凭啥客观评判？

那么怎么让人觉得你努力呢？多干活少娱乐，或者说少浪费时间在不重要的事情上，这样你就看上去就很努力了。

@airqj 你这样没法根据标签拉用户列表

一般就是一张用户标签表，里面 3 个字段：id ｜ user_id ｜ tag

充分抽象，直到所有特性都被共性代替。

分级汇总。简单的说就是今年之前的数据是不变的，可以按需求汇总之后存起来。然后今年 1 、2 月份的数据也是不变了，也可以按月 /日汇总后存起来。剩下的也就是查当月数据罢了。或者干脆连当月的数据也按天汇总存起来，竟只需查询当日数据就够了。

不同账号之间内网是隔离的，所以并不会发生来自内网的攻击。倒是有可能有来自同一个云服务商的用户的攻击，当然是通过公网攻击。

自从 get 了终极秘技 cv 大法，Java 语言啰嗦繁琐的弱点也就不存在了，反倒是隐隐成了优势。所以 kotlin 什么的也就没有吸引力了

经典的 id/parentId 已经可以满足需求，子节点需要递归查询。因为层级最多也就 10 来层，递归查询效率还是没问题的。

还有个办法就是设置一个层级编码，但这个需要对每一层的子节点数量有预期，譬如 010203 这样的编码，每层子节点最多只能 100 个，超过 100 就要 3 位数编码。好处是查询时可以用 code like '#{code}%'作为条件一次查出全部子节点。

@LeeReamond 什么叫只会用 centOS ？反正只是用来跑 docker，用起来难道还和 Debian 有什么不同吗？

11 有 zgc，8 有免费的甲骨文原厂 jdk

1 、配置中心。只需要运维人员掌握权限即可。
2 、打包脚本替换配置文件，打包服务器只允许运维访问。别人要打包发布通过 Jenkins 运行脚本。
3 、各种骚操作，但难度比上面两个办法要大。

Java8 怎么了？别看现在 16 了，但比 8 多了多少值得升级的特性 /功能？要是有足够份量的东西，Java8 早就被扔进垃圾桶了。
还有，kafka 有什么好学的？需要用的时候拿来用就是了。