TiKV

- 起源 - Raft协议起源于 2013 年 斯坦福 Diego Ongaro和John Ousterhout的论文《In Search of an Understandable Consensus Algorithm》。作者表示因为Paxos 晦涩难懂且缺乏工程实现，所以要设计个既容易实现又利于学生学习的一致性算法。Raft 的数据一致性等价于 Multi Paxos，可以用于取代Paxos，并且证明可以提供与Paxos相同的容错性以及性能。 Raft协议是一种基于日志复制的一致性算法，通过选举领袖的方式来实现的。Raft协议设计首要目标是易于理解，所以采用了分解法（Raft流程可分解为选主、日志复制和安全）和状态空间简化（相较于 Paxos，Raft 减少了未定状态的数量）。 - 节点状态 - 在Raft集群里，服务器可能会是这三种身份其中一个： Leader (领袖者)：所有请求的处理者，Leader 接受 client的更新请求，本地处理后再同步至多个其他节点； Follower (追随者) ：请求的被动更新者，从Leader接受更新请求，然后写入本地日志文件 Candidate (候选人) ：节点处于候选状态，正在竞选 Leader。 在正常情况下只会有一个领袖者节点，其他都是追随者节点。而领袖节点会负责所有外部的请求，如果是 非领袖节点收到 时，请求会被 转发 到

前言 前面三章基本把 TiDB 的环境弄好了，也做了一下简单测试，有兴趣的同学可以看一下： TiDB 入门（一）：TiDB 简介 TiDB 入门（二）：虚拟机搭建 TiDB-Ansible 部署方案 TiDB 入门（三）：简单测试 本来还有一些用 jmeter 压力测试的，后来测试的结果非常不好，就不想写出来了，因为自己毕竟是用虚拟机模拟的和 TiDB 官网推荐的配置差很多，如果自己写出来是有失偏颇的。 为何“跑路” 穷 我们可以看到，TiDB 对性能要求特别高，简单看一下配置。参考： 软硬件要求 开发测试环境: 组件 CPU 内存 本地存储 网络 实例数量(最低要求) TiDB 8 核 16 GB+ 无特殊要求 千兆网卡 1（可与 PD 同机器 PD 4 核+ 8 GB+ SAS, 200 GB+ 千兆网卡 1（可与 TiDB 同机器 TiKV 8 核 32 GB+ SSD, 200 GB+ 千兆网卡 3 生产环境： 组件 CPU 内存 硬盘类型 网络 实例数量(最低要求) TiDB 16 核+ 32 GB+ SAS 万兆网卡（2 块最佳） 2 PD 4 核+ 8 GB+ SSD 万兆网卡（2 块最佳） 3 TiKV 16 核+ 32 GB+ SSD 万兆网卡（2 块最佳） 3 监控 8 核+ 16 GB+ SAS 千兆网卡 1 开发环境大概就需要两台 DELL 服务器才能满足

TiDB也使用了一段时间，持续记录一些日常，防止大家也踩到同样的坑~ 🥕 raft sync-log 目前,公司使用的Tidb分别部署在生产环境和测试环境，生产环境的是在阿里云，而测试环境是在公司的机房。周末的时候，机房不知道为啥断过电，什么都不知道的我，周一来到公司发现测试环境的Tidb挂了（这是肯定的，因为停过电嘛~），然后就是怎么都启动不了，相当崩溃。一查日志发现： 下面是raft的介绍: 经过分析，得出原因应该是raft在做副本的时候出了问题。测试环境是3个kv示例，那每条数据将会有2个node去持有。node1已经将raft-log写入磁盘，而node2在写入时，发生了断电，导致node1，node2的服务和磁盘都挂掉，造成了raft日志出错。 避免这样的问题，可以设置参数（类似mysql的 innodb_flush_log_at_trx_commit ），保证每个数据的提交都能落地。不过这样就会降低性能。 联系了Tidb的开发人员，处理该情况的工具还没有完善（该问题已有 issues ），没办法删掉出错的数据，因为测试环境的数据量比较大，迁移出来太费时，还好数据不是很重要，清理了数据就可以启动了。当时Tidb的版本如下： 所以小伙伴们在部署Tidb的时候要考量是否可能出现同时挂掉的可能（虽然概率不大），尤其是对于一些关键的业务，需要更多的考虑，比如更多的副本

