TiKV

某厂面试归来，发现自己落伍了！>>> TiDB 挑战赛第二季之 易用性挑战赛 已经开始一周了，由于有参加过上一季 性能挑战赛 的老玩家强势加入，这一季挑战赛的竞争格外激烈，短短一周的时间，已有 3 支队伍获得了上千积分！ 完整积分排行榜可以登陆 活动官网 查看。 战况简介： BABAIsWatchingYou Team 通过 改进 Rust-Prometheus 中 Thread Local Metrics 的易用性 获得 2530 分。 niedhui Team 通过 为 TiDB-Dashboard 增加 TLS 支持 获得 1680 分。 hawking&chacha Team 通过 为 RocksDB WAL 写延迟增加监控 获得了 1300 分。 .* Team 通过 使用单独的日志文件存储 TiKV 慢查询日志 获得了 950 分。 羡慕不如行动！我们也在这里简单分享一些捞分技巧，希望能够帮助大家快速上手，追上这些排名靠前的参赛选手们。 捞分技巧 1：用户投票结果中排名前三的需求有高额加分！ 为鼓励大家选择用户呼声更高的任务，本次挑战赛中用户投票排名前三的需求对应的任务，会在原有积分的基础上分别额外增加 10000、8000、6000 分。比如这个排名第三的需求： record access statistics of databases, tables and

出处 ： PingCAP 微信公众号 翻译 ： Rust中文社区翻译小组 原文 ： The Rust Compilation Model Calamity 原作者 ： Brian Anderson 是 Rust 编程语言及其姊妹项目 Servo Web 浏览器的共同创始人之一。他目前在 PingCAP 担任高级数据库工程师。 Rust 编译缓慢的根由在于语言的设计 我的意思并非是此乃 Rust 语言的设计目标。正如语言设计者们相互争论时经常说的那样，编程语言的设计总是充满了各种权衡。其中最主要的权衡就是：运行时性能和编译时性能。而 Rust 团队几乎总是选择运行时而非编译时。 因此，Rust 编译时间很慢。这有点让人恼火，因为 Rust 在其他方面的表现都非常好，唯独 Rust 编译时间却表现如此糟糕。 Rust 与 TiKV 的编译时冒险：第 1 集 在 PingCAP，我们基于 Rust 开发了分布式存储系统 TiKV 。然而它的编译速度慢到足以让公司里的许多人不愿使用 Rust。我最近花了一些时间，与 TiKV 团队及其社区中的其他几人一起调研了 TiKV 编译时间缓慢的问题。 通过这一系列博文，我将会讨论在这个过程中的收获： 为什么 Rust 编译那么慢，或者说让人感觉那么慢； Rust 的发展如何造就了编译时间的缓慢； 编译时用例； 我们测量过的

这个问题出现呢，是因为用户权限问题。解决方法有2个： 切换为root用户执行命令。 sudo docker-compose up -d 将当前用户加入到docker组。 sudo gpasswd -a ${USER} docker 然后切换成root用户，再切换为当前用户，再次执行 docker-compose up -d ，就没有问题了。 ➜ /usr/local/tidb-docker-compose git:(master) sudo gpasswd -a penelope docker 正在将用户“penelope”加入到“docker”组中 ➜ /usr/local/tidb-docker-compose git:(master) su - 密码： root@wjj-PC:~# su - penelope ➜ /home/penelope cd /usr/local/tidb-docker-compose ➜ /usr/local/tidb-docker-compose git:(master) docker-compose up -d Creating network "tidb-docker-compose_default" with the default driver Creating tidb-docker-compose_prometheus_1

