rabbitmq类型及请求限流方式

简单模式（Hello World）

做最简单的事情，一个生产者对应一个消费者，RabbitMQ相当于一个消息代理，负责将A的消息转发给B

应用场景： 将发送的电子邮件放到消息队列，然后邮件服务在队列中获取邮件并发送给收件人

工作队列模式（Work queues）

在多个消费者之间分配任务（竞争的消费者模式），一个生产者对应多个消费者，一般适用于执行资源密集型任务，单个消费者处理不过来，需要多个消费者进行处理

应用场景： 一个订单的处理需要10s，有多个订单可以同时放到消息队列，然后让多个消费者同时处理，这样就是并行了，而不是单个消费者的串行情况

订阅模式（Publish/Subscribe）

一次向许多消费者发送消息，一个生产者发送的消息会被多个消费者获取，也就是将消息将广播到所有的消费者中。

应用场景： 更新商品库存后需要通知多个缓存和多个数据库，这里的结构应该是：

• 一个fanout类型交换机扇出两个个消息队列，分别为缓存消息队列、数据库消息队列

• 一个缓存消息队列对应着多个缓存消费者

• 一个数据库消息队列对应着多个数据库消费者

路由模式（Routing）

有选择地（Routing key）接收消息，发送消息到交换机并且要指定路由key ，消费者将队列绑定到交换机时需要指定路由key，仅消费指定路由key的消息

应用场景： 如在商品库存中增加了1台iphone12，iphone12促销活动消费者指定routing key为iphone12，只有此促销活动会接收到消息，其它促销活动不关心也不会消费此routing key的消息

主题模式（Topics）

根据主题（Topics）来接收消息，将路由key和某模式进行匹配，此时队列需要绑定在一个模式上，#匹配一个词或多个词，*只匹配一个词。

应用场景： 同上，iphone促销活动可以接收主题为iphone的消息，如iphone12、iphone13等

交换机：

• 直连交换机（Direct exchange）： 具有路由功能的交换机，绑定到此交换机的时候需要指定一个routing_key，交换机发送消息的时候需要routing_key，会将消息发送道对应的队列

• 扇形交换机（Fanout exchange）： 广播消息到所有队列，没有任何处理，速度最快

• 主题交换机（Topic exchange）： 在直连交换机基础上增加模式匹配，也就是对routing_key进行模式匹配，*代表一个单词，#代表多个单词

• 首部交换机（Headers exchange）： 忽略routing_key，使用Headers信息（一个Hash的数据结构）进行匹配，优势在于可以有更多更灵活的匹配规则

请求限流方式：

1.固定窗口

1. 将时间划分为固定的窗口大小，例如1s
2. 在窗口时间段内，每来一个请求，对计数器加1。
3. 当计数器达到设定限制后，该窗口时间内的之后的请求都被丢弃处理。
4. 该窗口时间结束后，计数器清零，从新开始计数。

2.滑动窗口

1. 将时间划分为细粒度的区间，每个区间维持一个计数器，每进入一个请求则将计数器加一。
2. 多个区间组成一个时间窗口，每流逝一个区间时间后，则抛弃最老的一个区间，纳入新区间。
3. 若当前窗口的区间计数器总和超过设定的限制数量，则本窗口内的后续请求都被丢弃。

        使用一个大小可变的窗口，通过控制窗口左右两端移动的方向和移动步调，来达到找出要查找子序列的目的。左右两端点一般是向前滑动，可以是右端固定时，左端向前滑动；或者左端固定时，右端向前滑动。

        滑动窗口法，可以用来解决一些查找满足一定条件的连续区间的性质的问题。由于区间连续，因此当区间发生变化时，可以通过旧有的计算结果对搜索空间进行剪枝，这样便减少了重复计算，降低了时间复杂度。

3.令牌桶算法

1，令牌按固定速率发放，生成的令牌放入令牌桶中。

2，令牌桶有容量限制，当桶满时，新生成的令牌会被丢弃。

3，请求到来时，先从令牌桶中获取令牌，如果取得，则执行请求；如果令牌桶为空，则丢弃该请求。
令牌桶算法可以把请求平均分散在时间段内，是使用较为广发的限流算法。

redisson限流器：

        基于Redis的分布式限流器RateLimiter可以用来在分布式环境下现在请求方的调用频率。既适用于不同Redisson实例下的多线程限流，也适用于相同Redisson实例下的多线程限流。

        RateLimter主要作用就是可以限制调用接口的次数。主要原理就是调用接口之前，需要拥有指定个令牌。限流器每秒会产生X个令牌放入令牌桶，调用接口需要去令牌桶里面拿令牌。如果令牌被其它请求拿完了，那么自然而然，当前请求就调用不到指定的接口。

        主要使用业务场景：（1）单机或分布式情况下的缓存击穿（2）接口需要限制调用次数

4.漏桶算法

1，每个请求看作“水滴” 一样，放入漏桶中暂存。
2，漏桶以固定的速率，漏出请求来执行；如果漏桶空了，则停止漏水。3，如果漏桶满了，则新来的请求会被丢弃。
很明显，漏桶算法在实现的数据结构会选择有容量限制的队列，请求执行者定期定点从队列取出请求来执行，新来的请求会被暂存在队列中或者被丢弃。

漏桶算法的缺点是，不论当前系统的负载压力如何，所有请求都得进行排队，即便此时服务器负载处于低位。

• 令牌桶算法，桶里装的是令牌。每次能拿取到令牌，就可以进行访问。并且，令牌会按照速率不断恢复放到令牌桶中直到桶满。
• 漏桶算法，桶里装的是请求。当桶满了，请求就进不来。例如说，Hystrix 使用线程池或者 Semaphore 信号量，只有在请求未满的时候，才可以进行执行。