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

项目背景

会员中心有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的开发思路。

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