分库分表实战场景分析

背景：目前需支撑交易表日五千万数据，后续完全切量到此新系统

数据库：四个部署在Aix系统上的Oracle库、每个库一张交易主表(按日31个物理分区)、十二个交易历史表（无分区）

服务节点：每个Oracle库都对应着多个服务节点

流量入口：业务网关

路由规则：用户ID末两位进行路由

---

一阶段：此为正常上云后流程

        流量经过业务网关路由后到达业务系统，根据当前轧差日期来放入交易主表具体分区，月初会新起调度节点进行历史数据的清理，上面描述了主表有31个物理分区（这里的分区对应表结构是一个字段，包含在唯一索引中），每天会将指定日期之前的数据挪移到十二张历史表中，在进行清理的时候理论上只会影响到当前所使用的分区，对不同物理分区处理基本不会影响主业务

二阶段：

        业务完全切量，需扩库进行性能冗余，下面粗糙的描述下当时的切量方案：
                步骤I：在原本业务网关中增加配置，根据配置决定将业务发往哪个数据库上的服务
                步骤II：起8个库，部分流量发往新库，进行数据查询的时候至多走两次查询
                步骤III：陆续切量，直至所有的流量都按8库正常跑
                步骤IV：待业务网关切量稳定后，上游开始切量（之前：流量->业务网关->业务, 现在：部分流量恢复之前状态：流量->业务）
                待业务稳定后将所有量直接发往业务，下掉业务网关，由业务系统直连

        在扩容阶段会开启特殊标记，表明此时所有订单查询将会路由两个库查询最终响应结果，因之前99用户会路由到4库，扩库之后会路由到8库，此时多出来的一次查询是其补偿机制，防止业务出现异常

---

上面描述的已经是业务基于当时现状选择的结果

其实在做分库分表分区的时候还需要考虑不少方面，下面列举部分：
        技术选型：

                关系型数据库 NoSQL 还是类似于TIDB这样的NewSQL，此时第一版还是采用的Oracle，后续将切到TDSQL
        分库技术实现：

                Client模式 和 Proxy模式，因框架天然支持对库路由，故业务为Client模型

        分区字段的选择：

                这个需要根据业务常见需求选择，例如：业务需要用哪些字段进行查询，这里业务选择的是时间

        扩容方案：

                扩容后数据不准情况处理大致有两种处理方案：查询侧补偿、扩容后数据迁移                

                上面二阶段其实就是查询侧做的补偿机制，若采用扩容后数据迁移需要理解hash、一致性hash、一致性hash+虚拟节点之间的区别

        分区索引：

                分区索引 和 全局索引，这里业务选择的是分区索引，对此时业务来说影响更小性能更优

        复杂查询、分页等：

                因数据按照某些规则进行分离了，想要汇总查询是非常难受的，不依赖三方中间件的情况下没什么好的解决方案，目前采用 ES 做数据分离查询
                
        历史数据迁移：

               业务拆分为1+12张表以及31个分区来实现历史业务的迁移

        短时间订单量大爆发：

                冗余性能来应对这种流量

---