分库分表.md

一：简介

大中型项目，一旦数据量比较大，就要进行对数据的拆分了，一般有两种，垂直拆分与水平拆分。
mysql 一般单表 500 万条，存储上限 256TB
垂直分库：
一个数据库的数据库量大，拆分出订单库和用户库
垂直分库是指按照业务将表进行分类，分布到不同的数据库上面，每个库放在不同的服务器上，其核心思想是专库专用。
优点：
解决业务层面的耦合，业务清晰，能对不同业务进行分级管理，维护，监控，扩展等。高并发场景下，垂直分库一定程度上提升 IO。但是依然没有解决单表数据量过大的问题。

拆分思想

随着业务增长，可以将订单数据划分成两大类型：分别是热数据和冷数据。

  • 热数据：3 个月内的订单数据，查询实时性较高;使用 mysql 进行存储，当然需要分库分表；
  • 冷数据 A：3 个月 ~ 12 个月前的订单数据，查询频率不高;对于这类数据可以存储在 ES 中，了利用搜索引擎特性基本上可以做到较快的查询
  • 冷数据 B：1 年前的订单数据，几乎不会查询，只有偶尔的查询需求;对于这类不经常查询的数据，可以存放到 Hive 中。

    Hash 取模方案

    以水平分表为例

在我们设计系统之前，可以先预估一下大概这几年的订单量，如：4000 万。每张表我们可以容纳 1000 万，也我们可以设计 4 张表进行存储。

  • 优点：

订单数据可以均匀的放到那 4 张表中，这样此订单进行操作时，就不会有热点问题。

  • 缺点：

将来的数据迁移和扩容，会很难。数据不连续

Range 范围方案

以水平分表为例

优点：有利于扩容，不需要数据迁移
缺点：有热点问题

分组思想

先按范围进行分组。比如 0-4000 万分到 group1，然后 group1 中再进行 Hash 分，这样当扩容的时候，直接新增一个 group2，存储 4000 万到 8000 万的数据。然后每个组里的表或者库再进行 Hash 分。

水平分表

分表时要选择适当的分表策略，是的数据能够较为均匀的分到不同的表中，并且不影响查询。
大部分数据都是与用户关联的，因此，用户 id 是最常用的分表字段。因为大部分查询都需要带上用户 id，这样既不影响查询，又能够使数据较为均衡地分布到各个表中(当然，有的场景也可能会出现冷热数据分布不均衡的情况)。
拆分的记录根据user_id%256取得对应的表进行存储，前台应用则根据对应的 user_id%256，找到对应订单存储的表进行访问。（即 id 除以 256 余数为 0 则查 0 号表）

垂直分表：

比如当用户浏览商品列表时，只有感兴趣的才会查看商品的详细描述，且该字段存储空间较大，访问频次低，只有商品名称，商品价格等字段是用户关心的，访问频次高。故可以将商品信息表拆分成两张表

这样可以避免 IO 争抢并减少锁表的几率，查看详情与商品信心浏览互不影响。

垂直分库

垂直分库是原本库里有三张表，现在每个库里有一张表

水平分库

分表能够解决单表数据量过大带来的查询效率下降的问题，但是，却无法给数据库的并发处理能力带来质的提升。面对高并发的读写访问，当数据库 master 服务器无法承载写操作压力时，不管如何扩展 slave 服务器，此时都没有意义了。
水平分库就是每个库的表都还是一样的， 只是将数据分散到不同的库里
分库可以采用通过一个关键字取模的方式
分库分表 - 图1

读写分离

读写分离一般适用于主从结构，从节点负责读，主节点负责写

分库分表

有时数据库可能既面临着高并发访问的压力，又需要面对海量数据的存储问题，这时需要对数据库既采用分表策略，又采用分库策略，以便同时扩展系统的并发处理能力，以及提升单表的查询性能，这就是所谓的分库分表。
分库分表的策略比前面的仅分库或者仅分表的策略要更为复杂，一种分库分表的路由策略如下：

  1. 中间变量 = user_id % (分库数量 * 每个库的表数量)
  2. 库 = 取整数 (中间变量 / 每个库的表数量)
  3. 表 = 中间变量 % 每个库的表数量

    如何做分库分表

    1：根据业务分成用户，商品，订单模块，每个对应不同的库

