【高并发-用户中心】读多写少的系统如何优化

• 本博客纯属个人总结，非原创。
• 喜欢技术交流的，可关注博主，武汉有后端开发群，可支持内推，了解武汉行情等。

如何对读多写少的系统进行高并发优化？

比如：用户中心是一个读多写少的系统，它经常喝多个系统重度耦合，固用户中心通常是系统改造中第一个要优化的模块，
读多写少的系统通过缓存能得到性能提升。

---

数据梳理

任何老系统在做高并发改造(重构)时，都建议先做一次表的梳理。
现状：老系统在使用数据库时，会存在很多问题，比如：实体表字段过多，表之间关系混乱，用途多样，存在多对多关系等。

先梳理数据库结构，再对系统进行高并发改造是有帮助的。

精简数据会有更好的性能

用户中心是读多写少的数据，主要功能是维护用户信息，用户权限，登陆状态。

(读多写少)优化手段：将用户中心和业务彻底拆开，不再于业务耦合，并适当添加缓存来提高系统性能。

举例说明：有张表接近2000万的账户表，对表功能和字段进行业务解耦和精简，让用户中心的账户表只保留用户登陆所需要的账号，密码。

CREATE TABLE `account` (
  `id` int(10) NOT NULL AUTO_INCREMENT,
  `account` char(32) COLLATE utf8mb4_unicode_ci NOT NULL,
  `password` char(32) COLLATE utf8mb4_unicode_ci NOT NULL,
  `salt` char(16) COLLATE utf8mb4_unicode_ci NOT NULL,
  `status` tinyint(3) NOT NULL DEFAULT '0'
  PRIMARY KEY (`id`),
  UNIQUE KEY `login_account` (`account`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

精简：减少账户表字段的核心在于，长度小的数据再吞吐，查询，传输上都很快，方便管理+缓存。精简数据量虽然能换来更好的响应速度，但不提供过度设计，我们需要在 "更多的字段 " 和 “更少的职能” 之间找到平衡。

总结：通过精简表的职能来提高表的性能和维护，同时需要在更多的字段和更少的职能之间找到平衡。

---

数据的归类及深入整理

目的：对不同类型的表做不同方向的缓存优化。

数据主要有四种：实体对象主表，辅助表，实体关系，和历史数据。
错误场景：将用户来访记录历史，放进缓存中，记录的目的是统计有多少好友来访，有多少陌生人来访，它同时保存着和用户是否是好友的标志。

需求：好友关系发生变化，历史数据需要同步更新

将历史记录和需要实时更新的好友状态混在一起，是不合理的，我们应该拆分成三个职能表，分别进行管理：

• 历史记录表：不做缓存，仅展示最近几条，极端情况临时缓存。
• 好友关系：缓存关系，用于统计有几个好友。
• 统计数字

数据实体表：主表，一行数据代表一个实体，拥有一个独立唯一的ID作为标识，实体代表着抽象的事物，实体中的字段是当前实体的动态属性，这类表是针对业务的主要查询需求而设计的。

一个人代表着一个实体，一个人中有很多器官表示属性。

ID是很重要的，用户登陆后用自己的账户ID直接找到对应的订单，用户信息和好友信息，但是业务除了按照ID查找，还需要一些组合条件，比如：

• 在7月4日下单购买耳机的订单有哪些？
• 天津的用户里有多少新注册的用户？有多少老用户？
• 昨天是否有用户名前缀叫rick的账号注册？
• count(), sum()

这种根据条件查询统计的数据是不太容易做缓存的，高并发服务缓存的数据通常是能够Hash直接匹配的数据，因此这类数据只适合存在关系数据库中或提前作为热点数据放到缓存中直接使用，不能频繁查询，在高并发系统中要减少使用数据库做计算。

总结：实体表的核心思路有以下几点

• 精简数据总长度，要从更多的字段和更少的职能中进行权衡。
• 减少表承担的业务职责。
• 减少统计计算查询。
• 实体数据更适合放进缓存中
• 尽量让实体能够通过ID或关系方式查找
• 减少实时条件筛选方式的对外服务。

实体辅助表：对主表拆分，常见的方式是纵向表拆分

纵向表拆分的目的：把主表使用频率不高的数据搬出去，精简主表的职能，实体辅助表和主表的关系一般是1:1。
.
比如账户主表用于登陆，而辅助信息表保存着家庭地址，省份，微信，邮编等平时不会展示的信息，目的是辅助查询。

实体关系：

针对m:n的实体关系，一般推荐再加一个关系表来记录，这样两个实体就不用相互依赖，导致难以维护。

历史数据表：记录数据实体的动作或状态变化过程，比如用户登陆日志，用户积分消费等，这类数据会随着时间不断增长，不建议用在业务的实时统计计算上，如果真的需要统计，建议维护一张实时查询统计表会更好。

总结

• 根据当前的业务逻辑对比数据表进行职能归类，精简主表，要在更多的字段和更少的职能中做权衡，
• 数据可分为四类：实体主表，辅助表，实体关系表，历史表。

读多写少场景如何解决更新缓存不同步问题

只有热点数据放到缓存中才有价值。
在某一刻内，将查询用户信息频繁的数据放进缓存中，设置过期时间，简称：临时缓存。

设置过期时间的好处是：能帮我们节省内存，节约钱。

缓存更新不及时问题

临时缓存是有过期时间的，如果60秒内去数据库中修改了用户信息，缓存是不会马上更新的，需在60秒后才会刷新这个用户的昵称缓存，解决办法如下：

• 单点实体数据缓存刷新
  更新用户昵称，先更新数据库，然后清理缓存，让下次读取时刷新缓存。
• 关系型和统计型数据缓存刷新
  订阅数据库来找到ID数据变化，将Binlog变更信息推送到MQ内，在消费的时候更新对于的缓存。

长期热数据缓存

当过期时间到期时，如果大量缓存请求没有命中，透传的流量会进入数据库，这就是常见的缓存穿透问题，数据库若扛不住流量，我们就不能使用临时缓存的方式去设计缓存系统，只能使用长期缓存这种方式来实现热点缓存。
如果热key过期，大量请求进入数据库层，我们可以利用"热点数据重建"手段，对查询条件进行加锁，让一个线程获取锁去数据库中查询，重建数据，其他线程阻塞，待重建数据完成后，也就避免了大量流量进入数据库。

如何降低用户身份鉴权的流量压力

目的：如何用token算法降低用户中心的身份鉴权流量压力
历史版本：在用户登陆成功后，将用户信息写在服务端的session缓存中，并分配一个session_id保存在cookie中, 该用户每次请求会带上这个ID，用来获取用户信息。

注意：其他系统每次拿到ID，都需要去用户中心获取用户信息，全站的请求都会对用户中心进行访问一次，影响到响应速度，决定了QPS上限。

如何降低用户中心与各个子系统间的耦合度，提高系统的性能呢？

• JWT登陆和token校验
  常见的方式是签名加密的token，用户登陆后将用户信息放到一个加密签名的token中，每次请求都把这个token放到header或cookie内，带给服务端，服务端直接解析token获取用户的信息，无需和用户中心做任何交互请求。
  服务端和用户中心解耦，业务服务端直接解析带来的token，即可获取用户信息，无需每次请求都去用户中心获取，token的刷新完全可以由App客户端主动请求用户中心来完成，而不再需要业务服务端去用户中心更换。

如何实现机房之间的数据同步

如何保证多机房数据的一致性