如果要问“分布式系统有哪些经典学习资料”，MIT 6.824（即 MIT 分布式系统课程） 一定位居榜首，这门课程已经有 20 年历史，日前公布了 2020 年春季课表，与往年不同的是，除了传统的文字介绍，官方还放出了高清课程视频。网友：终于有了非偷拍的高清视频看了:) 课程地址： https://pdos.csail.mit.edu/6.824/schedule.html 课程视频官方地址： https://www.youtube.com/channel/UC_7WrbZTCODu1o_kfUMq88g 激动之余，问题来了： 除了 MIT 6.824， 还有哪些资料可以更加深入学习分布式系统， 哪些项目可以练手？ 请查收一份超全的分布式数据库资料集 作为 开源分布式数据库 TiDB 的研发团队，我们一直希望带领更多小伙伴进入分布式系统、数据库领域，探索更多奇妙的事儿，也总结了一些从“入门到高阶玩家”更优的学习路径。 下面我们就将这些资料，一次性打包给大家。 插播科普 TiDB 源码：github.com/pingcap/tidb TiKV 源码：github.com/tikv/tikv 注：TiKV 是 TiDB 的存储层，现已成为 CNCF 的孵化项目） 1. PingCAP Talent Plan PingCAP Talent Plan 是一项进阶学习计划，内容涵盖：语言学习

作者介绍： 康文权，马上消费金融总账高级研发工程师。 李银龙，原腾讯云运维工程师，马上消费金融容器云 TiDB 负责人，西南区 TUG Leader。 背景介绍 马上消费金融于 2015 年 6 月营业，截止到 2020 年 1 月，历经 4 年多风雨，总注册用户数 8000 万，活跃用户数 2500 万，累计放贷 2900 多亿元人民币。公司于 2018 年 6 月增资到 40 亿，成为内资第一大的消费金融公司。 在业务爆发式增长的 4 年多里，马上消费金融的数据库经历了从单表数十 GB 到数百 GB 的过程，单表的数据量正在往 TB 级别演进。基于数据量的升级变迁，我们的数据库也经历了 2 次架构迭代，并在探索 第三代数据库架构： 第一代数据库架构 ——核心系统以 Oracle 为主，MySQL 为辅的时代。 第一代数据库架构 ——核心系统以 Oracle 为主，MySQL 为辅的时代。 第三代数据库架构 ——核心系统以 MySQL 结合 NewSQL 为主，NewSQL、MySQL、NoSQL 并存的时代。 马上金融第二代数据库架构痛点 海量数据 OLTP 场景需求痛点 截止目前账务系统的核心表累计数据量已达到单表 15 亿行以上，还在高速增长中。监管要求金融行业历史数据至少保留 5 年以上。这给数据库系统带来了巨大挑战： 海量的历史交易与账务数据堆积在 MySQL 数据库中

第一作者：李建俊，第二作者：杨哲轩，王聪 TiKV 作为一个分布式 KV 数据库，使用 Raft 算法来提供强一致性。Raft 算法提供了单一 group 的一致性，但是单一 group 无法扩展和均衡。因此，TiKV 采用了 MultiRaft 的方式基于 Raft 算法提供能兼顾一致性、扩展均衡的 KV 储存。下文以 3.0 版本代码为例，讲述 raftstore 源码中的关键定义和设计。 MultiRaft MultiRaft 顾名思义就是多个 Raft group。数据组织上，TiKV 将数据按范围划分成多个分片，这些分片称之为 region。每个 region 由一个 Raft group 来管理。Raft group 和 region 是一对一的关系。由下方示意图可以看到一个 Raft group 管理的多个副本分别落在不同的机器上，一个机器的数据包含了多个不同 region 的副本。通过这种组织方式，我们让 Raft group 并行起来，从而实现扩展和均衡。 Batch System Batch System 是 raftstore 处理的基石，是一套用来并发驱动状态机的机制。状态机的核心定义如下： pub trait Fsm { type Message: Send; fn is_stopped(&self) -> bool; } 状态机通过

