目录
前言
开源分布式数据库中间件MyCat架构简介——MyCat源起
一、数据库切分概述：OLTP和OLAP
二、关系型数据库和NoSQL数据库
三、关系型数据库和NoSQL数据库的特点及优缺点
1、关系型数据库
2、NoSQL数据库
四、关于数据切分
1、垂直切分
2、水平切分
3、针对数据源管理，目前主要的两种思路
五、Mycat的由来
前言
当今社会一些公司试图通过收购等手段遏制开源产品的发展，那么，那些开源产品爱好者们和贡献者们获得了什么呢？在【无私奉献】的过程中他们获得了知识——信息社会最有价值的资产，他们可以用这些知识以任何形式换来不可估量的财富，信息社会的开源组织使【按劳分配】达到了前所未有的公平与公正。企业所采取的期权激励、扁平化管理、自由工作时间等模式，正是对公司这种生产关系【自顶向下】的改良，以适应持久技术进步带来的生产力的高速发展。但公司的本质：追求股东利益最大化，使其不可能实现真正意义的去中心化。信息社会的开源组织形态是对原有公司模式【自底向上】的一次颠覆式创新，他们将带来生产力的极速发展。这种组织先天具有开放、共享、敏捷、去中心化等等这些可以带来高效率的特性，可以想像拥有杰出技术与高效团队的开源组织可以创造出超越一切公司的更优秀的产品。
关于分布式数据库中间件产品 Mycat，它并不是由任何一家公司主导开发的，而是由民间自发组织的由那些喜爱它的不知名的开源爱好者们协同开发的，而如今该产品的发展速度极快，其影响力也逐渐扩大。国内外类似的开源组织和产品还有很多，这些开源产品潜力无限，无论开发效率和质量都逐渐超越任何一家公司的产品。
开源分布式数据库中间件MyCat架构简介——MyCat源起
一、数据库切分概述：OLTP和OLAP
在互联网时代，海量数据的存储与访问成为系统设计与使用的瓶颈问题，对于海量数据处理，按照使用场景，主要分为两种类型：联机事务处理（OLTP）和联机分析处理（OLAP）。
联机事务处理（OLTP）：也称为面向交易的处理系统，其基本特征是原始数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果。
联机分析处理（OLAP）：是指通过多维的方式对数据进行分析、查询和报表，可以同数据挖掘工具、统计分析工具配合使用，增强决策分析功能。
对于两者的主要区别可以用下表来说明：
二、关系型数据库和NoSQL数据库
针对上面两类系统有多种技术实现方案，存储部分的数据库主要分为两大类：关系型数据库与NoSQL数据库。
关系型数据库：是建立在关系模型基础上的数据库，其借助于集合代数等数学概念和方法来处理数据库中的数据。主流Oracle、DB2、MS SQL Server和mysql都属于这类传统的关系型数据库。
NoSQL数据库：全称为Not Only SQL，意思就是适用关系型数据库的时候就使用关系型数据库，不适用的时候也没有必要非使用关系型数据库不可，可以考虑使用更加合适的数据存储。主要分为临时性键值存储（memcached、Redis）、永久性键值存储（ROMA、Redis）、面向文档的数据库（MongoDB、CouchDB）、面向列的数据库（Cassandra、HBase），每种NoSQL都有其特有的使用场景及优点。
Oracle，MySQL 等传统的关系数据库非常成熟并且已大规模商用，为什么还要用NoSQL数据库呢？主要是由于随着互联网发展，数据量越来越大，对性能要求越来越高，传统数据库存在着先天性的缺陷，即单机（单库）性能瓶颈，并且扩展困难。这样既有单机单库瓶颈，却又扩展困难，自然无法满足日益增长的海量数据存储及其性能要求，所以才会出现了各种不同的NoSQL产品，NoSQL 根本性的优势在于在云计算时代，简单、易于大规模分布式扩展，并且读写性能非常高。
三、关系型数据库和NoSQL数据库的特点及优缺点
1、关系型数据库
特点：
数据关系模型基于关系模型，结构化存储，完整性约束；基于二维表及其之间的联系，需要连接、并、交、差、除等数据操作；采用结构化的查询语言（SQL）做数据读写；操作需要数据的一致性，需要事务甚至是强一致性；
优点：
保持数据的一致性（事务处理）；可以进行join等复杂查询；通用化，技术成熟；
缺点:
数据读写必须经过sql解析，大量数据、高并发下读写性能不足；对数据做读写，或修改数据结构时需要加锁，影响并发操作；无法适应非结构化存储；扩展困难；昂贵、复杂；
2、NoSQL数据库
特点：
非结构化的存储；基于多维关系模型；具有特有的使用场景；
优点：
高并发，大数据下读写能力较强；基本支持分布式，易于扩展，可伸缩；简单，弱结构化存储；
缺点：
join等复杂操作能力较弱；事务支持较弱；通用性差；无完整约束复杂业务场景支持较差；
虽然在云计算时代，传统数据库存在着先天性的弊端，但是NoSQL数据库又无法将其替代，NoSQL只能作为传统数据的补充而不能将其替代，所以规避传统数据库的缺点是目前大数据时代必须要解决的问题。如果传统数据易于扩展，可切分，就可以避免单机（单库）的性能缺陷，但是由于目前开源或者商用的传统数据库基本不支持大规模自动扩展，所以就需要借助第三方来做处理，那就是本文要讲的数据切分，下面就来分析一下如何进行数据切分。
四、关于数据切分
简单来说，就是指通过某种特定的条件，将我们存放在同一个数据库中的数据分散存放到多个数据库（主机）上面，以达到分散单台设备负载的效果。
数据的切分（Sharding）根据其切分规则的类型，可以分为两种切分模式：一种是按照不同的表（或者Schema）来切分到不同的数据库（主机）之上，这种切可以称之为数据的垂直（纵向）切分；另外一种则是根据表中的数据的逻辑关系，将同一个表中的数据按照某种条件拆分到多台数据库（主机）上面，这种切分称之为数据的水平（横向）切分。
垂直切分的最大特点就是规则简单，实施也更为方便，尤其适合各业务之间的耦合度非常低，相互影响很小，业务逻辑非常清晰的系统。在这种系统中，可以很容易做到将不同业务模块所使用的表分拆到不同的数据库中。根据不同的表来进行拆分，对应用程序的影响也更小，拆分规则也会比较简单清晰。
水平切分，水平切分与垂直切分相比，相对来说稍微复杂一些。因为水平切分需要将同一个表中的不同数据拆分到不同的数据库中，对于应用程序来说，拆分规则本身就较根据表名来拆分更为复杂，后期的数据维护也会更为复杂一些。
1、垂直切分
一个数据库由很多表的构成，每个表对应着不同的业务，垂直切分是指按照业务将表进行分类，分布到不同的数据库上面，这样也就将数据或者说压力分担到不同的库上面，如下图：
如上图系统被切分成了商品系统、用户系统、订单系统、购物车系统。
一个架构设计较好的应用系统，其总体功能肯定是由很多个功能模块所组成的，而每一个功能模块所需要的数据对应到数据库中就是一个或者多个表。而在架构设计中，各个功能模块相互之间的交互点越统一越少，系统的耦合度就越低，系统各个模块的维护性以及扩展性也就越好。这样的系统，实现数据的垂直切分也就越容易。
但是往往系统之有些表难以做到完全的独立，存在这扩库join的情况，对于这类的表，就需要去做平衡，是数据库让步业务，共用一个数据源，还是分成多个库，业务之间通过接口来做调用。在系统初期，数据量比较少，或者资源有限的情况下，会选择共用数据源，但是当数据发展到了一定的规模，负载很大的情况，就需要必须去做分割。
一般来讲业务存在着复杂join的场景是难以切分的，往往业务独立的易于切分。如何切分，切分到何种程度是考验技术架构的一个难题。
垂直切分的优点：
拆分后业务清晰，拆分规则明确；系统之间整合或扩展容易；数据维护简单；
垂直切分的缺点：
部分业务表无法join，只能通过接口方式解决，提高了系统复杂度；受每种业务不同的限制存在单库性能瓶颈，不易数据扩展跟性能提高；事务处理复杂；由于垂直切分是按照业务的分类将表分散到不同的库，所以有些业务表会过于庞大，存在单库读写与存储瓶颈，所以就需要水平拆分来做解决；
2、水平切分
相对于垂直拆分，水平拆分不是将表做分类，而是按照某个字段的某种规则来分散到多个库之中，每个表中包含一部分数据。简单来说，我们可以将数据的水平切分理解为是按照数据行的切分，就是将表中的某些行切分到一个数据库，而另外的某些行又切分到其他的数据库中，如图：
这样所有的数据查询join都会在单库内解决；如果从商户的角度来讲，要查询某个商家某天所有的订单数，就需要按照商户ID做拆分；但是如果系统既想按会员拆分，又想按商家数据，则会有一定的困难。如何找到合适的分片规则需要综合考虑衡量。
几种典型的分片规则包括：
按照用户ID求模，将数据分散到不同的数据库，具有相同数据用户的数据都被分散到一个库中；按照日期，将不同月甚至日的数据分散到不同的库中；按照某个特定的字段求摸，或者根据特定范围段分散到不同的库中；
如图，切分原则都是根据业务找到适合的切分规则分散到不同的库，下面根据商品ID（ItemId）求模举例：
水平切分优点：
拆分规则抽象好，join操作基本可以数据库做；不存在单库大数据，高并发的性能瓶颈；应用端改造较少；提高了系统的稳定性跟负载能力；
水平切分的缺点：
拆分规则难以抽象；分片事务一致性难以解决；数据多次扩展难度跟维护量极大；跨库join性能较差；
垂直切分和水平切分的共同的缺点：
引入分布式事务的问题；跨节点join的问题；跨节点合并排序分页问题；多数据源管理问题；
3、针对数据源管理，目前主要的两种思路
第一种：客户端模式，在每个应用程序模块中配置管理自己需要的一个（或者多个）数据源，直接访问各个数据库，在模块内完成数据的整合；
第二种：通过中间代理层来统一管理所有的数据源，后端数据库集群对前端应用程序透明；
可能90%以上的人在面对上面这两种解决思路的时候都会倾向于选择第二种，尤其是系统不断变得庞大复杂的时候。确实，这是一个非常正确的选择，虽然短期内需要付出的成本可能会相对更大一些，但是对整个系统的扩展性来说，是非常有帮助的。
Mycat 通过数据切分解决传统数据库的缺陷，又有了NoSQL易于扩展的优点。通过中间代理层规避了多数据源的处理问题，对应用完全透明，同时对数据切分后存在的问题，也做了解决方案。下面章节就分析，mycat 的由来及如何进行数据切分问题。由于数据切分后数据 join 的难度，在此也分享一下数据切分的经验（四个原则）：
第一原则：能不切分尽量不要切分；第二原则：如果要切分一定要选择合适的切分规则，提前规划好；第三原则：数据切分尽量通过数据冗余或表分组（Table Group）来降低跨库Join的可能；第四原则：由于数据库中间件对数据Join实现的优劣难以把握，而且实现高性能难度极大，业务读取尽量少使用多表join；
五、Mycat的由来
如果我有一个32核心的服务器，我就可以实现1个亿的数据分片，我有32核心的服务器么？没有，所以我至今无法实现1个亿的数据分片。——Mycat's Plan
上面这句话是Mycat 1.0快要完成时候的一段感言，而当发展到Mycat 1.3的时候，又有了一个新的Plan：
如果我们有10台物理机，我们就可以实现1000亿的数据分片，我们有10台物理机么？没有，所以，Mycat至今没有机会验证1000亿大数据的支撑能力——Mycat's Plan 2.0
“每一个成功的男人背后都有一个女人”。自然Mycat也逃脱不了这个法则。Mycat背后是阿里曾经开源的知名产品——Cobar。Cobar的核心功能和优势是 MySQL 数据库分片，此产品曾经广为流传，据说最早的发起者对 Mysql 很精通，后来从阿里跳槽了，阿里随后开源的 Cobar，并维持到年初，然后，就没有然后了。
Cobar 的思路和实现路径的确不错。基于 Java 开发的，实现了 MySQL 公开的二进制传输协议，巧妙地将自己伪装成一个MySQLServer，目前市面上绝大多数 MySQL 客户端工具和应用都能兼容。比自己实现一个新的数据库协议要明智的多，因为生态环境在哪里摆着。Cobar 使用起来也非常方便。由于是基于Java语言开发的，下载下来解压，安装JDK，然后配置几个不是很复杂的配置文件，猛击鼠标，就能启动 Cobar。因此这个开源产品赢得了很多Java粉丝以及PHP用户的追捧。
当然，笨人(Leader us)也跟着进入，并且在某个大型云项目中——“苦海无边”的煎着熬，良久。爱情就像是见鬼。只有撞见了，你才会明白爱情是怎么回事。TA是如此神秘，欲语还羞。情窦初开的你又玩命将TA的优点放大，使自己成为一只迷途的羔羊。每个用过 Cobar 的人就像谈过一段一波三折、荡气回肠的爱情，令你肝肠寸断。就像围城：里面的人已经出不来了，还有更多的人拼命想挤进去。仅以此文，献给哪些努力在IT界寻求未来的精英和小白们，还有更多被无视的，正准备转行的同仁，同在江湖混，不容易啊，面试时候就装装糊涂，放人家一马，说不定，以后又是一个Made in China的乔布斯啊。
曾经的Cobar
Cobar 曾是多少IT骚年心中的那个TA，有关Cobar的这段美好的描述(不能说是广告)俘虏了众多程序猿躁动纯真的心：Cobar是阿里巴巴研发的关系型数据的分布式处理系统，该产品成功替代了原先基于Oracle的数据存储方案，目前已经接管了3000+个MySQL数据库的schema，平均每天处理近50亿次的SQL执行请求。
50亿有多大？99%的普通人类看到这个数字，已经不能呼吸。当然，我指的是-RMB。99%的程序猿除了对工资比较敏感，其实对数字通常并不感冒。上面这个简单的数字描述，已立刻让我们程序型的大脑短路。恨不得立刻百度Cobar，立刻Download，立刻熬夜研究。做个简单的推算，50亿次请求转换为每个schema每秒的数据访问请求即TPS，于是我们得到一个让自己不能相信的数字：20TPS，每秒不到20个访问。
Cobar最重要的特性是分库分表。Cobar可以让你把一个MySQL的Table放到10个甚至100个位于不同物理机上的MySQL服务器上去存储，而在用户看来是一张表（逻辑表）。这样功能很有价值。比如：我们有1亿的订单，则可以划分为10个分片，存储到2-10个物理机上。每个MySQL服务器的压力减少，而系统的响应时间则不会增加。看上去很完美的功能，而且潜意识里，执行这句SQL：select count(*) from employee，对于这类的SQL，100%的人都会认为：会返回1条数据，但事实上，Cobar会返回N条数据，N=分片个数。接下来我们继续执行SQL:select count(*) from employeeorder by employee_date你会发现奇怪的乱序现象，而且结果还随机，这是因为，Cobar只是简单的把上述SQL发给了后端N个分片对应的MySQL服务器去执行，然后把结果集直接输出….再继续看看，我们常用的Limit分页的结果…可以么？答案是：<不可以>，这个问题可以在客户端程序里做些工作来解决。所以随后出现了Cobar Client。据我所知，很多Cobar的使用者也都是自行开发了类似Cobar Client的工具来解决此类问题。从实际应用效果来说，一方面，客户端编程方式解决，困难度很高，Bug率也居高不下；另一方面，对于DBA和运维来说，增加了困难度。当你发现这个问题的严重性，再回头看看Cobar的官方文档，你会怅然若失，四顾茫然。
Mycat 闪耀登场
当大批软件工程师开始觉醒，用互联网思维思考和规划自己的人生，第四次工业革命才拉开序幕——《Mycat宣言》Mycat最早的版本完成于年底，实现于雾霾中的北京城。Mycat 要解决的第一个问题就是要将Cobar后端实现为非阻塞模式。
将 Cobar 从“个人版”提升到真正的“企业版”。据未经证实的渠道了解，非开源的 Cobar 内部版本已经实现后端 NIO，但是并没有开源出来。于是 Mycat 注定要诞生了，尽管可能不会是Leader-us 发起的。但软件界里，总会有那么一些桀骜（jié ào）不驯的人，用一个电脑，在某一个不经意的晚上，写了一段代码，惊艳了这个世界。Mycat 的前身是 OpencloudDB，而现在的 Mycat QQ 群则用来开发一个叫做 Mycloud OA 的云平台的 SAAS 企业办公软件的，半年的时间里，这个群聚集了一大帮IT人，拥有超过10个“顾问”头衔的、超过十个“架构师”头衔的、超过20个“研发”头衔的庞大志愿者团队，然后，仅有不到3个人提交过文档和少量代码，其他的人都很专业的谈论着需求、谈论着框架、谈论着市场，最后的最后，大家都变成了资深酱油瓶，于是 Mycloud OA 出师未捷身先死。
OpencloudDB 改名为 Mycat，一个原因是简单好记，另外一个原因，是打算未来入驻 Apache。因为 Apache Tomcat 也是一 只猫，从年龄来看，Tomcat 算是 Mycat 表姐吧，从相貌身材来看，Tomcat 她表妹，绝对是东方第一萌妹子，虽然目前 Rainbow 大侠设计的 Mycat Logo，看起来是个 100% 的女汉子。Mycat 1.0的发布，立即引起不少人的关注，曾经参与 Mycloud OA 开发的一些小伙伴陆续加入进来，资深酱油师Michael 还注册了一个 opencloud DB 的网站，随后又实现了 Mycat 全局序列号（基于文件方式）；一些了解或使用过 Cobar 的同学也陆续加入，网名为无影的大侠，提供了最早的 Mycat 分页排序的源码，最早在生产系统上部署了 Mycat 并且采用 HA Proxy 方式做高可用方案；随后，一个叫做小鱼的 PHP 高手，在不到3个月时间内，用 Mycat 改造了原先的电商系统。后来又有一些美容美发的 SAAS 创业项目采用了 Mycat；再后来，一些比较大的电信软件领域的公司和项目开始使用 Mycat，他们中的大多数都对 Mycat 做过不少的贡献，比如测试，Bug 修复等。
直到今天，Mycat 核心研发团队里的大多数人，都是来自上述这些公司。Mycat １.3的诞生，是 Mycat 历史上最重大的一个里程碑。在这个版本里，需求、测试和功能开发各项工作，首次从个人为主变为开源团队为主的模式，更多的人参与到需求、开发、测试以及Bug修复活动中，基本上确定的 Bug 都在24小时内修复并有志愿者或用户确认修复。Mycat 1.3版本的性能与1.2比提升巨大，功能更完备，这是因为包括武、成都-研发、冰峰影、Leader-us 等实力派编程高手各自负责一部分重要模块并一起协同研发，后来又加入聆听、从零开始、南哥、Mclaren、兵临城下等新的一批实力派编程达人，以及正在排队等待收编的PCY实力派干将，其他关于参与 Mycat 官网建设、文档编写和翻译的就更多了（当然也失联很多）。截至目前，Mycat 志愿者团队有以 Marshy 大美女为首的负责官网和广告的团队，以 Leader-us 为首的负责 Mycat-Server 研发的团队、以 Rainbow 为首的 Mycat-Web 的研发团队、以海王星为首的 QA 团队，以及群龙无首的测试团队和DBA团队。
此外，Mycat 开源社区正在进一步强化数据库监控、智能调优等方面的功能，未来将实现一键优化的能力，根据拦截到的SQL的执行统计数据，自动分析热点数据、给出建议的索引和优化措施以及读写分离的建议，DBA一键完成优化，数据迁移也将可以在节目上点击鼠标完成。Mycat 截至到4月，保守估计已经有超过60个项目在使用，主要应用在电信领域、互联网项目，大部分是交易和管理系统，少量是信息系统。比较大的系统中，数据规模单表单月30亿。以后 Mycat 和 Mycat 社区成为IT和互联网创业的最佳伴侣。
参考文献：
MyCat官网：【MyCat官方网站】
GitHub：【MyCATApache】
Issues：【Mycat-Server-issues】
MyCat指南：【MyCat指南CSDN】
好了，关于开源分布式数据库中间件MyCat架构简介——MyCat源起 就写到这儿了，如果还有什么疑问或遇到什么问题欢迎扫码提问，也可以给我留言哦，我会一一详细的解答的。
歇后语：“ 共同学习，共同进步 ”，也希望大家多多关注CSND的IT社区。
开源分布式数据库中间件MyCat架构简介（一）——基于MyCat的分库分表 读写分离 水平切分和垂直切分实现原理
如果觉得《开源分布式数据库中间件MyCat架构简介（一）——基于MyCat的分库分表 读写分离 水平》对你有帮助，请点赞、收藏，并留下你的观点哦！
