第五周学习代码技术选型总结

今周的主题是技术选型

分布式缓存

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

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

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

* 缓存键集合的大小

* 缓存可使用的内存空间

* 缓存对象的生存时间

• 代理缓存

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

• 反向代理缓存

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

• CDN

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

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

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

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

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

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

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

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



• 技术栈各个层次的缓存



消息队列

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

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

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

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

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



负载均衡

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

• 分类

* HTTP 重定向负载均衡

* DNS 负载均衡

* 反向代理负载均衡

* IP负载均衡

* 数据链路层负载均衡

• 均衡算法

* 轮询

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

* 随机

* 最少连接

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

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

* 利用 Cookie 保存 Session

* Session 复制

* Session 绑定

* Session 服务器

总结

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



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



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