cobar

之前 有不少刚入坑 Java 的粉丝留言，想系统的学习一下分库分表相关技术，可我一直没下定决心搞，眼下赶上公司项目在使用 sharing-jdbc 对现有 MySQL 架构做分库分表的改造，所以借此机会出一系分库分表落地实践的文章，也算是自己对架构学习的一个总结。 我在网上陆陆续续的也看了一些有关于分库分表的文章，可发现网上同质化的资料有点多，而且知识点又都比较零碎，还没有详细的实战案例。为了更深入的学习下，我在某些平台买了点付费课程，看了几节课发现有点经验的人看还可以，但对于新手入门来说，其实学习难度还是蛮大的。 为了让新手也能看得懂，有些知识点我可能会用更多的篇幅加以描述，希望大家不要嫌我啰嗦，等这分库分表系列文章完结后，我会把它做成 PDF 文档开源出去，能帮一个算一个吧！如果发现文中有哪些错误或不严谨之处，欢迎大家交流指正。 具体实践分库分表之前在啰嗦几句，回头复习下分库分表的基础概念。 什么是分库分表 其实 分库 和 分表 是两个概念，只不过通常分库与分表的操作会同时进行，以至于我们习惯性的将它们合在一起叫做分库分表。 分库分表是为了解决由于库、表数据量过大，而导致数据库性能持续下降的问题。按照一定的规则，将原本数据量大的数据库拆分成多个单独的数据库，将原本数据量大的表拆分成若干个数据表，使得单一的库、表性能达到最优的效果（响应速度快），以此提升整体数据库性能。

点击上方“ 猿程之家 ”，选择“置顶公众号” 关键时刻，第一时间送达！ 阅读本文需要5分钟 一. 数据切分 关系型数据库本身比较容易成为系统瓶颈，单机存储容量、连接数、处理能力都有限。当单表的数据量达到1000W或100G以后，由于查询维度较多，即使添加从库、优化索引，做很多操作时性能仍下降严重。此时就要考虑对其进行切分了，切分的目的就在于减少数据库的负担，缩短查询时间。 数据库分布式核心内容无非就是数据切分（Sharding） ，以及切分后对数据的定位、整合。数据切分就是将数据分散存储到多个数据库中，使得单一数据库中的数据量变小，通过扩充主机的数量缓解单一数据库的性能问题，从而达到提升数据库操作性能的目的。 数据切分根据其切分类型，可以分为两种方式：垂直（纵向）切分和水平（横向）切分 1、垂直（纵向）切分 垂直切分常见有垂直分库和垂直分表两种。 垂直分库 就是根据业务耦合性，将关联度低的不同表存储在不同的数据库。做法与大系统拆分为多个小系统类似，按业务分类进行独立划分。与"微服务治理"的做法相似，每个微服务使用单独的一个数据库。如图： 垂直分表 是基于数据库中的"列"进行，某个表字段较多，可以新建一张扩展表，将不经常用或字段长度较大的字段拆分出去到扩展表中。在字段很多的情况下（例如一个大表有100多个字段），通过"大表拆小表"，更便于开发与维护，也能避免跨页问题

我在网上陆陆续续的也看了一些有关于分库分表的文章，可发现网上同质化的资料有点多，而且知识点又都比较零碎，还没有详细的实战案例。 为了更深入的学习下，我在某些平台买了点付费课程，看了几节课发现有点经验的人看还可以，但对于新手入门来说，其实学习难度还是蛮大的。 为了让新手也能看得懂，有些知识点我可能会用更多的篇幅加以描述，希望大家不要嫌我啰嗦，等这分库分表系列文章完结后，我会把它做成 PDF 文档开源出去，能帮一个算一个吧！如果发现文中有哪些错误或不严谨之处，欢迎大家交流指正。 具体实践分库分表之前在啰嗦几句，回头复习下分库分表的基础概念。 什么是分库分表 其实 分库 和 分表 是两个概念，只不过通常分库与分表的操作会同时进行，以至于我们习惯性的将它们合在一起叫做分库分表。 分库分表是为了解决由于库、表数据量过大，而导致数据库性能持续下降的问题。按照一定的规则，将原本数据量大的数据库拆分成多个单独的数据库，将原本数据量大的表拆分成若干个数据表，使得单一的库、表性能达到最优的效果（响应速度快），以此提升整体数据库性能。 如何分库分表 分库分表的核心理念就是对数据进行切分（ Sharding ），以及切分后如何对数据的快速定位与查询结果整合。而分库与分表都可以从： 垂直 （纵向）和 水平 （横向）两种纬度进行切分。 分库分表 下边我们就以订单相关的业务举例，看看如何做库、表的 垂直 和

