用户表结构
原本的表结构如下
由于用户量大，采用分库分表：
分库分表设计
根据系统设计的假设，12306 的注册用户规模约为 10 亿，每年新增用户约 1000 万。在用户数据分库或分表之前，我们需要先考虑拆分成多少个库或表才能达到最优性能。为了进行这样的决策，我们可以预估单个表的最大数据量。根据过去的经验，通常我们会选择 2000 万作为一个经验值。这个数据量既不会过小，同时又能保证增删改查等操作相对流畅。
根据当前用户表的数据量为 10 亿，并且每年新增 1000 万用户，预估未来系统的生命周期较长，数据量大概会达到 30 亿左右。基于这个数据量，我们预估单表的数据量在2000 万左右，因此需要分大约 150 张表来容纳这些数据。
在进行分库分表容量评估时，我们通常会尽可能多地进行评估。这样做的好处是，即使每张表的数据量不多，也能及早发现拆分后是否存在数据问题，以便及时进行调整和优化。此外，需要特别指出的是，我们对表数据量考虑的阈值相对较小，这是因为我们的系统具备良好的可扩展性，可以轻松应对大量的数据增长。因此，基于这种情况的分库分表策略，即使在几百年后，这个分库分表依然能够处理数据，并且不会出现性能问题。这为我们的系统提供了稳定可靠的性能障。
选择分库分表中的分片键（Sharding Key）是一个关键决策，它直接影响了分库分表的性能和可扩展性。以下是一些选择分片键的关键因素：
1. 访问频率：选择分片键应考虑数据的访问频率。将经常访问的数据放在同一个分片上，可以提高查询性能和降低跨分片查询的开销。
2. 数据均匀性：分片键应该保证数据的均匀分布在各个分片上，避免出现热点数据集中在某个分片上的情况。
3. 业务关联性：分片键应该与业务关联紧密，这样可以避免跨分片查询和跨库事务的复杂性。
4. 数据不可变：一旦选择了分片键，它应该是不可变的，不能随着业务的变化而频繁修改。
基于以上考虑，我们选择使用 username 作为分片键。
分库分表实现
使用 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.yaml3. 用户分片配置
因为 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 排序接口，我们可以优化责任链的执行顺序，使得处理效率高的操作优先执行，避免不必要的性能损耗，从而提升整体处理性能和效率。
用户表相关新增
先来查看 12306 登录功能的原型截图及其对应的功能
在登录功能中，用户一栏明确标出可以使用用户名、邮箱或手机号中的任意一个搭配密码进行登录。需要强调的是，在分库分表中，我们是通过用户名进行分片的。因此，如果在查询用户信息时不带用户名，将会触发读扩散问题。
为了解决这个问题，我们引入了两张路由表：用户手机号表和用户邮箱表。这些表的核心字段是手机号和邮箱，以及它们对应的用户名。通过这样的设计，我们能够在用户登录时，灵活地使用手机号、邮箱或用户名来进行认证。
其它操作
在用户注册后，该用户名将不再可用，因此我们需要将其添加到布隆过滤器中，以防止其他人在后续尝试注册时再次使用。
另外，关于用户注册文章中提到的用户名可复用问题，我们特别考虑了这一点。已经注销的用户名需要能够被其他用户再次使用，因此我们对可复用用户名进行了扩展设计。
这意味着，我们需要将对应的缓存和数据库表一并删除。一旦删除完成，后续用户将无法再通过这个扩展点使用该用户名。这样的设计保证了用户名的合理复用，同时确保已注销用户名的信息不会对后续用户产生影响。
扫一扫
6085
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
