TiKV 是一个开源的分布式事务 Key-Value 数据库，支持跨行 ACID 事务，同时实现了自动水平伸缩、数据强一致性、跨数据中心高可用和云原生等重要特性。作为一个基础组件，TiKV 可作为构建其它系统的基石。目前，TiKV 已用于支持分布式 HTAP 数据库—— TiDB 中，负责存储数据，并已被多个行业的领先企业应用在实际生产环境。2019 年 5 月，CNCF 的 TOC（技术监督委员会）投票决定接受 TiKV 晋级为孵化项目。
· 源码地址：https://github.com/tikv/tikv
· 更多技术信息：https://tikv.org
特性
- 跨数据中心高可用：使用 Raft 协议和 PD（Placement Driver）来实现跨地域、跨数据中心的高可用。
- 水平扩展：通过 PD 和精心实现的 Multi-Raft ，TiKV 在水平扩展性方面的表现出色，可以轻松扩展到 200+TB 的数据。
- 一致的分布式事务 ：与 Google Spanner 类似，TiKV 支持外部一致的分布式事务。
协处理器（Coprocessor）支持：与 HBase 类似，TiKV 实现了支持分布式计算的协处理器框架，用于支持计算下推操作。
-
与 TiDB 无缝协同 ：TiKV 和 TiDB 强强联合，构建了一个具有高水平扩展能力、支持一致性事务、融合传统关系型数据库和 NoSQL 优势特性的 NewSQL 数据库解决方案。
架构
架构详解请点 这里 查看
TiKV 与 CNCF
2018 年 8 月 29 日，云原生计算基金会（Cloud Native Computing Foundation，简称 CNCF）宣布接纳 TiKV 作为 CNCF Sandbox 的云原生项目。
2019 年 5 月，CNCF 的 TOC（技术监督委员会）投票决定接受 TiKV 晋级为孵化项目。
-
TiKV Control（以下简称 tikv-ctl）是 TiKV 的命令行工具，用于管理 TiKV 集群。它的安装目录如下： 如果是使用 TiUP 部署的集群，在 ~/.tiup/components/ctl/{VERSION}/ 目录下。 通过 TiUP 使用 TiKV Control 注意 建议使用的 Control 工具版本与集群版本保持一致。 tikv-ctl 也集成在了 tiup 命令
-
本文主要介绍 TiKV 线程池性能调优的主要手段，以及 TiKV 内部线程池的主要用途。 线程池介绍 在 TiKV 中，线程池主要由 gRPC、Scheduler、UnifyReadPool、Raftstore、StoreWriter、Apply、RocksDB 以及其它一些占用 CPU 不多的定时任务与检测组件组成，这里主要介绍几个占用 CPU 比较多且会对用户读写请求的性能产生影响的线程池。
-
TiKV 的命令行参数支持一些可读性好的单位转换。 文件大小（以 bytes 为单位）：KB, MB, GB, TB, PB（也可以全小写） 时间（以毫秒为单位）：ms, s, m, h -A, --addr TiKV 监听地址。 默认："127.0.0.1:20160" 如果部署一个集群，--addr 必须指定当前主机的 IP 地址，例如 "192.168.100.113:20160"，如果是运
-
ShardingSphereTransactionManager SPI 名称 详细说明 ShardingSphereTransactionManager 分布式事务管理器 已知实现类 详细说明 XAShardingSphereTransactionManager 基于 XA 的分布式事务管理器 SeataATShardingSphereTransactionManager 基于 Seata 的分
-
ShardingSphere-Proxy 接入的分布式事务 API 同 ShardingSphere-JDBC 保持一致，支持 LOCAL，XA，BASE 类型的事务。 XA 事务 ShardingSphere-Proxy 原生支持 XA 事务，默认的事务管理器为 Atomikos。 可以通过在 ShardingSphere-Proxy 的 conf 目录中添加 jta.properties 来定
-
通过 Apache ShardingSphere 使用分布式事务，与本地事务并无区别。 除了透明化分布式事务的使用之外，Apache ShardingSphere 还能够在每次数据库访问时切换分布式事务类型。 支持的事务类型包括 本地事务、XA事务 和 柔性事务。可在创建数据库连接之前设置，缺省为 Apache ShardingSphere 启动时的默认事务类型。
-
背景 数据库事务需要满足 ACID（原子性、一致性、隔离性、持久性）四个特性。 原子性（Atomicity）指事务作为整体来执行，要么全部执行，要么全不执行。 一致性（Consistency）指事务应确保数据从一个一致的状态转变为另一个一致的状态。 隔离性（Isolation）指多个事务并发执行时，一个事务的执行不应影响其他事务的执行。 持久性（Durability）指已提交的事务修改数据会被持久
-
单文档原子性可满足大多数业务需求 在 MongoDB 中，对单个文档的操作是原子操作。 由于 MongoDB 文档数据模型，一个文档中通过嵌入式的文档和数组来表示传统关系数据库模型中的一对一、一对多关系，而不是通过文档之间的复杂关系来描述业务需求中的一对一、一对多关系。 所以单文档原子性可以满足实际生产中大多数关于事务的需求。 对于需要对多个文档（在单个或多个集合中）进行原子读写的情况，Mongo
-
在很多情况下，日志内容本身都是一个类似于 key-value 的格式，但是格式具体的样式却是多种多样的。logstash 提供 filters/kv 插件，帮助处理不同样式的 key-value 日志，变成实际的 LogStash::Event 数据。 配置示例 filter { ruby { init => "@kname = ['method','uri','verb'
-
两阶段提交协议 通常在复杂场景下是不推荐使用的，除非是非常简单的场景，非常容易提供回滚，而且依赖的服务也非常少的情况。 这种实现方式会造成代码量庞大，耦合性高。而且非常有局限性，因为有很多的业务是无法很简单的实现回滚的，如果串行的服务很多，回滚的成本实在太高。 本地消息表 这种实现方式的思路，其实是源于ebay，后来通过支付宝等公司的布道，在业内广泛使用。其基本的设计思想是将远程分布式事务拆分成一
-
分布式事务基于 JTA/XA 规范实现 1。 两阶段提交： 1. 本功能暂未实现 ↩