系统架构设计师—数据库基础篇—数据库优化技术

文章目录

集中式数据库
- 反规范化设计
- - 分类
  - 保证数据的一致性方法
分布式数据库
分布式缓存技术-Redis

集中式数据库

反规范化设计

优点：

避免进行表之间的连接操作，可以提高数据操作的性能。

缺点：

数据的重复存储，浪费磁盘空间。
会产生数据不一致性问题。

分类

类型	说明	作用
增加冗余列	指在多个表中具有相同的列。	在查询时避免连接操作。
增加派生列	增加的列可用通过表中其他数据计算生成。	在查询时减少计算量，从而加快查询速度。
重新组表	如果许多用户需要查看两个表连接出来的结果数据，则把这两个表重新组成一个表来减少连接而提高性能。	在查询时减少连接，从而加快查询速度。
水平分割表	按记录进行分割，把数据放到多个独立的表中。	主要用于表数据规模很大、表中数据相对独立或数据需要存放到多个介质上使用的场景。
垂直分割表	对表进行分割，将主键与部分列放到一个表中，主键与其他列放到另一个表中。	在查询时减少I/O次数，以提高查询效率。

保证数据的一致性方法

触发器
事务机制保证（适用于单体数据库中）
应用保证（适用于异构数据库之间）
批处理脚本（）

分布式数据库

主从复制

主从复制，建立一个和主数据库完全一样的数据库环境，称为从数据库。

做数据的热备：作为后备数据库，主数据库服务器故障后，可切换到从数据库继续工作，避免数据丢失。
架构的扩展：业务量越来越大，I/O访问频率过高，单机无法满足，此时做多库的存储，降低磁盘I/O访问的频率，提高单个及其的I/O性能。
读写分离：使数据库能支持更大的并发。

基本过程

主从数据库之间通过 binary log（二进制日志，一般称 binlog）进行数据的同步。

binlog的同步模式

	基于SQL语句的复制	基于行的复制	混合复制
基本流程	每一条写语句都会记录在binlog中，进而同步到从库的relaylog中，被从库的SQL线程取出来，回放执行。	不记录SQL语句，只记录了哪个记录更新前和更新后的数据。	对于有绑定本地特性、评估可能造成主从不一致的SQL语句，则自动选用ROW；其他的选则STATEMENT。
优点	binlog的日志量比较少。	可以保证主从之间数据绝对相同。	binlog的日志量尽可能少，主从之间数据尽可能相同。
缺点	同步的SQL语句如果含有绑定本地变量的函数、关键字时，可能造成主从不一致的情况。如：时区。	单条SQL批量更新数据的情况，会产生大量日志。	受限于评估算法，如未快速支持某种新特性，可能产生主从数据不一致的问题。

MySQL的同步模式

		一致性	可用性	典型框架/系统
全同步复制技术	主库等待所有从库都同步完毕，才返回客户端。	强	弱	MySQL
半同步复制技术	主课等待至少一个从库同步完毕，则返回客户端	较强	较弱	MySQL、Zookeeper、Redis、Oracle
异步复制技术	主库不等待从库同步，执行完客户端提交的事务后就返回客户端。	弱	强	MySQL、Redis、Oracle

读写分离

读写分离，设置不同的主/从数据库分别负责不同的操作。

主数据库负责数据的写操作。
从数据库负责数据的读操作。

通过角色分担的策略，分别提升读写性能，有效减少数据并发操作的延迟。

分表

分表，也叫分片，解决并发能力、I/O性能提升。

将一张大表分成若干小表，业务同时访问多个表。

分表是重在单个实例内部，一张表拆分称多个表。

垂直切分
水平切分

分库

分库，将原本存放在一个实例上众多分类的数据(表)，分开存放到不同的实例上。有利于差异化管理。

分布式缓存技术-Redis

Redis用作缓存组件时，其基于内存的读写特性，比基于磁盘读写的数据库性能要高很多，适合缓存高频热点的数据，来提高读性能。这样可以降低厎数据库服务器的查询请求，提高系统性能。

数据类型

