CN117041233B - 一种分布式云计算的方法及系统 - Google Patents

一种分布式云计算的方法及系统 Download PDF

Info

Publication number
CN117041233B
CN117041233B CN202311289680.9A CN202311289680A CN117041233B CN 117041233 B CN117041233 B CN 117041233B CN 202311289680 A CN202311289680 A CN 202311289680A CN 117041233 B CN117041233 B CN 117041233B
Authority
CN
China
Prior art keywords
request
abnormal
music
node
user
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202311289680.9A
Other languages
English (en)
Other versions
CN117041233A (zh
Inventor
林金怡
李韩
胡磊明
吴伟华
胡高生
陈泽宇
余武
于善龙
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Unicom WO Music and Culture Co Ltd
Original Assignee
China Unicom WO Music and Culture Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by China Unicom WO Music and Culture Co Ltd filed Critical China Unicom WO Music and Culture Co Ltd
Priority to CN202311289680.9A priority Critical patent/CN117041233B/zh
Publication of CN117041233A publication Critical patent/CN117041233A/zh
Application granted granted Critical
Publication of CN117041233B publication Critical patent/CN117041233B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80Responding to QoS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1416Event detection, e.g. attack signature detection
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1425Traffic logging, e.g. anomaly detection
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请提供一种分布式云计算的方法及系统,包括:根据音乐播放频率、播放时段分布和用户活跃度监测,获取音乐播放的主要热点时间以及出现的异常登录或播放行为;通过异常请求源地址追踪结合用户位置信息统计,确定异常请求的来源并进行阻断,同时确保真实用户的音乐播放不受影响;采用数据传输速率检测和网络连接稳定性分析,判断网络或服务器是否出现瓶颈,以及是否有必要对节点进行负载均衡;通过计算资源分配策略和节点负载均衡机制,确保真实有用的音乐播放请求和其他正常业务得到更多的计算资源;结合音乐播放设备种类和用户账号安全性检测,对于受到威胁的账号或设备,提供额外的资源以确保播放流畅。

Description

一种分布式云计算的方法及系统
技术领域
本发明涉及信息技术领域,尤其涉及一种分布式云计算的方法及系统。
背景技术
现有音乐播放器往往依赖传统的安全防护措施来识别和拦截异常请求。然而,这些方法往往难以准确识别新型的攻击手法,尤其是针对音乐播放服务的特定攻击,现有音乐播放器检测用户是否为真实用户的手段单一,这导致了一些恶意请求能够绕过检测,进而对云计算节点产生影响。现有音乐播放器面对复杂的攻击手法时往往无法有效地防御。分布式拒绝服务攻击和零日攻击会以大规模流量或者漏洞利用的方式对云计算节点进行攻击,极大地消耗节点的资源,导致正常请求无法得到响应。现有音乐播放器缺乏应对这些复杂攻击的能力,容易受到严重影响。现有音乐播放器在面对异常请求攻击时往往需要手动介入来进行响应和阻断。这导致了响应时间延迟,无法及时处理攻击请求。同时,由于人工干预的限制,现有播放器难以实现即时的响应和快速的恢复。这使得恶意请求能够在一段时间内持续攻击,进一步影响用户的音乐体验。异常请求攻击往往会导致节点资源被耗尽,使得部分正常用户的音乐播放请求无法得到及时的处理。现有音乐播放器缺乏动态调整节点资源的能力,无法根据实时负载情况来进行资源分配。这导致了资源的不均衡分配,一些用户可能会遭受到服务延迟和缓冲等问题。
发明内容
本发明提供了一种分布式云计算的方法及系统,主要包括:
根据音乐播放频率、播放时段分布和用户活跃度监测,获取音乐播放的主要热点时间以及出现的异常登录或播放行为;若各类音乐流派播放量发生大幅波动或存在大量疑似异常请求,通过异常请求流量统计和疑似异常请求特征,判断异常请求的影响范围;采用节点响应时间分析和节点资源消耗状况,结合音乐文件的完整性和音质,确定哪些云计算节点可能受到疑似异常请求的影响或数据完整性受到威胁;根据当前云计算节点数、节点健康状况以及服务器响应时间监测,动态调整云计算节点,优先处理真实有用的音乐播放请求,同时降低受到异常请求影响的节点数量;通过异常请求源地址追踪结合用户位置信息统计,确定异常请求的来源并进行阻断,同时确保真实用户的音乐播放不受影响;通过计算资源分配策略和节点负载均衡机制,确保真实有用的音乐播放请求和其他正常业务得到更多的计算资源;结合音乐播放设备种类和用户账号安全性检测,对于受到威胁的账号或设备,提供额外的资源以确保播放流畅;采用音乐播放请求数据量、真实请求与异常请求比例以及音乐播放请求优先级,进行综合判断,确保高优先级的音乐播放请求和其他重要业务得到优先响应。
在一些实施例中,所述根据音乐播放频率、播放时段分布和用户活跃度监测,获取音乐播放的主要热点时间以及出现的异常登录或播放行为,包括:
通过统计用户的播放次数和播放时长数据,得到用户的播放频率;统计用户在早晨、下午、晚上不同时间段的播放次数,确定用户的喜好播放时段;根据用户的登录次数、播放次数和播放时长,获得用户的活跃度;通过分析用户在不同时间段内的播放次数和播放时长,确定用户的热点时间段;通过监测用户的登录IP地址和登录地点,判断是否出现异常登录行为;通过分析用户的播放行为和异常播放次数,判断是否出现异常播放行为;根据对用户的播放次数、播放时长、登录次数、活跃时长、登录IP地址、登录地点以及异常播放次数进行分析,得到用户的播放频率、喜好播放时段、活跃度水平和热点时间段,判断异常登录行为和异常播放行为。
在一些实施例中,所述若各类音乐流派播放量发生大幅波动或存在大量疑似异常请求,通过异常请求流量统计和疑似异常请求特征,判断异常请求的影响范围,包括:
根据不同音乐流派的异常请求量和播放量,获取各个流派的异常请求数据和播放量数据;通过比较异常请求的播放量变化和正常请求的播放量变化,判断异常请求对播放量的影响范围;如果异常请求导致播放量出现大于预设值的波动或异常增加,确定异常请求对播放量的影响大;统计异常请求的流量变化和正常请求的流量变化,确定异常请求对流量的影响范围;如果异常请求导致流量突然增加或突然减少,判断异常请求对流量的影响范围大;分析异常请求的特征,包括访问频率、访问来源、访问时间,判断异常请求的来源和影响范围;如果高于预设请求值的异常请求来自某个特定的地理位置或特定的设备,判断异常请求的影响范围局限在这个范围内,判断影响范围小;根据异常请求的播放量影响、流量影响和特征分析的结果,确定异常请求的影响范围;如果异常请求对各类音乐流派的播放量造成高于预设的波动或存在高于预设请求值的疑似异常请求,并且异常请求流量统计和疑似异常请求特征分析结果均为影响范围大,判断异常请求的影响范围大。
在一些实施例中,所述采用节点响应时间分析和节点资源消耗状况,结合音乐文件的完整性和音质,确定哪些云计算节点可能受到疑似异常请求的影响或数据完整性受到威胁,包括:
通过监测云计算节点对请求的响应时间,得到每个节点的响应时间数据;检查每个节点的资源消耗,包括CPU利用率、内存利用率、网络带宽利用率,获取节点的资源消耗数据;对存储在云计算节点上的音乐文件进行完整性检查,包括校验和或哈希值比对,获取每个音乐文件的完整性检查结果;对音乐文件进行音质分析,包括噪声、失真,获取每个音乐文件的音质分析结果;识别疑似异常请求的模式或特征,获取疑似异常请求的识别结果;根据节点响应时间数据,判断是否存在响应时间高于预设值的节点;根据节点资源消耗数据,判断是否存在资源消耗异常的节点;根据音乐文件完整性检查结果,判断是否存在完整性受到威胁的音乐文件;根据音质分析结果,判断是否存在音质异常的音乐文件;综合分析每个节点的响应时间、资源消耗状况、音乐文件完整性和音质,确定受到疑似异常请求影响或数据完整性受到威胁的云计算节点;还包括:根据节点响应时间数据,对音乐数据进行异常值检测,识别疑似异常请求的模式或特征,确定受到疑似异常请求影响的云计算节点。
所述根据节点响应时间数据,对音乐数据进行异常值检测,识别疑似异常请求的模式或特征,确定受到疑似异常请求影响的云计算节点,具体包括:
根据节点响应时间数据,获取每个节点对音乐请求的响应时间。对节点响应时间数据进行时间序列处理,将其按照时间顺序进行排序,形成时间序列。通过趋势分析对数据进行预处理和特征提取。根据时间序列数据,提取统计特征,作为节点响应时间的特征。采用3倍标准差法,根据节点响应时间的特征,判断疑似异常请求的模式或特征。对音乐数据进行异常值检测,确定异常请求,并确定受到影响的云计算节点。
在一些实施例中,所述根据当前云计算节点数、节点健康状况以及服务器响应时间监测,动态调整云计算节点,优先处理真实有用的音乐播放请求,同时降低受到异常请求影响的节点数量,包括:
通过Nagios获取当前系统中可用的云计算节点的数量,各个云计算节点的运行状态和健康程度,包括节点的CPU利用率、内存利用率、网络负载;获取服务器对请求的响应时间,请求发送到服务器返回响应的时间间隔;根据用户认证、请求内容标识,判断请求是否为真实有用的音乐播放请求;根据请求是否带有恶意请求、非法请求、重复请求标识,判断请求是否为异常请求;根据异常请求的影响范围,确定受到异常请求影响的节点数量;根据节点健康状况和服务器响应时间,对云计算节点进行动态调整;如果节点健康状况良好且服务器响应时间较短,减少节点数量以减少系统的负载;如果节点健康状况不佳且服务器响应时间较长,增加节点数量降低每个节点的负载;将真实有用的音乐播放请求优先分配给可用的健康节点进行处理;对异常请求进行过滤或防御措施,以降低异常请求对节点的影响,减少受到异常请求影响的节点数量;还包括:根据节点健康状况和服务器响应时间,动态调整云计算节点数量,提高系统的处理能力和性能;根据请求来源、用户行为和用户位置,判断真实有用的音乐播放请求,分配健康网络节点;根据检测到的疑似异常请求模式或特征,设计强化模块来应对异常请求,提高节点的处理能力。
所述根据节点健康状况和服务器响应时间,动态调整云计算节点数量,提高系统的处理能力和性能,具体包括:
根据监控系统获取节点健康状况,包括节点的CPU使用率、内存使用率、磁盘使用率。根据监控系统获取服务器响应时间,评估服务器的响应速度,包括请求的处理时间、网络延迟。采用加权轮询法,根据节点健康状况和服务器响应时间,进行节点数量的动态调整。根据阈值设定,通过比较节点健康状况和服务器响应时间的阈值,确定是否需要增加或减少节点数量。利用云计算平台提供的节点弹性伸缩功能,根据业务需求自动进行节点的增加或减少。结合业务属性,根据节点健康状况和服务器响应时间的实时数据,通过加权轮询法和节点弹性伸缩功能,实现动态节点调整。
所述根据请求来源、用户行为和用户位置,判断真实有用的音乐播放请求,分配健康网络节点,具体包括:
根据请求来源,获取请求的授权信息。判断请求的授权信息是否合法和可信。根据用户行为,包括用户的点击、收藏、分享数据,判断用户是否为真实用户。根据用户位置信息,确定用户所在地理位置。根据用户位置和网络节点候选列表中每个节点的地理位置,计算距离用户小于预设距离的节点。获取网络节点候选列表中每个节点的资源利用率,确定空闲资源高于预设值的节点。判断真实有用的请求并将其分配给距离最近且空闲资源高于预设值的节点。
所述 根据检测到的疑似异常请求模式或特征,设计强化模块来应对异常请求,提高节点的处理能力,具体包括:
根据节点的资源监测工具Nagios,获取节点的CPU利用率、内存使用量和网络带宽使用,判断当前资源利用率是否超过预设的阈值。如果资源利用率超过阈值,调整节点的资源分配,增加CPU、内存或网络带宽,得到调整后的节点资源分配情况。通过云节点服务监控系统Prometheus,获取当前请求的数量和请求处理时间,判断当前请求的数量和请求处理时间是否超过预设的阈值。如果超过阈值,进行负载均衡调度,将请求分发到负载低于预设值的节点上,得到调整后的节点负载情况。根据请求的特征,判断是否为频繁请求的静态资源,如果是频繁请求的静态资源,采用缓存技术将资源缓存到节点上。根据请求的特征,动态调整缓存策略,提高缓存的命中率,得到调整后的节点缓存策略。根据请求的增减情况,判断是否需要进行节点的弹性扩缩容。如果请求量增加,自动添加新节点来增加处理能力,如果请求量减少,自动释放多余的节点,减少资源的浪费,得到调整后的节点数量。根据检测到的异常请求模式或特征,判断是否为恶意请求。如果是恶意请求,采取相应的防护策略,包括IP封禁或限流,保护节点的正常运行,防止恶意请求对系统造成影响。
在一些实施例中,所述通过异常请求源地址追踪结合用户位置信息统计,确定异常请求的来源并进行阻断,同时确保真实用户的音乐播放不受影响,包括:
通过网络日志或防火墙工具,获取每个请求的源IP地址;根据每个用户的IP地址,使用IP地理定位服务获取其位置信息,包括国家、城市和经纬度;在服务器端使用计数器记录每个请求的时间戳和请求频率,将异常请求与正常请求进行对比;通过服务器端日志或请求头中的字段获取每个请求的类型,包括GET、POST、PUT,识别攻击类型;解析请求头或参数来获取每个请求中的用户标识,包括用户ID和会话ID;通过规则匹配来分析异常请求的行为特征,包括请求头中的异常字段、异常的请求参数或异常的请求路径,识别和区分异常请求;根据异常请求的源地址、用户位置信息、请求时间戳、请求频率、请求类型、用户标识和异常请求行为特征的综合分析,确定异常请求的来源;如果异常请求来自特定地理区域、具有高于预设值的请求频率、异常的请求类型,并且不包含有效的用户标识特征,判断为异常请求;对于确定为异常请求的来源,通过防火墙或访问控制列表,封禁源IP地址、限制请求频率或拒绝异常请求的访问;在采取阻断措施时,通过优先级设置或白名单机制,确保真实用户的请求正常访问和播放音乐,确保真实用户的音乐播放不受影响。
在一些实施例中,所述通过计算资源分配策略和节点负载均衡机制,确保真实有用的音乐播放请求和其他正常业务得到更多的计算资源,包括:
根据音乐播放请求的重要性和紧急程度,为其设置优先级;根据系统负载和业务需求,动态调整分配给音乐播放请求的计算资源的数量;监测节点的负载,通过收集节点的CPU使用率、内存占用,判断节点的负载,并根据负载动态调整资源分配;根据不同业务需求,确定根据负载调整资源分配的速度;采用加权轮询算法,将音乐播放请求分发到不同的节点;每个节点依次处理请求,确保计算资源均衡分配;定期监测节点的负载和可用性,通过心跳检测检查节点的健康状态,判断节点是否过载或发生故障,并及时调整请求的分发策略;根据节点的负载,采用自动化的横向扩展机制,动态地增加或减少节点的数量;当某个节点发生故障时,采用故障转移机制,将音乐播放请求转发到其他正常的节点。
在一些实施例中,所述结合音乐播放设备种类和用户账号安全性检测,对于受到威胁的账号或设备,提供额外的资源以确保播放流畅,包括:
通过识别不同类型的音乐播放设备,包括智能手机、平板电脑、个人电脑、智能音箱,获取设备的功能和资源信息;引入账号锁定机制,在连续多次登录失败或检测到可疑活动时,自动锁定账号并发送通知给用户;实时检测用户账号和设备的异常行为,如果有异常活动,包括登录失败超过预设次数、异地登录、频繁更改设备,自动触发警报并要求用户重新验证身份或暂时冻结账号;搭建分布式服务器网络,如果部分服务器受到攻击或故障,将播放请求转移到其他服务器;通过LOF算法,检测用户与正常模式明显不同的行为,设定一个阈值来判断数据中的异常点,如果LOF得分超过阈值,则判定为异常行为;将受威胁用户常用的音乐内容存储在本地设备上,降低对服务器的依赖;通过预加载,在用户播放新的音乐时提前下载相应的音乐内容,减少加载时间;使用自适应比特率,在低网络带宽或网络不稳定时动态调整音乐的比特率;还包括:根据设备的硬件和网络条件,选择音频编码、数据压缩算法和传输协议,获取经过优化的音乐数据,减少数据传输量,提高播放效率和流畅性。
所述根据设备的硬件和网络条件,选择音频编码、数据压缩算法和传输协议,获取经过优化的音乐数据,减少数据传输量,提高播放效率和流畅性,具体包括:
根据设备的处理能力、存储空间和网络接口硬件条件,确定音频编码和数据压缩算法的选择。根据设备的处理能力,音频编码算法的特点,包括编码效率、音质和解码复杂度,选择适合设备的音频编码算法。根据存储空间和网络接口的限制,选择数据压缩算法。根据设备所连接的网络条件包括3G、4G、Wi-Fi,选择合适的传输协议。如果网络传输速率低于预设网络传输速率或断开网络连接次数高于预设断开次数,采用流媒体传输协议。根据设备硬件条件和网络条件,传输协议的特点,包括可靠性、传输效率和延迟,确定数据传输协议的选择。根据设备的硬件和网络条件,获取经过优化的音乐数据,经过音频编码和数据压缩,减少数据传输量,通过合适的数据传输协议,提高播放效率和流畅性。
在一些实施例中,所述采用音乐播放请求数据量、真实请求与异常请求比例以及音乐播放请求优先级,进行综合判断,确保高优先级的音乐播放请求和其他重要业务得到优先响应,包括:
根据业务需求和用户体验,定义不同请求的优先级规则,将音乐播放请求划分为高优先级,并将其他重要业务分配相应的优先级;对音乐播放请求中传输的音频文件进行数据量估算,根据文件大小评估音乐播放请求所需的传输带宽和处理时间;根据历史数据或实时数据对音乐播放请求中真实请求与异常请求的比例进行统计分析,提高真实请求的优先级;根据数据量属性和真实请求与异常请求比例,对音乐播放请求进行分类和优先级调整,确认音乐播放请求的优先级为高,而其他重要业务的优先级则根据业务需求进行调整,充分利用系统资源并满足不同请求的优先级需求;获取当前的网络状况、处理能力和实时性要求,对不同优先级的请求进行动态调度和分配资源,确保高优先级的音乐播放请求和其他重要业务得到及时响应和优化处理;通过监测当前的网络状况和可用带宽,判断是否满足音乐播放请求的需求,如果带宽和网络速度有限,优化文件压缩和传输方式;建立异常处理机制,包括错误提示和异常请求过滤,出现异常请求或处理错误时,及时给予用户反馈,并且自动过滤异常请求;还包括:获取用户行为,根据用户行为判断用户身份,分配业务优先级。
所述获取用户行为,根据用户行为判断用户身份,分配业务优先级,具体包括:
根据用户的注册信息和登录状态,获取用户类型。通过用户的行为数据包括听歌记录、喜好标记、上传记录,判断用户的活跃程度和行为偏好。根据用户的活跃程度和行为偏好,确定用户的身份为普通用户、资深用户还是专业音乐人。根据用户的身份确定业务优先级和相关属性。根据普通用户的身份以及用户的听歌历史、喜好信息,为用户推荐相关音乐,获取热门歌曲、热门榜单内容,生成排行榜供用户浏览,通过分析用户的喜好和音乐类型,为其推荐适合的歌单。根据资深用户的身份以及用户的喜好、听歌习惯信息,定制个性化的歌单,提供高音质、无损音乐下载或播放选项,以满足其对音乐品质的要求,为其提供上传原创作品、与其他音乐人交流的平台。根据专业音乐人的身份,提供上传个人原创音乐并进行推广的平台,推广音乐人的作品,提供合作、演出机会信息,搭建专业音乐人社区平台。
本发明提供了一种分布式云计算系统,所述系统包括:
音乐播放监测与异常检测模块,用于根据音乐播放频率、播放时段分布和用户活跃度监测,获取音乐播放的主要热点时间以及出现的异常登录或播放行为;
异常流量分析与影响评估模块,用于若各类音乐流派播放量发生大幅波动或存在疑似异常请求,通过异常请求流量统计和疑似异常请求特征,判断异常请求的影响范围;
云计算节点安全监测模块,用于采用节点响应时间分析和节点资源消耗状况,结合音乐文件的完整性和音质,确定哪些云计算节点可能受到疑似异常请求的影响或数据完整性受到威胁;
动态节点调度模块,用于根据当前云计算节点数、节点健康状况以及服务器响应时间监测,动态调整云计算节点,优先处理真实有用的音乐播放请求,同时降低受到异常请求影响的节点数量;
异常请求追踪与阻断模块,用于通过异常请求源地址追踪结合用户位置信息统计,确定异常请求的来源并进行阻断,同时确保真实用户的音乐播放不受影响;
资源调度优化模块,用于通过计算资源分配策略和节点负载均衡机制,确保真实有用的音乐播放请求和其他正常业务得到更多的计算资源;
安全播放模块,用于结合音乐播放设备种类和用户账号安全性检测,对于受到威胁的账号或设备,提供额外的资源以确保播放流畅;
播放请求管理模块,用于采用音乐播放请求数据量、真实请求与异常请求比例以及音乐播放请求优先级,进行综合判断,确保高优先级的音乐播放请求和其他重要业务得到优先响应。
本发明实施例提供的技术方案可以包括以下有益效果:
本发明公开了一种基于音乐播放频率、播放时段分布和用户活跃度监测的异常请求检测和优化方法。该方法通过监测音乐播放的热点时间和出现的异常登录或播放行为,以及各类音乐流派播放量的波动和异常请求的影响范围,确定受到异常请求影响的云计算节点和数据完整性受到威胁的音乐文件。在确定受到影响的节点后,通过节点响应时间和资源消耗状况,结合音乐文件的完整性,优先处理真实有用的音乐播放请求,降低受到异常请求影响的节点数量。同时,通过异常请求源地址追踪和用户位置信息统计,确定异常请求的来源并尝试阻断,确保真实用户的音乐播放不受影响,对节点进行负载均衡。本发明采用计算资源分配策略和节点负载均衡机制,检测音乐播放设备种类和用户账号安全性,对受到威胁的账号或设备提供额外的资源以确保播放流畅。最后,本发明通过判断音乐播放请求数据量、真实请求与异常请求比例以及音乐播放请求优先级,确保高优先级的音乐播放请求得到优先响应,实现对音乐播放的异常请求检测和优化,提升音乐播放服务的质量和用户体验。
附图说明
图1为本发明的一种分布式云计算的方法及系统的流程图。
图2为本发明的一种分布式云计算的方法及系统的示意图。
图3为本发明的一种分布式云计算的方法及系统的又一示意图。
图4为本发明的一种分布式云计算系统的结构框图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、详细地描述。所描述的实施例仅仅是本发明的一部分实施例。
本实施例一种分布式云计算的方法及系统具体可以包括:
S101、根据音乐播放频率、播放时段分布和用户活跃度监测,获取音乐播放的主要热点时间以及出现的异常登录或播放行为。
通过统计用户的播放次数和播放时长数据,得到用户的播放频率。统计用户在早晨、下午、晚上不同时间段的播放次数,确定用户的喜好播放时段。根据用户的登录次数、播放次数和播放时长,获得用户的活跃度。通过分析用户在不同时间段内的播放次数和播放时长,确定用户的热点时间段。通过监测用户的登录IP地址和登录地点,判断是否出现异常登录行为。通过分析用户的播放行为和异常播放次数,判断是否出现异常播放行为。根据对用户的播放次数、播放时长、登录次数、活跃时长、登录IP地址、登录地点以及异常播放次数进行分析,得到用户的播放频率、喜好播放时段、活跃度水平和热点时间段,判断异常登录行为和异常播放行为。例如,用户A在过去一周内共播放了100首音乐,总共播放时长为7小时。根据统计,用户A的播放频率可以计算为每天播放14首音乐。根据用户A在不同时间段内的音乐播放次数统计,发现他在过于一周的早晨总共播放了10首音乐,下午总共播放了50首音乐,晚上总共播放了40首音乐。因此可以判断用户A的喜好播放时段是下午。根据用户A的登录次数和活跃时长统计,发现他共登录了20次,总活跃时长为8小时。则可以得出用户A的活跃度水平为平均每次登录时长为24分钟。根据用户A在不同时间段内的播放次数和播放时长,可以确定他的热点时间段是下午。因为下午是他播放次数最多的时间段。通过监测用户A的登录IP地址和登录地点,如果发现他在短时间内多次登录且IP地址和地点不一致,判断出现了异常登录行为。通过分析用户A的播放行为和异常播放次数,如果发现他在一天内播放了200首以上的音乐,判断出现了异常播放行为。综上所述,根据用户A的数据统计和分析,可以得出他的播放频率为每天14首音乐,喜好播放时段为下午,活跃度水平为每次登录时长为24分钟,热点时间段为下午。
S102、若各类音乐流派播放量发生大幅波动或存在大量疑似异常请求,通过异常请求流量统计和疑似异常请求特征,判断异常请求的影响范围。
根据不同音乐流派的异常请求量和播放量,获取各个流派的异常请求数据和播放量数据。通过比较异常请求的播放量变化和正常请求的播放量变化,判断异常请求对播放量的影响范围。如果异常请求导致播放量出现大于预设值的波动或异常增加,确定异常请求对播放量的影响大。统计异常请求的流量变化和正常请求的流量变化,确定异常请求对流量的影响范围。如果异常请求导致流量突然增加或突然减少,判断异常请求对流量的影响范围大。分析异常请求的特征,包括访问频率、访问来源、访问时间,判断异常请求的来源和影响范围。如果高于预设请求值的异常请求来自某个特定的地理位置或特定的设备,判断异常请求的影响范围局限在这个范围内,判断影响范围小。根据异常请求的播放量影响、流量影响和特征分析的结果,确定异常请求的影响范围。如果异常请求对各类音乐流派的播放量造成高于预设的波动或存在高于预设请求值的疑似异常请求,并且异常请求流量统计和疑似异常请求特征分析结果均为影响范围大,判断异常请求的影响范围大。例如,有以下不同音乐流派的异常请求数据和播放量数据,流派A异常请求量500次、播放量1000次、流派B异常请求量300次、播放量800次,流派C异常请求量200次,播放量600次。通过比较异常请求的播放量变化和正常请求的播放量变化,计算异常请求对播放量的影响范围。流派A的播放量变化率(异常请求量/播放量)x100%=(500/1000)x100%=50%,流派B的播放量变化率(异常请求量/播放量)x100%=(300/800)x100%=37.5%,流派C的播放量变化率(异常请求量/播放量)x100%=(200/600)x100%=33.3%。根据播放量变化率,看到流派A受到了50%的影响,而流派B和流派C的影响分别为37.5%和33.3%。如果预设的波动阈值为40%,那么在这个例子中,异常请求对流派A的播放量造成的影响范围较大。接下来,统计异常请求的流量变化和正常请求的流量变化,以确定异常请求对流量的影响范围。流派A的异常请求流量变化500次,流派A的正常请求流量变化1000次-500次=500次,流派B的异常请求流量变化300次,流派B的正常请求流量变化800次-300次=500次,流派C的异常请求流量变化200次,流派C的正常请求流量变化600次-200次=400次。根据异常请求的流量变化,我们可以看到流派A和流派B的异常请求流量变化与正常请求流量变化相等,而流派C的异常请求流量变化小于正常请求流量变化。如果异常请求流量变化超过预设阈值,我们可以认为异常请求对流量的影响范围较大。最后,分析异常请求的特征,包括访问频率、访问来源和访问时间。发现异常请求来自某个特定的地理位置,而其他流派的异常请求没有明显的地理限制。根据这个特征分析结果,我们可以推断异常请求的影响范围局限在特定地理位置的用户,因此对该流派的影响范围相对较小。综合以上分析,如果异常请求对流派A的播放量造成高于预设的40%的波动,并且流派A的异常请求流量变化与正常请求流量变化相等,判断异常请求对流派A的影响范围大。对流派B和流派C的异常请求数据和播放量数据进行分析,可以得出对流派B和流派C的异常请求的影响范围小。
S103、采用节点响应时间分析和节点资源消耗状况,结合音乐文件的完整性和音质,确定哪些云计算节点可能受到疑似异常请求的影响或数据完整性受到威胁。
通过监测云计算节点对请求的响应时间,得到每个节点的响应时间数据。检查每个节点的资源消耗,包括CPU利用率、内存利用率、网络带宽利用率,获取节点的资源消耗数据。对存储在云计算节点上的音乐文件进行完整性检查,包括校验和或哈希值比对,获取每个音乐文件的完整性检查结果。对音乐文件进行音质分析,包括噪声、失真,获取每个音乐文件的音质分析结果。识别疑似异常请求的模式或特征,获取疑似异常请求的识别结果。根据节点响应时间数据,判断是否存在响应时间高于预设值的节点。根据节点资源消耗数据,判断是否存在资源消耗异常的节点。根据音乐文件完整性检查结果,判断是否存在完整性受到威胁的音乐文件。根据音质分析结果,判断是否存在音质异常的音乐文件。综合分析每个节点的响应时间、资源消耗状况、音乐文件完整性和音质,确定受到疑似异常请求影响或数据完整性受到威胁的云计算节点。例如,节点A的平均响应时间为10ms,节点B的平均响应时间为12ms,节点C的平均响应时间为8ms。检查每个节点的资源消耗,包括CPU利用率、内存利用率、网络带宽利用率,获取节点的资源消耗数据。节点A的CPU利用率为60%,内存利用率为70%,网络带宽利用率为80%。对存储在云计算节点上的音乐文件进行完整性检查,包括校验和或哈希值比对,获取每个音乐文件的完整性检查结果。音乐文件1的校验和为ABC123,完整性检查结果为通过,音乐文件2的校验和为DEF456,完整性检查结果为通过。对音乐文件进行音质分析,包括噪声、失真,获取每个音乐文件的音质分析结果。音乐文件1的噪声水平为低,失真程度为无失真;音乐文件2的噪声水平为中,失真程度为轻微失真。识别疑似异常请求的模式或特征,获取疑似异常请求的识别结果。识别出某个请求在短时间内发送了大量数据包。根据节点响应时间数据,判断是否存在响应时间异常高的节点。节点B的响应时间明显高于其他节点的平均响应时间,可能存在响应时间异常高的节点。根据节点资源消耗数据,判断是否存在资源消耗异常的节点。节点C的CPU利用率和内存利用率都明显高于其他节点,可能存在资源消耗异常的节点。根据音乐文件完整性检查结果,判断是否存在完整性受到威胁的音乐文件。音乐文件3的校验和与原始校验和不一致,存在完整性受到威胁的音乐文件。根据音质分析结果,判断是否存在音质异常的音乐文件。音乐文件4的噪声水平非常高,存在音质异常的音乐文件。综合分析每个节点的响应时间、资源消耗状况、音乐文件完整性和音质,确定受到疑似异常请求影响或数据完整性受到威胁的云计算节点。根据节点B的响应时间异常高和音乐文件2的完整性检查结果通过,可以确定节点B受到疑似异常请求影响,并且音乐文件2的完整性可能受到威胁。
根据节点响应时间数据,对音乐数据进行异常值检测,识别疑似异常请求的模式或特征,确定受到疑似异常请求影响的云计算节点。例如节点响应时间的标准差作为特征。节点1响应时间标准差2.28ms,节点2响应时间标准差0.63ms、节点3响应时间标准差:1.10ms。采用3倍标准差法,根据节点响应时间的特征,判断疑似异常请求的模式或特征。使用3倍标准差法判断异常值。节点1异常请求,19ms,超过了平均响应时间12ms+3倍标准差2.28ms=18.84ms、节点2异常请求,无异常值、节点3异常请求,16ms,超过了平均响应时间12ms+3倍标准差1.10ms=15.3ms。对音乐数据进行异常值检测,确定异常请求,并确定受到影响的云计算节点。节点1和节点3有异常请求。根据节点响应时间数据,例如有3个节点,每个节点对音乐请求的响应时间如下,节点1,10ms,12ms,11ms,10ms,13ms、节点2,9ms,9ms,10ms,8ms,9ms、节点3,11ms,12ms,14ms,11ms,12ms。对节点响应时间数据进行时间序列处理,将其按照时间顺序进行排序,形成时间序列。时间序列数据,节点1,14ms,12ms,9ms,15ms,10ms、节点2,9ms,9ms,10ms,8ms,9ms、节点3,11ms,12ms,14ms,11ms,12ms。通过趋势分析对数据进行预处理和特征提取,计算每个节点的平均响应时间作为特征。节点1平均响应时间,(14+12+9+15+10)/5=12ms、节点2平均响应时间,(9+9+10+8+9)/5=9ms、节点3平均响应时间,(11+12+14+11+12)/5=12ms。根据时间序列数据,可以进一步提取统计特征,例如节点响应时间的标准差作为特征。节点1响应时间标准差2.28ms,节点2响应时间标准差0.63ms、节点3响应时间标准差:1.10ms。采用3倍标准差法,根据节点响应时间的特征,判断疑似异常请求的模式或特征。使用3倍标准差法判断异常值。节点1异常请求,19ms,超过了平均响应时间12ms+3倍标准差2.28ms=18.84ms、节点2异常请求,无异常值、节点3异常请求,16ms,超过了平均响应时间12ms+3倍标准差1.10ms=15.3ms。对音乐数据进行异常值检测,确定异常请求,并确定受到影响的云计算节点。节点1和节点3有异常请求。
S104、根据当前云计算节点数、节点健康状况以及服务器响应时间监测,动态调整云计算节点,优先处理真实有用的音乐播放请求,同时降低受到异常请求影响的节点数量。例如,通过系统监测工具Nagios,获取当前系统中有10个可用的云计算节点。监测工具显示第一个节点的运行状态和健康程度如下,CPU利用率,60%、内存利用率,70%、网络负载,50%;监测工具显示第二个节点的运行状态和健康程度如下,CPU利用率,80%、内存利用率,90%、网络负载,80%。监测工具显示服务器对请求的响应时间为200毫秒,即请求发送到服务器返回响应的时间间隔为200毫秒。根据用户认证、请求内容标识,判断请求是否为真实有用的音乐播放请求。如果请求的用户经过身份验证并且请求的内容是音乐文件,则可以判断该请求为真实有用的音乐播放请求。根据请求是否带有恶意请求、非法请求、重复请求标识,判断请求是否为异常请求。如果一个请求被标记为恶意请求,则可以判断该请求为异常请求。根据异常请求的影响范围,确定受到异常请求影响的节点数量。如果一个异常请求导致一个节点崩溃,则可以确定一个节点受到了异常请求的影响。根据节点健康状况和服务器响应时间,对云计算节点进行动态调整。如果节点健康状况良好且服务器响应时间为100毫秒,可以减少节点数量以提高系统的处理能力和性能。将节点数量减少到8个。如果节点健康状况不佳且服务器响应时间为500毫秒,可以增加节点数量降低系统负载。将节点数量增加到12个。将真实有用的音乐播放请求优先分配给可用的健康节点进行处理,以保证用户的体验。当有多个节点可用时,优先将音乐播放请求分配给健康状态良好的节点进行处理。对异常请求进行过滤或防御措施,以降低异常请求对节点的影响,从而减少受到异常请求影响的节点数量。使用防火墙来过滤恶意请求,或者采用请求限制机制来防止非法请求的频繁发生。
根据节点健康状况和服务器响应时间,动态调整云计算节点数量,提高系统的处理能力和性能。
根据监控系统获取节点健康状况,包括节点的CPU使用率、内存使用率、磁盘使用率。根据监控系统获取服务器响应时间,评估服务器的响应速度,包括请求的处理时间、网络延迟。采用加权轮询法,根据节点健康状况和服务器响应时间,进行节点数量的动态调整。根据阈值设定,通过比较节点健康状况和服务器响应时间的阈值,确定是否需要增加或减少节点数量。利用云计算平台提供的节点弹性伸缩功能,根据业务需求自动进行节点的增加或减少。结合业务属性,根据节点健康状况和服务器响应时间的实时数据,通过加权轮询法和节点弹性伸缩功能,实现动态节点调整。例如,有以下几个云计算节点,并且已经通过监控系统获取到了它们的健康状况和服务器响应时间的数据:节点1,CPU使用率30%、内存使用率50%、磁盘使用率20%、服务器响应时间100ms,节点2,CPU使用率50%、内存使用率80%、磁盘使用率70%、服务器响应时间150ms,节点3CPU使用率20%、内存使用率40%、磁盘使用率40%、服务器响应时间80ms。根据加权轮询法,根据节点的健康状况和服务器的响应时间来决定每个节点的权重。设定健康状况和响应时间的权重比例为2:1,得到以下计算结果,节点1的权重(0.3x2)+(100x1)=0.6+100=100.6,节点2的权重(0.5x2)+(150x1)=1+150=151,节点3的权重:(0.2x2)+(80x1)=0.4+80=80.4。根据权重结果,看到节点2具有最高的权重,说明它是最需要负载均衡的节点。因此,我们可以选择将更少的请求发送到节点2上,同时增加节点1和节点3上的请求。接下来,根据阈值设定,设置相应的阈值来判断节点的健康状况和服务器的响应时间是否超过预设阈值。如果CPU使用率和内存使用率超过80%,磁盘使用率超过90%,或者服务器响应时间超过200ms,判断节点健康状况和响应时间出现问题,需要进行节点数量调整。利用云计算平台提供的节点弹性伸缩功能,根据业务需求自动进行节点的增加或减少。如果节点2的权重持续高于其他节点,说明它的处理负载过重,自动增加一个新的节点分担负载。反之,如果节点1和节点3的权重持续较低,可以自动将其中一个节点进行缩减,以减少资源浪费。
根据请求来源、用户行为和用户位置,判断真实有用的音乐播放请求,分配健康网络节点。例如,根据请求来源,获取请求的授权信息。请求来源为应用程序A,获取到的授权信息为Token="ABCD1234"。通过与授权服务器进行验证,确认Token="ABCD1234"是一个合法且可信的授权信息。根据用户行为,包括用户的点击、收藏、分享数据,判断用户是否为真实用户。用户A点击应用程序B中的某个按钮,记录下该点击行为并分析用户行为模式,发现用户A的点击行为与真实用户的行为模式相符合,可以判定用户A为真实用户。根据用户位置信息,确定用户所在地理位置。用户A的设备提供了GPS信息,根据该信息确定用户A所在的地理位置为纬度(37°74′N,经度-12°41′E)。根据用户位置和网络节点候选列表中每个节点的地理位置,计算距离用户较近的节点。假如网络节点候选列表中有3个节点,其地理位置分别为节点1(纬度37°74′N,经度12°41′E),节点2(纬度37°75′N,经度-12°41′E),节点3(纬度37°73′N,经度-12°41′E),通过计算用户A与每个节点之间的距离,发现用户A距离节点1的距离最近。获取网络节点候选列表中每个节点的资源利用率,确定空闲资源较多的节点。节点1的资源利用率为30%,节点2的资源利用率为50%,节点3的资源利用率为20%。预设资源利用率为40%,节点1,节点3的空闲资源满足预设值。用户A发起了一个请求,经过判断和计算,发现用户A为真实用户且距离节点1最近,节点1的资源利用率满足预设值。因此,将用户A的请求分配给节点1。
根据检测到的疑似异常请求模式或特征,设计强化模块来应对异常请求,提高节点的处理能力。
根据节点的资源监测工具Nagios,获取节点的CPU利用率、内存使用量和网络带宽使用,判断当前资源利用率是否超过预设的阈值。如果资源利用率超过阈值,调整节点的资源分配,增加CPU、内存或网络带宽,得到调整后的节点资源分配情况。通过云节点服务监控系统Prometheus,获取当前请求的数量和请求处理时间,判断当前请求的数量和请求处理时间是否超过预设的阈值。如果超过阈值,进行负载均衡调度,将请求分发到负载低于预设值的节点上,得到调整后的节点负载情况。根据请求的特征,判断是否为频繁请求的静态资源,如果是频繁请求的静态资源,采用缓存技术将资源缓存到节点上。根据请求的特征,动态调整缓存策略,提高缓存的命中率,得到调整后的节点缓存策略。根据请求的增减情况,判断是否需要进行节点的弹性扩缩容。如果请求量增加,自动添加新节点来增加处理能力,如果请求量减少,自动释放多余的节点,减少资源的浪费,得到调整后的节点数量。根据检测到的异常请求模式或特征,判断是否为恶意请求。如果是恶意请求,采取相应的防护策略,包括IP封禁或限流,保护节点的正常运行,防止恶意请求对系统造成影响。例如,一个节点的CPU利用率为80%,内存使用量为6GB,网络带宽使用率为50%。预设的阈值为CPU利用率超过90%、内存使用量超过8GB、网络带宽使用率超过70%时进行调整。根据当前资源利用率情况,CPU利用率为80%,低于阈值,不需要调整。内存使用量为6GB,低于阈值,不需要调整。网络带宽使用率为50%,低于阈值,不需要调整。另一个节点的请求数量为1000个/秒,请求处理时间为10ms。预设的阈值为请求数量超过1500个/秒、请求处理时间超过15ms时进行负载均衡调度。根据当前请求情况,请求数量为1000个/秒,低于阈值,不需要调整。请求处理时间为10ms,低于阈值,不需要调整。有一个频繁请求的静态资源,需要缓存到节点上。根据请求特征,节点采用缓存技术将该静态资源缓存到内存中。根据请求特征和缓存策略,节点动态调整缓存策略,提高缓存的命中率。根据请求的访问频率和时间窗口,将经常访问的资源放在缓存中,并设置适当的过期时间。请求量增加,节点需要进行弹性扩容。自动添加新节点来增加处理能力。节点数量从10个增加到15个。检测到一个异常请求模式,恶意请求。采取IP封禁或限流的防护策略,防止恶意请求对系统造成影响。封禁恶意IP地址或限制恶意请求的访问频率。
S105、通过异常请求源地址追踪结合用户位置信息统计,确定异常请求的来源并进行阻断,同时确保真实用户的音乐播放不受影响。例如,通过网络日志或防火墙工具,获取每个请求的源IP地址。检测到一次请求的源IP地址为192.161.2.6。根据每个用户的IP地址,使用IP地理定位服务获取其位置信息,包括国家、城市和经纬度。通过IP地理定位服务,得知该IP地址对应的位置为中国北京,经纬度为39,42°N、114,74°E。通过在服务器端记录请求的时间和计数器记录每个请求的时间戳和请求频率,用于将异常请求与正常请求进行对比。记录了请求的时间戳为2021-01-01、10:00:00,并且该IP地址在过去一分钟内发送了10次请求,请求频率为10次/分钟。通过服务器端日志或请求头中的字段获取每个请求的类型,包括GET、POST、PUT,识别可能的攻击类型。从请求头中获得了该请求的类型为GET。解析请求头或参数来获取每个请求中的用户标识,包括用户ID和会话ID。从请求头中解析得到该请求的用户ID为123456和会话ID为7890ABCDEF.通过规则匹配来分析异常请求的行为特征,包括请求头中的异常字段、异常的请求参数或异常的请求路径,识别和区分异常请求。发现该请求的请求路径为非常规的路径,包含不存在的路径。根据异常请求的源地址、用户位置信息、请求时间戳、请求频率、请求类型、用户标识和异常请求行为特征的综合分析,确定异常请求的来源。根据综合分析,判断该请求来自中国北京地区,请求频率异常高,并且请求路径异常,没有有效的用户标识特征,判断为异常请求。对于确定为异常请求的来源,通过防火墙或访问控制列表,封禁源IP地址、限制请求频率或拒绝异常请求的访问。将该源IP地址192.161.2.6加入防火墙黑名单,限制该IP地址的请求频率或直接拒绝该异常请求的访问。在采取阻断措施时,通过优先级设置或白名单机制,确保真实用户的请求正常访问和播放音乐,确保真实用户的音乐播放不受影响。可以通过设置白名单,将已知的合法用户IP地址加入,确保他们的请求正常访问和音乐播放不受阻断影响。
S106、采用数据传输速率检测和网络连接稳定性分析,判断网络或服务器是否出现瓶颈,以及是否有必要对节点进行负载均衡。
通过监测网络带宽的利用率和传输延迟,得到网络的数据传输速率,如果数据传输速率低于预设速率或传输延迟高于预设延迟,表示网络或服务器出现瓶颈。对网络连接进行稳定性分析,包括检测网络连接的丢包率和稳定性,如果网络连接不稳定或存在大量丢包现象,进行负载均衡平衡服务器负载和提高网络连接的稳定性。监测服务器的负载,包括CPU利用率、内存利用率和磁盘IO指标,如果服务器负载高于预设负载率,导致性能下降和服务不可用,需要进行负载均衡。通过测量服务器的响应时间,包括请求到达服务器和服务器返回响应的时间,确定服务器的响应速度,如果响应时间高于预设时间,表示服务器出现瓶颈,需要进行负载均衡以提高响应速度。对网络流量进行分析,获取各个节点或服务器的负载,如果某个节点或服务器的流量大于预设流量,进行负载均衡以平衡负载。统计网络或服务器的故障率,如果故障率高于预设故障率,进行负载均衡提高系统的可用性和稳定性。获取网络或服务器的可扩展性,包括支持的最大连接数、最大带宽,如果网络或服务器无法满足当前业务需求,进行负载均衡来扩展系统的能力。例如,通过监测网络带宽的利用率和传输延迟,如果网络带宽利用率低于80%或传输延迟高于50毫秒,则表示网络出现瓶颈。对网络连接进行稳定性分析,检测网络连接的丢包率和稳定性,如果丢包率超过5%或网络连接不稳定,连接断断续续,需要进行负载均衡。监测服务器的负载情况,CPU利用率超过90%、内存利用率超过80%或磁盘IO超过1000次/秒,表示服务器负载过高,需要进行负载均衡。通过测量服务器的响应时间,请求到达服务器的时间为10毫秒,服务器返回响应的时间为50毫秒,判断服务器的响应速度,如果响应时间高于100毫秒,需要进行负载均衡以提高响应速度。对网络流量进行分析,某个节点或服务器的流量达到10GB/s,需要进行负载均衡以平衡负载。统计网络或服务器的故障率,网络中断每天发生2次、服务器宕机每周发生1次,如果故障率超过每天一次,需要进行负载均衡提高系统的可用性和稳定性。对网络或服务器的可扩展性进行评估,网络支持的最大连接数为1000个、最大带宽为100MB/s,如果网络或服务器无法满足当前业务需求,连接数超过1000个或带宽超过100MB/s,需要进行负载均衡来扩展系统能力。判断网络或服务器是否出现瓶颈,以及是否需要对节点进行负载均衡。
S107、通过计算资源分配策略和节点负载均衡机制,确保真实有用的音乐播放请求和其他正常业务得到更多的计算资源。
根据音乐播放请求的重要性和紧急程度,为其设置优先级。根据系统负载和业务需求,动态调整分配给音乐播放请求的计算资源的数量。监测节点的负载,通过收集节点的CPU使用率、内存占用,判断节点的负载,并根据负载动态调整资源分配。根据不同业务需求,确定根据负载调整资源分配的速度。采用加权轮询算法,将音乐播放请求分发到不同的节点。每个节点依次处理请求,确保计算资源均衡分配。定期监测节点的负载和可用性,通过心跳检测检查节点的健康状态,判断节点是否过载或发生故障,并及时调整请求的分发策略。根据节点的负载,采用自动化的横向扩展机制,动态地增加或减少节点的数量。当某个节点发生故障时,采用故障转移机制,将音乐播放请求转发到其他正常的节点。例如,将音乐播放请求设置为最高优先级,确保它们获得更多的计算资源。为音乐播放请求分配70%的计算资源,而其他业务只分配30%。根据系统负载和业务需求,动态调整分配给音乐播放请求的计算资源的数量。当系统负载高时,将更多的计算资源分配给音乐播放请求,分配90%的计算资源给音乐播放请求。监测节点的负载情况,通过收集节点的CPU使用率、内存占用等指标,判断节点的负载情况,并根据负载情况动态调整资源分配。当节点的CPU使用率超过80%,则将更多的计算资源分配给音乐播放请求。根据不同业务需求,确定根据负载情况调整资源分配的速度,以确保及时响应音乐播放请求。每个节点依次处理请求,确保计算资源能够均衡分配。每个节点依次处理10个音乐播放请求。定期监测节点的负载情况和可用性,通过定时发送心跳检测、检查节点的健康状态等方式,判断节点是否过载或发生故障,并及时调整请求的分发策略。每10秒发送一次心跳检测,如果节点未能及时响应,则将请求转发到其他节点。根据节点的负载情况,采用自动化的横向扩展机制,动态地增加或减少节点的数量,以确保资源分配的均衡和高效。当节点的CPU使用率超过90%,自动增加一个节点来分担负载。当某个节点发生故障时,采用故障转移机制,将音乐播放请求转发到其他正常的节点,以确保服务的连续性。当节点A发生故障时,将请求转发到节点B或节点C。
S108、结合音乐播放设备种类和用户账号安全性检测,对于受到威胁的账号或设备,提供额外的资源以确保播放流畅。
通过识别不同类型的音乐播放设备,包括智能手机、平板电脑、个人电脑、智能音箱,获取设备的功能和资源信息。引入账号锁定机制,在连续多次登录失败或检测到可疑活动时,自动锁定账号并发送通知给用户。实时检测用户账号和设备的异常行为,如果有异常活动,包括登录失败超过预设次数、异地登录、频繁更改设备,自动触发警报并要求用户重新验证身份或暂时冻结账号。搭建分布式服务器网络,如果部分服务器受到攻击或故障,将播放请求转移到其他服务器。通过LOF算法,检测用户与正常模式明显不同的行为,设定一个阈值来判断数据中的异常点,如果LOF得分超过阈值,则判定为异常行为。将受威胁用户常用的音乐内容存储在本地设备上,降低对服务器的依赖。通过预加载,在用户播放新的音乐时提前下载相应的音乐内容,减少加载时间。使用自适应比特率,在低网络带宽或网络不稳定时动态调整音乐的比特率。例如,可以通过识别设备的操作系统、处理器和内存等属性来确定设备的性能和兼容性。一个设备的处理器是4GHz的四核处理器,内存是4GB,操作系统是最新版本的iOS,那么可以得出该设备性能好,能够支持音乐播放。系统设置账号锁定机制,当用户连续5次登录失败时,系统会锁定账号,并发送一条通知告知用户账号已被锁定。系统实时检测到用户在不同地理位置进行登录,并且频繁更改设备,系统触发警报并要求用户重新验证身份。搭建了分布式服务器网络,当某个服务器受到攻击或故障时,系统会将用户的播放请求转移到其他可用的服务器。使用LOF算法来检测异常行为,设定阈值为2,当用户的行为LOF得分超过2时,系统将标记为异常行为。对于缓存技术和预加载技术,设备的本地存储容量为1GB,用户常用的音乐内容占用500MB的空间。当用户播放新的音乐时,预加载技术提前下载相应的音乐内容,每首歌曲的平均大小为10MB,系统预先下载3首新的音乐。这样,用户可以在播放新音乐时减少加载时间,并且播放流畅度更高。用户的网络带宽为1Mbps,根据网络条件,动态调整音乐的比特率。网络良好时,系统播放音乐的比特率至512kbps,播放音质较高的音乐,当网络带宽较低时,系统降低音乐的比特率至256kbps,以确保音乐的流畅播放。
根据设备的硬件和网络条件,选择音频编码、数据压缩算法和传输协议,获取经过优化的音乐数据,减少数据传输量,提高播放效率和流畅性。例如,有一个智能音箱设备,其处理能力有限,存储空间较小,并且使用Wi-Fi网络进行数据传输。根据这些硬件条件,需要选择适合设备的音频编码和数据压缩算法以及传输协议。对于音频编码算法,可以选择较低的编码效率但音质较高的算法,以保证音乐的质量。可以选择MP3格式作为音频编码算法,它具有较高的音质但相对较低的编码效率,适合设备的处理能力。对于数据压缩算法,由于存储空间有限,需要选择能够压缩数据量的算法。可以选择ZIP算法进行数据压缩,以减少存储空间的占用。对于传输协议,由于设备使用的是Wi-Fi网络,可以选择使用HTTP协议进行数据传输,这是一种常用的传输协议,能够在Wi-Fi环境下稳定传输数据。对于数据传输协议的选择,需要考虑设备的处理能力和网络条件。设备的处理能力较低,网络传输速率较慢,可以选择使用流媒体传输协议,如RTSP协议。这种协议可以将音频数据分成小片段进行传输,以提高播放效率和流畅性。综上所述,针对该智能音箱设备,选择使用MP3作为音频编码算法,ZIP作为数据压缩算法,HTTP作为传输协议,并根据设备的处理能力和网络条件选择使用流媒体传输协议。
S109、采用音乐播放请求数据量、真实请求与异常请求比例以及音乐播放请求优先级,进行综合判断,确保高优先级的音乐播放请求和其他重要业务得到优先响应。
根据业务需求和用户体验,定义不同请求的优先级规则,将音乐播放请求划分为高优先级,并将其他重要业务分配相应的优先级。对音乐播放请求中传输的音频文件进行数据量估算,根据文件大小评估音乐播放请求所需的传输带宽和处理时间。根据历史数据或实时数据对音乐播放请求中真实请求与异常请求的比例进行统计分析,提高真实请求的优先级。根据数据量属性和真实请求与异常请求比例,对音乐播放请求进行分类和优先级调整,确认音乐播放请求的优先级为高,而其他重要业务的优先级则根据业务需求进行调整,充分利用系统资源并满足不同请求的优先级需求。获取当前的网络状况、处理能力和实时性要求,对不同优先级的请求进行动态调度和分配资源,确保高优先级的音乐播放请求和其他重要业务得到及时响应和优化处理。通过监测当前的网络状况和可用带宽,判断是否满足音乐播放请求的需求,如果带宽和网络速度有限,优化文件压缩和传输方式。建立异常处理机制,包括错误提示和异常请求过滤,出现异常请求或处理错误时,及时给予用户反馈,并且自动过滤异常请求。例如,将音乐播放请求划分为高优先级,其他重要业务根据业务需求进行优先级调整,如中优先级和低优先级。通过对音乐播放请求中传输的音频文件进行数据量评估,假设音频文件大小为10MB,评估传输带宽为1Mbps。根据此评估,音乐播放请求所需的传输时间为80秒(传输时间=文件大小/传输带宽)。通过历史数据统计分析得知,音乐播放请求中真实请求与异常请求的比例为8:2。根据此比例,将真实请求的优先级提高为高优先级。根据数据量属性和真实请求与异常请求比例,对音乐播放请求进行分类和优先级调整。将音乐播放请求的优先级设置为高优先级,而其他重要业务的优先级根据业务需求进行相应的调整。综合考虑当前的网络状况、处理能力和实时性要求,进行动态优先级调度和资源分配。系统的处理能力能同时处理3个高优先级请求和5个其他重要业务请求,根据请求的优先级和系统处理能力,进行动态调度,确保高优先级的音乐播放请求和其他重要业务能够得到及时响应和优化处理。当前的带宽为10Mbps,可以满足音乐播放请求的需求。如带宽有限的情况下,可以优化文件压缩和传输方式,进一步提升音乐播放请求的处理效率和质量。建立异常处理机制,当出现异常请求或处理错误时,及时给予用户反馈并自动过滤异常请求。系统每天出现10个异常请求,系统能够在10秒内给予用户提示并过滤异常请求。
获取用户行为,根据用户行为判断用户身份,分配业务优先级。
根据用户的注册信息和登录状态,获取用户类型。通过用户的行为数据包括听歌记录、喜好标记、上传记录,判断用户的活跃程度和行为偏好。根据用户的活跃程度和行为偏好,确定用户的身份为普通用户、资深用户还是专业音乐人。根据用户的身份确定业务优先级和相关属性。根据普通用户的身份以及用户的听歌历史、喜好信息,为用户推荐相关音乐,获取热门歌曲、热门榜单内容,生成排行榜供用户浏览,通过分析用户的喜好和音乐类型,为其推荐适合的歌单。根据资深用户的身份以及用户的喜好、听歌习惯信息,定制个性化的歌单,提供高音质、无损音乐下载或播放选项,以满足其对音乐品质的要求,为其提供上传原创作品、与其他音乐人交流的平台。根据专业音乐人的身份,提供上传个人原创音乐并进行推广的平台,推广音乐人的作品,提供合作、演出机会信息,搭建专业音乐人社区平台。例如,根据用户的注册信息和登录状态,可以判断用户类型为普通用户、资深用户或专业音乐人。注册信息中包含用户的年龄和职业信息,登录状态包括最近一次登录时间。对于活跃程度的评估,可以通过用户的行为数据进行分析。听歌记录中包括用户每天听歌的时长,喜好标记包括用户标记的歌曲类型和喜欢的艺人,上传记录包括用户上传的原创音乐数量。用户A的注册信息显示其年龄为25岁,职业为学生,最近一次登录时间为昨天。用户A的行为数据显示,平均每天听歌时长为2小时,喜好标记中喜欢流行音乐和摇滚乐,上传记录中没有上传过原创音乐。根据用户A的活跃程度和行为偏好,可以确定其身份为普通用户。普通用户的业务优先级可能较低,相关属性可能包括推荐热门歌曲、生成排行榜供用户浏览,以及根据喜好和音乐类型为其推荐适合的歌单。假设用户B的注册信息显示其年龄为35岁,职业为音乐老师,最近一次登录时间为今天。用户B的行为数据显示,平均每天听歌时长为4小时,喜好标记中喜欢古典音乐和爵士乐,上传记录中有10首原创音乐。根据用户B的活跃程度和行为偏好,可以确定其身份为资深用户。资深用户可能对音乐品质有较高要求,相关属性可能包括定制个性化的歌单、提供高音质、无损音乐下载或播放选项,以及提供上传原创作品、与其他音乐人交流的平台。用户C的注册信息显示其年龄为28岁,职业为专业音乐制作人,最近一次登录时间为上周。用户C的行为数据显示,平均每天听歌时长为6小时,喜好标记中喜欢电子音乐和嘻哈音乐,上传记录中有50首原创音乐。根据用户C的活跃程度和行为偏好,可以确定其身份为专业音乐人。专业音乐人可能需要更多的推广和合作机会,相关属性可能包括提供上传个人原创音乐并进行推广的平台,提供合作、演出机会信息,以及搭建专业音乐人社区平台。
尽管上面已经示出和描述了本发明的实施例,可以理解的是,上述实施例是示例性的,不能理解为对本发明的限制,本领域的普通技术人员在本发明的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (10)

1.一种分布式云计算方法,其特征在于,所述方法包括:
根据音乐播放频率、播放时段分布和用户活跃度监测,获取音乐播放的主要热点时间以及出现的异常登录行为或异常播放行为;若各类音乐流派播放量发生大幅波动或存在疑似异常请求,通过异常请求流量统计和疑似异常请求特征,判断异常请求的影响范围;采用节点响应时间分析和节点资源消耗状况,结合音乐文件的完整性和音质,确定哪些云计算节点可能受到疑似异常请求的影响或数据完整性受到威胁;根据当前云计算节点数、节点健康状况以及服务器响应时间监测,动态调整云计算节点,优先处理真实有用的音乐播放请求,同时降低受到异常请求影响的节点数量;通过异常请求源地址追踪结合用户位置信息统计,确定异常请求的来源并进行阻断,同时确保真实用户的音乐播放不受影响;采用数据传输速率检测和网络连接稳定性分析,判断网络或服务器是否出现瓶颈,以及是否有必要对节点进行负载均衡;通过计算资源分配策略和节点负载均衡机制,确保真实有用的音乐播放请求和其他正常业务得到更多的计算资源;结合音乐播放设备种类和用户账号安全性检测,对于受到威胁的账号或设备,提供额外的资源以确保播放流畅;采用音乐播放请求数据量、真实请求与异常请求比例以及音乐播放请求优先级,进行综合判断,确保高优先级的音乐播放请求和其他重要业务得到优先响应;
所述采用数据传输速率检测和网络连接稳定性分析,判断网络或服务器是否出现瓶颈,以及是否有必要对节点进行负载均衡,具体包括:
通过监测网络带宽的利用率和传输延迟,得到网络的数据传输速率,如果数据传输速率低于预设速率或传输延迟高于预设延迟,表示网络或服务器出现瓶颈;对网络连接进行稳定性分析,包括检测网络连接的丢包率和稳定性,如果网络连接不稳定或存在大量丢包现象,进行负载均衡平衡服务器负载和提高网络连接的稳定性;监测服务器的负载,包括CPU利用率、内存利用率和磁盘IO指标,如果服务器负载高于预设负载率,导致性能下降和服务不可用,需要进行负载均衡;通过测量服务器的响应时间,包括请求到达服务器和服务器返回响应的时间,确定服务器的响应速度,如果响应时间高于预设时间,表示服务器出现瓶颈,需要进行负载均衡以提高响应速度;对网络流量进行分析,获取各个节点或服务器的负载,如果某个节点或服务器的流量大于预设流量,进行负载均衡以平衡负载;统计网络或服务器的故障率,如果故障率高于预设故障率,进行负载均衡提高系统的可用性和稳定性;获取网络或服务器的可扩展性,包括支持的最大连接数、最大带宽,如果网络或服务器无法满足当前业务需求,进行负载均衡来扩展系统的能力。
2.根据权利要求1所述的方法,其中,所述根据音乐播放频率、播放时段分布和用户活跃度监测,获取音乐播放的主要热点时间以及出现的异常登录行为或异常播放行为,包括:
统计用户的播放次数和播放时长,获得用户的活跃度;统计用户在早晨、下午和晚上的播放次数,确定用户的热点时间段;监测用户的登录IP地址和地点,判断异常登录行为;分析用户的播放行为和异常播放次数,判断异常播放行为。
3.根据权利要求1所述的方法,其中,所述若各类音乐流派播放量发生大幅波动或存在疑似异常请求,通过异常请求流量统计和疑似异常请求特征,判断异常请求的影响范围,包括:
获取各流派的异常请求数据和播放量;比较异常请求的播放量变化和正常请求的变化;统计异常请求的流量变化和正常请求的流量变化;分析异常请求的特征,包括访问频率、来源和时间;识别疑似异常请求的影响范围。
4.根据权利要求1所述的方法,其中,所述采用节点响应时间分析和节点资源消耗状况,结合音乐文件的完整性和音质,确定哪些云计算节点可能受到疑似异常请求的影响或数据完整性受到威胁,包括:
监测云计算节点的响应时间;检查每个节点的资源消耗,包括CPU利用率、内存利用率和网络带宽;对云节点上的音乐文件进行完整性检查,包括校验和或哈希值比对;对音乐文件进行音质分析,包括噪声和失真;综合分析节点响应时间、资源消耗、音乐文件完整性和音质,确定受影响的云计算节点。
5.根据权利要求1所述的方法,其中,所述根据当前云计算节点数、节点健康状况以及服务器响应时间监测,动态调整云计算节点,优先处理真实有用的音乐播放请求,同时降低受到异常请求影响的节点数量,包括:
通过Nagios获取云计算节点数量及其运行状态;获取服务器对请求的响应时间间隔;判断请求是否为真实有用的音乐播放请求和是否为异常请求;确定受到异常请求影响的节点数量;对云计算节点进行动态调整;将真实有用的音乐播放请求分配给健康节点;对异常请求进行过滤。
6.根据权利要求1所述的方法,其中,所述通过异常请求源地址追踪结合用户位置信息统计,确定异常请求的来源并进行阻断,同时确保真实用户的音乐播放不受影响,包括:
通过网络日志获取每个请求的源IP地址;使用IP地理定位服务获取其位置信息;记录每个请求的时间戳和请求频率;获取请求类型及用户标识;分析异常请求的行为特征;根据综合分析确定异常请求来源;对异常请求进行封禁;确保真实用户的请求正常访问。
7.根据权利要求1所述的方法,其中,所述通过计算资源分配策略和节点负载均衡机制,确保真实有用的音乐播放请求和其他正常业务得到更多的计算资源,包括:
为音乐播放请求设置优先级;动态调整分配给音乐播放请求的计算资源的数量;监测节点的负载,收集节点的CPU使用率和内存占用,判断节点的负载,并根据负载调整资源分配;确定根据负载调整资源分配的速度;将音乐播放请求分发到不同的节点;每个节点处理请求,定期监测节点的负载和可用性,检查节点的健康状态,并及时调整请求的分发策略;采用自动化的横向扩展机制,动态地增加或减少节点的数量;当节点发生故障时,将音乐播放请求转发到其他正常的节点。
8.根据权利要求1所述的方法,其中,所述结合音乐播放设备种类和用户账号安全性检测,对于受到威胁的账号或设备,提供额外的资源以确保播放流畅,包括:
识别不同类型的音乐播放设备,获取设备的功能和资源信息;在连续多次登录失败或检测到可疑活动时,锁定账号并通知用户;实时检测用户账号和设备的异常行为,触发警报并要求用户验证身份或冻结账号;建立分布式服务器网络,将播放请求转移到其他服务器;通过LOF算法,检测用户异常行为;将受威胁用户常用的音乐内容存储在本地设备上;在用户播放新的音乐时预加载相应的音乐内容;在低网络带宽时动态调整音乐的比特率;选择音频编码、数据压缩算法和传输协议,获取优化的音乐数据。
9.根据权利要求1所述的方法,其中,所述采用音乐播放请求数据量、真实请求与异常请求比例以及音乐播放请求优先级,进行综合判断,确保高优先级的音乐播放请求和其他重要业务得到优先响应,包括:
定义不同请求的优先级规则,将音乐播放请求划分为高优先级;对音乐播放请求中传输的音频文件进行数据量估算;对音乐播放请求中真实请求与异常请求的比例进行统计分析,提高真实请求的优先级;根据数据量属性和请求比例,对音乐播放请求进行优先级调整;获取当前的网络状况、处理能力,对不同优先级的请求进行动态调度和分配资源;通过监测网络状况和可用带宽,判断请求的需求,优化文件压缩和传输方式;建立异常处理机制,包括错误提示和异常请求过滤;获取用户行为,判断用户身份,分配业务优先级。
10.一种分布式云计算系统,其特征在于,所述系统包括:
音乐播放监测与异常检测模块,用于根据音乐播放频率、播放时段分布和用户活跃度监测,获取音乐播放的主要热点时间以及出现的异常登录行为或异常播放行为;
异常流量分析与影响评估模块,用于若各类音乐流派播放量发生大幅波动或存在疑似异常请求,通过异常请求流量统计和疑似异常请求特征,判断异常请求的影响范围;
云计算节点安全监测模块,用于采用节点响应时间分析和节点资源消耗状况,结合音乐文件的完整性和音质,确定哪些云计算节点可能受到疑似异常请求的影响或数据完整性受到威胁;
动态节点调度模块,用于根据当前云计算节点数、节点健康状况以及服务器响应时间监测,动态调整云计算节点,优先处理真实有用的音乐播放请求,同时降低受到异常请求影响的节点数量;
异常请求追踪与阻断模块,用于通过异常请求源地址追踪结合用户位置信息统计,确定异常请求的来源并进行阻断,同时确保真实用户的音乐播放不受影响;
资源调度优化模块,用于通过计算资源分配策略和节点负载均衡机制,确保真实有用的音乐播放请求和其他正常业务得到更多的计算资源;
安全播放模块,用于结合音乐播放设备种类和用户账号安全性检测,对于受到威胁的账号或设备,提供额外的资源以确保播放流畅;
播放请求管理模块,用于采用音乐播放请求数据量、真实请求与异常请求比例以及音乐播放请求优先级,进行综合判断,确保高优先级的音乐播放请求和其他重要业务得到优先响应。
CN202311289680.9A 2023-10-08 2023-10-08 一种分布式云计算的方法及系统 Active CN117041233B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311289680.9A CN117041233B (zh) 2023-10-08 2023-10-08 一种分布式云计算的方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311289680.9A CN117041233B (zh) 2023-10-08 2023-10-08 一种分布式云计算的方法及系统

Publications (2)

Publication Number Publication Date
CN117041233A CN117041233A (zh) 2023-11-10
CN117041233B true CN117041233B (zh) 2024-04-09

Family

ID=88630349

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311289680.9A Active CN117041233B (zh) 2023-10-08 2023-10-08 一种分布式云计算的方法及系统

Country Status (1)

Country Link
CN (1) CN117041233B (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117560700B (zh) * 2024-01-12 2024-03-29 深圳市芯科云科技有限公司 一种基于智能设备监控网络数据的控制方法及系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103327016A (zh) * 2013-06-06 2013-09-25 合一信息技术(北京)有限公司 一种计算网络流媒体异常播放量并对其修正的方法及系统
CN114756698A (zh) * 2022-04-18 2022-07-15 腾讯音乐娱乐科技(深圳)有限公司 一种播放行为检测方法、设备及存储介质
CN116159310A (zh) * 2023-01-29 2023-05-26 腾讯科技(深圳)有限公司 数据处理方法、装置、电子设备以及存储介质

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180285893A1 (en) * 2017-03-31 2018-10-04 International Business Machines Corporation Determining music to influence customer behavior

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103327016A (zh) * 2013-06-06 2013-09-25 合一信息技术(北京)有限公司 一种计算网络流媒体异常播放量并对其修正的方法及系统
CN114756698A (zh) * 2022-04-18 2022-07-15 腾讯音乐娱乐科技(深圳)有限公司 一种播放行为检测方法、设备及存储介质
CN116159310A (zh) * 2023-01-29 2023-05-26 腾讯科技(深圳)有限公司 数据处理方法、装置、电子设备以及存储介质

Also Published As

Publication number Publication date
CN117041233A (zh) 2023-11-10

Similar Documents

Publication Publication Date Title
US11641343B2 (en) Methods and systems for API proxy based adaptive security
US7805529B2 (en) Method and system for dynamically changing user session behavior based on user and/or group classification in response to application server demand
CN1921479B (zh) 一种流媒体系统负荷分担方法及其系统
JP6790169B2 (ja) 繰り返されるライセンス更新によるメディアセッション同時性管理のためのシステム、方法およびコンピュータプログラム
US9781012B2 (en) Behavior monitoring and compliance for multi-tenant resources
US8626910B1 (en) Systems and methods for performing localized server-side monitoring in a content delivery network
US8635345B2 (en) Network scoring system and method
JP4002584B2 (ja) ストリーミング・データの送信及びダウンロード方法
CN117041233B (zh) 一种分布式云计算的方法及系统
EP3488559B1 (en) Network attack defense system and method
US20090180377A1 (en) Adaptive Edge-Implemented Traffic Policy in a Data Processing Network
KR20060057525A (ko) 데이터 제공자를 선택하는 시스템 및 방법
KR20090094292A (ko) 파일 데이터 분배 방법, 디바이스, 및 시스템
WO2001097557A1 (en) Dynamic bandwidth allocation
US20140259140A1 (en) Using learned flow reputation as a heuristic to control deep packet inspection under load
CN110771122A (zh) 使内容传送网络能够处理非预期流量激增的方法和网络节点
US20090150564A1 (en) Per-user bandwidth availability
US11368550B2 (en) Systems and methods for entity aware allocation of electronic resources
US8583819B2 (en) System and method for controlling server usage in peer-to-peer (P2P) based streaming service
Yoshida Dynamic CDN against flash crowds
AU2007351385B2 (en) Detecting and interdicting fraudulent activity on a network
KR101328351B1 (ko) 퍼지 로직을 기반으로 하는 트래픽의 대역폭을 제어하는 방법 및 시스템
Kim et al. PECAN: Peer cache adaptation for peer-to-peer video-on-demand streaming
US20240022583A1 (en) Data Collection Management
Daghistani et al. Guard: Attack-Resilient Adaptive Load Balancing in Distributed Streaming Systems

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant