CN108416665B

CN108416665B - Data interaction method and device, computer equipment and storage medium

Info

Publication number: CN108416665B
Application number: CN201810123801.5A
Authority: CN
Inventors: 花海勇; 栾继臣
Original assignee: Ping An Puhui Enterprise Management Co Ltd
Current assignee: Ping An Puhui Enterprise Management Co Ltd
Priority date: 2018-02-07
Filing date: 2018-02-07
Publication date: 2020-08-04
Anticipated expiration: 2038-02-07
Also published as: CN108416665A

Abstract

The application relates to a data interaction method, a data interaction system, computer equipment and a storage medium. The method comprises the following steps: extracting loan application data at a plurality of source servers; the loan application data includes an origin server identification; determining a guarantee party identifier adaptive to the loan application data according to a preset rule; respectively generating corresponding loan tasks by utilizing the extracted multiple groups of loan application data; the loan task has a corresponding task identifier; calling a target interface, generating a calling record by using the task identifier and the corresponding source server identifier, and respectively sending a plurality of loan tasks to the target servers corresponding to the corresponding guarantor identifiers by using the target interface; when receiving a guarantee result returned by the target server, the guarantee result carries a task identifier; and inquiring the source server identification corresponding to the task identification in the guarantee result in the stored multiple call records, and sending the guarantee result to the corresponding source server. By adopting the method, the data interaction cost can be reduced.

Description

Data interaction method and device, computer equipment and storage medium

Technical Field

The present application relates to the field of computer technologies, and in particular, to a data interaction method and apparatus, a computer device, and a storage medium.

Background

With the development of internet finance, P2P network loan (hereinafter referred to as "network loan") is increasingly well known due to its convenience and transparency. The main mode of the network loan is that the lender and the investor freely compete on the network loan platform to make a deal. The investor obtains interest income and bears risks, the lender pays the principal due, and the credit company providing the network lending platform charges agency service fee. The collateral mode of the online crediting platform includes third party collateral. The third party guaranty means that a third party (hereinafter referred to as a "guarantor") legally assumes responsibility for compensation of an investor when the lender does not fulfill the debt on the investor.

The traditional network credit platform based on the third party guarantee mode only supports a single guarantee function, in other words, one network credit platform can only be guaranteed by a single guarantee party. If a guarantor wants to provide a guarantee for more lenders through a plurality of network lending platforms, a target server corresponding to the guarantor needs to perform data interaction with platform servers corresponding to different network lending platforms and different platform servers corresponding to the same network lending platform respectively, so that the target server and the platform servers have strong coupling. The target server needs to implement complex interaction logic with the platform server through programming, so that the data interaction cost is increased.

Disclosure of Invention

In view of the above, it is necessary to provide a data interaction method, an apparatus, a computer device and a storage medium capable of reducing data interaction cost.

A method of data interaction, the method comprising: extracting loan application data at a plurality of source servers; the loan application data includes an origin server identification; determining a guarantee party identifier which is adaptive to the loan application data according to a preset rule; utilizing the extracted multiple groups of loan application data to respectively generate corresponding loan tasks; the loan task has a corresponding task identifier; calling a target interface, generating a calling record by using the task identifier and the corresponding source server identifier, and respectively sending the plurality of loan tasks to the target servers corresponding to the corresponding guarantor identifiers by using the target interface; when receiving a guarantee result returned by the target server, the guarantee result carries a task identifier; and inquiring the source server identification corresponding to the task identification in the guarantee result in the stored multiple call records, and sending the guarantee result to the corresponding source server.

In one embodiment, before the step of determining the identifier of the guarantor corresponding to the loan application data according to the preset rules, the method further comprises: calculating data quantities corresponding to the plurality of groups of loan application data respectively; monitoring the loads of other servers in the cluster to which the server belongs; acquiring a preset load balancing file, and determining the total data volume of loan application data which can be processed by a plurality of servers in a cluster according to the load balancing file; and dividing the plurality of groups of loan application data into a plurality of parts according to the total data volume, and distributing each part of loan application data to a corresponding server in the cluster.

In one embodiment, the loan application data further comprises a loan identifier and an application amount; the step of determining the guarantor identification adapted to the loan application data according to a preset rule comprises: obtaining a message queue corresponding to the loan identifier; the message queue comprises a plurality of guarantor identifications and corresponding guarantor states; the vouching status comprises guaranteed and non-guaranteed; traversing the acquired message queue according to a preset traversing direction, and screening a first guarantee party identifier with an unsecured guarantee state; calculating the remaining guarantee amount corresponding to the screened guarantee party identification; comparing whether the remaining guarantee amount is larger than or equal to the application amount; if yes, marking the screened guarantor identification as the guarantor identification corresponding to the loan application data, and changing the guaranty state of the screened guarantor identification into the guaranty; otherwise, screening the guarantor identification with the next guarantor state being non-guaranty, returning to the step of calculating the remaining guaranty amount corresponding to the screened guarantor identification until the guarantor identification corresponding to the loan application data is determined.

In one embodiment, the plurality of sponsor identifications in the message queue have different sponsor proportions; the step of obtaining the message queue corresponding to the loan identifier comprises the following steps: detecting whether a corresponding message queue exists or not according to the loan identifier; when the corresponding message queue does not exist, acquiring a plurality of guarantor identifications corresponding to the loan identification; determining the guarantee sequence of the plurality of guarantor identifications according to the obtained guarantee proportion of the plurality of guarantor identifications; acquiring a preset queue length, and determining the guarantee times of a plurality of guarantor identifications according to the queue length and the guarantee proportion of the plurality of guarantor identifications; and generating a corresponding message queue by using a plurality of guarantor identifications according to the guaranty sequence and the guaranty times.

In one embodiment, before the step of sending the plurality of loan tasks to the target servers corresponding to the corresponding guarantor identifications respectively by using the target interface, the method further includes: receiving a newly increased guarantee party request sent by a configuration terminal; according to the newly added request of the guarantor, returning a configuration page to the configuration terminal, so that the configuration terminal obtains the configuration information recorded in the configuration page; and receiving configuration information returned by the configuration terminal, and establishing a communication link with a target server corresponding to the guarantor identifier according to the configuration information.

In one embodiment, the step of sending the plurality of loan tasks to the target servers corresponding to the corresponding guarantor identifications respectively by using the target interface includes: packing the loan tasks corresponding to the same guarantor identification to obtain a plurality of task data packets; calling a plurality of target interfaces, and synchronously sending a plurality of task data packets to a target server corresponding to a corresponding guarantor identifier by using the plurality of target interfaces; acquiring a forwarding log generated in the sending process, and detecting whether forwarding abnormality exists according to the forwarding log; adding the loan tasks with abnormal forwarding to a cache queue; and when the corresponding task data packet is sent, resending the loan task in the cache queue.

In one embodiment, before the step of querying the stored multiple call records for the source server identifier corresponding to the task identifier in the guarantee result, the method further comprises: when the guarantee result is that the guarantee is refused, traversing the message queue again, and detecting whether other guarantee party identifiers which are suitable for the loan application data exist or not; if not, splitting the loan application data according to the application limit and a residual guarantee limit corresponding to a guarantee party identifier with an unsecured guarantee state in the message queue to obtain a plurality of sub-item application data with different application limits; and traversing the message queue again, screening the guarantor identifications adapted to the sub-item application data, respectively sending the sub-item application data to the target servers corresponding to the corresponding guarantor identifications, and returning to the step of receiving the guarantor result returned by the target servers.

A data interaction apparatus, the apparatus comprising: the data acquisition module is used for extracting loan application data from a plurality of source servers; the loan application data includes an origin server identification; the guarantor determining module is used for determining a guarantor identifier which is adaptive to the loan application data according to a preset rule; the data forwarding module is used for respectively generating corresponding loan tasks by utilizing the extracted multiple groups of loan application data; the loan task has a corresponding task identifier; calling a target interface, generating a calling record by using the task identifier and the corresponding source server identifier, and respectively sending the plurality of loan tasks to the target servers corresponding to the corresponding guarantor identifiers by using the target interface; the guarantee result feedback module is used for receiving the guarantee result returned by the target server, and the guarantee result carries the task identifier; and inquiring the source server identification corresponding to the task identification in the guarantee result in the stored multiple call records, and sending the guarantee result to the corresponding source server.

