Credit data storage method and processing method, terminal and storage medium

Abstract

The invention relates to the technical field of data processing, and discloses a credit data storage method and processing method, a terminal and a storage medium, the credit data storage method comprises the following steps: in response to a credit call command for acquiring credit data from an external data supplier, writing a corresponding credit call record into a first database; after credit information data corresponding to the credit information calling command is obtained, the credit information data and the corresponding credit information calling record are associated and stored in a first database, and the credit information calling record and the corresponding credit information data are synchronously associated and then stored in a second database and a third database at the same time; wherein the first database is a database which only retains credit data within preset time; the second database is a database which only retains the latest record of the credit subject; the third database is a full-amount database. Through the method provided by the invention, the rate of calling or querying the credit data can be improved.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to a credit data storage method, processing method, terminal and storage medium. Background Art

[0002] With the increase of banking business, the credit system is carrying more and more credit query and retrieval tasks. At present, all credit data are in one database, which will not have much impact on a small number of credit data query and retrieval tasks. However, with the increase of credit query and retrieval tasks, the current growth rate may reach 1 million / day. Therefore, the existing single database processing method faces the problem of rapid growth leading to reduced database performance and increased maintenance costs. Summary of the invention

[0003] In view of this, the embodiments of the present application provide a credit data storage method, a processing method, a terminal and a storage medium, which can improve the speed of credit data retrieval and query.

[0004] In a first aspect, an embodiment of the present application provides a credit data storage method, comprising: In response to a credit calling command for obtaining credit data from an external data supplier, writing a corresponding credit calling record into the first database; After obtaining the credit data corresponding to the credit call command, the credit data is associated with the corresponding credit call record and saved in the first database, and the credit call record and the corresponding credit data are associated and saved in the second database and the third database respectively; Among them, the first database is a database that only retains credit data within a preset time; the second database is a database that only retains the latest record of the credit subject; and the third database is a full database.

[0005] In some embodiments, the credit call record includes a credit subject, a serial number, and a call status; wherein the serial number is used to delete the credit data that does not conform to the preset time according to the serial number when updating the first database; After obtaining the credit data corresponding to the credit calling command, the method further includes: Update the calling status to a calling success status; A corresponding message log is written into the local message table, and the processing state of the message log is defined as an unsynchronized state; wherein the message log corresponds one-to-one to the credit call record.

[0006] In some embodiments, the credit call record is queried at a first preset interval, and if the call status in the credit call record includes a processing status, all credit call tasks with the processing status are reprocessed.

[0007] In some embodiments, after synchronously saving the credit information call record and the corresponding credit information data in association with each other in the second database and the third database, the method further includes: The processing status of the message log corresponding to the credit call record is updated to a synchronization status.

[0008] In some embodiments, querying the message log in which the processing status is an unsynchronized state at a second preset interval; querying the second database and the third database according to the message log in the unsynchronized state whether they contain the corresponding credit data; If included, updating the processing status of the corresponding message log to a synchronization status; If not included, the corresponding credit data and the credit call record are resynchronized.

[0009] In some embodiments, after obtaining the credit data corresponding to the credit call command, the credit data is associated with the corresponding credit call record and saved in the first database, and the credit call record and the corresponding credit data are simultaneously associated and saved in the fourth database; Wherein, the fourth database is an offline database.

[0010] In a second aspect, an embodiment of the present application provides a credit data processing method, including: In response to the credit calling command, determining a credit calling channel according to a credit multiplexing rule in the credit calling command; If it is determined that the credit calling channel is to obtain credit data from an external data supplier, after obtaining the credit data, the credit data is stored in the first database, the second database and the third database respectively using the credit data storage method described above; If it is determined that the credit information calling channel is to obtain the credit information data from a local database, the corresponding credit information data is obtained from the first database or the second database.

[0011] In some embodiments, the credit reuse rules include mandatory query, mandatory cache, and reuse of local data within a preset time; Determining the credit calling channel according to the credit multiplexing rule in the credit calling command includes: If the credit reuse rule is the mandatory query, determining the credit calling channel is to obtain credit data from an external data supplier; If the credit reuse rule is the mandatory cache, determining the credit calling channel is to obtain the credit data from the second database; If the credit reuse rule is to reuse local data within the preset time, then determine that the credit call channel is to obtain the credit data from the first database, and if the corresponding credit data is not obtained from the first database, then continue to obtain credit data from an external data supplier; In a third aspect, an embodiment of the present application provides a terminal device, which includes a processor and a memory, wherein the memory stores a computer program, and the processor is used to execute the computer program to implement the above-mentioned credit data storage method or the above-mentioned credit data processing method.

