工程中通常权衡效率和安全
- 效率优先：以 redis 作为主数据库读写，mysql 作为备份数据库，性能最高，安全性较差。可以使用伪装从数据库 pika，从 redis 拉取数据，持久化。
- 安全优先：以 mysql 作为主数据库读写，redis 作为缓存数据库，缓存热点数据。用户只能从 redis 获取热点数据，降低 mysql 的读写压力。
本文主要讨论第二种方案。
1、访问性能提升
1.1、读写分离
为了解决读压力，设置多个从数据库，读操作在从数据库，写操作在主数据库，主数据库提供数据的主要依据。
读写分离
原理：主从复制。主从复制是异步复制方式，主从数据会有差异，读写分离只能保证数据最终一致性。若要保证强一致性，则读操作去读主数据库。
mysql 主从复制
主从复制
主从复制流程
- 主库更新事件（DML 操作）通过 io-thread 写到 binlog
- 从库请求 binlog，通过 io-thread 写入从库本地 relaylog 中继日志
- 从库通过 sql-thread 读取 relay-log，并把更新事件再从库中重放 repaly 一遍
1.2、连接池
为了并发提升数据库访问性能，在服务端创建多个与数据库的连接，同时复用连接，避免连接建立、连接断开、安全验证的开销。
原理：mysql 网络模型（IO 多路复用 select + 阻塞 IO）
特别地，如果发送一个多语句事务，那么该事务必须在一个连接中处理。
1.3、异步连接
减少网络传输时间，在服务创建一个非阻塞连接，使用非阻塞 IO
2、缓存方案
2.1、场景分析
业务场景中，读的需求远远大于写的需求，应当主要解决读性能。对于写没必要优化，必须保证写的数据正确落盘。所有数据存放在主数据库，热点数据存放在缓存数据库，用户只从缓存数据库获取热点数据，减少主数据库的读压力。
对于整个系统来说，缓存数据库不可用，系统仍然保持正常工作；主数据库不可用，系统停止对外提供服务。
存储层
主数据库选择一般选择关系型数据库，例如 mysql，原因是：
- 存储大量数据，磁盘存储
- 数据统计分析，关系型数据库
注：mysql 的自身缓存层（缓存索引，记录）与业务无关。
缓存层
缓存数据库可以选用内存数据库 redis, memcached，作为辅助数据库，存放热点数据。
热点数据
热点 key 总是在同一条连接操作。具体来说，同一个热点 key 在同一个 mysql 连接操作，同一个 redis 连接操作。以 hash(key)的方式实现。这样同一个 key 没有并发问题，避免加锁。
2.2、一致性状态分析
以主数据库 mysql 和缓存数据库 redis 为例，获取热点数据分别操作 redis 和 mysql
数据的状态可能有：
- mysql 有，redis 无
- mysql 无，redis 有
- 都有，但数据不一致
- 都有，数据一致
- 都没有
状态 1 4 5，没有问题。对于状态1，获取数据的主要依据是 mysql，只需要将 mysql 的数据正确同步到 redis 就可以了。
状态 2 3，存在数据不一致的问题。对于状态2，考虑 mysql 会主动断开长时间没有操作的连接，来减少系统资源消耗，此时若同时向 redis 和 mysql 写操作，redis 写入成功，mysql 写入失败，产生脏数据。对于状态3，mysql 同步到 redis 是异步复制，短时间内会出现数据不一致。
因此设置读写策略，就是为了解决上述状态 2 3 存在的数据不一致问题。
2.3、读写策略
2.3.1、读策略
热点数据读策略，非热点数据直接读数据库。
先读缓存层
- 没有，读 mysql
- 没有，则返回没有
- 有，mysql 读到的数据同步到 redis
- 有，直接返回
2.3.2、写策略
安全优先
先删除 redis 缓存，再写 mysql，等待 mysql 数据同步到 redis。回归为状态1
问题：为了安全降低效率，不断删除缓存，设置缓存没有了意义。
效率优先
先写 redis 缓存并设置过期时间，再写 mysql，等待 mysql 同步到 redis。若 mysql 写失败，redis 缓存数据过期失效；若 mysql 写成功，mysql 数据同步到 redis 会覆盖之前设置的过期时间。
设置过期时间大致为：mysql 网络传输时间 + mysql 处理时间 + 同步时间，200ms。
问题：过期时间内，缓存层和存储层数据不一致。如果没有写入主数据库，则这段时间内，提供了脏数据服务。
2.4、同步策略
将 Mysql 数据同步到 redis 中
- 伪装从数据库：阿里 canal，go-mysql-transfer 等
- 触发器 + udf：把热点数据表设置触发器，在触发器中调用 udf，udf 与 redis 建立连接，进行数据同步。效率低，不建议。
伪装从库
伪装从数据库原理
伪装从数据库以 go-mysql-transfer 为例，缺点是需要引入 zk，etcd 等实现高可用
安装 go-mysql-transfer
# 安装 Golang 1.14 及以上版本 wget https://golang.google.cn/dl/go1.17.8.linux-amd64.tar.gz tar -zxvf go1.17.8.linux-amd64.tar.gz # 配置 vim /etc/profile export PATH=$PATH:/opt/go/bin # 配置 go 环境变量 # 安装 go-mysql-transfer git clone https://gitee.com/mirrors/go-mysql-transfer.git GO111MODULE=on go env -w GOPROXY=https://goproxy.cn,direct go build
修改 mysql 配置文件，位置：/etc/mysql/my.cnf
log-bin=mysql-bin # 开启 binlog binlog-format=ROW # 选择 ROW 模式 server_id=1 # 配置 MySQL replaction 需要定义，不要和slave_id重复
修改 app,yml，配置 mysql 和 redis，配置热点数据
# mysql配置 addr: 127.0.0.1:3306 user: root pass: 123456 charset : utf8 slave_id: 1001 #slave ID # redis连接配置 redis_addrs: 127.0.0.1:6379 # redis地址，多个用逗号分隔 redis_pass: 123456 # redis密码 # 配置热点数据 schema: mark # 数据库名称 table: t_user # 表名称 order_by_column: id #排序字段，存量数据同步时不能为空 column_underscore_to_camel: true # 列名称下划线转驼峰,默认为false lua_file_path: lua/t_user.lua # lua脚本文件位置 # redis相关 redis_structure: hash # 数据类型。
编写 Lua 同步逻辑
local ops = require("redisOps") --加载redis操作模块 local row = ops.rawRow() --当前数据库的一行数据,table类型，key为列名称 local action = ops.rawAction() --当前数据库事件,包括：insert、update、delete -- 同步方法 if action == "insert" or action == "update" then -- 只监听insert事件 local id = row["id"] --获取ID列的值 local key = "user:" .. id local name = row["nick"] --获取USER_NAME列的值 local sex = row["sex"] local height = row["height"] --获取PASSWORD列的值 local age = row["age"] ops.HSET(key, "id", id) -- 对应Redis的HSET命令 ops.HSET(key, "nick", name) -- 对应Redis的HSET命令 ops.HSET(key, "sex", sex) -- 对应Redis的HSET命令 ops.HSET(key, "height", height) -- 对应Redis的HSET命令 ops.HSET(key, "age", age) -- 对应Redis的HSET命令 elseif action == "delete" then local id = row['id'] local key = "user:" .. id ops.DEL(key) end
启动 mysql, redis, go-mysql-transfer
# 全量数据同步，初次启动 ./go-mysql-transfer -stock # 启动 nohup go-mysql-transfer &
2.5、缓存方案的弊端
不能处理多语句事务。这是因为缓存数据库不支持回滚，造成缓存数据库与存储数据库数据不一致。
3、* 缓存故障
3.1、缓存雪崩
问题描述
- 特征：缓存层无，存储层有
- 原因：大量缓存数据同时过期；缓存数据库宕机。
- 描述：同一时间，大量缓存数据集中失效。若此时有大量用户请求，无法在 redis 处理，于是所有请求涌向数据库，从而导致数据库压力骤增，甚至数据库崩溃宕机。
解决方案
针对大量数据同时过期
- 均匀设置 key 过期时间：避免将大量数据同一时刻过期，设置 key 间隔过期或者随机过期。
- 分布式锁：保证同一时间只有一个请求构建缓存。
- 双 key 策略：主 key 设置过期时间，备 key 永久，主 key 过期返回备 key 内容
- 后台更新缓存：定时更新，消息队列通知更新
针对缓存数据库宕机
- 构建缓存高可用集群：主从节点构建缓存高可用集群，当缓存数据库宕机时，主从切换。
- 服务熔断或请求限流机制：当缓存数据库宕机时，服务熔断（暂停业务线程对缓存服务的访问，直接返回错误），请求限流机制（指限制访问数据库的请求数量）。
缓存数据库宕机重启
- 缓存数据库开启持久化，宕机重启后恢复数据。
- 缓存数据库预热，预先导入热数据，构建缓存。
3.2、缓存击穿
问题描述
- 特征：缓存层无，存储层有
- 原因：热点数据过期
- 描述：热点数据过期，大量用户请求该热点数据，无法在 redis 处理，高并发的请求涌向数据库。
解决方案
- 过热数据不过期：热点 key 不过期，由后台异步更新缓存。
- 分布式锁：保证同一时刻只能有一个业务线程更新缓存，其他请求线程只能等待该线程运行完毕，重新从 redis 中获取数据
3.3、缓冲穿透
问题描述
- 特征：缓存层无，存储层无
- 原因：请求不存在的数据。一般有两种情况，业务误操作删除缓存和数据库中的数据；黑客恶意攻击，故意大量请求不存在数据的业务。
- 描述：大量请求缓存和数据库都不存在的数据，无法在 redis 处理，高并发的请求涌向数据库。
解决方案
非法请求限制
判断如果是恶意请求，则直接返回错误。
缓存空值
当发现数据库不存在该 key，针对查询的数据，在缓存设置 <key, nil> 并设置过期时间，后续请求就可以从缓存中直接读取，不再访问数据库。但是会造成缓存数据库缓存很多无效数据，浪费内存；而且过期时间这段时间内缓存层和存储层数据不一致。
布隆过滤器
布隆过滤器是一种概率型的数据结构，特点是高效地插入和查询，能判断某个字符串一定不存在或可能存在。查询布隆过滤器若数据不存在，则数据库中该数据一定不存在；若数据存在，则数据库中该数据可能存在。
将 key 写入数据库时，使用布隆过滤器做标记。当用户请求到来，业务线程确认缓存失效后，可以查询布隆过滤器快速判断数据是否存在，若不存在，则不需要通过查询数据库来判断数据是否存在。即使发生了缓存穿透，大量请求也只会查询 Redis 和布隆过滤器，不会查询数据库。实际中，最好在缓存数据库上部署布隆过滤器。
布隆过滤器通过 3 个操作完成标记：
- 第一步，使用 N 个哈希函数分别对数据做哈希计算，得到 N 个哈希值；
- 第二步，将第一步得到的 N 个哈希值对位图数组的长度取模，得到每个哈希值在位图数组的对应位置。
- 第三步，将每个哈希值在位图数组的对应位置的值设置为 1
小结
- 缓存雪崩和缓存击穿主要原因是数据不在缓存。区别在于，缓存雪崩是面（大量数据），缓存击穿是点（热点数据）。
- 缓存穿透主要原因是数据不在数据库。缓存层和存储层一起穿透。
