会员中心架构-用户锁定状态存储你会怎么设计?

项目背景

会员中心有1000万注册会员,目前进行项目重构,使用Java语言,Oracle数据库,缓存使用Redis。

应用场景

会员登录超过3次,需要将会员的状态设置为锁定状态。在锁定状态的存储位置上产生的异议?如何进行锁定状态的存储和清理成为了关键问题。

登录流程[简化版]

1)前置条件:用户已注册账号,且进入登录页面;

2)前端:会员输入账号和密码登录;

3)后端:验证账号密码是否正确,如果不正确则错误次数+1;

4)用户:超过登录次数3次;

5)后端:更新会员状态为锁定状态;

6)后置条件:用户再次登录或部分业务请求显示用户状态为锁定状态;

领域分析

1)锁定状态是临时的状态,24小时后会清空;

2)锁定状态影响到部分业务场景的执行(需要判断会员状态时)

方案分析

1)存到Redis缓存中

优点:1、避免DB操作,提高系统性能;2、利用redis自身的缓存淘汰机制;

缺点:1、强依赖缓存-比如缓存故障时,锁定状态会丢失;2、增加了系统和代码编写的复杂度,多个子系统需要判断锁定状态,比如-会员系统-后台管理系统都需要判断缓存;

2)存到数据库字段中

优点:1、数据高一致性;2、代码简单;多接口需要会员状态时,不需要每次调用缓存的锁定状态进行判断;

缺点:1、损耗一点性能;2、需要开发定时任务-处理会员锁定状态过期;

改造方案

小结:缓存方式存储和判断会员锁定状态,适合会员信息全量缓存的架构。比如新浪微博等,而目前项目中未采用全量缓存会员信息的架构,会导致多个接口与缓存耦合,并且存在每次登陆逻辑都需要判断数据库状态,再判断缓存状态的弊端,因此使用数据库作为实施方案。

改造点

1)数据表:会员状态-增加状态标识-登录锁定;

2)代码:超过登录次数,更新会员DB记录为锁定状态;

3)定时任务:增加定时清理锁定状态过期的处理;

未来优化

1)增加锁定日志表,记录锁定的会员ID,避免定时任务全量扫描。

2)会员数据全量缓存,锁定状态通过缓存进行临时存储;

设计体会

架构设计不是高来高去,一定要根据具体的业务量,应用场景相结合,考虑非功能性需求(复杂性,扩展性等)以及团队情况。这样制定的方案才是最合理的方案(没有最好的,只有当下最合适的,具备一定的前瞻性,但不盲目超前)。适合互联网高效敏捷,快速迭代,最小MVP的开发思路。

这是我们的设计,欢迎留言讨论或提供更好的方案。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20181214B1INJ100?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券