贵金属报价系统及报价方法

摘要

本申请涉及一种贵金属报价系统及报价方法。其中，所述系统包括和客户端；服务器通过从至少两个报价源获取原始数据并对原始数据进行处理得到报价数据，可以确保得到的报价数据的准确性；此外，客户端与服务器之间基于WebSocket推送和Http请求两种方式的接口进行数据交互，且在通过WebSocket推送方式进行数据交互时，由客户端定时发起心跳，从而实现在出现网络异常等异常情况时及时向用户发出提示，确保客户端与服务器的正常连接，进而确保客户端展示的报价数据的实时性，消除网络异常给报价系统带来的安全隐患。

说明书

技术领域

本申请涉及互联网技术领域，尤其涉及一种贵金属报价系统及报价方法。

背景技术

贵金属买卖业务是互联网科技公司向客户提供的重要金融产品，产品需要一个价格，但科技公司自身很难给出一个合理的定价，目前市场上的做法是参考上金所或国际交易所等的交易价格，再根据自身风险控制能力和当地市场情况等，加上一定的点差，向客户提供报价。

贵金属报价系统本身稳定性非常重要，现有的系统一般通过接收一个外部市场报价，对数据进行加工后，提供给其他系统使用。当外部报价源出现问题或报价源出现不正常的波动或系统本身出现故障，都将停止报价或者报价错误，给公司经济效益和名誉带来严重影响。

现有技术一般都采用一个报价源进行数据加工，由于国际市场上贵金属报价的影响因素是实时变动的，通过一个报价源不能判断出报价变化是正常的还是系统出现了问题，也即不能保证报价信息的准确性。

另外，现有技术的客户端接收报价时若出现网络异常，会导致报价系统无法正常工作，给报价系统的安全性带来隐患。

发明内容

本申请提供一种贵金属报价系统及报价方法，以解决现有报价系统不能保证报价信息的准确性，以及客户端在接收报价时若出现网络异常，会导致报价系统无法正常工作，给报价系统的安全性带来隐患的问题。

本申请的上述目的是通过以下技术方案实现的：

第一方面，本申请实施例提供一种贵金属报价系统，其包括：服务器和客户端；

所述服务器用于，从至少两个针对贵金属的报价源获取原始数据，以及对获取的原始数据进行处理得到报价数据，并存储所述报价数据；

所述客户端用于，基于WebSocket推送和Http请求两种方式的接口从所述服务器获取所述报价数据，并以图表的形式展示获取的报价数据；

其中，所述客户端在通过WebSocket推送方式与所述服务器建立连接后，定时向所述服务器发起心跳，所述服务器在每次接收到心跳后，在设定时间内若未再次接收到同一客户端发起的心跳，则断开与该客户端的WebSocket链接；所述客户端在向所述服务器发起心跳后能够获取到是否发送成功的回调状态，并在单次发送失败时向用户进行弱提示，在连续多次发送失败时向用户进行强提示；所述弱提示和所述强提示均用于提示用户检查网络状态。

可选的，所述报价数据包括历史报价数据和实时报价数据，所述历史报价数据和所述实时报价数据均包括金额和时间戳数据；

所述客户端通过WebSocket推送方式与所述服务器建立连接后，通过Http请求方式从所述服务器获取所述历史报价数据并进行展示，以及，通过WebSocket推送方式接收所述服务器发送的实时报价数据并进行展示。

可选的，所述客户端通过Http请求方式从所述服务器获取所述历史报价数据并进行展示时，具体用于：

在展示界面加载时，通过接口按预设的时间需求获取所述服务器处理完毕并按不同周期存储在内存中的数据列，通过金额、时间戳格式化校验后输入至图表中进行展示。

可选的，所述客户端在通过WebSocket推送方式接收所述服务器发送的实时报价数据并进行展示时，具体用于：

使用指定ID通过WebSocket接口接入所述服务器，开始接收所述实时报价数据，由所述服务器在每当有交易发生或金额变化时向所述客户端推送新的单列数据，所述客户端通过金额、时间戳格式化校验后添加至图表中进行展示。

可选的，所述客户端定时向所述服务器发起心跳包括：通过WebSocket链接定时向所述服务器发送自身的标识码。

可选的，所述服务器在获取到原始数据并对所述原始数据进行处理得到所述历史报价数据时，具体用于：