[0012] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium storing a computer program, which, when executed on a processor, implements the above-mentioned credit data storage method or the above-mentioned credit data processing method.

[0013] The embodiments of the present application have the following beneficial effects: the present application saves the credit data according to different situations, with one database used to save the credit data of a preset time, one database used to save the latest credit data of each credit subject, and another used to save the full amount of credit data. In this way, when it is necessary to obtain credit data from a local database or to query credit data from a local database, the relevant credit data can be obtained from the corresponding database according to a credit call command or a credit query command. Through this credit data storage method of the present application, the required credit data can be quickly obtained according to a call command or a query command. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0015] Figure 1 A first flow chart of the credit data storage method according to an embodiment of the present application is shown; Figure 2 A second flow chart of the credit data storage method according to an embodiment of the present application is shown; Figure 3 A first flow chart of the credit data processing method according to an embodiment of the present application is shown; Figure 4 A second flow chart of the credit data processing method according to an embodiment of the present application is shown; Figure 5 A schematic diagram showing a comparison between a stress test of a credit data processing method in the prior art and a stress test of a credit data processing method in an embodiment of the present application is shown; Figure 6 A schematic diagram showing the structure of a credit information data storage device according to an embodiment of the present application is shown; Figure 7 A structural schematic diagram of a credit data processing device according to an embodiment of the present application is shown. DETAILED DESCRIPTION

[0016] The technical solutions in the embodiments of the present application will be described clearly and completely below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all of the embodiments.

[0017] The components of the embodiments of the present application generally described and shown in the drawings herein may be arranged and designed in various configurations. Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the application claimed for protection, but merely represents the selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without making creative work belong to the scope of protection of the present application.

[0018] Hereinafter, the terms "including", "having" and their cognates that can be used in various embodiments of the present application are intended only to indicate specific features, numbers, steps, operations, elements, components or a combination of the foregoing items, and should not be understood as first excluding the existence of one or more other features, numbers, steps, operations, elements, components or a combination of the foregoing items or increasing the possibility of one or more features, numbers, steps, operations, elements, components or a combination of the foregoing items. In addition, the terms "first", "second", "third" and the like are only used to distinguish descriptions and cannot be understood as indicating or implying relative importance.

[0019] Unless otherwise defined, all terms (including technical terms and scientific terms) used herein have the same meanings as those generally understood by those skilled in the art to which the various embodiments of the present application belong. The terms (such as those defined in generally used dictionaries) will be interpreted as having the same meanings as the contextual meanings in the relevant technical field and will not be interpreted as having idealized meanings or overly formal meanings unless clearly defined in the various embodiments of the present application.

[0020] In conjunction with the accompanying drawings, some embodiments of the present application are described in detail below. In the absence of conflict, the following embodiments and features in the embodiments can be combined with each other.

[0021] With the rapid growth of credit retrieval and query tasks, the performance of the database currently storing credit data has decreased and the maintenance cost has increased. Based on this, the present application proposes a credit data storage method, processing method, terminal and storage medium to improve the speed of credit data retrieval and query.

[0022] The credit data storage method is described below with reference to some specific embodiments.

[0023] Example 1 Figure 1 The first flow chart of the credit data storage method of the embodiment of the present application is shown. Exemplarily, the credit data storage method includes the following steps: Step S100, in response to a credit calling command for obtaining credit data from an external data supplier, a corresponding credit calling record is written into the first database.

[0024] Credit retrieval is required in loan approval, credit card approval, guarantee qualification review, post-loan risk management, credit rating, etc. When retrieving a customer's credit data, a credit retrieval command is issued to the credit business system. After the credit business system receives the credit retrieval command, if it is determined based on the credit retrieval command that the credit retrieval requires obtaining credit data from an external supplier, the corresponding credit retrieval record is first written into the transaction record table of the first database, wherein the credit retrieval record includes but is not limited to the credit subject, serial number, and call status, etc.; wherein the credit subject is the object of the credit data retrieval; the serial number is a number containing the retrieval time, and the retrieval time in the serial number can be the direct time, or So the code is formed by a certain encoding form, and the call time can be obtained through the code; the call status includes a call success status and a processing status, wherein the initial state of the call status is the processing status, and the call success status and the processing status can be represented by different codes, such as the processing status can be represented by 0, and the call success status can be represented by 1; its processing status can be represented by ING, and the call success status can be represented by SUCC. It can be understood that the above representation methods for the processing status and the call success status are only exemplary, and other representation methods can be used as needed, as long as the processing status and the call success status can be distinguished, which will not be repeated here.

