在一个群里被恶心坏了

[gongxuanzhang]

我在 B 站看到一个微博架构师发的一些视频.觉得他讲的东西很实战,加了他的群,而且是哈尔滨的,我本人是佳木斯的所以对他非常有好感
今天上午群里在讨论事务隔离级别的问题.
本身就这一个技术问题大家有着不同的理解很正常,无论说的是对是错我觉得都没啥问题.
主要是针对 MySQL 的 RR 隔离级别下的幻读问题






这时候他表示没有锁就是幻读,还表示 Java 的锁就没学明白,我表达快照读就算不加锁同样没有幻读问题,除非你在事务里面修改了其他事务新增的数据,那就没办法了





然后就开始攻击我了,说官方文档写的清楚.

然后我去 MySQL 官方看,同时自己做了验证,我的理解是普通 Select 无论加不加锁,无论怎么查询都不会有幻读问题,如果 for update 或者 delete update 这种操作就会用临建锁或者间隙锁来保证一致.
所以他的结论"不加锁都是幻读" 就是不对的

还上升到 java 的锁,CopyOnWirteArrayList 不就是快照实现吗? 一个快照迭代器创建之后就是不会被其他线程影响啊,难道迭代器不加锁要被 add 影响吗? 无锁保证数据一致的方法多了,JcTool 里面好多队列都是



当我想把官方这个截图贴到群里的时候,我就已经被踢了. 我巨无语,一个资深技术专家可以这么讨论问题的.

然后我去 B 站质问他,果不其然 B 站也把我拉黑了



这就是架构师的格局吗 开了眼了


我觉得无论我说的是不是对的,技术问题起码应该就事论事,直接开始人身攻击,属实牛

https://www.bilibili.com/video/BV1gD421N7Ur/?spm_id_from=333.999.0.0&vd_source=b13a31d63cf084a4bc7e9d71d9c78835

回复的视频已经贴在上边,
V 友指出的我说"innodb 没有幻读问题",我说的确实是错的,这点的修正我当时在群里就已经说明,只是没截图出来,这点在视频中提到了,可以去看视频.
我表达的是我对他"不加锁都是幻读的情况"的质疑.
如果有兴趣可以去看视频

[yuxuan0piv]

卖课的么？

[meisen]

要不进 TG 群？ https://t.me/V2EXPro

[MajestySolor]

这种所谓的 up 主啊大佬啊所建立的小群，要么是想精准割韭菜赚钱，要么是想体验当偶像甚至皇帝被所有小弟吹捧的感觉，你不会以为这种群真的能心平气和的讨论技术问题吧，第一天接触网络世界么🤣

[gongxuanzhang]

@meisen TG 封了.. 没号了已经

[dif]

你说他错了，岂不是他很没面子。如果他没顶着架构师或者群主的称号，那可能就没这么敏感。

[yusheng88]

要 ”资深技术专家“ 承认错误，很难的啦
你在公众面前打他脸啊

[yazinnnn0]

耽误他卖课了

[0o0O0o0O0o]

你问他”这不是一个技术群吗“，可能真不是，围绕个人的这种微信技术群我几乎一个也没见过，在 B 站发视频引流到微信群更可能是卖课的

[qgewfg]

说明他找不到反驳你的理由了，让你继续说下去的话，会让他在自己的群里丢了面子

[xtreme1]

只看群里这几句, 我觉得它说话都说不明白(防杠: 我也说不明白), 为何你觉得它能讲明白技术呢..

[grimbedroom]

直接发视频，硬刚他，标题起和他相关的，我支持你

[0xD800]

。。。这种没质量的群 赶紧退吧

[gongxuanzhang]

@grimbedroom 我真有这个打算

[gongxuanzhang]

@0xD800 已经被送走了

[PingAn66]

楼主技术不错啊

[watzds]

正常，好多面试官也是半吊子，以前年轻还有点被唬住了

[frankilla]

其他不说，我个人，从不对什么老乡有先入为主的好感，就当一般人对待就是。（有的时候甚至会有些排斥）

[ajyz]

现在已经没有为爱发热的地方了，记住这点就行了，不论群、论坛等都一样，所以也都没落了（当然还有部分原因是言论管控）

[blankmiss]

@gongxuanzhang 出视频 狠狠的打它脸

[watzds]

另外讨论问题，也别一上来就质疑的口气，别人不一定喜欢辩论

