业务请求的处理方法、装置与流程

1.本发明涉及直播事故处理领域，尤其涉及一种业务请求的处理方法、装置、电子设备和计算机可读存储介质。


背景技术：

2.在直播晚高峰的时候，系统经常会因为压力过于集中，并发过大，而底层的系统或部分旁路依赖系统无法承受产生雪崩效应，因此在系统的入口网关处利用redis增加并发统计，每接收一个请求并发数就累积 1，当请求处理完之后就在后置中间件将并发数-1，如果有请求超5s没处理完毕默认失效防止请求卡死现象，然后再给请求路由设置熔断规则，每个路由可承受的并发是多少，当统计的并发数达到改请求设置的阈值时，就不再接收转发改请求，直接在入口网关进行拦截返回，减少系统的并发压力，保障核心功能的处理。
3.由此可见，相关技术中存在以下不足：1：统计的并发是全局的，会熔断某些原本性能比较高的业务功能；2：redis单机统计压力过大。
4.针对相关技术中，直播事故预防及处理方式比较粗略的问题，尚未提出有效地解决方案。


技术实现要素：

5.本发明实施例提供了一种业务请求的处理方法、装置、电子设备和计算机可读存储介质，以至少解决相关技术中直播事故预防及处理方式比较粗略的技术问题。
6.根据本发明实施例的一个方面，提供了一种业务请求的处理方法，包括：分别计算出每个业务请求所对应的每秒查询率qps；根据所述每个业务请求所对应的qps，使用令牌桶算法对所述每个业务请求分别设置令牌桶的数量，其中，所述令牌桶用于对所述业务请求进行控制；在接收到业务请求后，设置所述业务请求从所述令牌桶中获取令牌；在所述业务请求获取到所述令牌的情况下，对所述业务请求进行处理。
7.可选地，所述方法还包括：在对所述业务请求进行处理之后，实时获取所述令牌桶的业务请求处理能力，其中，所述业务请求处理能力包括所述令牌桶每秒处理的业务请求数大于第一预设阈值；根据所述令牌桶的业务请求处理能力，使用预设规则补充所述令牌桶的数量，其中，所述预设规则包括毫秒级别的补充规则。
8.可选地，获取所述每个业务请求的请求阈值；在所述业务请求的请求数大于所述请求阈值时，在控制面板上单独对所述业务请求进行控制。
9.可选地，所述方法还包括：在系统的入口网关处，使用redis集群对所述业务请求进行统计。
10.可选地，所述方法还包括：判断所述令牌桶中剩余令牌的数量是否低于第二预设阈值；在判断结果为是的情况下，获取所述业务请求的优先级；根据所述业务请求的优先级，对所述业务请求进行处理。
11.根据本发明实施例的另一个方面，还提供了一种业务请求的处理装置，包括：计算
模块，用于分别计算出每个业务请求所对应的每秒查询率qps；第一设置模块，用于根据所述每个业务请求所对应的qps，使用令牌桶算法对所述每个业务请求分别设置令牌桶的数量，其中，所述令牌桶用于对所述业务请求进行控制；第二设置模块，用于在接收到业务请求后，设置所述业务请求从所述令牌桶中获取令牌；处理模块，用于在所述业务请求获取到所述令牌的情况下，对所述业务请求进行处理。
12.可选地，所述装置还包括：获取模块，用于在对所述业务请求进行处理之后，实时获取所述令牌桶的业务请求处理能力，其中，所述业务请求处理能力包括所述令牌桶每秒处理的业务请求数大于第一预设阈值；补充模块，用于根据所述令牌桶的业务请求处理能力，使用预设规则补充所述令牌桶的数量，其中，所述预设规则包括毫秒级别的补充规则。
13.可选地，所述装置还包括：所述装置还包括：统计模块，用于在系统的入口网关处，使用redis集群对所述业务请求进行统计。
14.可选地，所述装置还用于获取所述每个业务请求的请求阈值；在所述业务请求的请求数大于所述请求阈值时，在控制面板上对所述请求阈值进行调整。
15.所述装置还用于判断所述令牌桶中剩余令牌的数量是否低于第二预设阈值；在判断结果为是的情况下，获取所述业务请求的优先级；根据所述业务请求的优先级，对所述业务请求进行处理。
16.本发明实施例提供一种电子设备，包括：处理器；用于存储处理器可执行指令的存储器；其中，处理器被配置为执行上述任一项方法的步骤。
17.本发明实施例提供一种计算机可读存储介质，计算机可读存储介质上存储有指令，指令被处理器执行时实现上述任一项方法的步骤。
18.本发明实施例中，分别计算出每个业务请求所对应的每秒查询率qps；根据该每个业务请求所对应的qps，使用令牌桶算法对该每个业务请求分别设置令牌桶的数量，其中，该令牌桶用于对该业务请求进行控制；在接收到业务请求后，设置该业务请求从该令牌桶中获取令牌；在该业务请求获取到该令牌的情况下，对该业务请求进行处理。也就是说，本发明实施例弃用了原来的计数方式改用令牌桶实现，精细化控制每个业务请求的处理性能，进而解决了相关技术中直播事故预防及处理方式比较粗略的问题，达到了有效保护直播系统下层服务以及公共资源进而避免发生雪崩效应而影响整个系统功能的技术效果。
附图说明
19.此处所说明的附图用来提供对本发明的进一步理解，构成本技术的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：
20.图1为本发明实施例提供的一种业务请求的处理方法的流程示意图；
21.图2为本发明实施例提供的一种业务请求的处理装置的示意图(一)；
22.图3为本发明实施例提供的一种业务请求的处理装置的示意图(二)；
23.图4为本发明实施例提供的一种业务请求的处理装置的示意图(三)。
具体实施方式
24.为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是
本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。
25.需要说明的是，本发明的说明书和权利要求书及附图中的术语“第一”、“第二”等是用于区别不同对象，而不是用于限定特定顺序。
26.本发明实施例提供一种业务请求的处理方法，图1为本发明实施例提供的一种业务请求的处理方法的流程示意图。
27.可选地，本发明实施例的应用场景包括但并不限于：
28.场景一、用户通过直播平台查询货品详情并进行购买，由于购买人数较多，系统经常会因为压力过于集中，并发过大，而底层的系统或部分旁路依赖系统无法承受的情况下，出现卡死的情况，那么就可以使用本发明实施例提供的方法，分别计算出每个业务请求所对应的每秒查询率qps；根据该每个业务请求所对应的qps，使用令牌桶算法对该每个业务请求分别设置令牌桶的数量，其中，该令牌桶用于对该业务请求进行控制；在接收到业务请求后，设置该业务请求从该令牌桶中获取令牌；在该业务请求获取到该令牌的情况下，对该业务请求进行处理。也就是说，本发明实施例弃用了原来的计数方式改用令牌桶实现，精细化控制每个业务请求的处理性能。
29.场景二、大量用户同一时间访问某一小程序，由于访问人数较多，系统经常会因为压力过于集中，并发过大，而底层的系统或部分旁路依赖系统无法承受的情况下，出现卡死的情况，那么就可以使用本发明实施例提供的方法，分别计算出每个业务请求所对应的每秒查询率qps；根据该每个业务请求所对应的qps，使用令牌桶算法对该每个业务请求分别设置令牌桶的数量，其中，该令牌桶用于对该业务请求进行控制；在接收到业务请求后，设置该业务请求从该令牌桶中获取令牌；在该业务请求获取到该令牌的情况下，对该业务请求进行处理。也就是说，本发明实施例弃用了原来的计数方式改用令牌桶实现，精细化控制每个业务请求的处理性能。
30.如图1所示，本技术实施例提供的业务请求的处理方法包括以下步骤：
31.s102，分别计算出每个业务请求所对应的每秒查询率qps；
32.其中，qps是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。在因特网上，经常用每秒查询率来衡量域名系统服务器的机器的性能，对应fetches/sec，即每秒的响应请求数，也即最大吞吐能力，其计算关系为qps＝并发量/平均响应时间。
33.s104，根据该每个业务请求所对应的qps，使用令牌桶算法对该每个业务请求分别设置令牌桶的数量，其中，该令牌桶用于对该业务请求进行控制；
34.需要说明的是，在网络中传输数据时，为了防止网络拥塞，需限制流出网络的流量，使流量以比较均匀的速度向外发送。令牌桶算法就实现了这个功能，可控制发送到网络上数据的数目，并允许突发数据的发送。令牌桶算法是网络流量整形(traffic shaping)和速率限制(rate limiting)中最常使用的一种算法。典型情况下，令牌桶算法用来控制发送到网络上的数据的数目，并允许突发数据的发送。大小固定的令牌桶可自行以恒定的速率源源不断地产生令牌。如果令牌不被消耗，或者被消耗的速度小于产生的速度，令牌就会不断地增多，直到把桶填满，后面再产生的令牌就会从桶中溢出，最后桶中可以保存的最大令牌数永远不会超过桶的大小。传送到令牌桶的数据包需要消耗令牌。不同大小的数据包，消
耗的令牌数量不一样。令牌桶这种控制机制基于令牌桶中是否存在令牌来指示什么时候可以发送流量。令牌桶中的每一个令牌都代表一个字节。如果令牌桶中存在令牌，则允许发送流量；而如果令牌桶中不存在令牌，则不允许发送流量。因此，如果突发门限被合理地配置并且令牌桶中有足够的令牌，那么流量就可以以峰值速率发送。令牌桶算法的基本过程如下：假如用户配置的平均发送速率为r，则每隔1/r秒一个令牌被加入到桶中；假设桶最多可以存发b个令牌。如果令牌到达时令牌桶已经满了，那么这个令牌会被丢弃；当一个n个字节的数据包到达时，就从令牌桶中删除n个令牌，并且数据包被发送到网络；如果令牌桶中少于n个令牌，那么不会删除令牌，并且认为这个数据包在流量限制之外；算法允许最长b个字节的突发，但从长期运行结果看，数据包的速率被限制成常量r。对于在流量限制外的数据包可以以不同的方式处理：它们可以被丢弃；它们可以排放在队列中以便当令牌桶中累积了足够多的令牌时再传输；它们可以继续发送，但需要做特殊标记，网络过载的时候将这些特殊标记的包丢弃。
35.s106，在接收到业务请求后，设置该业务请求从该令牌桶中获取令牌；
36.s108，在该业务请求获取到该令牌的情况下，对该业务请求进行处理。
37.可选地，在本实施例中，上述对该业务请求进行处理包括但并不限于：对该业务请求进行转发、对该业务请求进行拒绝处理。
38.通过上述步骤s102～s108，分别计算出每个业务请求所对应的每秒查询率qps；根据该每个业务请求所对应的qps，使用令牌桶算法对该每个业务请求分别设置令牌桶的数量，其中，该令牌桶用于对该业务请求进行控制；在接收到业务请求后，设置该业务请求从该令牌桶中获取令牌；在该业务请求获取到该令牌的情况下，对该业务请求进行处理。也就是说，本发明实施例弃用了原来的计数方式改用令牌桶实现，精细化控制每个业务请求的处理性能，进而解决了相关技术中直播事故预防及处理方式比较粗略的问题，达到了有效保护直播系统下层服务以及公共资源进而避免发生雪崩效应而影响整个系统功能的技术效果。
39.在一个可选地实施方式中，上述方法还包括：
40.s11，在对该业务请求进行处理之后，实时获取该令牌桶的业务请求处理能力，其中，该业务请求处理能力包括该令牌桶每秒处理的业务请求数大于第一预设阈值；
41.s12，根据该令牌桶的业务请求处理能力，使用预设规则补充该令牌桶的数量，其中，该预设规则包括毫秒级别的补充规则。
42.例如，令牌桶会以每秒能够处理的请求数按毫秒级别进行补充，这种方式还能保证某个功能不会一直得不到处理，可能下一秒就能够被处理了。
43.可选地，该方法还包括：
44.s21，获取该每个业务请求的请求阈值；
45.s22，在该业务请求的请求数大于该请求阈值时，在控制面板上单独对该业务请求进行控制。
46.例如，假设业务请求1的请求阈值为5000条，业务请求2的请求阈值为10000条，当发生业务请求1的请求数为6000条，业务请求2的请求数为7000条时，由于业务请求1的请求数6000条大于业务请求1的请求阈值5000条，业务请求2的请求数7000条小于业务请求2的请求阈值10000条，那么就只需要在控制面板上单独对该业务请求1进行控制，而业务请求2
保持原有的控制方式。
47.又例如，假设业务请求1的请求阈值为5000条，业务请求2的请求阈值为10000条，当发生业务请求1的请求数为6000条、业务请求2的请求数为12000条时，由于业务请求1的请求数6000条大于业务请求1的请求阈值为5000条，业务请求2的请求数12000条大于业务请求2的请求阈值10000条，那么就需要在控制面板上对该业务请求1、业务请求2进行控制。
48.再例如，假设业务请求1的请求阈值为5000条，业务请求2的请求阈值为10000条，当发生业务请求1的请求数为4000条，业务请求2的请求数为7000条时，由于业务请求1的请求数4000条小于业务请求1的请求阈值5000条，业务请求2的请求数7000条小于业务请求2的请求阈值10000条，那么业务请求1、业务请求2保持原有的控制方式。
49.通过上述s21～22，可用于紧急处理手段，当某个服务压力承受突然发生变化没有预知的情况下，可在控制面板上单独对某个业务请求进行控制，以防发生雪崩的现象。
50.可选地，上述方法还包括：
51.s31，在系统的入口网关处，使用redis集群对所述业务请求进行统计。
52.其中，单机redis统计的主要原理为每接收一个请求并发数就累积 1，当请求处理完之后就在后置中间件将并发数-1，如果有请求超5s没处理完毕默认失效防止请求卡死现象；然后再给请求路由设置熔断规则，每个路由可承受的并发是多少，当统计的并发数达到改请求设置的阈值时，就不再接收转发改请求，直接在入口网关进行拦截返回，减少系统的并发压力，保障核心功能的处理。
53.redis集群采用去中心化的思想，没有中心节点的说法，对于客户端来说，整个集群可以看成一个整体，可以连接任意一个节点进行操作，就像操作单一redis实例一样，不需要任何代理中间件，当客户端操作的key没有分配到该node上时，redis会返回转向指令，指向正确的node。redis也内置了高可用机制，支持n个master节点，每个master节点都可以挂载多个slave节点，当master节点挂掉时，集群会提升它的某个slave节点作为新的master节点。
54.在redis集群中，所有的redis节点彼此互联，节点内部使用二进制协议优化传输速度和带宽。当一个节点挂掉后，集群中超过半数的节点检测失效时才认为该节点已失效。不同于tomcat集群需要使用反向代理服务器，redis集群中的任意节点都可以直接和java客户端连接。redis集群上的数据分配则是采用哈希槽(hash slot)，redis集群中内置了16384个哈希槽，当有数据需要存储时，redis会首先使用crc16算法对key进行计算，将计算获得的结果对16384取余，这样每一个key都会对应一个取值在0～16383之间的哈希槽，redis则根据这个余数将该条数据存储到对应的redis节点上，开发者可以根据每个redis实例的性能来调整每个redis实力上哈希槽的分布范围。
55.其主要分为主从模式、sentinel模式、cluster模式。其中，关于主从模式：当slave启动后，主动向master发送sync命令。master接收到sync命令后在后台保存快照(rdb持久化)和缓存保存快照这段时间的命令，然后将保存的快照文件和缓存的命令发送给slave。slave接收到快照文件和命令后加载快照文件和缓存的执行命令。复制初始化后，master每次接收到的命令都会同步发送给slave，保证主从数据的一致性。
56.关于sentinel模式：每个sentinel以每秒钟一次的频率向它所知的master，slave以及其他sentinel实例发送一个ping命令。如果一个实例距离最后一次有效回复ping命令
per second，简称为qps)，利用令牌桶算法对每个业务请求设置初始化可处理的请求数，精细到可单独根据某个业务处理性能进行请求控制；根据对每个业务请求的压测性能结果，在服务启动的时候给每个业务请求设置初始的令牌桶数量，每来一个业务请求都需要去令牌桶中获取令牌，只有获取到令牌了才能接收转发该业务请求，同时令牌桶会以每秒能够处理的业务请求数按毫秒级别进行补充，这种方式还能保证某个功能不会一直得不到处理，可能下一秒就能够被处理了；同时每个业务请求的阈值规则设置可在控制面板上进行动态调整，可用于紧急处理手段，当某个服务压力承受突然发生变化没有预知的情况下，可在控制面板上单独对某个请求进行控制，以防发生雪崩的现象。
71.通过本示例，为保护下层服务以及公共资源避免发生雪崩效应而影响这个系统的功能，同时在这原则之上最大程度让所有功能可用，最差情况下也能保证核心功能可用，对比现有技术更精细化的设置规则以及单独控制请求处理的数量，同样也还是利用redis技术来实现，采用集群版的进行压力分散。即，弃用原来的计数方式改用令牌桶实现，精细化控制每个请求的处理性能，同时将单机改成集群的redis，分散redis压力提升系统整体的处理能力。
72.本发明实施例还提供了一种业务请求的处理装置，图2为本发明实施例提供的一种业务请求的处理装置的示意图。
73.场景一、用户通过直播平台查询货品详情并进行购买，由于购买人数较多，系统经常会因为压力过于集中，并发过大，而底层的系统或部分旁路依赖系统无法承受的情况下，出现卡死的情况，那么就可以使用本发明实施例提供的方法，分别计算出每个业务请求所对应的每秒查询率qps；根据该每个业务请求所对应的qps，使用令牌桶算法对该每个业务请求分别设置令牌桶的数量，其中，该令牌桶用于对该业务请求进行控制；在接收到业务请求后，设置该业务请求从该令牌桶中获取令牌；在该业务请求获取到该令牌的情况下，对该业务请求进行处理。也就是说，本发明实施例弃用了原来的计数方式改用令牌桶实现，精细化控制每个业务请求的处理性能。
74.场景二、大量用户同一时间访问某一小程序，由于访问人数较多，系统经常会因为压力过于集中，并发过大，而底层的系统或部分旁路依赖系统无法承受的情况下，出现卡死的情况，那么就可以使用本发明实施例提供的方法，分别计算出每个业务请求所对应的每秒查询率qps；根据该每个业务请求所对应的qps，使用令牌桶算法对该每个业务请求分别设置令牌桶的数量，其中，该令牌桶用于对该业务请求进行控制；在接收到业务请求后，设置该业务请求从该令牌桶中获取令牌；在该业务请求获取到该令牌的情况下，对该业务请求进行处理。也就是说，本发明实施例弃用了原来的计数方式改用令牌桶实现，精细化控制每个业务请求的处理性能。
75.如图2所示，本技术实施例提供的业务请求的处理装置包括：
76.计算模块22，用于分别计算出每个业务请求所对应的每秒查询率qps；
77.其中，qps是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。在因特网上，经常用每秒查询率来衡量域名系统服务器的机器的性能，对应fetches/sec，即每秒的响应请求数，也即最大吞吐能力，其计算关系为qps＝并发量/平均响应时间。
78.第一设置模块24，用于根据该每个业务请求所对应的qps，使用令牌桶算法对该每个业务请求分别设置令牌桶的数量，其中，该令牌桶用于对该业务请求进行控制；
79.需要说明的是，在网络中传输数据时，为了防止网络拥塞，需限制流出网络的流量，使流量以比较均匀的速度向外发送。令牌桶算法就实现了这个功能，可控制发送到网络上数据的数目，并允许突发数据的发送。令牌桶算法是网络流量整形(traffic shaping)和速率限制(rate limiting)中最常使用的一种算法。典型情况下，令牌桶算法用来控制发送到网络上的数据的数目，并允许突发数据的发送。大小固定的令牌桶可自行以恒定的速率源源不断地产生令牌。如果令牌不被消耗，或者被消耗的速度小于产生的速度，令牌就会不断地增多，直到把桶填满，后面再产生的令牌就会从桶中溢出，最后桶中可以保存的最大令牌数永远不会超过桶的大小。传送到令牌桶的数据包需要消耗令牌。不同大小的数据包，消耗的令牌数量不一样。令牌桶这种控制机制基于令牌桶中是否存在令牌来指示什么时候可以发送流量。令牌桶中的每一个令牌都代表一个字节。如果令牌桶中存在令牌，则允许发送流量；而如果令牌桶中不存在令牌，则不允许发送流量。因此，如果突发门限被合理地配置并且令牌桶中有足够的令牌，那么流量就可以以峰值速率发送。令牌桶算法的基本过程如下：假如用户配置的平均发送速率为r，则每隔1/r秒一个令牌被加入到桶中；假设桶最多可以存发b个令牌。如果令牌到达时令牌桶已经满了，那么这个令牌会被丢弃；当一个n个字节的数据包到达时，就从令牌桶中删除n个令牌，并且数据包被发送到网络；如果令牌桶中少于n个令牌，那么不会删除令牌，并且认为这个数据包在流量限制之外；算法允许最长b个字节的突发，但从长期运行结果看，数据包的速率被限制成常量r。对于在流量限制外的数据包可以以不同的方式处理：它们可以被丢弃；它们可以排放在队列中以便当令牌桶中累积了足够多的令牌时再传输；它们可以继续发送，但需要做特殊标记，网络过载的时候将这些特殊标记的包丢弃。
80.第二设置模块26，用于在接收到业务请求后，设置该业务请求从该令牌桶中获取令牌；
81.处理模块28，用于在该业务请求获取到该令牌的情况下，对该业务请求进行处理。
82.可选地，在本实施例中，上述对该业务请求进行处理包括但并不限于：对该业务请求进行转发、对该业务请求进行拒绝处理。
83.通过图2所示装置，分别计算出每个业务请求所对应的每秒查询率qps；根据该每个业务请求所对应的qps，使用令牌桶算法对该每个业务请求分别设置令牌桶的数量，其中，该令牌桶用于对该业务请求进行控制；在接收到业务请求后，设置该业务请求从该令牌桶中获取令牌；在该业务请求获取到该令牌的情况下，对该业务请求进行处理。也就是说，本发明实施例弃用了原来的计数方式改用令牌桶实现，精细化控制每个业务请求的处理性能，进而解决了相关技术中直播事故预防及处理方式比较粗略的问题，达到了有效保护直播系统下层服务以及公共资源进而避免发生雪崩效应而影响整个系统功能的技术效果。
84.可选地，如图3所示，上述装置还包括：
85.获取模块32，用于在对该业务请求进行处理之后，实时获取该令牌桶的业务请求处理能力，其中，该业务请求处理能力包括该令牌桶每秒处理的业务请求数大于第一预设阈值；
86.补充模块34，用于根据该令牌桶的业务请求处理能力，使用预设规则补充该令牌桶的数量，其中，该预设规则包括毫秒级别的补充规则。
87.例如，令牌桶会以每秒能够处理的请求数按毫秒级别进行补充，这种方式还能保
证某个功能不会一直得不到处理，可能下一秒就能够被处理了。
88.可选地，如图4所示，上述装置还包括：
89.统计模块42，用于在系统的入口网关处，使用redis集群对该业务请求进行统计。
90.其中，单机redis统计的主要原理为每接收一个请求并发数就累积 1，当请求处理完之后就在后置中间件将并发数-1，如果有请求超5s没处理完毕默认失效防止请求卡死现象；然后再给请求路由设置熔断规则，每个路由可承受的并发是多少，当统计的并发数达到改请求设置的阈值时，就不再接收转发改请求，直接在入口网关进行拦截返回，减少系统的并发压力，保障核心功能的处理。
91.redis集群采用去中心化的思想，没有中心节点的说法，对于客户端来说，整个集群可以看成一个整体，可以连接任意一个节点进行操作，就像操作单一redis实例一样，不需要任何代理中间件，当客户端操作的key没有分配到该node上时，redis会返回转向指令，指向正确的node。redis也内置了高可用机制，支持n个master节点，每个master节点都可以挂载多个slave节点，当master节点挂掉时，集群会提升它的某个slave节点作为新的master节点。
92.在redis集群中，所有的redis节点彼此互联，节点内部使用二进制协议优化传输速度和带宽。当一个节点挂掉后，集群中超过半数的节点检测失效时才认为该节点已失效。不同于tomcat集群需要使用反向代理服务器，redis集群中的任意节点都可以直接和java客户端连接。redis集群上的数据分配则是采用哈希槽(hash slot)，redis集群中内置了16384个哈希槽，当有数据需要存储时，redis会首先使用crc16算法对key进行计算，将计算获得的结果对16384取余，这样每一个key都会对应一个取值在0～16383之间的哈希槽，redis则根据这个余数将该条数据存储到对应的redis节点上，开发者可以根据每个redis实例的性能来调整每个redis实力上哈希槽的分布范围。
93.其主要分为主从模式、sentinel模式、cluster模式。其中，关于主从模式：当slave启动后，主动向master发送sync命令。master接收到sync命令后在后台保存快照(rdb持久化)和缓存保存快照这段时间的命令，然后将保存的快照文件和缓存的命令发送给slave。slave接收到快照文件和命令后加载快照文件和缓存的执行命令。复制初始化后，master每次接收到的命令都会同步发送给slave，保证主从数据的一致性。
94.关于sentinel模式：每个sentinel以每秒钟一次的频率向它所知的master，slave以及其他sentinel实例发送一个ping命令。如果一个实例距离最后一次有效回复ping命令的时间超过own-after-milliseconds选项所指定的值，则这个实例会被sentinel标记为主观下线。如果一个master被标记为主观下线，则正在监视这个master的所有sentinel要以每秒一次的频率确认master的确进入了主观下线状态。当有足够数量的sentinel(大于等于配置文件指定的值)在指定范围内确认master的确进入了主观下线状态，则master会被标记为客观下线。在一般情况下，每个sentinel会以每10秒一次的频率向它已知的所有master，slave发送info命令。当master被sentinel标记为客观下线时，sentinel向下线的master的所有slave发送info命令的频率从10秒一次改为1秒一次。若没有足够数量的sentinel统一master已经下线，master的客观下线状态就会被移除，若master重新向sentinel的ping命令返回有效恢复，master的主观下线状态就会被移除。当使用sentinel模式的时候，客户端就不要直接连接redis，而是连接sentinel的ip和port，由sentinel来
提供具体的可提供服务的redis实现。
95.关于cluster模式：cluster可以说是sentinel和主从模式的结合体，通过cluster可以实现主从和master重选功能，所以如果配置两个副本三个分片的话，就需要六个redis实例。因为redis的数据是根据一定规则分配到cluster的不同机器的，当数据量过大时，可以新增机器进行扩容。
96.可选地，在本实施例中，上述redis集群所包括的redis数量可根据业务压力确定。上述redis集群进行统计时，可将业务请求进行平均分配，也可以根据一定的比例进行分配。
97.例如，在系统的入口网关处利用10个redis进行统计，该10个redis在统计时，可将业务请求分成10份，分别由对应的redis进行统计。
98.再例如，在系统的入口网关处利用2个redis进行统计，该2个redis在统计时，将业务请求的80％分给redis1进行统计，将业务请求的20％分给redis2进行统计。
99.通过上述装置，将单机redis改成集群的redis，分散redis压力提升系统整体的处理能力。
100.可选地，该装置还用于获取该每个业务请求的请求阈值；在该业务请求的请求数大于该请求阈值时，在控制面板上对该请求阈值进行调整。
101.例如，假设业务请求1的请求阈值为5000条，业务请求2的请求阈值为10000条，当发生业务请求1的请求数为6000条，业务请求2的请求数为7000条时，由于业务请求1的请求数6000条大于业务请求1的请求阈值5000条，业务请求2的请求数7000条小于业务请求2的请求阈值10000条，那么就只需要在控制面板上单独对该业务请求1进行控制，而业务请求2保持原有的控制方式。
102.又例如，假设业务请求1的请求阈值为5000条，业务请求2的请求阈值为10000条，当发生业务请求1的请求数为6000条、业务请求2的请求数为12000条时，由于业务请求1的请求数6000条大于业务请求1的请求阈值为5000条，业务请求2的请求数12000条大于业务请求2的请求阈值10000条，那么就需要在控制面板上对该业务请求1、业务请求2进行控制。
103.再例如，假设业务请求1的请求阈值为5000条，业务请求2的请求阈值为10000条，当发生业务请求1的请求数为4000条，业务请求2的请求数为7000条时，由于业务请求1的请求数4000条小于业务请求1的请求阈值5000条，业务请求2的请求数7000条小于业务请求2的请求阈值10000条，那么业务请求1、业务请求2保持原有的控制方式。
104.通过上述装置，可用于紧急处理手段，当某个服务压力承受突然发生变化没有预知的情况下，可在控制面板上单独对某个业务请求进行控制，以防发生雪崩的现象。
105.在一个可选地实施方式中，上述装置还用于判断该令牌桶中剩余令牌的数量是否低于第二预设阈值；在判断结果为是的情况下，获取该业务请求的优先级；根据该业务请求的优先级，对该业务请求进行处理。
106.可选地，上述第二预设阈值的取值可根据系统对业务请求被处理的速度确定，在业务请求被处理的速度要求较高时，设置该第二预设阈值的数值比较大，在业务请求被处理的速度要求较低时，设置该第二预设阈值的数值比较小。
107.例如，假设令牌桶中剩余令牌的数量为1000，上述第二预设阈值为1500，在这种情况下，就需要获取该业务请求的优先级，假设该业务请求的优先级为高优先级，那么就优先
对该业务请求进行处理，保证高优先级的业务请求被及时处理，假设该业务请求的优先级为低优先级，那么就对该业务请求不进行处理，保证高优先级的业务请求被及时处理。
108.通过上述装置，可以最大程度让所有功能可用，最差情况下也能保证核心功能可用。
109.本发明实施例还提供了一种电子设备，包括：处理器；用于存储处理器可执行指令的存储器；其中，处理器被配置为执行上述任一项方法的步骤。
110.本发明实施例还提供了一种计算机可读存储介质，计算机可读存储介质上存储有指令，指令被处理器执行时实现上述任一项方法的步骤。
111.以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。