架构师训练营 第 5 周总结

用户头像
Lingjun
关注
发布于: 2020 年 07 月 05 日

本周学习重点知识点:

  • 分布式缓存架构

  • 缓存和缓冲的区别

  • 缓存:把常用的数据存储到可以快速获取的区域(缓存区),以备重复读取,提高效率。例如,将业务数据缓存在应用程序或者 Redis 等缓存服务中,避免每次都查询数据库,从而提高访问性能,降低对数据库的查询压力。

  • 缓冲:在数据流转过程中,不同层次数据速度不一致时,利用缓冲区来缓解上下层之间的速度问题。例如,将数据从内存写入到磁盘时,先写入缓冲区,磁盘则直接从缓冲区中读取写入,减少 IO 次数,增加速度,降低对磁盘的损耗。

  • 使用缓存的位置

  • CPU 缓存

  • 操作系统缓存

  • 数据库缓存

  • JVM 编译缓存

  • CDN 缓存

  • 代理与反向代理缓存

  • 应用程序缓存

  • 分布式对象缓存

  • 缓存的关键指标

  • 缓存命中率(及受影响的主要指标)

  • 缓存键集合大小

  • 缓存可使用内存空间

  • 缓存对象生存时间

  • 缓存方式

  • 通读缓存(read-through)

  • 旁路缓存(cache-aside)

  • 缓存集群的2个核心问题(适用于各种集群)

  • 集群路由

  • hash + 取模(对伸缩不友好,扩容时大量缓存会失效,可能导致缓存雪崩和系统崩溃)

  • 一致性 hash(只有很小部分缓存会失效,推荐使用)

  • 集群伸缩

  • 消息队列与异步架构

  • 异步调用

  • 有回调的异步调用

  • 多次异步调用,不阻塞应用线程

  • 消息队列构建异步调用架构

  • 消息生产者

  • 消息队列

  • 消息消费者

  • 架构模型

  • 点对点

  • 发布订阅

  • 消息队列的好处

  • 实现异步处理,提升处理性能

  • 更好的伸缩性

  • 削峰填谷

  • 失败隔离和自我修复

  • 解耦

  • 负载均衡架构

  • 负载均衡的种类

  • HTTP 重定向负载均衡

  • 缺点

  • 性能问题(2次请求)

  • 安全问题,直接暴露了应用服务器

  • 只支持 Get 请求

  • DNS 负载均衡

  • 反向代理负载均衡

  • IP 负载均衡(三层协议)

  • 数据链路层负载均衡(二层协议)

  • 负载均衡算法

  • 轮询

  • 加权轮询

  • 随机

  • 最少连接

  • 源地址散列

  • 应用服务器的 Session 管理

  • Session 复制

  • Session 绑定(无法满足业务发展需要,因为服务器扩容,或者重启都会导致 Session 丢失)

  • 利用 Cookie 记录 Session

  • Session 服务器

  • 分布式数据库

  • MySQL 复制

  • 主从复制

  • 一主多从复制

  • 分摊负载

  • 专机专用

  • 便于冷备

  • 高可用

  • 主主复制

一些学习感悟:

  • 关于集群伸缩

hash(key) + 按节点数取模 的方式对集群伸缩不友好,以集群节点100个为例,增加一个新节点会导致99%的缓存数据失效。

这种方式在极端情况下,会导致其它服务器压力大增,引起缓存雪崩,最后使整个系统崩溃。而且在访问高峰期间,系统很难重新恢复,刚重启,数据库就可能瞬间被打爆。这时候要让系统恢复,可以通过 Nginx 阻断限流,慢慢放流量,才可能在高峰期恢复系统。



一致性哈希 + 虚拟节点,在以集群节点100个为例时,增加一个新节点只会导致1%的缓存数据失效。

一致性哈希算法可以将数据尽可能平均的存储到N台缓存服务器上,提高系统的负载均衡,并且当有缓存服务器加入或退出集群时,尽可能少的影响现有缓存服务器的命中率,减少数据对后台服务的大量冲击。



  • 关于缓存的使用

缓存一般不需要更新,在数据发生变化时,通常只要把缓存清除就可以了,不需要同步更新。

缓存集群扩容时导致小部分数据访问不到没关系(比如通过一致性哈希只有很小一部分数据失效),只要不出现大面积数据失效就没太大问题(比如hash(key)取模的方式)。

缓存强大就是因为它简单,缓存就应该有缓存的样子,最纯粹地使用缓存,它简单、耐用、时效。不要把缓存的数据搞得完美同步,那样反而会增加不必要的复杂度。



一条数据从Redis缓存读取和从数据库查询(带索引)的性能会相差100倍左右(从Redis中读取大约是0.5毫秒,从数据库查询大约是十几到50毫秒)。



  • 负载均衡



负载均衡的高并发

第一级通过DNS负载均衡到多个反向代理负载均衡服务器(DNS解析会在客户端有缓存,更新一次DNS负载均衡不会立马生效,架构中应考虑这一点)

第二级反向代理负载均衡服务器再分发到具体的后台服务器上

如果第二级还是不够用,那么可以增加DNS负载均衡的反向代理服务器(DNS改动会有延迟,因为客户端的缓存),或者通过F5之类的硬件负载均衡服务器(走更底层的协议,如数据链路层)来转发到多个反向代理负载均衡服务器



负载均衡服务器的高可用

可以通过类似 LVS + Keepalived 实现



LVS、Nginx 一般可以支持数万至十万级的并发

硬件负载均衡可以用在百万级的并发

阿里的 SLB 七层、四层、二层都有



  • 分布式数据库



一般方案

主主+多从,以实现高可用(主主)和高性能(主从,读写分离)

双主的方案可能导致数据的不一致和冲突,比如主1宕机时,有数据未同步到主2,那么主2的自增id的数据会和主1有冲突,此类问题没有太好的解决办法,一般需要额外的工作来追回数据,或者就直接放弃掉那部分数据(如果不重要的话)



如果需要做DDL的话,因为DDL可能会导致所表,使数据暂时无法插入,所以在更新主上的表结构时候,同时手动更新从上的表结构(而不是等待同步自动更新),因为此时从是最好的更新时机,因为如果主的表锁住,也不会有数据进入主,那么从可以趁这个时段同时更新表结构。



发布于: 2020 年 07 月 05 日 阅读数: 55
用户头像

Lingjun

关注

还未添加个人签名 2018.11.22 加入

还未添加个人简介

评论

发布
暂无评论
架构师训练营 第 5 周总结