[0025] Step S200, after obtaining the credit data corresponding to the credit call command, the credit data is associated with the corresponding credit call record and saved in the first database, and the credit call record and the corresponding credit data are associated and saved in the second database and the third database at the same time.

[0026] The first database is a database that only retains credit data within a preset time.

[0027] Among them, the second database is a database that only retains the latest record of the credit subject; the third database is a full database.

[0028] In this step, after obtaining the credit data corresponding to the credit call command, it is necessary not only to associate the credit data with the corresponding credit call record and save it in the first database, but also to associate the credit call record and the corresponding credit data and save it in the second database and the third database. In this way, since the first database stores credit data within a preset time, such as credit data within 3 months or credit data within 30 days, and since the credit data is the latest credit data obtained from an external supplier, it needs to be saved in the first database; in addition, since the second database only retains the database of the latest record of the credit subject, the latest credit data obtained from the external supplier must be the latest credit data of the corresponding credit subject. If it is queried according to the credit call record saved in the second database, a piece of credit data of the credit subject was previously saved in the second database, then the previously saved credit data of the credit subject will be deleted from the database; further, the third database is a full database, that is, the third database is a database that stores all credit data, so the latest credit data and the corresponding credit call record should also be associated and saved in the third database.

[0029] The present application stores the credit data according to different situations. One database is used to store the credit data of the preset time, one database is used to store the latest credit data of each credit subject, and the other is used to store the full credit data. In this way, when it is necessary to obtain credit data from the local database or to query credit data from the local database, the relevant credit data can be obtained from the corresponding database according to the credit call command or credit query command. If it is necessary to query the latest credit data of a credit subject from the local database, it is only necessary to query from the second database. If it is necessary to query or retrieve the credit data of a credit subject in the past 10 days from the local database, it can be directly queried or retrieved from the first database, without the need for all credit data to be in the same database as in the prior art. No matter what credit data is required to be queried, it must be obtained from the same database, which will inevitably affect the speed of querying or retrieving data. In addition, the volume of credit data is relatively large. This method of the prior art will not only affect the speed of querying or retrieving, but also increase the cost of database maintenance. However, through this credit data storage method of the present application, the required credit data can be quickly obtained according to the retrieval command or query command.

[0030] Example 2 Figure 2 The second flow chart of the credit data storage method of the embodiment of the present application is shown. Exemplarily, the credit data storage method includes the following steps: Step S1, in response to a credit calling command for obtaining credit data from an external data supplier, write a corresponding credit calling record into the first database. This step is consistent with step S100 in embodiment 1 and will not be described in detail here.

[0031] After inserting the credit call record into the transaction record table of the first database in step 1, obtain the corresponding credit data from the external supplier. After obtaining the credit data corresponding to the credit call command, execute step S2 to associate the credit data with the corresponding credit call record and save it in the first database, and update the call status of the corresponding credit call record to a successful status.

[0032] Step S3: Write a corresponding message log into the local message table, and define the processing state of the message log as an unsynchronized state.

[0033] After obtaining the corresponding credit data in the above steps, a message log corresponding to the credit call record is written into the local message table. The initial processing status of the message log is an unsynchronized state. The message log is used to record whether the obtained credit data is successfully synchronized to the second database and the third database. If the synchronization is successful, the processing status of the message record is updated to the unsynchronized state. It should be noted that the synchronization state and the bit synchronization state of the message log can be represented by different codes, such as the unsynchronized state can be represented by 0, and the synchronized state can be represented by 1; the unsynchronized state can also be represented by a, and the synchronized state can be represented by b, etc.

[0034] Step S4, synchronously associate the credit information call record and the corresponding credit information data and save them to the second database and the third database at the same time.

[0035] Step S5, querying the credit calling record at a first preset interval, if the calling status in the credit calling record includes a processing status, reprocessing all credit calling tasks with a processing status.

[0036] In this step, the credit call record is queried according to the set first preset time, usually when there is no credit call task. If there is a call status of "processing" in the credit call record, it means that the credit data corresponding to the credit call command has not been obtained. At this time, it is considered that the retrieval of these credit data has failed, and the credit retrieval command corresponding to the processing status is reprocessed.

[0037] Step S6, querying the message logs whose processing status is unsynchronized in the message logs at a second preset interval.

[0038] Step S7, querying whether the second database and the third database contain corresponding credit data according to the message log in the unsynchronized state.

[0039] If included, step S8 is executed to update the processing status of the corresponding message log to a synchronization status.

[0040] If not, execute step S9 to resynchronize the corresponding credit data and credit call records.

[0041] In steps S6-S9, the message logs in the local transaction record table that are in an unsynchronized state can be queried periodically by setting a scheduled task, and then the second database and the third database can be queried based on the message logs in the unsynchronized state to see whether they contain the corresponding consulting data and credit call records. If they do, it means that the synchronization is successful, and the processing status of the corresponding message log is updated to the unsynchronized state. If they do not, it means that the synchronization is not successful, and the credit data and credit call records that have not been successfully synchronized are resynchronized. Furthermore, this embodiment also includes a fourth database. After obtaining the credit data corresponding to the credit call command, the credit data and the corresponding credit call record are associated and saved in the first database, and the credit call record and the corresponding credit data are simultaneously associated and saved in the fourth database, wherein the fourth database is not an offline database, so that offline services can use the credit data in the fourth database.

[0042] Based on Example 1, this embodiment adds a query on the call status in the credit call record, and determines whether the call is successful based on the call status. If the call is not successful, the re-call operation is performed in time; in addition, a message log is added, and the processing status of the message log is queried according to the scheduled task, and then the data verification operation of the second database and the third database is performed according to the processing status to ensure that all consulting data obtained have been synchronized to the second database and the third database to avoid errors in credit data.

[0043] Example 3 Figure 3 The first flow chart of a credit data processing method according to an embodiment of the present application is shown. Exemplarily, the credit data processing method includes the following steps: Step S10, in response to the credit calling command, determine the credit calling channel according to the credit multiplexing rule in the credit calling command.

[0044] Among them, the credit reuse rules include mandatory query, mandatory cache, and reuse of local data within a preset time; According to the credit reuse rule in the credit call command, the credit call channel is determined, including: if the credit reuse rule is a forced query, the credit call channel is determined to obtain credit data from an external data supplier; if the credit reuse rule is a forced cache, the credit call channel is determined to obtain credit data from a second database; if the credit reuse rule is to reuse local data within a preset time, the credit call channel is determined to obtain credit data from the first database. If the corresponding credit data is not obtained from the first database, continue to obtain credit data from external data suppliers.

[0045] Step S20: If it is determined that the credit calling channel is to obtain credit data from an external data supplier, after obtaining the credit data, the credit data is stored in the first database, the second database and the third database respectively according to the above-mentioned credit data storage method.

[0046] It should be noted that when the retrieved credit data is stored in the first database, the second database and the third database, the credit data will also be stored in the fourth database.

[0047] Step S30: If it is determined that the credit information calling channel is to obtain credit information data from a local database, then the corresponding credit information data is obtained from the first database or the second database.

[0048] In some embodiments, Figure 4 As shown, after the credit data call begins, step S11 is executed to determine the credit call channel according to the credit multiplexing rule in the credit call command.

[0049] The credit calling command at least includes the credit subject and credit reuse rules.

[0050] In this step, the credit reuse rules include forced query, forced caching, and reuse of local data within a preset time, wherein forced query means that the corresponding credit data must be retrieved from an external supplier. For example, if a certain credit subject has never retrieved credit data before, or the credit subject is not a loan overdue customer or a bad debt customer, in this case, a forced query method is usually used; forced caching means obtaining the latest credit data of the corresponding credit subject from the second database. In this case, it does not matter whether the retrieved credit data is recent, as long as it is the credit data of the credit subject that was last saved in the second database; reuse of local data within a preset time means obtaining credit data within a preset time from the local database, which usually refers to obtaining credit data from the first database.

[0051] If the credit channel is determined to be a mandatory inquiry, step S12 is executed to send a corresponding credit inquiry to the external supplier.

