Mysql缓存方案

前提：读多写少，单个主节点能支撑项目数据量；数据的主要依据是mysql。

一、MySQL缓存方案目的分析

mysql 有自己缓冲层，它的作用也是用来缓存热点数据，这些数据包括索引、记录等。mysql 缓冲层是从自身出发，跟具体的业务无关。这里的缓冲策略主要是 lru。

mysql 数据主要存储在磁盘当中，适合大量重要数据的存储；磁盘当中的数据一般是远大于内存当中的数据。

一般业务场景的关系型数据库（mysql）是作为主要数据库的。

1.1、缓存层的作用

MySQL缓存方案用来缓存用户定义的热点数据，用户直接从缓存获取热点数据，降低数据库的读写压力。

1.2、缓存层选择

缓存数据库可以选用 redis，memcached；它们所有数据都存储在内存当中，当然也可以将内存当中的数据持久化到磁盘当中。

1.3、场景分析

（1）内存访问速度是磁盘访问速度10W倍，访问磁盘的速度比较慢，尽量使获取数据是从内存中获取。

（2）读的需求远远大于写的需求。主要解决读的性能；因为写没必要优化，必须让数据正确的落盘。如果写性能出现问题，那么请使用横向扩展集群方式来解决。

（3）MySQL自身缓冲层跟业务无关。由于 mysql 的缓冲层不由用户来控制，也就是不能由用户来控制缓存具体数据。

（4）MySQL作为项目主要数据库，便于统计分析。项目中需要存储的数据应该远大于内存的容量，同时需要进行数据统计分析，所以数据存储获取的依据应该是关系型数据库。

（5）缓存数据库作为辅助数据库，存放热点数据。缓存数据库可以存储用户自定义的热点数据。

二、提升MySQL访问性能的方式

（1）读写分离。

（2）连接池。

（3）异步连接。

（4）预处理。

（5）更换存储引擎。

（6）分库分表。（淘汰的技术）

（7）mycat。（淘汰的技术）

（8）tidb。

2.1、MySQL主从复制

mysql_M_S

1. 主库更新事件 ( update、insert、delete ) 通过 io-thread写到 binlog。

2. 从库请求读取 binlog，通过 io-thread 写入从库本地 relay log（中继日志）。

3. 从库通过 sql-thread 读取 relay-log，并把更新事件在从库中重放（replay）一遍。

复制流程：

1. Slave 上面的 IO 线程连接上 Master，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容。
2. Master 接收到来自 Slave 的 IO 线程的请求后，负责复制的IO 线程会根据请求信息读取日志指定位置之后的日志信息，返回给 Slave 的 IO 线程。返回信息中除了日志所包含的信息之外，还包括本次返回的信息已经到 Master 端的 binlog 文件的名称以及 binlog 的位置。
3. Slave 的 IO 线程接收到信息后，将接收到的日志内容依次添加到 Slave 端的 relay-log 文件的最末端，并将读取到的Master 端的 binlog 的文件名和位置记录到master-info 文件中，以便在下一次读取的时候能够清楚的告诉 Master 从何处开始读取日志。
4. Slave 的 sql 进程检测到 relay-log 中新增加了内容后，会马上解析 relay-log 的内容成为在 Master 端真实执行时候的那些可执行的内容，并在自身执行。

由于MySQL的主从复制是异步的，所以同一时刻主数据库和从数据库的数据可能存在不一致的现象，这就造成可能从数据库中读取的数据不是最新的。

2.2、读写分离

读写分离

读写分离会设置多个从数据库，从数据库可能会在多个机器中。

写操作依然在主数据库中，主数据库提供数据的主要依据。

读写分离通过设置多个从数据库解决读压力。

读写分离主要依据MySQL的主从复制原理，因为MySQL的主从复制是异步复制的，所以读写分离只能保证数据的最终一致性，不能保证实时一致性。

如果读操作有强一致性要求，那么需要读操作去读主数据库。

2.3、连接池

connectors

