@Aresxue
1. ACID 这个概念已经被滥用，有各种解释，就像"一致性"这个词语被滥用一样，这也是造成现在大家认知混乱的原因；建议看看 DDIA 里面作者的观点，我看了是收益良多

2. 从你的回答可以看出你没有读过 CAP 的论文，也不清楚它真正的价值到底在哪里（提到 CAP 就只知道三选二的都是在网上碎片化获取的知识）；关于 C 到底是什么含义：可以参考 https://www.the-paper-trail.org/page/cap-faq/

3. 大家理解的所谓强一致：“写了就能读到最新的”，在工业实践上面是不可能做到的，在有各种延迟的情况下，数据“最新”就是一个不存在的说法； linearizably 就是工业实践能做到的最强一致性，zk 提供了 linearizably 的 sync 接口；你说的多数派叫 Quorum，问题的范畴属于我楼下提到的共识问题（ Paxos 、Raft 、ZAB （ zk 使用的这个）都属于 quorum-based 的共识算法），你可以去了解一下 Quorum 和 2PC 的区别，是做了什么 trade-off，解决什么问题 什么场景来用；现在主流保证多个数据副本之间一致性用的算法也就是上面提到的 Quorum-based 的算法，对于 server 端自己来讲这是共识问题，一致性这个东西的主要观察对象是 client 端

@yeqizhang 14 楼说得并不对，理解太浅显
ACID 里面的 C 定义非常模糊，与业务定义有关，ACID 这几个概念就不正交；单机数据库谈论 ACID 比较多，AID 是对 C 的约束
CAP 里面的 C 也不是指什么副本一致，而是指线性一致性（也就是大家谈论的强一致，但其实大部分人自己是说不清楚什么是强一致的）

还是去看书吧，这个需要扎实的理论基础

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 这个对数据库很重要
稳不稳定这个问题，至少在这边生产环境已经用上了，相信也是自己跑了充分的测试；我不是那个组的 具体的情况我也不太清楚