携手创造，共同成长！这是我参加「日新方案 8 月更文挑战」的第11天，点击检查活动概况
概述
分库分表后涉及到的第一个问题就是，怎么挑选路由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端是独立的)。
用户端和商户端的完整数据流程图：