A computer device comprising a memory and a processor, the memory storing a computer program, the processor implementing the following steps when executing the computer program: determining a guarantee party identifier which is adaptive to the loan application data according to a preset rule; utilizing the extracted multiple groups of loan application data to respectively generate corresponding loan tasks; the loan task has a corresponding task identifier; calling a target interface, generating a calling record by using the task identifier and the corresponding source server identifier, and respectively sending the plurality of loan tasks to the target servers corresponding to the corresponding guarantor identifiers by using the target interface; when receiving a guarantee result returned by the target server, the guarantee result carries a task identifier; and inquiring the source server identification corresponding to the task identification in the guarantee result in the stored multiple call records, and sending the guarantee result to the corresponding source server.

A computer-readable storage medium, on which a computer program is stored which, when executed by a processor, carries out the steps of: determining a guarantee party identifier which is adaptive to the loan application data according to a preset rule; utilizing the extracted multiple groups of loan application data to respectively generate corresponding loan tasks; the loan task has a corresponding task identifier; calling a target interface, generating a calling record by using the task identifier and the corresponding source server identifier, and respectively sending the plurality of loan tasks to the target servers corresponding to the corresponding guarantor identifiers by using the target interface; when receiving a guarantee result returned by the target server, the guarantee result carries a task identifier; and inquiring the source server identification corresponding to the task identification in the guarantee result in the stored multiple call records, and sending the guarantee result to the corresponding source server.

According to the data interaction method, the data interaction device, the computer equipment and the storage medium, the user can directly send loan application data to the source server through the user terminal; according to the preset rule, the guarantee party identification corresponding to the loan application data can be determined; a calling record corresponding to each loan task can be generated by calling the target interface; the loan tasks respectively corresponding to a plurality of groups of loan application data can be sent to the target server corresponding to the corresponding guarantor identification by using the target interface; when receiving the guarantee result returned by the target server, the source server identifier corresponding to the task identifier can be inquired in the stored multiple call records according to the task identifier carried by the guarantee result, and then the guarantee result can be sent to the corresponding source server. Because the corresponding guarantor identification is identified through the loan application data, the identification of the service party corresponding to the target interface can be realized; and determining the source server identifier corresponding to the guarantee result according to the call record, so that the caller corresponding to the target interface can be identified, and the accurate forwarding of data can be realized by utilizing the target interface. Compared with the traditional method that the target server needs to perform data interaction with a plurality of platform servers respectively, the method has the advantages that the coupling between the target server and the platform servers can be reduced, the interaction logic is simple, the programming cost of the target server for performing data interaction can be reduced, and the data interaction cost is reduced.

Drawings

FIG. 1 is a diagram of an application scenario of a data interaction method in one embodiment;

FIG. 2 is a flow diagram that illustrates a method for data interaction in one embodiment;

FIG. 2A is a diagram of an application framework for a method of data interaction in one embodiment;

FIG. 3 is a block diagram showing the structure of a data interaction device according to an embodiment;

FIG. 4 is a diagram illustrating an internal structure of a computer device according to an embodiment.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the present application is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application.

The data interaction method provided by the application can be applied to the application environment shown in fig. 1. Wherein, the user terminal 102 communicates with the platform server 104 through a network; the platform server 104 communicates with the target server 106 over a network. The platform server 104 includes an origin server (hereinafter referred to as "first server") 1042 and a second server 1044. The user terminal 102 may be, but is not limited to, various personal computers, notebook computers, smart phones, tablet computers, and portable wearable devices. The first server 1042, the second server 1044 and the target server 106 may be implemented by independent servers or a server cluster composed of a plurality of servers. The user terminal 102 may be a terminal corresponding to a lender or a terminal corresponding to a loan counter service person, so that the user may apply for a loan based on a network loan platform on the user terminal 102 or may apply for a loan through a counter channel. The loan platform may be an APP (Application, at least one of an Application, a website, or an applet) capable of performing loan transactions, different loan channels correspond to different first servers 1042, the first servers 1042 are configured to receive loan Application data sent by the user terminal 102 through corresponding loan channels, the second servers 1044 are configured to process a plurality of loan Application data, the target servers 106 are servers corresponding to a sponsor, and the platform server 104 may access the target servers 106 through configuration.

When a user applies for a loan based on the online loan platform on the user terminal 102, the user terminal 102 obtains loan application data entered by the user, and sends the loan application data to the corresponding first server 1042. The first server 1042 receives and stores loan application data within a preset duration. The loan application data includes an origin server identification. The second server 1044 extracts a plurality of groups of loan application data from the plurality of first servers 1042 respectively according to a preset time frequency. And the second server 1044 respectively performs credit verification on each group of loan application data and determines the guarantor identification corresponding to each group of loan application data passing the verification according to a preset rule. The second server 1044 generates loan tasks corresponding to each group of loan application data respectively. The loan job has a corresponding job identification. The second server 1044 calls the target interface, generates a call record corresponding to each loan task by using the task identifier and the corresponding source server identifier, and sends the plurality of loan tasks to the target servers 106 corresponding to the corresponding guarantor identifiers by using the target interface. The target server 106 determines whether to guarantee based on the loan application data. When receiving the guarantee result returned by the target server 106, the second server 1044 matches the guarantee result with the stored multiple call records according to the task identifier carried by the guarantee result, and returns the guarantee result to the corresponding first server 1042 according to the source server identifier included in the call record successfully matched. The first server 1042 returns the vouching result to the corresponding user terminal 102. In the loan data processing process, the adaptive guarantor identification is automatically screened and determined according to the preset message queue, so that the loan application efficiency can be improved; the plurality of target servers only need to perform data interaction with the second server, so that the coupling between the target servers and the platform server can be reduced, the interaction logic is simple, and the programming cost or hardware cost for performing data interaction by the target servers can be reduced.

In one embodiment, as shown in fig. 2, a data interaction method is provided, which is described by taking the application of the method to the platform server in fig. 1 as an example, and includes the following steps:

step 202, extracting loan application data from a plurality of source servers; the loan application data includes an origin server identification.

Users in different geographic regions can apply for loan through various loan channels such as APP, websites or counter. As shown in fig. 2A, in order to improve the efficiency of loan application, the first servers may be respectively disposed in different geographic areas, in other words, the different geographic areas correspond to different data processing backgrounds. Different loan channels in the same geographic region correspond to different data processing backgrounds, namely a first server.

When the user needs to apply for the loan, loan application data can be input through the user terminal. The loan application data includes applicant information, application amount, loan resource type, and the like. The applicant information includes an application identifier, applicant contact information, and the like. The loan resource type refers to the type of loan product. The loan resource type can be a type of loan product selected by the user after knowing the attribute information of interest rate of borrowing, term of borrowing, repayment mode and the like of different loan products. In order to distinguish loan application data from different loan channels in different geographic regions, a first server adds a source server identifier to the received loan application data. The source server identification includes a loan channel identification and/or a geographic region identification.

The first server packages the loan application data of the users received within the preset time. Specifically, the preset time period may be freely set according to actual requirements, such as 24 hours. The first server detects whether the total data volume of the loan application data received within a preset time exceeds a threshold value. And if so, the first server divides the loan application data of the users into multiple parts, and packages each part of the loan application data to obtain multiple loan application data packets. And the second server respectively extracts the loan application data packets from the plurality of first servers according to a preset time frequency. The loan application data of a plurality of users within the preset time length are extracted in a centralized manner, and compared with the method that the loan application data of one user is extracted once, the interaction frequency between the second server and the first server can be reduced, so that the occupation of resources of the second server can be reduced.

And step 204, determining the guarantor identification which is adaptive to the loan application data according to a preset rule.

And the second server analyzes the loan application data packet extracted from the first server to obtain a plurality of groups of loan application data, wherein each group of loan application data comprises one or more loan identifiers. The loan identifier includes at least one of a loan resource type, a loan channel identifier, or a geographic region identifier. The second server stores a plurality of loan identifier combinations and one or more sponsor identifiers corresponding to each loan identifier combination in advance. The loan identifier combination includes one or more loan identifiers. The sponsor identification may be the sponsor's organization code or the like. For example, the sponsor identifier corresponding to the loan identifier combination "beijing + APP" may be sponsor a, sponsor B, and sponsor C.