2020 年这个春天格外特殊， 我们在 全员远程办公 中开启了新目标、新征程， 当然，我们招纳人才的脚步也不会停歇。 是的，我们在招人， PingCAP 2020 招聘季正式开启了！ 去年招聘季 我们为大家介绍了这些有趣的团队： 无法抑制内心技术躁动的 TiDB 团队 传说中「面试通过率最低、难度最高」的 TiKV 团队 最具活力的 AP 团队 让 TiDB 在云端跳舞的 Cloud 团队 「效率至上」的 EE 团队 今年各个团队积极拓展职责边界，在团队职责、团队名称等方面都有了一些令人惊喜的新变化： 原 AP 团队正式更名为 Real-Time Analytics，继续专注面向实时分析和 HTAP 场景的产品开发，并与 TiDB 团队以及负责产品规划与管理的 PM 团队共同组成 PingCAP 三个研发部门之一（R&D Group Dept.1），专注 TiDB 产品研发。 原 TiKV 团队进一步细分为专注于分布式存储层构建的 Storage Team、专注于分布式数据库架构领域的 Arch Team 以及专注于分布式系统整体性能的 Scheduling Team，并与效率工具、生态工具研发团队共同组成 PingCAP 另一研发部门（R&D Group Dept.2，后文简称 R2D2），专注提升工程效率，构建全球知名的分布式系统生态。 Cloud 团队与「效率至上」的 EE

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 本文转载自微信公众号“ OPPO大数据 ”。 作者介绍 ：OPPO 数据分析与解决方案团队主要负责 OPPO 全集团的大数据分析和解决方案提供，团队成员多来自一线互联网公司及著名高校，在 OPPO 众多场景的大数据应用方面有很深经验，极大的支撑了业务迅速发展。 文章具体作者：羊欢，代凯，柳青，陈英乐。 OPPO 大数据中心在 2019 年初承接了接入某业务线核心数据的重要任务：一期目标是建立一个能提供准实时大数据查询服务的数据仓库。我们选用了之前从未在公司大规模正式使用过的 TiDB 作为核心数据库引擎。本文记录这次吃螃蟹的一些经验和教训，供大家参考。 前期工作 核心挑战 经过需求调研阶段，我们发现面临以下核心的挑战： 大数据能力支持 。从业务数据量看，当前虽然尚在 TB 级别，但增长速度非常快，业务本身有进行全量整合分析查询的需求。 数据接入困难 。数据分散且多样，跨国，多种 DB 类型，多网络环境，接入难度较大。 数据变动频繁 。核心数据存在生命周期，在生命周期内变动频繁，这与互联网的核心数据一旦生成就不再变化有较大不同。 服务实时性较高 。数据整合的速度和查询结果越实时，对业务价值就越大。 现有技术架构体系 公司数据中心目前承载着公司各业务系统积累的数据。 数据仓库方面的技术体系：

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 作者：殷成文 2019 年 12 月 31 日，我们在 GitHub 上正式开源了 Chaos Mesh。作为一个云原生的混沌测试平台，Chaos Mesh 提供在 Kubernetes 平台上进行混沌测试的能力。本篇文章将围绕 Chaos Mesh 起源及原理等方面进行介绍，并结合具体案例带领大家一起探索混沌测试的世界。 现实世界中，各类故障可能会随时随地的发生，其中有很多故障我们无法避免，例如磁盘突然写坏，或者机房突然断网断电等等。这些故障可能会给公司造成巨大损失，因此提升系统对于故障的容忍度成为很多工程师努力的目标。 为了更方便地验证系统对于各种故障的容忍能力，Netflix 创造了一只名为 Chaos 的猴子，并且将它放到 AWS 云上，用于向基础设施以及业务系统中注入各类故障类型。这只 “猴子” 就是混沌工程起源。 在 PingCAP 我们也面临同样的问题，所以在很早的时候就开始探索混沌工程，并逐渐在公司内部实践落地。 在最初的实践中我们为 TiDB 定制了一套自动化测试平台，在平台中我们可以自己定义测试场景，并支持模拟各类错误情况。但是由于 TiDB 生态的不断成熟，各类周边工具 TiDB Binlog 、 TiDB Data Migration 、 TiDB Lightning 等的出现

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> tidb默认变量 SHOW GLOBAL VARIABLES like '%mem_quota%' # 查看内存使用阈值 set @@tidb_mem_quota_query = 8 << 30; -- 配置整条SQL的内存使用阈值为8GB SELECT @@tidb_mem_quota_query -- 查看当前变量 慢sql show variables like 'tidb_slow_query_file'; # 查看慢sql文件位置 admin show slow recent 10; # 查看最近10条慢sql admin show slow top 3; -- 最慢的查询记录 admin show slow top all 5; -- 包含内部SQL的慢查询记录 select query_time, query from information_schema.slow_query where is_internal = false -- 排除 TiDB 内部的慢查询 SQL order by query_time desc limit 5; # 搜索排名前5的慢SQL select query_time, query, user from information_schema.slow_query