week5- 作业

发布于: 3 小时前
week5-作业

【分布式缓存】

什么是缓存CACHE

CACHE 缓存 用来多次读取

BUFFER 缓冲 用来读和写

缓存无处不在,应用场景如下:

CPU 缓存

操作系统缓存

数据库缓存

JVM 编译缓存

CDN缓存

代理与反向代理缓存

前端缓存

应用程序缓存

分布式对象缓存

缓存的数据存储 (HASH表)

缓存的目的是快速读取;

HASH表的读取 O(1)

EXCDN缓存:URL 就是 KEY ,图片就是VALUE;

在一个巨大的内存空间中存储大量的数据,如何快速查找到的呢?

KEY VALUE

HASH表的本质还是数组;

如何根据下标找到位置的呢?

(1)给出KEY

(2)根据KEY算出HASHCODE

(3)根据HASHCODE算出对应的HASH表索引

(4)根据索引找到内存地址(首地址+偏移量)

缓存的关键项

缓存的命中率

缓存的键值越少命中率就越高

缓存使用的都是内存大小,缓存的数据对象越多,命中率就越高。

缓存的失效时间,TTL

代理缓存、反向代理缓存

内部服务之间也可以使用代理服务器,

RESTFUL 风格,就方便使用URL 做KEY ,做反向代理

旁路缓冲

对象缓存是一种旁路缓存,

应用代理会查询缓存是否存在,如果不存在就先访问数据源来组装对象,并保存到对象缓存中。

浏览器对象缓存:

本地对象缓存:

SPRING的 单例实现,就是HASH表。

工厂也是MAP,每次取对象就是从内存中取对应的数据。

【消息队列】

同步调用和异步调用

同步调用:

客户端发起请求,service 接受请求,然后发给 远程server系统处理,等待server 处理,于是service 就IO阻塞了,等待处理结果。

问题:线程在等待,资源没被释放。

操作数据库又是个慢操作。

解决方案:异步调用

请求写入消息队列,

原来是秒级操作,现在变成了毫秒级操作,效率提高了几千倍

增加了处理结果的通知流程,

(1)有个生产者将处理结果写入消息队列;

(2)有个消费者处理返回结果的消息。

消息队列的异步调用架构:(三个角色)

消息生产者:

消息队列:

消息消费者:

主要架构模型:

(1)点对点模型:

多个生产者(同一个类型)

多个消费者,任何一个消费者都可以消费。

消息只能被处理一次;

(2)发布订阅模型:

生产者生产消息:

多个消费者可以订阅消息

多个消费者订阅就可以有自己的消息队列。

缓存:一个数据多次读取,可以通过缓存来提高效率。

缓存只能处理读的场景,不能处理写的场景。

写不要使用缓存,缓存不要用来写数据。

写的时候如何提升性能,就是使用消息队列。

缓存:提高读效率;

消息队列:提高写效率;

(MQ 常用的就是RocketMQ 和 KAFKA )

数据的存储是异步完成的。

用户大并发访问数据库会对数据库造成巨大的压力。

但是写消息队列可以高并发的写入。

然后消息队列再缓慢的写入数据库,以数据库可以承受的压力来写入数据库。

所以对应的订单处理就有延迟。

消息队列的好处:

(1)更好的伸缩性:

(2)削峰填谷:降低业务高峰时的系统压力;

(3)失败隔离和自我修复:重启或修复消费者,不会影响生产者接受前端的请求,生产消息。

(4)解耦:生产者和消费者解耦,互相感知不到对方。

【负载均衡】

应用服务器是无状态的:每次请求都是新的,不需要上下文。

负载均衡服务器怎么把请求发给应用服务器。

HTTP重定向负载均衡服务器

缺点:

(1)两次请求,对网络流量影响较大。

(2)暴露了应用服务器的公网IP地址;

DNS负载均衡

大家可以买个域名,可以本地缓存,节省网络带宽。