When the guarantor identification corresponding to the loan identification combination comprises a plurality of guarantor identifications, the second server generates a message queue corresponding to the loan identification combination by using the guarantor identification. The message queue may set a corresponding expiry date, such as 1 month. The plurality of vouchers' identities in the message queue have different vouching proportions. The proportion of vouching that the same vouching party identity is in different message queues may be different. For example, in the message queue a generated by the above-mentioned guarantor a, the guarantor B, and the guarantor C, the guarantor ratio corresponding to the three guarantor identifiers is 10%, 70%, and 20% in this order. The message queue B includes four guarantor identifications, guarantor a, guarantor C, guarantor D, and guarantor E, corresponding to a guarantor ratio of 30%, 10%, 45%, and 15%.

And the second server acquires the message queue corresponding to the loan identifier in each group of loan application data which passes the credit verification, traverses the acquired message queue, and screens the guarantor identifier which is adaptive to the loan application data according to a preset rule.

Step 206, generating corresponding loan tasks by using the extracted multiple groups of loan application data respectively; the loan job has a corresponding job identification.

Step 208, calling a target interface, and generating a calling record by using the task identifier and the corresponding source server identifier; and respectively sending the plurality of loan tasks to the target servers corresponding to the corresponding guarantor identifications by using the target interfaces.

And after the guarantor identification corresponding to each group of loan application data is determined, the second server respectively generates corresponding loan tasks by using the plurality of groups of loan application data. The loan job has a corresponding job identification. The task identification may be a batch number or the like. And the second server calls a preset target interface to respectively forward the plurality of loan tasks to the target server corresponding to the corresponding guarantor identification. The target interface includes a call logging function. When the target interface is called, a callback instruction to the call record function is generated. And the second server executes a call record function according to the callback instruction, acquires corresponding task identification and call time from the source server identification in the loan application data, and generates a corresponding call record by using the acquired source server identification, task identification, call time and the like.

Step 210, when receiving the guarantee result returned by the target server, the guarantee result carries the task identifier; and inquiring the source server identification corresponding to the task identification in the guarantee result in the stored multiple call records, and sending the guarantee result to the corresponding source server.

And when a guarantee result returned by the target server is received, the second server inquires the source server identifier corresponding to the task identifier in the stored multiple call records according to the task identifier carried by the guarantee result. Specifically, the second server matches the task identifier in the guarantee result with the stored multiple call records respectively. And acquiring the source server identification contained in the successfully matched call record. And the second server sends the guarantee result to the first server corresponding to the obtained source server identification. The vouching result also carries applicant contact information. And the first server returns the guarantee result to the corresponding user terminal according to the applicant contact information. The second server does not directly return the guarantee result to the user terminal, but returns the guarantee result to the corresponding first server first, and the first server performs specific distribution of the guarantee result according to the applicant information and the like, so that the task of data forwarding is dispersed to the plurality of first servers, the data forwarding frequency of the second server can be reduced, the occupation of resources of the second server is reduced, and the data forwarding efficiency can be improved.

In the embodiment, the user can directly send loan application data to the source server through the user terminal; according to the preset rule, the guarantee party identification corresponding to the loan application data can be determined; a calling record corresponding to each loan task can be generated by calling the target interface; the loan tasks respectively corresponding to a plurality of groups of loan application data can be sent to the target server corresponding to the corresponding guarantor identification by using the target interface; when receiving the guarantee result returned by the target server, the source server identifier corresponding to the task identifier can be inquired in the stored multiple call records according to the task identifier carried by the guarantee result, and then the guarantee result can be sent to the corresponding source server. Because the corresponding guarantor identification is identified through the loan application data, the identification of the service party corresponding to the target interface can be realized; and determining the source server identifier corresponding to the guarantee result according to the call record, so that the caller corresponding to the target interface can be identified, and the accurate forwarding of data can be realized by utilizing the target interface. Compared with the traditional method that the target server needs to perform data interaction with a plurality of platform servers respectively, the method has the advantages that the coupling between the target server and the platform servers can be reduced, the interaction logic is simple, the programming cost of the target server for performing data interaction can be reduced, and the data interaction cost is reduced.

The second server is a server cluster formed by a plurality of servers. The cluster to which the second server belongs includes a plurality of other servers, and the plurality of other servers share the same database. The second server is deployed with a load balancer for monitoring the load of a plurality of other servers in the cluster. The load balancer stores a load balancing file in advance. The load balancing file records a plurality of data volume intervals and corresponding load intervals. The load interval comprises a CPU resource utilization rate interval, a memory occupancy rate interval and the like. For example, a load interval may be 50% to 60% of the CPU resource utilization rate and 40% to 50% of the memory occupancy rate, and the data volume interval corresponding to the load interval may be 2400 to 2600.

The second server monitors the load of a plurality of other servers within the cluster using the load balancer. And determining the load interval corresponding to each other server in the cluster. And the second server inquires a corresponding data volume interval in the load balancing file according to the load interval corresponding to each other server in the cluster, so that the total data volume of the loan application data which can be respectively processed by a plurality of other servers in the cluster is determined.

And the second server divides the plurality of groups of loan application data into a plurality of shares according to the total data volume. For example, suppose that loan application data corresponding to three applicant identifications A, B and C are extracted, the data amount of the loan application data corresponding to the applicant identification a is 1800, the data amount of the loan application data corresponding to the applicant identification B is 3600, and the data amount of the loan application data corresponding to the applicant identification C is 700. The cluster comprises other four servers A, B, C and D, wherein the load of the server A is 52% of the CPU resource utilization rate, and the memory occupancy rate is 47%. And determining that the data volume interval corresponding to the first server is 2400-2600 according to the load balancing file, and the data volume interval corresponding to the second insurance server is 3300-3700, determining the loan application data corresponding to the applicant identifications A and C as a first part, and determining the loan application data corresponding to the applicant identification B as a second part. The third server and the fourth server do not obtain loan application data, which means that the current time load of the two servers is higher, namely the data volume of the loan application data currently being processed is larger. It should be understood that the above examples are for the convenience of the reader only, and the actual meaning of specific numbers may not be considered.

In this embodiment, the load of the server in the cluster to which the loan application data belongs is monitored, so that the data volume of the loan application data being processed by each server in the cluster at the current time can be obtained. When the data volume of the loan application data processed by one server in the cluster at the current time is large, and the corresponding load is high, new loan application data is not distributed or the loan application data with small data volume is distributed; and for the loan application data which are processed at the current time, the loan application data with a large data volume can be distributed corresponding to the server with a low load. The loan application data are distributed to other corresponding servers in the cluster respectively, so that the loan application data are synchronously processed by the servers, the loan application efficiency can be improved, the data processing load of a single server can be reduced, and the load balance is realized.

In one embodiment, the loan application data further includes an applicant identification; the step of determining the guarantor identification which is adapted to the loan application data according to the preset rule comprises the following steps: acquiring a preset credit blacklist, wherein the credit blacklist comprises a plurality of applicant identifications; detecting whether the applicant identification in the loan application data belongs to a credit blacklist or not; when the loan application data does not belong to the credit blacklist, performing credit verification on the loan application data; and determining the guarantor identification which is adaptive to the loan application data passing the credit verification according to the preset rules according to the preset multiple loan identification combinations and the corresponding message queues respectively.

In order to reduce unnecessary data processing, the second server checks each group of extracted loan application data, and only when the check is passed, the subsequent step of screening the guarantee party identification is carried out. Specifically, the second server performs multi-level verification on the loan application data. The second server first verifies whether the applicant identification in the loan application data is within a predetermined credit blacklist. And when the applicant mark in the loan application data is in a preset credit blacklist, the second server returns the prompt information of loan failure to the corresponding user terminal. And when the applicant identification in the loan application data is not in a preset credit blacklist, the second server further performs credit verification on the loan application data, and if the credit verification is passed, the guarantee party identification corresponding to the loan application data is determined according to the method.

