- 业务层面乐观锁CAS，使用版本号解决ABA问题，实际使用中使用时间戳，更新的时候把查出来的时间戳带上，如果更新失败可以自旋，获取最近值和时间戳，直到更新成功。
- DB层面开启一个事务，然后select一行for update给这一行加上排它锁，再去更新行，然后提交，其他事务就会阻塞在select for update。
- 分布式锁适合竞争不激烈的情况保证一致性，因为性能比较差，按CAP理论来讲应该是保证了CP放弃了A，zk或者redis保证一致性P，只有拿到锁的线程才能执行，保证一致性C
并发下保证数据一致性
©著作权归作者所有,转载或内容合作请联系作者
平台声明：文章内容（如有图片或视频亦包括在内）由作者上传并发布，文章内容仅代表作者本人观点，简书系信息发布平台，仅提供信息存储服务。
平台声明：文章内容（如有图片或视频亦包括在内）由作者上传并发布，文章内容仅代表作者本人观点，简书系信息发布平台，仅提供信息存储服务。
推荐阅读更多精彩内容
- 为了降低成本，充分利用备DB，很多业务会使用读写分离的架构，由备DB负载处理读请求。但是很难保证主备的严格同步，而...
- 本人最近学习了一下微服务下数据一致性的特点，总结了下目前的保障微服务下数据一致性的几种实现方式如下，以备后查。此篇...
- 文章纲要 此次分享的缘由 目前分布式事务问题是怎么解决的 行业中有什么解决方案 这些解决方案分别有什么优缺点 别人...
- 1. 传统应用的事务管理 1.1 本地事务 再介绍微服务下的数据一致性之前，先简单地介绍一下事务的背景。传统单机应...