[0052] In this step, if it is determined that the credit channel is a mandatory query, the credit data corresponding to the credit subject in the credit call command is directly sent to the external supplier. After the corresponding credit data is obtained through the external supplier, step S13 is executed to store the corresponding credit data in the local database according to the method of embodiment 1 or embodiment 2. Specifically, the credit data is stored in the first database, the second database, the third database and the fourth database at the same time, wherein the first database is a MYSQL database, the second database and the third database are both mongodb databases, and the fourth database is a HIVE database.

[0053] If the credit channel reuses local data within a preset time, step S14 is executed to retrieve corresponding credit data from the first database. If no corresponding credit data is retrieved from the first database, the process returns to step S12.

[0054] If the credit channel is a mandatory cache, step S15 is executed to retrieve the corresponding credit data from the second database.

[0055] In some implementations, it also includes: determining a database for querying credit data based on credit result query conditions.

[0056] If the query is for the last piece of credit data of the credit subject, the query is performed directly from the second database. If the query is for the credit data of the credit subject within a preset time, the query is performed from the first database or the third database according to the time requirement. If the preset time is within the time range of the credit data stored in the first database, the query can be performed directly from the first database. If the preset time is no longer within the time range of the credit data stored in the first database, the query is performed directly from the third database.

[0057] The following is a comparison between the method of storing credit data in a database in the prior art and the method of processing credit data in this application using the Jemeter stress testing tool. Figure 5 As shown, the method before optimization is the existing technology, and the method after optimization is the method of this application. In the existing technology, as long as there is a large flow of data query access; the system time consumption and DB monitoring will often generate warnings. According to the stress test, compared with the existing technology, the time consumption of credit data retrieval or query in this application is reduced by 10 times to 100ms, and the throughput of the interface is also increased by 100 times to 1000qps. It can be seen that the processing rate of credit data is improved by the method of this application, and the operation and maintenance cost is also low.

[0058] Example 4 Figure 6 A schematic diagram of the structure of a credit information data storage device according to an embodiment of the present application is shown. Exemplarily, the credit information data storage device comprises: The writing module 100 is used to write a corresponding credit calling record into the first database in response to obtaining a credit calling command from an external data supplier.

[0059] The synchronization module 200 is used to obtain the credit data corresponding to the credit call command, associate the credit data with the corresponding credit call record and save it in the first database, and synchronously associate the credit call record and the corresponding credit data and save it in the second database and the third database.

[0060] Among them, the first database is a database that only retains credit data within a preset time; among them, the second database is a database that only retains the latest record of the credit subject; and the third database is a full database.

[0061] It can be understood that the device of this embodiment corresponds to the credit data storage method of the above embodiment, and the optional items in the above embodiment are also applicable to this embodiment, so they will not be described repeatedly here.

[0062] Example 5 Figure 7 A structural schematic diagram of a credit data processing device according to an embodiment of the present application is shown. Exemplarily, the credit data processing device includes: The determination module 10 is used to respond to the credit calling command and determine the credit calling channel according to the credit multiplexing rule in the credit calling command.

[0063] The storage module 20 is used to store the credit data in the first database, the second database and the third database respectively according to the above-mentioned credit data storage method after obtaining the credit data if it is determined that the credit calling channel is to obtain the credit data from an external data supplier.

[0064] The calling module 30 is used to obtain the corresponding credit data from the first database or the second database if it is determined that the credit calling channel is to obtain the credit data from the local database.

[0065] The present application also provides a terminal device. Exemplarily, the terminal device includes a processor and a memory, wherein the memory stores a computer program, and the processor runs the computer program, thereby enabling the terminal device to execute the above-mentioned credit data storage method or the above-mentioned credit data processing method.

[0066] Among them, the processor can be an integrated circuit chip with signal processing capabilities. The processor can be a general-purpose processor, including a central processing unit (CPU), a graphics processing unit (GPU), a network processor (NP), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or at least one of other programmable logic devices, discrete gates or transistor logic devices, and discrete hardware components. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc., which can implement or execute the methods, steps and logic block diagrams disclosed in the embodiments of the present application.

[0067] The memory may be, but is not limited to, a random access memory (RAM), a read only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electric erasable programmable read-only memory (EEPROM), etc. The memory is used to store a computer program, and the processor may execute the computer program accordingly after receiving an execution instruction.

[0068] The present application also provides a computer-readable storage medium for storing the computer program used in the above terminal device. For example, the computer-readable storage medium may include but is not limited to: a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and other media that can store program codes.

