敞开生长之旅!这是我参加「日新方案 12 月更文应战」的第3天,点击检查活动概况
本文记录博主线上项目一次用户重复注册问题的剖析进程与解决方案
- 博主github地址:github.com/wayn111
一 复现进程
线上客户端用户运用微信扫码登陆时需要再绑定一个手机号,在绑定手机后,用户购买客户端产品下线再登录,发现用户账号ID被变更,已经不是用户刚绑定手机号时主动登录的用户账号ID,查询线上数据库,发现同一个手机生成了多个账号id,至此问题复现
二 剖析进程
发现数据库中一个手机号生成了多个用户账号,榜首反应是用户在绑定手机号进程中,多次点击绑定按钮,导致绑定接口被调用多次,造成多线程并发调用用户注册接口,进而生成多个账号。为了验证咱们的猜想,直接检查绑定手机后的用户注册办法
/**
* 根据用户手机号进行注册操作
*/
// 启动@Transactional业务注解
@Transactional(rollbackFor = Exception.class)
public boolean userRegister(LoginReqBody body, BaseReqHeader header, BaseResp<BaseRespHeader, LoginRespBody> resp) {
RedisLock redisLock = redisCache.getRedisLock(RedisNameEnum.USER_REGISTER_LOCK.get(""), 10);
boolean lock;
try {
lock = redisLock.lock();
// 运用redis分布式锁
if (lock) {
// 查询数据库该用户手机号是否刺进成功,已存在则退出操作
MemberDO member = mapper.findByMobile(body.getAccount(), body.getRegRes());
if (Objects.nonNull(member)) {
resp.setResultFail(ReturnCodeEnum.USER_EXIST);
return false;
}
// 履行用户注册操作,包括刺进用户表、订单表、是否被约请
...
}
} catch (Exception e) {
log.error("用户注册失利:", e);
throw new Exception("用户注册失利");
} finally {
redisLock.unLock();
}
// 增加注册日志,上签到数据剖析渠道...
return true;
}
初看代码,在分布式环境中,先加分布式锁确保同时只能被一个线程履行,然后判断数据库中是否存在用户手机信息,已存在则退出,不存在则履行用户注册操作,咋认为逻辑上没有问题,可是线上环境的确便是出现了相同手机号重复注册的问题,首要代码被 @Transactional
注解包括,便是在主动业务中履行注册逻辑
现在博主带咱们回想一下,MySQL
业务的阻隔等级有4个
- Read uncommitted:读取未提交,其他业务只需修正了数据,即使未提交,本业务也能看到修正后的数据值。
- Read committed:读取已提交,其他业务提交了对数据的修正后,本业务就能读取到修正后的数据值。
- Repeatable read:可重复读,不管其他业务是否修正并提交了数据,在这个业务中看到的数据值一直不受其他业务影响。
- Serializable:串行化,一个业务一个业务的履行。
- MySQL数据库默许运用可重复读( Repeatable read)。
阻隔等级越高,越能确保数据的完整性和一致性,可是对并发性能的影响也越大,MySQL的默许阻隔等级是读可重复读。在上述场景里,也便是说,不管其他线程业务是否提交了数据,当前线程所在业务中看到的数据值一直不受其他业务影响
说人话(划要点):便是在 MySQL
中一个线程所在业务是读不到另一个线程业务未提交的数据的
下面结合上述代码给出剖析进程:上述注册逻辑都包括在 Spring
供给的主动业务中,整个办法都在业务中。而加锁也在业务中履行。终究导致咱们注册 线程B
在当前事物中查询不到另一个注册 线程A
所在事物未提交的数据, 举个比如
eg:
- 当用户履行注册操作,重复点击注册按钮时,假定线程A和B同时履行到
redisLock.lock()
时,假定线程A获取到锁,线程B进入自旋等候,线程A履行mapper.findByMobile(body.getAccount(), body.getRegRes())
操作,发现用户手机不存在数据库中,进行注册操作(增加用户信息入库等),履行结束,释放锁。履行后续增加注册日志,上签到数据剖析渠道操作,注意此刻业务还未提交。
- 线程B总算获取到锁,履行
mapper.findByMobile(body.getAccount(), body.getRegRes())
操作,在咱们一开始的假定中,认为这里会返回用户已存在,可是实践履行成果并不是这样的。原因便是线程A的业务还未提交,线程B读不到线程A未提交业务的数据也便是说查不到用户已注册信息,至此,咱们知道了用户重复注册的原因。
三 解决方案:
给出三种解决方案
3.1 修正业务规模,将业务的操作代码最小化,确保在加锁结束前完结业务提交,代码如下敞开手动业务,这样其他线程在加锁代码块中就能看到最新数据
@Autowired
private PlatformTransactionManager platformTransactionManager;
@Autowired
private TransactionDefinition transactionDefinition;
private boolean userRegister(LoginReqBody body, BaseReqHeader header, BaseResp<BaseRespHeader, LoginRespBody> resp) {
RedisLock redisLock = redisCache.getRedisLock(RedisNameEnum.USER_REGISTER_LOCK.get(""), 10);
boolean lock;
TransactionStatus transaction = null;
try {
lock = redisLock.lock();
// 运用redis分布式锁
if (lock) {
// 查询数据库该用户手机号是否刺进成功,已存在则退出操作
MemberDO member = mapper.findByMobile(body.getAccount(), body.getRegRes());
if (Objects.nonNull(member)) {
resp.setResultFail(ReturnCodeEnum.USER_EXIST);
return false;
}
// 手动敞开业务
transaction = platformTransactionManager.getTransaction(transactionDefinition);
// 履行用户注册操作,包括刺进用户表、订单表、是否被约请
...
// 手动提交业务
platformTransactionManager.commit(transaction);
...
}
} catch (Exception e) {
log.error("用户注册失利:", e);
if (transaction != null) {
platformTransactionManager.rollback(transaction);
}
return false;
} finally {
redisLock.unLock();
}
// 增加注册日志,上签到数据剖析渠道...
return true;
}
3.2 在用户注册时针对注册接口增加防重复提交处理
下面给出一个基于 AOP
切面 + 注解实现的限流逻辑
/**
* 限流枚举
*/
public enum LimitType {
// 默许
CUSTOMER,
// by ip addr
IP
}
/**
* 自定义接口限流
*
* @author jacky
*/
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface Limit {
boolean useAccount() default true;
String name() default "";
String key() default "";
String prefix() default "";
int period();
int count();
LimitType limitType() default LimitType.CUSTOMER;
}
/**
* 限制器切面
*/
@Slf4j
@Aspect
@Component
public class LimitAspect {
@Autowired
private StringRedisTemplate stringRedisTemplate;
@Pointcut("@annotation(com.dogame.dragon.sparrow.framework.common.annotation.Limit)")
public void pointcut() {
}
@Around("pointcut()")
public Object around(ProceedingJoinPoint joinPoint) throws Throwable {
ServletRequestAttributes attrs = (ServletRequestAttributes) RequestContextHolder.getRequestAttributes();
HttpServletRequest request = attrs.getRequest();
MethodSignature signature = (MethodSignature) joinPoint.getSignature();
Method signatureMethod = signature.getMethod();
Limit limit = signatureMethod.getAnnotation(Limit.class);
boolean useAccount = limit.useAccount();
LimitType limitType = limit.limitType();
String key = limit.key();
if (StringUtils.isEmpty(key)) {
if (limitType == LimitType.IP) {
key = IpUtils.getIpAddress(request);
} else {
key = signatureMethod.getName();
}
}
if (useAccount) {
LoginMember loginMember = LocalContext.getLoginMember();
if (loginMember != null) {
key = key + "_" + loginMember.getAccount();
}
}
String join = StringUtils.join(limit.prefix(), key, "_", request.getRequestURI().replaceAll("/", "_"));
List<String> strings = Collections.singletonList(join);
String luaScript = buildLuaScript();
RedisScript<Long> redisScript = new DefaultRedisScript<>(luaScript, Long.class);
Long count = stringRedisTemplate.execute(redisScript, strings, limit.count() + "", limit.period() + "");
if (null != count && count.intValue() <= limit.count()) {
log.info("第{}次拜访key为 {},描述为 [{}] 的接口", count, strings, limit.name());
return joinPoint.proceed();
} else {
throw new DragonSparrowException("短时间内拜访次数受限制");
}
}
/**
* 限流脚本
*/
private String buildLuaScript() {
return "local c" +
"\nc = redis.call('get',KEYS[1])" +
"\nif c and tonumber(c) > tonumber(ARGV[1]) then" +
"\nreturn c;" +
"\nend" +
"\nc = redis.call('incr',KEYS[1])" +
"\nif tonumber(c) == 1 then" +
"\nredis.call('expire',KEYS[1],ARGV[2])" +
"\nend" +
"\nreturn c;";
}
}
3.3 前端针对绑定手机按钮增加防止连点处理
四 总结
线上项目对于 Spring
供给的主动业务注解运用要多加考虑,尽可能减少业务影响规模,针对注册等按钮要在前后端增加防重复点击处理