架构技术选型一（总结）

• 分布式缓存架构

缓存是什么？

缓存是介于数据访问者与数据源之间的一种高速存储，当数据需要多次读取的时候，用于加快读取速度。常见的缓存场景：CPU缓存、操作系统缓存、数据库缓存、JVM编译缓存、CDN缓存、代理与反向代理缓存、前端缓存、应用程序缓存、分布式对象缓存……

缓存的数据结构

缓存一般用Hash表数据结构，通过对key的哈希计算来确定元素具体放在哪个数组下标。

缓存的关键指标

缓存命中率：

• 缓存是否有效依赖与能多少次重用同一个缓存相应请求，这个度量就是缓存的命中率

• 例如：查询一个缓存，十次查询有九次是无误的，那么命中率就是90%

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

• 缓存键集合大小

• 缓存中每个对象是通过键（key）去存储识别的，定位一个对象的唯一方式就是通过键。缓存键空间是你的应用能生成的所有键的数量。键越多命中率越小，反之越大。

• 缓存可使用内存空间

• 缓存可使用内存空间直接影响到你具体能缓存多少对象的数量。因为缓存是存在内存里的是比较昂贵的，如果想要存给多对象要定期或不定期清除老的对象/不常被访问的对象从缓存里移除。物理上缓存的越多，缓存命中率就越高。

• 缓存对象生存空间

• 缓存生存时间称为TTL（Time To Live）。需要更具业务场景设置失效时间。比如天气预报数据缓存15分钟没啥问题，但是电商产品可能随时更新，缓存15分钟就不合适的。简言之，对象缓存时间越长，缓存命中率越高。

代理缓存

代理缓存是指：用户访问的时候会先去代理服务器（公司网络代理服务器）查询缓存，命中直接返回，未命中到数据中心去请求返回。

反向代理缓存

反向代理是指：用户的访问会被方向代理拦截，缓存未命中时才转发到web服务器；多重反向代理是部署多个方向代理，用户请求通过负载均衡器（硬件负载或软负载）请求多个不同的服务器。

内容分发网络（CDN）

是网络供应商提供的用作托管的反向代理服务器，它可以同时配置静态文件和动态内容。

通读缓存（read-theoungh）

• 代理缓存、方向代理缓存、CDN都是通读缓存

• 通读缓存给客户端直接返回缓存资源，并在未命中时获取实际数据

• 客户端连接的是通读缓存，而不是生成响应的服务器

旁路缓存（cache-aside）

• 对象存储是一种旁路缓存，它通常是一个独立的键值对存储

• 应用代理通常会查询对象缓存是否存在，存在就直接返回，不存在就查数据源，把数据源存入缓存再返回。

浏览器缓存

通过javascript 存储在浏览器的缓存数据。

本地对象缓存

• 直接存储在在应用程序中

• 对象存储在共享内存中，同一台机器多个进程都可以访问

• 缓存服务器作为独立应用和应用服务器部署在同一台服务器上

远程分布式缓存

存储服务器以分布式的形式部署，客户端和web服务器通过远程调用去查询缓存。

分布式缓存的一致性hash算法

传统的分布式缓存当其中某些缓存服务下线后，因为重新计算缓存的命中节点和之前的不一致，就会导致所有的缓存失效。一致性hash算法可以大大降低缓存失效。它是通过抽象的一个环形结构，初始就会根据算法均匀划分不同的段，当有新节点加入的时候只会根据算法落在一小段节点当中。即时缓存服务器下线了几台，也仅仅影响导向下线这几台服务器的缓存失效。



各种介质的访问延迟



技术栈各个层次的缓存节省的资源



缓存为什么能显著提升性能

• 缓存一般存在内存中，内存比访问磁盘的速度要快的多

• 缓存一般存的最终形态不需要再计算，可以节省CPU计算资源

• 缓存降低了数据库、磁盘、网络的负载压力

合理使用缓存

要防止滥用、过分依赖缓存。要结合具体的业务场景考虑。经常改动的数据、没有热点访问以及需要数据强一致性的场景就不适合用缓存处理

缓存雪崩