在斯坦福大学, 乔布斯做了一场我认为他最精彩的演讲之一 (另一场可能是iphone的问世发布会)。他讲了第一个故事 "connecting the dots" 你不可能充满预见地将生命的点滴串联起来；只有在你回头看的时候，你才发现这些点点滴滴之间的联系。所以，你要坚信，你现在所经历的将在你未来的生命中串联起来。你不得不相信某些东西，你的直觉、命运、生活、因缘际会……正是这种信仰让我不会失去希望，它让我的人生变得与众不同。 什么是连接生命中的点滴呢？我的理解:当一个人的能力还在上升期, 格局和视野还不够广阔的时候,他需要专注当前的事情,并且把每件事情做到他当时的能力所能做到的极限,也许当时没有那么大的成就感,但"蓦然回首,那人却在灯火阑珊处"。 十年前刚进入IT这个行业的时候,我是一个很普通的工程师,脑袋也不灵光,工作老是得不到要领,我的同学智商很高,他看一次代码基本就会写了,我得花很长时间去消化吸收,我对自己能不能在这一行生存下去都产生了质疑。 没有办法,只能勤能补拙,笨鸟先飞, 当遇到问题的时候, 我都抱着死咬不放的心态去寻找最佳解决方案, 洗澡的时候，睡觉的时候，吃饭的时候，甚至上厕所的时候都会去思考。很自然的,"追"源码也成为我程序生命中的一部分。 阅读过很多源码，和大家分享几个对我的职业影响比较大的追源码的经历。 正文 1 Druid 连接池 这是在2013年

如果你期待对分布式系统有一个更全面的认识，想要了解各个技术在分布式系统中如何应用、分别解决哪些问题、有怎样优秀的实现，推荐阅读、收藏本篇。 前言 分布式系统涉及到的理论知识及技术点比较多，以致于很多童鞋都说，分布式系统的学习是入门容易、深入难，通过网络搜索到的知识点较为零散，难以系统化学习、融会贯通。本篇Mike将从以下几个方面分享，带着大家先窥探分布式的全貌，希望为大家厘清分布式学习之路的方向与具体路径。 以上专题资料及学习图谱，获取方式：添加下方小助手VX即可 本篇主题 分布式系统的概念 分布式系统的作用 分布式系统的特性 分布式系统主流技术 分布式系统专题合集及知识图谱 分布式系统的概念 分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。有一种说法：分布式系统是若干独立计算机的组合共同对用户提供服务，但对于用户来说，这些计算机就像是单个相关系统。 布式系统的作用 分布式系统的出现是为了用廉价的、普通的机器完成单个计算机无法完成的计算、存储任务。其目的是利用更多的机器，处理更多的数据。 分布式系统的特性 布式系统特性主要有透明性、可扩展性、可用性、可靠性、高性能、一致性等。这几个特性是分布式系统的主要衡量指标，开始分布式系统的学习，从了解分布式系统的特性开始。 1、透明性 分布式的特征之一是向用户隐藏系统的内部组织结构，各种计算机之间的差别

大家好，我是小富~ 之前有不少刚入坑 Java 的粉丝留言，想系统的学习一下分库分表相关技术，可我一直没下定决心搞，眼下赶上公司项目在使用 sharding-jdbc 对现有 MySQL 架构做分库分表的改造，所以借此机会出一系分库分表落地实践的文章，也算是自己对架构学习的一个总结。 我在网上陆陆续续的也看了一些有关于分库分表的文章，可发现网上同质化的资料有点多，而且知识点又都比较零碎，还没有详细的实战案例。为了更深入的学习下，我在某些平台买了点付费课程，看了几节课发现有点经验的人看还可以，但对于新手入门来说，其实学习难度还是蛮大的。 为了让新手也能看得懂，有些知识点我可能会用更多的篇幅加以描述，希望大家不要嫌我啰嗦，等这分库分表系列文章完结后，我会把它做成 PDF 文档开源出去，能帮一个算一个吧！如果发现文中有哪些错误或不严谨之处，欢迎大家交流指正。 具体实践分库分表之前在啰嗦几句，回头复习下分库分表的基础概念。 什么是分库分表 其实 分库 和 分表 是两个概念，只不过通常分库与分表的操作会同时进行，以至于我们习惯性的将它们合在一起叫做分库分表。 分库分表是为了解决由于库、表数据量过大，而导致数据库性能持续下降的问题。按照一定的规则，将原本数据量大的数据库拆分成多个单独的数据库，将原本数据量大的表拆分成若干个数据表，使得单一的库、表性能达到最优的效果（响应速度快）

目录 1.为什么需要中间件 不分库篇 （1）普通的应用程序 （2）并发读写大--缓存 （3）缓存过期问题--读写分离+缓存 （4）隔离对DAO层影响--数据库中间件+读写分离+缓存 （5）业务模块多--集群+数据库中间件+读写分离+缓存 分库篇 （1）业务模块多，数据总量大--分库+缓存 （2）分库对Dao层代码影响--分库+数据库中间件+缓存 （3）读写压力大--分库+读写分离+数据库中间件+缓存 2.数据库中间价设计要点 （1）垂直拆分 （2）水平拆分 （3）无论是垂直拆分、水平拆分，都有共同的技术难点 （4）数据库中间件的两种实现模式 （5）常用数据库中间件简介 小结 1.为什么需要中间件 不分库篇 （1）普通的应用程序 数据库访问 数据库存储的数据量不是很大，但并发的读写操作都很大，超过数据库服务器的处理能力。 阿里云-RDS版MySQL性能测试结果（MySQL 5.6） TPS：每秒钟处理事务数量 QPS：每秒钟SQL语句执行条数（并发请求数） （2）并发读写大–缓存 业务场景 ：数据量不是很大，仅并发读写超过数据库服务器的处理能力 解决办法 ： 加缓存 （3）缓存过期问题–读写分离+缓存 业务场景 ：缓存会有过期命不中，还是会有大量的读和全部的写操作将请求数据库，如果数据库支持不起，怎么办？ 解决办法 ：读写分离+缓存 （4）隔离对DAO层影响–数据库中间件+读写分离

