摘要:
此前做查询优化和查询执行比较多, 一般是在一个单独的事务内考虑优化查询.
最近在做并发控制方面的事情, 一些此前考虑的较少的方面需要做更为深入的思考.
并发控制和事务的特性息息相关, 直白的说就是事务的隔离性, 但是这么理解过于肤浅, 本文做一些初步的思考.
为什么需要并发控制?
一. 从资源临界区的角度理解
- 一个比较明显的点就是数据库的数据对于所有的会话都保持了内存可见性, 也就是所有的客户端会话在操作临界区的数据
- 从线程安全的角度, 对于临界区, 是要进行加锁操作, 以保持每个执行线程的内存可见性
- 即使是每个会话的执行序列都正确执行, 那么操作同一份数据也会导致两个独立的会话相互影响
二. 从事务的角度理解
- 按照八股文的说法事务的特性ACID, 这里必须保持隔离性
- 事务的目的是为了保证数据库在遇到问题的时候的安全, 引发出了ACID四个特性, 也导致了一系列的八股文
- 那么考虑下, 事务是什么? 是的，是一些列操作序列的集合, 分为读r和写w
- 那么为什么事务需要并发控制呢?
- 如果在某一时刻, 仅仅只有一个事务, 那么就没有并发, 自然不需要并发控制
- 如果在同一个时刻，有多个事务，但是这个事务，是排队执行, 也就是可串行化的隔离级别，那么这些事务也不会互相影响, 自然也不需要并发控制
- 那么为什么不把事务都做成可串行化的，一个一个排队在单个线程中执行呢？
- redis是单个线程的串行化处理的, 但是这么做有前置条件
- redis的数据主要在内存, 读和写也是在内存, 持久化是在后台的子进程单独的去处理, 所以可以理解成单个事务操作耗时极短
- 如果单个事务执行耗时过长，将会后续排队的事务造成影响
- 但是如果直接套用在AP领域或者关系型数据库领域, 就不适合，因为事务必须要保证持久性, 一个事务的完成，必须要持久化到磁盘, 这会单个事务的执行耗时有巨大的影响
- 所以一般的数据库对于单个客户端会话都采用了一个独立的线程去处理，而不是像redis那样所有的客户端的会话都只在一个线程中处理。极端的例如pg是用一个独立的进程去处理
