架构师训练营第五周 - 总结

发布于: 2020 年 07 月 06 日
架构师训练营第五周 - 总结

今周的主题是技术选型

分布式缓存

技术简单,性能提升显著,应用场景多。但应注意合理使用,不合理的使用会成为累赘。缓存服务器崩溃还会将大量的访问压力传递到后端,造成缓存雪崩。

  • 适用于遵循二八定律访问的系统,将热点数据保存在缓存中,减轻对后端的压力。

  • 影响缓存命中率的主要指标

* 缓存键集合的大小

* 缓存可使用的内存空间

* 缓存对象的生存时间

  • 代理缓存

部署与客户端所在网络,减少对远程网络数据的访问,加快客户端的数据加载

  • 反向代理缓存

部署于服务器端所在网络,减轻对后端数据访问的压力

  • CDN

  • 有互联网上的 CDN 提供商提供,对网站的部分内容进行托管,未命中时再向网站原始服务器发送请求。

  • 根据对客户端对缓存的了解程度,可分为

* 通读缓存 —— 客户端直接向缓存请求数据,未能命中时由缓存向后端服务获取数据交给客户端

* 旁路缓存 —— 客户端先尝试从缓存获取数据,未命中时客户端直接向后端服务获取数据,并更新缓存

  • 分布式缓存的一致性 Hash 算法

* 避免增加节点时大批节点的缓存失效

* 可通过增加虚拟节点层来减轻数据存储倾斜的程度

  • 各种介质的数据访问延迟

  • 技术栈各个层次的缓存

消息队列

  • 异步处理,提升性能。发送请求后不必等待请求处理完成,可以继续处理其它事情。

  • 更好的伸缩性。消息被排队,消息生产者和消息处理者的数量可以不一样,消息处理者的数量可以根据消息产生的速率进行动态调整。

  • 削峰填谷。消息生产者与消息处理者按各自的步调生产和消费消息,消息队列起到了缓冲的作用,吸收瞬时涌入的大量消息,不致于冲垮后端的消息消费者。

  • 失败隔离和自我修复。生产者和消费者互相不受对方失败影响。提高可用性,减低部署难度。

  • 解耦。生成者不关心有多少个消费者对消息感兴趣,以及消息会如何被处理,便于添加新的消费者扩展业务逻辑。消费者不关心生产者具体是谁,只要符合约定的消息格式就可以进行处理,便于添加新的生产者,扩展前端的业务解除面。

负载均衡

对服务器集群的访问进行分配,充分利用服务器资源,配合系统伸缩。

  • 分类

* HTTP 重定向负载均衡

* DNS 负载均衡

* 反向代理负载均衡

* IP负载均衡

* 数据链路层负载均衡

  • 均衡算法

* 轮询

* 加权轮询 —— 根据服务器性能配置权重

* 随机

* 最少连接

* 原地址散列 —— 保证相同来源的请求被相同的服务器处理,实现会话粘滞

  • 应用服务器集群的 Session 管理

* 利用 Cookie 保存 Session

* Session 复制

* Session 绑定

* Session 服务器

总结

本周的内容覆盖面比较广,浏览了大型网站实施中常见的各种技术手段,比较了各种方案的优缺点,分析了各自适用的场合。

从技术上来看,各自方案都是秉承了计算机科学中的分而治之、增加额外中间层这两个原理。对问题进行分解,利用局部性解决系统中的热点问题(例如缓存),利用专职的中间层负责与业务无关的复杂基础设施逻辑(例如分布式数据库中间件),利用异步提高性能和可伸缩性。

互联网系统除了要解决传统企业信息系统中的业务逻辑问题外,还要面对大访问量、大数据量的问题,由此产生了与传统系统中不同的解决方案。甚至以应对高并发、大数据量为优先,放弃了传统架构中的一些原则。这些都是在生存压力下快速演化的结果。如果抱着传统系统的方式来开发,企图从一开始就构建一个大而全的系统,很快就会被淘汰。

用户头像

Lost Horizon

关注

给写代码的人写代码 2017.10.17 加入

Clojure

评论

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