https://zhuanlan.zhihu.com/p/47445841
- 单机场景一致性主要看并发隔离
- 分布式场景一致性主要看怎么获得全序关系
一致性门道很多，不系统性的学习根本就弄不清楚的；可以看看 DDIA 这本书

...已经迟到了 🌶🐔iphone

@miaoever 学习了，蟹蟹老哥

@leavan 可以（不过我只接触过 spark 的）；不是说业务需求复杂，是说引擎里面不应该有这么多的复杂数据结构，前置需要打平和结构化，你们初衷就要追求性能，就更加不能整这么多复杂的数据结构了，要把数据做成大宽表

追求性能就应该少用 UDF 或者 UDAF，这玩意对优化器来讲是黑盒，而且对业务侧来讲也不透明 优化空间受限

那就上 UDAF 咯，不过我不觉得这个是健康的开发模式；不能把所有的活都丢给 SQL 来干（不要欺负一个图灵不完备的 DSL =-=），离线数据就先做一层 ETL，再入库；实时数据就业务代码里面帮忙处理好，打平了再丢到存储引擎

@ittianyu 很久没看到老哥了，去哪里发财了

@bitdepth 质疑需要拿出证据，而且这个话题的关注点难道在这里？你友善交流也不会跟别人吵起来。全世界都不相信中国的数据，又有几个真的来过国内看看实际情况，都是靠脑补意淫，质疑就质疑呗，我们自己过得很安心。世界就是分裂的，感到无奈和寒心，人性如此

一个服务应该有两层：无状态的应用层和有状态的存储层，前者根本不存在挂，有问题替换就行；后者挂了才是真的挂；所以每个微服务的有状态层需要隔离开来；你这样所有服务都去查缓存，存在的问题很致命：
1. 数据都在同一个有状态的服务上，有状态的服务一旦出现问题全都给挂
2. 数据写入 /读取的一致性问题
3. 一刀切使用旧版数据完全脱离业务，很多业务并不能接受过期的数据

如果只是想搞清楚相关概念，我建议直接读 ANSI 标准，各类主流数据库在实现的时候都会遵循，也避免掉到具体数据库的实现细节中去：
https://wiki.hsr.ch/Datenbanken/files/Paper_ANSI_SQL_Isolation_Levels_Stefan_Luetolf_V2_1.pdf

一篇老而经典的论文：A Critique of ANSI SQL Isolation Levels，里面有指出了 ANSI 标准一些容易让人误解的场景

认真读完这两个东西，理解会很深刻

@dovme 走了，因为二级索引里面已经包含了所有要的字段数据，所以去扫二级索引的树，不用回表；你改一下表结构，新增一些字段结果就不同了，不会命中索引

让我想起旁边部门的 leader，也是光头，但是很帅..很有气质

@hezhiming1993 室友就是陌陌的，最忙的时候加班加成狗，一周 6 天，每天到晚上 3 点；加班属于常态

引导式学习的一个教程，强动手性质： https://github.com/Gazler/githug

1. HBase 是 CF 的 NoSQL，跟 OLAP 没关系
2. CH 可以，但运维成本高，没法更新，rebalance、扩容、 删数据头疼
3. Doris 整体而言不错，性能、运维、灵活性皆可，可以低频更新
但用此类 OLAP 的系统都需要先把数据打平，有一个 ETL 的过程，过于复杂的 SQL （ join 过多），性能都不会太好

有一个纯内存的 OLAP 引擎：SnappyData，速度很快，可以支持非常复杂的 SQL ；但社区小众，而且不稳定，BUG 多，不过千万级的数据还是随便玩了

楼主可以都调研一下，个人推荐 Doris

试试美团点评吧，刚看春招扩招了（说是 1000 的校招 HC ），前端一直是比较缺的岗位： https://campus.meituan.com/jobs?jobType=1

另外如楼上很多人说的，对薪资要求不高可以不写，不要太妄自菲薄，这是减分项

@BBCCBB 使用场景适用最重要； ZGC 没有严格意义上的 STW 这个对数据库很重要
稳不稳定这个问题，至少在这边生产环境已经用上了，相信也是自己跑了充分的测试；我不是那个组的 具体的情况我也不太清楚

@BBCCBB 木有文档，主要是牺牲一些整体的吞吐（因为要绑几个核专门拿来 GC ），和一些内存的 overhead 来换取整体的 Latency，没有 fullgc

有，美团的 Doris 用了 ZGC，JDK12