In this embodiment, before the loan application data matches the sponsor identifier, the loan application data is subjected to multi-level verification, which can reduce unnecessary data processing, thereby reducing the occupation of server resources.

In one embodiment, the loan application data further includes an application amount and a loan resource type; the credit checking step of the loan application data comprises the following steps: generating credit investigation requests corresponding to a plurality of preset credit investigation platforms according to the applicant identification, and calling multithreading to send the credit investigation requests to the corresponding preset credit investigation platforms in parallel; receiving credit investigation records respectively returned by a plurality of preset credit investigation platforms, analyzing the credit investigation records and generating a comprehensive credit record corresponding to the applicant identification; calculating a credit value corresponding to the applicant identification according to the comprehensive credit record; determining a loan upper limit line corresponding to the loan resource types in the loan application data according to the preset corresponding relation between the multiple loan resource types and the loan upper limit line; and when the credit value reaches the threshold value and the application limit does not exceed the corresponding loan upper limit, the loan application data passes the verification.

The preset credit investigation platform comprises at least one of a third-party payment platform, a public security bureau service platform, a social security bureau service platform, an online banking platform, an insurance service platform or other online credit platforms. The second server generates a plurality of credit investigation requests corresponding to the preset credit investigation platforms respectively according to the applicant identification, calls multiple threads and sends the plurality of credit investigation requests to the corresponding preset credit investigation platforms in parallel, so that credit verification efficiency is improved, and loan application efficiency is further improved. And the second server receives credit investigation records respectively returned by the plurality of preset credit investigation platforms. The credit investigation record can be a social security public accumulation fund payment record, a bank bill and the like. It is easy to understand that the second server can also obtain more credit investigation records corresponding to the applicant identification through a web crawler or the like. And when the credit investigation records respectively returned by the plurality of preset credit investigation platforms are received, the second server analyzes the plurality of credit investigation records to generate the comprehensive credit record corresponding to the applicant identification. The comprehensive credit record includes multiple credit indicators, such as the existence of house credits and the like.

The second server presets a plurality of credit indexes and corresponding credit scores respectively. The server acquires the credit score corresponding to each credit index in the comprehensive credit record, sums the credit scores corresponding to the credit indexes to obtain the credit score corresponding to the applicant identification, namely the credit value. The second server compares whether the credit value reaches a threshold value. The second server also presets the corresponding relation between various loan resource types and loan upper limit. And the second server acquires the loan upper limit line corresponding to the loan resource type in the loan application data according to the corresponding relation, and detects whether the application limit line exceeds the corresponding loan upper limit line. And when the credit value reaches the threshold value and the application amount does not exceed the corresponding loan upper limit amount, indicating that the loan application data passes the verification.

In the embodiment, credit verification is carried out on the loan application data, risk control can be carried out on the loan application, and the credit value and the loan upper limit amount are simultaneously used as risk control conditions, so that the operation risk of the network loan platform can be reduced; and multithreading is called to collect credit investigation records corresponding to the applicant identifications in parallel on a plurality of credit investigation platforms, so that the credit verification efficiency can be improved, and the loan application efficiency is further improved.

In one embodiment, the loan application data further includes a loan identification and an application amount; the step of determining the guarantor identification which is adapted to the loan application data according to the preset rule comprises the following steps: obtaining a message queue corresponding to the loan identifier; the message queue comprises a plurality of guarantor identifications and corresponding guarantor states; the guaranteed state includes guaranteed and unsecured; traversing the acquired message queue according to a preset traversing direction, and screening a first guarantee party identifier with an unsecured guarantee state; calculating the remaining guarantee amount corresponding to the screened guarantee party identification; comparing whether the remaining guarantee amount is greater than or equal to the application amount; if yes, marking the screened guarantor identification as the guarantor identification corresponding to the loan application data, and changing the guaranty state of the screened guarantor identification into the guaranty; otherwise, screening the guarantor identification with the next guarantor state being non-guaranty, returning to the step of calculating the remaining guaranty amount corresponding to the screened guarantor identification until the guarantor identification corresponding to the loan application data is determined.

The second server extracts the loan identifier from the loan application data, and detects whether there is a guarantee party identifier corresponding to the extracted loan identifier. And if the corresponding guarantor identification does not exist, the second server acquires the default guarantor identification, and marks the default guarantor identification as the guarantor identification corresponding to the loan application data. If a corresponding sponsor identifier exists, the second server marks the corresponding sponsor identifier as a sponsor identifier adapted to the loan application data. If a plurality of corresponding guarantor identifications exist, the second server detects whether a corresponding message queue exists. And when the corresponding message queue does not exist, the second server acquires a plurality of guarantor identifications corresponding to the loan identification in the loan application data, and generates the message queue by using the acquired plurality of guarantor identifications. The message queue records the vouching state corresponding to each vouching party identification. The vouched status includes vouched and unsecured.

And traversing the acquired message queue by the second server according to a preset traversing direction, screening the guarantee party identifier with the first guarantee state being not guaranteed, and calculating the remaining guarantee limit corresponding to the screened guarantee party identifier. The preset traversal direction may be a positive traversal or a negative traversal. The second server compares whether the remaining guarantee quota is greater than or equal to the application quota. If yes, the second server directly marks the screened guarantor identification as the guarantor identification corresponding to the loan application data. Otherwise, the second server traverses the message queue again according to the mode and detects whether other guarantor identifications adaptive to the loan application data exist. In other words, the second server screens the guarantee party identifier with the next guarantee order state as non-guarantee, and detects whether the remaining guarantee amount of the screened guarantee party identifier is greater than or equal to the application amount until a guarantee party identifier corresponding to the loan application data is determined.

In another embodiment, before traversing the message queue, the second server compares whether the application credit exceeds a preset value. The preset value refers to the highest application amount of a single loan allowed by the online loan platform. And if so, the second server splits the loan application data according to the application amount to obtain multiple sub-item application data. The sub-item application data has different application quota, and the application quota corresponding to different sub-item application data can be the same or different. The second server determines the corresponding guarantor identification of each sub-item application data according to the method, and the guarantor identifications corresponding to the sub-item application data are marked as the corresponding guarantor identifications of the loan application data together, so that the plurality of guarantors guarantee the high-volume loan application together, the loan application success rate is improved, and the loan application efficiency is further improved indirectly.

In another embodiment, before the step of querying the stored plurality of call records for the source server identifier corresponding to the task identifier in the vouch-for result, the method further comprises: when the guarantee result is that the guarantee is refused, traversing the message queue again, and detecting whether other guarantee party identifiers which are suitable for the loan application data exist or not; if not, the loan application data is split according to the application limit and the remaining guarantee limit corresponding to the guarantee party identifier with the guarantee state of being not guaranteed in the message queue to obtain a plurality of sub-item application data with different application limits; and traversing the message queue again, screening the guarantor identifications adapted to the sub-item application data, respectively sending the sub-item application data to the target servers corresponding to the corresponding guarantor identifications, and returning to the step of receiving the guarantor result returned by the target servers.

And after the second server sends the loan application data to the target server corresponding to the corresponding guarantee party identification, if a guarantee result of refusing guarantee returned by the target server is received, the second server traverses the message queue again according to the mode and detects whether other guarantee party identifications adaptive to the loan application data exist. If the information queue is traversed, the guarantee party identification corresponding to the loan application data does not exist, the second server splits the loan application data according to the application limit and the remaining guarantee limit corresponding to the guarantee party identification of which the guarantee state is not guaranteed in the information queue to obtain a plurality of sub-item application data with different application limits; and traversing the message queue again, screening the guarantor identifications adapted to the sub-item application data, respectively sending the sub-item application data to the target servers corresponding to the corresponding guarantor identifications, and receiving the guarantor result returned by the target servers. In the embodiment, when the application limit is high and causes a plurality of security parties to refuse to secure, the second server automatically adjusts the application limit according to the loan application data, and compared with the traditional mode that only a security result is mechanically returned to the user terminal after the security result refusing the security is received, the user adjusts the application limit, the success rate of loan application security can be improved, and therefore the efficiency of loan application can be improved.

It is easy to understand that there are many ways to improve the loan application guarantee success rate and further improve the loan application efficiency besides splitting the loan application data, which are not listed here.

