本申请涉及计算机软件领域，特别涉及一种应用实例的缓存中数据的更新方法、装置及一种集群。
背景技术：
在全球化大型信息系统的构建中，为了满足系统的全球化服务、高可用和快速响应能力，集群技术被广泛应用。集群中包括节点和数据库，其中，节点的个数有多个，每个节点中包含多个应用实例，数据库中存储所有应用实例响应外围请求消息所需要的参数及参数对应的数据。为了提高应用实例对外围请求消息的响应速度，将应用实例内存中的一部分存储空间作为缓存，该缓存用于保存该应用实例访问数据库中频率较高的参数以及参数对应的数据。
由于应用实例依据缓存中的数据来响应外围请求消息，为了保证响应外围请求消息的准确性，需要保证各应用实例的缓存中的数据与数据库中对应的数据相同，因此当数据库中的数据被更新时，应用实例应该更新缓存中的数据。在实际应用中，由于应用实例更新缓存中的数据需要网络资源，因此，如何保证在所有应用实例的缓存中的数据与更新后的数据库中对应的数据相同的前提下，节省集群中应用实例更新缓存中的数据所消耗的网络资源，是本申请所要解决的问题。
技术实现要素：
基于此，本申请提供了一种应用实例的缓存中数据的更新方法，用以实现当数据库中的数据被更新时，在保证所有应用实例的缓存中的数据与更新后的数据库中的对应数据相同的前提下，节省应用实例更新缓存中的数据所消耗的网络资源。
本申请还提供了一种应用实例的缓存中数据的更新装置及一种集群，用以保证上述方法在实际中的实现及应用。
本申请公开了一种应用实例的缓存中数据的更新方法，该方法应用于集群，所述集群中包括多个节点，每个节点中部署有至少一个应用实例，该方法包括：
所述应用实例接收广播设备发送的报文；所述报文用于指示数据库中的数据存在更新，且所述报文携带有所述数据库中更新后的至少一个第一参数的数据，以及更新所述数据库中的所述至少一个第一参数的目标应用实例的消息类型标识，所述消息类型标识用于表征应用实例处理的外围请求消息的类型；
所述应用实例从所述报文中解析出所述目标应用实例的消息类型标识与所述更新后的至少一个第一参数的数据；
所述应用实例判断所述应用实例的消息类型标识与所述目标应用实例的消息类型标识是否相同；
若所述应用实例的消息类型标识与所述目标应用实例的消息类型标识相同，则所述应用实例依据所述更新后的至少一个第一参数的数据更新所述应用实例的缓存中存储的参数对应的数据。
其中，所述应用实例依据所述更新后的至少一个第一参数的数据更新所述应用实例的缓存中存储的参数对应的数据，包括：
确定所述应用实例的缓存中与所述至少一个第一参数相同的至少一个第二参数；
调用更新所述第二参数对应的更新算法；
依据所述更新算法与所述更新后的至少一个第一参数的数据，更新所述应用实例的缓存中存储的至少一个第二参数的数据。
其中，所述广播设备为消息队列主题，所述应用实例接收广播设备发送的报文，包括：
所述应用实例接收消息队列主题发送的报文；所述报文由所述目标应用实例通过java消息服务发送至消息队列主题。
其中，所述应用实例依据所述更新后的至少一个第一参数的数据更新所述应用实例的缓存中存储的至少一个第二参数的数据之后，还包括：
将对所述至少一个第二参数的数据的更新结果记录在所述数据库；所述更新结果包括更新成功与更新失败。
其中，所述应用实例为目标应用实例时，所述应用实例将对所述至少一个第二参数的数据的更新结果记录在所述数据库后，还包括：
判断所述数据库中是否存在更新结果为更新失败的应用实例；
若所述数据库中存在所述更新结果为更新失败的应用实例，则将所述报文通过广播设备向所述更新失败的应用实例发送，使得所述更新失败的应用实例更新缓存中存储的数据。
本申请还公开了一种应用实例的缓存中数据的更新装置，所述装置集成于集群，所述集群包括多个节点，每个所述节点中部署有至少一个应用实例，所述装置包括：
接收单元，用于接收广播设备发送的报文；所述报文用于指示数据库中的数据存在更新，且所述报文携带有所述数据库中更新后的至少一个第一参数的数据，以及更新所述数据库中的所述至少一个第一参数的目标应用实例的消息类型标识，所述消息类型标识用于表征应用实例处理的外围请求消息的类型；
解析单元，用于从所述报文中解析出所述目标应用实例的消息类型标识与所述更新后的至少一个第一参数的数据；
第一判断单元，用于判断所述应用实例的消息类型标识与所述目标应用实例的消息类型标识是否相同；
更新单元，用于在所述第一判断单元的判断结果为所述应用实例的消息类型标识与所述目标应用实例的消息类型标识相同时，依据所述更新后的至少一个第一参数的数据更新所述应用实例的缓存中存储的参数对应的数据。
其中，所述更新单元包括：
确定子单元，用于确定所述应用实例的缓存中与所述至少一个第一参数相同的至少一个第二参数；
调用子单元，用于调用更新所述第二参数对应的更新算法；
更新子单元，用于依据所述更新算法与所述更新后的至少一个第一参数的数据，更新所述应用实例的缓存中存储的至少一个第二参数的数据。
其中，所述广播设备为消息队列主题，所述接收单元，用于接收消息队列主题发送的报文；所述报文由所述目标应用实例通过java消息服务发送至消息队列主题。
其中，所述装置还包括：
记录单元，用于在更新子单元更新所述应用实例的缓存中存储的至少一个第二参数的数据之后，将对所述至少一个第二参数的数据的更新结果记录在所述数据库；所述更新结果包括更新成功与更新失败。
其中，所述装置还包括：
第二判断单元，用于判断所述数据库中是否存在更新结果为更新失败的应用实例；
发送单元，用于在所述第二判断单元的判断结果为所述数据中存在更新结果为更新失败的应用实例时，将所述报文通过广播设备向所述更新失败的应用实例发送，使得所述更新失败的应用实例更新缓存中存储的数据。
本申请还公开了一种集群，该集群包括多个节点、广播设备、数据库，每个所述节点中部署有至少一个应用实例；
所述节点，用于在节点中的应用实例接收所述广播设备发送的报文，所述报文用于表示数据库中的数据存在更新，所述报文携带更新所述数据中的数据的目标应用实例的消息类型标识，更新后的至少一个第一参数的数据；
所述应用实例从所述报文中解析出所述目标应用实例的消息类型标识与所述更新后的至少一个第一参数的数据；
所述应用实例判断所述应用实例的消息类型标识与所述目标应用实例的消息类型标识是否相同；
若所述应用实例的消息类型标识与所述目标应用实例的消息类型标识相同，则所述应用实例依据所述更新后的至少一个第一参数的数据更新所述应用实例的缓存中存储的参数对应的数据。
其中，所述节点，还用于在所述节点中更新所述数据库中数据的目标应用实例在更新所述数据库中的数据后，根据更新后的至少一个第一参数的数据更新缓存中存储的数据；
所述目标应用实例将报文发送至所述广播设备；所述报文用于表示数据库中的数据存在更新，所述报文携带目标应用实例的消息类型标识，更新后的至少一个第一参数的数据；
所述广播设备将所述报文发送至所述节点中除所述目标应用实例外的应用实例。
与现有技术相比，本申请包括以下优点：
由于集群中的应用实例接收到广播设备发送的报文时，该报文表示数据库中的数据存在更新，该报文中携带有数据库中被更新的至少一个第一参数的数据，以及更新数据库中至少一个第一参数的数据的目标应用实例的消息类型标识，该应用实例从报文中解析出更新后的至少一个第一参数的数据，以及更新至少一个第一参数的数据的目标应用实例的消息类型标识；该应用实例判断该应用实例的消息类型标识与目标应用实例的消息类型标识是否相同，如果该应用实例的消息类型标识与目标应用实例的消息类型标识相同时，则根据解析出的更新后的至少一个第一参数的数据更新该应用实例的缓存中存储的参数对应的数据。由于应用实例的消息类型标识表征该应用实例处理的外围请求消息的类型，因此，消息类型标识不同的应用实例处理的外围请求消息的类型不同，所以不同消息类型标识的应用实例的缓存中保存的参数数据不同，因此，当数据库中的数据被更新时，与目标应用实例的消息类型标识不同的应用实例在不更新缓存中存储的参数的数据的情况下，同样与更新后的数据库中对应的数据相同，而与目标应用实例的消息类型标识相同的应用实例更新其缓存中存储的参数的数据，从而保持与更新后的数据库中对应的数据相同；此时，集群中只有部分的应用实例更新缓存中存储的参数的数据，因此更新缓存中存储的参数的数据的应用实例的数量减小了，进而节省了更新缓存中存储的参数的数据所消耗的网络资源，同时还保证了集群中所有应用实例的缓存中存储的参数数据与更新后的数据库中对应的数据相同。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
图1是本申请中一种应用实例的缓存中数据的更新方法实施例的流程图；
图2是本申请中又一种应用实例的缓存中数据的更新方法实施例的流程图；
图3是本申请中又一种应用实例的缓存中数据的更新方法实施例的流程图；
图4是本申请中一种应用实例的缓存中数据的更新装置实施例的结构示意图；
图5是本申请中一种集群的结构示意图。
具体实施方式
本申请实施例所述的应用实例的缓存中数据的更新方法可以由应用实例的缓存中数据的更新装置执行，所述装置可以集成在各应用实例中，也可以独立设置。
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
参考图1，示出了本申请的一种应用实例的缓存中数据的更新方法实施例的流程图，具体可以包括以下步骤：
步骤101：每个应用实例从对应的配置文件中获取消息类型标识，该消息类型标识用于表征应用实例处理的外围请求消息的类型。
在本实施例中，集群中包括多个节点与一个数据库，每个节点中包括至少一个应用实例，不同的应用实例处理不同类型的外围请求消息，为了区别任意一个节点中的多个不同的应用实例，在每个应用实例对应的配置文件中已设置了该应用实例的消息类型标识，该消息类型标识用于表征该应用实例处理的外围请求消息的类型，应用实例在启动时自动从配置文件中获取消息类型标识，在实际应用中，应用实例的消息类型标识可以为id，即节点中的不同应用实例对应不同的id。
集群中不同节点中的应用实例相同，例如，集群中有两个节点，分别为节点1与节点2，其中，节点1中有3个应用实例，分别为应用实例1、应用实例2与应用实例3，节点2中的应用实例所处理的外围请求消息的类型与节点1中的应用实例相同，同样分别与应用实例1、应用实例2与应用实例3处理相同类型的外围请求消息，因此，节点1与节点2中应用实例对应的消息类型标识相同，在实际应用中，节点1与节点2中处理相同类型外围请求消息的应用实例对应的id相同。
步骤102：当数据库中的数据被集群中的目标应用实例更新时，目标应用实例将该目标应用实例的消息类型标识、数据库中被更新的至少一个第一参数的数据发送至广播设备。
在本实施例中，目标应用实例为集群中更新数据库中数据的一个应用实例，也就是说集群中更新数据库中数据的应用实例即为本步骤中的目标应用实例。本实施例中将数据库中被更新的任意一个参数称为第一参数，在实际的应用中，第一参数的个数至少一个。在本实施例中广播设备是集群中用于收发消息的设备。当目标应用实例更新数据库中至少一个第一参数的数据后，该目标应用实例将目标应用实例的消息类型标识，以及更新后的至少一个第一参数的数据发送至广播设备。
具体的，目标应用实例将目标应用实例的消息类型标识，以及更新后的至少一个第一参数的数据发送至广播设备包括：
步骤a1：目标应用实例将目标应用实例的消息类型标识，以及更新后的至少一个第一参数的数据打包为报文。
在实际应用中，目标应用实例还可以将目标应用实例的id、至少一个第一参数、至少一个第一参数的数据、目标应用实例所在的节点的名称、数据库中至少一个第一参数的数据被更新的时间等内容按照约定的格式组装成报文。
步骤a2：目标应用实例将该报文发送至广播设备。
在本步骤中，广播设备可以为消息队列(messagequeue，mq)的主题(topic)。本实施例中应用实例可以通过开源框架(spring)的java消息服务(javamessageservice，jms)与mqtopic进行通信，即目标应用实例通过jms将报文发送至mqtopic，其中，jms即java消息服务应用程序接口，是一个java平台中关于面向消息中间件的api，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信，mq是一种应用程序对应用程序的通信方法。
步骤103：广播设备将报文发送至集群中的各应用实例。
在mqtopic接收到报文后，接着将该报文发送至集群中的各应用实例。
步骤104：应用实例接收广播设备发送的报文。
在mqtopic将该报文发送至集群中的各应用实例后，各应用实例接收该报文，在本实施例中集群中所有的应用实例都接收该报文。报文用于指示数据库中的数据存在更新，并且该报文中携带有数据库中更新后的至少一个第一参数的数据，以及目标应用实例的消息类型标识。由于集群中的各应用实例接收广播设备发送的报文，以及接收后所执行的动作都相同，因此，本实施例以一个应用实例进行介绍，因此，本步骤的应用实例为集群中的一个应用实例。
步骤105：应用实例从报文中解析出目标应用实例的消息类型标识，以及更新后的至少一个第一参数的数据。
在步骤104中的应用实例接收到报文后，接着，在本步骤中，该应用实例需要对报文进行解析。具体的该应用实例解析报文的过程为：应用实例按照约定的格式从报文中解析出目标应用实例的消息类型标识，以及更新后的至少一个第一参数的数据，其中，约定的格式与目标应用实例将目标应用实例的消息类型标识，以及更新后的至少一个第一参数的数据打包为报文时所用的格式相同。
步骤106：应用实例判断该应用实例的消息类型标识是否与目标应用实例的消息类型标识相同。
在该应用实例从报文中解析出目标应用实例的消息类型标识，以及更新后的至少一个第一参数的数据后，将该应用实例的消息类型标识与目标应用实例的消息类型标识进行比较，判断应用实例的消息类型标识是否与目标应用实例的消息类型标识相同，在实际应用中，应用实例可以判断该应用实例的id是否与目标应用实例的id相同。若该应用实例的消息类型标识与目标应用实例的消息类型标识相同，则执行步骤107，若该应用实例的消息类型标识与目标应用实例的消息类型标识不相同，则结束操作。
步骤107：应用实例依据更新后的至少一个第一参数的数据更新应用实例的缓存中存储的参数对应的数据。
在应用实例的消息类型标识与目标应用实例的消息类型标识相同时，该应用实例则依据更新后的至少一个第一参数的数据更新应用实例的缓存中存储的参数对应的数据。具体的更新缓存中存储的参数对应的数据的过程可以包括：
步骤b1：确定应用实例的缓存中与至少一个第一参数相同的至少一个第二参数。
在本实施例中，消息类型标识相同的应用实例处理的外围请求消息的类型相同，但是消息类型标识相同的应用实例的缓存中存储的参数不完全相同，因此，本步骤中的至少一个第二参数是至少一个第一参数中的部分参数，或者是全部参数，具体需要根据实际情况来定。在本步骤中应用实例从缓存中存储的参数中确定出与至少一个第一参数相同的至少一个第二参数。
步骤b2：调用更新该至少一个第二参数对应的更新算法。
应用实例在确定出至少一个第二参数后，分别根据每个第二参数调用该第二参数对应的更新算法，以便第二参数对应的更新算法更新第二参数的数据。
步骤b3：依据更新算法与更新后的至少一个第一参数的数据，更新应用实例的缓存中存储的至少一个第二参数的数据。
应用实例分别调用每个第二参数对应的更新算法后，依据该更新算法与该第二参数对应的第一参数的数据，来更新该应用实例的缓存中存储的至少一个第二参数的数据。
上述步骤106～步骤107实现了应用实例更新缓存中存储的参数的数据，在实际应用中，上述步骤106～步骤107可以为一颗两层的判定树，第一层为判断应用实例的消息类型标识与目标应用实例的消息类型标识是否相同，第二层为在应用实例的缓存中确定与至少一个第一参数相同的至少一个第二参数，当第一层判断通过后才执行第二层。并且，该判定树中存在多个叶子节点，每个叶子节点对应一个第二参数的更新方法，判定树在确定出至少一个第二参数后，分别在每个第二参数对应的叶子节点上执行从数据库中加载该第二参数的数据的动作，接着，更新该第二参数的数据。
上述步骤104～步骤107的目的是：应用实例更新缓存中存储的数据的过程，具体流程如图2所示。
步骤108：应用实例将对至少一个第二参数的数据的更新结果记录在数据库。
在应用实例更新至少一个第二参数的数据后，该应用实例将更新结果记录在数据库中，其中，该更新结果包括更新成功与更新失败，具体的应用实例可以采用区别更新成功与更新失败的标志记录在数据库中的数据表中。
上述步骤104～步骤108是集群中的同一个应用实例实现对缓存中存储的数据的更新过程，对于集群中的其他应用实例对缓存中存储的数据的更新过程同样为步骤104～步骤108。
步骤109：目标应用实例检测数据库中是否存在更新失败的应用实例。
应用实例将对缓存中存储的数据的更新结果记录在数据库中后，例如记录在数据库中的数据表中，目标应用实例检测该数据表中是否存在更新失败的应用实例。
步骤110：当目标应用实例检测到数据库中存在更新失败的应用实例时，目标应用实例将该报文通过广播设备发送至该更新失败的应用实例，以便更新失败的应用实例根据至少一个第一参数的数据更新缓存中存储的数据。
在本步骤中当目标应用实例检测到数据库中存在更新失败的应用实例时，目标应用实例将携带目标应用实例的消息类型标识、更新后的至少一个第一参数的数据，以及对缓存中的至少一个第二参数的数据更新失败的应用实例的消息类型标识的报文发送至广播设备，广播设备将该报文发送至更新失败的应用实例，该更新失败的应用实例按照步骤104～步骤108的动作执行，由于不同节点中的应用实例所处理的外围请求消息的类型相同，因此集群中所有需要更新缓存中存储的参数数据的应用实例的个数应该等于集群中节点的个数，因此，目标应用实例检测到数据库表中所有更新结果为更新成功，并且进行更新的应用实例的数目等于集群中节点的个数时，完成了对集群中应用实例的缓存中存储的数据的更新过程。
在本实施例中，由于应用实例的消息类型标识表征该应用实例处理的外围请求消息的类型，因此，消息类型标识不同的应用实例处理的外围请求消息的类型不同，所以不同消息类型标识的应用实例的缓存中保存的参数数据不同，因此，当数据库中的数据被更新时，与目标应用实例的消息类型标识不同的应用实例在不更新缓存中存储的参数的数据的情况下，同样与更新后的数据库中对应的数据相同，而与目标应用实例的消息类型标识相同的应用实例更新其缓存中存储的参数的数据，从而保持与更新后的数据库中对应的数据相同；此时，集群中只有部分的应用实例更新缓存中存储的参数的数据，因此更新缓存中存储的参数的数据的应用实例的数量减小了，进而节省了更新缓存中存储的参数的数据所消耗的网络资源，同时还保证了集群中所有应用实例的缓存中存储的参数数据与更新后的数据库中对应的数据相同。
此外，在本实施例中，当目标应用实例更新数据库中的数据后，将报文发送至广播设备，每个应用实例接收到广播设备发送的报文后，对于需要更新缓存中存储的数据的应用实例同步更新缓存中存储的数据，因此，在本实施例中，集群中应用实例的缓存中存储的数据的更新过程是同步的，避免了集群中需要更新缓存中存储的数据的所有应用实例由于更新不同步，而导致消息类型标识相同的不同应用实例对相同类型的外围请求消息的处理结果不同的缺点。
此外，在本实施例中，集群中的应用实例在更新缓存中存储的数据后，将更新结果记录在数据库中，目标应用实例根据各应用实例的更新结果来确定是否所有需要更新数据的应用实例都成功进行更新，如果某个应用实例的对缓存中存储的数据更新失败，则接着更新，直至集群中所有需要更新缓存中存储的数据的应用实例都更新成功，从而保证具有相同消息类型标识的应用实例对相同类型的外围请求消息的处理结果相同。
参考图3，示出了本申请又一种应用实例的缓存中数据的更新方法实施例的流程图，具体可以包括以下步骤：
步骤301：每个应用实例从对应的配置文件中获取消息类型标识，该消息类型标识用于表征应用实例处理的外围请求消息的类型。
在本实施例中，该步骤的具体过程与图1对应的实施例中的步骤101相同，具体细节可以参考图1对应的实施例中的步骤101，这里不再赘述。
步骤302：当数据库中的数据被集群中的目标应用实例更新时，目标应用实例根据数据库中被更新的至少一个第一参数的数据更新缓存中存储的参数的数据。
在本步骤中目标应用实例依据更新后的至少一个第一参数的数据更新缓存中存储的参数的数据的过程与图1对应的实施例中的步骤107～步骤108所述的过程相同，具体细节可以参考步骤107～步骤108，这里不再赘述。
步骤303：目标应用实例将该目标应用实例的消息类型标识、数据库中被更新的至少一个第一参数的数据发送至广播设备。
步骤304：广播设备将报文发送至集群中的各应用实例。
步骤305：应用实例接收广播设备发送的报文。
本实施例中的步骤304～步骤305的具体实方式与图1对应的实施例中的步骤103～步骤104的具体实施方式相同，具体细节可以对应参考步骤103～步骤104，这里不再赘述。
步骤306：应用实例从报文中解析出目标应用实例的消息类型标识，以及更新后的至少一个第一参数的数据。
在本步骤中的应用实例为集群中除目标应用实例外的应用实例，除目标应用实例外的各应用实例执行本步骤的过程相同，因此，本步骤描述的是一个应用实例的执行过程，具体的执行过程可以参考图1对应的实施例中的步骤105，这里不再赘述。
步骤307：应用实例判断该应用实例的消息类型标识是否与目标应用实例的消息类型标识相同。
在本步骤中应用实例判断该应用实例的消息类型标识与目标应用实例的消息类型标识相同时，则执行步骤308，若该应用实例的消息类型标识与目标应用实例的消息类型标识不相同时，则结束操作。
步骤308：应用实例依据更新后的至少一个第一参数的数据更新应用实例的缓存中存储的参数对应的数据。
步骤309：应用实例将对至少一个第二参数的数据的更新结果记录在数据库。
上述步骤308～步骤309中的应用实例与步骤307中的应用实例为同一个应用实例，具体实施方式与图1对应的实施例中步骤107～步骤108的具体实施方式相同，具体细节可参考步骤107～步骤108，这里不再赘述。
上述步骤305～步骤309为集群中除目标应用实例外的同一个应用实例实现更新缓存中存储的至少一个第二参数的过程，对于集群中除目标应用实例外的所有应用实例都按照步骤305～步骤309的动作来更新缓存中存储的至少一个第二参数。
步骤310：目标应用实例检测数据库中是否存在更新失败的应用实例。
步骤311：当目标应用实例检测到数据库中存在对缓存中的至少一个第二参数的数据更新失败的应用实例时，目标应用实例将携带目标应用实例的标识、更新后的至少一个第一参数的数据，以及更新失败的应用实例的消息类型标识的报文通过广播设备发送至该更新失败的应用实例，以便更新失败的应用实例根据更新后的至少一个第一参数的数据更新缓存中存储的数据。
上述步骤310～步骤311的具体实现方式与图1对应的实施例中步骤109～步骤110的具体实现方式相同，具体细节可参考步骤109～步骤110，这里不再赘述。
在本实施例中，由于应用实例的消息类型标识表征该应用实例处理的外围请求消息的类型，因此，消息类型标识不同的应用实例处理的外围请求消息的类型不同，所以与目标应用实例的消息类型标识不同的应用实例的缓存中存储的参数与目标应用实例的缓存中存储的参数不同，因此，当数据库中的数据被更新时，与目标应用实例的消息类型标识不同的应用实例在不更新缓存中存储的参数的数据时，同样与更新后的数据库中对应的数据相同，而与目标应用实例的消息类型标识相同的应用实例更新其缓存中存储的参数的数据，从而保持与更新后的数据库中对应的数据相同，此时，集群中只有部分的应用实例更新缓存中存储的参数的数据，因此更新缓存中存储的参数的数据的应用实例的数量减小了，进而节省了更新缓存中存储的参数的数据所消耗的网络资源，同时还保证了集群中所有应用实例的缓存中存储的参数数据与更新后的数据库中对应的数据相同。
参考图4，示出了本申请一种应用实例的缓存中数据的更新装置实施例的结构示意图，具体可以包括：
接收单元401，用于接收广播设备发送的报文；所述报文用于指示数据库中的数据存在更新，且所述报文携带有所述数据库中更新后的至少一个第一参数的数据，以及更新所述数据库中的所述至少一个第一参数的目标应用实例的消息类型标识，所述消息类型标识用于表征应用实例处理的外围请求消息的类型；
其中，接收单元中的广播设备为消息队列主题，具体用于接收消息队列主题发送的报文；所述报文由所述目标应用实例通过java消息服务发送至消息队列主题。
解析单元402，用于从所述报文中解析出所述目标应用实例的消息类型标识与所述更新后的至少一个第一参数的数据；
第一判断单元403，用于判断所述应用实例的消息类型标识与所述目标应用实例的消息类型标识是否相同；
更新单元404，用于在所述第一判断单元的判断结果为所述应用实例的消息类型标识与所述目标应用实例的消息类型标识相同时，依据所述更新后的至少一个第一参数的数据更新所述应用实例的缓存中存储的参数对应的数据。
其中，所述更新单元404，具体可以包括：
确定子单元，用于确定所述应用实例的缓存中与所述至少一个第一参数相同的至少一个第二参数；
调用子单元，用于调用更新所述第二参数对应的更新算法；
更新子单元，用于依据所述更新算法与所述更新后的至少一个第一参数的数据，更新所述应用实例的缓存中存储的至少一个第二参数的数据。
其中，所述装置实施例还可以包括：
记录单元，用于在更新子单元更新所述应用实例的缓存中存储的至少一个第二参数的数据之后，将对所述至少一个第二参数的数据的更新结果记录在所述数据库；所述更新结果包括更新成功与更新失败。
其中，所述装置实施例还可以包括：
第二判断单元，用于判断所述数据库中是否存在更新结果为更新失败的应用实例；
发送单元，用于在所述第二判断单元的判断结果为所述数据中存在更新结果为更新失败的应用实例时，将所述报文通过广播设备向所述更新失败的应用实例发送，使得所述更新失败的应用实例更新缓存中存储的数据。
参考图5，示出了本申请一种集群的结构示意图，该集群可以包括：
节点501、广播设备502、数据库503；节点501中都部署有至少一个应用实例；
所述节点501，用于在所述节点中更新所述数据库503中数据的目标应用实例更新所述数据库503中的数据后，根据更新后的至少一个第一参数的数据更新缓存中存储的数据；
所述目标应用实例将报文发送至所述广播设备502；所述报文用于表示数据库503中的数据存在更新，所述报文携带所述目标应用实例的消息类型标识，更新后的至少一个第一参数的数据；
节点501中除目标应用实例外的应用实例接收所述广播设备502发送的报文；
节点501中除目标应用实例外的应用实例从所述报文中解析出所述目标应用实例的消息类型标识，以及更新后的至少一个第一参数的数据；
节点501中若所述除所述目标应用实例外的应用实例的消息类型标识与所述目标应用实例的消息类型标识相同时，则应用实例依据所述更新后的至少一个第一参数的数据更新所述应用实例的缓存中存储的参数对应的数据。
需要说明的是，为了示意上述集群的工作流程，上述集群中的节点个数为2个，在实际应用中，集群中的节点个数不限于2个，可以为多个，本申请实施例对集群中节点的个数不作具体限定。
还需要说明的是，上述节点中目标应用实例为更新数据库503的应用实例，本实施例为了示意集群的工作流程，节点501中的一个应用实例为目标应用实例，在实际应用中，该集群中的目标应用实例可以为集群中任意一个应用实例，只要是集群中更新数据库中的数据的应用实例即可。
图5所示的实施例为一种应用场景下的技术方案，在实际应用中，集群还可以包括图5所示的集群中的部件，但是集群中目标应用实例在更新数据库中的数据后，不更新该目标应用实例的缓存中存储的数据，而是将报文直接发送至广播设备，该广播设备将报文统一发送至集群中所有的应用实例，集群中所有需要更新的应用实例同步对缓存中存储的数据进行更新。
对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。