先承认他说的对的地方，有特殊场景细化再问问，他要是不懂又不爱讨论，自己心里知道就行

[xianyv]

@meisen 这群......奇怪的人有点多

[gongxuanzhang]

@watzds 有道理 我下次换个方式

[gongxuanzhang]

@blankmiss 周末就做

[MoGeJiEr]

我也支持你发个视频反驳他，事不是什么大事，关键是太恶心了。

[rainABC]

总有些人高高在上的感觉，不能惯着

[Jame00001]

我也是最讨厌这些，但看了 5 楼的说法倒是有些理解。只能擦亮眼睛了

[7911364440]

笑死了，那几个喊勇哥牛逼，勇哥厉害的都是托吧。

另外 select 加锁以后就变成当前读了，会有幻读问题的。而且间隙锁只对索引字段生效，所以可重复读并不能完全避免幻读

[wyhooo]

技术群一个不加。这种打着 XX title 的本质都是割韭菜 or 满足个人虚荣心，群里大多数都小白，也不会有什么技术含量的。

[gongxuanzhang]

@7911364440 是的,普通的 select 区别于 select for update

[a86356]

这世界本来就不是非黑即白的，都是利益，op 理解了这句话，才会不那么较真。。。

[hangbale]

什么架构师 打的就是架构师

[zfyStars]

把你从韭菜群移除 你不是目标用户
你打大哥脸了 以后他怎么教育小弟

[gongxuanzhang]

@a86356 我较真的是技术和对技术的态度,我也不反感卖课,但内容得值吧.. 起码得对吧

[a86356]

@gongxuanzhang 不讨论对错，只能说站的立场不同。他能卖得下去，有粉丝，有受众，就说明他的内容有一定的价值。很明显，你不是他的受众，他 t 你也正常。

[NeedI09in]

首先，mysql 里读是加锁的，读锁和写锁是互斥的，rr 和 rc 之所以读写快是因为用了一致性非锁定读，本质是 mvcc ，通过 undo_log 实现。
rc 和 rr 都加了 mvcc ，但是 rc 有幻读，为了解决这个问题加的 rr 。
幻读解决办法是 rr 隔离级别加的间隙锁 + 一致性非锁定读（ mvcc ）解决的。
硬要说 rr 隔离级别下也有幻读。因为他不用一致性非锁定读，而用排他锁 for update ，或者共享锁 for share mode 。来读当前数据，确实有道理，但是他只是想显得自己很懂而已，没必要计较，因为你知道有这种特殊情况接纳就行了，当你和他争论，你就陷入了自证陷阱。语气不好就反击，没必要惯着。讨论问题是基于态度端正，而不是谁说话难听，反问句多就有道理。
如果我说的有不对还望各位海涵。

[adm7n]

哈哈，建议直接 B 站出视频 DISS 他

[gongxuanzhang]

@NeedI09in 是的,我觉得他用道理和例子拍我一脸我都接受,结果让我多读书别 BB,我真忍不了

[luolin0826]

[shyrock]

你见过哪个技术社区有人不停喊“勇哥牛逼”“勇哥高明”的。。。在技术者眼里跟个傻子一样。。。

[NeedI09in]

@NeedI09in 补充一下，开发始终是一个百密不如一疏的行业，有人提出疏忽其实是好事，但是阴阳怪气和鄙夷（这点都不知道）这种态度是不对的，“你知道”并不意味着你可以阴阳怪气和鄙夷。

[linxb]

其实这个可以看林晓斌的《 mysql 实战 45 讲》，关于幻读的讲解，说的非常仔细了

[zhuisui]

我通篇看下来，包括技术和交流方式两条线，尝试分析一下
1. 先说交流方式
- 架构师嘛，我猜估计资历和年龄都不小，有点脾气也能说得过去吧。上来先是教训小朋友的口气，然后是有点不太耐心仔细的回答，最后一竿子打死看起来不怎么靠谱的新人。我想说是没那么好，但是也没那么差。这个世界就是这么浮躁。
- 题主嘛，开口就是“你说得不对”（技术的东西我一会儿说），直接莽撞，然后回答也没那么严谨仔细（第二句“但是...”，下面说），也是充满了年轻人（我猜的）的脾气，也没做到处事严谨仔细。

