开源数据库中间件kingshard横空出世

开源数据库中间件kingshard横空出世

项目主页：https://github.com/flike/kingshard项目发起人：flikekingshard简介kingshard是一个由Go开发高性能MySQL Proxy项目，kingshard在满足基本的读写分离的功能上，致力于简化MySQL分库分表操作；能够让DBA通过kingshard轻松平滑地实现MySQL数据库扩容。 kingshard的性能大约是直连MySQL性能的80%以上。主要功能：读写分离。跨节点分表。支持透明的MySQL连接池，不必每次新建连接。支持客户端IP访问控制。平滑上线DB或下线DB，前端应用无感知。支持多个slave，slave之间通过权值进行负载均衡。支持强制读主库。支持将sql发送到特定的node。支持在单个node上执行事务，不支持跨多个node执行事务。支持跨node的count,sum,max和min等函数。支持单个分表的join操作，即支持分表和另一张不分表的join操作。支持order by,limit等操作。支持主流语言（java,php,python,C/C++,Go)SDK的mysql的prepare特性。支持到后端DB的最大连接数限制。支持SQL日志及慢日志输出。kingshard的应用场景现在很多互联网公司还是在大量使用MySQL来存储各种类型的关系型数据。随着访问量和数据量的增长，开发者不得不考虑一些MySQL相关的新问题：读写分离问题。由于前端应用访问量增加，单台MySQL不足以支撑整个系统的写入和查询操作。这时候，我们不得不将一些耗时的查询操作分散到多个slave上。单表容量问题。如果在系统设计之初，没有考虑到分表问题。随着数据量的增长，单表容量越来越大。作者见过单表容量5亿条记录，然后一个简单的delete操作都会引起系统慢日志，而且有可能导致MySQL IO瞬发性的飙升。很多同学可能会想到，在查询的字段上加上索引，但当数据量增长到这么大的时候，即使加上索引效果也不明显了。归根结底，就是单表数据量太大，导致MySQL即使通过索引定位数据，仍然需要扫描很多记录。数据库的运维问题。如果在代码中配置主库和从库host，系统运行当然也是没问题的。但这样大大增加了运维工作的压力，比如：MySQL数据库IO压力由于访问量的增加居高不下，DBA需要添加一台slave，这时候就不得不修改代码，然后打包并上线。还有很多非常实际的例子，在这就不一一列举。连接池。前端应用频繁连接MySQL，由此给MySQL带来的额外性能消耗也是不容忽视的。如果通过增加一个连接池，每个DB缓存一定数量的MySQL连接，当有应用需要连接后端的MySQL，直接从连接池里取出一个已建好的连接来发送SQL请求，这样会大大加快数据查询速度。而且可以降低MySQL的性能消耗。SQL日志。在程序出现问题时，我们希望得到一些SQL日志，比如，什么时刻哪条SQL发送到哪一台DB上了。通过查看这种日志能够帮助我们快速定位问题。面对这些问题，我们可以在客户端代码中逐一实现。但这样也会使得客户端越来越重，不那么灵活。作者一直从事数据库相关工作的开发，正是基于数据库开发的痛点，设计和实现了kingshard数据库中间件。kingshard对上述5类问题都有比较合适的解决方案。

整体架构

kingshard采用Go开发，充分地利用了Go语言的并发特性。Go语言在并发方面，做了很好的封装，这大大简化了kingshard的开发工作。kingshard的整体工作流程如下所述：

读取配置文件并启动，在配置文件中设置的监听端口监听客户端请求。收到客户端连接请求后，启动一个goroutine单独处理该请求。首选进行登录验证，验证过程完全兼容MySQL认证协议，由于用户名和密码在配置文件中已经设置好，所以可以利用该信息验证连接请求是否合法。 当用户名和密码都正确时，转入下面的步骤，否则返回出错信息给客户端。认证通过后，客户端发送SQL语句。kingshard对客户端发送过来的SQL语句，进行词法和语义分析，识别出SQL的类型和生成SQL的路由计划。如果有必要还会改写SQL，然后转发到相应的DB。也有可能不做词法和语义分析直接转发到相应的后端DB。如果转发SQL是分表且跨多个DB，则每个DB对应启动一个goroutine发送SQL和接收该DB返回的结果。接收并合并结果，然后转发给客户端。

