V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  leeqingshui  ›  全部回复第 1 页 / 共 2 页
回复总数  39
1  2  
15 天前
回复了 SteveRogers 创建的主题 问与答 大家 airpods pro 二代都有品控问题么?
耳机盒缝隙较大,用手左右移动会疙瘩疙瘩响,换过一次还是老样子......
不过降噪确实可以。
@lmshl 不想背八股文😂,只是想研究下什么业务下用哪个隔离级别更合适~
这是目前我在网上找到的一篇一定程度下解惑的相关性文章: https://www.zhihu.com/question/47007926/answer/2264785785

原文搬运到此(侵删)

真实的场景可以注意一下,代码里面,有没有出现连续 2 次 select 的场景。

那为什么会出现连续 2 次 select 的场景,第二次不能复用第一次的结果吗?
这个主要是因为写代码的时候,第一次 select 和第二次 select 很可能不在一个方法里面。要复用,就要在第一个方法里面 return 这个结果,再传给第二个方法。有时候觉得这样写太难看了,干脆就查两次算了,反正小业务不用考虑啥性能的。这个也可以认为是用性能换取代码可读性,代码可维护性。( PS:不过个人还是不喜欢这样查两次,可以再想想办法,在不影响代码可读性上查一次)

另外,讨论幻读和可重复读的问题,很多时候可能都在考虑选 RR 还是 RC 的问题。

选 RR 还是 RC 首要考虑的是业务逻辑上会不会出错。
1.一个判断就是有没有两次 select
2.另外一个就是要注意 RR 虽然能解决可重复读,幻读的问题,但是并不意味着代码就不出错。有点像 java volatile 虽然能保证可见性,但不是说用 volatile 就能解决并发问题这个道理。

举个例子说:现在 RC 级别,一个业务失败了可以记录表等待重试,也可以直接取消掉。定时任务拉取了现在记录表等待重试的记录,结果后面重试又失败了,原因是被直接取消掉了。心想为啥呢,要是被取消了,定时任务也拉不起来呀,这个原因就是拉起来后,中途马上被别人改掉了,重试的时候冲突发生了错误。

这个时候可能心想:哦,原来是读到了别人取消的信号。那简单,直接改成 RR ,保持我这次业务逻辑的正确性(定时任务拉取到,就要能修改),如果是这样做,最后数据库这行记录变成了:取消标志位:true ;执行状态:success 。人傻了。。。

还有一个场景就是,更新余额的时候。像在上上个公司,更新余额的时候,是事务里面,select for update 查出数据,然后减少余额,应用里算出余额的值,最后 update 。这个不管是 RC 还是 RR 级别,都没问题,因为 select for update 锁行了。

像在上个公司,更新库存的时候,开了 RC 级别事务,更新的时候,代码里没有像 select for update 锁行,而是在更新语句中 update 表 set 现在的库存=原来的库存-要扣的数量。这个也没问题。

但是如果你数据库是 RR 级别,没有用 select for update 锁住行,是在应用层算出最后新值,然后再直接 update 这个新值。心里想着,那现在总没问题了吧,RR 级别,可重复读,我这个业务的计算可是正确的。但是实际上也是有问题的,会把别人的覆盖掉。

所以总的来说,RR 和 RC 我一般会先看下有没有两个 select ,也就是明显的幻读,可重复读问题。另一个会看下会不会有可重复读的问题解决了,本次业务能够保证正确性,但是在更大的维度上可能会出错(把别人的覆盖了)