在我看来半斤八两。
2. 再说技术
我很久没看 MySQL 了，临时搜索了解的脏读、不可重复读、幻读三个问题，以及快照读、当前读俩读取手段，还有可重复读和串行读四种隔离级别，也看到一些文章提到可重复读对于当前读手段，会有产生幻读问题的情况。当然我也没有验证，不过人家声称是验证了的，所以我觉得这是可信的。这里又牵扯到 MySQL 版本的问题。
我想说，这个特定场景在特定时空下肯定是存在的，而且这和题主的声称（但是...）的场景也相左。（不知道题主说的修改、冲突具体指啥，也不是专有名词概念，也不一定是指“可重复读对于当前读产生幻读问题”）
可以认为题主自己的技术也不严谨，一开始声称是 MySQL 实现上用 innodb 彻底解决了幻读问题，说对方是只知道规范。但是实际上是反过来的，对方才是很了解实现的人（毕竟都在美团了应该也见过不少特殊场景了），而题主自己主要是在看文档（虽然自己做了测试，但没提到上述场景）。

所以技术我站对方。

但是再看一下这个帖子的标题吧，我觉得题主过分了。
我自己吧，不觉得架构师就应该有好人品好涵养什么的，这是一个技术称谓，又不是“大师”“方丈”😃。
over

[vczyh]

这种群根本不是讨论技术的

[gongxuanzhang]

@zhuisui 首先我确实没表达清楚,是我的问题,这个冲突比较模糊,我想表达的是在正常查询的时候没有幻读,但是如果在你的事务过程中,你去修改了其他事务提交过的数据,或者是你自己新增,造成了主键冲突. 就会有问题, 这个是不是幻读的概念我也不知道,总之是有问题.

他表达的观点是: 不上锁都是幻读,很显然是错的. 官方文档的快照读就是无锁.
再次我并不觉得我不了解实现,相反我自己为了学习 innodb 自己写了一个项目用 kotlin 实现 innodb,还没写完.但是基本架构和功能都完成了,从经验上我确实远不如他,这也是我关注他的原因.

最后,你可以教育我,可以教训我,但是教育方式是什么? 别 BB 了 然后踢了.
还是拿出我的逻辑问题死死打我

[dolorain]

B 站发个视频揭露他吧。

[FireKey]

看语气明显群里被捧臭脚习惯了,碰到你这种较真的拉不下脸

[xguanren]

正常 这也是现在为什么拒绝大龄程序员.因为不得不承认 随着时间的推离.某些人会故步自封.拒绝外部新的资讯.远不如年轻程序员接受新鲜技术.新鲜事物的接受能力高.或者某个地方你稍微反对他.他就会恼羞成怒.其实映射到家庭.有点像家庭当中.孩子本身刚开始就懵懂.其中父亲的话.会有非常多的这种固有认知.从而影响.

[z1829909]

这种人数很多的技术群, 发展的最终形态就是总有几个 2b 天天不上班似的一直说些有的没的, 没事和你杠几句, 正经讨论技术的会被他们恶心走, 最后成养蛊了.
想要技术群保持健康, 要么是小圈子认识的人, 要么天天有人发涩图新闻.

[billzhuang]

支持你干他，我给你投币

[shapper]

本来人家建群就是想建立权威带领群友收割韭菜的，你这进去讲道理，扰乱发财，不 K 你才怪

[laikick]

别加任何和技术有关的群. 多看代码. 多参加开源项目最实际

[TomDu]

看完感觉.. 就是这些知识自己平时都记不住，需要用的时候才会临时去 Google

唉，勇哥牛逼。

[crab]

技术专家技术专家.jpg

[qieqie]

几周前我还在 B 站上刷到这个人锐评 TiDB ，看了 5 分钟就发现是个外行胡说八道，在评论区喷了他他都不敢回我。

[qlee1122]

微博的不都在微博玩吗，像泰迪老师这些这些 https://weibo.com/u/1809500942

[oneisall8955]

B 站视频在哪，参观下

[miyuki]

这就又要搬出 @clowwindy 的经典结论：编程圈子都会变成“小白”围着“大大”转，“小白”捧“大大”臭脚，“大大”获得夸奖而自我满足

[aragakiyuii]

旧文重读
https://liuyangming.tech/06-2019/Transaction_Isolation.html

[DefoliationM]

在微信上这种所谓技术群里讨论，不如把 GitHub 的 issue 当论坛看，感觉这个更有意思。

[Hisoka]

在他的地盘上，他的权威一旦被成功挑战他就完了

