系统架构设计师案例分析题——数据库缓存篇
一.核心知识
1.redis和MySQL的同步方案怎么做的？
- 读数据：先查询缓存，缓存不存在则查询数据库，然后将数据新增到缓存中
- 写数据：新增时，先新增数据库，数据库成功后再新增缓存；更新和删除时，先更新或者删除数据库中的数据，再删除缓存或者修改缓存的过期时间
2.实现Redis和MySQL之间的同步的方法
- 利用触发器
- 通过数据库插件
- 异步队列方式同步，可采用消息中间件处理
- 实现同步方案，先查缓存，查不到再从DB查询，并保存到缓存，更新缓存时先更新数据库，再讲缓存设置过期
3.Redis分布式存储常见方案
中从模式、哨兵模式、集群模式
4.Redis集群切片的常见方式
- 客户端分片：即在客户端就通过key的hash值对应到不同的服务器
- 中间件实现分片：再应用软件和Redis中间，由中间件实现服务到后台Redis节点的路由分派
- 客户端服务端协作分片：Redis cluster模式，客户端采用一致哈希，服务端提供错误节点的重定向服务slot上
5.分布式缓存
在高并发的环境下，为了减轻数据库压力，提高系统响应事件，在应用和数据库之间增加独立缓存系统，常见的分布式缓存有Redis和memcache。
6.解决SQL注入有哪几种方式
- 正则表达式
- 参数化的过滤语句
- 检查用户的输入合法化
- 数据加密处理
- 存储过程
- 漏洞扫描工具
- web防火墙
7.Redis缓存淘汰机制
- 所有key中随机淘汰一个key
- 在过期时间的key中，删除使用频率最少的key
- 在过期时间的key中，删除即将要过期的key
- 所以key中，删除最不经常使用的key
- 随机删除设置了过期时间的key
8.Redis数据结构与文件持久化差别在哪
- 磁盘更新频率：前者频率较慢，后者每条指令对数据的操作都要保存，默认时间1秒
- 数据安全：前者不如后者安全
- 数据一致性：RDB可能发生数据丢失和不一致，后者即使宕机也能解决一致性问题
- 重启性能：前者恢复速度比后者快很多
- 数据文件大小：前者保存整个数据库的快照，容量比后者大
二.案例考察扩展
1.简要说明数据迁移准备工作的内容
- 待迁移数据源的详细说明：包括数据的存放方式、数据量和数据的时间跨度
- 建立新旧系统数据库的数据字典，对现有系统的历史数据进行质量分析，以及新旧系统数据结构的差异分析
- 新旧系统代码数据的差异分析
- 建立新旧系统数据库表的映射关系，对无法映射字段的处理方法
- 开发或者购买、部署ETL工具
- 编写数据转换的测试计划和校验程序
- 制定数据转换的应急措施
2.SQL语句优化的常见策略
- 建立雾化视图或者尽可能减少多表查询。
- 以不相干子查询替代相干子查询。
- 只检索需要的列。
- 用带in的条件子句等价替换or子句。
- 经常提交commit，以尽早释放锁。
- 避免嵌套的游标和多重循环等。
三.真题
1.2024下半年
Cache-aside架构，也称为旁路缓存模式，是一种常见的缓存使用策略。
1+2.填空流程图说明缓存读写的过程。
- 向缓存请求读取该商品信息
- 若命中则返回该商品信息
- 若未命中则访问数据库查询该商品信息
- 将查询到的数据库数据更新到缓存
- 将查询到的数据库目标数据返回
- 更新数据库中的目标商品信息。
- 将数据库中更新的商品信息写入到缓存中，确保数据一致性。
3.王工使用了多线程技术进行缓存处理，线程1负责写入，线程2负责读取，可能存在数据一致性问题，请解释其原因，并给出3个以上的解决办法。
原因：
- 如果没有适当的同步机制，两个或多个线程可能同时访问和修改共享资源，导致最终结果取决于线程调度顺序。
- 在多线程环境中，一个线程对共享变量所做的更改不一定立刻被其他线程看到。
- 写入操作可能不是一个原子操作，意味着它可以被中断或分段执行。
解决方案：
- 延时双删
- 同步删除
- 加互斥锁（分布式锁）
- 消息队列
- 基于缓存更新策略
2.2024上半年
1.使用基于数据库的分布式锁所存在的缺陷
基于数据库的分布式锁虽然实现简单，但在高并发、高可用性场景下存在一些明显的缺陷，主要包括以下几个方面：
- 数据库读写性能较低，锁竞争导致连接池耗尽
- 非原子性操作具有风险
- 数据库锁通常是非公平的
- 如果使用单机数据库，一旦数据库宕机，所有依赖它的分布式锁将失效。
- 锁超时的时间难以设定
2.redis的几种操作命令
- 写入：SET key value，哈希：HSET key field value
- 查询：GET key，哈希：HGET key field
- 删除：DEL key1 [key2]，哈希：HDEL key field1 [field2]
3.基于redis的数据库锁也会存在死锁场景，举例说明：
基于数据库的分布式锁和基于redis的分布式锁都存在问题，还有哪些其它的分布式锁的类型？
- 利用 ZooKeeper 的 临时有序节点（Ephemeral Sequential Nodes） 实现锁竞争。
- 基于 etcd 的 租约（Lease） 和 事务（TXN） 实现
- 利用 Consul 的 KV 存储+Session 机制
- 基于 Redlock 的分布式锁（Redis 多实例）
- 基于 Chubby（Google）的分布式锁，Google 内部的分布式锁服务，类似 ZooKeeper 但更强调高可用。