连接池的定义：在服务端当中创建多个与数据库的连接线程。

解决的问题：并发提升数据库访问性能；同时复用连接，避免连接建立、断开依据安全验证的开销。

原理：利用MySQL的网络模型创建多个连接，每个连接复用去处理SQL语句。值得注意的是，如果发送一个事务（多条SQL语句），这个事务必须要在一个连接里面完成。

2.4、异步连接

在服务端创建一个连接，针对这个连接采用非阻塞IO。这种方式可以节省网络传输时间。

三、redis作为主数据库的常用方法

（1）以redis为主，在redis中读写数据，MySQL作为数据备份，过程中可能需要分布式消息队列（kafka）进行异步同步。这种方式性能最高，但安全性较差。仅适合小项目。工程中要会在效率和安全直接做权衡。

（2）针对redis持久化较差的情况，最早使用leveldb伪装成从数据库，不断从redis中获取数据来实时持久化。

随着技术提升，leveldb的方式被淘汰，使用了更完善的pika方式。pika内部使用的rocksdb，支持redis协议。

四、缓存方案

4.1、缓存和MySQL一致性状态分析

没有缓冲层之前，对数据的读写都是基于 mysql；所以不存在同步问题；这句话也不是必然，比如读写分离就存在同步问题（数据一致性问题）。

引入缓冲层后，对数据的获取需要分别操作缓存数据库和mysql，那么这个时候数据可能存在以下状态：

1. mysql 有，缓存无。
2. mysql 无，缓存有。
3. 都有，但数据不一致。
4. 都有，数据一致。
5. 都没有。

缓存和MySQL一致性状态

4 和 5显然是没问题的，现在需要考虑1、2以及3。

首先明确一点：获取数据的主要依据是 mysql，只需要将mysql 的数据正确同步到缓存数据库就可以了。

同理，缓存有，mysql 没有，这比较危险，此时可以认为该数据为脏数据；所以需要在同步策略中避免该情况发生；同时可能存在mysql 和缓存都有数据，但是数据不一致，这种也需要在同步策略中避免。

注意：以MySQL为主，保证缓存不可用，整个系统依然要保持正常工作；mysql 不可用的话，系统停摆，停止对外提供服务。

4.2、制定读写策略

读写策略

读策略：先读缓存，若缓存有，直接返回；若缓存没有，读mysql；若 mysql 有，同步到缓存，并返回；若 mysql 没有，则返回没有。

读策略

写策略：从安全优先方面考虑；先删除缓存，再写 mysql，后面数据同步交由 go-mysql-transfer 等中间件处理（将问题 3 转化成 1）。

先删除缓存，为了避免其他服务读取旧的数据；也是告知系统这个数据已经不是最新，建议从 mysql 获取数据。但是对于服务 A 而言，写入 mysql 后，接着读操作必须要能读到最新的数据。

写策略，安全优先

写策略：从效率优先方面考虑；先写缓存，并设置过期时间（如 200ms），再写mysql，后面数据同步交由其他中间件处理。

这里设置的过期时间是预估时间，大致上是 mysql 到缓存同步的时间。在写的过程中如果 mysql 停止服务，或数据没写入 mysql，则200 ms 内提供了脏数据服务；但仅仅只有 200ms 的数据错乱，即效率优先的写策略也有安全性的问题，但只会影响200ms。

写策略，效率优先

五、同步方案

同步方案可以有：

（1）伪装从数据库。比如阿里开源的canal方案、kafka、go-mysql-transfer等。

（2）MySQL的触发器+udf。udf全称User-defined function，是MySQL提供的一种可扩展代码。UDF不具备事务，不能回滚；而且效率较低。

5.1、canal

canal会考虑分布式问题，如果一个canal宕机了，会有从canal顶替上来，保证服务正常提供。

canal

5.2、go-mysql-transfer

go-mysql-transfer只有一个节点，相对canal简单些，没有解决分布式问题。要增强go-mysql-transfer的高可用，可以引入etcd、zk等。