[luckyfly]

看到勇哥牛逼 我以为是油管上的勇哥砍砍砍了哈哈

[paidaxinginfo]

理解的不够透彻。看看这个文章吧（无恶意）： https://mp.weixin.qq.com/s/K5l6hixzn5K9jWd7shu2GQ

[ucando]

平时用 postgresql 比较多，刚刚粗浅地看了下题主说的幻读问题，然后想想“勇哥”的观点：不上锁都是幻读，虽然题主提出这是错的，举了快照读是无锁的例子，但快照读明明就是有可能发生幻读的呀，难道是我理解错了？其实“勇哥”是不是想表达“不上锁的事务都有可能发生幻读”呢？按我的理解幻读都出现在事务中，是要针对查询出来的结果做其它操作才会有影响，不在事务中的单条查询要么出来的是其它事务提交前的数据，要么出来的是其它事务提交后的数据，都不存在幻读的概念了吧？大牛们请指教

[kmyzzy]

在微信群里和不认识的人讨论技术问题简直就是扯淡。

[LFITS]

OP 你引用架构师的话得时候 没有打马赛克#24

[sagaxu]

之前某个对标 netty 的国产 IO 库，作者写的 release notes 顺便吐槽了 socket read 返回的字节数小于指定的值，还说那是个 bug 。我留言里指出了问题所在，他怕影响他推广，私信让我删了留言，搞开源不易，我配合他删了评论。

我就不点名那个作者了，虽然技术细节可能不够到位，但他执行力是真的强大，不考虑稳定性和正确性，仅从功能角度看待，已经不比 netty 差了。

[cnrting]

不 T 你课还怎么卖

[zjp]

@sagaxu 有点印象，这人还挺神奇。有种地基没打好就盖大楼还真盖成了的感觉😂

[hefish]

我隐约看到了 20 年前的我。。哈哈。。。 向前看。

[macaodoll]

一个技术群，我是管理员，有个自称架构师的天天把群友挨个加，加了就发公众号让人家关注阅读，后来警告过不听，还在加，我直接给丫的踢了。

[Achophiark]

@luolin0826 先不说技术，这兄台活的真通透佩服佩服！

[jzphx]

讲不过的人常说的一句话就是多看看书

[Jack66]

从这人开始发的信息到最后，把自己摆的较高，说的技术性东西很少，具有对人的攻击性。说明他就不是一个做技术的，卖车不懂车的选手多了去了。

[eatgrass]

技术问题能够自己查的答案的不要在群里问，技术群是最低效准确性最差的解决问题的地方

[asLw0P981N0M0TCC]

干干干！出了视频说下

[amon]

牛逼，现在还有技术群讨论技术的。

[zhtyytg]

@watzds 刚毕业的时候有个面试官，自己出的题自己回答错了，给我整无语了

[liuzimin]

赞同楼上某几位说的，这个群主脾气虽然臭，但楼主你的口气也很不给面子啊，说话太直了。

[awalkingman]

@NeedI09in #35 rc 有不可重复读，为了解决这个问题，加 RR 。幻读时数据行增加或减少，是在 SERIALIZABLE 处理

[sun1993]

看到卖课的这种水平，很欣慰，这样涌进这个行业的人就没办法和我竞争了😂

[lambdaX999]

看了大部分评论都没有讨论 OP 提出的问题，我很想知道这个问题的真正结论是啥，到底是那个架构师错了，还是 OP 错了，为什么大家都在讨论架构师怎么样，OP 怎么样，对于 OP 核心的问题讨论甚少，希望能看到让我学习下。

另外这种通过视频引流拉的群，本身大多数 UP 都是希望通过这种方法卖课或者干点别的，俗称噶韭菜，当你在群里让他颜面扫地或者怼他的时候，他踢人确实正常。我之前在阿里的一个群里讨论别的产品都被踢了，格局低的基本都这样，我感觉也没必要生气，还是应该回到问题的本质，就事儿论事

[chunzhang5748]

让我想起王迅跟一个教授在一个节目中讨论‘上善若水’的场景......

[zzhaolei]

@liuzimin 卖课的，靠知识挣别人钱的，知识都了解的不对，就别怪别人说话直了

[xuanbg]

自己知道就行了，没必要非要指出别人的错误。这也是尊重他人命运吧。。。

[zzhaolei]

这不是诈骗吗，这能纵容？？？？

