间的数据交换。
[0115]步骤102:所述匹配分片对生成时间早于或等于所述处理截止时间的购买申请进行交易匹配处理。
[0116]为了进行匹配处理，在每个匹配分片启动的时候要先获取并加载产品信息，然后再对购买申请信息和已获取的产品信息进行匹配处理。整个处理过程包括6个子步骤，请参考附图3，其为本申请的匹配分片进行交易匹配处理的实施例流程图，下面分别针对各个子步骤加以说明。
[0117]步骤102-1:获取对购买申请进行匹配处理所需的产品信息。
[0118]匹配的过程，就是查找符合用户购买申请要求的产品信息的过程，产品信息通常存放在产品数据库中，匹配过程需要读取大量的产品数据信息，因此会频繁访问数据库，由于查询量巨大造成的压力，可能使数据库成为整个系统的性能瓶颈，导致匹配效率低下。为了避免出现这一问题，本申请提供一种优选实施方式，即:在每个匹配分片启动的时候，先将进行匹配处理所需的产品信息加载到内存中，这样每次只须将购买申请信息与内存中的产品信息进行匹配就可以了，从而提高匹配效率。
[0119]在具体的实施过程中，考虑到内存空间是有限的，每次加载的产品信息不一定是产品数据库的全量数据，只需要加载当前匹配所需要使用的产品数据就可以了。在本实施例的一个具体例子中，当前分片主要用于进行用户购买申请和理财产品之间的匹配，因此在本步骤中就以较大的比例从产品数据库中加载理财产品，而且只加载拥有有效库存、处于在售状态并允许匹配的理财产品，而收益率越高、发布时间越早的产品在匹配过程中拥有越高的处理优先级，因此在内存空间受限的情况下，可以优先加载这部分产品数据。
[0120]步骤102-2:从消息中间件的消息队列中拉取购买申请信息。
[0121]进行购买申请信息和产品信息的匹配，需要先从消息中间件的消息队列中拉取购买申请信息，并将拉取的购买申请信息与产品信息进行匹配处理，这个过程也可以称为对购买申请进行消费的过程。
[0122]本申请所述的拉取，是指从消息中间件的消息队列中取出第一个购买申请信息，因为本申请的技术方案采用消息中间件以队列的方式存储购买申请信息，并且该队列遵循先进先出模式，这种队列只允许在队列的前端(front)进行删除操作(即:拉取操作)，在队列的后端(rear)进行插入操作(B卩:添加操作)，而向队列中添加购买申请时是按照购买申请的提交时间排序的，即:提交时间较早的购买申请位于提交时间较晚的购买申请的前面，因此每次从队列中取出第一个购买申请进行处理，也符合匹配系统通常的时间优先原则。
[0123]如果当前消息中间件队列为空，也就是说当前没有需要进行匹配处理的购买申请，这种情况下本匹配分片也不结束，而是继续保持工作状态，一直轮询检查消息中间件的消息队列中是否有新的购买申请到达，一旦消息中间件中有新的购买申请时，本匹配分片会立即拉取该购买申请信息并进行相应的处理。
[0124]步骤102-3:判断所述购买申请信息包含的提交时间是否早于或者等于当前匹配分片的处理截止时间；如果是，说明当前拉取的购买申请属于本匹配分片的处理范围之内，因此继续执行步骤102-4进行匹配操作；如果不是，则说明当前拉取的购买申请已经不属于本匹配分片的管辖范围了，则转到步骤102-6执行。
[0125]步骤102-4:对所述购买申请信息和已获取的产品信息执行匹配操作。
[0126]将已经从消息中间件拉取的、并且应该由本匹配分片负责处理的购买申请信息，与产品信息进行匹配，查找是否存在满足购买申请要求的产品。在本实施例的一个具体例子中，用户根据自己的风险偏好和收益预期，在理财综合业务平台下发了一个购买理财产品的预约单，其中设定了对理财产品的要求，包括:期望收益率、产品类型、年限、购买金额等信息，在本步骤中，拉取到了该购买申请信息，则根据该购买申请信息设定的要求，从已经加载到内存的产品信息中查找满足上述要求的理财产品，如果找到满足上述要求的理财产品，则认为匹配成功。
[0127]步骤102-5:对匹配成功的购买申请和产品发起交易请求。
[0128]对于匹配成功的购买申请和产品，则自动发起交易，在交易过程中对产品的真实库存执行扣减动作。到这里，就成功地完成了一个购买申请的匹配过程。但是当前的匹配分片并没有结束，还要继续转到步骤102-2从消息中间件中拉取下一个购买申请并重复上述处理。
[0129]步骤102-6:将所述购买申请重新放入消息中间件的消息队列中，并结束当前分片。
[0130]之所以执行本步骤，是因为在步骤102-3中，发现当前拉取的购买申请信息包含的提交时间晚于当前匹配分片的处理截止时间，说明当前拉取的购买申请已经不属于当前匹配分片的管辖范围了，因此将该购买申请重新放入消息中间件的消息队列中(该购买申请会由后续的匹配分片处理)，并结束当前分片。
[0131]下面以先后启动的两个匹配分片为例，对上述匹配分片的处理流程进行说明:预先设定匹配分片的启动时间间隔为5分钟，10:00:00启动了匹配分片1，并指定该匹配分片的处理截止时间为10:04:50，如果匹配分片I从消息中间件中拉取的购买申请的提交时间为10:02:00，则执行匹配当前购买申请信息和产品信息的操作，如果成功则发起交易；如果匹配分片I从消息中间件中拉取的购买申请的提交时间为10:04:55，则该购买申请已经不属于匹配分片I的处理范围了，这时该购买申请会被重新放回消息中间件，匹配分片I也就结束了。而匹配分片2在10:05:00启动，因此该购买申请会很快被匹配分片2拉取并进行相应的处理。
[0132]通过上面的例子可以看出，采用本申请提供的技术方案，虽然匹配分片是通过定时任务定期启动的，但是由于每个匹配分片都是一直处于工作状态，并且在上述例子中，由于每个匹配分片的处理截止时间仅仅略小于下一个匹配分片的启动时间，因此从时间维度上看，相邻的匹配分片近似处于连续工作状态，即:当前匹配分片结束后，下一个匹配分片也很快就启动了，从而当用户的购买申请提交后，可以得到及时地处理，这个效果近似等价于匹配系统是处于一个连续匹配的工作状态中。
[0133]作为一种优选实施方式，如果每个匹配分片的处理截止时间等于下一个匹配分片的启动时间，那么，从时间维度上看，相邻的匹配分片就处于连续工作状态，前一个匹配分片结束时，下一个匹配分片必然已经启动了，其效果就是:用户的购买申请提交后，不需要等待启动新的匹配分片就可以得到及时处理，从而实现了功能上等价于连续匹配的匹配系统。
[0134]一个匹配分片拉取的属于其处理区间的购买申请可能很多，以致该匹配分片的处理截止时间已经经过，这些购买申请的交易匹配过程还没有完成，则该匹配分片会继续完成这些交易的匹配；一个匹配分片不会因为截止时间已经到达，或者下一个匹配分片已经开始工作而停止工作，而是会继续工作到其管理的时间区间的所有交易匹配完成。
[0135]采用本申请提供的分片式交易匹配方法，可以在基于定时任务触发的匹配系统中实现连续匹配功能，提高对用户请求的处理效率。在具体应用中，如果采用传统的单机匹配模式，虽然成本低廉、易于管理，但是存在以下两方面的缺点:一方面无法满足随着业务量增大而出现的扩容需求；另一方面无法应对宕机的情况，一旦宕机匹配系统就完全不可用，用户的购买申请无法得到及时的处理。因此，在具体实施中，通常采用集群系统共同完成匹配任务。当业务容量增长造成系统匹配能力不足时，可以通过增加集群内部的匹配服务器的数量来进行扩展，从而平滑应对业务增长的压力；另外，当匹配集群中的某台匹配服务器无法正常工作时，可以将其从匹配集群中剔除，匹配任务继续由匹配集群中的其他服务器共同分担，从而保证了用户购买申请仍然能够得到及时的处理。
[0136]本申请提供的方法也可以应用于上述集群系统，实现整个集群系统的连续匹配，整个集群系统的匹配处理依然是通过定时任务进行触发，具体的触发方式与单机模式有一些区别。为了与分布式处理机制相适应，定时任务将定时触发指令发送到预先指定的一台中心匹配服务器，或者随机发到一台匹配服务器，该服务器即成为当前的中心匹配服务器。中心匹配服务器根据当前时间与预先设定的匹配分片处理时间区间的长度，计算将要启动的匹配分片的处理截止时间，例如，当前时间为t，预先设定的匹配分片处理时间区间的长度为η分钟，那么将要启动的匹配分片的处理截止时间=t+n。计算完毕，中心匹配服务器向集群中的所有匹配服务器发送包含上述处理截止时间的启动匹配指令，采用这种处理方式，可以使所有的匹配服务器能够几乎同时启动匹配分片，开始进行匹配处理。
[0137]中心匹配服务器除了完成上述计算处理截止时间、并向所有匹配服务器发送启动匹配指令外，还可以负责执行从产品数据库加载产品信息的任务。在单机模式下，匹配服务器在启动匹配分片时从产品数据库读取产品信息并加载到本地内存中，这样可以提高匹配分片执行匹配的效率，也能够减少对数据库的访问频率。
[0138]在分布式环境下如果仍然按照上述单机模式工作，在匹配分片的启动过程中，会出现大量并发的数据库访问，势必影响匹配分片的启动速度，而且每台匹配服务器执行的都是重复的数据库访问操作。为了改善上述状况，可以将从产品数据库读取产品信息的任务交由中心匹配服务器完成，即:中心匹配服务器从产品数据库中读取产品信息，并在分布式缓存中保存一份产品信息，然后再向分布式集群的所有匹配服务器发起启动匹配的指令，集群中的每台匹配服务器接收到指令后，在启动匹配分片时，先将分布式缓存中的产品信息复制到本匹配服务器的内存中，然后按照前面描述的步骤进行匹配处理。采用这种方式，既可以提高启动匹配分片的效率，同时也降低了由于大量并发访问对数据库造成的压力。(关于上面提到的分布式缓存的概念，请参见下文预扣减库存部分的相关描述。)
[0139]上面描述的技术方案采用的是定时任务触发中心匹配服务器、中心匹配服务器再触发所有匹配服务器的方式，在其他实施方式中，也可以采取由定时任务直接触发所有匹配服务器的方式；上面描述的技术方案采用由中心匹配服务器计算匹配分片的处理截止时间并发送给每台匹配服务器的方式，在其他实施方式中，也可以在每台匹配服务器上预先设置每个匹配分片的处理时间区间的长度，由各台匹配服务器自行根据当前的启动时间和预先设置的处理时间区间的长度计算得到当前匹配分片的处理截止时间；上面描述的技术方案采用由中心服务器加载产品信息的方式，在其他实施方式可以采用其他加载方式或者采用与单机模式类似的方式。上述都只是【具体实施方式】的变更，都不偏离本申请的核心，因此都在本申请的保护范围之内。
[0140]采用单机模式或者是集群模式，在具体的实施过程中会有一些差别，但是都不影响本申请的技术方案的核心，只要按照本申请的技术方案，正确地指定匹配分片的处理截止时间，并且在没有拉取到提交时间晚于匹配分片处理截止时间的购买申请之前，所述匹配分片一直处于工作状态，那么就可以从时间维度上明确匹配分片的处理范围；基于这一确定性，还可以继续扩展本技术方案，将上述匹配分片的工作方式应用在基于定时任务的分片式匹配系统中，并且通过对启动匹配分片的定时间隔和每个匹配分片的处理截止时间的合理设置，使每个匹配分片的处理截止时间略小于或者等于下一个匹配分片的启动时间，从而可以在基于定时任务的分片式匹配系统中