03认证业务架构设计之缓存
3 认证业务架构方案设计
3.1 如何解决缓存问题
分布式环境常用什么缓存
思考：
1.引入Redis解决什么问题。
2.目前现状应用场景是什么样的。
业务说法：少量登录注册，大量业务请求。
需要翻译业务术语到专业术语：
专业术语: 少量写入操作，大量读取操作。
缓存首先要考虑的点是 一致性，如何保证
弱一致性：D1 写DB D2 写cache D3 读cache
也就是持久化一定要成功；
强一致性：
四种方案：
- D1 写cache D2 写DB
- D1 写db D2 写cache
- D1 删cache D2 写db
- D1 写 DB D2 删cache
要思考： 时间+多线程 叠加 干D1 D2两件事时，如果有两个线程T1 ， T2来做D1和D2，会出现问题。
在写DB和删除cache的先后方案中，这种方案应该是最好的方案。
要考虑：缓存的过期时间需要平摊到不同时间。
业务的容忍度
缓存失败如何应对
Redis 单点故障/集群/持久化
【单点问题应对之道】
自负冗分数
- 自动故障切换
- 负载均衡
- 冗余设计 -- 数据丢失
- 分布式设计 -- 拆在不同地方
- 数据备份和恢复 -- 出问题后恢复
分布式 解决什么问题：压力
集群 解决什么问题：能力
备份 解决什么问题：可靠
引申出来：
分布式/集群 ： 有可靠性问题
分布式/备份：能力不足 最终选择它
集群/备份： 有压力问题
分布式/集群/备份： 完美
⭐ 分布式是每一部分干的不一样的事情；集群是一坨东西干一样的事情。
认证的架构形式：
在这个架构中，Redis00 存放的key和Redis01or02是不一样的，每一个Redis中的Key干的事情也不一样。
1 估算Redis情况
需要使用120个Redis价格非常贵60W
需要向上截流
[突破口思考]
Tomcat:7层协议,专注业务处理
Nginx:7层协议,专注代理转发
LVS:4层协议,专注代理转发
DNS:域名解析,专注域名映射
对于登陆业务,需要的是存放登陆信息,首先考虑Tomcat的内存扩大,显然不可取,也就是扩大内存的方法不可取,需要将数据保存到磁盘,也就是 内存➕磁盘 来解决减少Redis.
[哪些框架支撑内存+磁盘]
Guava、Ehcache、 Caffeine
[如何选]
spring5 废弃Guava 支持Caffeine
Ehcache 性能读写14w+
[分片提升缓存命中率]
思考三个问题:
1 什么是缓存命中率
2 怎么才能命中
3 返乡思考为什么老是不能命中(缓存的时间太多没有命中?,分流到其他机器?,缓存容量?)
[分流影响]
LVS: 源地址hash
Nginx: 源地址hash
分流参数:有一个固定的值方便分流
3.2 Redis单点故障
Web容器:必须是无状态的才可以伸缩,登陆态一致性,不受节点变化影响.
Tomcat单点问题的应对考虑:
- 多个Tomcat使用一个磁盘
- 随机分,找不到去Redis
- 多部署一台Tomcat,存储全部数据
Redis:需要同步当前状态到各自的ehcache
3.3 CAP理论介绍
3.4 DID原则
强调原则: 设计、设施和部署
Design设计20倍的容量
Implement实施3倍的容量
Deploy部署1.5倍的容量
3.5 Nginx转发处理
3.6 两个思想
分治思想 + 切面思想
3.7 异常 监控 打点
功能点存在哪些异常的思考方法:
从外到内,按顺序来梳理.
共性的异常
S:服务状态异常
L:大量日志异常
C:cpu异常
M:内存居高不下
I:网络连接异常
D:磁盘读写异常
业务异常
写数据 度数据 空数据
监控+打点
3.8 认证模块功能设计图实现使用 时序图来说明使用本软件(Typora)
3.9 基础⾯试，表⾯看似基础，实际考验⾯试者结构性思维组织语⾔表述：
从⾃⼰所做的功能中，看看哪些地⽅⽤到了缓存，基于什么业务思考为什么要这么⽤？
尝试使⽤ START 分析法组织下语⾔，变成⾃⼰拿⼿的功能点描述。
“S”—— situation，背景或环境。
“T”—— task，制定任务。
“A”—— action，实施步骤。
“R”—— result，结果反响。
“T”—— think，思考改进。