PS:不过上述的考虑我觉得还是有点偏理论偏学生,站在更加实际,现实的角度:
1 、小项目的话,直接默认 RR ,因为没有业务,我没理由改 RC 。改 RC 可能还会有潜在的我不知道的错误(因为毕竟不是默认的),前期需要研发速度,需要尽量简单快速落地
2 、项目变大了,想要 RR 改 RC 。不敢改。项目变大了,稳字优先,稳字当头
3 、想要利用 RR 改 RC 提升性能,没有其他技术手段了吗,非要改这个?
4 、没有其他技术手段了,那就改吧
@liprais 这个有争议,有的认为有,有的没有😂
查了些资料: https://www.zhihu.com/question/47007926
@7911364440 昂昂,居然还有这种操作嘛😂,周末搭个主从研究下~
@7911364440 这是主从复制 binlog 格式设置为 STATEMENT 的问题,row 格式则不会有这个问题,找到了一篇相关介绍的文章:
https://www.cnblogs.com/fanguangdexiaoyuer/p/11323248.html
@momocraft 网上查询资料时,看的很多文章说——阿里建议将数据库级别设置为 RC ,用来:
- 提升并发:RC 在加锁的过程中,是不需要添加 Gap Lock 和 Next-Key Lock 的,只对要修改的记录添加行级锁就行了,另外,因为 RC 还支持"半一致读",可以大大的减少了更新语句时行锁的冲突;对于不满足更新条件的记录,可以提前释放锁,提升并发度。
- 减少死锁:RR 隔离级别会增加 Gap Lock 和 Next-Key Lock ,这就使得锁的粒度变大,那么就会使得死锁的概率增大,而 RC 不用 Gap Lock 和 Next-Key Lock

有的业务使用应该还是有好处的
30 天前
回复了 gabriel_zhen 创建的主题 问与答 求一个数据库导出 excel 的工具或方法
Navicat 和 DataGrip 都可以将 SQL 执行的结果导出为 Excel ,甚至 csv 等其他格式的文件
32 天前
回复了 chengong 创建的主题 NAS 文件存储服务搭建建议
minio
形式主义抄就完了,比如你数据处理有用到排序的 API ,比如 Java 的底层用的是快排,网上找篇分析快排的文章复制下写进文档就行了
@bthulu 生产环境客户不会让这么搞的,只能压测了~
@Dganzh 官方启动脚本内存默认单机模式给了 512 M ,集群模式默认设置了 2G
@leeqingshui 看错了,上面那个是 dubbo 2.7.8 集成 Nacos 的 bug
nacos 配置列表中出现很多以接口名为 dataid 的 dubbo 的配置文件,这个可以关闭,但不知影响如何
https://github.com/apache/dubbo/issues/7598
dubbo:
registry:
address: nacos://127.0.0.1:8848?username=nacos&password=nacos
# 增加以下配置
use-as-metadata-center: false
use-as-config-center: false
@damai0419
@Rumble66 https://github.com/apache/dubbo/issues/6988
Nacos 集成 Dubbo 多了巨多 dubbo 的配置文件,我查了下,这个应该是 dubbo 的 bug
https://github.com/alibaba/nacos/issues/4491
https://github.com/apache/dubbo/issues/6988

dubbo 社区已经有人发现了这个 bug ( https://github.com/apache/dubbo/issues/6988 )并且提交了 pr 。目前已经被合并到了 master 分支( dubbo 2.7.9 )。
@damai0419
将 Nacos 作为注册中心遇到过其他问题嘛?
后面你们是不是又换回了 zk😂
zk 存储是树形结构,看着是会舒服点
nacos 一启动,日志文件也多一堆😂
@Kaiv2 好的,我会试下~
@bthulu 用 Nacos 主要是它的某些功能特性刚好符合实际业务场景需要,能解决一些问题,和应用规模没关系吧。。。
数据字典这个功能应该放到一个基础模块当中,其他组件引用就好。
多产品的不同参数含义一样,名称不同,那么应该抽离一个专门的模块做字段映射,比如说公司内部的产品三方调用各种外部接口,最终接口的参数经映射统一后落到公司内的数据库,后续看日志想知道外部传递了哪些参数过来,以你映射后的参数为基准即可。
对于你司内部产品应该也是互相调用吧?那经过这个中转映射模块就好。
@wolfie 这块国庆抽时间弄了下~
视频地址:aHR0cHM6Ly9zcGFjZS5iaWxpYmlsaS5jb20vMjAzNTE2NzkzL3ZpZGVv
代码地址:aHR0cHM6Ly9naXRodWIuY29tL0Nocmlzc3NXb25nL2ludm9rZS1jb21wZW5zYXRpb24=

后面的优化下周会弄下~
@wolfie 嗯呢,我看到了,我这边也写了 80%,这周有空完善下,国庆我会把代码放出来,B 站再录个视频说明下~
1  2  
关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   4819 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 68ms · UTC 06:37 · PVG 14:37 · LAX 22:37 · JFK 01:37
Developed with CodeLauncher
♥ Do have faith in what you're doing.