购买域名之后怎么做网站,中国建设人才网信息网证书是假的吗,简单html网页代码,罗湖商城网站建设哪家服务周到分布式事务
下面一个事务 里面有两个更新,分别将id1的Tom改为Jack,将id2的zhangsan 改为 lisi。在MySQL中这个事务很普通#xff0c;但是在分布式数据库TiDB 中的会遇到什么问题呢#xff1f;
begin;
(1,Tom) -- (1,Jack)
(2,zhangsan) -- (2,lisi)
commit;
比如(…分布式事务
下面一个事务 里面有两个更新,分别将id1的Tom改为Jack,将id2的zhangsan 改为 lisi。在MySQL中这个事务很普通但是在分布式数据库TiDB 中的会遇到什么问题呢
begin;
(1,Tom) -- (1,Jack)
(2,zhangsan) -- (2,lisi)
commit;
比如(1,‘Tom’) 存储在一个TiKV中 (2,zhangsan)存储在另一个TiKV中
当我完成修改操作(1,‘Tom’) -- (1,‘Jack’) 数据所在的TiKV并提交后存储(2,zhangsan)的TiKV不可用了这样就出现了一个事务中一部分提交修改持久化一部分未提交的状况破坏了事务的原子性。
TiDB采用Google的模型解决这个问题
分布式事务在TiKV的存储 通过一个只修改一行的事务了解事务是如何存储在TiKV中的 。
事务流程
begin; 从PD中获取事务开始的时间戳 start_ts
接下来会把修改的数据读取到内存中
commit;两阶段提交 第一阶段 prewrite阶段写两个CF, 分别为default CF 和 Lock CF。将内存中修改的数据写入到TiKV节点中 将锁信息写入到TiKV节点中。第二阶段 commit阶段从PD中获取事务结束的时间戳commit_ts。
乐观锁在提交commit的时候将锁信息写入到TiKV ,其他会话感知不到
悲观锁将锁信息提前写入到TiKV中其他会话可以感知到。
目前讨论的按乐观锁讨论
事务是如何存储在TiKV上
事务中TiKV节点会有三个CF 分别存储为
① default CF 存储修改的数据put 3_100,Frank 在 (ID_时间戳修改的新值)只存储修改的新值因为新数据永远在上面
put 3_100,Frank 修改
put 3_100,Frank 插入
delete 3_100,Frank 删除
② Lock CF 存储锁信息 只给事务修改的第一行加一把主锁 其他修改的行指向主锁。
锁结构3,(w,pk,3,100,...) w代表写锁pk代表主键3 代表key? ,100代表开始时间戳
③ 在Write CF中 写入 提交信息 commit 之后 两阶段提交的第二阶段
3_110,100 业务ID_提交时间,事务开始时间
然后写入 锁信息的清理不是删除 LOCK CF中数据而是插入一条数据 例如
3,(D,pk,3,100,...) D 代表删除 write CF 不单单会记录提交信息 当这一行的数据长度小于255字节时 还能写数据的修改。
分布式事务在TiKV的实现
分布式事务解决的关键点只给修改的第一行加一把主锁 其他行加的是锁的指向 指向第主锁 。分布式事务原子性取决于主锁。 put 1_100,Jack 业务id_事物开始的时间戳
1,(W,pk,1,100...) 只给修改的第一行加一把主锁 其他行加的是锁的指向 指向第主锁 put2_100,Candy
2,(w,1,2,100...) 存储的是锁的指向指向的是主锁。 MVCC
如果需要修改很多数据这些数据在修改期间都不能读写那严重影响了数据库系统的并发性。
解决上面的方法 写确实不能再写了因为这些数据在修改。但是可以读。
其他数据库也有MVCC。