[htxy1985]

所以，这个问题的答案是什么，还有人探讨下吗，就像 35 楼那样。

[liuzimin]

@zzhaolei 如果是这个角度想，那我觉得楼主的口气反而轻了，直接就应该骂他丫的，什么傻逼架构师狗屁不懂你他妈卖个什么课。。。
不过如果从讨论技术的角度，楼主的口气又重了。

[zzhaolei]

关于 MySQL 实际上的幻读问题： https://xiaolincoding.com/mysql/transaction/phantom.html
1.普通读是快照读，select for update 是当前读，当前读会加锁，基本上解决了幻读的问题
2.没有完全解决有两种情况会出现幻读，具体可以看这篇文章
2.1 第一个幻读场景我觉得不能这么用，用法就很奇怪

[jackwaycn]

讨论问题意见不合很正常，可以就事论事摆证据，一言不合就踢人格局一下就低了

[xiaoxixi08]

是要开发数据库？讨论这个有啥意义

[0xLittleFi]

在 MySQL 中，幻读 是一种特定情况下的并发控制问题，它发生在使用事务时，特别是在可重复读（ Repeatable Read ）隔离级别下。幻读是指在同一个事务内，当执行同样的查询时，第二次查询返回了第一次查询未出现的新行，这些新行是在第一次查询之后被其他事务插入的。

幻读通常与以下场景相关：

范围查询：

当一个事务在执行一个范围查询（如 SELECT * FROM table WHERE some_column BETWEEN value1 AND value2 ）时，如果在事务开始后，其他事务在这个范围内插入了新的行，那么在事务的后续查询中，这些新行将被看到，尽管它们在事务开始时并不存在。
索引间隙：

在 InnoDB 存储引擎中，使用行级锁和间隙锁（ Next-Key Locks ）来防止幻读。但是，如果查询不包含任何索引范围条件，或者索引选择性不高，导致锁定的是整张表或大范围数据，那么幻读仍然可能发生。
隔离级别：

在默认的可重复读隔离级别下，InnoDB 通过多版本并发控制（ MVCC ）防止脏读和不可重复读，但仍然可能遇到幻读。
要完全避免幻读，可以将隔离级别提升到序列化（ Serializable ）。这将对所有查询施加读锁，从而确保事务之间的一致性，但代价是降低了并发性能。
解决幻读的方法包括：

使用 SELECT ... FOR UPDATE：

在查询时添加 FOR UPDATE 子句，这会锁定查询到的行，直到事务结束。但这只适用于锁定已经存在的行，对于新插入的行，仍可能出现幻读。
提升隔离级别到 SERIALIZABLE：

这是最高的隔离级别，会阻止幻读，因为它会对整个查询进行锁定，相当于对事务执行时的数据库快照进行读取。但这种方法可能会导致大量的锁竞争和阻塞，降低系统性能。
使用特定的事务设计：

通过调整事务的逻辑，例如使用更大的事务粒度，或者避免在事务中进行范围查询，可以减少幻读的可能性。
请注意，幻读仅在特定隔离级别下发生，并且主要与并发事务插入新行有关。在读已提交（ Read Committed ）隔离级别下，由于每次查询都会看到最新的提交，因此幻读的概念并不适用。

[ryougifujino]

@xguanren 确实是有这样的人，但拒绝的理由不成立。没有爹味的大龄程序员没有理由为有爹味的大龄程序员负责，这是典型的中式一刀切......

[FrankAdler]

[架构师-刘志勇的个人空间-哔哩哔哩] https://b23.tv/RlFXAfb 应该是这个人了吧，自称架构师

[oxykr]

承认自己错了太难了

[tracebundy]

我接触的技术专家，讨论技术都很平和，实事求是

[kylix]

影响他卖课了，不踢你踢谁

[zhouweiluan]

群主这种格局就不讨论了。😂
不过我跟人家探讨意见不合的问题的时候都喜欢加上「我觉得」「我记得」「好像」「应该」「可能是」这种字眼，这样对抗感和质疑感会没有这么强。

[fionasit007]

@gongxuanzhang 换个号进去打他脸吗，不能惯着他

[moonalalei]

在别人的技术群纠别人的错是不行的，因为现代社会人都是狭隘的，自私的。

[chanlk]

https://icyfenix.cn/architect-perspective/general-architecture/transaction/local.html

看看这个，我觉得写得很好！