“分库分表 不注意选型和流程的话，容易失控
|
Atlas、Kingshard、DBProxy、mysql router、MaxScale、58 Oceanus、ArkProxy、Ctrip DAL、Tsharding、Youtube vitess、网易DDB、Heisenberg、proxysql、Mango、DDAL、Datahekr、MTAtlas、MTDDL、Zebra、Cobar、Cobar 汗、几乎每个大厂都有自己的数据库中间件(还发现了几个喜欢拿开源组件加公司前缀作为产品的)，只不过不给咱用罢了。 流程解决方案 无论是采用哪个层面切入进行分库分表，都面临以下工作过程。
信息收集 统计影响的业务和项目 项目范围越大，分库难度越高。有时候，一句复杂的SQL能够涉及四五个业务方，这种SQL都是需要重点关注的。 确定分库分表的规模，是只分其中的几张表，还是全部涉及。分的越多，工作量越大，几乎是线性的。 还有一些项目是牵一发动全身的。举个例子，下面这个过程，影响的链路就不仅是分库这么简单了。
确定参与人员 除了分库分表组件的技术支持人员，最应该参与的是对系统、对现有代码最熟悉的几个人。只有他们能够确定哪些SQL该废弃掉、SQL的影响面等。 确定分库分表策略 确定分库分表的维度和切分键。切分键(就是路由数据的column)一旦确定，是不允许修改的，所以在前期架构设计上，应该首先将其确立下来，才能进行后续的工作;数据维度多意味着有不同的切分键，达到不同条件查询的效果。这涉及到数据的冗余(多写、数据同步)，会更加复杂。 前期准备 数据规整 库表结构不满足需求，需要提前规整。比如，切分键的字段名称不同或者类型各异。在实施分库分表策略时，这些个性会造成策略过大不好维护。 扫描所有SQL 将项目中所有的SQL扫描出来，逐个判断是否能够按照切分键正常运行。 在判断过程中肯定会有大量不合规的SQL，则都需要给出改造方案，这是主要的工作量之一。 验证工具支持 直接在原有项目上进行改动和验证是可行的，但会遇到诸多问题，主要是效率太低。我倾向于首先设计一些验证工具，输入要验证的SQL或者列表，然后打印路由信息和结果进行判断。 技术准备 建议以下提到的各个点，都找一个例子体验一下，然后根据自己的团队预估难度。 以下： 中间件所有不支持的SQL类型 整理容易造成崩溃的注意事项 不支持的SQL给出处理方式 考虑一个通用的主键生成器 考虑没有切分键的SQL如何处理 考虑定时任务等扫全库的如何进行遍历 考虑跨库跨表查询如何改造 准备一些工具集 实施阶段 数据迁移 分库分表会重新影响数据的分布，无论是全量还是增量，都会涉及到数据迁移，所以Databus是必要的。 一种理想的状态是所有的增删改都是消息，可以通过订阅MQ进行双写。
但一般情况下，仍然需要去模拟这个状态，比如使用Canal组件。
怎么保证数据安全的切换，我们分其他章节进行讨论。 充足的测试 分库分表必须经过充足的测试，每一句SQL都要经过严格的验证。如果有单元测试或者自动化测试工具，完全的覆盖是必要的。一旦有数据进行了错误的路由，尤其是增删改，将会创造大量的麻烦。 在测试阶段，将验证过程输出到单独的日志文件，充足测试后review日志文件是否有错误的数据流向。 SQL复验 强烈建议统一进行一次SQL复验。主要是根据功能描述，确定SQL的正确性，也就是通常说的review。 演练 在非线上环境多次对方案进行演练，确保万无一失。 制定新的SQL规范 分库分表以后，项目中的SQL就加了枷锁，不能够随意书写了。很多平常支持的操作，在拆分环境下就可能运行不了了。所以在上线前，涉及的SQL都应该有一个确认过程，即使已经经过了充足的测试。 题外话 没有支持的活别接，干不成。 （编辑：晋中站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