In the embodiment, the user can carry out loan based on a plurality of guarantors only by inputting loan application data in one online loan platform, and the guarantors automatically screen and determine according to the preset message queue, so that the loan application efficiency can be improved. The remaining guarantee amount is dynamically calculated in real time, so that the remaining guarantee amount can more accurately reflect the current actual guarantee capability of the guarantee party identifier, and the accuracy of determining the guarantee party identifier is improved. When the remaining guarantee amount of the guarantee party identification in the guarantee state of non-guarantee is lower than the application amount, the other guarantee party identifications are automatically screened, the loan application guarantee success rate is improved, and the loan application efficiency can be further improved.

In one embodiment, multiple vouchers' identities in the message queue have different vouching proportions; the step of obtaining the message queue corresponding to the loan identifier comprises the following steps: detecting whether a corresponding message queue exists or not according to the loan identifier; when the corresponding message queue does not exist, acquiring a plurality of guarantor identifications corresponding to the loan identification; determining the guarantee sequence of the plurality of guarantor identifications according to the obtained guarantee proportion of the plurality of guarantor identifications; acquiring a preset queue length, and determining the guarantee times of a plurality of guarantor identifications according to the queue length and the guarantee proportion of the plurality of guarantor identifications; and generating a corresponding message queue by using a plurality of guarantor identifications according to the guaranty sequence and the guaranty times.

The second server sorts the plurality of sponsor identifiers according to the obtained sponsor ratio of the plurality of sponsor identifiers and the sponsor ratio from small to large, and the order is used as the sponsor order of the plurality of sponsor identifiers. For example, in the above example, the loan identifier combination "beijing + APP" may correspond to a plurality of collateral identifiers in the order of the collateral, which are the collateral a, the collateral C, and the collateral B. And the second server acquires the preset queue length. The preset queue length refers to the total number of the message queues expected to be generated and containing the guarantor identifications. The second server multiplies the queue length by the guarantee proportion corresponding to each guarantor identification, and takes the obtained product as the guarantee times of the corresponding guarantor identification. For example, in the above example, assuming that the queue length is 100, the number of guarantees by the guarantor a is 100 × 10 ═ 10 times, the number of guarantees by the guarantor B is 100 × 70 ═ 70 times, and the number of guarantees by the guarantor C is 100 × 20 × -20 times.

The second server generates a corresponding message queue using the plurality of sponsor identifiers according to the guarantee sequence and the guarantee times of each sponsor identifier. For example, in the example above, the message queue generated by cross-queuing guarantor A, guarantor C, and guarantor B may be A, C, B, A, C · C, B, C · B, B. Wherein, after 10 times of appearance, the guarantor A remains the guarantor B, the guarantor C remains the guarantor B after 20 times of appearance. It is to be easily understood that the present application only exemplarily shows one generation manner in the message queue, and the message queue may also be generated in other manners, such as sequentially arranging the guarantor a, the guarantor C, and the guarantor B, and the generated message queue may also be A, A, A · · C, C, C · B, B · B, and for example, the sub-queue A, B, C, C, C, C, B, C, C, C is cycled for 10 times to generate the message queue, and the like, which is not limited in this respect.

In the embodiment, the guarantee party identifier is determined according to the message queue, so that the determination of the guarantee party identifier is simple in logic, the guarantee party identifier determination efficiency can be improved, and the loan application efficiency can be improved; corresponding guarantor identifications are preset according to different loan identification combinations, the information queue is generated according to the guarantor identifications corresponding to the preset loan identification combinations, and the information queue is generated by fully combining the guarantor proportions corresponding to the multiple guarantor identifications, so that some improper loan applications can be guaranteed by some guarantor parties, and the accuracy of determining the guarantor identifications is improved.

In one embodiment, the step of calculating the remaining guarantee amount corresponding to the screened guarantor identification comprises: acquiring a total share degree and a historical guarantee record corresponding to the guarantee party identifier; counting the guaranteed limit corresponding to the identity of the guarantor according to the historical guaranty record; measuring and calculating the on-road guarantee amount corresponding to the guarantee party identification according to the plurality of groups of loan application data extracted from the source server; and calculating the remaining guarantee limit corresponding to the guarantee party identifier according to the total guarantee limit, the guaranteed limit and the on-the-way guarantee limit.

Different sponsor identities have different total guarantee amounts. The total security degree can be configured in the second server in advance according to the legal security limit applied by the corresponding security party in the security prison. The second server obtains a historical guarantee record corresponding to the guarantee party identifier. The historical underwriting record includes the number of times the sponsor identifier was flagged as a sponsor identifier appropriate to the loan application data, the time of the flagging, and the corresponding underwriting results. The second server obtains the application amount corresponding to one or more times of guarantee with the guarantee result of agreement guarantee, sums the application amount corresponding to one or more times of guarantee, and takes the sum result as the guaranteed amount corresponding to the guarantee party identification.

The appropriate sponsor identifier has been determined in the manner described above, but the loan application data for which the results of the guarantee have not been received belongs to an in-transit loan. The second server obtains the amount of the in-transit loan corresponding to the guarantor identification. The second server prestores the average amount of the unit quantity on-the-way loans and the agreement guarantee probability corresponding to a plurality of guarantee party identifications. The second server calculates the product of the number of the loans in transit, the average amount and the probability of agreeing to guarantee corresponding to the guarantee party identification, and the product is used as the guarantee amount in transit corresponding to the corresponding guarantee party identification. The second server calculates a first difference value between the total guarantee amount and the guaranteed amount, calculates a second difference value between the first difference value and the on-road guarantee amount, and takes the second difference value as a remaining guarantee amount corresponding to the corresponding guarantee party identifier.

In this embodiment, the total guarantee amount, the guaranteed amount, and the remaining guarantee amount corresponding to the guarantee party identifier may change at any time, and when a certain guarantee party identifier is traversed in the message queue, the remaining guarantee amount corresponding to the guarantee party identifier is calculated in real time, so that the remaining guarantee amount can more accurately reflect the current actual guarantee capability of the guarantee party identifier, and the accuracy of determining the guarantee party identifier is improved. When the remaining guarantee amount corresponding to the guarantee party identification is calculated, the on-the-way application loan is fully considered, the on-the-way guarantee amount corresponding to the on-the-way application loan is converted, and the accuracy of the remaining guarantee amount is improved.

In one embodiment, before the step of sending the plurality of loan tasks to the corresponding target servers of the corresponding guarantor identifications respectively by using the target interface, the method further includes: receiving a newly increased guarantee party request sent by a configuration terminal; returning a configuration page to the configuration terminal according to the newly added request of the guarantor, so that the configuration terminal obtains the configuration information recorded in the configuration page; and receiving the configuration information returned by the configuration terminal, and establishing a communication link with the target server corresponding to the guarantor identifier according to the configuration information.

And when a target server needs to be newly added, the configuration terminal sends a server newly-added request to the second server. And the second server returns a configuration page to the configuration terminal according to the new adding request of the server. Related personnel can add the guarantee party identifier and configuration information such as an interface name, an interface protocol, an interface type, an IP address (Internet protocol address), a port number, a user name and a password of a corresponding interface of the guarantee party identifier on a configuration page so as to realize data interaction between the second server and a corresponding target server. The same sponsor identifier may set configuration information for multiple interfaces.

In the embodiment, the access of the target server can be realized through a simple configuration mode, the access threshold of the target server is reduced, and the convenience of accessing the target server can be improved.

In one embodiment, the step of sending the plurality of loan tasks to the target servers corresponding to the corresponding guarantor identifications respectively by using the target interface includes: packing the loan tasks corresponding to the same guarantor identification to obtain a plurality of task data packets; calling a plurality of target interfaces, and synchronously sending a plurality of task data packets to a target server corresponding to a corresponding guarantor identifier by using the plurality of target interfaces; acquiring a forwarding log generated in the sending process, and detecting whether forwarding abnormality exists according to the forwarding log; adding the loan tasks with abnormal forwarding to a cache queue; and when the corresponding task data packet is sent, the loan task in the cache queue is sent again.

