-
乐观锁和悲观锁
乐观锁和悲观锁是两种并发控制策略,用于解决多线程或多进程访问同一资源时的数据一致性问题。
乐观锁
- 概念:假设数据很少被修改,因此不会在数据访问前加锁。
- 机制:读取数据时不加锁,更新时检查数据是否被修改(通常通过版本号或时间戳)。如果数据没有变化,则提交修改;否则,操作失败,需要重试。
- 适用场景:适合读多写少的场景,避免因频繁加锁导致的性能问题。
悲观锁
- 概念:假设数据会被频繁修改,因此在访问前加锁。
- 机制:读取或修改数据时加锁,确保同一时间只有一个事务可以操作数据。其他尝试获取锁的事务会被阻塞,直到锁被释放。
- 适用场景:适合写多读少的场景,需要严格控制数据一致性。
例子
- 乐观锁:电商网站的库存管理系统,用户读取商品信息时不加锁,提交订单时检查库存是否改变。
- 悲观锁:银行转账系统,在进行账户余额更新时加锁,以确保数据一致性。
选择使用哪种锁策略取决于系统的读写比例和对并发的要求。
-
共享锁和排它锁
两种锁的概念
共享锁(Shared Lock,S锁)
- 允许多个事务同时读取数据,但不允许修改数据。
- 其他事务可以获取共享锁,但不能获取排它锁。
排它锁(Exclusive Lock,X锁):
- 独占数据的访问权,禁止其他事务读取或修改。
- 在事务持有排它锁期间,其他事务不能获取共享锁或排它锁。
这两种锁机制确保了数据的一致性和完整性。
两种锁的使用场景
共享锁(Shared Lock, S锁)
假设有两个用户,用户A和用户B,他们都想读取同一条记录。用户A获取了该记录的共享锁,因此可以读取数据。同时,用户B也可以获取共享锁来读取相同的数据,因为共享锁允许多个读操作并发进行。
排它锁(Exclusive Lock, X锁)
现在,用户A想要修改这条记录,他需要获取排它锁。此时,用户B不能获取任何锁(包括共享锁和排它锁)来访问该记录,直到用户A完成修改并释放排它锁。这样保证了数据的一致性和防止并发写入冲突。
文章归档
2015 年 08 月
1
2015 年 06 月
1
2015 年 04 月
1
2015 年 01 月
1
2014 年 10 月
2
2014 年 09 月
1
2014 年 08 月
3
2014 年 07 月
1
2014 年 06 月
3
2014 年 05 月
1
文章日历
2014 年 10 月 | ||||||
---|---|---|---|---|---|---|
日 | 一 | 二 | 三 | 四 | 五 | 六 |
29 | 30 | 31 | 01 | 02 | 03 | 04 |
05 | 06 | 07 | 08 | 09 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
27 | 28 | 29 | 30 | 31 | 01 | 02 |
文章标签
- Linux
- Go
- Yii
- 新浪
- CentOS
- PHP
- Git
- WSL
- Composer
- Mac
- 入职
- Bootstrap
- pyenv
- UCenter
- 厦门
- 出差
- 长沙
- 湖南卫视
- 微博
- Tengine
- YUI
- 泰国
- pecl
- 优化
- GitLab
- 迁移
- rootless
- 年会
- 生日
- Tengin
- RedHat
- Sphinx
- cygwin
- Windows
- Tmux
- Zsh
- 升级
- MySQL
- sql_mode
- Shadowsockets
- 面向对象
- HTTP
- 状态码
- grep
- unoconv
- PPT
- Nginx
- htpasswd
- golang