第五周学习总结
知识点总结
分布式缓存架构
什么是缓存 Cache
缓存:存储在计算机上的一个原始数据复制集,以便于访问。
缓存是介于数据访问者和数据源之间的一种高速存储,当数据需要多次读取的时候,用
于加快读取的速度。
缓存( Cache )和缓冲 (Buffer )的分别?
缓冲是用来在读写数据的时候在应用程序和低速的设备之间用来缓冲数据的中间存储。
无处不在的缓存
CPU 缓存
操作系统缓存
数据库缓存
JVM 编译缓存
CDN 缓存
代理与反向代理缓存
前端缓存
应用程序缓存
分布式对象缓存
缓存的关键指标
缓存命中率
缓存是否有效依赖于能多少次重用同一个缓存响应业务请求,这个度量指标被称作缓存命中率。
如果查询一个缓存,十次查询九次能够得到正确结果,那么它的命中率是 90%。
影响缓存命中率的主要指标
缓存键集合大小
缓存可使用内存空间
缓存对象生成时间
缓存键集合大小
缓存中的每个对象使用缓存键进行识别,定位一个对象的唯一方式就是对缓存键执行精确匹配。一定要想办法减少可能的缓存键数量。键数量越少,缓存的效率越高。
缓存可使用内存空间
缓存可使用内存空间直接决定了缓存对象的平均大小和缓存对象数量。因为缓存通常存
储在内存中,缓存对象可用空间受到严格限制且 相对昂贵。如果想缓存更多的对象,就
需要先删除老的对象,再添加新的对象。替换(清除)对象会降低缓存命中率,因为缓存对
象被删除后,将来的请求就无法命中了。物理上能缓存的对象越多,缓存命中率就越高。
缓存对象生成时间
TTL(Time to live)
原始数据被修改、缓存数据失效等导致缓存命中率降低
代理缓存
正向的代理
代理用户上网的服务器,通过代理服务器去访问用户想要访问的资源
用户不知道
反向代理
缓存目标服务器的输出,当用户访问过来时,先看缓存中有没有需要的内容,有的话直接返回,没有再去访问目标资源
restful 通过 url 访问,反向代理服务器更容易以 url 作为 key 缓存内容。所以说,对 restful 的支持更友好
CDN
可以在服务端对静态和动态内容指定不同的域名
也可以在 CDN 服务器中配置,区分动静资源,再跳转到不同服务器
缓存的类型
通读缓存(read-through)
代理缓存,反向代理缓存,CDN 缓存都是通读缓存
客户端直接连接的是通读缓存而不是目标服务器
通读缓存给客户端返回缓存资源,并在请求未命中缓存时获取实际数据
旁路缓存(cache-aside)
对象缓存是一种旁路缓存,通常是一个独立的键值对存储
应用程序通常会询问对象缓存需要的对象是否存在,如果存在,它会获取并使用缓存对象,如果不存在或已过期,应用程序会主动连接主数据源来获取对象,并同时将其保存到对象缓存中,以供将来使用。
旁路缓存中的对象,一般是不更新的,而是直接删除,再用新的对象替换
本地对象缓存
直接存储在应用程序内存中
存储在共享内存中,同一台服务器的多个进程可以访问它们
缓存服务器作为独立应用和应用程序一起部署在同一个服务器上
分布式缓存的关键技术点
缓存读写的路由选择
余数哈希
一致性哈希
扩展性,新增或删减服务器时的适应性
技术栈各层次的缓存
缓存为什么能显著提升性能
缓存数据通常来自内存,比硬盘要快
缓存存储的是数据是最终结果形态,不需要中间计算,减少 CPU 资源的消耗。
要么过期删除,要么新增,不要修改
缓存降低了数据库、磁盘、网络的负载压力,使这些设备能更好的响应
不正常的使用缓存
频繁修改的数据不适合使用缓存
应用来不及读取就已经失效或更新。一般来说,数据的读写在 2:1 以上,缓存才有意义
简单应用缓存,用于多次读取的情况,不要更新操作,会导致缓存效率降低
没有热点的访问
缓存使用的是内存,内存资源宝贵而有限,所以不能把所有数据都缓存起来,应该只缓存热点数据
根据二八定律,大部分的数据访问应该集中的小部分的数据上,否则,缓存就没有意义
怎样知道哪些是热点数据(LRU 算法,总是把热点数据放到头部)
数据不一致与脏读,最简单的是,应用需要容忍一段时间内的数据不一致问题。
缓存雪崩
缓存数据丢失或缓存不可用会导致数据直接从数据库获取数据
数据库可能因为不能完全承受缓存数据的读取压力而宕机
数据库宕机就会导致整个系统瘫痪
缓存预热
在缓存系统启动的时候就先把热点数据加载好。
对于一些源数据如城市地名列表等,可以在启动时加载数据库中所有数据到缓存中进行预热
目的是为了访问一进来就能访问到缓存数据
缓存穿透
如果持续高并发的请求某个不存在的数据,因为缓存中没有数据,请求就会落在数据库中,会给数据库带来很大压力,甚至崩溃。
一个简单的对策是,将不存在的数据也缓存起来,并设定一个较短的失效时间。
Redis VS Memcached
Redis 支持复杂的数据结构
Redis 支持多路复用异步 I/O 高性能
Redis 支持主从复制高可用
Redis 原生集群与 share nothing 集群模式
Redis 功能众多,更像是一个 NoSql 数据库。
Redis 使用的不是一致性 hash
消息队列与异步架构
同步调用 VS 异步调用
同步
多个耗时操作同步调用
异步
有回调的异步调用
消息队列构建异步调用框架
消息生产者
消息队列
消息消费者
两种架构模型
点对点模型:
生产者有多个,而且是独立的;只要求有消费者能处理生产者的消息。
发布订阅
生产者的消息有几个消费者订阅,就会有几个消息队列
多个消费者之间是独立的,一个消费消息不会影响另外一个消费者
消息队列的好处
实现异步处理,提升处理性能
相比缓存提升读的效率,消息队列可以提升写的效率。
更好的伸缩性
削峰填谷
失败隔离和自我修复
解耦
主要的 MQ 产品
RabbitMQ
ActiveMQ
RocketMQ
Kafka
负载均衡架构
HTTP 重定向负载均衡
用户访问 HTTP 重定向负载均衡服务器,服务器响应头返回一个重定向地址,不同用户访问不同的应用服务器。实现用户请求的分发。
缺点:一次网络通信变成了两次,效率低。安全性问题,重定向请求使用的是公网 IP。
DNS 负载均衡
用户请求 DNS 服务器不同用户返回不同的 IP,实现请求分发。
DNS 解析出来的公网 IP 地址是负载均衡服务器的 IP 地址。
反向代理负载均衡
基于 http 协议的转发
适用于小规模服务器,服务器集群不能太多。
反向代理服务器效率就会比较低
http 协议比较重,包比较大,要拿到完整的 http 包才能继续,所以解析压力就大
IP 负载均衡
负载进化服务器不再需要拿到完整的 http 包,而只要拿到 ip 层的请求;
转发请求时,将源地址改为负载均衡服务器 IP,目标地址改为应用服务器 IP
数据链路层负载均衡
用户端请求发向负载均衡服务器,负载均衡服务器修改 Mac 地址返回响应数据。
负载均衡的算法:请求应用服务器的路由选择
轮询
加权轮询
随机
加权随机
最少连接
原地址散列
总结
通过本周课程的学习对缓存的内容有了更全面的认知,缓存消息队列这些都是目前工作中特别常用的技术。结合工作思考之后也发现了一些问题,只要读写频繁的数据就全部丢缓存,只要需要解耦,缓冲的业务就会加上消息队列。并不是很合理,本周课程内容相对而言,还是很多的。我承认我还没有完全消化,有些感悟一时也表述不清。后续我不会做补充。
评论