And the second server packages the loan tasks corresponding to the same guarantor identification to obtain a plurality of task data packets, and respectively sends the plurality of task data packets to the target servers corresponding to the corresponding guarantor identifications. Specifically, the second server sequences the plurality of task data packets, and sequentially sends the plurality of task data packets to the corresponding target servers according to the sequence. In another embodiment, to improve data forwarding efficiency, the second server invokes multithreading to forward multiple task packets in parallel. Specifically, the second server calls a plurality of target interfaces, and synchronously sends a plurality of task data packets to corresponding target servers by using the plurality of target interfaces.

In order to improve the success rate of data forwarding, in the process of data forwarding, the second server detects whether forwarding logs generated in the process of forwarding have forwarding anomalies according to a preset time frequency. And when the forwarding abnormality exists, the second server adds the loan task with the forwarding abnormality to the cache queue, and resends the loan task in the cache queue after the corresponding task data packet is sent. In order to avoid resource waste caused by frequent repeated forwarding of the same loan task to the second server, the second server limits the repeated forwarding times of each loan task. Specifically, the second server detects the forwarding times corresponding to the loan tasks with abnormal forwarding, and detects whether the forwarding times exceed a preset value. If so, the second server generates a forwarding early warning corresponding to the loan task, and sends the forwarding early warning to the operation and maintenance terminal, so that the operation and maintenance terminal performs supplementary forwarding on the corresponding loan task, and the success rate of forwarding the loan task is ensured.

In the embodiment, a plurality of target interfaces are called to synchronously forward a plurality of task data packets, so that the data forwarding efficiency can be improved; and the abnormal forwarding detection is carried out in the forwarding process, and the loan task with the abnormal forwarding is automatically retransmitted, so that the success rate of data forwarding is improved.

It should be understood that, although the steps in the flowchart of fig. 2 are shown in order as indicated by the arrows, the steps are not necessarily performed in order as indicated by the arrows. The steps are not performed in the exact order shown and described, and may be performed in other orders, unless explicitly stated otherwise. Moreover, at least a portion of the steps in fig. 2 may include multiple sub-steps or multiple stages that are not necessarily performed at the same time, but may be performed at different times, and the order of performance of the sub-steps or stages is not necessarily sequential, but may be performed in turn or alternately with other steps or at least a portion of the sub-steps or stages of other steps.

In one embodiment, as shown in fig. 3, there is provided a data interaction apparatus, including: a data collection module 302, a sponsor determination module 304, a data forwarding module 306, and a vouch result feedback module 308, wherein:

a data acquisition module 302 for extracting loan application data at a plurality of source servers; the loan application data includes an origin server identification.

And the guarantor determining module 304 is used for determining the guarantor identifier which is adapted to the loan application data according to a preset rule.

The data forwarding module 306 is configured to generate corresponding loan tasks by using the extracted multiple groups of loan application data; the loan task has a corresponding task identifier; and calling the target interface, generating a calling record by using the task identifier and the corresponding source server identifier, and respectively sending the plurality of loan tasks to the target servers corresponding to the corresponding guarantor identifiers by using the target interface.

The guarantee result feedback module 308 is configured to receive a guarantee result returned by the target server, where the guarantee result carries the task identifier; and inquiring the source server identification corresponding to the task identification in the guarantee result in the stored multiple call records, and sending the guarantee result to the corresponding source server.

In one embodiment, the apparatus further includes a load balancing module 310, configured to calculate data amounts corresponding to the plurality of groups of loan application data, respectively; monitoring the loads of other servers in the cluster to which the server belongs; acquiring a preset load balancing file, and determining the total data volume of loan application data which can be processed by a plurality of servers in a cluster according to the load balancing file; and dividing the plurality of groups of loan application data into a plurality of parts according to the total data volume, and distributing each part of loan application data to a corresponding server in the cluster.

In one embodiment, the loan application data further includes a loan identification and an application amount; the sponsor determination module 304 includes a queue traversal module 3042 and an amount matching module 3044; the queue traversing module 3042 is configured to obtain a message queue corresponding to the loan identifier; the message queue comprises a plurality of guarantor identifications and corresponding guarantor states; the guaranteed state includes guaranteed and unsecured; traversing the acquired message queue according to a preset traversing direction, and screening a first guarantee party identifier with an unsecured guarantee state; the quota matching module 3044 is used for calculating the remaining guarantee quota corresponding to the screened guarantee party identifier; comparing whether the remaining guarantee amount is greater than or equal to the application amount; if yes, marking the screened guarantor identification as the guarantor identification corresponding to the loan application data, and changing the guaranty state of the screened guarantor identification into the guaranty; otherwise, screening the guarantor identification with the next guarantor state being non-guaranty, returning to the step of calculating the remaining guaranty amount corresponding to the screened guarantor identification until the guarantor identification corresponding to the loan application data is determined.

In one embodiment, multiple vouchers' identities in the message queue have different vouching proportions; the guarantor determination module 304 includes a queue generation module 3046, configured to detect whether a corresponding message queue exists according to the loan identifier; when the corresponding message queue does not exist, acquiring a plurality of guarantor identifications corresponding to the loan identification; determining the guarantee sequence of the plurality of guarantor identifications according to the obtained guarantee proportion of the plurality of guarantor identifications; acquiring a preset queue length, and determining the guarantee times of a plurality of guarantor identifications according to the queue length and the guarantee proportion of the plurality of guarantor identifications; and generating a corresponding message queue by using a plurality of guarantor identifications according to the guaranty sequence and the guaranty times.

In one embodiment, the apparatus further includes a configuration access module 312, configured to receive a guarantor addition request sent by the configuration terminal; returning a configuration page to the configuration terminal according to the newly added request of the guarantor, so that the configuration terminal obtains the configuration information recorded in the configuration page; and receiving the configuration information returned by the configuration terminal, and establishing a communication link with the target server corresponding to the guarantor identifier according to the configuration information.

In one embodiment, the apparatus further includes an anomaly monitoring module 314, configured to package loan tasks corresponding to the same sponsor identifier, to obtain a plurality of task data packets; calling a plurality of target interfaces, and synchronously sending a plurality of task data packets to a target server corresponding to a corresponding guarantor identifier by using the plurality of target interfaces; acquiring a forwarding log generated in the sending process, and detecting whether forwarding abnormality exists according to the forwarding log; adding the loan tasks with abnormal forwarding to a cache queue; and when the corresponding task data packet is sent, the loan task in the cache queue is sent again.

In one embodiment, the collateral determination module 304 includes a collateral splitting module 3048, configured to traverse the message queue again when the result of the collateral is a decline of the collateral, and detect whether there are other collateral identifiers corresponding to the loan application data; if not, the loan application data is split according to the application limit and the remaining guarantee limit corresponding to the guarantee party identifier with the guarantee state of being not guaranteed in the message queue to obtain a plurality of sub-item application data with different application limits; and traversing the message queue again, screening the guarantor identifications adapted to the sub-item application data, respectively sending the sub-item application data to the target servers corresponding to the corresponding guarantor identifications, and returning to the step of receiving the guarantor result returned by the target servers.

For specific limitations of the data interaction device, reference may be made to the above limitations of the data interaction method, which is not described herein again. The modules in the data interaction device can be wholly or partially implemented by software, hardware and a combination thereof. The modules can be embedded in a hardware form or independent from a processor in the computer device, and can also be stored in a memory in the computer device in a software form, so that the processor can call and execute operations corresponding to the modules.

In one embodiment, a computer device is provided, which may be a server, the internal structure of which may be as shown in fig. 4. The computer device includes a processor, a memory, a network interface, and a database connected by a system bus. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device comprises a nonvolatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of an operating system and computer programs in the non-volatile storage medium. The database of the computer device is used for storing the call records. The network interface of the computer device is used for communicating with an external terminal through a network connection. The computer program is executed by a processor to implement a data interaction method.

Those skilled in the art will appreciate that the architecture shown in fig. 4 is merely a block diagram of some of the structures associated with the disclosed aspects and is not intended to limit the computing devices to which the disclosed aspects apply, as particular computing devices may include more or less components than those shown, or may combine certain components, or have a different arrangement of components.

