数据库CPU压力较大 高并发该如何处理?

普遍的数据库在运行中遇到高并发读写的问题,导致数据库思索或压力增大而无法访问,随即数据库的处理机制也就是所谓的并发控制,是保证并发执行事务在一定隔离级别上正确执行的机制。需要指出的是,并发控制由数据库的调度器负责,事务本身不知道。如下图所示,Scheduler将多个事务的读写请求排列成合法的序列,以便依次执行:在此过程中,对于可能破坏数据正确性的冲突事务,调度器可以选择以下两种处理方法:Delay:将某项事务推迟到合法时间。Abort:直接放弃提交事务,恢复事务可能带来的影响。可见Abort比Delay带来了更高的成本,下面我们同并发控制机制在不同情况下的处理方法。


分类。

从横向和纵向两个维度对常见的并发控制机制进行分类:一是乐观程度。不同的实现机制基于不同的冲突概率假设。悲观的方式认为,只要两个事务访问相同的数据库对象,就会发生冲突,所以要尽快阻止;乐观的方式认为冲突的概率不大,会延迟处理冲突的时间。如上图横坐标所示,乐观程度从左向右提高:基于Lock:最悲观的实现需要在操作开始前,甚至事务开始前,锁定要访问的数据库对象,对冲突操作Delay;


以Timestamp为基础:乐观实现,每项事务在开始时都会得到全局增长的时间戳,期望按开始时间戳依次执行,在操作数据库对象时检查冲突,选择Delay或Abort;以Validation为基础:更加乐观的实现,仅在Commit之前进行Validate,Abort交易冲突。可见,不同乐观程度机制的本质区别在于,检查或预测冲突的时机,Lock在事务开始时,Timestamp在运行时,Validation在最后的Commit之前。与悲观的方式相比,乐观的机制能够获得更高的并发性,而且一旦发生冲突,Abort事务也会比Delay花费更多。


2.单版VS多版。

在相同的乐观程度下,还有多版本的实现。所谓多版本,就是每次需要修改数据库对象时,生成一个新的数据版本,每个对象的多个版本共存。阅读请求可以直接访问相应版本的数据,避免读写事务和只读事务之间的堵塞。当然,多个版本也会带来不同版本的维护成本。如果需要垃圾回收机制,可以释放任何东西都看不到的版本。需要指出的是,这些并发控制机制不与具体的隔离水平相结合,通过冲突判断的不同规则可以实现不同强度的隔离水平,基于Serializable具体介绍各机制的实现方式。


基于Lock实现的Scheduler需要在事务访问数据前添加必要的锁保护。为了提高并发性,会根据实际访问情况分配不同模式的锁,常见的有读写锁、更新锁等。最简单的是,需要长时间持有锁,直到事务结束。为了尽可能在保证正确性的基础上提高并行性,数据库中常用的锁定方法称为两阶段锁(2PL)Growing阶段可以申请锁定,Shrinking阶段只能释放,即第一次锁定释放后不能再有锁定要求。需要注意的是,2PL不能解决锁定问题,所以需要有锁定检测和处理机制,通常选择锁定事务进行Abort。


Scheduler还需要与LockTable相匹配,如下图所示,它是一个可能获得LockTable信息的示意,每个被访问的数据库对象都会在LockTable中有相应的表项,其中记录了当前最高的持有锁模式,是否有事务在Delay,以及是否有事务在Delay,以及是否有事务在Delay,以及是否有事务在Delay,以及是否有任何事务在Delay,以及是否有任何事务在Delay,以及是否有任何事务在Delay,以及是否有任何事务在Delay,以及是否有任何事务在Commit或Abort之后,Scheduler会根据不同的策略唤醒等待队列中的Delay事务。

分享: