仿12306校招项目业务三（用户注册）

用户表结构

原本的表结构如下

由于用户量大，采用分库分表：

分库分表设计

根据系统设计的假设，12306 的注册用户规模约为 10 亿，每年新增用户约 1000 万。在用户数据分库或分表之前，我们需要先考虑拆分成多少个库或表才能达到最优性能。为了进行这样的决策，我们可以预估单个表的最大数据量。根据过去的经验，通常我们会选择 2000 万作为一个经验值。这个数据量既不会过小，同时又能保证增删改查等操作相对流畅。

根据当前用户表的数据量为 10 亿，并且每年新增 1000 万用户，预估未来系统的生命周期较长，数据量大概会达到 30 亿左右。基于这个数据量，我们预估单表的数据量在2000 万左右，因此需要分大约 150 张表来容纳这些数据。

在进行分库分表容量评估时，我们通常会尽可能多地进行评估。这样做的好处是，即使每张表的数据量不多，也能及早发现拆分后是否存在数据问题，以便及时进行调整和优化。此外，需要特别指出的是，我们对表数据量考虑的阈值相对较小，这是因为我们的系统具备良好的可扩展性，可以轻松应对大量的数据增长。因此，基于这种情况的分库分表策略，即使在几百年后，这个分库分表依然能够处理数据，并且不会出现性能问题。这为我们的系统提供了稳定可靠的性能障。

选择分库分表中的分片键（Sharding Key）是一个关键决策，它直接影响了分库分表的性能和可扩展性。以下是一些选择分片键的关键因素：

1. 访问频率：选择分片键应考虑数据的访问频率。将经常访问的数据放在同一个分片上，可以提高查询性能和降低跨分片查询的开销。

2. 数据均匀性：分片键应该保证数据的均匀分布在各个分片上，避免出现热点数据集中在某个分片上的情况。

3. 业务关联性：分片键应该与业务关联紧密，这样可以避免跨分片查询和跨库事务的复杂性。

4. 数据不可变：一旦选择了分片键，它应该是不可变的，不能随着业务的变化而频繁修改。

基于以上考虑，我们选择使用 username 作为分片键。

分库分表实现

使用 ShardingSphere 分库分表操作，可以查看官网进行一些前置条件理解:

数据分片 :: ShardingSphere

1. 引入 ShardingSphere 依赖

<dependency>
<groupId>org.apache.shardingsphere</groupId>
<artifactId>shardingsphere-jdbc-core</artifactId>
<version>5.3.2</version>
</dependency>

2. 定义分片规则

spring:
  application:
    name: index12306-user${unique-name:}-service
  datasource:
    driver-class-name: org.apache.shardingsphere.driver.ShardingSphereDriver
    url: jdbc:shardingsphere:classpath:shardingsphere-config.yaml

3. 用户分片配置

因为 12306 更多的是向大家演示分库分表，所以分 2 个库以及对应业务 16 张表。

shardingsphere-config.yaml:

dataSources:
  ds_0:
    dataSourceClassName: com.zaxxer.hikari.HikariDataSource
    driverClassName: com.mysql.cj.jdbc.Driver
    jdbcUrl: jdbc:mysql://127.0.0.1:3306/12306_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/12306_user_1?useUnicode=true&characterEncoding=UTF-8&rewriteBatchedStatements=true&allowMultiQueries=true&serverTimezone=Asia/Shanghai
    username: root
    password: root

