案例介绍
用户中心的主要功能是维护用户信息、用户权限和登录状态，它保存的数据大部分都属于读多写少的数据。常见的优化方式主要是将用户中心和业务彻底拆开，不再与业务耦合，并适当增加缓存来提高系统性能。
用户中心通常是系统改造中第一个要优化的模块，因为它常常和多个系统重度耦合，所以梳理这个模块对整个系统后续的高并发改造非常重要。
结构梳理
数据库表结构主要可以分为四类，从数据结构出发，先对一些场景进行改造，按照这四类进行数据整理后，再按需设计缓存策略会轻松很多。
数据实体表
实体表一般会作为主表 ，它的一行数据代表一个实体，每个实体都拥有一个独立且唯一的 ID 作为标识。其中，“实体”代表一个抽象的事物，具体的字段表示的是当前实体实时的状态属性。
但是实体表的字段属性需要确认，不要过多，尤其是不要包含 text 字段，否则会导致数据量过多，作缓存时容易过大且需要进行一些特定字段剔除的处理。
不常用的字段可以通过横向或纵向拆分到辅助表中。
实体辅助表
实体表字段过多，且部分字段使用频率并不高的场景下，可以把这些字段摘出来，形成一张实体辅助表。
-
纵向拆分
直接把字段拆出来，辅助表的通过记录主表 ID 进行关联，它们之间的常见关系为 1:1。 -
横向拆分
一张横表，通常如下：
create table params (
id bigint not null auto_increment,
external_id bigint not null,
key varchar(64) not null,
value varchar(128),
primary key (id),
index idx_cluster_id (external_id));
engine=InnoDB default charset=utf8mb4;
通过 kv 方式维护，辅助表的通过记录主表 ID 进行关联，他们之间的常见关系为 1: n。
实体关系表
- 1: n 常用来表示从属关系
- n: 1 常用来表示分类聚合
- m:n 多对多关系，常见于社交等，建议简化为多组 1: n 关系进行维护
历史动作表
一般来说，动作历史数据表记录的是数据实体的动作或状态变化过程，比如用户登陆日志、用户积分消费获取记录等。这类数据会随着时间不断增长，它们一般用于记录、展示最近信息，不建议用在业务的实时统计计算上。
总结
- 能够通过 ID 快速匹配的实体，以及通过关系快速查询的数据，适合放在长期缓存当中；
- 通过组合条件筛选统计的数据，也可以放到临时缓存，但是更新有延迟；
- 数据增长量大或者跟设计初衷不一样的表数据，这种不适合、也不建议去做做缓存。
缓存
不是所有的数据放在缓存就能有很好的收益，我们要从数据量、使用频率、缓存命中率三个角度去分析。
临时缓存
最实用简单的方式就是临时缓存形式
- 先从缓存读，如果有，直接返回
- 如果没有，从数据库读取，并存入缓存，设置 TTL 过期时间
但这个在一些场景会出现缓存更新不及时的情况，比如
- 单条实体数据缓存刷新
- 关系型和统计型数据缓存刷新
单条实体数据缓存刷新
这种比较简单，在数据更新时，直接提出缓存相关缓存，待下次请求进入时再重新从数据库加载即可。
关系型和统计型数据缓存刷新
监控 binlog 更新
通过订阅数据库来找到 ID 数据变化触发事件，然后监听事件触发到具体执行逻辑来实现缓存更新。
版本号缓存设计
如果我们表内的数据更新很少，那么可以采用版本号缓存设计。这个方式比较狂放：一旦有任何更新，整个表内所有数据缓存一起过期。
比如对 user_info 表设置一个 key，假设是 user_info_version，当我们更新这个表数据时，直接对 user_info_version 进行 incr +1。而在写入缓存时，同时会在缓存数据中记录 user_info_version 的当前值。
识别主要实体 ID 来刷新缓存关联型数据缓存
这要保证其他缓存保存的 key 也是主要实体 ID，这样当某一条关联数据发生变化时，就可以根据主要实体 ID 对所有缓存进行刷新。这个方式的缺点是，我们的缓存要能够根据修改的数据反向找到它关联的主体 ID 才行。
长期热数据缓存
数据库要是扛不住平时的流量，我们就不能使用临时缓存的方式去设计缓存系统，只能用长期缓存这种方式来实现热点缓存，以此避免缓存穿透打沉数据库的问题。要求我们的业务几乎完全不走数据库，并且服务运转期间所需的数据都要能在缓存中找到，同时还要保证使用期间缓存不会丢失。
这边提供一个长期热缓存的简单实现逻辑图。一些 key point：
- 如何判定是否是热点数据？
- 对于数据量小，可以直接通过 list、map 维护
- 对于数据量大，可以通过 Bloom Filter
- 锁的作用
- 仅让抢到锁的服务去做更新操作，其他的直接读缓存，减少压力。
- 为什么数据没查到要写 null 到缓存
- 减少对于这个 key 查询 db 的压力
Token: 降低用户身份鉴权压力
传统的 Session 方式是把用户的登录信息通过 SessionID 统一缓存到服务端中，客户端和子系统每次请求都需要到用户中心去“提取”，这就会导致用户中心的流量很大，所有业务都很依赖用户中心。
为了降低用户中心的流量压力，同时让各个子系统与用户中心脱耦，我们采用信任“签名”的 token，把用户信息加密发放到客户端，让客户端本地拥有这些信息。而子系统只需通过签名算法对 token 进行验证，就能获取到用户信息。这种方式的核心是把用户信息放在服务端外做传递和维护，以此解决用户中心的流量性能瓶颈。
此外，通过定期更换 token，用户中心还拥有一定的用户控制能力，也加大了破解难度，可谓一举多得。