根据网络状况或所述客户端的展示需求，对原始数据进行基于预设规则的分割，从而由秒级数据计算提供出分钟级数据，以使所述客户端能够先进行基本走势的展示并在此之后根据用户的操作获取并展示对应的详细数据；其中，所述预设规则包括时间段规则和数据长度规则。

可选的，所述服务器中预设有针对所述报价数据的基准值、上浮动值和下浮动值；

所述服务器发送所述实时报价数据时，若待发送的实时报价数据大于所述基准值与所述上浮动值之和时，或者，小于所述基准值与所述下浮动值之和时，确定报价异常；报价异常时，所述客户端采用所述基准值作为实时报价数据进行展示。

可选的，所述服务器在报价异常时向预设的终端发送提示信息，且若在报价异常时获取到自定义报价，则将所述自定义报价发送至所述客户端，所述客户端采用所述自定义报价作为实时报价数据进行展示。

可选的，所述客户端在获取到所述实时报价数据时，对获取到的实时报价数据进行分析，通过模板引擎的模式实时输出在展示界面中，从而最低延时的展示当前交易情况,包括展示交易量和展示五档买卖。

第二方面，本申请实施例还提供一种贵金属报价方法，其特征在于，应用于第一方面任一项所述的系统，所述方法包括：

所述服务器从至少两个针对贵金属的报价源获取原始数据，以及对获取的原始数据进行处理得到报价数据，并存储所述报价数据；

所述客户端基于WebSocket推送和Http请求两种方式的接口从所述服务器获取所述报价数据，并以图表的形式展示获取的报价数据；

其中，所述客户端在通过WebSocket推送方式与所述服务器建立连接后，定时向所述服务器发起心跳，所述服务器在每次接收到心跳后，在设定时间内若未再次接收到同一客户端发起的心跳，则断开与该客户端的WebSocket链接；所述客户端在向所述服务器发起心跳后能够获取到是否发送成功的回调状态，并在单次发送失败时向用户进行弱提示，在连续多次发送失败时向用户进行强提示；所述弱提示和所述强提示均用于提示用户检查网络状态。

本申请的实施例提供的技术方案可以包括以下有益效果：

本申请的实施例提供的技术方案中，提供一种贵金属报价系统及方法，其中系统包括服务器和客户端，服务器通过从至少两个报价源获取原始数据并对原始数据进行处理得到报价数据，可以确保得到的报价数据的准确性；此外，客户端与服务器之间基于WebSocket推送和Http请求两种方式的接口进行数据交互，且在通过WebSocket推送方式进行数据交互时，由客户端定时发起心跳，从而实现在出现网络异常等异常情况时及时向用户发出提示，确保客户端与服务器的正常连接，进而确保客户端展示的报价数据的实时性，消除网络异常给报价系统带来的安全隐患。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1为本申请实施例提供的一种贵金属报价系统的交互过程示意图；

图2为本申请实施例提供的一种贵金属报价方法的流程示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

为了解决背景技术中提到的问题，也即现有报价系统不能保证报价信息的准确性，以及客户端在接收报价时若出现网络异常则存在安全隐患的问题，本申请提供一种贵金属报价系统及报价方法。以下通过实施例进行详细说明。

实施例

参照图1，图1为本申请实施例提供的一种贵金属报价系统的交互过程示意图。如图1所示，该报价系统主要包括服务器和客户端(图1中仅示出了一个客户端，但应当理解的是，实际应用中，客户端的数量一般为多个，同理，图1中所示的服务器也可以是由多台服务器组成)；

服务器用于，从至少两个针对贵金属的报价源获取原始数据，以及对获取的原始数据进行处理得到报价数据，并存储报价数据；

客户端用于，基于WebSocket推送和Http请求两种方式的接口从服务器获取报价数据，并以图表的形式展示获取的报价数据；

其中，客户端在通过WebSocket推送方式与服务器建立连接后，定时向服务器发起心跳，服务器在每次接收到心跳后，在设定时间内若未再次接收到同一客户端发起的心跳，则断开与该客户端的WebSocket链接；客户端在向服务器发起心跳后能够获取到是否发送成功的回调状态，并在单次发送失败时向用户进行弱提示，在连续多次发送失败时向用户进行强提示；弱提示和强提示均用于提示用户检查网络状态。

