Skip to content

架构优化

1 使用缓存

使用Redis，常用且简单的做法。

注意：

  1. 注意MySQL和Redis的数据一致性
  2. 注意Redis占用的内容（或者说注意缓存的数据量）

2 读写分离（集群、主从复制）

读写分离，将读和写分离到不同的服务器上，避免了读写冲突的同时提高读写效率。

项目的初期，数据库通常是运行在一台服务器上的，用户的所有读写请求会直接作用到这台数据库服务器，单台服务器承担的并发量终究是有限的。

针对单机的并发量瓶颈，我们可以同时使用多台数据库服务器来形成“集群”来解决——将其中一台服务器作为主节点（master/source）,其余节点作为从节点（slave/replica）,主节点负责写操作，从节点负责读操作，主节点在写操作时，会自动将数据同步到从节点，从而实现读写分离。

主节点将数据同步到从节点的操作，称为主从复制。binlog 是实现 MySQL 主从复制的基础，主节点会将所有的写操作记录到 binlog 中，从节点会有专门的 I/O 线程读取主节点的 binlog，将写操作同步到当前从节点，从而实现主从复制。

3 分库分表

3.1 垂直分库

垂直分库——在单体数据库的基础上垂直切割，按照业务逻辑拆分成不同的数据库。

// 传统结构
application --- database --- table[user,order,goods]

// 垂直分库
application --- database01 --- table[user]
            |-- database02 --- table[order]
            |-- database03 --- table[goods]

3.2 垂直分表

垂直分表——根据具体业务进行判断出冷热字段，将一张大表根据冷热字段切割成冷热两(N)张表。

// 传统结构
tbl_goods: {
  goods_id,
  goods_name,
  goods_price,
  goods_detail,
  goods_property,
}

// 垂直分表
tbl_goods: {
  goods_id,
  goods_name,
  goods_price,
}

tbl_goods_info: {
  goods_id,
  goods_detail,
  goods_property,
}

一般来说，商品详情信息比较长，而且查看商品列表时往往不需要立即展示商品详情（一般点击查看商品详情时才需要显示），所以可以将经常显示的商品名、商品价格信息存储到主表，而商品详情信息存储到另一个表，这样在查看商品列表时，可以只查询主表，而当用户点击查看商品详情时，再查询另一个表。从而实现垂直分表。

理论原理：

MySQL单个数据页的大小是 16KB，也就是说，单条记录的大小越少，单个数据页存储的记录行数就越多，每次查询数据页能够查询到的数据也就越多，也就不需要那么多的数据页进行存储。所以，垂直分表能够提高查询效率。

3.3 水平分表

水平分表——将一张大表切割成多张表，将数据按照一定的规则(分片规则)分配到不同的表。

例如将前5000万条数据切割成5张表，每张表存储1000万条数据。

3.4 总结

  • 水平划分 => 解决存储的瓶颈问题

  • 垂直划分 => 减轻并发压力

4 消息队列

消息队列的作用：解耦、异步、削峰