求信息的次数，或者某一个客户端在预定时间内发送重复请求信息的次数。其中，接收地址可以为数字接收地址(例如电话号码、即时通讯账号号码等)或者文字接收地址(例如网络邮箱地址)。
[0035]作为一个可选实施例，当根据重复请求数量，判断发送信道存在或有可能存在故障时，系统切换用于发送数据信息的通道。
[0036]作为一个可选实施例，根据接收到的重复请求信息确定接收地址。根据历史记录，判断具有相同接收地址的客户端在连续发送重复请求信息时，使用不同的信道项客户端发送数据信息，以避免某一条发送信息的通道发生故障而导致的发送数据信息不成功。
[0037]作为一个可选实施例，步骤S15计算在预定时间内与信道对应的重复请求信息的重复请求数量可以包括:
[0038]步骤S151，从重复请求信息的历史记录中，确定与每条重复请求记录对应的用于接收数据信息的接收地址。
[0039]步骤S153，根据历史记录，确定与重复请求记录对应的发送数据信息的发送信道。
[0040]步骤S155，根据接收地址和历史记录，按获取到重复请求信息的时间生成重复请求记录与发送信道的对照表。
[0041]步骤S157，根据对照表，确定在预定时间内与发送信道对应的重复请求数量。
[0042]在每次获取到重复请求信息后，便将该条重复请求信息添加至历史记录当中。通过上述步骤S151至步骤S157，从重复请求历史记录中，确定与每条重复请求信息对应的接收地址。根据历史记录中的每条重复请求记录接收时间和与所述重复请求记录对应的发送信道，统计确定在预定时间内与发送信道对应的重复请求数量。
[0043]作为一个可选实施例，步骤S17根据重复请求数量，判断发送信道是否存在故障包括:
[0044]步骤S171，获取预先设置的计算系数和预先设置的判断阈值。
[0045]步骤S173，根据计算系数和重复请求数量，计算与发送信道对应的计算值。
[0046]步骤S175，将计算值与判断阈值进行比对，判断发送信道是否存在故障。
[0047]通过上述步骤S171至步骤S175，获取重复请求数量与计算系数，并对发送信道做加权运算。当通过加权运算计算得到的计算值小于预先设置的判断阈值时，确定该发送信道存在故障。
[0048]作为一个可选实施例，重复请求数量包括连续重复数量和非连续重复数量，其中，在步骤S157根据对照表，确定在预定时间内与发送信道对应的重复请求数量之后，步骤S15还包括:
[0049]步骤S158，根据对照表，计算得出在预定时间内与接收地址对应的连续重复数量。
[0050]步骤S159，根据重复请求数量和连续重复数量，计算得出非连续重复数量。
[0051]通过上述步骤S158至步骤S159，进一步的根据重复请求记录与发送信道的对照表，确定在预定时间内获取到的具有相同接收地址的重复请求记录得连续重复数量和非连续重复数量。通过对连续重复数量和非连续重复数量赋予不同的权重系数，来更加精确的通过加权运算计算出发送信道的计算值。
[0052]作为一个可选实施例，步骤S17根据重复请求数量，判断发送信道是否存在故障，可以包括:
[0053]步骤S171，获取预先设置的第一计算系数、第二计算系数和判断阈值。
[0054]步骤S173，根据第一计算系数和连续重复数量，计算发送信道的第一计算值。
[0055]步骤S175，根据第二计算系数和非连续重复数量，计算发送信道的第二计算值。
[0056]步骤S177，根据第一计算值和第二计算值，计算与发送信道对应的计算值。
[0057]步骤S179，将计算值与判断阈值进行比对，判断发送信道是否存在故障。
[0058]通过上述步骤S171至步骤S179，获取分别与连续重复数量和非连续重复数量对应的第一计算系数和第二计算系数。通过将连续重复数量与第一计算系数、费连续重复数量与第二计算系数进行加权计算，得出与发送信道对应的计算值。通过将计算值判断该发送信道是否存在故障。
[0059]作为一个可选实施例，当在预定时间内获取到与发送信道对应的重复发送请求超过次数阈值时，在下一次获取到重复发送请求时，开始对发送信道做加权运算，以判断该发送信道是否存在故障。
[0060]作为一个可选实施例，可以设置预定时间为5分钟，次数阈值为3次。设置发送信道的初始计算值为100。每当该发送信道的连续重复数量加I时，将计算值减去2分；每当该发送信道的非连续重复数量加I时，将计算值减去I分。如果当计算值低于60分时，确定该发送信道发生故障或者该发送信道具有潜在故障。
[0061]作为一个可选实施例，如图2所示，在步骤S17在根据重复请求数量，判断发送信道是否存在故障之后，方法还可以包括:
[0062]步骤S19，当确定发送信道存在故障时，发送报警信息。
[0063]通过步骤S19，当发送信道存在故障时，可以讲警报信息及时的发送至开发人员或者运维人员处，使发送信道可以及时被修复或者屏蔽，从而提高数据信息的发送成功率。
[0064]实施例2
[0065]本发明实施例还提供了一种信道故障的预警装置，如图3所示，该装置可以包括:获取模块21、确定模块23、计算模块25和判断模块27。
[0066]其中，获取模块21，用于获取重复请求信息，其中，重复请求信息，用于根据重复请求信息重新发送数据信息；确定模块23，用于根据重复请求信息，确定与重复请求信息对应的用于发送数据信息的发送信道，信道为发送数据信息的通道；计算模块25，用于计算在预定时间内与发送信道对应的重复请求信息的重复请求数量；判断模块27，用于根据重复请求数量，判断发送信道是否存在故障。
[0067]通过上述获取模块21、确定模块23、计算模块25和判断模块27，通过接收客户端发送的重复请求信息，确定之前向发送重复请求信息的客户端发送数据信息所使用的发送通道，通过计算在预定时间内获取到的与发送数据信息的通道对应的重复请求信息的数量，来判断该信道是否存在故障。利用上述实施例，实现了通过重复请求信息来对信道故障进行预警的效果，达到了对信道的工作状态进行监控的目的，从而解决了现有技术中因无法对用于发送验证信息的线路的故障进行预警，导致在线路故障时影响网络账号正常使用的问题。
[0068]作为一个可选实施例，上述计算模块25包括:第一子确定模块251、第二子确定模块253、第一子获取模块255和第三子确定模块257。
[0069]其中，第一子确定模块251，用于从重复请求信息的历史记录中，确定与每条重复请求记录对应的用于接收数据信息的接收地址；第二子确定模块253，用于根据历史记录，确定与重复请求记录对应的发送数据信息的发送信道；第一子获取模块255，用于根据接收地址和历史记录，按获取到重复请求信息的时间生成重复请求记录与发送信道的对照表；第三子确定模块257，用于根据对照表，确定在预定时间内与发送信道对应的重复请求数量。
[0070]在每次获取到重复请求信息后，便将该条重复请求信息添加至历史记录当中。通过上述第一子确定模块251、第二子确定模块253、第一子获取模块255和第三子确定模块257，从重复请求历史记录中，确定与每条重复请求信息对应的接收地址。根据历史记录中的每条重复请求记录接收时间和与所述重复请求记录对应的发送信道，统计确定在预定时间内与发送信道对应的重复请求数量。
[0071]作为一个可选实施例，上述判断模块27包括:第二子获取模块271、子处理模块273和子判断模块275。
[0072]其中，第二子获取模块271，用于获取预先设置的计算系数和预先设置的判断阈值；子处理模块273，用于根据计算系数和重复请求数量，计算与发送信道对应的计算值；子判断模块275，用于将计算值与判断阈值进行比对，判断发送信道是否存在故障。
[0073]通过上述第二子获取模块271、子处理模块273和子判断模块275，获取重复请求数量与计算系数，并对发送信道做加权运算。当通过加权运算计算得到的计算值小于预先设置的判断阈值时，确定该发送信道存在故障。
[0074]作为一个可选实施例，重复请求数量可以包括连续重复数量和非连续重复数量，上述判断模块27还可以执行如下步骤:
[0075]步骤1，根据对照表，计算得出在预定时间内与接收地址对应的连续重复数量。
[0076]步骤2，根据重复请求数量和连续重复数量，计算得出非连续重复数量。
[0077]通过上述步骤进一步的根据重复请求记录与发送信道的对照表，确定在预定时间内获取到的具有相同接收地址的重复请求记录得连续重复数量和非连续重复数量。通过对连续重复数量和非连续重复数量赋予不同的权重系数，来更加精确的通过加权运算计算出发送信道的计算值。
[0078]