go-mysql-transfer的项目地址：Gitee 极速下载/go-mysql-transfer)

操作步骤：

（1）找到MySQL的my.ini配置文件，修改为主从模式。设置binlog-format=ROW和server-id=1。

（2）修改go-mysql-transfer中的app.yml文件的mysql配置和redis连接配置。

# mysql配置
addr: 127.0.0.1:3306
user: root
pass: root
charset : utf8
slave_id: 1001 #slave ID
flavor: mysql #mysql or mariadb,默认mysql

#redis连接配置
redis_addrs: 127.0.0.1:6379 #redis地址，多个用逗号分隔
#redis_group_type: cluster   # 集群类型 sentinel或者cluster
#redis_master_name: mymaster # Master节点名称,如果group_type为sentinel则此项不能为空，为cluster此项无效
#redis_pass: 123456 #redis密码
#redis_database: 0  #redis数据库 0-16,默认0。如果group_type为cluster此项无效

（3）修改go-mysql-transfer中的app.yml文件的规则配置，设置热点数据。

#规则配置
rule:
  -
    schema: eseap #数据库名称
    table: t_user #表名称
    #order_by_column: id #排序字段，存量数据同步时不能为空
    #column_lower_case:false #列名称转为小写,默认为false
    #column_upper_case:false#列名称转为大写,默认为false
    column_underscore_to_camel: true #列名称下划线转驼峰,默认为false
    # 包含的列，多值逗号分隔，如：id,name,age,area_id  为空时表示包含全部列
    #include_columns: ID,USER_NAME,PASSWORD
    #exclude_columns: BIRTHDAY,MOBIE # 排除掉的列，多值逗号分隔，如：id,name,age,area_id  默认为空
    #column_mappings: USER_NAME=account    #列名称映射，多个映射关系用逗号分隔，如：USER_NAME=account 表示将字段名USER_NAME映射为account
    #default_column_values: area_name=合肥  #默认的列-值，多个用逗号分隔，如：source=binlog,area_name=合肥
    #date_formatter: yyyy-MM-dd #date类型格式化， 不填写默认yyyy-MM-dd
    #datetime_formatter: yyyy-MM-dd HH:mm:ss #datetime、timestamp类型格式化，不填写默认yyyy-MM-dd HH:mm:ss
    #lua_file_path: lua/t_user.lua   #lua脚本文件
    #lua_script:   #lua 脚本
    value_encoder: json  #值编码，支持json、kv-commas、v-commas；默认为json
    #value_formatter: '{{.ID}}|{{.USER_NAME}}' # 值格式化表达式，如：{{.ID}}|{{.USER_NAME}},{{.ID}}表示ID字段的值、{{.USER_NAME}}表示USER_NAME字段的值

    #redis相关
    redis_structure: string # 数据类型。 支持string、hash、list、set、sortedset类型(与redis的数据类型一致)
    #redis_key_prefix: USER_ #key的前缀
    #redis_key_column: USER_NAME #使用哪个列的值作为key，不填写默认使用主键
    #redis_key_formatter: '{{.ID}}|{{.USER_NAME}}'
    #redis_key_value: user #KEY的值（固定值）；当redis_structure为hash、list、set、sortedset此值不能为空
    #redis_hash_field_prefix: _CARD_ #hash的field前缀，仅redis_structure为hash时起作用
    #redis_hash_field_column: Cert_No #使用哪个列的值作为hash的field，仅redis_structure为hash时起作用，不填写默认使用主键
    #redis_sorted_set_score_column: id #sortedset的score，当数据类型为sortedset时，此项不能为空，此项的值应为数字类型

    #mongodb相关
    #mongodb_database: transfer #mongodb database不能为空
    #mongodb_collection: transfer_test_topic #mongodb collection，可以为空，默认使用表名称

    #elasticsearch相关
    #es_index: user_index #Index名称,可以为空，默认使用表(Table)名称
    #es_mappings: #索引映射，可以为空，为空时根据数据类型自行推导ES推导
    #  -
    #    column: REMARK #数据库列名称
    #    field: remark #映射后的ES字段名称
    #    type: text #ES字段类型
    #    analyzer: ik_smart #ES分词器，type为text此项有意义
    #    #format: #日期格式，type为date此项有意义
    #  -
    #    column: USER_NAME #数据库列名称
    #    field: account #映射后的ES字段名称
    #    type: keyword #ES字段类型

    #rocketmq相关
    #rocketmq_topic: transfer_test_topic #rocketmq topic，可以为空，默认使用表名称

    #kafka相关
    #kafka_topic: user_topic #rocketmq topic，可以为空，默认使用表名称

    #rabbitmq相关
    #rabbitmq_queue: user_topic #queue名称,可以为空，默认使用表(Table)名称

    #reserve_raw_data: true #保留update之前的数据，针对rocketmq、kafka、rabbitmq有用;默认为false

（4）写lua同步逻辑。

（5）启动mysql个redis。

六、缓存方案的故障问题及解决

6.1、缓存穿透

假设某个数据 redis 不存在，mysql 也不存在，而且一直尝试读怎么办？缓存穿透，数据最终压力依然堆积在 mysql，可能造成mysql 不堪重负而崩溃。

解决方案：

（1） 发现 mysql 不存在，将 redis 设置为 <key, nil>，设置过期时间 ，下次访问 key 的时候 不再访问 mysql 容易造成 redis 缓存很多无效数据。

（2）布隆过滤器，将 mysql 当中已经存在的 key，写入布隆过滤器，不存在的直接 pass 掉。

1）缓存设置 <key,nil>，告诉服务器mysql也没有数据，不用去访问mysql了。这种方式可能占大量内存。
2）部署布隆过滤器。

6.2、缓存击穿

缓存击穿是某些数据 redis 没有，但是 mysql 有；此时当大量这类数据的并发请求，同样造成 mysql 过大。

解决方案：

（1） 分布式锁。请求数据的时候获取锁，若获取成功，则操作后释放锁；若获取失败，则休眠一段时间（200ms）再去获取，当获取成功，操作后释放锁。

（2） 将很热的 key，设置不过期。

6.3、缓存雪崩

表示一段时间内，缓存集中失效（redis 无， mysql 有），导致请求全部走 mysql，有可能搞垮数据库，使整个服务失效。

缓存数据库在整个系统不是必须的，也就是缓存宕机不会影响整个系统提供服务。

解决方案：

（1）如果因为缓存数据库宕机，造成所有数据涌向 mysql。采用高可用的集群方案，如哨兵模式、cluster模式。

（2）如果因为设置了相同的过期时间，造成缓存集中失效。设置随机过期值或者其他机制错开失效时间。

（3） 如果因为系统重启的时候，造成缓存数据消失。重启时间短，redis 开启持久化（过期信息也会持久化）就行了； 重启时间长提前将热数据导入 redis 当中。

6.4、缓存方案的弊端

不能处理多语句的事务。redis不支持回滚，造成redis跟MySQL的不一致。

七、总结

1. binlog的作用是数据备份和主从复制；确保主从数据的一致。
2. redolog的作用是确保事务持久化，确保本地数据一致。
3. 缓存方案读策略：先读缓存，存在则直接返回；不存在则去访问MySQL，再写redis。
4. 缓存方案写策略，从安全为主；先删除缓存层中对应数据，再写MySQL，最后将MySQL数据同步到缓存层。添加缓存层的目的是为了提升效率，这种方式为了安全降低了效率。
5. 缓存方案写策略，从效率为主；先写缓存层并设置过期时间，再写MySQL，等待MySQL同步到缓存层中。过期时间=MySQL网络传输时间+MySQL处理时间。
6. 缓存穿透的解决方法有：缓存设置 <key,nil>，告诉服务器mysql也没有数据，不用去访问mysql了；部署布隆过滤器。