数据库冷热隔离方案

数据现装

目前项目中的数据存储在mysql数据库中，虽然mysql按照业务域分库（16个），单库256张表。但是表数据量目前300W，每日新增560w，平均每张物理表日新增数据量560W/256=2.18W。每张表数据量上限按照800W条计算，距离每张表的上限需要（800-300）/2.18=229天。

业务还在持续增长，提前对DB做冷热隔离。

前期技术选型

后期技术调研

直接将数据存储在Hbase或者ES等基于HDFS分布式存储架构中，当数据量持续增长时，如果遇到存储瓶颈直接加机器即可。目前主流的大数据量也按照此方案存储。例如阿里的lindorm(Hbase上做的封装)，腾讯的基于ES的一个技术栈（具体叫啥名记不清了）。

隔离方案

全量数据同步方案：

mysql每天会同步数据至数据仓库hive中（odps）,考虑到有业务持续写入，减少db的压力，采用离线同步方案，将hive(odps)中的数据采用快照方式同步到Hbase中（lindorm）。

增量数据同步方案：

方案1.采用消费mysql binlog的方式去同步数据至冷库（Hbase）中。

方案2.a.先采用方案1执行。b.当mysql业务数据写成功之后发一条mq消息。c.创建消费者消费此主题消息，写冷库（Hbase）。d.停止a这一步。

如果采用方案1同步增量数据，为了保证数据的安全性和一致性，可以在全量任务开始前就启动增量任务，但是增量任务此时不消费binlog同步数据，将消费binlog的位点前置（早于全量任务开始，或者和全量任务开始时间一致）.当全量任务跑完的时间点增量任务开始消费binlog。

如果采用方案2同步增量数据，此方案可能会有重复数据出现，但是Hbase中修改操作也是新增一条数据，每条数据对应一个时间戳做多版本，当查询数据时，会按照时间戳取最新的那条数据。为了节省预算资源和保证数据的安全性，必须采用方案1先执行，然后消费mq，再停止方案1。

注意：为保证全量任务迁移安全，全量任务执行期间，不要往热库写数据。

当数据迁移完成后删除热库（mysql）中100天之后的数据，这样就保证了mysql的空间资源，同时需要对mysql做optimize。

需要分库分表的扫描，然后按照主键id删除数据。

接口改造

逻辑层再加一层路由层，判断数据的创建时间，如果大于90天就请求冷DB，如果小于90天就请求热DB。

测试及其灰度配置

此外 可以在diamond（阿里）或者Apollo（携程）或者wconfig（58）等可配置化平台配置白名单，采用变动推送新配置方式，项目实时读取新配置。通过白名单做测试用。同时在diamond上采用分桶方式在上线之后做灰度百分比，如果一旦发现问题将请求冷DB流量切换至0%，及时回滚。

下面这个是我在diamond上的配置：

{
    "experiment": "AHIM_DB_B2C",
    "totalBucket": 1000,
    "divideType": "cid",
    "config": {
        "buckets": [{
            "startBucket": 0,
            "endBucket": -1,
            "whiteList": ["111","222","333"],
            "bucketType": 1
        }],
        "defaultBuckets": 0
    }
}

可以在代码中加开关控制，有问题随时关闭开关，停止走冷库逻辑