具体的，贵金属的报价源包括上金所(上海黄金交易所)和国际交易所等，由于不同报价源的数据存在差别，因此本实施例中，在从不同报价源获取到原始数据后，对原始数据进行处理，得到一个统一的报价数据，用于在客户端进行展示，以便用户查看。其中，通过原始数据得到统一的报价数据时，可以考虑自身风险控制能力和当地市场情况等因素，也即可以根据实际需求设定处理规则，具体过程不进行限制。

其中，当从多个报价源获取原始数据时，虽然不同报价源的原始数据存在差别，但通过互相对比可以在一定程度上判断不同报价源的原始数据的波动是否正常，从而保证处理后得到的报价数据的准确性。

得到报价数据后，可以通过客户端进行展示，也即用户可以通过客户端查看报价数据，并根据自身意愿进行交易等。其中，客户端比如可以是PC等，其可以通过网页、程序等方式展示报价数据，展示形式可以是图表(例如折线图、表格等)的形式。

此外，本实施例中客户端与服务器之间的数据交互采用WebSocket推送和Http请求两种方式，从而客户端可以通过接口从服务器获取报价数据。当采用Http请求方式时，只能由客户端主动向服务器请求数据，而服务器不能主动向客户端发送数据，因此，这种方式在对展示的报价数据的实时性有要求时效果不好(因为客户端难以确定服务器何时从报价源获取到新的原始数据，因此难以确定客户端请求数据的时机)。基于此，客户端与服务器之间还采用WebSocket推送的方式进行数据交互，采用这种方式时，只需要经过一次Http请求之后即可建立WebSocket链接，从而客户端与服务器均可以主动向对方发送数据，如此，当服务器处理得到实时数据后，可以主动发送到客户端进行展示。其中，客户端通过WebSocket连接服务器时需要发送指定命令到服务器来响应推送特定数据，当客户端连接失败时，服务器推送数据就会抛出异常，此时服务器就会断开与客户端的连接，客户端需要重新连接服务器来获取实时数据。并且，由于可能会存在多个客户端请求与服务器连接，因此，在连接过程中，服务器会为每个客户端指定特定的ID，从而客户端使用该特定的ID与服务器建立连接。

基于此，一些实施例中，可以将报价数据分为历史报价数据和实时报价数据。历史报价数据，也即用户通过客户端查看报价数据的时刻之前已经产生的报价数据，实时报价数据则是指用户通过客户端查看报价数据的过程中，服务器实时从报价源获取原始数据后，处理得到的新的报价数据；其中，历史报价数据和实时报价数据均包括金额和时间戳数据，也即报价金额和该报价金额对应的时间。相应的，客户端通过WebSocket推送方式与服务器建立连接后，通过Http请求方式从服务器获取历史报价数据并进行展示，以及，通过WebSocket推送方式接受服务器发送的实时报价数据并进行展示。并且，实际应用中，对于历史报价数据，由于其已经产生并进行存储，因此可以是客户端与服务器建立连接后直接获取当日全部的历史报价数据并进行展示，而对于实时报价数据，则由服务器根据实际情况主动向客户端发送。

在具体实施时，客户端通过Http请求方式从服务器获取历史报价数据并进行展示时，具体用于：在展示界面加载时，通过接口按预设的时间需求获取服务器处理完毕并按不同周期存储在内存中的数据列(如图1所示)，通过金额、时间戳格式化校验后输入至图表中进行展示。展示界面的加载，指的是例如PC上的网页、程序的加载过程，包括接收到用户操作后的数据读取和界面生成过程。

而客户端在通过WebSocket推送方式接收服务器发送的实时报价数据并进行展示时，具体用于：使用指定ID通过WebSocket接口接入服务器，并开始接收实时报价数据，由服务器在每当有交易发生或金额变化时向客户端推送新的单列数据，客户端通过金额、时间戳格式化校验后添加至图表中进行展示。也即，如图1所示，服务器会持续监听多个报价源，持续获取原始数据并按照设定规则进行处理，处理后的数据批量存储至本地文件，而仅当有交易发生或金额变化时，才将处理完毕的数据发送到客户端，从而由客户端实时展示交易信息和变化后的报价金额以及对应的时间。

此外，在实际应用中，当客户端通过Http请求从服务器获取数据时，如果接口有异常(例如网络异常)，则前后端双方(也即客户端和服务器)都可以在第一时间获取到异常原因，并出具对应解决方案；但是，当使用WebSocket推送时发生网络异常等异常情况时，双方无法第一时间捕捉异常，基于此，为了确保客户端与服务器的正常连接，本实施例中采用客户端定时向服务器发起心跳的方式保持自己的链接状态，比如可以是通过WebSocket链接定时(例如每分钟)向服务器发送自身的标识码，服务器在接收到客户端发起的心跳(例如客户端的标识码)时，会自动记录该心跳(标识码以及对应的时间)，如果服务器能够在设定的时间间隔(该时间间隔根据实际需求进行设定，例如，对于每秒刷新的数据，则可以设置为每分钟进行检测，以此类推)连续接收到同一客户端发起的心跳，则表明该客户端“在线”，服务器保持与该客户端的链接状态，而如果服务器在设定的时间间隔未再次接收到同一客户端发起的心跳，则表明该客户端“掉线”，比如网络可能异常，此时，服务器断开与该客户端的链接。同时，当客户端在每次发起心跳后可以获取到是否发送成功的回调状态，如果发送成功，则不进行其他操作，继续等待发送下一次心跳；如果发送失败，则根据失败次数对用户进行提示，在单次发送失败时向用户进行弱提示(包括小的网络标识、小浮窗等)，以提醒用户检测网络状态，在连续多次发送失败时向用户进行强提示(弹窗提醒用户检查网络、刷新页面等)，来进行重新链接，以保证展示界面的报价数据的实时性。并且，在网络异常等情况短时间内不能消除时，由于已向用户发出提示，因此也不会导致用户出现对报价数据的误判、误解。

上述方案技术方案中，提供一种贵金属报价系统，其包括服务器和客户端，服务器通过从至少两个报价源获取原始数据并对原始数据进行处理得到报价数据，可以确保得到的报价数据的准确性；此外，客户端与服务器之间基于WebSocket推送和Http请求两种方式的接口进行数据交互，且在通过WebSocket推送方式进行数据交互时，由客户端定时发起心跳，从而实现在出现网络异常等异常情况时及时向用户发出提示，确保客户端与服务器的正常连接，进而确保客户端展示的报价数据的实时性，消除网络异常给报价系统带来的安全隐患。

此外，在实际应用中，服务器在监听实时交易信息、价格变动信息时，时常获取到的都是秒级数据(一秒有一组到多组的数据)，但由于单位时间内需要处理和发送的数据量较少，因此通过服务器处理后直接存储在文件，同时推送到客户端进行实时展示时，由于处理速度极快并不会产生一些性能问题。但是对于历史报价数据，当要获取当天或者指定时间段的数据组时，秒级数据会变得十分庞大，无论是加载，还是读写都会变得十分缓慢，也即用户需要等待一定时间。针对该问题，本方案中，服务器在获取到原始数据并对原始数据进行处理得到历史报价数据时，具体用于：根据网络状况或客户端的展示需求，对原始数据进行基于预设规则的分割，从而由秒级数据计算提供出分钟级数据，以使客户端能够先进行基本走势的展示并在此之后根据用户的操作获取并展示对应的详细数据；其中，所述预设规则包括时间段规则和数据长度规则。

也即，当服务器获取到原始数据后，根据设定的时间段和数据长度等规则对原始数据进行划分，比如，当采用时间段规则时可以是：当获取到一条原始数据后存储至新的数据列，在设定的时间段内(比如一分钟内)，由于该数据列已存在数据，则新获取的数据不再存储至该数据列，而是和其他数据一起按照时间顺序等规则批量存储至其他数据库或本地文件中，设定的时间之后，当获取到新的数据时，重新存储至另一数据列中，以此类推；进而，当客户端请求历史数据时，服务器首先向其发送上述仅包含一条数据的数据列，从而在客户端的展示界面先进行基本走势的展示。在此之后，当客户端获取到用户操作比如图标拖动、放大、查询等操作时，再按照操作情况实时从服务器批量存储的数据中获取与该操作对应的定量数据，比如特定时间点的数据等，从而在肉眼辨识动态反应速度(0.2s)内对图表进行数据更新补全，实现在高性能展示的同时可以随时查看最新、最全的数据列。

此外，在服务器从多个报价源实时获取原始数据并进行处理时，处理得到的报价数据可能出现较大波动，以及出现报价异常。针对该问题，服务器中预设有针对报价数据的基准值、上浮动值和下浮动值；服务器发送实时报价数据时，若待发送的实时报价数据大于基准值与上浮动值之和时，或者，小于基准值与下浮动值之和时，确定报价异常；报价异常时，客户端采用基准值作为实时报价数据进行展示。

