乐观锁、悲观锁

乐观锁:

总认为不会产生并发问题,因此不会上锁,更新时会判断其他线程在这之前有没有对数据进行修改,一般会使用版本号机制或CAS操作来实现

version: 数据上有数据版本号version字段,每次更新version值加一

CAS操作方式:compare and set, 三个参数,数据所在的内存值,预期值,新值,当需要更新时,判断内存值与之前取到的值是否相等,若相等,用新值更新,否则不断尝试

悲观锁: 总是假设最坏的情况,每次取数据都认为其他线程会修改,所以都会加锁(读锁,写锁,行锁),当其他线程要访问数据时, 阻塞挂起。

# --------------------------------------------------------------------------------------------------------------------------------

集群: 同一个任务部署在多台机器上,提高系统可用性

分布式: 将不同的业务分部在不同的地方

    分布式的每一个节点,都完成不同的任务,一个节点跨了,该任务就无法访问

举例: 计算1到100加法

集群: 每台集群都要完成1 加到 100, 耗时1秒,但可以多台机器同时进行计算,即1秒可以完成多次1 加到 100 这个请求

分布式: 将 1 到100 拆成 例如10组部署10台机器,每台机器完成一组计算,耗时0.1 秒, 总用时 0.1秒

总结: 分布式中的每一个节点都可以做集群,而集群不一定是分布式的

# --------------------------------------------------------------------------------------------------------------------------------

微服务:
单体应用: 项目是一个整体,一旦出错,程序奔溃
微服务: 项目拆成不同的服务,服务和服务之间交互,restful 接口

幂等性:

多次请求和一次请求的效果一样,put和patch 是幂等性,post不是
post 是新增, put and patch 是修改,所以是幂等性

原文地址:https://www.cnblogs.com/Afrafre/p/10609877.html

时间: 2024-11-03 20:42:31

乐观锁、悲观锁的相关文章

[转]数据库并发控制 乐观锁,悲观锁

在数据库中,并发控制有乐观锁和悲观锁之间,什么时候用乐观锁比较好什么时候用悲观锁比较好? 实际生产环境里边,如果并发量不大,完全可以使用悲观锁定的方法,这种方法使用起来非常方便和简单.但是如果系统的并发非常大的话,悲观锁定会带来非常大的性能问题,所以就要选择乐观锁定的方法. 悲观锁假定其他用户企图访问或者改变你正在访问.更改的对象的概率是很高的,因此在悲观锁的环境中,在你开始改变此对象之前就将该对象锁住,并且直到你提交了所作的更改之后才释放锁.悲观的缺陷是不论是页锁还是行锁,加锁的时间可能会很长

最全Java锁详解:独享锁/共享锁+公平锁/非公平锁+乐观锁/悲观锁

在Java并发场景中,会涉及到各种各样的锁如公平锁,乐观锁,悲观锁等等,这篇文章介绍各种锁的分类: 公平锁/非公平锁 可重入锁 独享锁/共享锁 乐观锁/悲观锁 分段锁 自旋锁 01.乐观锁 vs 悲观锁 乐观锁与悲观锁是一种广义上的概念,体现了看待线程同步的不同角度,在Java和数据库中都有此概念对应的实际应用. 1.乐观锁 顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号等机制. 乐观锁适用于多

【多线程】公平锁/非公平锁、乐观锁/悲观锁

公平锁/非公平锁(多线程执行顺序的维度) 概念理解 公平锁:加锁前先查看是否有排队等待的线程,有的话优先处理排在前面的线程,先来先得. 非公平所:线程加锁时直接尝试获取锁,获取不到就自动到队尾等待. 例子 ReentrantLock 同时支持两种锁 //创建一个非公平锁,默认是非公平锁 Lock nonFairLock= new ReentrantLock(); Lock nonFairLock= new ReentrantLock(false); //创建一个公平锁,构造传参true Lock

AtomicInteger如何保证线程安全以及乐观锁/悲观锁的概念

