分库分表实战

前言

近期笔者在开发过程中碰到一个棘手问题,笔者从事app消息相关任务的优化,迭代。发现相关表的记录都是500w+,其中消息表已经有了1billion的数据。其中带来的条件查询,分页查询等问题

以下是解决方案:

分库与分表:

1)、分表策略

以订单表为例,在订单表中,订单id肯定是不可重复的,因此将该字段当做shard key 是非常适合的 假设预估单个库需要分配100个表满足我们的业务需求,我们可以简单的取模计算出订单在哪个子表中,例如: order_id % 100 但是我如果想根据user_id查询相应订单的话就很难做到

数据库分表能够解决单表数据量很大的时候数据查询的效率问题,但是无法给数据库的并发操作带来效率上的提高,因为分表的实质还是在一个数据库上进行的操作,很容易受数据库IO性能的限制

  1. 水平切分的分片维度 1)按照哈希切片 2)按照时间切片

问题: 事务:

  1. 分布式事务 推荐在一个数据库实例中的操作尽可能使用本地事务来保证一致性,跨数据库实例的一系列更新操作需要根据事务路由在不同的数据源中完成,各个数据源之间的更新操作需要通过分布式事务处理
    • 1)两阶段提交协议 2)最大努力保证模式 更新多个资源时,将多个资源的提交尽量延后到最后一刻处理,这样的话,如果业务流程出现问题,则所有的资源更新都可以回滚,事务仍然保持一致

3)事务补偿机制 采用事务补偿机制,则在遇到问题时,我们需要记录遇到问题的环境、信息、步骤、状态等,后续通过重试机制使其达到最终一致性

复杂查询:垂直切分后,就跟join说拜拜了;水平切分后,查询的条件一定要在切分的维度内,比如查询具体某个用户下的各位订单等;禁止不带切分的维度的查询,即使中间件可以支持这种查询,可以

数据迁移: