《500 kV电网中的限流器配置探讨.docx》由会员分享，可在线阅读，更多相关《500 kV电网中的限流器配置探讨.docx（6页珍藏版）》请在第壹文秘上搜索。
1、目前高压特高压电网的短路超标问题非常严重，而相应电压等级的故障限流器在实际运行中还存在一些问题，且目前的限流器方案都是基于单条线路的限流，未考虑限流器对其他线路的影响，以及在电网中如何配置限流器以充分利用限流器功能。因此研制一种500kV电压等级、损耗小、动作迅速的限流装置，并在电网层面上对其进行合理有效的配置，是解决目前5OOkV电力系统短路容量过大问题的经济、有效的方式。本文使用的50OkV交流电网限流装置可由多个40.572.5kV故障限流模块串联组成。限流模块由快速真空开关和限流电抗器并联组成，可以方便地组建500kV电压等级的限流器。500kV分布式限流器布置方案如图1所示。(a)母
2、线短路故障时FCLl线路2hFCL2FCL3线路3h- i4I_s)(b)线路出口短路故障(限流器前)线珞1 Z1Cr4FCL3线路3-Ms-FCLl线路2 H=FCL2|：1IFeiJ或路4 -W ,Z4用线2（C）线路出口短路故障（限流器后）图1不同故障情况下的分布式限流图1为某500kV变电站简化模型，与其他变电站有4条线路相连。变电站双母线运行，Bl、B2、B3、B4为50OkV母联断路器。11、12、13、14为线路电流，If为故障点电流。如图1所示，分布式限流方案中，在每条线路出口处配置限流器（FCLIFCL4）发生不同故障时，限流模块的动作模式如下：A）母线短路故障（如图1（a）
3、所示）。动作模式：所有线路上的限流器都动作,分别限制各自线路上的短路电流，使得最终需要开断的总短路电流不超过断路器Bl和B2的开断能力。B）线路出口发生故障时（线路出口与限流器之间），如图1（b）所示。动作模式：故障线路之外的限流器（即FCL2-4）动作，限制各自线路的短路电流，确保流经Bl的总短路电流不超过其开断能力。此时故障线路的限流模块FCLl可以动作，也可以不动作。C）线路出口发生故障时（线路与限流器之间），如图I（C）所示。这种情况断路器的动作模式与B）中相同，但由于线路24的总短路电流要流经FCLl,故FCLl不能动作。由于总短路电流已经被FeL24限制，因此FCLl可以按照本线路
4、短路电流参数进行配置，而无需考虑流经的总短路电流。综上，分布式限流方案的动作模式为：在母线发生故障时，所有线路出口安装的限流器均动作，限制故障电流；在线路发生短路故障时，该线路出口限流器不动作，其他线路限流器动作；限流模块参数按照所在线路参数配置，不考虑可能流经的总短路电流。实际中，电网尤其是输电系统发生故障时，其影响不仅仅局限于某一变电站。因此，限流器的布置应从电网全局考虑。而分布式限流方案中，限流器安装在输电线路出口处，限流阻抗投入后，提高了输电线路的阻抗水平。对于变电站之间的输电线路，可以起到双向限流的作用，提高了整个电网的稳定性。根据电网500kV变电站增城站的实际参数，利用PSCAD
5、建立了增城站的系统模型，对分布式限流方案的效果进行了仿真分析。图2是增城站50（）kV母线发生故障时限流示意图。此时所有线路的限流器均可正常投入使用。,短路故障增城.北邠Io增城水乡I -oo增城-水乡Il F丽盛落能H）增城超能HHKS）工变3Os)变40o图2增城站母线短路故障（分布式限流）仿真得到，在母线发生单相短路接地故障时，若不进行限流，最后一个断路器需要开断的电流峰值约为99.l0kA,已经超过断路器的最大开断能力；经限流之后,最后一个断路器需要开断的电流峰值为77.55kA,有效值为54.84kA63kA0开断过程中断路器两端未出现明显过电压。相对不加限流模块时，电流有效值降低了
6、15.24kA,限流率约为21.75%。主要结论（1）分布式限流方案能够提高了输电线路的阻抗水平，安装方式灵活，可以双向限流，提高整个电网的稳定性；（2）分布式限流时，需加入限流器保护装置，检测通过限流器的电流，如果短路电流超过了限流器所能承受的最大电流，则限流器不能动作。即故障线路上的限流装置不能动作；（3）分布式限流模式相比于其他限流模式，增加了延迟时间，其响应速度稍慢；（4）对于自然过零方式，其换流过程比较平稳，不会出现明显的过电压；强迫换流过程会出现明显的过电压，必须使用容量较大的避雷器来进行限制。后续研究内容能够快速响应、有效限流的限流装置是实现故障电流限制的基础。理想的限流装置，其
7、阻抗在正常电流范围内为零，在电流超出范围时能够迅速增加，能够吸收较大瞬时功率，过电压低，暂态过程平稳。因此将进一步研究阻抗能够随电流从O到大阻抗迅速变化并能承受瞬时大功率的高压变阻器装置，以实现较为理想的限流效果。目前课题组已提出多种高压变阻器装置的方案并展开了研究。在开发高并发系统的时候，我们一般通过三种方式去保障系统服务稳定：服务降级、服务限流和缓存。对于缓存在实际开发中使用的比较多，这个是大家的共识没有什么异议的。今天我们的主角是服务限流，在此之前我们先来看下服务限流和服务降级的区别：服务降级服务降级是在服务器压力陡增的情况下，利用现有的资源，关闭一些服务接口或者页面，以此来释放服务器资
8、源保证核心任务的正常运行。服务限流限流本质上是减少流量的访问，而服务的处理能力不变；而对于服务降级来说是降低了部分服务的处理能力，增加另一部分服务处理能力，访问量不变本篇文章中说到的服务限流不是nginx层面的限流，而是业务代码中的逻辑限流。那么，我们为什么要服务限流？从服务调用方来说，可以把服务简单的划分为以下几种类型的服务。1.与用户打交道的服务比如web服务，对外APL这种类型的服务有以下几种可能会导致服务器压力变大：用户增长过快热点事件恶意的攻击/刷单爬虫这些情况都是无法预知的，我们不知道什么时候请求流量会突增，如果真的要是碰到这种情况，扩容根本是来不及的。2.对内的RPC服务一个服务
9、A的接口可能会被其他BCDE多个服务调用，如果其中一个服务的流量突增比如B服务，导致A服务压力变大甚至挂掉，那么这个时候也不能给CDE服务提供服务。这种情况在实际开发中时常发生。常见的限流算法下面我们来看几种实际业务场景中常用的几种限流算法：计数器算法、漏桶算法、令牌桶算法。计数器算法计数器算法应该是最简单，最容易想到的限流策略。限流的本质是限制某一个API在某个维度单位时间内处理请求的次数。我们可以设置一个计数器对某一时间段内的请求进行计数，当请求量超过事先设定好的阈值,拒绝用户的请求。比如限流的QPS是100,算法的实现思路是从第一个请求进来开始计数，在接下来的IS内，每来一个请求计数器自
10、动加1,如果累加的数字超过100,那么后续的请求就会被拒绝，等到IS结束后，计数器开始重置为0,重新开始计数。这种方式存在弊端弊端1：如果在Is的前IomS请求数己经达到了100,那么剩下的990ms,服务调用方就要眼巴巴的看着请求被拒绝。弊端2：如果有一个恶意的用户在999ms的时候瞬间发送了100次请求，并且又在I(X)OmS时瞬间发送了100次请求，那么其实这个用户在Is内发送了200次请求。利用时间窗口的重置节点处突发请求，可以瞬间超过我们服务本身能承受的压力，瞬间压垮服务。针对计数器算法的漏洞一个比较经典的处理方案是采用滑动窗口。比如我们把上面的Imin内100次请求上限看成是一个大
11、的时间窗口，然后把这个窗口进一步细分，比如每IoS一个小窗口，该窗口的频率上限同样设置成100,这样大窗口包含16个小窗口，并且每过IOs大窗口就移动一个小窗口长度。如果一个恶意用户在09:59:3009:59:59之间发送了100次请求，等到了10:00:00-10:00:30时100次计数仍然是有效的，所以，这个时间段新的请求仍然会被拒绝。漏桶算法漏桶算法是限流方面比较经典的算法。可以把该算法联想成一个具体的漏桶模型，漏桶始终以一个恒定的速率往外排水，如果桶被装满的话则后来涌入的水会溢出。对应到接口限流来说，用户的请求可以看做是水，不管用户的请求量有多大多不均衡，能够被处理的请求速率是恒定
12、的，而且能够接受的请求数也是有上限的，超出上限的请求会被拒绝，在算法实现方面可以准备一个队列来作为漏桶的实现,用这个队列保存请求，通过一个线程池定期从队列中获取请求并执行，也可以一次性获取多个并发请求，如下图：12Mbps2 MbpsO 1 23456789 10Bursty data3 Mbps01 23456789 10 SFixed-ratedata漏桶算法也存在一个弊端：无法应对短时间的突发流量。令牌桶算法在令牌桶算法中，存在一个桶，用来存放固定数量的令牌。算法中存在一种机制，以一定的速率往桶中放令牌。每次请求调用需要先获取令牌，只有拿到令牌才有机会继续执行，否则请求选择等待或者服务直
13、接拒绝请求。放令牌这个动作是持续不断的进行，如果桶中令牌数量达到上限，就丢弃令牌，所以，会存在这样的一种情况，桶中一直有大量的令牌，这时进来的请求就可以直接拿到令牌执行。比如我们把QPS设置成100,那么限流器完成初始化IS后，桶中已经有100个令牌，这时候服务还未完全启动好，等启动完成功对外提供服务时，该限流器可以抵挡瞬时的100个请求。所以，当桶中没有令牌时请求才会等待或者被拒绝，当没有请求申请令牌时，那么这个令牌桶会溢出。在这里令牌桶类似一个buffer,请求密度比较低或者处于冷却状态下，令牌桶会溢出，当请求流量突增时，则过去积累的结余资源直接可以拿来借用，从这里可以看出这点弥补了漏桶算
14、法的不足。ArrivalReject实现思路：可以准备一个队列，用于存放令牌，另外通过一个线程池定期生成令牌存放到队列中，没来一个请求就从队列中取出一个令牌，并继续执行。上面我们提到的限流算法主要是针对于单机限流，实际业务场景更加的复杂，业务的需求五花八门，简单的单机限流很难满足需求。比如为了限制某个资源被某个用户访问的次数，IOs只能访问3次，或者一天只能访问100次，这种需求通过单机限流是无法实现的，这时就需要通过集群限流的方式实现。如何实现?为了实现对访问次数的限制，肯定需要一个计数器，那么我们需要把这个计数器放在哪里呢？因为这个限流是在集群层面实现的，集群形式存在的情况才需要分布式限流，由于redis天生对分布式支持非常友好，所以redis成了一个很好的选择。大致思路：每次有相关的操作时候，我们就向redis服务器发送一个incr命令。比如限制某个用户访问接口的次数，当用户请求过来时我们使用用户ID和接口名称生成对应key,每次该用户访问这个接口时,只需要对这个key增加1,并且给这个key设置有效期，这样就可以简单的实现指定时间内的访问效率。