kingshard工作整体流程可参考下面这幅图

kingshard整体架构图如下所示

词法和语义分析

要将kingshard的功能做的足够强大，就不得不进行SQL的词法和语义分析。SQL语句的词法分析指的是将SQL语句切分成一个一个的关键字。例如对SQL语句：select name from stu where id < 13进行词法分析，得到的结果是：{"select","name","from","stu","where","id","<","13"}。 这样做的目的主要为了生成一棵抽象语法树，也就是大家常说的AST(abstract syntax tree),语义分析就是基于这棵语法树来操作的。语义分析的目的主要有以下几个方面：

读写分离，只有识别出SQL语句的类型，才能进行正确的读写分离操作。数据分片，解析出表名和查询条件，将SQL路由到正确的DB。SQL黑名单，通过词法和语义分析，也可以快速识别出需要屏蔽的SQL语句。例如，检测到delete语句不带where操作，就可以直接阻断该SQL的转发。

kingshard并没有考虑完全兼容MySQL所有语法，因为完全兼容MySQL语法会使得词法和语义分析模块变得异常复杂，而且低效。对于DDL语句其实没必要解析，只要能正确转发到后端相应的DB上就可以。

kingshard只对部分DML语句（select,update,insert,delete,replace)进行了解析，这样可以满足绝大部分的分表操作。对于其他语句，kingshard会将其发送到一个默认的DB，或者通过kingshard特有的方式将其发送到指定的DB上，例如： /*node2*/insert into stu（id,name) values(12,'xiaoming'),对于这种带有注释的的sql语句，kingshard能够识别出，然后将这条sql语句发送到node2节点的Master DB上。

负载均衡

用户使用Mysql Proxy目的很大一部分就是为了降低单台DB的负载，将读压力分担到多台DB上。kingshard支持多个slave，不同的slave可以配置不同的读权重，权重越大分担的读请求越多。kingshard读请求负载均衡采用的是权重轮询调度算法。

大部分系统采用该算法时，都是转发SQL语句时，动态地计算出本次选取DB的序号。然后将读请求的SQL语句发送到该DB。仔细分析一下，这样做其实是没有必要的。因为DB的权重是相对固定的，不会经常变动，所以完全可以计算出一个固定的轮询序列，然后将这个序列保存在一个数组中。这样不需要动态计算，每次读取数组就可以。举个例子来说，在kingshard的node配置项中配置slave选项： slave:192.168.0.12@2,192.168.0.13@3 kingshard在读取配置信息初始化系统的时候，就生成了一个轮询数组:[0,0,1,1,1]。在kingshard中会将这个数组打乱顺序，变成：[0,1,1,0,1]。这样就避免了动态计算DB下标的问题，对性能提升有一定帮助。

sharding实现

首选需要介绍两个概念：

子表，在kingshard中一张逻辑上的大表由若干张小的子表组成。例如：将stu表分成stu_0000,stu_0001,stu_0002,stu_0003。 在数据库中stu表是不存在的，它只是一张逻辑上的表。数据库中只存在四张子表（stu_0000,stu_0001,stu_0002,stu_0003）。 发送SQL语句时，kingshard会识别出需要分表的SQL语句，并改写该SQL。例如，客户端发送过来的SQL语句是：select name from stu where id =10; kingshard收到该SQL语句后，从配置信息中识别出该表是一个Hash类型的分表。根据分表规则，将该SQL改写成：select name from stu_2 where id =10; 然后发送给对应的DB。Node，子表分布在各个node上，每个node包含一个maser server和若干个slave server（slave个数可以为0）。写请求会发往该node中master server，读请求会发往该node中的slave server。

kingshard的sharding采用了两级映射的思想，首选根据SQL语句的分表条件计算出这条SQL语句落在哪个子表上，然后再根据配置信息找到该子表 落在哪个node上。采用两级映射的思想，对于MySQL的扩容和缩容都能很方便地支持。目前kingshard sharding支持insert, delete, select, update和replace语句, 所有这五类操作都支持跨子表。但写操作仅支持单node上的跨子表，select操作则可以跨node，跨子表。

对于有些表没有分表，操作该表的SQL语句会发往default node。或者用户可以选择在SQL语句前面加上注释，指定该SQL要发往的node，kingshard接收到语句后，识别出注释中指定的node，然后将该SQL发往对应node中合适的DB。例如用户发送/*node1*/select * from member where id=100,kingshard接收到该SQL后会将其发送到node1的salve上。这样kingshard就能很好地兼容分表和不分表的各种应用场景了。

事务的实现

所有proxy支持shard后都会面临一个问题：支不支持分布式事务？出于性能和可用性考虑， kingshard只支持单台DB上的事务，不允许跨DB的事务。kingshard处理单DB上的事务流程如下：

用户发送begin语句。kingshard接收到SQL语句后，将该连接的状态设置为事务。用户发送DML语句，kingshard识别出语句需要发送到的DB，然后kingshard新建一个与后端DB的连接，利用该连接发送语句。收取SQL语句的结果后，将连接放回。kingshard收到下一条SQL语句，判断该SQL是不是发往同一个DB，如果不是则报错。如果是发往同一个DB，则利用该连接发送语句。收到用户发送的commit语句，将该连接的状态设置为非事务，事务结束。

后端DB存活检测

kingshard每个node启动了一个goroutine用于检测后端master和slave的状态。当goroutine持续一段时间（由配置文件中down_after_noalive参数设置）ping不通后端的DB后，会将该DB的状态设置为down，后续kingshard就不会将sql语句发往该DB了。

客户端白名单机制

有时候用户为了安全考虑，希望只只允许某几台server连接kingshard。在kingshard的配置文件中有一个参数：allow_ips，用于实现客户端白名单机制。当管理员设置了该参数，则意味着只有allow_ips指定的IP能够连接kingshard，其他IP都会被kingshard拒绝连接。如果不设置该参数，则连接kingshard的客户端不受限制。

管理端设计和实现kingshard的管理端口复用了工作端口，通过特定的关键字(admin)来标示。kingshard是通过对管理端特定的SQL进行词法和语义分析，将SQL语句解析为一条kingshard可以识别的命令。目前支持平滑上下线master和slave，和查看kingshard配置和后端DB状态。后续打算将web页面集成到管理端，这样用户就可以不用输入命令行操作，而是在网页上操作。大大降低用户使用kingshard的门槛。

上述各个模块都是kingshard中比较核心的模块，通过这篇文章的介绍，我想读者应该对kingshard的架构和实现有了初步的了解。很多功能的设计和实现，都是作者慢慢地摸索和实践。如果有读者对kingshard的设计或实现感兴趣或者对上述设计有不同的想法，欢迎发邮件（flikecn#126.com）给我。

License

kingshard采用Apache 2.0协议，相关协议请参看目录

鸣谢

感谢mixer作者siddontang, kingshard最初的版本正是基于mixer开发而来的。

感谢bigpyer，他对kingshard做了详细的性能测试，并撰写了一份非常详细的测试报告。

感谢以下开源爱好者为kingshard做出的贡献。

反馈

kingshard开源以来，经过不断地迭代开发，功能较为完善，稳定性有较大提升。 目前已有几家公司在生产环境使用kingshard作为MySQL代理。 如果您在使用kingshard的过程中发现BUG或者有新的功能需求，非常欢迎您发邮件至hiflike#gmail.com与作者取得联系，或者加入QQ群(147926796)交流。

更多kingshard文档移步：https://github.com/flike/kingshard/blob/master/README_ZH.md

加入运维帮

运维帮已开通多个微信群供大家交流学习，需要先加南非蜘蛛微信 （yunweibang008）后拉你入群。

会员讨论群：总群1、总群2、总群3

地方讨论群：北京、上海、广州、深圳、杭州、成都

软件讨论群：Nginx、Zabbix

QQ讨论群：186356564