---
title: "02-分库分表-用户服务-购票人表"
created: 2025-12-10
aliases:
  - 分库分表-用户服务-购票人表
tags:
  - 项目
---
# 分库分表-用户服务-购票人表

阅读此文前，建议小伙伴先阅读分库分表的前置知识，对分库分表 和 shardingsphere 有了大概的理解后，在继续阅读本文

## 介绍

在订票系统中，添加的购票人是指用户在购买票务（如电影票、飞机票、火车票等）时所添加的一组信息，这组信息用于标识实际将要使用该票务的人员。这些信息通常包括但不限于购票人的姓名、身份证号、电话号码等。购票人信息是完成购票过程中的关键一环，确保了票务的正确分配与使用

购票人这个业务特点小伙伴都会遇到，常见的购票系统都会有只不过叫法不同而已。其实就是将购买的票绑定要对应的购票人身上，购票人和用户是依附关系，在数据库设计中，购票人信息通常与用户信息（购票系统的注册账户）存在关联关系。这种关系可以是一对一、一对多，具体取决于业务需求和设计逻辑

一对一关系：如果系统中用户账户下只有本人自己一个购票人信息，那么用户与购票人之间就是一对一的关系

一对多关系：在大多数场景下，一个用户可能会为家庭成员或朋友购票，因此一个用户账户下可能有多个购票人信息，这就形成了一对多的关系

### d\_ticket\_user 购票人表

```sql
CREATE TABLE `d_ticket_user` (
  `id` bigint(20) NOT NULL COMMENT '主键id',
  `user_id` bigint(20) NOT NULL COMMENT '用户id',
  `rel_name` varchar(256) NOT NULL COMMENT '用户真实名字',
  `id_type` int(11) NOT NULL DEFAULT '1' COMMENT '证件类型 1:身份证 2:港澳台居民居住证 3:港澳居民来往内地通行证 4:台湾居民来往内地通行证 5:护照 6:外国人永久居住证',
  `id_number` varchar(512) NOT NULL COMMENT '证件号码',
  `create_time` datetime NOT NULL COMMENT '创建时间',
  `edit_time` datetime NOT NULL COMMENT '编辑时间',
  `status` tinyint(1) NOT NULL DEFAULT '1' COMMENT '1:正常 0:删除',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='购票人表';
```

### 对于分片键的考虑

选择分片键（Sharding Key）是进行数据库分库分表时的关键决策之一，因为它直接影响到数据的分布、查询性能、数据平衡以及系统的可扩展性。选择合适的分片键需要综合考虑以下几个因素：

1. 访问模式和查询性能：了解应用的数据访问模式是至关重要的。分片键应该选择能够支持高效查询的字段，尽量避免跨分片的查询操作，因为这将大幅度降低查询效率。如果查询经常基于某个字段进行，那么这个字段可能是一个好的分片键候选
2. 数据分布的均匀性：理想的分片键应该能够使得数据在各个分片之间均匀分布，避免某些分片过热（数据过多导致的负载过高）的情况。均匀的数据分布有助于实现负载均衡，从而提高整体的系统性能和稳定性
3. 数据增长的可预测性：分片键的选择应考虑到数据增长的模式，以确保系统可以平滑地扩展。选择一个随时间平均增长的分片键可以帮助避免未来的数据迁移和重分片操作\
4. 业务逻辑的兼容性：分片键的选择需要与业务逻辑紧密相连确保分片操作不会破坏业务逻辑或导致不必要的复杂性。例如，如果业务逻辑需要经常联合多个表查询，那么这些表最好使用相同的分片键

### 购票人业务

在大麦网中设计的购票人的业务有添加购票人、查询购票人列表、查询用户和购票人集合

既然购票人是依附于用户的，所以和用户是一直相关连的，而且在上述业务中，都离不开userId，因为根据业务来考虑，使用userId作为分片键，不仅实现了分库分表的区别，而且分库分表后的购票人表和分库分表后的用户表是在一块的

配置
引入 ShardingSphere 的相关依赖

```xml
<properties>
	<shardingsphere.version>5.3.2</shardingsphere.version>
</properties>
<dependency>
    <groupId>org.apache.shardingsphere</groupId>
    <artifactId>shardingsphere-jdbc-core</artifactId>
    <version>${shardingsphere.version}</version>
    <exclusions>
        <exclusion>
            <artifactId>logback-classic</artifactId>
            <groupId>ch.qos.logback</groupId>
        </exclusion>
    </exclusions>
</dependency>
```

