订单分库分表实战分析

前情提要

最近在做一个项目，该项目是一个仿12306的购票系统，这篇博文主要是记录，如何对订单数据进行分库分表的。

订单数据量估算

作为一个铁路购票系统，要供全国的人使用，要将大家的购票数据都存储下来，这个数据量肯定是庞大的，那到底有多大呢？全国14亿人口，使用12306的人我们假设有7亿，假设每个人每个月只买两张车票，也就是产生两条订单数据，那么一年下来，总的订单数据就是 2712=168亿，而且随着时间的推移，订单数据肯定是一直在增多的，显然提供所有历史订单信息的查询是不切实际的，通过查看12306系统的订单查询，我们发现只能查询近一个月的用户订单数据，这样也就大大的减少了整个系统的存储压力。

订单表结构

1. 字段
   
   整个订单表中一共包含了19个字段，它们分别是id，订单号(order_sn)，用户id（user_id）、用户名（username）、列车Id（trian_id）、列车车次（train_number）、乘车日期（riding_date）、出发站点（departure）、到达站点（arrival）、出发时间（departure_time）、到达时间（arrival_time）、订单来源（source）、订单状态（status）、下单时间（order_time）、支付方式（pay_type）、支付时间（pay_time）、创建时间（create_time）、修改时间（update_time）、删除标识（del_flag)
2. 索引
   订单表中的索引为：用户id（user_id）订单号（order_sn)，建立这个两个字段为索引的原因是，系统中经常会用到它们查询订单信息。
   

分片键的选择

1. 分片键是什么？
   分片键是数据库分库分表策略中用于确定数据应该存储在哪一个特定分片（Shard）上的字段或字段集合。它是分片算法的输入，算法根据分片键的值计算出数据所属的分片ID，进而决定数据的具体存储位置。
2. 分片键的作用
   • 数据定位：分片键使得系统能够快速定位到数据所在的物理分片，这对于读写操作至关重要。
   • 负载均衡：合理选择分片键可以保证数据在各个分片间均匀分布，避免热点问题。
   • 优化查询：选择适当的分片键可以减少跨分片查询的需求，提高查询效率。
3. 确定分片键
   在本系统中，一个最基本的业务诉求就是用户可以查询到自己的订单信息（根据user_id查询）、根据订单号精准查询订单（查询别人的订单），这就意味着我们需要使用两个字段当作分片键，每次查询的时候需要带着这两个字段，比较不方便，那有没有更简单的方法呢，有，就是下面的基因法
   • 基因法
     “基因法”是一种特殊的分片算法，用于确定数据行应该被放置在哪个数据库（分库）或哪个表（分表）中。基因法的核心思想是从数据的标识符中提取一部分信息（“基因”），使用这部分信息来决定数据的归属。
   • 具体实施
     将user_id的后六位加到order_sn中，形成一个含有”冗余数据“的新order_sn
     

• 未完待续。。。。。