TiDB Hackathon 是由 TiDB 社区主办，专属于全球开发者与技术爱好者的顶级挑战赛事，通过开发与应用实战，鼓励开发者基于 TiDB 及上下游生态项目实现技术与商业创新。 自 2017 年创办以来，TiDB Hackathon 在过去的三年连获好评，吸引了全球 800+ 技术爱好者参与，先后诞生了 Unified Threat Pool、TiDB-wasm、TiDB 跨数据中心解决方案等一些列高质量项目，已经成为全球数据库技术领域的知名赛事。 本届大赛主题为「∞」，参赛项目可围绕 TiDB 组件或结合 TiDB 生态周边（包括：TiKV、ChaosMesh®、Backup & Restore（BR）、TiDB Data Migration（DM）、Dashboard、Flink、ES 等上下游社区、用户&企业业务场景等）进行创作，用最硬核的技术和最炸裂的创意去创造无限可能。 赛事亮点 奖金加码： 除了金额丰厚的一二三等奖，本次大赛还将联合赞助商推出特别奖，以及增设最佳人气奖，欢迎小伙伴们围观 Demo 现场投出你心中最佳的项目。 全球联动： 去年北上广三地联动 Demo 的场景还历历在目，今年 TiDB 将更进一步，联动全球开发者共享代码狂欢。 项目落地： 通过 TOC（Technical Oversight Committee） 投票表决的优秀项目将在大赛结束后进入

本文是《剖析Spark数据分区》系列文章的第三篇，本篇我们将分析Spark streaming，TiSpark中的数据分区。 系列一： 剖析Spark数据分区之Hadoop分片 系列二： 剖析Spark数据分区之Spark RDD分区 1. Kafka +Spark Streaming 图 1 Spark Streaming从Kafka接收数据，转换为Spark Streaming中的数据结构DStream即离散数据流。 数据接收方式有两种： 1)使用Receiver接收的旧方法； 2)使用Direct拉取的新方法 （Spark 1.3引入） ； 1）Receiver方式 当前spark已经 不支持 该模式。 图 2 receiver模式的 并行度 由spark.streaming.blockInterval决定，默认是200ms。 receiver模式接收block.batch数据后会封装到RDD中，这里的block对应RDD中的partition。 batchInterval一定的情况 下： 减少 spark.streaming.Interval参数值，会 增大 DStream中的partition个数。 建议spark.streaming.Interval 最低不能低于50ms 。 2）Direct方式 图 3 Spark会创建跟Kafka partition一样多的RDD

在过去的12个月中，广泛使用的数据存储解决方案已经有200位不同的贡献者 旧金山，加利福尼亚州--2020年11月24日-- CNCF®（云原生计算基金会，Cloud Native Computing Foundation®），旨在为云原生软件构建可持续的生态系统，今天宣布etcd毕业。从孵化到毕业阶段，etcd已经被越来越多的人采用、拥有开放的治理过程、特性成熟度，以及对社区、可持续性和包容性的强烈承诺。 etcd 是分布式的、可靠的键值存储，它提供了可靠的方式来存储需要由分布式系统或机器集群访问的数据。任何复杂的应用程序，从简单的web应用程序到Kubernetes，都可以从etcd读取数据并将数据写入其中。该项目于2013年在CoreOS创建，并于2018年12月作为孵化项目加入CNCF。 https://etcd.io/ “etcd项目是Kubernetes内部的关键组件，其他许多项目都依赖etcd来实现可靠的分布式数据存储。”CNCF CTO Chris Aniszczyk说：“我们对etcd在规模上持续达到的里程碑和在最近的保安审计上的成熟处理方式留下深刻印象，我们期待其作为毕业项目培育社区。” etcd被 许多公司 用于生产，包括阿里巴巴、亚马逊、百度、思科、EMC、谷歌、华为、IBM、红帽、Uber、Verizon等，以及Kubernetes、CoreDNS、M3

云原生键值数据库项目在全球拥有近1000家生产用户 旧金山，加利福尼亚州-2020年9月2日- CNCF®（Cloud Native Computing Foundation®，云原生计算基金会）为云原生软件构建可持续的生态系统，今天宣布TiKV是第12个毕业的项目。从孵化阶段到毕业阶段，TiKV被越来越多的人采用，拥有一个开放的治理过程，特性成熟，以及对社区、可持续性和包容性的坚定承诺。 TiKV是一个以Rust编写的开源分布式事务键值数据库。它提供具有ACID保证的事务性键值API。项目为需要数据持久性、水平可伸缩性、分布式事务、高可用性和强一致性的应用程序提供了统一的分布式存储层，使其成为下一代云原生基础设施的理想数据库。 “TiKV是我们第一个基于Rust的项目，它是一个真正灵活和可扩展的云原生键值存储。”CNCF CTO/COO Chris Aniszczyk说：“自项目加入CNCF以来，我们对项目的成长及培育全球开源社区的愿望印象深刻。” 自2018年8月加入CNCF以来，在生产中采用TiKV的公司增加了一倍，达到了1000家，横跨多个行业，核心仓库的贡献者从78位增加到226位。维护团队目前有7人，所代表的企业分布健康，包括PingCAP、知乎、京东云、一点资讯等。 PingCAP 首席工程师、TiKV 项目负责人唐刘表示：“开源已经成为全球基础软件发展的重要方向

今天主要是想把我们 TiDB 做 SQL 性能优化的一些经验和一些思考，就此跟大家探讨一下。题目写的比较大，但是内容还是比较简单。我们做 TiDB 的 SQL 层时，一开始做的很简单，就是通过最简单的 KV 接口(Get/Set/Seek)去存数据、取数据，做一些非常直白、简单的计算。然而后来我们发现，这个方案在性能上不可接受，可能行不通，我们就重新思考了这个事情。 TiDB 的目标是做一个 NewSQL 的 database ，什么是 NewSQL？从 Wikipedia 上我们看到 NewSQL 的定义『NewSQL is a class of modern relational database management systems that seek to provide the same scalable performance of NoSQL systems for online transaction processing (OLTP) read-write workloads while still maintaining the ACID guarantees of a traditional database system.』。首先NewSQL Database 需要能存储海量数据，这点就像一些 NoSQL 数据库一样。然后，能够提供事务的功能。所以

作者介绍：陈振东，北京银行软件开发部 北京银行是一家城市商业银行，公司价值位列中国区域性发展银行的首位，依托于中国经济的大环境，北京银行的资产总量在全球千家大银行中名列第 61 位，连续六年跻身全球银行业百强。北京银行积极开辟多元化的业务经营，例如北京地区的社保缴纳和医保代发，都是由北京银行在提供服务，在你入职一家公司的时候，收到的医保折子就是来自北京银行。 业务转型驱动分布式架构建设 由于快速的业务发展需求，北京银行在业务转型中对系统架构进行了升级，逐渐向分布式架构进行转移。早在 2016 年，北京银行就开始了对分布式数据库的探索，并于 2018 年正式投产上线了 TiDB 分布式数据库，当时在业内还没有一个比较完善与成熟的体系，我们也是根据银行的安全合规需求建设了两地三中心的部署方案。 如上图所示，在两地三中心部署了 TiDB 分布式数据库集群，采用主从的多活架构，主集群作为生产集群承担日常的生产服务，从集群是建设在西安的异地灾备中心，主从之间是用 Kafka 同步 Binlog 形式进行数据的同步。 在这两年的建设过程中，北京银行与 PingCAP 进行专项的深度合作，这里简单介绍三个方面： 两地三中心 ：在两地三中心的部署方案中，异地中心的网络延时会对整个集群的性能产生较大影响，我们在这层面上对 gRPC 的消息格式进行了压缩，同时利用 Multi-Raft

参考文章： 日均数据量千万级，MySQL、TiDB 两种存储方案的落地对比 盖 娅广告匹配系统（GaeaAD）用于支撑盖娅互娱全平台实时广告投放系统，需要将广告数据和游戏 SDK 上报的信息进行近实时匹配，本质上来说需要实时的根据各个渠道的广告投放与相应渠道带来的游戏玩家数据进行计算，实现广告转化效果分钟级别的展现及优化。 初期的 MySQL 存储方案 在系统设计之初，基于对数据量的预估以及简化实现方案考虑，我们选用了高可用的 MySQL RDS 存储方案，当时的匹配逻辑主要通过 SQL 语句来实现，包含了很多联表查询和聚合操作。当数据量在千万级别左右，系统运行良好，基本响应还在一分钟内。 遭遇瓶颈，寻找解决方案 然而随着业务的发展，越来越多游戏的接入，盖娅广告系统系统接收数据很快突破千万/日，高峰期每次参与匹配的数据量更是需要翻几个番，数据库成为了业务的瓶颈。由于此时，整个技术架构出现了一些问题： 1. 单次匹配耗时已从原本的 10 秒左右增加到 2 分钟以上，最慢的聚合查询甚至达到 20 分钟，时效性受到严重挑战。而且 MySQL 的问题是查询的时间随着数据量的增长而增长，以至于数据量越大的情况下查询越慢。 2. 随着历史数据的积累，单表数据很快达到亿级别，此时单表的读写压力已经接近极限。 3. 由于第一点提到的查询性能问题以及单机的容量限制，需要定时删除数据