架构师训练营 -W05S- 技术选型

发布于: 2020 年 07 月 08 日

分布式缓存架构

  • 缓存(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主主复制

  • 增加写的高可用

  • 注意事项

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

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

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



用户头像

BlazeLuLu

关注

还未添加个人签名 2018.05.30 加入

还未添加个人简介

评论

发布
暂无评论
架构师训练营-W05S-技术选型