rules:
  - !SHARDING
    tables:
      t_user:
        actualDataNodes: ds_${0..1}.t_user_${0..31}
        databaseStrategy:
          standard:
            shardingColumn: username
            shardingAlgorithmName: user_database_hash_mod
        tableStrategy:
          standard:
            shardingColumn: username
            shardingAlgorithmName: user_table_hash_mod
      t_passenger:
        actualDataNodes: ds_${0..1}.t_passenger_${0..31}
        databaseStrategy:
          standard:
            shardingColumn: username
            shardingAlgorithmName: passenger_database_hash_mod
        tableStrategy:
          standard:
            shardingColumn: username
            shardingAlgorithmName: passenger_table_hash_mod
      t_user_mail:
        actualDataNodes: ds_${0..1}.t_user_mail_${0..31}
        databaseStrategy:
          standard:
            shardingColumn: mail
            shardingAlgorithmName: t_user_mail_database_hash_mod
        tableStrategy:
          standard:
            shardingColumn: mail
            shardingAlgorithmName: t_user_mail_table_hash_mod
      t_user_phone:
        actualDataNodes: ds_${0..1}.t_user_phone_${0..31}
        databaseStrategy:
          standard:
            shardingColumn: phone
            shardingAlgorithmName: t_user_phone_database_hash_mod
        tableStrategy:
          standard:
            shardingColumn: phone
            shardingAlgorithmName: t_user_phone_table_hash_mod
    shardingAlgorithms:
      user_database_hash_mod:
        type: CLASS_BASED
        props:
          sharding-count: 32
          table-sharding-count: 16
          strategy: standard
          algorithmClassName: org.opengoofy.index12306.framework.starter.database.algorithm.sharding.CustomDbHashModShardingAlgorithm
      passenger_database_hash_mod:
        type: CLASS_BASED
        props:
          sharding-count: 32
          table-sharding-count: 16
          strategy: standard
          algorithmClassName: org.opengoofy.index12306.framework.starter.database.algorithm.sharding.CustomDbHashModShardingAlgorithm
      t_user_mail_database_hash_mod:
        type: CLASS_BASED
        props:
          sharding-count: 32
          table-sharding-count: 16
          strategy: standard
          algorithmClassName: org.opengoofy.index12306.framework.starter.database.algorithm.sharding.CustomDbHashModShardingAlgorithm
      t_user_phone_database_hash_mod:
        type: CLASS_BASED
        props:
          sharding-count: 32
          table-sharding-count: 16
          strategy: standard
          algorithmClassName: org.opengoofy.index12306.framework.starter.database.algorithm.sharding.CustomDbHashModShardingAlgorithm
      passenger_table_hash_mod:
        type: HASH_MOD
        props:
          sharding-count: 32
      t_user_mail_table_hash_mod:
        type: HASH_MOD
        props:
          sharding-count: 32
      t_user_phone_table_hash_mod:
        type: HASH_MOD
        props:
          sharding-count: 32
      user_table_hash_mod:
        type: HASH_MOD
        props:
          sharding-count: 32
  - !ENCRYPT
    tables:
      t_user:
        columns:
          id_card:
            cipherColumn: id_card
            encryptorName: common_encryptor
          phone:
            cipherColumn: phone
            encryptorName: common_encryptor
          mail:
            cipherColumn: mail
            encryptorName: common_encryptor
          address:
            cipherColumn: address
            encryptorName: common_encryptor
      t_passenger:
        columns:
          id_card:
            cipherColumn: id_card
            encryptorName: common_encryptor
          phone:
            cipherColumn: phone
            encryptorName: common_encryptor
        queryWithCipherColumn: true
    encryptors:
      common_encryptor:
        type: AES
        props:
          aes-key-value: d6oadClrrb9A3GWo
props:
  sql-show: true

缓存穿透解决

缓存穿透是指在使用缓存系统时，恶意或频繁地请求一个不存在于缓存中的数据，导致每次请求都需要查询数据库或其他数据存储系统，从而绕过了缓存的效果，严重影响系统性能。这种情况通常发生在恶意攻击、大量请求缓存中不存在的数据或缓存数据过期后的高并发访问。

缓存穿透会导致以下问题：

1. 频繁的查询数据库或其他数据存储系统，增加了数据库负载，降低了系统的吞吐量。

2. 大量的缓存不存在的数据请求可能会导致缓存服务器的内存被耗尽，影响其他正常的缓存操作。

3. 用户体验下降，因为请求的数据无法从缓存中获取，导致响应时间延长。

采用布隆过滤器结合缓存的方式来解决缓存穿透问题

用户注册接口

用户注册接口整体流程如下所示：

责任链模式

12306 系统中，我们定义责任链模式分为三步，确定方法执行入参、定义当前业务责任链接口以及具体实施验证责任链执行器。

1）确定方法执行入参

因为我们是用户注册接口，验证的也是用户提交的数据，直接复用该实体即可。

@Data
public class UserRegisterReqDTO {

    /**
     * 用户名
     */
    private String username;

    /**
     * 密码
     */
    private String password;

    /**
     * 真实姓名
     */
    private String realName;

    /**
     * 证件类型
     */
    private Integer idType;

    /**
     * 证件号
     */
    private String idCard;

    /**
     * 手机号
     */
    private String phone;

    /**
     * 邮箱
     */
    private String mail;

    /**
     * 旅客类型
     */
    private Integer userType;

    /**
     * 审核状态
     */
    private Integer verifyState;

    /**
     * 邮编
     */
    private String postCode;

    /**
     * 地址
     */
    private String address;

    /**
     * 国家/地区
     */
    private String region;

    /**
     * 固定电话
     */
    private String telephone;
}

2）定义业务责任链接口

public interface UserRegisterCreateChainFilter<T extends UserRegisterReqDTO> extends AbstractChainHandler<UserRegisterReqDTO> {

    @Override
    default String mark() {
        return UserChainMarkEnum.USER_REGISTER_FILTER.name();
    }
}

3）定义责任链业务具体处理器。

在定义责任链处理器时，需要注意使用 getOrder 排序接口来决定组件的执行顺序。通常情况下，处理效率高且在内存中执行的验证策略应该优先执行，而需要涉及交互操作（例如 Redis 等）的处理策略则放在后面执行。

举例来说，假设用户没有传递身份证号，在这种情况下，首先执行验证用户名的操作是非常浪费的，因为后续还需要验证参数必填性，这样就多了一次查询缓存的无用耗时。尽管性能损耗可能不会很高，但这种无用的损耗应该尽量避免。

因此，通过合理地使用 getOrder 排序接口，我们可以优化责任链的执行顺序，使得处理效率高的操作优先执行，避免不必要的性能损耗，从而提升整体处理性能和效率。