将不同的业务放到不同的库中，将原来所有压力由同一个库中分散到不同的库中，提升系统吞吐量
分表策略
order_id%100 方式，但这种……加库怎么办？范围查询怎么办？根据 user_id 查怎么办？

主流框架

数据库中间件分为两类

  • proxy：中间经过一层代理，需要独立部署
  • client：在客户端就知道指定到那个数据库

各个中间件：

  • shardingSphere

当当开源的，属于 client 层方案。确实之前用的还比较多一些，因为 SQL 语法支持也比较多，没有太多限制，而且目前推出到了 2.0 版本，支持分库分表、读写分离、分布式 id 生成、柔性事务（最大努力送达型事务、TCC 事务）。而且确实之前使用的公司会比较多一些（这个在官网有登记使用的公司，可以看到从 2017 年一直到现在，是不少公司在用的），目前社区也还一直在开发和维护，还算是比较活跃，个人认为算是一个现在也可以选择的方案。
sharding-jdbc 这种 client 层方案的优点在于不用部署，运维成本低，不需要代理层的二次转发请求，性能很高，但是如果遇到升级啥的需要各个系统都重新升级版本再发布，各个系统都需要耦合 sharding-jdbc 的依赖；

基于 cobar 改造的，属于 proxy 层方案，支持的功能非常完善，而且目前应该是非常火的而且不断流行的数据库中间件，社区很活跃，也有一些公司开始在用了。但是确实相比于 sharding jdbc 来说，年轻一些，经历的锤炼少一些。
mycat 这种 proxy 层方案的缺点在于需要部署，自己及运维一套中间件，运维成本高，但是好处在于对于各个项目是透明的，如果遇到升级之类的都是自己中间件那里搞就行了。

问题

事务问题

方案一：使用分布式事务

  • 优点：交由数据库管理，简单有效
  • 缺点：性能代价高，特别是 shard 越来越多时

方案二：由应用程序和数据库共同控制

  • 原理：将一个跨多个数据库的分布式事务分拆成多个仅处 于单个数据库上面的小事务，并通过应用程序来总控 各个小事务。
  • 优点：性能上有优势
  • 缺点：需要应用程序在事务控制上做灵活设计。如果使用 了spring的事务管理，改动起来会面临一定的困难。

    唯一主键

    参考：业务 ID 的生成方式

    跨节点语句

    join
    count(*)
    order by
    分页：我们需要在不同的分片节点中将数据进行排序并返回，并将不同分片返回的结果集进行汇总和再次排序，最后再返回给用户。
    取出第十页，每页 10 个

分别在各个节点上得到结果后在应用程序端进行合并。

数据迁移

现在有一个未分库分表的系统，未来要分库分表，如何设计才可以让系统从未分库分表动态切换到分库分表上？

停机迁移方案：

双写迁移方案：

就是在线上系统里面，之前所有写库的地方，增删改操作，都除了对老库增删改，都加上对新库的增删改，这就是所谓双写，同时写俩库，老库和新库。
跑起来读老库数据读到写入新库，写的时候要根据 gmt_modified 这类字段判断这条数据最后修改的时间，除非是读出来的数据在新库里没有，或者是比新库的数据新才会写。
接着导完一轮之后，有可能数据还是存在不一致，那么就程序自动做一轮校验，比对新老库每个表的每条数据，接着如果有不一样的，就针对那些不一样的，从老库读数据再次写。反复循环，直到两个库每个表的数据都完全一致为止。

容量规划，扩容问题

来自淘宝综合业务平台团队，它利用对 2 的倍数取余具有向前兼容的特性（如对 4 取余得 1 的数对 2 取余也是 1）来分配数据，避免了行级别的数据迁移，但是依然需要进行表级别的迁移，同时对扩容规模和分表数量都有限制。

停机扩容

导数工具