亿级订单系统分库分表技术方案和Flink数据同步方案

一、需求背景

随着公司业务的发展，订单系统的数据量和访问量日益增长，单库单表的架构已经无法满足我们的需求。主要面临以下问题：

1. 数据量大：单一数据库存储所有订单数据，导致数据量过大，影响查询效率。
2. 并发压力大：大量用户同时访问系统，产生高并发请求，对数据库造成较大压力。
3. 扩展性差：当需要对订单表进行改动时，大量的数据造成表结构修改时间变长

二、业务现状

1. 订单表有主键orderId和唯一索引orderNo，orderId依赖数据库自增，orderNo自定义生成并且后4位为类用户id，内部场景用orderId进行数据传递，外部场景用orderNo进行数据传递

解决方案：去除数据库自增，将orderId和orderNo进行合并，将自定义编号作为唯一主键，内外部场景全部采用orderNo进行数据传递

2. 订单表超过10个索引，部分索引用于C端场景，部分索引用于B端场景

解决方案：将OLTP中的订单数据同步到OLAP数据库中；确保所有C端场景能够命中分库分表的分片键；将B端分析场景进行剥离，例如查询订单列表，在OLAP数据库中进行查询，再根据订单主键CRUD时，再走OLTP数据库

3. 订单表中存在部分老数据，老orderNo没有采用后4位是类用户id，并且老orderNo中可能存在字母

解决方案：借助Flink将老订单编号数据进行清洗（数据清洗技术方案另行商议），统一采用现有订单编号规则

4. 订单表存在一些拓展表，比如订单位置、订单申诉记录等，有些采用orderNo进行关联，有些采用orderId进行关联

解决方案：和第1点一样，统一采用主键进行关联，并且需要保证关联字段为分片键。如果有分库，最好将拓展表也进行分库分表，并且需要保证拓展表的分库分表规则和原表一致

5. 订单表中字段过多，有计费、开票、退款等非核心数据

解决方案：考虑纵向拆分，可以考虑这几个方面：是否核心、更新是否频繁、字段长度是否过大

三、技术选型

1、分库分表和分布式数据库对比

理解普通数据库、分布式数据库、云原生数据库、云原生分布式数据库区别

• 普通数据库：通常采用传统的垂直架构，由单一的数据库服务器提供数据存储和查询服务。
• 分布式数据库：采用水平分片的方式，将数据分散到多个数据库服务器上，实现数据的高可用性和可扩展性。
• 云原生数据库：基于云计算技术构建，具有容器化、微服务等特性，可以快速部署和扩展。
• 云原生分布式数据库：结合了分布式数据库和云原生数据库的特点，实现高性能、高可用、可扩展的数据库服务。

产品名称	PolarDB-分区表	OceanBase	PolarDB-X	TIDB	传统分库分表