类型	说明	适用场景
string	基本类型。	可用于缓存层或计数器，如视频播放量、文章浏览量等。
hash	代替string类型，节省空间。	描述用户信息较为方便
set	无序集合，每个值不能重复。	可用于去重、抽奖、初始化用户池等。
zset	有序集合，每个元素有一个分数。	如首页推荐10个最热门的帖子。
list	双向链表结构，可以模拟栈、队列等形式。	可用于回复评论、点赞。
pub/sub	发布/订阅	可以用作消息队列,生产者将消息投送给某个key为主题的队列,消费者监听并得到消息的推送.

读写数据的基本步骤

读数据

根据key读缓存。
读取成功则直接返回。
若key不在缓存中时，根据key读数据库。
读取成功后写缓存。
成功返回。

写数据

根据key写数据库。
成功后更新缓存key值。
成功返回。

过期策略

惰性删除

查询key时，才对key进行检测，如果已经达到过期时间，则删除。

缺点：如果这些过期的key没有被访问，那么就一直无法被删除，一直占用内存。

定期删除

redis每隔一段时间对数据库做一次检查，删除里面的过期key。由于不可能对所有key去做轮询来删除，所有redis会每次随机取一些key去做检查和删除。

内存淘汰机制

淘汰机制	说明
volatile-lru	从已设置过期时间的key中，移出最近最少使用的key进行淘汰。
volatile-lfu	从已设置过期时间的key中，移出最不经常使用的进行淘汰。
volatile-random	从已设置过期时间的key中随机选择key淘汰。
volatile-ttl	从已设置过期时间的key中，移出将要过期的key。
allkeys-lru	从所有key中选择最近最少使用的进行淘汰。
allkeys-lfu	从所有key中选择最不经常使用的进行淘汰。
allkeys-random	从所有key中随机选择key进行淘汰。

持久化

	RDB内存快照(RedisDataBase)	AOF日志(Append Only File)
说明	把当前内存中的数据集快照写入磁盘(数据库中所有键值对数据)。恢复时，是将快照文件直接读取到内存里。	通过持续不断地保存Redis服务器所执行的更新命令来记录数据库状态，类似mysql的binlog。恢复数据时，需要从头开始回放更新命令。
磁盘刷新频率	低	高
文件大小	小	大
数据恢复效率	高	低
数据安全	低	高

缓存异常问题

缓存穿透

访问的key在redis中不存在。

原因：

恶意攻击，造成大量访问Redis中不存在的key。
大量请求访问数据库里有但redis没有的key。

解决方案：

针对来源是比较少的请求来源ip，主动限制访问次数，或者拉入黑名单。
应用程序检查key的合法性，提前拒绝不合法的请求。
使用布隆过滤器。
预热redis，运行一个批处理脚本，将可能会大量访问的数据预先加载到redis，业务再开张。
在最前端进行流量控制，逐步释放进来的请求。给出一段时间，让redis逐步加载热数据。
如果数据库里也没有的key，也要在redis中设置key，使其值为null或空。

缓存雪崩

Redis的key是已存在的，但同时失效了。

redis故障

如宕机、网络抖动

解决方案：

使用主从复制提高可用性，使用cluster集群方案降低故障时的影响范围。
如果出现故障，则可以采取服务降级、熔断、限流等措施。

大量key同时过期

采取了相同的过期时间，例如在同一时刻设置了大量的key，但过期时间都是5分钟。

解决方案：

过期时间加上一个随机值，使得众多key均匀过期。

缓存击穿

少量热点key缓存时间失效。

原因：

热点的key设置了太短的过期时间。

如：秒杀业务下的"库存数量"。

解决方案：

设置较长的过期时间。非常重要的key则设置永久有效。但需要解决好与数据库中的key的一致性问题。
使用分布式锁：如果热点key失效了，要控制好访问后端数据库的流量。只允许一个请求去访问数据库，取出罪行的key，存放到redis，其他请求必须等待。但分布式锁也要防止出现异常的情况。

集群

主从复制集群
哨兵集群
Cluster集群

切片

类型	说明
客户端分片	将分片工作放在业务程序端。不依赖于第三方分布式中间件，实现方法和代码可掌控，对开发人员要求高。
代理分片	将分片工作交给专门的代理程序来做，运维方便。代表：Twemproy，Codis。
服务器端分片	Redis Cluster将所有key映射到16384个Slot中，集群中每个Redis实例负责一部分，业务程序通过集成的Redis Cluster客户端进行操作。