众所周知,JDK提供了AtomicInteger保证对数字的操作是线程安全的,线程安全我首先想到了synchronized和Lock,但是这种方式又有一个名字,叫做互斥锁,一次只能有一个持有锁的线程进入,再加上还有不同线程争夺锁这个机制,效率比较低,所以又称“悲观锁”. 但是相应的有了乐观锁的概念,他的思路就是,它不加锁去完成某项操作,如果因为冲突失败就重试,直到成功为止.这种说的比较抽象,我们直接拿AtomicInteger源码举例,因为AtomicInteger保证线程安全就是因为使用了乐观

并发控制:(二)乐观锁 悲观锁

悲观锁:(pessimistic locking):假定:发生冲突的概率比较高,实现:在对任意记录进行修改前,先尝试为该记录加上排他锁(exclusive locking).这样其他事务如果想操作该记录,需要等待锁的释放特点: 当并发量较大,频繁访问时,等待时间较长,并发访问性不好例如: java的synchronized,SqlServer页级锁,Oracle行级锁 乐观锁:(optimistic locking)假设:发生冲突的概率比较低实现:在提交对记录的更改时才将对象锁住,提交前需要检查

乐观锁悲观锁

老生常谈,这个写的挺好. http://blog.csdn.net/hongchangfirst/article/details/26004335 悲观锁(Pessimistic Lock), 顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到它拿到锁.传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁. 乐观锁(Optimistic Lock), 顾名思义,就是很乐观

乐观锁+悲观锁

乐观锁: 乐观锁( Optimistic Locking ) 相对悲观锁而言,乐观锁机制采取了更加宽松的加锁机制.悲观锁大多数情况下依靠数据库的锁机制实现,以保证操作最大程度的独占性.但随之而来的就是数据库性能的大量开销,特别是对长事务而 言,这样的开销往往无法承受.而乐观锁机制在一定程度上解决了这个问题.乐观锁,大多是基于数据版本( Version )记录机制实现.何谓数据版本?即为数据增加一个版本标识,在基于数据库表的版本解决方案中,一般是通过为数据库表增加一个 “version” 字段来实

MySQL 乐观锁 悲观锁 共享锁 排他锁

乐观锁 乐观锁是逻辑概念上的锁,不是数据库自带的,需要我们自己去实现.乐观锁是指操作数据库时(更新操作),想法很乐观,认为这次的操作不会导致冲突,在操作数据时,并不进行任何其他的特殊处理(也就是不加锁),而在进行更新后,再去判断是否有冲突了. 通常实现是这样的:在表中的数据进行操作时(更新),先给数据表加一个版本(version)字段,每操作一次,将那条记录的版本号加1.也就是先查询出那条记录,获取出version字段,如果要对那条记录进行操作(更新),则先判断此刻version的值是否与刚刚查

解决并发问题,数据库常用的两把锁——悲观锁,乐观锁

一.概念: 乐观锁:适用于写少读多的情景,因为这种乐观锁相当于java的cas(比较并替换),所以多条数据同事过来的时候不用等待,可以立即进行返回 悲观锁:适用于写多读少的情景,这种情况也相当于java的synchronized,reentrantLock等,大量数据过来的时候,只有一条被写入,其他数据需要等待,智行完成后下一条数据继续. 二:实现方式: 乐观锁:采用版本号的方式.即当前版本号如果对应上了就可以写入数据,如果判断当前版本号不一致,那么就不会更新成功. 比如 update tabl

Django - ORM - 事务, 乐观锁, 悲观锁

事务 概念 Transaction 事务:一个最小的不可再分的工作单元:通常一个事务对应一个完整的业务(例如银行账户转账业务,该业务就是一个最小的工作单元) 一个完整的业务需要批量的DML(insert.update.delete)语句共同联合完成 事务只和DML语句 ( 数据库操作语句 ) 有关,或者说DML语句才有事务.这个和业务逻辑有关,业务逻辑不同,DML语句的个数不同 特性 ? 原子性(A) 事务是最小单位,不可再分 ? 一致性(C) 事务要求所有的DML语句操作的时候,必须保证同时成