In one embodiment, there is provided a computer device comprising a memory storing a computer program and a processor implementing the following steps when the processor executes the computer program: extracting loan application data at a plurality of source servers; the loan application data includes an origin server identification; determining a guarantee party identifier adaptive to the loan application data according to a preset rule; respectively generating corresponding loan tasks by utilizing the extracted multiple groups of loan application data; the loan task has a corresponding task identifier; calling a target interface, generating a calling record by using the task identifier and the corresponding source server identifier, and respectively sending a plurality of loan tasks to the target servers corresponding to the corresponding guarantor identifiers by using the target interface; when receiving a guarantee result returned by the target server, the guarantee result carries a task identifier; and inquiring the source server identification corresponding to the task identification in the guarantee result in the stored multiple call records, and sending the guarantee result to the corresponding source server.

In one embodiment, the processor, when executing the computer program, further performs the steps of: calculating data quantities corresponding to the plurality of groups of loan application data respectively; monitoring the loads of other servers in the cluster to which the server belongs; acquiring a preset load balancing file, and determining the total data volume of loan application data which can be processed by a plurality of servers in a cluster according to the load balancing file; and dividing the plurality of groups of loan application data into a plurality of parts according to the total data volume, and distributing each part of loan application data to a corresponding server in the cluster.

In one embodiment, the loan application data further includes a loan identification and an application amount; the processor, when executing the computer program, further performs the steps of: obtaining a message queue corresponding to the loan identifier; the message queue comprises a plurality of guarantor identifications and corresponding guarantor states; the guaranteed state includes guaranteed and unsecured; traversing the acquired message queue according to a preset traversing direction, and screening a first guarantee party identifier with an unsecured guarantee state; calculating the remaining guarantee amount corresponding to the screened guarantee party identification; comparing whether the remaining guarantee amount is greater than or equal to the application amount; if yes, marking the screened guarantor identification as the guarantor identification corresponding to the loan application data, and changing the guaranty state of the screened guarantor identification into the guaranty; otherwise, screening the guarantor identification with the next guarantor state being non-guaranty, returning to the step of calculating the remaining guaranty amount corresponding to the screened guarantor identification until the guarantor identification corresponding to the loan application data is determined.

In one embodiment, multiple vouchers' identities in the message queue have different vouching proportions; the processor, when executing the computer program, further performs the steps of: detecting whether a corresponding message queue exists or not according to the loan identifier; when the corresponding message queue does not exist, acquiring a plurality of guarantor identifications corresponding to the loan identification; determining the guarantee sequence of the plurality of guarantor identifications according to the obtained guarantee proportion of the plurality of guarantor identifications; acquiring a preset queue length, and determining the guarantee times of a plurality of guarantor identifications according to the queue length and the guarantee proportion of the plurality of guarantor identifications; and generating a corresponding message queue by using a plurality of guarantor identifications according to the guaranty sequence and the guaranty times.

In one embodiment, the processor, when executing the computer program, further performs the steps of: receiving a newly increased guarantee party request sent by a configuration terminal; returning a configuration page to the configuration terminal according to the newly added request of the guarantor, so that the configuration terminal obtains the configuration information recorded in the configuration page; and receiving the configuration information returned by the configuration terminal, and establishing a communication link with the target server corresponding to the guarantor identifier according to the configuration information.

In one embodiment, the processor, when executing the computer program, further performs the steps of: packing the loan tasks corresponding to the same guarantor identification to obtain a plurality of task data packets; calling a plurality of target interfaces, and synchronously sending a plurality of task data packets to a target server corresponding to a corresponding guarantor identifier by using the plurality of target interfaces; acquiring a forwarding log generated in the sending process, and detecting whether forwarding abnormality exists according to the forwarding log; adding the loan tasks with abnormal forwarding to a cache queue; and when the corresponding task data packet is sent, the loan task in the cache queue is sent again.

In one embodiment, the processor, when executing the computer program, further performs the steps of: when the guarantee result is that the guarantee is refused, traversing the message queue again, and detecting whether other guarantee party identifiers which are suitable for the loan application data exist or not; if not, the loan application data is split according to the application limit and the remaining guarantee limit corresponding to the guarantee party identifier with the guarantee state of being not guaranteed in the message queue to obtain a plurality of sub-item application data with different application limits; and traversing the message queue again, screening the guarantor identifications adapted to the sub-item application data, respectively sending the sub-item application data to the target servers corresponding to the corresponding guarantor identifications, and returning to the step of receiving the guarantor result returned by the target servers.

In one embodiment, a computer-readable storage medium is provided, having a computer program stored thereon, which when executed by a processor, performs the steps of: extracting loan application data at a plurality of source servers; the loan application data includes an origin server identification; determining a guarantee party identifier adaptive to the loan application data according to a preset rule; respectively generating corresponding loan tasks by utilizing the extracted multiple groups of loan application data; the loan task has a corresponding task identifier; calling a target interface, generating a calling record by using the task identifier and the corresponding source server identifier, and respectively sending a plurality of loan tasks to the target servers corresponding to the corresponding guarantor identifiers by using the target interface; when receiving a guarantee result returned by the target server, the guarantee result carries a task identifier; and inquiring the source server identification corresponding to the task identification in the guarantee result in the stored multiple call records, and sending the guarantee result to the corresponding source server.

In one embodiment, the computer program when executed by the processor further performs the steps of: calculating data quantities corresponding to the plurality of groups of loan application data respectively; monitoring the loads of other servers in the cluster to which the server belongs; acquiring a preset load balancing file, and determining the total data volume of loan application data which can be processed by a plurality of servers in a cluster according to the load balancing file; and dividing the plurality of groups of loan application data into a plurality of parts according to the total data volume, and distributing each part of loan application data to a corresponding server in the cluster.

In one embodiment, the loan application data further includes a loan identification and an application amount; the computer program when executed by the processor further realizes the steps of: obtaining a message queue corresponding to the loan identifier; the message queue comprises a plurality of guarantor identifications and corresponding guarantor states; the guaranteed state includes guaranteed and unsecured; traversing the acquired message queue according to a preset traversing direction, and screening a first guarantee party identifier with an unsecured guarantee state; calculating the remaining guarantee amount corresponding to the screened guarantee party identification; comparing whether the remaining guarantee amount is greater than or equal to the application amount; if yes, marking the screened guarantor identification as the guarantor identification corresponding to the loan application data, and changing the guaranty state of the screened guarantor identification into the guaranty; otherwise, screening the guarantor identification with the next guarantor state being non-guaranty, returning to the step of calculating the remaining guaranty amount corresponding to the screened guarantor identification until the guarantor identification corresponding to the loan application data is determined.

In one embodiment, multiple vouchers' identities in the message queue have different vouching proportions; the computer program when executed by the processor further realizes the steps of: : detecting whether a corresponding message queue exists or not according to the loan identifier; when the corresponding message queue does not exist, acquiring a plurality of guarantor identifications corresponding to the loan identification; determining the guarantee sequence of the plurality of guarantor identifications according to the obtained guarantee proportion of the plurality of guarantor identifications; acquiring a preset queue length, and determining the guarantee times of a plurality of guarantor identifications according to the queue length and the guarantee proportion of the plurality of guarantor identifications; and generating a corresponding message queue by using a plurality of guarantor identifications according to the guaranty sequence and the guaranty times.

In one embodiment, the computer program when executed by the processor further performs the steps of: receiving a newly increased guarantee party request sent by a configuration terminal; returning a configuration page to the configuration terminal according to the newly added request of the guarantor, so that the configuration terminal obtains the configuration information recorded in the configuration page; and receiving the configuration information returned by the configuration terminal, and establishing a communication link with the target server corresponding to the guarantor identifier according to the configuration information.

In one embodiment, the computer program when executed by the processor further performs the steps of: packing the loan tasks corresponding to the same guarantor identification to obtain a plurality of task data packets; calling a plurality of target interfaces, and synchronously sending a plurality of task data packets to a target server corresponding to a corresponding guarantor identifier by using the plurality of target interfaces; acquiring a forwarding log generated in the sending process, and detecting whether forwarding abnormality exists according to the forwarding log; adding the loan tasks with abnormal forwarding to a cache queue; and when the corresponding task data packet is sent, the loan task in the cache queue is sent again.