[0069] In several embodiments provided in the present application, it should be understood that the disclosed devices and methods can also be implemented in other ways. The device embodiments described above are merely schematic. For example, the flowcharts and structure diagrams in the accompanying drawings show the possible architecture, functions and operations of the devices, methods and computer program products according to multiple embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, a program segment or a part of a code, and the module, a program segment or a part of a code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in an alternative implementation, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the structure diagram and / or the flow diagram, and the combination of boxes in the structure diagram and / or the flow diagram, can be implemented with a dedicated hardware-based system that performs a specified function or action, or can be implemented with a combination of dedicated hardware and computer instructions.

[0070] In addition, the functional modules or units in the various embodiments of the present application may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.

[0071] If the functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling a computer device (which can be a smart phone, a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application.

[0072] The above description is only a specific implementation manner of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application.

Claims

1. A credit data storage method, characterized in that: include: In response to a credit calling command for obtaining credit data from an external data supplier, writing a corresponding credit calling record into the first database; After obtaining the credit data corresponding to the credit call command, the credit data is associated with the corresponding credit call record and saved in the first database, and the credit call record and the corresponding credit data are associated and saved in the second database and the third database at the same time; Among them, the first database is a database that only retains credit data within a preset time; the second database is a database that only retains the latest record of the credit subject; and the third database is a full database.

2. The credit information data storage method according to claim 1, characterized in that: The credit call record includes a credit subject, a serial number, and a call status; wherein the serial number is used to delete the credit data that does not conform to the preset time according to the serial number when updating the first database; After obtaining the credit data corresponding to the credit calling command, the method further includes: Update the calling status to a calling success status; A corresponding message log is written into the local message table, and the processing state of the message log is defined as an unsynchronized state; wherein the message log corresponds one-to-one to the credit call record.

3. The credit information data storage method according to claim 2, characterized in that: The credit calling record is queried at a first preset interval, and if the calling status in the credit calling record includes a processing status, all credit calling tasks whose calling status is the processing status are reprocessed.

4. The credit information data storage method according to claim 2, characterized in that: After synchronously saving the credit information call record and the corresponding credit information data in the second database and the third database, the method further includes: The processing status of the message log corresponding to the credit call record is updated to a synchronization status.

5. The credit information data storage method according to claim 4, characterized in that: querying the message log in the message log at a second preset interval for the message log in which the processing status is an unsynchronized status; querying the second database and the third database according to the message log in the unsynchronized state whether they contain the corresponding credit data; If included, updating the processing status of the corresponding message log to a synchronization status; If not included, the corresponding credit data and the credit call record are resynchronized.

6. The credit information data storage method according to claim 1, characterized in that: After obtaining the credit data corresponding to the credit call command, the credit data is associated with the corresponding credit call record and saved in the first database, and the credit call record and the corresponding credit data are simultaneously associated and saved in the fourth database; Wherein, the fourth database is an offline database.

7. A credit data processing method, characterized in that: include: In response to the credit calling command, determining a credit calling channel according to a credit multiplexing rule in the credit calling command; If it is determined that the credit calling channel is to obtain credit data from an external data supplier, after obtaining the credit data, the credit data is stored in the first database, the second database and the third database respectively according to the credit data storage method according to any one of claims 1 to 6; If it is determined that the credit information calling channel is to obtain the credit information data from a local database, the corresponding credit information data is obtained from the first database or the second database.

8. The credit data processing method according to claim 7, characterized in that: The credit reuse rules include mandatory query, mandatory cache, and reuse of local data within a preset time; Determining the credit calling channel according to the credit multiplexing rule in the credit calling command includes: If the credit reuse rule is the mandatory query, determining the credit calling channel is to obtain credit data from an external data supplier; If the credit reuse rule is the mandatory cache, determining the credit calling channel is to obtain the credit data from the second database; If the credit reuse rule is to reuse local data within the preset time, the credit call channel is determined to obtain the credit data from the first database. If the corresponding credit data is not obtained from the first database, the credit data continues to be obtained from the external data supplier.

9. A terminal device, characterized in that: The terminal device includes a processor and a memory, the memory stores a computer program, and the processor is used to execute the computer program to implement the credit data storage method described in any one of claims 1-6 or the credit data processing method described in any one of claims 7-8.

10. A computer-readable storage medium, characterized in that: It stores a computer program, which, when executed on a processor, implements the credit data storage method according to any one of claims 1-6 or the credit data processing method according to any one of claims 7-8.

Images