不同的时段不同的地区 ping 百度 返回的地址不同,说明使用了DNS负载均衡。

HTTP反向代理负载均衡:(7层负载均衡)

反向代理服务器收到请求,然后向后面的服务器发送HTTP请求。

反向代理后面的服务器如果多了(几十台以上)并不适合。

为什么?

因为HTTP的包比较大,比较重。

反向代理的服务器会成为瓶颈。

TCP是小包,几K字节;

HTTP是大包,有的是几M;

小规模的情况下,可以使用反向代理负载均衡。

如果集群规模很大,如果几万台,就不能使用反向代理负载均衡了。

所以,就需要在第三层去做负载均衡了

IP负载均衡 (3层负载均衡)

就是修改目标地址为实际应用服务器的地址

缺点:所有的请求都还是走负载均衡的服务器,网卡的出口带宽会成为瓶颈。

千兆网卡 发送1M的图片,每秒可以发送125张图片( 1000Mbit/8bit=125)

(因为改了IP地址,所以必须要从负载均衡服务器出口)

数据链路层负载均衡(2层负载均衡)

不修改服务器IP地址,设置不同的MAC地址。

负载均衡的IP 和 应用服务器的IP 地址保持一样,不变。

因为IP地址没有被修改,所以,可以由应用服务器直接返回给请求方服务器。

因为IP没有改变所以不影响IP的协议交互。

(大型的网站常用的负载均衡方案,也叫三角模式,走了个三角形)

维基百科的LVS ,出现了两次。

LVS就是负载均衡,可支持 IP负载均衡和数据链路层负载均衡。

目前LINUX 最新版本已经集成了LVS ,可以配置LVS。

负载均衡有两个意思:

负载均衡的算法;

怎么把请求分发过去;

架构师需要知道负载均衡的模式,如果业务量大了,可能需要知道可能是负载均衡有瓶颈。

负载均衡的算法

轮询

加权轮询

随机

最少链接

源地址散列

SESSION复制(已被淘汰)

任何应用服务器的SESSION修改,需要复制给其它应用服务器。

如果服务器数量多了,那么每次都要同步,对网络压力大。

所以SESSION复制已经被淘汰了。

SESSION绑定(也不行)

没有高可用,不能滚动升级,单点故障;

Cookie记录Session

在cookie中记录session

缺点:

网络开销大

有些客户端禁用了COOKIE

Session服务器

使用redis或数据库专门管理session信息

共享session服务器

【MYSQL 复制】

MYSQL是如何做主从复制的?

主服务器更新本地数据库,同步写binlog;

从服务器获取binlog,写入RelayLog ,SQL执行写入本地数据库。

通常DDL不同步到从服务器

如果DDL在从服务器执行,通常要很长时间,导致后续数据再等待,主从数据很长时间不一致,程序会异常。

那怎么办?如果主要加个字段,从又不能执行,怎么办?

程序先不要访问数据库对应表,再处理DDL。

MYSQL 一主多从复制

主写,从读

有的从给应用程序读

有的从给统计程序读;

优点:

分摊负载

专机专用

便于冷备

高可用

MYSQL 主主复制

当一个服务器挂了,另一个服务器可以高可用

实际不能两台服务器同时写,会导致数据冲突。

当一台服务器宕机就把写操作切换到另一台服务器。

已经被同步的BINLOG 不会再次被同步到另一台服务器,MYSQL会做处理。

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

复制只是增加了数据的并发处理能力,没有增加写并并发能力和存储能力

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

【总结】

每一种技术本身就是一种架构方案,思考架构同时,需要知道关键点。

不要局限于技术本身,要理解掌握技术背后的思想,以便于举一反三,思考架构的方法和思路。

要在日常的技术问题中引入架构的思想来解决问题。

用户头像

蒜泥精英

关注

还未添加个人签名 2018.09.19 加入

还未添加个人简介

评论

发布
暂无评论
week5-作业