阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 juejin.cn/post/7128726681954549768 「人间凑个数」欢迎转载，保留摘要，谢谢！

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

---

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

概述

分库分表后设计到的第一个问题就是，如何选择路由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，然后根据订单号获取订单信息，然后再把订单信息插入到商户的数据库表当中。商户的路由策略和用户的路由策略是一样的。

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