第五周 作业二
分布式缓存架构:架构原理与使用中的注意事项
什么是缓存?
缓存是在介于数据访问者和数据源之间的通过一种高速存储存放原始数据的复制集,当数据需要多次读取的时候,用于加快读取的速度。
缓存(Cache)和缓冲(Buffer)的区别?
缓存是多次读取时加快读取速度的;缓冲也是高速与低速设备之间的装备,用来高速与低速设备间读写时,在设备之间做缓冲的中间存储,如高速设备向低速设备写入数据时,先写入缓冲,再由 Buffer 缓慢从将数据缓慢地写入低速设备。
场景与用途不一样。
无处不在的缓存
CPU 缓存,L1, L2, L3
操作系统缓存
数据库缓存
JVM 编译缓存,字节码指令
CDN 缓存
代理与反向代理缓存
前端缓存
应用程序缓存
分布式对象缓存
缓存的关键指标
缓存命中率
缓存是否有效依赖于能多次重用同一个缓存响应业务请求,
如果查询一个缓存,十次查询九次能够查询到正确结果,那么它的缓存命中率是 90%
影响命中率的指标
缓存键集合大小。缓存key进行识别,key 唯一性越高,重用的机会越小。减少可能的缓存键数量,键数量越少,缓存的效率越高。
缓存可使用内存空间。决定了缓存对象的大小和数量。物理上能缓存的对象越多,缓存命中率就越高。
缓存对象生存时间。TTL,缓存生命时间越长,被重用的可能行就越高。
分布式缓存架构:常见的缓存实现形式
通读缓存(read-through),客户端连接的是通读缓存而不是生成响应的原始服务器
代理缓存:数据中心中 HTTP 反向代理拦截所有请求
内容分发网络(CDN):静态URL解析为运营商最近机房的数据中心,CDN 作为托管反向代理服务器,缓存未命中时请求原始服务器。
CDN 同时配置静态文件和动态内容(AWS)
旁路缓存(cache-aside)
对象缓存是一种旁路缓存,通常是一个独立的键值对(key-value)存储
应用代码通常会询问对象缓存需要的对象是否存在,如果存在,它会获取并使用缓存对象,如果不存在或已过期,应用会连接主数据源来组装对象,并将其保存回对象缓存中以便将来使用
如浏览器对象缓存
本地对象缓存:应用程序中(jboss cache);共享缓存,同一台服务器的多个进程可以访问;独立缓存服务器
Memcached 分布式对象缓存,share-nothing 不感知对方
Memcached API , 路由算法(服务结点列表)、通讯模块、 Memcached 服务器集群
余数Hash 取模算法,扩容导致很多数据缓存不命中
分布式缓存架构:一致性 Hash 算法
增加服务器只会导致 一小部分 key 不能命中
Node 节点分布不均匀,数据存储不均衡
增加服务器只解决一台服务器的压力,负载的分摊也不均衡
基于虚拟节点的一致性 Hash 算法,每个物理服务器虚拟成多个虚拟节点,如1个服务器虚拟成 150 个node节点,通过key计算得到的这些节点都在这台计算机
构建 2^32 一致性 hash 环,每个服务器虚拟为多个节点,
尽量让前端缓存数据,节约服务器资源
为什么能提升性能
内存比磁盘更快
缓存计算最终结果,不需要中间计算,减少 CPU 资源消耗
降低数据库、磁盘、网络的负载压力,使这些 I/O 设备获得更好的响应特性
不需要用缓存的地方
频繁修改的数据
没有热点的访问
数据不一致和脏读
三大难题:缓存失效、命名事物、计算错误
缓存雪崩- 不能简单的重启缓存服务器和数据库服务器来恢复
缓存预热- warm up, 元数据如 城市地点列表、商品类目
缓存穿透- 一个简单的对策是将不存在的数据也缓存起来(其 value 为 null)
Redis VS Memcached
Redis 支持复杂的数据结构
Redis 支持多路复用一步/IO高性能
Redis 支持主从复制高可用
Redis 原生集群与 share nothing 集群模式
Redis 原生集群(不是 share nothing ,每个服务器共享服务器节点信息、Key 的分布)
LRU 算法,最近最久未用算法
消息队列:如何避免系统故障传递
缓存解决读性能问题。写数据使用消息队列的异步架构。
点对点模型。消息只会被消费一次
发布订阅模型。消息一次生成,多次消费
好处:
更容易扩展、伸缩
削峰填谷
失败隔离和自我修复
事件驱动架构 EDA
负载均衡架构:如何用十行代码写一个负载均衡服务器
请求分发
HTTP 重定向。好处:简单;坏处:一次请求变成两次、性能较低,暴露了实际应用服务器、带来安全隐患
DNS 负载均衡。一个域名配置多个 A 记录,轮询返回不同的IP。
只有第一次回域名解析,后面缓存。
域名解析是必需的。
反向代理负载均衡。反向代理服务器是否有缓存请求内容,没有则转发应用服务器处理。几台和十几台的规模。
效率低、性能差(转发 HTTP 请求),构建 HTTP 协议包
IP 负载均衡
把用户发过来的 TCP/IP 数据包中的 源地址改为负载均衡服务器 IP 地址,目标地址改为内部应用服务器 IP 地址,并记录影射表,数据返回时需要转换到用户IP。
操作系统内核处理,IP数据包小,处理能力大,处理简单
也可能成为响应的瓶颈,如网络的带宽
数据链路层负载均衡
修改 MAC 地址,负载均衡服务器和应用服务器的 IP 使用地址相同,同一个虚拟 IP 地址。
应用服务器返回数据直接返回给用户。
降低了负载均衡服务器处理压力、带宽压力
三角模式负载均衡
目前最主要的负载均衡方式
如何选择服务器
轮询方式,所有请求依次分发到每个应用服务器,适合所有服务器硬件相同的场景。
加权轮询,按照权重将请求分发到每个服务器,高性能的服务器分配更多的请求。
随机,简单
最少连接,记录每个应用服务器正在处理的连接数(请求数),将新到的请求分发到最少连接的服务器,最符合负载均衡定义
的算法
源地址散列,根据请求来源的IP地址进行Hash计算,得到应用服务器,保证同一个来源总在同一个服务器处理,实现会话粘滞
Session 管理
Session 复制
Session 散列,影响高可用
利用 Cookie 记录 Session
Session 服务器集群。集群伸缩容易,应用服务器是无状态的应用服务
版权声明: 本文为 InfoQ 作者【Yangjing】的原创文章。
原文链接:【http://xie.infoq.cn/article/b5d063399b90da811845d65b9】。
本文遵守【CC-BY 4.0】协议,转载请保留原文出处及本版权声明。
评论