1.什么是MyCat MyCAT是一款由阿里Cobar演变而来的用于支持数据库，读写分离、分表分库的分布式中间件。MyCAT支持Oracle、MSSQL、MYSQL、PG、DB2关系型数据库，同时也支持MongoDB等非关系型数据库。 MyCAT原理MyCAT主要是通过对SQL的拦截，然后经过一定规则的分片解析、路由分析、读写分离分析、缓存分析等，然后将SQL发给后端真实的数据块，并将返回的结果做适当处理返回给客户端。 2.基于MyCat实现读写分离 读写分离，简单地说是把对数据库的读和写操作分开，以对应不同的数据库服务器。主数据库提供写操作，从数据库提供读操作，这样能有效地减轻单台数据库的压力。主数据库进行写操作后，数据及时同步到所读的数据库，尽可能保证读、写数据库的数据一致，比如MySQL的主从复制、Oracle的data guard、SQL Server的复制订阅等。 3.安装Mycat 安装前准备 三台服务器（关闭防火墙） mycat安装服务器：192.168.223.140 主数据库：192.168.223.141 从数据库：192.168.223.142 读写分离前提是：实现主从复制，主从复制请参考 《主从复制原理》 1 、上传安装Mycat - server - 1.6 .5 - release - 20180122220033 - linux . tar 2

首先采用Mysql存储千亿级的数据，确实是一项非常大的挑战。Mysql单表确实可以存储10亿级的数据，只是这个时候性能非常差，项目中大量的实验证明，Mysql单表容量在500万左右，性能处于最佳状态。 针对大表的优化，主要是通过数据库分库分表来解决， 目前比较普遍的方案有三个：分区，分库分表，NoSql/NewSql。 实际项目中，这三种方案是结合的，目前绝大部分系统的核心数据都是以RDBMS存储为主，NoSql/NewSql存储为辅。 分区 首先来了解一下分区方案。 分区表是由多个相关的底层表实现的。这些底层表也是由句柄对象表示，所以我们也可以直接访问各个分区，存储引擎管理分区的各个底层表和管理普通表一样（所有的底层表都必须使用相同的存储引擎），分区表的索引只是在各个底层表上各自加上一个相同的索引。这个方案对用户屏蔽了sharding的细节，即使查询条件没有sharding column，它也能正常工作（只是这时候性能一般）。 不过它的缺点很明显： 很多的资源都受到单机的限制，例如连接数，网络吞吐等。如何进行分区，在实际应用中是一个非常关键的要素之一。 下面开始举例： 以客户信息为例，客户数据量5000万加，项目背景要求保存客户的银行卡绑定关系，客户的证件绑定关系，以及客户绑定的业务信息。 此业务背景下，该如何设计数据库呢。项目一期的时候，我们建立了一张客户业务绑定关系表

为什么要分库分表（设计高并发系统的时候，数据库层面该如何设计）？用过哪些分库分表中间件？不同的分库分表中间件都有什么优点和缺点？你们具体是如何对数据库如何进行垂直拆分或水平拆分的？ 面试官心理分析 其实这块肯定是扯到 高并发 了，因为分库分表一定是为了 支撑高并发、数据量大 两个问题的。而且现在说实话，尤其是互联网类的公司面试，基本上都会来这么一下，分库分表如此普遍的技术问题，不问实在是不行，而如果你不知道那也实在是说不过去！ 面试题剖析 为什么要分库分表？（设计高并发系统的时候，数据库层面该如何设计？） 说白了，分库分表是两回事儿，大家可别搞混了，可能是光分库不分表，也可能是光分表不分库，都有可能。 我先给大家抛出来一个场景。 假如我们现在是一个小创业公司（或者是一个 BAT 公司刚兴起的一个新部门），现在注册用户就 20 万，每天活跃用户就 1 万，每天单表数据量就 1000，然后高峰期每秒钟并发请求最多就 10 个。我的天，就这种系统，随便找一个有几年工作经验的，然后带几个刚培训出来的，随便干干都可以。 结果没想到我们运气居然这么好，碰上个 CEO 带着我们走上了康庄大道，业务发展迅猛，过了几个月，注册用户数达到了 2000 万！每天活跃用户数 100 万！每天单表数据量 10 万条！高峰期每秒最大请求达到 1000！同时公司还顺带着融资了两轮，进账了几个亿人民币啊