是指当缓存维护/故障突然下线了后，大量请求到了数据库，导致数据库服务器宕机用户无妨访问服务。

缓存预热

缓存中存到热点数据，热点数据又是基于LRU（最近最久未用）算法不断对访问的数据淘汰筛选出来的，这个过程需要花费一定的时间，在这段时间里因为缓存的命中率低，系统的性能和数据库的负载不太好，那么最好的是将热点数据先加载好，比如：城市地名列表、分类信息、可以启动时加载数据库全部数据到缓存进行预热。

缓存穿透

缓存穿透是指在客户端访问服务器时服务器先查缓存，缓存未命中后查数据库，数据库也没命中放回空值。当大量请求都访问到这个数据时全部都要到数据库里查询，导致数据库访问压力增大。一般都解决方案为：缓存和数据库都未命中时，在缓存里存下这个值，只是值是个空值，并设置较短的过期时间

Redis缓存数据库

• 支持复杂的数据结构

• 支持复用异步I/O高性能

• 支持主从复制高可用

• 原生集群与share nothing集群模式

消息队列与异步架构

同步vs异步

同步调用在遇到响应时间长的场景时会迟迟占用系统资源阻塞线程直到执行完毕后才释放相关资源；异步调用，调用后直接就返回，不会等调用响应。

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

所有的消息生产者不直接给消费者交互，而是将消息发送给消息队列，消费者通过订阅消息队列来完成消费。实现系统解偶异步调用，提升系统性能。

消息队列模型

• 点对点模型

• 发布订阅模型

消息队列的好处

• 实现异步处理，提升系统性能

• 更好的伸缩性

• 削峰填谷

• 失败隔离、自我修复

• 解偶



主要MQ产品比较

• RabbitMQ：主要特点性能好，社区活跃。但是它是用Erlang开发，对不熟悉这么语言的开发来说不易于二次开发和扩展

• ActiveMQ：影响比较广泛，可以平台，使用java开发，对java开发比较友好（27M）

• RocketMQ：阿里推出的一款开源产品，也是使用java开发，性能比较好，可靠性比较高。（35M）

• Kafka：Linkedln出品，用Scala开发，专门针对分布式场景进行优化，因此分布式的伸缩性更好（63M）

负载均衡架构

负载均衡架构，是将用户的请求通过负载均衡架构根据场景合理的分发在分布式服务集群中。

HTTP重定向负载均衡

客户请求到HTTP重定向负载均衡服务器重定向到一个经过负载算出来的应用服务地址。

DNS负载均衡

客户请求到DNS服务器重定向到一个经过负载算出来的应用服务地址。

反向代理负载均衡

客户请求到反向代理服务器，方向代理服务器请求转发到经过负载算出来应用服务地址。

IP负载均衡

客户请求到负载均衡服务器，将请求数的目的ip改为负载计算后端应用服务地址，应用服务响应到负载均衡服务器，再由负载均衡服务器响应返回到客户端

数据链路层负载均衡

客户请求到负载均衡服务器，将请求数的目的ip改为负载计算后端应用服务地址，应用服务器直接响应到客户端

负载均衡算法

• 轮询

• 加权轮询

• 随机

• 最少连接

• 源地址散列

应用服务器集群的Session管理

Session复制（已被淘汰）

session在集群每个服务器上复制。当集群数量庞大时，session复制本身就会占用很多系统资源，影响业务访问

Session绑定

根据用户的ip,访问指定的服务器，实现session绑定机器。

利用Cookie记录Session

将session存放在客户端浏览器的cookie里，请求携带cookie

Session服务器

搭建共享Session服务器（集群），应用服务统一到session服务器获取session。

分布式数据库

Mysql 复制

• 主从复制



• 一主多重复制

• 优点：分摊负载、专机专用、便于冷备、高可用



• 主主复制





• 主主失效恢复

• 主主失效的维护过程



• 复制注意事项：

• 主主复制的两个数据库不能并发写入

• 复制只是增加了数据读并发的处理能力，没有增加写的并发处理能力

• 更新表结构会导致巨大的同步延迟