MySQL分库分表后路由策略设计详情

目录
  • 概述
  • 支持场景
  • 路由策略
  • 用户端路由key
  • 商家路由key

概述

分库分表后设计到的第一个问题就是，如何选择路由key，应该如何对key进行路由。路由key应该在每个表中都存在而且唯一。路由策略应尽量保证数据能均匀进行分布。

如果是对大数据量进行归档类的业务可以选择时间作为路由key。比如按数据的创建时间作为路由key，每个月或者每个季度创建一个表。按时间作为分库分表后的路由策略可以做到数据归档，历史数据访问流量较小，流量都会打到最新的数据库表中。

也可以设计其与业务相关的路由key。这样可以保证每个数据库的资源都能很好的承担流量。

支持场景

外卖订单平台分库分表后需要支持的场景，用户的角度，需要实时查看所点外卖订单的状态，跟踪订单信息。商家需要查询订单信息，通过订单分析菜品的质量，进行商业决策。

用户Consumer = C端 商家Business = B端

用户下单后订单可能会落到不同的表中，查询的时候可能需要查询多张表。

路由策略

如果创建订单时随机插入到某一张表中，或者不知道插入到那张表中，查询订单的时候都需要查询所有的表才能确保查询的准确信。

如果在插入订单的时候有一定的规则，根据这个规则插入到数据库中，查询的时候也执行相应的规则到对应的表中进行查询。这样就能减少数据操作的复杂性。可以通过设计路由策略来实现，用户和商家查询数据的时候都遵循相同的路由策略。

用户端路由key

根据上一小节的路由策略分析，现在需要选定一个路由key。用户端让同一个用户id的数据保存到某固定的表中，所以可以选用用户id最为路由key。

在单库的情况下，用户下单，生成一个订单，把用户id作为路由key，对user_id取hash值然后对表的数量进行取模，得到对应需要路由的表，然后写入数据。

多库多表的情况下需要先找到对应的库然后再找到对应的表。多库多表的路由策略：用户下达->生成订单->路由策略：根据用户id的hash值对数据库的数量进行取模找到对应的数据库->根据用户id的hash值除以对表的数量，然后在对表的数量进行取模即可找到对应的表。

路由策略设计的要点是根据具体的业务业务场景设计，跟用户信息关联度比较大的作为路由key进行hash值取模

商家路由key

单独为商家B端设计了一套表(C端和B端是独立的)。

用户的角度以user_id作为路由key，商户的角度以商家id作为路由key。商家是如何通过路由key路由数据的呢。游湖在下单的时候把队友的订单号发送到MQ里，商家可以去消费这个MQ，然后根据订单号获取订单信息，然后再把订单信息插入到商户的数据库表当中。商户的路由策略和用户的路由策略是一样的。

用户端和商户端的完整数据流程图：

到此这篇关于MySQL分库分表后路由策略设计详情的文章就介绍到这了,更多相关MySQL分库分表内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们！

赞 (0)

