分流方法、数据服务系统及其前端、存储介质与流程

本发明涉及计算机
技术领域：
，特别涉及一种分流方法、数据服务系统及其前端、存储介质。
背景技术：
：系统上线运营期间，可能会遇到用户量激增、访问量暴涨超过系统负荷的情况，也可能发生地震造成机房断电等极端情况，导致系统完全无法使用。为防止由于上述原因导致系统无法正常使用，一般会提升系统性能以应对用户量激增、访问量暴涨等的情况，或者配置容灾环境以应对系统瘫痪等的恶劣情况，保证系统的正常运行。比如，对于需要承接世界杯等的直播、转播的系统，就需要对系统进行扩展以提升性能。现有措施一般包括：对后台数据库、缓存、应用等的扩容；对系统后台业务逻辑处理的优化；对系统后台接口访问量的限制和放通；异地容灾环境配置及系统双活实现。发明人发现相关技术至少存在以下问题：现有系统性能的提升着重于后台自身的优化，而一旦后台由于压力过大或者突发情况导致系统瘫痪，则会极大影响用户使用。同时由于压力过大，也会影响系统的稳定性。技术实现要素：本发明实施方式的目的在于提供一种分流方法、数据服务系统及其前端、存储介质，通过前端探测系统后台的实时响应能力，并在压力过大时对请求进行分流，从而可以大幅缓解后台压力，保障系统稳定运行。为解决上述技术问题，本发明的实施方式提供了一种分流方法，应用于数据服务系统的前端，所述分流方法包括：在处理接收的请求之前，获取所述数据服务系统主服务后台的实时响应数据；根据所述实时响应数据确定是否需要分流，若需要分流，则将当前请求分流至所述数据服务系统的灾备后台，若不需要分流，则将当前请求发送至所述主服务后台处理。本发明的实施方式还提供了一种数据服务系统的前端，包括：存储器和处理器，存储器存储计算机程序，处理器运行所述计算机程序以实现如前所述的分流方法。本发明的实施方式还提供了一种存储介质，用于存储计算机可读程序，所述计算机可读程序用于供计算机执行如前所述的分流方法。本发明实施方式相对于现有技术而言，在处理接收的请求之前，通过前端获取数据服务系统主服务后台的实时响应数据，并根据获取的实时响应数据确定是否需要分流，即根据后台的实时响应数据确定后台的压力是否过大，并在后台的压力过大时，将当前请求分流至灾备后台，从而可以有效缓解后台的处理压力，进而既可保障后台的稳定运行，又能更好的响应用户请求，提高用户体验。作为一个实施例，所述根据所述实时响应数据确定是否需要分流，具体包括：根据所述实时响应数据计算得到系统实时响应率；确定所述系统实时响应率是否小于系统响应率阈值，若小于所述系统响应率阈值，则确定需要分流；若所述系统实时响应率大于或者等于所述系统响应率阈值，则确定不需要分流。作为一个实施例，所述实时响应数据包括以下参考数据：最近的第一预设时长内的各单位时间内请求响应数、各单位时间内并发数、各单位时间内吞吐量以及各单个请求的处理时间；所述根据所述实时响应数据计算得到系统实时响应率，具体包括：计算得到最近的第一预设时长内的单位时间内请求响应数到达单位时间内请求响应数阈值的概率p1；计算得到最近的第一预设时长内的单位时间内并发数到达单位时间内并发数阈值的概率p2；计算得到最近的第一预设时长内的单位时间内吞吐量到达单位时间内吞吐量阈值的概率p3；根据最近的第一预设时长内的各单个请求的处理时间计算得到系统时间响应率p4；将所述p1至所述p4加权求和得到所述系统实时响应率。作为一个实施例，采用泊松分布计算得到所述p1、所述p2和所述p3。作为一个实施例，所述根据最近的第一预设时长内的各单个请求的处理时间计算得到系统时间响应率p4，具体包括：按照预设的多个响应区间确定所述第一预设时长内的每个请求的处理时间所属的响应区间；计算得到所述第一预设时长内的每个响应区间内的单个请求的平均处理时间；计算每个所述响应区间的平均处理时间与所述响应区间的分布率的乘积，得到各所述响应区间对应的乘积；其中，所述响应区间的分布率为该响应区间内的请求次数与所有响应区间内的请求次数之比；将各所述响应区间对应的乘积加权求和得到所述p4。作为一个实施例，所述分流方法还包括：每次计算得到所述系统实时响应率之后将所述系统实时响应率缓存；在所述获取所述数据服务系统主服务后台的实时响应数据之后，且在所述确定所述系统实时响应率是否小于系统响应率阈值之前，还包括：确定是否需要更新缓存的所述系统实时响应率，若需要更新缓存的所述系统实时响应率，则根据获取的实时响应数据重新计算得到系统实时响应率；所述确定所述系统实时响应率是否小于系统响应率阈值，具体包括：确定缓存的所述系统实时响应率是否小于所述系统响应率阈值，若缓存的所述系统实时响应率小于所述系统响应率阈值，则确定需要分流，若缓存的所述系统实时响应率大于或者等于所述系统响应率阈值，则确定不需要分流。作为一个实施例，所述确定是否需要更新缓存的所述系统实时响应率，具体包括：确定所述系统实时响应率的缓存持续时长是否大于第二预设时长，若大于所述第二预设时长，则确定需要更新所述系统实时响应率，若小于或者等于所述第二预设时长，则确定不需要更新所述系统实时响应率。附图说明图1是本发明数据服务系统的结构示例图；图2是根据本发明第一实施方式分流方法的流程图；图3是图2中步骤202的子流程图；图4是图3中步骤301的子流程图；图5是图4中步骤404的子流程图；图6是根据本发明第二实施方式分流方法的流程图；图7是根据本发明第三实施方式数据服务系统的前端的结构示意图。具体实施方式为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合附图对本发明的各实施方式进行详细的阐述。然而，本领域的普通技术人员可以理解，在本发明各实施方式中，为了使读者更好地理解本发明而提出了许多技术细节。但是，即使没有这些技术细节和基于以下各实施方式的种种变化和修改，也可以实现本发明所要求保护的技术方案。本发明的第一实施方式涉及一种分流方法，可应用于如图1所示的数据服务系统的前端。数据服务系统包括主服务后台以及灾备后台。其中，后台应用现网集群以及nginx现网集群属于主服务后台，后台应用集群以及nginx容灾集群属于灾备后台。nginx是一个高性能的http(hypertexttransferprotocol，超文本传输协议)和反向代理服务，本实施方式对于数据服务系统不做具体限制。本实施方式的分流方法包括：在处理接收的请求之前，获取数据服务系统主服务后台的实时响应数据；根据实时响应数据确定是否需要分流，若需要分流，则将当前请求分流至数据服务系统的灾备后台，若不需要分流，则将当前请求发送至主服务后台处理。本发明实施方式相对于现有技术而言，在处理接收的请求之前，通过前端获取数据服务系统主服务后台的实时响应数据，并根据获取的实时响应数据确定是否需要分流，即根据后台的实时响应数据确定后台的压力是否过大，并在后台的压力过大时，将当前请求分流至灾备后台，从而可以有效缓解后台的处理压力，进而既可保障后台的稳定运行，又能更好的响应用户请求，提高用户体验。下面结合图2～图5对本实施方式的分流方法进行详细说明。如图2所示，本实施方式的分流方法包括步骤201至步骤204。步骤201：在处理接收的请求之前，获取数据服务系统主服务后台的实时响应数据。其中，实时响应数据包括最近的第一预设时长内的各单位时间内请求响应数、各单位时间内并发数、各单位时间内吞吐量以及各单个请求的处理时间。第一预设时长例如为30分钟，此时，实时响应数据即为距离当前请求最近的30分钟内的数据。然不限于此，第一预设时长可以根据主服务后台负载压力随时间变化的特点进行设定，例如还可以为10分钟。其中，单位时间内请求响应数例如为每分钟完成的web请求响应数n，单位时间内并发数例如为每分钟系统同时处理的web请求响应数量c,单位时间内吞吐量例如为每分钟系统传输数据总量。然不限于此，实时响应数据还可以包括其他能够反映主服务后台的处理压力的相关数据，或者不包括上述参考数据中的一者或者两者，只要通过实时响应数据能够准确衡量主服务后台的处理压力即可。下面结合图1对实时响应数据的获取方法举例说明如下：用户终端，例如移动终端向前端发起登录请求，即向前端中的app发起登录请求，app调起统一sdk(softwaredevelopmentkit，软件开发工具包)的登陆页，统一sdk调用后台验证账号密码，统一sdk每调用一次，就可以对主服务后台的上述数据每分钟完成的web请求响应数n、并发数c、单个请求的响应时间、吞吐量m进行采集，以获取实时响应数据。然不限于此。步骤202：根据实时响应数据确定是否需要分流，若需要分流，则执行步骤203将当前请求分流至数据服务系统的灾备后台，若不需要分流，则执行步骤204将当前请求发送至主服务后台处理。如图3所示，步骤202根据实时响应数据确定是否需要分流包括步骤301至步骤304。步骤301：根据实时响应数据计算得到系统实时响应率。其中，可以在前端每接收到一个请求时执行一次步骤301，然不限于此。步骤301中例如根据最近的30分钟内的前述四种参考数据计算得到系统实时响应率。请参阅图4，步骤301具体包括步骤401至步骤405。步骤401：计算得到最近的第一预设时长内的单位时间内请求响应数到达单位时间内请求响应数阈值的概率p1。步骤402：计算得到最近的第一预设时长内的单位时间内并发数到达单位时间内并发数阈值的概率p2。步骤403：计算得到最近的第一预设时长内的单位时间内吞吐量到达单位时间内吞吐量阈值的概率p3。其中，可以通过压力测试评估出主服务后台的各项处理指标最大值，从而得到单位时间内请求响应数阈值、单位时间内并发数阈值以及单位时间内吞吐量阈值。其中，前述各项阈值中的单位时间均可以为每分钟。然不限于此。步骤401～步骤403中，可以采用泊松分布计算得到p1、p2和p3。比如，可以根据泊松分布公式(一)，推算出当前主服务后台每分钟内的并发数超过每分钟内的并发数阈值的概率：泊松分布指单位时间内随机事件的平均发生率。其中，n表示函数关系，比如，一分钟请求100次，则p(n(1)＝100)，公式(一)等号右边为概率计算方法，公式中的λ表示实际每分钟并发数，可以通过将第一预设时长内的多个并发数取平均值得到；t表示单位时间，n表示每分钟内的并发数阈值。泊松分布实质就是单位时间内独立事件发生次数的概率分布，因此上述公式中的p即是第一预设时长内单位时间内并发数到达单位时间内并发数阈值的概率p2。同理，可以计算得到单位时间内请求响应数到达单位时间内请求响应数阈值的概率p1，其中λ表示实际每分钟的请求响应数，可以通过将第一预设时长内的多个每分钟内的请求响应数取平均值得到；t表示单位时间，n表示每分钟内的请求响应数阈值。还可以根据泊松分布公式类似地计算得到第一预设时长内的单位时间内吞吐量到达单位时间内吞吐量阈值的概率p3，计算方式此处不再赘述。步骤404：根据最近的第一预设时长内的各单个请求的处理时间计算得到系统时间响应率p4。步骤404具体包括步骤501至步骤504。步骤501：按照预设的多个响应区间确定第一预设时长内的每个请求的处理时间所属的响应区间。具体地，响应时间在5秒以内为快速响应，对应于第一响应区间，响应时间在5～8秒之间为响应稍慢，对应于第二响应区间，响应时间在8～10秒之间为响应偏慢，对应于第三响应区间,响应时间超过10秒则为响应极慢或者无法正常响应，对应于第四响应区间。本实施方式对于响应时间与响应区间的对应关系不作具体限制。步骤502：计算得到第一预设时长内的每个响应区间内的单个请求的平均处理时间。具体来说，最近30分钟内例如有1000条请求，对应1000条响应时间，响应时间在5秒内的请求有800条，即第一响应区间内的请求有800条，且第一响应区间内的800条请求的平均响应时间(即处理时间)是1秒，则第一响应区间内的单个请求的平均处理时间就为1秒，以此类推可以计算得到其他响应区间对应的单个请求的平均处理时间，此处不再赘述。步骤503：计算每个响应区间的平均处理时间与响应区间的分布率的乘积，得到各响应区间对应的乘积。其中，响应区间的分布率为该响应区间内的请求次数与所有响应区间内的请求次数之比。在一个例子中，分布率可以通过历史数据计算得到，如可以通过至少六个月的历史数据计算得到，以通过统计12个月的历史数据计算得到分布率为例，可以采集主服务后台12个月的响应时间日志，按月为单位，统计响应时间在5秒以内、5～8秒、8～10秒、10秒以上这四个响应区间内的请求数量q1、q2、q3、q4，按照公式(二)计算得到每个响应区间的请求次数与所有响应区间内的请求次数之比pi，即可得到单月分布率。取12个月的分布率均值作为本实施方式中的预设的分布率。pi＝q1/(q1+q2+q3+q4)*100％(二)比如，一个月采集到10万条请求分别对应10万条响应时间，并将其划分到四个响应区间内，比如，8万条响应时间在5秒以内，则该月5秒内的响应时间对应的分布率(即第一响应区间对应的分布率)即为80％，1.5万条数据的响应时间在5～8秒，则该月5～8秒内的响应时间对应的分布率(即第二响应区间对应的分布率)即为15％，以此类推，得到该月中其他响应区间对应的分布率，具体可参考表一中的示例数据，其中，第二响应区间对应的分布率为3％，第四响应区间对应的分布率为2％。连续采集12个月的分布率，取平均值，即可得出各响应区间对应的分布率作为预设的分布率。采用历史数据计算分布率，可以充分评估当前系统性能，采集时间区间越大，得到的当前系统响应区间分布率越精确，可以更准确地判断当前系统的处理能力。在实际应用中，还可以根据需要更新预设的分布率。表一不同响应区间的响应次数分布率响应时间在5秒以内的请求次数(q1)80％响应时间在5～8秒之间的请求次数(q2)15％响应时间在8～10秒之间的请求次数(q3)3％响应时间在10秒以上的请求次数(q4)2％其中，第一响应区间的分布率越大，说明主服务后台的响应率越高，处理能力越强。本实施方式中，第一预设时长内的每个响应区间对应的平均处理时间分别为qrt1～qrt4，分别表示第一至第四响应区间内的单个请求的平均处理时间。比如，距离当前请求最近的30分钟内的请求为1000条，分别对应1000条响应时间。响应时间在5秒内的请求有800条，且该800条请求的平均响应时间(即处理时间)是1秒，那么qrt1就为1秒，以此类推，根据第一预设时长内的单个请求的处理时间分别计算得到qrt2～qrt4。在计算得到各响应区间对应的qrt1～qrt4之后，计算得到各响应区间对应的qrt1～qrt4与各响应区间对应的预设的分布率之乘积。步骤504：将各响应区间对应的乘积加权求和得到p4。具体地，可以采用公式(三)计算得到系统时间响应率p4。其中，第一至第四响应区间对应的权值例如分别为5、3、2、1。因此，主服务后台的时间响应率p4的值越大，最终的处理性能越佳。p4＝(qrt1*5*80％+qrt2*3*15％+qrt3*2*3％+qrt4*1*2％)/11(三)步骤405：将p1至p4加权求和得到系统实时响应率。根据上述步骤中得到的p1至p4等的各项指标以及公式四计算得到系统实时响应率p。，其中，p1～p4等的各项指标的权值可以根据其对响应性能影响的大小确定。比如，p1～p4等的各项指标的权值分别为3、3、1、3，然不限于此。p＝(p1*3+p2*3+p3*3+p4*3)/10(四)其中，系统实时响应率p的值越大表明主服务后台的响应能力越佳。步骤302：确定系统实时响应率是否小于系统响应率阈值。其中，可以采用类似系统实时响应率的计算方式计算得到系统响应率阈值，区别在于系统实时响应率主要是基于主服务后台的实时响应数据计算得到，而系统响应率阈值则可以是根据通过压力测试得到的主服务后台的各项参考数据的最优值计算得到，此处不再赘述。若在步骤302中，确定系统实时响应率小于系统响应率阈值，则执行步骤303确定需要分流，若系统实时响应率大于或者等于系统响应率阈值，则执行步骤304确定不需要分流。也就是说，比较系统实时响应率p与前端统一sdk中预设的系统响应率阈值pt，如果p<pt,则说明主服务后台的处理能力较低，前端需要实施分流措施，将当前请求提交至灾备后台，例如提交至nginx容灾集群或者后台应用集群。同样，当前端统一sdk对主服务后台进行请求时无法获取实时响应数据时，或者计算得到的系统实时响应率p远低于pt时，则可确定主服务后台处于崩溃状态，此时，主服务后台自身已无法自动实现容灾环境的切换，此时亦由前端直接将请求提交至灾备后台。前端统一sdk根据灾备后台的返回结果对用户做出响应，例如对用户的登录请求做出登录响应。因此，本实施方式在主服务后台压力较大的情况下，由前端直接将请求提交至灾备后台进行处理，从而及时响应用户请求，提高用户体验。与现有技术相比，本实施方式通过前端获取主服务后台的实时响应数据，例如获取能够反映主服务后台的处理压力的多种参考数据，从而根据多种参考数据计算得到主服务后台的系统实时响应率，并根据系统实时响应率的大小确定是否需要分流，从而可在主服务后台的处理压力较大时，将请求切换至灾备后台处理，不仅有利于缓解主服务后台的压力，保障主服务后台的稳定性，而且可以更好地响应用户请求，提高用户体验。本发明的第二实施方式涉及一种分流方法，本实施方式与第一实施方式大致相同，主要区别之处在于：在第一实施方式中，前端可以根据当前请求实时计算系统实时响应率，而在第二实施方式中，可以根据预设条件确定系统实时响应率的计算频次，使得系统实时响应率的计算频次大幅减少，有利于提高响应性能。请参阅图6，本实施方式的分流方法包括步骤601至步骤607。步骤601：每次计算得到系统实时响应率之后将系统实时响应率缓存。其中，可以根据最近的第一预设时长内的多种类型的参考数据计算得到系统实时响应率，具体请参考第一实施方式的步骤301，此处不再赘述，并缓存计算得到的系统实时响应率，例如将计算得到的系统实时响应率缓存第二预设时长，第二预设时长例如为30分钟，然不限于此。步骤602：获取数据服务系统主服务后台的实时响应数据。其中，实时响应数据包括最近的第一预设时长内的多种类型的参考数据。步骤602与第一实施方式中的步骤201相同，此处不再赘述。步骤603：在处理接收的请求之前，确定是否需要更新缓存的系统实时响应率，若需要更新缓存的系统实时响应率，则执行步骤604，若不需要更新缓存的系统实时响应率，则执行步骤605。步骤603具体包括：确定系统实时响应率的缓存持续时长是否大于第二预设时长，若大于第二预设时长，则确定需要更新系统实时响应率，若小于或者等于第二预设时长，则确定不需要更新系统实时响应率。其中，第二预设时长可以根据实际需要设置，只要基本不影响系统实时响应率的准确性即可，第二预设时长例如为30分钟，然不限于此，例如还可以为5分钟等。在一个例子中，还可以根据缓存计算得到的系统实时响应率之后累计的请求次数的多少确定是否需要更新系统实时响应率，例如，累计的请求次数大于预设次数时，确定需要更新系统实时响应率，否则不需要更新系统实时响应率。步骤604：根据获取的实时响应数据重新计算得到系统实时响应率并缓存。步骤604中系统实时响应率的计算方式与步骤301相同，此处不再赘述。步骤605：确定缓存的系统实时响应率是否小于系统响应率阈值，若小于系统响应率阈值，则执行步骤606，若系统实时响应率大于或者等于系统响应率阈值，则执行步骤607。本实施方式中，当系统实时响应率被缓存之后且在未达到第二预设时长之前，用户再一次发起请求时，前端统一sdk可以直接根据缓存的系统实时响应率确定是否需要分流，而无需频繁计算系统实时响应率。步骤606：将当前请求分流至数据服务系统的灾备后台。步骤607：将当前请求发送至主服务后台处理。步骤605～步骤607与第一实施方式的步骤302～304对应，此处不再赘述。与现有技术相比，本实施方式通过前端获取主服务后台的实时响应数据，例如获取能够反映主服务后台的处理压力的多种参考数据，从而根据多种参考数据计算得到主服务后台的系统实时响应率，并根据系统实时响应率的大小确定是否需要分流，从而可在主服务后台的处理压力较大时，将请求切换至灾备后台处理，不仅有利于缓解主服务后台的压力，保障主服务后台的稳定性，而且可以更好地响应用户请求，提高用户体验。并且本实施方式中，由于前端是根据缓存的系统实时响应率确定是否需要分流的，而缓存中的系统实时响应率可以在其缓存持续时长到达第二预设时长时被更新，因此，本实施方式中前端无需在接收到每个请求时均计算系统实时响应率，从而可以在基本不影响系统实时响应率探测准确性的情况下，大幅降低前端的计算负担，提高响应性能。本发明的第三实施方式涉及一种数据服务系统的前端。如图7所示，该前端包括：存储器702和处理器701；其中，所述存储器702存储有可被所述至少一个处理器701执行的指令，所述指令被所述至少一个处理器701执行以实现：在处理接收的请求之前，获取所述数据服务系统主服务后台的实时响应数据；根据所述实时响应数据确定是否需要分流，若需要分流，则将当前请求分流至所述数据服务系统的灾备后台，若不需要分流，则将当前请求发送至所述主服务后台处理。一个或多个处理器701以及存储器702，图7中以一个处理器701为例。处理器701、存储器702可以通过总线或者其他方式连接，图7中以通过总线连接为例。存储器702作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块。处理器701通过运行存储在存储器702中的非易失性软件程序、指令以及模块，从而执行设备的各种功能应用以及数据处理，即实现上述分流方法。存储器702可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序。此外，存储器702可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施方式中，存储器702可选包括相对于处理器701远程设置的存储器，这些远程存储器可以通过网络连接至外接设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。一个或者多个模块存储在存储器702中，当被一个或者多个处理器701执行时，执行上述任意方法实施方式中的分流方法。上述设备可执行本发明实施方式所提供的方法，具备执行方法相应的功能模块和有益效果，未在本实施方式中详尽描述的技术细节，可参见本发明实施方式所提供的方法。与现有技术相比，本实施方式通过前端获取主服务后台的实时响应数据，例如获取能够反映主服务后台的处理压力的多种参考数据，从而根据多种参考数据计算得到主服务后台的系统实时响应率，并根据系统实时响应率的大小确定是否需要分流，从而可在主服务后台的处理压力较大时，将请求切换至灾备后台处理，不仅有利于缓解主服务后台的压力，保障主服务后台的稳定性，而且可以更好地响应用户请求，提高用户体验。并且本实施方式中，由于前端是根据缓存的系统实时响应率确定是否需要分流的，而缓存中的系统实时响应率可以在其缓存持续时长到达第二预设时长时被更新，因此，本实施方式中前端无需在接收到每个请求时均计算系统实时响应率，从而可以在基本不影响系统实时响应率探测准确性的情况下，大幅降低前端的计算负担，提高响应性能。本发明的第四实施方式涉及一种非易失性存储介质，用于存储计算机可读程序，所述计算机可读程序用于供计算机执行上述部分或全部的方法实施例。即，本领域技术人员可以理解，实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。本领域的普通技术人员可以理解，上述各实施方式是实现本发明的具体实施例，而在实际应用中，可以在形式上和细节上对其作各种改变，而不偏离本发明的精神和范围。当前第1页12