其中，在实际应用中，基准值可以采用平均值，例如昨日的收盘价等，上浮动值和下浮动值可以根据实际需求进行设定，上浮动值为正值，下浮动值为负值，且二者的绝对值可以相同等也可以不相等，对此没有严格限制。当实时报价数据大于基准值与上浮动值之和，也即大于报价最大值时，或者小于基准值与下浮动值之和，也即小于报价最小值时，均视为报价异常，此时为了保证报价系统向用户报价的合理性，服务器将上述基准值作为当前的实时报价数据发送至客户端进行展示。

此外，在此基础上，还可以设置为服务器在报价异常时向预设的终端发送提示信息，且若在报价异常时获取到自定义报价，则将所述自定义报价发送至所述客户端，所述客户端采用所述自定义报价作为实时报价数据进行展示。比如，在报价异常时，服务器通过短信通知系统的相关负责人()，该相关负责人可以自定义报价并发送至服务器，如此，服务器在获取到自定义报价时，将自定义报价(而不是基准值)作为当前的实时报价数据发送至客户端进行展示。相对以基准值代替实时报价数据，相关负责人设定的自定义报价代替实时报价数据更合理。如果相关负责人未设定自定义报价，则继续采用基准值作为当前的实时报价数据。并且，当报价恢复正常(位于报价最大值和报价最小值之间)时，服务器继续推送处理得到的实时报价数据给客户端进行展示。

此外，在实际应用中，客户端在获取到实时报价数据时，对获取到的实时报价数据进行分析，通过模板引擎的模式实时输出在展示界面中，从而最低延时的展示当前交易情况,包括展示交易量和展示五档买卖。其中，交易量包括当前买入价、当前卖出价、最高价和最低价等信息；五档买卖包括买单中买入价格比较高的前五个价位的单子和卖单中卖出价格比较低的前五个价位的单子。通过展示上述的交易信息，可以便于用户进一步了解贵金属的报价情况。

应当理解的是，贵金属有多种，比如金、银和铂族金属等，因此，上述方案中所述的服务器从报价源获取原始数据并进行处理，以及在客户端展示处理后的报价数据的过程，均是针对不同贵金属分别进行的。

此外，基于相同的发明构思，本申请在上述贵金属报价系统的基础上，还提供一种贵金属报价方法。

参照图2，图2为本申请实施例提供的一种贵金属报价方法的流程示意图。如图2所示，该方法至少包括以下步骤：

S101：所述服务器从至少两个针对贵金属的报价源获取原始数据，以及对获取的原始数据进行处理得到报价数据，并存储所述报价数据；

S102：所述客户端基于WebSocket推送和Http请求两种方式的接口从所述服务器获取所述报价数据，并以图表的形式展示获取的报价数据；

其中，所述客户端在通过WebSocket推送方式与所述服务器建立连接后，定时向所述服务器发起心跳，所述服务器在每次接收到心跳后，在设定时间内若未再次接收到同一客户端发起的心跳，则断开与该客户端的WebSocket链接；所述客户端在向所述服务器发起心跳后能够获取到是否发送成功的回调状态，并在单次发送失败时向用户进行弱提示，在连续多次发送失败时向用户进行强提示；所述弱提示和所述强提示均用于提示用户检查网络状态。

此外，基于前述实施例所述的报价系统的扩展功能和具体实现过程，可以对该方法进行相同的改进和扩展，并且，其具体的实现方式也可以参照前述实施例实现，此处不再赘述。

基于上述方案，服务器通过从至少两个报价源获取原始数据并对原始数据进行处理得到报价数据，可以确保得到的报价数据的准确性；此外，客户端与服务器之间基于WebSocket推送和Http请求两种方式的接口进行数据交互，且在通过WebSocket推送方式进行数据交互时，由客户端定时发起心跳，从而实现在出现网络异常等异常情况时及时向用户发出提示，确保客户端与服务器的正常连接，进而确保客户端展示的报价数据的实时性，消除网络异常给报价系统带来的安全隐患。

可以理解的是，上述各实施例中相同或相似部分可以相互参考，在一些实施例中未详细说明的内容可以参见其他实施例中相同或相似的内容。

需要说明的是，在本申请的描述中，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。此外，在本申请的描述中，除非另有说明，“多个”的含义是指至少两个。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理解。

应当理解，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。