事务
概念
Transaction
事务：一个最小的不可再分的工作单元；通常一个事务对应一个完整的业务(例如银行账户转账业务，该业务就是一个最小的工作单元)
一个完整的业务需要批量的DML(insert、update、delete)语句共同联合完成
事务只和DML语句 ( 数据库操作语句 ) 有关，或者说DML语句才有事务。这个和业务逻辑有关，业务逻辑不同，DML语句的个数不同
特性
▧ 原子性(A) 事务是最小单位，不可再分
▧ 一致性(C) 事务要求所有的DML语句操作的时候，必须保证同时成功或者同时失败
▧ 隔离性(I) 事务A和事务B之间具有隔离性
▧ 持久性(D) 是事务的保证，事务终结的标志(内存的数据持久到硬盘文件中)
行为
▧ 开启事务 Start Transaction
▧ 事务结束 End Transaction
▧ 提交事务 Commit Transaction
▧ 回滚事务 Rollback Transaction
标志
开启标志
任何一条DML语句(insert、update、delete)执行，标志事务的开启
结束标志
▧ 提交 成功的结束，将所有的DML语句操作历史记录和底层硬盘数据来一次同步
▧ 回滚 失败的结束，将所有的DML语句操作历史记录全部清空
代码库
Django 自带的代码库
from django.db import transaction
使用
方式一, 直接使用将一段操作设置为事务
with transaction.atomic():
...
方式二, 装饰器方式
@transaction.atomic
def foo():
....
悲观锁
概念
总是假设最坏的情况，每次取数据时都认为其他线程会修改，所以都会加锁（读锁、写锁、行锁等)
当其他线程想要访问数据时，都需要阻塞挂起。可以依靠数据库实现，如行锁、读锁和写锁等，都是在操作之前加锁
保证同一时刻只有一个线程能操作数据，其他线程则会被 block
运用场景
▧ 无脏读 上锁数据保证一致, 因此无脏读, 对脏读不允许的环境悲观锁可以胜任
▧ 无并行 悲观锁对事务成功性可以保证, 但是会对数据加锁导致无法实现数据的并行处理.
▧ 事务成功率高 上锁保证一次成功, 因此在对数据处理的成功率要求较高的时候更适合悲观锁.
▧ 开销大 悲观锁的上锁解锁是有开销的, 如果超大的并发量这个开销就不容小视, 因此不适合在高并发环境中使用悲观锁
▧ 一次性完成 如果乐观锁多次尝试的代价比较大，也建议使用悲观锁, 悲观锁保证一次成功
实例
from django.shortcuts import render
from django.http import HttpResponse
from django.views.generic import View
from django.db import transaction
from 应用名.models import 模型类名 # 类视图 (并发，悲观锁)
class MyView(View): @transaction.atomic
def post(self, request):
# select * from 表名 where id=1 for update;
# for update 就表示锁,只有获取到锁才会执行查询,否则阻塞等待。
obj = 模型类名.objects.select_for_update().get(id=1) # 等事务提交后，会自动释放锁。 return HttpResponse('ok')
乐观锁
概念
总是认为不会产生并发问题，每次去取数据的时候总认为不会有其他线程对数据进行修改，因此不会上锁
但是在更新时会判断其他线程在这之前有没有对数据进行修改，一般会使用版本号机制或CAS操作实现。
如果发现数据被改了. 就进行事务回滚取消之前的操作
运用场景
▧ 脏读 乐观锁不涉及到上锁的处理, 因此在数据并行需求的时候是更适合乐观锁,当然会产生脏读, 不过用回滚取消掉了.
▧ 高并发 相比起悲观锁的开销, 乐观锁也是比悲观锁更适合于高并发场景
▧ 事务成功率低 乐观锁不能保证每次事务的成功, 是使用回滚方式来保证数据一致性, 因此会导致事务成功率很低.
▧ 读多写少 乐观锁适用于读多写少的应用场景，这样可以提高并发粒度
▧ 开销小 可能会导致很多次的回滚都不能拿到正确的处理回应, 因此如果对成功性要求低,而且每次开销小比较适合乐观锁
实例
from django.shortcuts import render
from django.http import JsonResponse
from django.views.generic import View
from django.db import transaction
from 应用名.models import GoodsSKU # 类视图 (并发，乐观锁)
class MyView(View): @transaction.atomic
def post(self, request):
'''订单创建'''
count = 3 # 订购3件商品 # 设置事务保存点
s1 = transaction.savepoint() # 乐观锁，最多尝试5次
for i in range(5):
# 查询商品的信息(库存)
try:
sku = GoodsSKU.objects.get(id=1)
except:
# 商品不存在
transaction.savepoint_rollback(s1)
return JsonResponse({'res': 1, 'errmsg': '商品不存在'}) # 判断商品的库存
if count > sku.stock:
transaction.savepoint_rollback(s1)
return JsonResponse({'res': 2, 'errmsg': '商品库存不足'}) # 更新商品的库存和销量
orgin_stock = sku.stock # 原库存 (数据库隔离级别必须是Read Committed；如果是Repeatable Read,那么多次尝试读取的原库存都是一样的,读不到其他线程提交更新后的数据。)
new_stock = orgin_stock - count # 更新后的库存
new_sales = sku.sales + count # 更新后的销量 # update 商品表 set stock=new_stock, sales=new_sales where id=1 and stock = orgin_stock
# 通过where子句中的条件判断库存是否进行了修改。(并发，乐观锁)
# 返回受影响的行数
res = GoodsSKU.objects.filter(id=1, stock=orgin_stock).update(stock=new_stock, sales=new_sales)
if res == 0: # 如果修改失败
if i == 4:
# 如果尝试5次都失败
transaction.savepoint_rollback(s1)
return JsonResponse({'res': 3, 'errmsg': '下单失败'})
continue # 再次尝试 # 否则更新成功
# 跳出尝试循环
break # 提交事务
transaction.savepoint_commit(s1) # 返回应答
return JsonResponse({'res': 4, 'message': '创建成功'})