网站psd下载,制作网站要不要域名,Wordpress重复导入,深圳公司建立网站事务的ACID A 原子性#xff08;Atomicity#xff09; 多步骤操作#xff0c;只能是两种状态#xff0c;要么所有的步骤都成功执行#xff0c;要么所有的步骤都不执行#xff0c;举例说明就是小明向小红转账30元的场景#xff0c;拆分成两个步骤#xff0c;步骤1#…事务的ACID A 原子性Atomicity 多步骤操作只能是两种状态要么所有的步骤都成功执行要么所有的步骤都不执行举例说明就是小明向小红转账30元的场景拆分成两个步骤步骤1小明减30元。步骤2小红加30元。步骤1和2必须同时执行成功或失败不能只执行其中的一个步骤。 C 一致性Consistency 其实和原子性一样 I 隔离性Isolation 多个事务执行时不能受并发的事务的影响后面会详细的说隔离级别 D 持久性(Durability 事务一旦提交落盘后数据不会因为程序异常或断电丢失数据
隔离性
读未提交Read uncommitted读已提交Read committed可重复读Repeatable read序列化Serializable 从上到下四个级别的隔离性依次变强性能依次变差 读未提交 对应脏读在本事务的线段内会读到其他线段的中间状态。 读已提交对应不可重复读比上个好一些。该级别下不能读到其他事务的未提交状态。但如上图如果事务 t2 在执行时多次读某个记录 x 的状态在事务 t1 未启动前发现 x 2在事务 t1 提交后发现 x 3这便出现了不一致。 可重复读如上图事务 t2 在整个执行期间多次读取数据库 x 的状态无论他事务如 t1是否改变 x 状态并提交事务 t2 都不会感觉到。但是会存在幻读的风险。怎么理解呢最关键的原因在于写并发。因为读不到不代表其他事务的影响不存在。比如事务 t2 开始时通过查询发现 id “qtmuniao” 的记录为空于是创建了 id“qtmuniao” 的记录然而在提交时发现报错说该 id 已经存在。这可能是因为有一个开始的比较晚的事务 t2也创建了一个 id“qtmuniao” 的记录但是先提交了。于是用户就郁闷了明明你说没有但我写又报错难道我出现幻觉了这就太扯淡了但是此级别就只能做到这样了。反而因为兼顾了性能和隔离性他是大多数据库的默认级别。 序列化最简单的实现办法就是一把锁来串行化所有的事务boltdb就是这么做的。badgerdb在此基础上如果能提高并发做很多优化。
badger 的序列化SSI
badgerdb 的事务主要依靠多个tnx结构体和全局的一个oracle结构体来维护
type Txn struct {readTs uint64commitTs uint64
}type oracle struct {nextTxnTs uint64
}
每一个txn都有readTs和commitTs 其中全局的o.nextTxnTs只有获得提交时间戳的时候才加1如果多个事务并发任何一个事务都还没有提交的时候这些事务获得的readTs 是一样的 var readTs uint64o.Lock()readTs o.nextTxnTs - 1//txn 的readTso.readMark.Begin(readTs)o.Unlock()ts o.nextTxnTso.nextTxnTs//事务获得了提交时间后再把nextTxnTs1o.txnMark.Begin(ts)
创建一个事务的时候要进行授时txn.readTs db.orc.readTs()这个时间是一个递增的序列接下来主要来分析一下db.orc.readTs()这个函数获得readTs后会等待readTs这个时间戳提交的事务彻底写入LSM tree后才返回保证了不会脏读不会读到其他未提交的事务和不可重复读
func (o *oracle) readTs() uint64 {if o.isManaged {panic(ReadTs should not be retrieved for managed DB)}var readTs uint64o.Lock()readTs o.nextTxnTs - 1o.readMark.Begin(readTs)o.Unlock()// Wait for all txns which have no conflicts, have been assigned a commit// timestamp and are going through the write to value log and LSM tree// process. Not waiting here could mean that some txns which have been// committed would not be read.y.Check(o.txnMark.WaitForMark(context.Background(), readTs))return readTs
}
badgerdb 解决幻读
在上文描述的可重复读出现的幻读badgerdb解决幻读和不可重复读的方法就是事务t2放弃提交给用户层返回ErrConflict错误让用户层稍后再试。
先找到代码中报ErrConflict的地方是获取CommitTs的时候报的错误
func (txn *Txn) commitAndSend() (func() error, error) {orc : txn.db.orc// Ensure that the order in which we get the commit timestamp is the same as// the order in which we push these updates to the write channel. So, we// acquire a writeChLock before getting a commit timestamp, and only release// it after pushing the entries to it.orc.writeChLock.Lock()defer orc.writeChLock.Unlock()commitTs, conflict : orc.newCommitTs(txn)if conflict {return nil, ErrConflict}
}进去看orc.newCommitTs(txn)
func (o *oracle) newCommitTs(txn *Txn) (uint64, bool) {o.Lock()defer o.Unlock()if o.hasConflict(txn) {return 0, true}
}再看o.hasConflict(txn) txn.reads 是被txn.addReadKey进行修改的 committedTxn.conflictKeys 是txn.modify() 修改的txn.modify()是txn.Set或txn.Detele调用的 总结下来就是当前事务如果读过的key在当前事务的readTs后有在其他的事务对这些读到过的key做过修改那么本次事务就是有冲突的
// hasConflict must be called while having a lock.
func (o *oracle) hasConflict(txn *Txn) bool {if len(txn.reads) 0 {return false}for _, committedTxn : range o.committedTxns {// If the committedTxn.ts is less than txn.readTs that implies that the// committedTxn finished before the current transaction started.// We dont need to check for conflict in that case.// This change assumes linearizability. Lack of linearizability could// cause the read ts of a new txn to be lower than the commit ts of// a txn before it (mrjn).if committedTxn.ts txn.readTs {continue}for _, ro : range txn.reads {if _, has : committedTxn.conflictKeys[ro]; has {return true}}}return false
}
