分布式缓存架构

• 缓存（Cache）是介于数据访问者和数据源之间的一种高速存储，加速数据读取。

• 缓存（Cache）与缓冲（Buffer）的区别是缓存只有读操作，而缓冲是将高速设备数据缓冲到低速设备，读写都需要。

• 缓存数据存储

• Key-Value结构

• 本质是数组，下标可直接访问

• 哈希表访问过程

• 计算key的hashcode

• 通过取模计算hashcode对应的hash表索引

• 找到第对应位置读取数据

• 缓存的关键指标：缓存命中率

• 缓存键集合大小：键数量越少，缓存的命中效率越高

• 缓存可用内存空间：物理上能缓存的对象越多，缓存命中率越高

• 缓存对象生存时间：对象缓存的时间越长，缓存对象被重用的可能性越高

• 缓存的分类

• 通读缓存

• 代理缓存：代理服务器缓冲数据

• 反向代理

• 反向代理缓存

• url是key，对应的资源是value

• 多层反向代理缓存

• resful api对反向代理友好

• 内容分发网络

• CDN放在网络供应商的数据中心，距离用户距离很近

• 通过DNS解析

• CDN同时配置静态文件和动态内容

• 旁路缓存

• 浏览器对象缓存

• 本地对象缓存

• 本地对象缓存构建分布式集群

• 远程分布式对象缓存

• Memcached分布式对象缓存

• 路由选择

• 通过对key进行hash后取模选择到哪台服务器：abs(hashcode(key))%服务器数量

• 增加集群服务器数量

• 小部分数据访问不到没关系，可到数据库访问

• 加服务器尽量让尽可能少数据访问不到

• 一致性hash算法

• 构建一致性hash环，零到2的32次方减1 

• 服务器阶段取hash值（正整数），放到环上

• key的哈希值放到环上，顺时针找最近的节点

• 负载不均衡的问题

• 解决办法：基于虚拟节点的一致性Hash节点扩容

• 虚拟节点数量参考值150-200

• 集群与分布式的区别

• 分布式：多台服务器部署

• 路由选择：余数hash

• 增加服务器数量

• 一致性hash

• 虚拟节点的一致性hash

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

• 来自内存，比磁盘访问更快

• 不需要中间计算，减少CPU资源消耗

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

• 缓存可以有效提升系统性能

• 技术简单

• 性能提升显著

• 应用场景多

• 合理使用缓存

• 频繁修改的数据：数据读写比2:1以上，缓存才有意义

• 没有热点的访问：大部分数据访问不是集中在小部分数据上，缓存就没有意义，LRU算法确定热点数据

• 数据不一致与脏读

• 设置失效时间

• 数据更新通知缓存失效

• 缓存雪崩

• 缓存崩溃--数据库崩溃--网站崩溃

• 不能简单的重启缓存服务器和数据库服务器来恢复网站访问

• 缓存预热

• 提前加载热点数据

• 缓存预热后再启动应用

• 缓存穿透

• 持续高并发的恶请求不存在的数据导致数据库压力大

• 可以看成是一种攻击

• Redis VS Memcached

• Redis

• 支持复杂数据结构

• 支持多路复用异步IO高性能

• 支持主从复置高可用

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

• Redis集群

• Redis节点彼此互联

• 客户端路由选择使用余数哈希即可，不需使用一致性hash

消息队列与异步架构

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

• 点对点模式：一个消息只能消费一次

• 订阅模式：订阅topic，一个消息可被多个订阅者订阅

• 消息队列的优点

• 实现异步处理，提升处理（写操作）性能，消息队列以数据库可以承受的压力向数据库写数据

• 保护系统和数据库

• 更好的伸缩性能，伸缩单个功能的消息队列

• 削峰填谷

• 失败隔离和自我修复

• 发布者不直接依赖消费者，所以可以将消费者系统错误与生产者系统组件隔离

• 生产者和消费者互不影响

• 任意时刻可对后端服务器执行维护和发布操作

• 解耦

• 主要MQ产品

• RabbitMQ

• ActiveMQ

• RocketMQ

• Kafka

负载均衡架构

• 使用哪种负载均衡把请求发送给应用服务器

• HTTP重定向负载均衡（一般不使用）

• 性能有问题，两次http请求

• 安全有问题，暴露公网IP

• DNS负载均衡

• 性能没问题

• 安全没问题，不直接解析应用服务器，两级负载

• 反向代理负载均衡（七层负载）

• Nginx

• 性能只能满足小规模集群使用，反代服务器会成为瓶颈

• IP负载均衡（三层负载）

• 性能：网络出口带宽会成为瓶颈

• 数据链路层负载均衡（二层负载、负载均衡的三角模式）

• 负载均衡服务器修改目的mac地址，不修改IP地址，数据包直接由应用服务器返回给用户

• 大型互联网应用使用的方案

• 负载均衡该选择哪个应该服务器

• 应用服务器无状态

• 负载均衡的算法

• 轮询：依次分发

• 加权轮询：加权重，好的多，差的少

• 随机

• 加权随机

• 最少连接：需记录应用服务器的处理连接数

• 原地址散列

• 根据请求来源的IP地址进行Hash计算，得到应用服务器

• 同一来源的请求总在同一个服务器处理，实现会话粘滞

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

• 应用服务器无状态，不管理Session

• 解决方法

• Session复制

• 应用服务器之间互相同步Session

• 被淘汰的方案，集群规模受限制

• 网络压力大

• 负载本身就是为了解决请求多的问题

• Session绑定

• 根据请求来源的IP地址进行Hash计算，同一来源的请求总在同一个服务器处理

• 方案并不可行

• 应用迭代问题

• 伸缩问题

• 故障问题

• 利用Cookie记录Session

• Cookie中记录绘话Session

• 缺点

• 对网络开销大

• 不能禁用Cookie

• 现在用的少

• Session服务器

• 共享Session服务器（集群）管理上下文

• 目前最常用

分布式数据库架构

• MySQL复制

• MySQL主从复制

• 写操作到主（Binlog），读操作到从（Relay Log）

• 加字段：数据库先加，应用再发布访问新加字段

• 删字段：应用先删除字段访问，数据库再删

• MySQL主多从复制

• 优点

• 分摊负载

• 专机专用

• 便于冷备、热杯

• 高可用

• 缺点

• 不能解决主服务器宕的问题

• MySQL主主复制

• 互相复制

• 不是为了双写使用，而是保证高可用，同时写会数据冲突

• MySQL主主失效恢复

• 主服务器A--多从服务器

• 不同的从服务器给不同应用使用，增加读的性能，同时高可用

• 主服务器B--多从服务器

• 主服务器AB主主复制

• 增加写的高可用

• 注意事项

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

• 复制知识增加了数据的读并发处理能力，没有增加写并发能力和存储能力

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