使用 TiKV 作为分布式锁

「锁并不是性能瓶颈,冲突才是」 --- 可能是七牛老许说的 之前在很多不同的场合提到过,如果有一个支持跨行事务的高性能 KV 数据库就能做不少事情。今天下午随手用 TiKV 实现了一个可以 Scale 的高可用的分布式锁。 分布式锁是什么?问得好,简单来说就是大家熟悉的 mutex 的概念搬到分布式场景下。多个不同的进程,可能跨越不同的机器,怎么实现 mutex 语义,而且锁服务本身尽量不要成为单点,同时还尽可能可靠。 假设我们的存储层支持 »

TiDB 2016 回顾与 2017 的一些想法

新年伊始,突然发现 TiDB 又一次被国际友人顶上了 HackerNews 首页前十,借着这个由头有友人约稿说想让我写一下对于这个数据库的过去和未来的一些想法和规划,正好这个周末偷得半日闲,于是赶紧动笔,不过我本人一向懒得总结,同时不太希望做太远的计划,所以就想到哪写到哪了 😃 。 TiDB 是一个大概开始了两年的项目,从最早的 3 个人到现在背后目前大约 30 多个活跃开发者,包括周边的工具和 CI ,可以说是一个凝结了我们大量心血的一个项目。这个项目的开始的起点是很高的,当时的想法是要么别做,要么就做到最好,当时( »

Lua source reading order

Steal from Reddit [–]mikemike 38 指標 8 年前 Online Lua 5.1 source code browser Recommended reading order: lmathlib.c, lstrlib.c: get familiar with the »

为 Raft 引入 leader lease 机制解决集群脑裂时的 stale read 问题

问题: 当 raft group 发生脑裂的情况下,老的 raft leader 可能在一段时间内并不知道新的 leader 已经被选举出来,这时候客户端在老的 leader 上可能会读取出陈旧的数据(stale read)。 比如,我们假想一个拥有 5 个节点的 raft group: 其中 Node 5 是当前的 »

开源数据库的现状

数据库作为业务的核心,在整个基础软件栈中是非常重要的一环,近几年社区也是新的方案和思想层出不穷,在本次分享中,我将会总结一下近几年一些主流的开源数据库方案,背后的思想以及试用的场景,本人才疏学浅如有遗漏或者错误请见谅~本次分享我希望能尽量聚焦于数据库既结构化数据存储 OLTP 及 NoSQL 领域,不会涉及 OLAP, 对象存储,分布式文件系统。 开源 RDBMS 与互联网的崛起 其实很长时间以来,关系型数据库一直是大公司的专利,市场被 Oracle / DB2 等企业数据库把持,但是随着互联网的崛起, »

基于Raft构建的大规模分布式存储

最近在一个微信群的分享,记录一下 其实最近这两年也有很多的文章开始关注类似 Paxos 或者 Raft 这类的分布式一致性算法,但是主要内容还是在介绍算法本身和日志复制,但是对于如何基于这样的分布式一致性算法构建一个大规模的存储系统介绍得并不多,我们目前在以 Raft 为基础去构建一个大规模的分布式数据库 TiKV,在这方面积累了一些第一手的经验,今天和大家聊聊类似系统的设计,本次分享的内容不会涉及很多 Raft 算法的细节,大家有个 Paxos 或者 Raft 的概念,知道它们是干什么的就好。 首先想聊聊的是 Scale, »

Thoughts behind TiDB - Part I

“让我们看看未来的数据库到底应该是什么样子吧。” 其实想写这个蛮久了,趁着整个 TiDB 项目即将 release beta 的时机,作为 NewSQL 领域走在全球前沿的开源项目,我试着整理一下关于 TiDB 背后的一些理念和关键设计背后的想法,对于一起现在或者未来一起工作的 PingCAP 的小伙伴,也可以了解到目前为止这个项目是一步步走过来的,算是留个记录。另外对于分布式系统和数据库感兴趣的朋友如果能从我的文章中得到一点启发,也算是没白写。 TiDB 和 TiKV 项目均在 Github »

Hello world

好久没有时间写 Blog 了,决定重新开始记录一些东西,记录一下日常的点滴。 主要还是技术吧,因为觉得写其他东西确实太矫情,好吧,就这样。 »