week5 conclusion 分布式缓存架构 + 消息队列

分布式缓存架构



1. Cache vs. Buffer



缓存（Cache）：是介于数据访问者和数据源之间的一种高速存储，当数据需要多次读取的时候，用于加快读取的速度。



缓冲（Buffer）：是介于信息生产者和消费者之间的一种包含机制，当消费者消费速度慢于生产速度时，用于保护系统避免崩溃。



1. When a computer buffers information or buffers, it stores information temporarily in its memory while dealing with it or sending it.

2. to provide protection against harm



2. Cache is everywhere



单机环境下



• CPU cache

• 操作系统cache

• 数据库cache

• JVM编译cache



多机环境下



• CDN 缓存

• 代理与反向代理缓存

• 前端缓存

• 应用程序缓存

• 分布式对象缓存



3. How to store data in a caching system?



使用Hash表，查询性能是O(1)，但存在着哈希冲突的先天缺陷。如何设计和使用好cache，需要根据问题场景好好设计。



4. Key Metrics of a Caching System



4.1 Cache Hit Rate



​ 缓存命中率(Cache Hit Rate)，是缓存是否有效的关键度量指标，表示能多少次重用同一个缓存响应业务请求。影响缓存命中率的主要因素有：



• 与缓存中key set的大小成反比

• 与缓存可使用的内存空间成正比



• 与缓存对象的生存时间(TTL)成正比



5.分布式对象缓存的一致性hash算法





算法的关键点在于



• 将hash code（Integer.MIN ~ Integer.MAX)在INT32值域上构成一个环，使得每一个key都能落在环上，并顺时针找到最接近的节点，该节点作为该key的cache存储节点。当某个物理节点移出环上时，只需将该节点上已有的cache对象移到下一个物理节点上。新增物理节点时类似。

• 为了降低一个物理节点移动时要迁移的cache对象数量，在环上给每个物理节点增加等距离的若干虚拟节点，可有效降低迁移数量，因为在cache对象寻找存储节点时更加分散了。



参见作业1的实现。



6.各种介质数据访问延迟





7 缓存提升性能的原因



• 缓存数据通常来自内存，比磁盘上的数据有更快的访问速度。

• 缓存存储数据的最终结果形态，不需要中间计算，减少 CPU 资源的消耗。

• 缓存降低数据库、磁盘、网络的负载压力，使这些 I/O 设备获得更好的响应特性。



8. 缓存使用注意事项



• 频繁修改的数据不适合用缓存：存在应用还来不及读取就已失效或更新，徒增系统负担。一般的，数据的读写比在2:1以上，缓存才有意义。

• 没有热点的访问是不合理的设计：如果应用访问数据不遵循二八定律，即大部分访问不是集中在小部分数据上，就存在浪费内存的问题。

• 使用缓存会带来数据不一致和脏读的风险：需要合理设计失效时间和更新机制。

• 缓存雪崩现象：带缓存的业务系统，如果缓存服务崩溃，应用请求会直接打到后端的数据库服务，可能因为过载引起宕机，导致整体不可用。

• 最好能够有缓存预热机制：可用在系统启动时先把热点数据加载到缓存中，避免通过用户请求来逐步更新数据。

• 缓存穿透：如果不恰当的业务、或者恶意攻击持续高并发的请求某个不存在的数据，因为缓存没有保存该数据，所有的请求都会落到数据库上，会对数据库造成很大的压力，甚至崩溃。一个简单的对策是将不存在的数据也缓存起来（其 value 值为 null），并设定一个较短的失效时间。



9. Redis vs. Memcached



9.1 Redis



Redis 支持复杂的数据结构

Redis 支持多路复用异步 I/O 高性能

Redis 支持主从复制高可用

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



Redis 集群





消息队列与异步结构



1. 消息队列和异步结构



通过队列，可用实现异步调用





调用时，增加callback，可用实现返回结果的回调处理。





2. 消息队列的好处



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

• 更好的伸缩性

• 削峰填谷

• 失败隔离和自我修复

• 解耦



3. 事件驱动架构EDA



典型应用场景如下：





4.主要MQ产品比较



• RabbitMQ 的主要特点是性能好，社区活跃，但是 RabbitMQ 用 Erlang 开发，对不熟悉 Erlang 的同学而言不便于二次开发和维护。（49M）

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

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

• Kafka ，LinkedIn 出品的，Scala 开发，专门针对分布式场景进行了优化，因此分布式的伸缩性会比较好。（63M）



按stars数量来选用即可。



负载均衡架构



1. 定义



负载均衡是一种软件和算法，将请求转发到后端多个服务器上，避免出现单点过载。





包括有：



• HTTP重定向负载均衡

• DNS负载均衡

• 反向代理负载均衡

• IP负载均衡

• 数据链路层负载均衡



2. 负载均衡算法



• 轮询：所有请求被依次分发到每个应用服务器上，适合于所有服务器硬件都相同的场景。

• 加权轮询：根据应用服务器硬件性能的情况，在轮询的基础上，按照配置的权重将请求分发到每个服务器，高性能的服务器分配更多请求。

• 随机：请求被随机分配到各个应用服务器，在许多场合下，这种方案都很简单实用，因为好的随机数本身就很均衡。如果应用服务器硬件配置不同，也可以很容易的使用加权随机算法。

• 最少连接：记录每个应用服务器正在处理的连接数（请求数），将新到的请求分发到最少连接的服务器上，应该说，这是最符合负载均衡定义的算法。

• 源地址散列：根据请求来源的IP地址进行Hash计算，得到应用服务器，该算法可以保证同一个来源的请求总在同一个服务器上处理，实现会话粘滞。



3. Session管理