根据规则进行分库分表的规则配置

ShardingSphere 官网的规则配置说明：

<https://shardingsphere.apache.org/document/5.3.2/cn/user-manual/shardingsphere-jdbc/yaml-config/rules/sharding/>

用户项目相关配置：

```yaml
spring:
  datasource:
    driver-class-name: org.apache.shardingsphere.driver.ShardingSphereDriver
    url: jdbc:shardingsphere:classpath:shardingsphere-user.yaml
```

shardingsphere-user.yaml配置：

```yaml
dataSources:
  # 第一个用户库
  ds_0:
    dataSourceClassName: com.zaxxer.hikari.HikariDataSource
    driverClassName: com.mysql.cj.jdbc.Driver
    jdbcUrl: jdbc:mysql://127.0.0.1:3306/damai_user_0?useUnicode=true&characterEncoding=UTF-8&rewriteBatchedStatements=true&allowMultiQueries=true&serverTimezone=Asia/Shanghai
    username: root
    password: root
  # 第二个用户库
  ds_1:
    dataSourceClassName: com.zaxxer.hikari.HikariDataSource
    driverClassName: com.mysql.cj.jdbc.Driver
    jdbcUrl: jdbc:mysql://127.0.0.1:3306/damai_user_1?useUnicode=true&characterEncoding=UTF-8&rewriteBatchedStatements=true&allowMultiQueries=true&serverTimezone=Asia/Shanghai
    username: root
    password: root
    
rules:
  # 分库分表规则
  - !SHARDING
    tables:
      # 对d_ticket_user表进行分库分表
      d_ticket_user:
        # 库为damai_user_0 damai_user_1 表为d_ticket_user_0 至 d_ticket_user_1
        actualDataNodes: ds_${0..1}.d_ticket_user_${0..1}
        # 分库策略
        databaseStrategy:
          standard:
            # 使用user_id作为分片键
            shardingColumn: user_id
            # 用user_id列使用取模作为分库算法
            shardingAlgorithmName: databaseTicketUserModModel
        # 分表策略      
        tableStrategy:
          standard:
            # 使用user_id作为分片键
            shardingColumn: user_id
            # 用user_id列使用取模作为分表算法
            shardingAlgorithmName: tableTicketUserModModel      
    # 具体的算法        
    shardingAlgorithms:
      # d_ticket_user表分库算法
      databaseTicketUserModModel:
        type: MOD
        props:
          # 分库数量
          sharding-count: 2
      # d_ticket_user表分表算法
      tableTicketUserModModel:
        type: MOD
        props:
          # 分表数量
          sharding-count: 2
  # 加密规则
  - !ENCRYPT
    tables:
      # d_ticket_user表
      d_ticket_user:
        columns:
          # 对id_number列进行加密
          id_number:
            # 密文列id_number
            cipherColumn: id_number
            # 自定义的加密算法
            encryptorName: user_encryption_algorithm      
    encryptors:
      user_encryption_algorithm:
        type: SM4
        props:
          sm4-key: d3ecdaa11d6ab89e1987870186073eaa
          sm4-mode: CBC
          sm4-iv: 1afc7fdce9ebc393f693cd3d23e35ed2
          sm4-padding: PKCS7Padding
props:
  # 打印真实sql
  sql-show: true
```

## 总结

> d\_ticket\_user表的分库分表都是用的user\_id作为分片键，算法为MOD，取模

所谓的全路由，就是没有查询或者操作数据时，没有分片键的条件，ShardingSphere  无法定位数据具体到在哪个库，哪个表。就只能去所有的分片库，分片表上查询，这种情况的执行效率是非常慢的，会有数据库连接超时、接口超时 各种的问题

### 购票人的查看

目前在大麦网中用户只能查看此用户下的购票人订单列表，例如张三用户添加了张三和李四购票人并分别给这两个购票人各买了一张票，那么张三用户就可以看到张三和李四的购票订单，但李四用户并不能看到自己的购票人订单

![[image-8203564b.webp]]

---

**企业级项目导航**：⬅️ [[01-分库分表-用户服务-用户表|01-分库分表-用户服务-用户表]] | 02-分库分表-用户服务-购票人表 | ➡️ [[03-分库分表-节目服务|03-分库分表-节目服务]]