1.分布式系统为什么需要进行流量管制
- 地铁高峰期流量管制
- 五种分布式系统应对高并发、大流量的常规手段:
1.扩容
2.动静分离
3.缓存
4.服务降级
5.限流
2.限流的具体方案
2.1.常见的限流算法
令牌桶算法：令牌桶( Token Bucket)算法主要用于限制流量的平均流人速率，并且还允许出 现一定程度上的突发流量，如图 2-3 所示。基于令牌桶算法的限流场景较多，比如 Nginx 的限流模块就是一个典型的采用令牌桶算法的实现
- 令牌桶算法基本流程：
1.每秒会有 r个令牌被放人桶内，也就是说 ， 会以 llr秒的平均速率向桶中依次 放人令牌(比如每秒共放人 10 个令牌，那么每 0.1 秒放人 1 个令牌)
2.桶的容量是固定不变的，假设桶中最多只允许存放 b 个令牌，如果桶满了再 放人令牌，则溢出(新添加的令牌被丢弃)
3.当一个 n 字节的请求包到达时，将消耗 n 个令牌，然后再发送该数据包
4.若桶中的可用令牌数小于 n，则该数据包将会被执行限流处理(被抛弃或缓存)。 - 令牌桶算法流程图：
漏桶算法：
- 漏桶算法的基本流程
1.可以以任 意速率向桶中流人水滴
2.桶的容量是固定不变的，如果桶满了则 溢出(新流人的水滴被丢弃)
3.按照固定的速率从桶中流出水滴 - 漏桶算法的流程图
从本质上来说，令牌桶算法和漏桶算法都可以用于在高并发、大流量场景下对 流量实施管制，让系统的负载处于比较均衡的水位，不会因为峰值流量过大，导致 系统被击垮。但是需要注意，这两种算法的限流方向是截然相反的。令牌桶算法限 制的是流量的平均流人速率，并且可以允许出现一定程度上的突发流量，当桶中令 牌数量不足扣减时，新的请求将被执行限流处理;而漏桶算法限制的是流量的流出 速率，而不是流入速率，并且这种流出速率还是保持固定不变的，不允许像令牌桶 算法那样出现突发流量，当流人的水滴超过桶的容量时，新的请求将被执行限流 处理。
3.基于时间分片的消峰案例
3.1.活动分时段进行实现消峰
大促活动整点的波峰值流量如同 一把尖锐的刺刀，让人不寒而栗，但是如果将 整点的促销活动调整到多个时段进行(比如某一个 SKU 的库存数量为 5000，抢购时 段被分为 10 次，那么运营人员在每个时段放置的库存数量为 500 (SKU/时段)，同 一时段聚集的用户流量将会被有效分散，大家都不会火急火燎地在同一个时间点去 抢购心仪的爆款商品，这样系统的负载压力将会大大降低。在业务上做调整来对流量进行消峰，也能够收获非常好的限流效果，这便是站 在业务的角度对系统实施保护的 一个非常典型的案例。
3.2.通过答题验证实现消峰
12306购票网站
4.异步调用需求
4.1.使用 MQ 实现系统之间的解耦
- 由于 MQ 技术发展至今 已经相当成熟了，目前市面上也汇集了许多优秀的开源 MQ 产品，如 Apache 的 ActiveMQ 和 Kafka、阿里的 RocketMQ ，以及 HometQ、 RabbitMQ、 ZeroMQ 等，笔 者建议用户规模较小的网站使用遵循 JMS (Java Message Service)规范的 ActiveMQ 这种轻量级的 MQ 产品(甚至也可以使用 Redis 提供的 Publish/Subscribe 模型)，而 KafKa、 RocketMQ 等类型的 MQ 产品，天生就是为互联网场景下拥有高并发、大流 量的分布式系统量身打造的。因为在这种规模的消息体量上，我们重点需要考虑的 是 MQ 产品的吞吐量、可用性及扩展性等多个方面的问题
- 通过消息传递实现异步调用
4.2.两种消息模型
- pull拉模型，点对点：
- push推模型，发布订阅：
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
如需转载请保留出处：https://bianchenghao.cn/bian-cheng-ji-chu/96227.html