限流笔记-通道限流（二）

在工作中的时候，由于我负责的一个系统需要调用很多的第3方的系统，可是呢，这些个第3方的系统的性能完全不一致，有的好有的坏，还成本都不一样，当然了平时把，直接使用成本低的就行了，但是如果高并发的请求来的时候，系统就有问题了，一开始我们的方案时，系统部NOC实时监控，如果发现量起来了，我们就手动的切换通道，大多数问题还是能够解决，但是有时候的业务峰值一来，我们不知道，就抓瞎了，系统就会一台一台的挂，然后呢，我们又一台一台的重启。影响了业务运作，还影响了我们休息，每天都处于紧张之中。

后来吧，我就想着整一个分流分发的模块来试试，设计思想：对针对银行的特定业务通道做一个优先级排序，这个优先级排序通过一个系统，独立实时计算，分流分发模块调用该优先级，设置开关阀值，高流量时的管理分流业务。

流程

可以将模块划分为：

模块

通道选择：负责选择出符合逻辑的通道；

分流：负责最后通道选择，里面包含从统计获取的优先级，所有通道当前正在处理的线程数，通道处理时间，分流阀值及逻辑；

消息：负责将执行完的信息传送到统计模块及短信或邮件通知。

前端业务已经输入了4项信息，我需要获取到当前银行比如CCB能够支持的4项的信息的所有通道：通道1，通道2，通道3，我把这个几个通道传给统计模块，统计模块根据该卡最近成功，较远成功，没有使用，较远失败，较近失败，改银行该通道成功率，平均反应时间，统计出优先级：通道2，通道1，通道3，分流模块首先选中通道2，查询通道2当前正在执行线程数，通道2最近阀值个线程平均执行时间，根据阀值判断通道可否使用，可以就走，不可以改变通道2去选中通道1，依然上面逻辑，直到有通道可用，如果通道3都不不可用了，说明通道已经饱满，不能再接受新的请求了，当前这个银行CCB这4项信息的验证在本系统无法通过，要么等待，要么直接拒绝。如果有可以通道的通道，执行了流程，需将执行结果异步传入统计模块。

1.通道选择，我使用redis一级缓存，chcache做本地缓存（这个是简单的方式，如果选择的规则比较复杂，我比较建议用规则树，加载到本地文件或者缓存和内存）。

2.消息传送使用RabbitMQ

3.通道限流有2种办法可以选择：对于性能实在是堪忧的，直接使用Semaphore，性能可以的，使用RateLimiter，也可以全部都使用Semaphore或者线程池，这个池子的大小可以是时间*TPS（通常是进行压测的值，如果通道不让压测，那么也就只能按照经验来预测一个值了）*一个倍数。

对于还多的线程，使用随机数，将线程平均的分配给每一个通道等待队列，不过这样会造成一个问题，如果关闭这个通道，那么这个通道对应的等待队列里面的线程依然是可以执行的，但是新的请求就不会选中这个通道了。

4.请求前面针对本身系统也要有限流，这个我在前面的文章有写到。

5.

具体代码稍后上传。。。