伸缩性

对于热点业务或数据 当现有资源明显不足以应对可预期的流量需求 则需要进行伸缩

热点数据

行为热点 -> 链路热点 -> 数据热点 -> 热点压力 -> 达到瓶颈限制 -> 系统崩溃

热点很容易造成整个缓存击穿 进而导致击穿到数据库 所以需要将热点数据进行隔离 避免发生故障时故障扩散

热点预测

热点发现

日志监控 -> 聚合分析 -> 发布热点数据事件

热点预案

发现热点数据后，对相应组件进行扩容增配，但也要做好限流保护，避免被冲垮

在热点预测后，可以先进行缓存预热，另外一个就是对非热点降级，将资源分配大部给热点

热点逻辑

功能防御：在热点冲击的情况下，为了提高整体性能，某些逻辑不采取常用做法，而是通过异步、消息通知等方式来进行

热点分散

发现热点key

在架构设计中，为了实现热点分散这个目的，各个组件间需要做好隔离，通过全链路压测来探索热点的极限及范围等，通过统计与分散治理，并通过压测验证优化的正确性

无状态应用

负载均衡

算法

每个请求轮流发送到每个服务器上 该算法笔记适合每个服务器性能差不多的场景

在轮询的基础上，根据服务器的性能差异，为服务器赋予一定的权值，性能高的服务器分配更高的权值 权值更高的服务器接收更多的请求

将请求发送给当前最少连接数的服务器上

根据服务器的性能为每台服务器分配权重，再根据权重计算出每台服务器能处理的连接数

把请求随机发送到服务器上

通过对客户端 IP 计算哈希值之后，再对服务器数量取模得到目标服务器的序号 这样就可以保证同一ip的客户的请求都会转发到同一台服务器，这个算法可以解决分布式session问题

转发实现

HTTP重定向

负载均衡服务器使用某种负载均衡算法计算得到服务器的 IP 地址之后，将该地址写入 HTTP 重定向报文中，状态码为 302。客户端收到重定向报文之后，需要重新向服务器发起请求

这样客户端需要两次请求，性能会受到一定影响

2020317145131

DNS域名解析

DNS 解析域名的同时使用负载均衡算法计算服务器 IP 地址

优点是可以返回离用户地理位置更近的服务器 缺点是DNS具有多级结构，DNS解析结果可能被各级缓存，修改DNS记录后，需要比较长的时间才能生效

大型网站基本使用了 DNS 做为第一级负载均衡手段，然后在内部使用其它方式做第二级负载均衡

2020317145357

反向代理服务器

位于源服务器前面，用户的请求需要先经过反向代理服务器才能到达源服务器

反向代理服务器可能会成为性能瓶颈

这种方式对于其它类型层的转发优点是可以得到更为详细的数据包信息

nginx之类的代理服务器是工作在应用层上的，网络层上的反向代理可以直接修改数据包目的IP地址，进行转发，但在服务器的响应还是需要经过负载均衡器

在链路层根据负载均衡算法计算源服务器的 MAC 地址，并修改请求数据包的目的 MAC 地址，并进行转发

通过配置源服务器的虚拟 IP 地址和负载均衡服务器的 IP 地址一致，源服务器的响应可以直接发送给客户端，不用经过负载均衡器

有状态应用

session管理

Sticky Session

配置负载均衡器，使得一个用户的所有请求都路由到同一个服务器，这样就可以把用户的 Session 存放在该服务器中 当该节点宕机后，该节点的所有会话数据都将丢失

202031715046

Session Replication

在服务器之间进行 Session 同步操作，每个服务器都有所有用户的 Session 信息

内存占用过多，且同步过程会影响性能

202031715143

Session Server

使用一个单独的服务器存储 Session 数据，如可以使用mysql或者redis来实现

这可以使应用服务器保持无状态，但缺点是需要对session存取代码进行改造

202031715310

消息解耦

对于长任务、非实时、基于发布订阅多下游同语义的业务场景，使用消息组件来不仅可以对各业务方进行解耦有利于各业务方独立伸缩，并且可以有效利用消息组件的可靠性

性能规划

性能指标

RT与吞吐量是正相关的，RT越短、吞吐量越高

业务性能优化

性能基线

时刻关注拐点 确保集成新功能后系统仍能保持原来的曲线

20211024223453