端启用异步轮询通彳目方式，以使得请求端 通过轮询获取对请求消息的响应结果。
[0036] 若在上述步骤202中判断出响应时间超出时长阈值，说明接收端需要花费较长的 时间才能对请求消息做出响应。此时，如果请求端还要等待响应结果而无法执行其他操作， 则会对接收端和请求端之间的通信资源造成极大浪费。为了避免这种不必要的浪费，可以 将二者之间的通信方式由之前的同步转为异步。具体地，可以由接收端去通知请求端启动 异步轮询的通信方式。当请求端接收到该通知后，可以停止当前的等待，并去执行其他可能 需要的操作。然后以一定的时间间隔对接收端进行轮询，也就是每隔一段时间去接收端上 确认是否有响应结果产生。一旦在轮询中发现接收端对上述请求信息做出了响应，则可以 进一步从接收端上获取响应结果。可选地，请求端进行轮询的时间间隔可以是预先设置好 的，其具体数值可以根据历史经验数据或实际的应用需求来确定。
[0037] 本申请上述实施例提供的信息传输方法，能够首先通过同步通信方式发送请求信 息，若同步响应超时，则可以通过异步轮询的方式获取对请求消息的响应结果。在优先使用 同步通信方式时，若接收端能够快速对请求消息做出响应，则在保证通信速度的同时避免 了对系统内存的损耗。而在接收端对请求消息的响应超时时，可以转到异步通信方式，从而 避免因为长时间的等待增加整个系统的时延。通过将同步通信方式和异步通信方式组合， 可以最大化地提高通信效率，并减少对系统资源的损耗。
[0038] 进一步参考图3,其示出了根据本申请另一个实施例的消息传输方法的示例性流 程图。
[0039] 如图3所示，在步骤301中，接收请求端通过同步通信方式发送的请求消息。
[0040] 在步骤302中，判断对请求消息的响应时间是否超出时长阈值。
[0041] 在步骤303中，若是，则通知请求端启用异步轮询通信方式，以使得请求端通过轮 询获取对请求消息的响应结果。
[0042] 本实施例中的步骤301至303与图2中的步骤201至203相同，在此不再赘述。
[0043] 在步骤304中，获取对多个历史请求消息响应时的响应记录，响应记录包括每个 历史请求消息的消息类型和响应时间。
[0044] 当接收端对接收到的请求信息进行响应时，会同时保存一个响应日志信息，用于 记录与每个请求信息相关的数据。通常在响应日志信息中可以保存有请求消息的类型、请 求包大小、请求端的ID、发起请求的时间、响应时间以及与请求业务相关的各类信息等。当 获取对多个历史请求消息响应时的响应记录时，可以从响应日志信息中抽取需要的信息， 即每个历史请求消息的消息类型和响应时间。
[0045] 继而，在步骤305中，根据响应记录，确定每个消息类型所对应的同步超时时长。
[0046] 在从上述步骤304中获得到响应记录后，可以首先将所有的历史请求消息按照消 息类型进行分类。然后可以得到在一个消息类型中所包括的全部响应时间，最后通过对这 些响应时间进行统计分析确定出该消息类型的同步超时时长。例如，可以将全部响应时间 的平均值作为同步超时时长。
[0047] 在本实施例的一个可选实现方式中，确定同步超时时长的步骤可以包括：分别确 定每个消息类型所对应的所有响应时间的多个分位值；将多个分位值中的最小值确定为相 应消息类型的同步超时时长。在本实施例中，在得到在一个消息类型中所包括的全部响应 时间之后，可以首先确定出这些响应时间的多个分位值。分位值是一种统计学概念，如果有 100个数，按从小到大排列，排在第10个的即为10分位值，排在第50个即为50分位值，也 叫中位值。由于分位值不会因为个别极端的数字而引起偏离，因此比起平均值其更能说明 排列规律。具体到本实施例中，可以将所有响应时间按照从小到大的顺序排序，然后去获取 多个分位值，例如50、70和90分位值。最后可以将这多个分位值中的最小值确定为本消息 类型的同步超时时长。可选地，还可以确定当前通信网络的延时情况，并基于延时对同步超 时时长进行修正，以获得更精确的同步超时时长。
[0048] 之后，在步骤306中，基于同步超时时长，对时长阈值进行更新。
[0049] 当在上述步骤305中确定出每个消息类型所对应的同步超时时长后，可以进一步 对上述步骤302中的时长阈值进行更新。具体地，如果之前的时长阈值对所有的消息类型 都是一个固定值，则更新后的时长阈值针对每个消息类型都规定了不同的同步超时时长。 如果之前的时长阈值已经针对每个消息类型都规定了不同的同步超时时长，则可以按照每 个消息类型对各自的时长阈值进行更新。
[0050] 在对时长阈值进行更新后，如果再次执行上述步骤302,则可以首先确定出请求消 息的消息类型，然后在判断对该请求消息的响应时间是否超出该消息类型所对应的时长阈 值。通过按照请求消息的类型来确定相应的同步超时时长，可以提高同步超时判断的准确 度。
[0051 ] 可选地，本实施例中的消息传输方法还可以确定进行轮询时的时间间隔。具体 地：
[0052] 在步骤307中，根据响应记录，确定每一个消息类型所对应的异步轮询的时间间 隔。
[0053] 在从上述步骤304中获得到响应记录后，可以首先将所有的历史请求消息按照消 息类型进行分类。然后可以得到在一个消息类型中所包括的全部响应时间，最后通过对这 些响应时间进行统计分析确定出该消息类型所对应的异步轮询的时间间隔。例如，可以将 全部响应时间的平均值作为异步轮询的时间间隔。
[0054] 在本实施例的一个可选实现方式中，确定异步轮询的时间间隔的步骤可以包括： 分别对每个消息类型中的所有历史请求消息，按照响应时间进行分组；基于每组中历史请 求消息的数量，确定每一个消息类型所对应的异步轮询的时间间隔。在本实施例中，在得到 在一个消息类型中所包括的全部历史请求消息后，可以首先按照响应时间的长短将所有历 史请求消息分为多个组，然后统计每个组中历史请求消息的数量，最后根据数量最多的一 个或多个组所对应的响应时间来确定异步轮询的时间间隔。当根据一个组所对应的响应时 间来确定异步轮询的时间间隔时，得到的时间间隔可以是一个固定的值。而当根据多个组 所对应的响应时间来确定异步轮询的时间间隔时，得到的时间间隔可以是一个时间序列。
[0055] 为了便于理解，下面以一个具体例子进行说明。对某一个消息类型中的所有历史 请求消息按照响应时间进行分组，可以得到如下表所示的分组结果。
[0057] 在这个例子中，按照IOOms的时间间隔来划分响应时间，并使用数量占比来描述 每个分组中历史请求消息的数量。其中，数量占比是指一个响应时间范围内的消息数量占 全部消息数量的比例。在确定异步轮询的时间间隔时，如果按照数量最多的组即100-200ms 这一组来确定，则可以将200ms确定为时间间隔。而如果按照数量最多的两组即100-200ms 和200_300ms这两组来确定，则可以将200ms、IOOms的时间序列确定为时间间隔。这样，第 一次在200ms时轮询，可以覆盖100-200ms的范围。第二次在相隔IOOms时轮询，相当于在 第一次的200ms上增加了 100ms，则可以覆盖200-300ms的范围。可选地，在确定轮询的时 间序列时，可以剔除那些数量占比小于一定比例（例如20%)的分组。
[0058] 之后，在步骤308中，将时间间隔发送给请求端，以使得请求端根据时间间隔进行 轮询。
[0059] 在确定出异步轮询的时间间隔后，接收端可以进一步将该时间间隔发送给请求 端，以使得请求端能够根据时间间隔进行轮询。由于在本实施例中的时间间隔是与消息类 型相对应的，因此在一种可能的实现中，接收端可以先确定请求端所发送的请求消息的消 息类型，然后再将与该消息类型对应的时间间隔发给请求端。在另一种可能的实现中，接收 端还可以将所有消息类型对应的时间间隔都发送给请求端，然后由请求端根据自己所发送 的消息类型，选择相应的时间间隔进行轮询。
[0060] 在本实施例的一个可选实现方式中，接收端还可以按照一定的时间频率（例如，1 次/小时）去获取对多个历史请求消息响应时的响应记录，并在每次获取后都执行上述用 于更新时长阈值和确定异步轮询的时间间隔的步骤。从而能够实现对同步超时时长和异步 轮询的时间间隔的实时动态调整。
[0061] 与图2中的消息传输方法相比，本实施例在将同步通信方式和异步通信方式结合 的基础上，还可以进一步基于对历史消息的响应