TiKV采用了GooglePercolator这篇论文中所述的事务模型，我们在《TiKV事务模型概览》和《DeepDiveTiKV-Percolator》中都对该事务模型进行了讲解。为了更好的理解接下来的内容，建议大家先阅读以上资料。
大家可以看到，本质上TiKV的事务模型是基于Percolator的思想，但是对比原论文，做了很多工程上的优化，我们将原来论文中的L列和W列去掉，通过和MVCC的Meta来存储相关的事务信息。
论文中，TiDB选择的是方案2，针对OLTP工作负载提供一个行存引擎TiKV，针对OLAP工作负载负载提供一个列存引擎TiFlash，那么数据强一致性和资源相互隔离怎么解决呢？一般来说，对于一个分布式存储系统，数据强一致性和资源相互隔离经常是...
我是如何低效的看TiKV代码的（一）先从TiDB说起TiDB是什么首先引用一下官方的定义：TiDB是PingCAP公司受GoogleSpanner/F1论文启发而设计的开源分布式HTAP(HybridTransactionalandAnalyticalProcessing)数据库，结合了传统的...
FoundationDB在2PC时的容错怎么做的，没找到相关文档，percolator论文中说的很清楚，略。事务检测：TiKV检测在各个TiKV节点上，FoundationDB拎了一个单独的叫做resolver的组件出来做检测，这个组件可以有多个，组件会把最近5s的已经提交...
通过论文以及简单的介绍，我们基本熟悉了主流的几个分布式数据库系统以及基本分布式一致性原理，算是正式进入到TiKV的世界。第二三周开始深入学习TiKV，从基本的Read/WriteFlow解析到TiKV的部署以及性能测试，同时穿插学习Raft基本原理、MultiRaft实现原理以及Percolator事务模型。
TiKV中对Percolator的实现与论文中稍有差别。在TiKV中，CF_WRITE中有4中不同的类型的数据：Put，CF_DEFAULT中有一条对应的数据，写入操作是一个Put操作；Delete，表示写入操作是一个Delete操作；Rollback，当回滚一个事务的时候，我们不是简单...
TiKV选择Range的方式分片，将整个Key-Value空间分成很多段，每一段是一系列连续的Key，将每一段叫做一个Region，并且会尽量保持每个Region中保存的数据不超过一定的大小，目前在TiKV中默认是96MB。TiKV通过Range分片的方式，可以使得...
论文中，TiDB选择的是方案2，针对OLTP工作负载提供一个行存引擎TiKV，针对OLAP工作负载负载提供一个列存引擎TiFlash，那么数据强一致性和资源相互隔离怎么解决呢？
在Percolator的原始论文中的展现形式是在BigTable中支持跨行事务,事务本身提供RepeatableRead级别的隔离性,也就是我们平时说的快照级别隔离[5]。其实就其本质...
TiKV,TiDB中大量参考了Google论文中的相关内容,吸收了本质原理,排除无用东西。Percolator论文中介绍Percolator是一个大型系统,其中使用了上述的主从锁来解决...
上面简单的介绍了源码解析涉及的模块,还有一些模块譬如https://github/tikv/client-rust仍在开发中,等完成之后我们也会进行源码解析。我们希望通过该源码解析系列,能让大家对T...
对应Percolator论文中的这一步:if(T.Read(w.row,c+"lock",[0,∞]))returnfalse;在TiKV的代码中,如果发现该key被同一个事务上了锁(即lock.ts==self.star...
这里需要注意,TiKV以及etcd对于membershipchange的处理,跟Raft论文是稍微有一点不一样的,主要在于TiKV的membershipchange只有在logapplied的时候生效,这样主要的目的...
TiKV是一个分布式事务型的键值数据库,提供了满足ACID约束的分布式事务接口,并且通过Raft协议保证了多副本数据一致性以及高可用。TiKV作为TiDB的存储层,为用户写入TiDB的数据提供了持久...