架构师训练营第五周学习总结

什么是缓存？

缓存是介于数据访问者（应用程序）和数据源直接的一种高速存储，当数据需要被多次读取的时候，用于加快读取的速度。

缓存（Cache）和缓冲（Buffer）的区别？

Buffer的目的是平衡存储设备之间速度，比如：硬盘，网卡之上加了内存buffer，平衡了速度不匹配的问题，读有读buffer，写有写buffer。而cache只是为了多次读。

缓存的关键指标

缓存是否有效取决于有多少次重用同一个缓存响应业务请求，这个度量标准称为缓存命中率。

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

缓存键集合大小（总共有多少个key，比如有几百万商品，那就有几百万），缓存可用内存空间，缓存对象生存时间

什么是通读缓存（read-through）？

代理缓存，反向代理缓存，CDN都属于通读缓存。通读缓存给客户端返回缓存资源，并在请求未命中缓存时获取真实数据。客户端连接的是通读缓存而不是生成响应的原始服务器。

什么是旁路缓存（cache-aside）？

对象缓存是一种旁路缓存，旁路缓存通常是一个独立的key-value存储。应用代码通常会询问对象缓存需要的对象是否存在，如果存在，它会获取并使用缓存的对象，如果不存在或已经过期，应用会连接真实数据源来组装对象，并将其保存回对象缓存中以便将来使用。

本地对象缓存

1）对象之间缓存在应用程序内存中。（HashMap）

2）对象存储在共享内存中，同一个机器的多个进程可以访问它。

3）缓存服务器作为独立应用和应用程序部署在同一机器上（localhost socket通信）。

远程分布式对象缓存

缓存服务器之间彼此无感知，share nothing。存储空间随着服务器数量增多而线性增大。

集群和分布式区别？

很多个机器构建一个系统对外服务，就叫分布式系统。集群是分布式概念中的子集，特指提供相同功能或相同角色的机器所构建的子系统。

一致性hash

构建一致性hash环，范围0到2^32-1，把机器经过hash算法后等到的hash值放到hash环上，根据一个key查找对应的机器时，就是把key经过hash算法后得到的hash值顺时针查找到对应的机器上，那台机器就是key要访问的机器。增加或减少机器，只影响附近一小段的数据。



但是以上的方案存在负载不均衡的问题（比如：node2和node3挨得比较近，那么node3的负载就明显比较低；再比如，加机器的时候，只影响了附近的结点，其他机器的负载不受影响，可能违背了加机器分担负载的目标），以及机器节点hash值冲突导致节点覆盖的问题。于是就引入了虚拟节点的概念。虚拟节点的个数经验值是150~200之间。

各个介质数据访问延迟

技术栈各个层次的缓存

缓存越早越好。

控制缓存失效的LRU算法

怎么知道热点数据呢？就是LRU算法。

解决缓存不一致与脏读

加上失效时间，或者加上更新通知进行删除缓存。给用户一些预期，比如你的更新真正审核中，几分钟后生效。

Redis集群

Redis集群预先分配好16384个桶，当需要put一个key-value的时候，根据crc16(key) mod 16384得出这个key应该放置到哪个桶里面。redis-cluster把所有的物理结点映射到者16384个桶里面，一个机器扶着一部分桶，加机器会触发桶的重新分配和数据迁移。Redis客户端不需要连接集群的所有节点，连接任意一个节点即可。

何时使用多级缓存？

对性能有更高要求（0.5ms都等不及的），或者是超级热点。

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

点对点模型：

发布订阅模型：

消息队列的好处

1）实现异步处理，提升写性能

2）更好的伸缩性

3）削峰添谷

4）失败隔离和自我修复

5）解耦

耦合表面积



负载均衡架构（请求怎么发过去）

HTTP重定向负载均衡

缺点：每个请求都要经过重定向服务器进行重定向，性能差；暴露了应用服务器的外网ip（应用服务器其实是比较脆弱的，容易有bug，攻击面比较大，被攻击后损失非常严重），容易遭受攻击，安全性存在问题。



DNS负载均衡

优点：DNS有缓存，性能方面比较好

缺点：暴露应用服务器外网ip，安全性仍然存在问题。应用服务器宕机，下线或发布的时候，要修改域名服务器把ip下掉是非常难的。

淘宝，百度那些也用了DNS负载均衡，但是实际上他们用了两级负载均衡。



反向代理负载均衡

目前小型网站会使用，大型互联网不会使用这种方案。主要是HTTP本身协议比较重，反向代理可能会成为瓶颈。这种能应对的集群规模比较有限。



IP负载均衡

负载均衡服务器需要修改请求包的源地址和目标地址做修改，再转发给应用服务器，应用服务器处理完以后再返回给负载均衡服务器，负载均衡服务器收到后再重新修改响应包的源地址和目标地址做修改，再发送给用户。这种方案的处理能力就远远超过了反向代理负载均衡的方式。这里负载均衡服务器的网卡带宽容易成为瓶颈，比如图片服务器的场景。



数据链路层负载均衡

负载均衡服务器通过修改收到请求包的mac地址为目标应用服务器的mac地址，并且负载均衡服务器DS和所有的RS绑定了同一个vip。这种方式，应用服务器处理完直接返回给用户，不需要经过负载均衡服务器，负载均衡服务器的网卡带宽不再成为瓶颈。这种负载均衡的三角模式，是大型网站经常使用的。



负载均衡算法（如何选择应用服务器）

轮询，加权轮询，随机，最少连接（记录每台应用服务器正在处理的连接数或请求数），源地址散列（会话粘滞）



应用服务器的Session管理

session复制

缺点：这种方案集群规模是受限的。做集群就是为了分摊负载，负载高说明用户量大了，但是做了集群反而把数据同步过来了。这种使用过一小段时间，很快被淘汰了。



session绑定

这种方案几乎没有使用。主要原因是：互联网快速迭代，快速发布，升级的时候就是要关闭程序，关闭后会话就丢失了，用户请求就失败了。



利用cookie记录session

缺点：有些终端禁用cookie，并且cookie会加大网络传输的带宽消耗。

优点：简单，请求任意一台应用服务器都能从cookie获取到session。



session服务器

目前最常用的方案。应用服务本身是无状态的，session服务器实现比如使用redis。



MySQL一主多从的优点

1）分摊负载

2）专机专用（应用读请求，数据分析等场景可以分开，避免互相影响）

3）便于冷备和热备

4）高可用



MySQL主主复制







解决主服务器宕机后高可用问题。两台服务器互相进行数据同步，注意客户端不写主服务器B。这里主要是为了数据库高可用，不是为了双写。主要是并发更新的话，数据冲突的问题解决不了。当主服务器A挂了以后，把写请求切换到主服务器B就能恢复了。