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会做处理。



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

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

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



【总结】

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

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

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