相关推荐

  • SpringCloud Gateway 利用 Mysql 实现动态路由的方法

    SpringCloud Gateway 利用 Mysql 实现动态路由的方法

    需求描述 标准网关动态路由功能是重要的一环,将路由.断言以及过滤器信息,持久化到 Mysql 中,通过配置后台页面实现路由.断言.以及过滤器等配置的增删改查. Spring Cloud Gateway 路由及黑白名单实现背景 Spring Cloud 路由API Spring Cloud Gateway 通过定义 RouteDefinitionRepository 来实现动态路由. //保存路由缓存 public interface RouteDefinitionWriter { Mono<Vo

  • MySQL分库分表的几种方式

    MySQL分库分表的几种方式

    目录 一.为什么要分库分表 二.什么是分库分表 三.分库分表的几种方式 1.垂直拆分 2. 水平拆分 四.分库分表带来的问题 五.分库分表技术如何选型 一.为什么要分库分表 如果一个网站业务快速发展,那这个网站流量也会增加,数据的压力也会随之而来,比如电商系统来说双十一大促对订单数据压力很大,Tps十几万并发量,如果传统的架构(一主多从),主库容量肯定无法满足这么高的Tps,业务越来越大,单表数据超出了数据库支持的容量,持久化磁盘IO,传统的数据库性能瓶颈,产品经理业务·必须做,改变程序,数据库

  • MySQL数据库优化之分表分库操作实例详解

    本文实例讲述了MySQL数据库优化之分表分库操作.分享给大家供大家参考,具体如下: 分表分库 垂直拆分 垂直拆分就是要把表按模块划分到不同数据库表中(当然原则还是不破坏第三范式),这种拆分在大型网站的演变过程中是很常见的.当一个网站还在很小的时候,只有小量的人来开发和维护,各模块和表都在一起,当网站不断丰富和壮大的时候,也会变成多个子系统来支撑,这时就有按模块和功能把表划分出来的需求.其实,相对于垂直切分更进一步的是服务化改造,说得简单就是要把原来强耦合的系统拆分成多个弱耦合的服务,通过服务间的

  • MySQL分库分表总结讲解

    项目开发中,我们的数据库数据越来越大,随之而来的是单个表中数据太多.以至于查询变慢,而且由于表的锁机制导致应用操作也受到严重影响,出现了数据库性能瓶颈. 当出现这种情况时,我们可以考虑分库分表,即将单个数据库或表进行拆分,拆分成多个库和多个数据表,然后用户访问的时候,根据一定的算法与逻辑,让用户访问不同的库.不同的表,这样数据分散到多个数据表中,减少了单个数据表的访问压力.提升了数据库访问性能. 下面是对项目中分库分表的一些总结: 单库单表 单库单表是最常见的数据库设计,例如,有一张用户(use

  • Mysql分库分表之后主键处理的几种方法

    Mysql分库分表之后主键处理的几种方法

    目录 数据库自增 ID 设置数据库 sequence 或者表自增字段步长 UUID 系统当前时间戳+XXX Snowflake 算法 数据库自增 ID 搞一个数据库,什么也不干,就用于生成主键. 你的系统里每次得到一个 id,都需要往那个专门生成主键的数据库中通过插入获取一个自增的ID,拿到这个 id 之后再往对应的分库分表里去写入. 优点:方便简单. 缺点:单库生成自增 id,要是高并发的话,就会有瓶颈的:如果你硬是要改进一下,那么就专门开一个服务出来,这个服务每次就拿到当前 id 最大值,然

  • MyBatis实现Mysql数据库分库分表操作和总结（推荐）

    前言 作为一个数据库,作为数据库中的一张表,随着用户的增多随着时间的推移,总有一天,数据量会大到一个难以处理的地步.这时仅仅一张表的数据就已经超过了千万,无论是查询还是修改,对于它的操作都会很耗时,这时就需要进行数据库切分的操作了. MyBatis实现分表最简单步骤 既然文章的标题都这么写了,不如直接上干货来的比较实际,我们就先来看看如何实现最简单的分表. 1.我们模拟用户表数据量超过千万(虽然实际不太可能) 2.用户表原来的名字叫做user_tab,我们切分为user_tab_0和user_t

  • mysql分表分库的应用场景和设计方式

    很多朋友在论坛和留言区域问mysql在什么情况下才需要进行分库分表,以及采用何种设计方式才是最优的选择,根据这些问题,小编为大家整理了关于MySQL分库分表的应用场景和最优的设计方式举例. 一. 分表 场景:对于大型的互联网应用来说,数据库单表的记录行数可能达到千万级甚至是亿级,并且数据库面临着极高的并发访问.采用Master-Slave复制模式的MySQL架构, 只能够对数据库的读进行扩展,而对数据库的写入操作还是集中在Master上,并且单个Master挂载的Slave也不可能无限制多,Sl

  • MySQL分库分表后路由策略设计详情

    MySQL分库分表后路由策略设计详情

    目录 概述 支持场景 路由策略 用户端路由key 商家路由key 概述 分库分表后设计到的第一个问题就是,如何选择路由key,应该如何对key进行路由.路由key应该在每个表中都存在而且唯一.路由策略应尽量保证数据能均匀进行分布. 如果是对大数据量进行归档类的业务可以选择时间作为路由key.比如按数据的创建时间作为路由key,每个月或者每个季度创建一个表.按时间作为分库分表后的路由策略可以做到数据归档,历史数据访问流量较小,流量都会打到最新的数据库表中. 也可以设计其与业务相关的路由key.这样

  • MySQL分库分表详情

    MySQL分库分表详情

    一.业务场景介绍 假设目前有一个电商系统使用的是MySQL,要设计大数据量存储.高并发.高性能可扩展的方案,数据库中有用户表.用户会非常多,并且要实现高扩展性,你会怎么去设计? OK咱们先看传统的分库分表方式 当然还有些小伙伴知道按照省份/地区或一定的业务关系进行数据库拆分 OK,问题来了,如何保证合理的让数据存储在不同的库不同的表里呢?让库减少并发压力?应该怎么去制定分库分表的规则?不用急,这不就来了 二.水平分库分表方法 1.RANGE 第一种方法们可以指定一个数据范围来进行分表,例如从1~

  • MySQL 分库分表的项目实践

    MySQL 分库分表的项目实践

    目录 一.为什么要分库分表 二.库表太大产生的问题 三.垂直拆分 1. 垂直分库 2. 垂直分表 四.水平分库分表 一.为什么要分库分表 数据库架构演变 刚开始多数项目用单机数据库就够了,随着服务器流量越来越大,面对的请求也越来越多,我们做了数据库读写分离, 使用多个从库副本(Slave)负责读,使用主库(Master)负责写,master和slave通过主从复制实现数据同步更新,保持数据一致.slave 从库可以水平扩展,所以更多的读请求不成问题 但是当用户量级上升,写请求越来越多,怎么保证数

  • MySQL分库分表与分区的入门指南

    MySQL分库分表与分区的入门指南

    前言 关系型数据库比较容易成为系统瓶颈,单机存储容量.连接数.处理能力都有限,当数据量和并发量起来之后,就必须对数据库进行切分了. 数据切分(sharding)的手段就是分库分表.分库分表有两方面,可能是光分库不分表,也可能是光分表不分库. 数据库分布式的核心内容无非就是数据切分,以及切分后对数据的定位.整合. 为什么要分库分表 分表 单表数据量太大时,会严重影响sql执行的性能.一般单表到达几百万的时候,性能就会相对差一些了,这时就得分表了. 分表就是把一个表的数据放到多个表中,然后查询的时候

  • 浅谈订单重构之 MySQL 分库分表实战篇

    浅谈订单重构之 MySQL 分库分表实战篇

    目录 一.目标 二.环境准备 1.基本信息 2.数据库环境准备 3.建库 & 导入分表 三.配置&实践 1.pom文件 2.常量配置 3.yml 配置 4.分库分表策略 5.dao层编写 6.单元测试 四.总结 一.目标 本文将完成如下目标: 分表数量: 256    分库数量: 4 以用户ID(user_id) 为数据库分片Key 最后测试订单创建,更新,删除, 单订单号查询,根据user_id查询列表操作. 架构图: 表结构如下: CREATE TABLE `order_XXX` (

  • 详解分库分表后非分片键如何查询

    目录 正文 设计一:冗余法 方法二:索引表法 方法三:基因法 小结 正文 我们知道在分库分表中对于toC业务来说,需要选择用户属性如 user_id 作为分片键,不推荐使用order_id这样的作为分片键. 那问题来了,对于订单表来说,选择了user_id作为分片键以后如何查看订单详情呢?比如下面这样一条SQL: SELECT * FROM T_ORDER WHERE order_id = 801462878019256325 由于查询条件中的order_id不是分片键,所以需要查询所有分片才能

  • MySQL常用分库分表方案汇总

    MySQL常用分库分表方案汇总

    目录 一.数据库瓶颈 二.分库分表 2.水平分表 3.垂直分库 4.垂直分表 三.分库分表工具 四.分库分表步骤 五.分库分表问题 1.非partition key的查询问题 2.非partition key跨库跨表分页查询问题 3.扩容问题 六.分库分表总结 一.数据库瓶颈 不管是IO瓶颈,还是CPU瓶颈,最终都会导致数据库的活跃连接数增加,进而逼近甚至达到数据库可承载活跃连接数的阈值.在业务Service来看就是,可用数据库连接少甚至无连接可用.接下来就可以想象了吧(并发量.吞吐量.崩溃).

随机推荐