背景

因为丰巢自去年年底开始在推送平台上尝试了TiDB,最近又要将承接丰巢所有交易的支付平台切到TiDB上。我本人一直没有抽出时间对TiDB的源码进行学习,最近准备开始一系列的学习和分享。由于我本人没有数据库相关的经验,本着学习的心态和大家一起探讨,欢迎高手随时指正。总结一下本次学习分享的目的:

  • 丰巢把最重要的两个基础业务都放到了TiDB上,后续应该会有更多的核心系统跑在TiDB上,我们丰巢中间件团队作为引入TiDB到丰巢的推动人和执行者,对于TiDB的稳定性和突发事件的处理,一定要做足功课;
  • 以TiDB为代表的newsql代表的是现在和未来,作为个人来说,有着充足的动力去学习;
  • 我们不满足于只是作为TiDB的使用者,我们需要在TiDB上定制开发对于丰巢更有意义的模块,如果能给社区做贡献,那更是非常棒的一件事;

言归正传,说一下本文的产生原因:去年我们在推送平台上使用TiDB的过程中,就发现老版本的TiDB是无法通过外部手段kill调用慢查询的,而慢查询的危害对于数据库来说会有致命的风险,后来pingcap公司在2.1版本(具体的版本参见TiDB的说明)中增加了show processlist和kill tidb命令,但是因为TiDB本身是无状态的,这两个命令属于单机命令,在使用的过程中,大家还是要提前做好准备,要直连到具体的TiDB的server上才可使用,不要通过nginx等服务进行转发请求,到时不但不能解决问题,还有可能带来意外的风险。今天第一章,我们先来看一下show processlist这个比较简单的命令的源码,下一章,我们再分析kill tidb这个命令。

源码分析

环境信息

  • 软件:TiDB2.1.7、PD2.1.4、TiKV2.1.4;
  • 硬件:为了随时调试,TiDB跑在本机的mac上、PD和TiKV跑在linux虚拟机上;

操作过程

  • 打开一个直连TiDB的客户端,输入命令:show PROCESSLIST;
  • 客户端会输出下图的列表;

上面的列表中展示了当前TiDB正在处理每个连接的sql语句详情。

问题

在我分析源码之前,我问了自己本次分析源码要搞清楚的两个问题,在这里和大家分享一下:

  • show processlist到底是不是单机的命令,和TiKV、PD有没有啥关系?
  • kill tidb需要使用的id字段到底代表的是什么?

接收命令

首先,启动TiDB server.代码在tidb-server/main.go里面,主要方法是:runServer方法

func runServer() {
err := svr.Run()
}

再来看一下:server/server.go源码:

func (s *Server) Run() error {
for {
conn, err := s.listener.Accept()
go s.onConn(conn)
}
}

重点代码是监听端口,并创建连接,启动另一协程去服务新来的连接,接下来再看看server.go中的onConn方法:

func (s *Server) onConn(c net.Conn) {
conn := s.newConn(c)
conn.Run()
}

其中,s.newConn方法会将net. Conn连接包装成clientConn连接,并分配在这个TiDB server下唯一的connectionID,此connectionID为原子变量,每次新连接自增加1,我们先记住这个id,后面分析的时候会用到它。我们来看看server/conn.go下的Run方法:

func (cc *clientConn) Run() {
for {
data, err := cc.readPacket()
cc.dispatch(data)
}
}

Run方法主要就是不断的轮训读取clientConn中的内容,并将它交给dispatch方法进行下面的分析及返回结果操作,至此关于接收show processlist命令部分已经分析完毕,当然其它的sql语句也是经过这个过程进入到dispatch方法中的。

show processlist的构建Executor

接着分析dispatch方法在处理show processlist命令的流程:

func (cc *clientConn) dispatch(data []byte) error {
switch cmd {
case mysql.ComQuery:
return cc.handleQuery(ctx1, hack.String(data))
}
}

show processlist命令属于mysql.ComQuery,因此流程会走到handleQuery方法里面,我们来看一下:

func (cc *clientConn) handleQuery(ctx context.Context, sql string) (err error) {
rs, err := cc.ctx.Execute(ctx, sql)
err = cc.writeResultset(ctx, rs[0], false, 0, 0)
}

handleQuery中处理show processlist命令的重点代码就是上面的两行,我们先来看一下server/driver_tidb.go中的Execute方法:

rsList, err := tc.session.Execute(ctx, sql)

Execute中的重点就是调用session/session.go中的Execute方法:

func (s *session) execute(ctx context.Context, sql string) (recordSets []sqlexec.RecordSet, err error) {
s.PrepareTxnCtx(ctx)
stmtNodes, warns, err := s.ParseSQL(ctx, sql, charsetInfo, collation)
compiler := executor.Compiler{Ctx: s}
for _, stmtNode := range stmtNodes {
recordSets, err = s.executeStatement(ctx, connID, stmtNode, stmt, recordSets);
}
}

上面的execute方法中会对sql语句进行处理及制定执行计划,处理完成后调用executeStatement方法,executeStatement中的重点方法是runStmt:

recordSet, err := runStmt(ctx, s, stmt)

我们再来看看session/tidb.go中的runStmt方法:

func runStmt(ctx context.Context, sctx sessionctx.Context, s sqlexec.Statement) (sqlexec.RecordSet, error) {
rs, err = s.Exec(ctx)
err = finishStmt(ctx, sctx, se, sessVars, err)
}

继续来分析executor/adapter中的(a *ExecStmt) Exec方法,一样采取划重点的方式:

func (a *ExecStmt) Exec(ctx context.Context) (sqlexec.RecordSet, error) {
e, err := a.buildExecutor(sctx)
e.Open(ctx)
var pi processinfoSetter
if raw, ok := sctx.(processinfoSetter); ok {
pi = raw
sql := a.OriginText()
if simple, ok := a.Plan.(*plannercore.Simple); ok && simple.Statement != nil {
if ss, ok := simple.Statement.(ast.SensitiveStmtNode); ok {
// Use SecureText to avoid leak password information.
sql = ss.SecureText()
}
}
// Update processinfo, ShowProcess() will use it.
pi.SetProcessInfo(sql)
//fmt.Println(sql)
a.Ctx.GetSessionVars().StmtCtx.StmtType = GetStmtLabel(a.StmtNode)
} return &recordSet{
executor: e,
stmt: a,
processinfo: pi,
txnStartTS: txnStartTS,
}, nil
}

(a *ExecStmt) Exec方法中raw, ok := sctx.(processinfoSetter)这段逻辑就是把当前连接正在执行的语句存储到processinfo里面取,关于这部分细节比较简单,在这里不展开来分析。我们先来看看buildExecutor中做了什么事情?

	b := newExecutorBuilder(ctx, a.InfoSchema)
e := b.build(a.Plan)

重点要来了,在executor/builder.go中的build方法做了啥事?

	case *plannercore.Show:
return b.buildShow(v)

build方法会根据不同的语句类型来构建不同的Executor并返回,show processlist命令会匹配到plannercore.Show类型,我们看看buildShow方法的实现:

	e := &ShowExec{
baseExecutor: newBaseExecutor(b.ctx, v.Schema(), v.ExplainID()),
Tp: v.Tp,
DBName: model.NewCIStr(v.DBName),
Table: v.Table,
Column: v.Column,
User: v.User,
Flag: v.Flag,
Full: v.Full,
GlobalScope: v.GlobalScope,
is: b.is,
}
if len(v.Conditions) == 0 {
return e
}
sel := &SelectionExec{
baseExecutor: newBaseExecutor(b.ctx, v.Schema(), v.ExplainID(), e),
filters: v.Conditions,
}
return sel

因为v.Conditions为0,所以返回类型为ShowExec的Executor,我们接下来再刚才的Exec方法中的e.Open方法,其实就是ShowExec的Open方法,ShowExec位于executor/show.go文件中,我们查找后发现ShowExec中没有Open方法,我当时是被搞蒙了,后来发现这是go的一个语言特性,它使用的是baseExecutor的Open方法:

func (e *baseExecutor) Open(ctx context.Context) error {
for _, child := range e.children {
err := child.Open(ctx)
if err != nil {
return errors.Trace(err)
}
}
return nil
}

上面的方法会遍历baseExecutor中的children的Executor,然后调用它们的Open方法,但是因为ShowExec在创建它的baseExecutor的时候,没有任何的children,所以在show processlist这个操作过程中,Open方法相当于啥也没干,但是大家在分析其它语句时,这个Open方法是一个很重要的方法。我们再来看刚才Exec中的最后的return块里面,返回了包装executor、processinfo等信息的recordSet类型。至此关于show processlist命令如何包装成Executor并和processinfo等信息作为recordSet类型的返回值返回给上层函数分析完毕。

show processlist的获取各个连接的processinfo信息

接下来我们再来看handleQuery中的writeResultset方法:

err = cc.writeResultset(ctx, rs[0], false, 0, 0)

在server/conn.go中的writeResultset主要的逻辑就是下面的逻辑:

err = cc.writeChunks(ctx, rs, binary, serverStatus)

我们继续来分析writeChunks中的重要部分:

func (cc *clientConn) writeChunks(ctx context.Context, rs ResultSet, binary bool, serverStatus uint16) error {
for {
err := rs.Next(ctx, chk)
}
}

writeChunks里面主要就是循环调用rs.Next的方法,直到满足条件为止,rs的类型实际上是server/driver_tidb.go下的tidbResultSet类型,我们来看一下它的Next方法:

func (trs *tidbResultSet) Next(ctx context.Context, chk *chunk.Chunk) error {
return trs.recordSet.Next(ctx, chk)
}

tidbResultSet的Next方法主要是调用了executor/adapter.go中的recordSet类型的Next方法,我们来看看这个Next方法:

func (a *recordSet) Next(ctx context.Context, chk *chunk.Chunk) error {
err := a.executor.Next(ctx, chk)
}

recordSet方法的重点就是调用它的executor的Next方法,我们在上一个小节 结尾处分析出recordSet的executor就是之前生成的ShowExec(可算是找到它了,我已经累晕)。那么,我们接着分析它的Next方法:

e.fetchAll()

ShowExec中的Next方法的主要逻辑就是调用它的fetchAll方法,接着往下看:

case ast.ShowProcessList:
return e.fetchShowProcessList()

因为匹配到了这个case,所以会调用它的fetchShowProcessList方法:

func (e *ShowExec) fetchShowProcessList() error {
sm := e.ctx.GetSessionManager()
pl := sm.ShowProcessList()
}

上面的sm类型的server/server.go中的Server类型,我们来看看它的ShowProcessList方法:

func (s *Server) ShowProcessList() map[uint64]util.ProcessInfo {
s.rwlock.RLock()
rs := make(map[uint64]util.ProcessInfo, len(s.clients))
for _, client := range s.clients {
if atomic.LoadInt32(&client.status) == connStatusWaitShutdown {
continue
}
pi := client.ctx.ShowProcess()
rs[pi.ID] = pi
}
s.rwlock.RUnlock()
return rs
}

它主要是遍历当前所有的客户端,并获取到所有客户端的ShowProcess,其中的client.ctx类型为server.TiDBContext,我们来看看它的ShowProcess:

func (tc *TiDBContext) ShowProcess() util.ProcessInfo {
return tc.session.ShowProcess()
}

逻辑比较简单,就是调用类型为session.session的ShowProcess方法,接着往下看:

func (s *session) ShowProcess() util.ProcessInfo {
var pi util.ProcessInfo
tmp := s.processInfo.Load()
if tmp != nil {
pi = tmp.(util.ProcessInfo)
pi.Mem = s.GetSessionVars().StmtCtx.MemTracker.BytesConsumed()
}
return pi
}

session的ShowProcess方法会从内存中加载当前session的processInfo信息。至此我们分析show processlist命令的源码分析完毕,关于每个连接如何设置自身的processinfo信息,逻辑也比较简单,大家有兴趣可以自己去研究一下。

总结

我们可以回答一下开头提出的两个问题:

  • show processlist到底是不是单机的命令,和TiKV、PD有没有啥关系?答案是show processlist确实是一个单机命令,和TiKV、PD没有任何关系。
  • kill tidb需要使用的id字段到底代表的是什么?id字段就是在创建连接时,分配的connectionId,它在单个TiDB服务内唯一。

通过上面的分析,我们还可以总结以下的特点:

  • TiDB的连接在客户端不能够复用,因为它处理请求时,主流程是在单协程中处理的,处理完一个再处理下一个;
  • show processlist命令的处理中关于ShowExec的Open方法调用,其实是它内部的baseExecutor的Open方法;
  • 每个连接的session负责独立管理此连接的processinfo信息;
  • TiDB的Executor机制靠next的方式不断在它的链式处理结构上传递;
  • show processlist因为没有其它条件,所以它在处理时的Executor类型为ShowExec,没有再包装SelectionExec类型;
  • 真正的语句执行(获取show processlist的信息)其实是在write的时候,我在分析这点的时候,花了不少时间;

源码阅读方法

最后,我想和大家分享一下,我自己在源码阅读里面用到的一些方法和技巧,大的方面会有两种方法:

  • 由因导果:就是由某一行代码,开始自顶向下的正向阅读;
  • 执果索因:就是从结果处出发,开始自底向上的反向阅读和推导;

上面的两种方法,会伴随大家在源码阅读的各个阶段,但是有了这两种方法还是远远不够的,我再分享一下我的相关技巧:

  • 编译运行:当我们在下定决心要阅读某个框架的源码时,第一步要做的就是,将这个框架的源码从源码库拉下来后,用我们的IDE工具编译运行起来,对于有些框架运行的难度会比较高,就比如说我这次选择的TiDB,在编译过程中花费了好多的时间。建议大家在这个过程中,不要放弃,第一步是一定要把它编译运行起来;
  • 资料参考:一般来讲只要不是太冷门的组件,一般网上都会有比较多的源码分享,我们需要甄别出写的好的源码分析资料,然后参考验证我们的源码阅读;
  • 重要类的结构关系图整理:我们都知道,java体系的组件(golang的也一样),在设计时都会有各种复杂接口和抽象类继承关系,在阅读源码时,我们很容易便陷入到这种复杂的继承关系中去,所以利用IDE工具绘出类的结构关系图,会在我们阅读源码时,有很大的帮助;
  • 掌握调试技巧:有较好的调试技巧可以便于我们分析代码流程和上下游关系;
  • 修改源码:在我们不能完全确定流程分支等情况下,可以靠修改源码去理解;
  • 提问题:在本文分析show processlist源码的过程中,提问题一直都伴随着我们的源码阅读过程,提问题能让我们更好的理解背后的含义,便于深入到源码的架构设计中去;
  • 聚焦:对于类似于TiDB如此复杂的组件,我们在一开始分析的过程中,一定要先选定分析的主线路,比如:本章的“show processlist”,在这个过程中,有意的忽略我们本次分析主线路之外的逻辑分支,目标明确,才能不会陷入到框架各种复杂的设计中去;
  • 总结分享:这一点是最重要的,源码阅读完后,如果不进行总结,过一段时间,我们便很容易遗忘了,同时分享也很重要,开源软件本身就是一种众包思想,我们既然是受益方,同时也要通过知识分享回馈他人;

TiDB show processlist命令源码分析的更多相关文章

  1. memcached学习笔记——存储命令源码分析下篇

    上一篇回顾:<memcached学习笔记——存储命令源码分析上篇>通过分析memcached的存储命令源码的过程,了解了memcached如何解析文本命令和mencached的内存管理机制 ...

  2. memcached学习笔记——存储命令源码分析上篇

    原创文章,转载请标明,谢谢. 上一篇分析过memcached的连接模型,了解memcached是如何高效处理客户端连接,这一篇分析memcached源码中的process_update_command ...

  3. debug:am、cmd命令源码分析

    debug:am.cmd命令源码分析 目录 debug:am.cmd命令源码分析 am命令的实现 手机里的am am.jar cmd命令的实现 手机里的cmd cmd activity cmd.cpp ...

  4. storm shell命令源码分析-shell_submission.clj

    当我们在shell里执行storm shell命令时会调用shell_submission.clj里的main函数.shell_submission.clj如下: shell_submission.c ...

  5. golang初探与命令源码分析

    前段时间有群友在群里问一个go语言的问题: 就是有一个main.go的main函数里调用了另一个demo.go里的hello()函数.其中main.go和hello.go同属于main包.但是在mai ...

  6. Django(三)runserver 命令源码分析

    应用环境 windows7 pycharm2018 profession python3.6 django2.0 我们在pycharm 启动django项目时,常常有这么一个命令操作: python ...

  7. redis源码分析之事务Transaction(上)

    这周学习了一下redis事务功能的实现原理,本来是想用一篇文章进行总结的,写完以后发现这块内容比较多,而且多个命令之间又互相依赖,放在一篇文章里一方面篇幅会比较大,另一方面文章组织结构会比较乱,不容易 ...

  8. redis源码分析之有序集SortedSet

    有序集SortedSet算是redis中一个很有特色的数据结构,通过这篇文章来总结一下这块知识点. 原文地址:http://www.jianshu.com/p/75ca5a359f9f 一.有序集So ...

  9. redis源码分析之事务Transaction(下)

    接着上一篇,这篇文章分析一下redis事务操作中multi,exec,discard三个核心命令. 原文地址:http://www.jianshu.com/p/e22615586595 看本篇文章前需 ...

随机推荐

  1. 解决miner.start() 返回null

    下面我列举了三种解决方案,前面两张是某两位大佬试出来的,第三种是我蒙出来的. 第一种解决方案 转载自  http://mp.weixin.qq.com/s/AB9vj1EzOgWT7JyryfQhDg ...

  2. Mysql系列-数据库

    一 .数据库管理软件的由来 基于我们之前所学,数据要想永久保存,都是保存于文件中,毫无疑问,一个文件仅仅只能存在于某一台机器上. 如果我们暂且忽略直接基于文件来存取数据的效率问题,并且假设程序所有的组 ...

  3. 关于JavaScript的那些话

    1.初学者动手环境----推荐Chrome的控制台(F12调用)2.JS中两个非常重要的数据类型是对象和数组.3.JavaScript 程序是用Unicode字符集编写的.4.JavaScript是区 ...

  4. Ubuntu 16.04开启SSH服务

    安装: sudo apt-get install openssh-server 启动: sudo service ssh start 查询服务启动状态: sudo ps -e | grep ssh 或 ...

  5. Powmod快速幂取模

    快速幂取模算法详解 1.大数模幂运算的缺陷: 快速幂取模算法的引入是从大数的小数取模的朴素算法的局限性所提出的,在朴素的方法中我们计算一个数比如5^1003%31是非常消耗我们的计算资源的,在整个计算 ...

  6. 初探Apache Beam

    文章作者:luxianghao 文章来源:http://www.cnblogs.com/luxianghao/p/9010748.html  转载请注明,谢谢合作. 免责声明:文章内容仅代表个人观点, ...

  7. 哈夫曼树【最优二叉树】【Huffman】

    [转载]只为让价值共享,如有侵权敬请见谅! 一.哈夫曼树的概念和定义 什么是哈夫曼树? 让我们先举一个例子. 判定树:         在很多问题的处理过程中,需要进行大量的条件判断,这些判断结构的设 ...

  8. Ubuntu16.04下安装Hive

    上一篇博客我们已经说过了要如何安装Hadoop,别忘记了我们的目的是安装Hive.所以这篇博客,我就来介绍一下如何安装Hive. 一.环境准备 (1)Vmware (2)  Ubuntu 16.04 ...

  9. Search in rotated array two

    description: Follow up for "Search in Rotated Sorted Array":What if duplicates are allowed ...

  10. npoi生成excel流并在客户端下载(html+后台 )

    //前端页面 <body> <input type="button" value="导出Excel" class="button&q ...