In one embodiment, the computer program when executed by the processor further performs the steps of: when the guarantee result is that the guarantee is refused, traversing the message queue again, and detecting whether other guarantee party identifiers which are suitable for the loan application data exist or not; if not, the loan application data is split according to the application limit and the remaining guarantee limit corresponding to the guarantee party identifier with the guarantee state of being not guaranteed in the message queue to obtain a plurality of sub-item application data with different application limits; and traversing the message queue again, screening the guarantor identifications adapted to the sub-item application data, respectively sending the sub-item application data to the target servers corresponding to the corresponding guarantor identifications, and returning to the step of receiving the guarantor result returned by the target servers.

It will be understood by those of ordinary skill in the art that all or a portion of the processes of the methods of the embodiments described above may be implemented by a computer program that may be stored in a non-volatile computer-readable storage medium, which, when executed, may include the processes of the embodiments of the methods described above, wherein any reference to memory, storage, database, or other medium used in the embodiments provided herein may include non-volatile and/or volatile memory.

The technical features of the above embodiments can be arbitrarily combined, and for the sake of brevity, all possible combinations of the technical features in the above embodiments are not described, but should be considered as the scope of the present specification as long as there is no contradiction between the combinations of the technical features.

The above examples only express several embodiments of the present application, and the description thereof is more specific and detailed, but not construed as limiting the scope of the invention. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the concept of the present application, which falls within the scope of protection of the present application. Therefore, the protection scope of the present patent shall be subject to the appended claims.

Claims

1. A data interaction method is applied to a platform server, wherein the platform server comprises an origin server and a second server, and the method comprises the following steps:

extracting loan application data at a plurality of source servers; the loan application data includes an origin server identification; the source server packages loan application data of a plurality of users received within a preset time length; the second server respectively extracts loan application data packets from the plurality of source servers according to a preset time frequency; the loan application data comprises one or more loan identifiers; the second server stores a plurality of loan identifier combinations and one or more guarantor identifiers corresponding to each loan identifier combination in advance;

determining a guarantee party identifier which is adaptive to the loan application data according to a preset rule;

the second server respectively generates corresponding loan tasks by utilizing the extracted multiple groups of loan application data; the loan task has a corresponding task identifier;

the second server calls a target interface, generates a call record by using the task identifier and the corresponding source server identifier, and respectively sends the loan tasks to target servers corresponding to corresponding guarantor identifiers by using the target interface;

when the second server receives a guarantee result returned by the target server, the guarantee result carries a task identifier; and inquiring the source server identification corresponding to the task identification in the guarantee result in the stored multiple call records, and sending the guarantee result to the corresponding source server.

2. The method of claim 1, further comprising, prior to the step of determining a sponsor identifier adapted to said loan application data in accordance with preset rules:

calculating data quantities corresponding to the plurality of groups of loan application data respectively;

monitoring the loads of other servers in the cluster to which the server belongs;

acquiring a preset load balancing file, and determining the total data volume of loan application data which can be processed by a plurality of servers in a cluster according to the load balancing file;

and dividing the plurality of groups of loan application data into a plurality of parts according to the total data volume, and distributing each part of loan application data to a corresponding server in the cluster.

3. The method of claim 1, wherein the loan application data further comprises a loan identifier and an application amount; the step of determining the guarantor identification adapted to the loan application data according to a preset rule comprises:

obtaining a message queue corresponding to the loan identifier; the message queue comprises a plurality of guarantor identifications and corresponding guarantor states; the vouching status comprises guaranteed and non-guaranteed;

traversing the acquired message queue according to a preset traversing direction, and screening a first guarantee party identifier with an unsecured guarantee state;

calculating the remaining guarantee amount corresponding to the screened guarantee party identification;

comparing whether the remaining guarantee amount is larger than or equal to the application amount;

if yes, marking the screened guarantor identification as the guarantor identification corresponding to the loan application data, and changing the guaranty state of the screened guarantor identification into the guaranty;

otherwise, screening the guarantor identification with the next guarantor state being non-guaranty, returning to the step of calculating the remaining guaranty amount corresponding to the screened guarantor identification until the guarantor identification corresponding to the loan application data is determined.

4. The method of claim 3, wherein a plurality of guarantor identifications in the message queue have different guaranty proportions; the step of obtaining the message queue corresponding to the loan identifier comprises the following steps:

detecting whether a corresponding message queue exists or not according to the loan identifier;

when the corresponding message queue does not exist, acquiring a plurality of guarantor identifications corresponding to the loan identification;

determining the guarantee sequence of the plurality of guarantor identifications according to the obtained guarantee proportion of the plurality of guarantor identifications;

acquiring a preset queue length, and determining the guarantee times of a plurality of guarantor identifications according to the queue length and the guarantee proportion of the plurality of guarantor identifications;

and generating a corresponding message queue by using a plurality of guarantor identifications according to the guaranty sequence and the guaranty times.

5. The method according to any one of claims 1 to 4, wherein before the step of sending the plurality of loan tasks to the target servers corresponding to the corresponding sponsor identifiers respectively by using the target interface, the method further comprises:

receiving a newly increased guarantee party request sent by a configuration terminal;

according to the newly added request of the guarantor, returning a configuration page to the configuration terminal, so that the configuration terminal obtains the configuration information recorded in the configuration page;

and receiving configuration information returned by the configuration terminal, and establishing a communication link with a target server corresponding to the guarantor identifier according to the configuration information.

6. The method according to any one of claims 1 to 4, wherein the step of sending the plurality of loan tasks to the target servers corresponding to the corresponding guarantor identifications respectively by using the target interface comprises:

packing the loan tasks corresponding to the same guarantor identification to obtain a plurality of task data packets;

calling a plurality of target interfaces, and synchronously sending a plurality of task data packets to a target server corresponding to a corresponding guarantor identifier by using the plurality of target interfaces;

acquiring a forwarding log generated in the sending process, and detecting whether forwarding abnormality exists according to the forwarding log;

adding the loan tasks with abnormal forwarding to a cache queue;

and when the corresponding task data packet is sent, resending the loan task in the cache queue.

7. The method of claim 3, wherein prior to the step of querying the stored plurality of call records for an origin server identification corresponding to the task identification in the vouching result, further comprising:

when the guarantee result is that the guarantee is refused, traversing the message queue again, and detecting whether other guarantee party identifiers which are suitable for the loan application data exist or not;

if not, splitting the loan application data according to the application limit and a residual guarantee limit corresponding to a guarantee party identifier with an unsecured guarantee state in the message queue to obtain a plurality of sub-item application data with different application limits;

and traversing the message queue again, screening the guarantor identifications adapted to the sub-item application data, respectively sending the sub-item application data to the target servers corresponding to the corresponding guarantor identifications, and returning to the step of receiving the guarantor result returned by the target servers.

8. A data interaction apparatus, the apparatus comprising:

the data acquisition module is used for extracting loan application data from a plurality of source servers; the loan application data includes an origin server identification; the source server packages loan application data of a plurality of users received within a preset time length; the second server respectively extracts loan application data packets from the plurality of source servers according to a preset time frequency; the loan application data comprises one or more loan identifiers; the second server stores a plurality of loan identifier combinations and one or more guarantor identifiers corresponding to each loan identifier combination in advance;

the guarantor determining module is used for determining a guarantor identifier which is adaptive to the loan application data according to a preset rule;

the data forwarding module is used for generating corresponding loan tasks by utilizing the extracted multiple groups of loan application data through the second server; the loan task has a corresponding task identifier; calling a target interface, generating a calling record by using the task identifier and the corresponding source server identifier, and respectively sending the plurality of loan tasks to the target servers corresponding to the corresponding guarantor identifiers by using the target interface;

the guarantee result feedback module is used for carrying a task identifier when the second server receives the guarantee result returned by the target server; and inquiring the source server identification corresponding to the task identification in the guarantee result in the stored multiple call records, and sending the guarantee result to the corresponding source server.

9. A computer device comprising a memory and a processor, the memory storing a computer program, wherein the processor implements the steps of the method of any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, carries out the steps of the method of any one of claims 1 to 7.