高性能MySql系列-分库分表和数据异构技术

分库分表

中间件：sharding-jdbc/cobar/mycat等中间件。
分表维度：如用户ID/订单ID等。
分表算法：取模/哈希/路由表等。
分库分表具体技术不做详细介绍，本文主要想聊下数据异构问题。

分库分表实际面临的问题

1.选择哪种分库分表的方式？

• 一种是按照 range 来分，就是每个库一段连续的数据，这个一般是按比如时间范围来的，但是这种一般较少用，因为很容易产生热点问题（如冷热订单数据），大量的流量都打在最新的数据上了。
• 或者是按照某个字段 hash 一下均匀分散，这个较为常用。

2.如何设计可以动态扩容缩容的分库分表方案？
谈分库分表的扩容，第一次分库分表，就一次性给他分个够，32 个库，1024 张表，可能对大部分的中小型互联网公司来说，已经可以支撑好几年了。
具体步骤：

1. 设定好几台数据库服务器，每台服务器上几个库，每个库多少个表，推荐是 32 库 * 32 表，对于大部分公司来说，可能几年都够了。
2. 路由的规则，orderId 模 32 = 库，orderId / 32 模 32 = 表
3. 扩容的时候，申请增加更多的数据库服务器，装好 MySQL，呈倍数扩容，4 台服务器，扩到 8 台服务器，再到 16 台服务器。
4. 由 DBA 负责将原先数据库服务器的库，迁移到新的数据库服务器上去，库迁移是有一些便捷的工具的。
5. 我们这边就是修改一下配置，调整迁移的库所在数据库服务器的地址。
6. 重新发布系统，上线，原先的路由规则变都不用变，直接可以基于 n 倍的数据库服务器的资源，继续进行线上系统的提供服务。

3.现在有一个未分库分表的系统，未来要分库分表，如何设计才可以让系统从未分库分表动态切换到分库分表上？
双向迁移方案：
简单来说，就是在线上系统里面，之前所有写库的地方，增删改操作，除了对老库增删改，都加上对新库的增删改，这就是所谓的双写，同时写俩库，老库和新库。

然后系统部署之后，新库数据差太远，用数据迁移工具，跑起来读老库数据写新库，写的时候要根据 DataChange_LastTime 这类字段判断这条数据最后修改的时间，除非是读出来的数据在新库里没有，或者是比新库的数据新才会写。简单来说，就是不允许用老数据覆盖新数据。

导完一轮之后，有可能数据还是存在不一致，那么就程序自动做一轮校验，比对新老库每个表的每条数据，接着如果有不一样的，就针对那些不一样的，从老库读数据再次写。反复循环，直到两个库每个表的数据都完全一致为止。

接着当数据完全一致了，就 ok 了，基于仅仅使用分库分表的最新代码，重新部署一次，不就仅仅基于分库分表在操作了么，还没有几个小时的停机时间，很稳。所以现在基本玩儿数据迁移之类的，都是这么干的。

数据异构

分库分表虽然解决了超大数据量导致的性能瓶颈问题，但也带来了新的难题。比如，如何跨库join聚合查询？如何全局排序/分组？
常见的解决办法是通过数据异构的手段。比如ES搜索异构，缓存异构等。

正式介绍前，我们来回顾下MySql主从复制的架构。

Canal中间件就类似于这里的slave角色，它可以订阅数据库的binlog日志，然后进行数据消费，比如数据镜像、数据异构、数据索引、缓存同步等。
Canal架构：

Canal应用场景：


Canal代码示例（省略了配置）