Detailed Description
The technical solutions of the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is apparent that the described embodiments are only some embodiments of the present specification, not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are intended to be within the scope of the present disclosure.
Please refer to fig. 1, 2 and 3. Embodiments of the present specification provide a data processing system.
In this embodiment, the data processing system may include a client. The client may be, for example, a PC, a server, an industrial personal computer (industrial control computer), a mobile smart phone, a tablet electronic device, a portable computer (e.g., a notebook computer, etc.), a Personal Digital Assistant (PDA), or a desktop computer or smart wearable device, etc.
In this embodiment, the data processing system may further include a service server of a third party payment authority. The third party payment mechanism may include, for example, a payment treasures, a financial payment, a hundred degrees wallet, etc. The business server may be used to provide business services such as account recharging, loan, online shopping, etc. The service server may be one server, or may also be a server cluster including a plurality of servers.
In this embodiment, the data processing system may further include an accounting server of the third party payment mechanism. The accounting server may be used to provide billing and reconciliation services. The accounting server may be one server, or may also be a server cluster including a plurality of servers. The accounting server and the service server may be independent servers, or may be integrated in the same server. The accounting server may be provided with an accounting data table, an idempotent data table, and a clearing data table.
The accounting data table may be used to hold accounting data for the third party payment mechanism. The accounting data table may have at least one field, and the accounting data may include an element value corresponding to the at least one field. For example, the accounting data table may include an order number field, a transaction amount field, a transaction channel field, a currency field, etc., and the accounting data may include element values of an order number, a transaction amount, a transaction channel, a currency, etc. The idempotent data table may be used to perform idempotent processing on the accounting data to avoid saving duplicate accounting data to the accounting data table. The idempotent data table can have at least one field. In an actual process, at least one field can be selected from the accounting data table as a field in the idempotent data table according to service requirements. In one example scenario, a field (e.g., an order number field) whose corresponding data value can uniquely identify a service may be selected from the accounting data table as a field in the idempotent data table. Some or all of the fields of the idempotent data table can be provided with a unique constraint. The uniqueness constraint can ensure that the data in the fields is unique in the idempotent data table. Thus, the idempotent processing of the accounting data can be realized through the unique constraint. The clearing data table may be used to hold clearing data for a clearing institution. The clearing house may include, for example, a bank, a silver-tie, etc. The clearing data table may have at least one field. The fields in the clearing data table and the fields in the accounting data table may be partially or wholly identical. The clearing data may include at least one element value. The kind of the element value in the clearing data and the kind of the element value in the accounting data may be partially or wholly the same.
The number of the accounting data table, the idempotent data table and the clearing data table may be one, respectively. Alternatively, in the case of a large data size, a plurality of data tables may be used to store data to maintain performance in operating on the data in the data tables. Thus the number of the accounting data table, the idempotent data table and the clearing data table can also be multiple respectively. In particular, the accounting server may be provided with a plurality of data table sets, each of which may include an accounting data table, an idempotent data table and a clearing data table corresponding to each other. The accounting data table, idempotent data table, and clearing data table in each data table group may each correspond to a table identification. For example, the accounting server may be provided with data table sets A, B and C. The data table set a may include an accounting data table a_zw, an idempotent data table a_md, a clearing data table a_qs. The table identifier corresponding to the accounting data table a_zw may be a_zw; the table identification corresponding to the idempotent data table A_MD can be A_MD; the table identification corresponding to the clearing data table a_qs may be a_qs. The data table set B may include an accounting data table b_zw, an idempotent data table b_md, a clearing data table b_qs. The table identifier corresponding to the accounting data table b_zw may be b_zw; the table identification corresponding to the idempotent data table b_md may be b_md; the table identification corresponding to the clearing data table b_qs may be b_qs. The data table set C may include an accounting data table c_zw, an idempotent data table c_md, a clearing data table c_qs. The table identifier corresponding to the accounting data table c_zw may be c_zw; the table identification corresponding to the idempotent data table c_md may be c_md; the table identification corresponding to the clearing data table c_qs may be c_qs.
In this embodiment, the data processing system may further include an institution server of the clearing institution. The clearing house may include, for example, a bank, a silver-tie, etc. The institution server may be used to provide payment services. The organization server may be one server or may also be a server cluster including a plurality of servers.
Based on the third party payment mechanism, the user can perform operations such as recharging (also known as transferring), settling (also known as presenting), paying, transferring, and the like. The following describes the technical solution of the embodiments of the present specification in detail using a recharging scenario as an example. The accounts involved in this scenario example may include a first account, a second account, and a third account. The first account may include an account opened by a user at a clearing house, such as an account opened by a user at a construction bank, an industrial and commercial bank, or the like. The second account may include an account opened by the user at a third party payment mechanism, for example, an account opened by the user at a third party payment mechanism such as a payment treasures, a financial payment, a hundred degree wallet, etc. The third account may include an account opened by a third party payment mechanism at a clearing institution, such as an account opened by a payment facilitator at a bank, such as a construction bank, an industrial and commercial bank, or the like.
In this scenario example, the user may perform a recharge operation at the client. And responding to the recharging operation, the client can send a recharging request to the service server, wherein the recharging request can carry information such as a first account, a recharging amount, a second account and the like. The service server may receive the recharge request; a payment request may be sent to the institution server through a financial channel to inform the clearing institution to deduct the recharge amount from the first account and to increase the recharge amount in the third account.
In this scenario example, a clearing mode may be agreed between the clearing house and the third party payment house. The clearing time between the clearing house and the third party payment house is typically later than the settling time between the third party payment house and the user, depending on the agreed clearing way. For example, the clearing house and the third party payment house may agree to take a clearing mode of "t+3", where "T" refers to the payment request submission date; "+3" refers to the third workday after the payment request was submitted. The institution server may thus receive a payment request; the recharge amount may be deducted from the first account; and feeding back a message of successful deduction to the service server. It should be noted that, according to the agreed clearing mode, the institution server will not increase the recharging amount in the third account at this time; but the recharge amount is increased in the third account after the contracted clearing time has been reached.
In this scenario example, the service server may receive a message that the deduction was successful; the recharge amount may be increased in a second account; information of successful recharging can be fed back to the client. The client may receive information that the recharge was successful. In addition, the service server can also send accounting data corresponding to the recharging service to the accounting server. The accounting server may receive the accounting data; the accounting data may be written to an idempotent data table. If the writing is successful, the accounting data is indicated to meet the unique constraint of the idempotent data table, namely, the fact that the recharging service is not repeated operation of the user is indicated, and the accounting server can write the accounting data into the accounting data table. If the writing fails, the account data does not meet the unique constraint of the idempotent data table, namely the repeated operation that the recharging service is a user is indicated, and the account server can ignore the account data. Of course, if the writing fails, the accounting server may also execute other predetermined actions, which are not described herein. In view of the fact that the idempotent data table includes some or all of the fields in the accounting data table, writing the accounting data into the idempotent data table may be understood as writing some or all of the element values in the accounting data into the idempotent data table, for example, writing the element values corresponding to the fields of the idempotent data table in the accounting data into the idempotent data table.
The number of idempotent data tables may be one. The accounting server can thus write the accounting data to the idempotent data table. Alternatively, the number of idempotent data tables may be multiple. The accounting server can select a target idempotent data table from the plurality of idempotent data tables; the accounting data can be written into a selected target idempotent data table. For example, the accounting server can provide N idempotent data tables. The table identifiers corresponding to the N idempotent data tables are A0, A1, A2, … and A (N-1) respectively. Then, the accounting server may calculate a hash value of one or more element values (e.g., order numbers) in the accounting data; when the remainder of dividing the hash value by N is 0, an idempotent data table corresponding to the table identifier A0 can be selected as a target idempotent data table; when the remainder of dividing the hash value by N is 1, the idempotent data table corresponding to the table identifier A1 can be selected as a target idempotent data table; and so on, when the remainder of dividing the hash value by N is N-1, the idempotent data table corresponding to the table identifier A (N-1) can be selected as the target idempotent data table. Of course, those skilled in the art will appreciate that the above process of selecting the target idempotent data table is merely an example, and that the accounting server may in fact select the target idempotent data table in other ways.
The number of the accounting data tables may be one. The accounting server may thus write the accounting data to the accounting data table. Alternatively, the number of the accounting data tables may be plural. The accounting server may thus select a target accounting data table from the plurality of accounting data tables; the accounting data may be written to a selected target accounting data table. The process of selecting the target accounting data table by the accounting server can be contrasted with the process of selecting the target idempotent data table.
In this scenario example, the institution server may also send a clearing file to the accounting server after the contracted clearing time has arrived. The accounting server may receive a clearing file; the clearing file can be parsed to obtain clearing data; the clearing data may be written to the idempotent data table. If the writing result shows that the clearing data meets the uniqueness constraint, the accounting server can determine that the account checking state of the clearing data is an abnormal state; the clearing data may be written into an exception data table for holding clearing data whose reconciliation status is an exception status. If the writing result shows that the clearing data does not meet the uniqueness constraint, the accounting server can determine that the reconciliation state of the clearing data is a state to be checked; the clearing data table may be written into a clearing data table for holding clearing data whose reconciliation status is a status to be reconciled.
In this scenario example, the accounting server obtains the clearing data typically later than the accounting data, since the clearing time contracted between the clearing house and the third party payment house is typically later than the settlement time between the third party payment house and the user. By utilizing the characteristics, the scene example can realize the check between the accounting data and the clearing data when the clearing data falls to the ground, and avoid influencing the performance of the database.
Whereas the clearing time agreed between the clearing house and the third party payment house is typically later than the settling time between the third party payment house and the user, the accounting server typically obtains the clearing data later than the accounting data. Based on this feature, the present embodiment may provide a reconciliation method. The account checking method takes an accounting server as an execution main body. Please refer to fig. 1, 2 and 3. The reconciliation method may include the following steps.
Step S10: clearing data is received from a clearing house.
In this embodiment, the institution server of the clearing institution may send a clearing file to the accounting server. The accounting server may receive a clearing file; and analyzing the clearing file to obtain at least one clearing data. In particular, the institution server may send the clearing file directly to the accounting server, or may also send the clearing file indirectly to the accounting server via other servers. The clearing file may be a funds detail interaction file agreed between the third party payment mechanism and the clearing mechanism, and may specifically include clearing data corresponding to at least one service.
Step S12: writing the clearing data into an idempotent data table.
In this embodiment, the idempotent data table can include at least one field for which a unique constraint is set. The idempotent data table can be used for carrying out idempotent processing on the accounting data so as to avoid storing repeated accounting data to the accounting data table. Whereas the accounting server usually obtains the clearing data later than the accounting data, the idempotent data table may have accounting data written in advance. Specifically, the accounting data may include an element value corresponding to the unique constraint field being set, and the idempotent data table may be written in advance with the element value corresponding to the unique constraint field being set.
In this embodiment, the accounting server may write each clearing data to an idempotent data table. The accounting server writes the clearing data into the idempotent data table, and it is understood that writing some or all of the element values in the clearing data into the idempotent data table, for example, writing the element values corresponding to the fields of the idempotent data table in the clearing data into the idempotent data table. In particular, the number of idempotent data tables may be one. The accounting server can thus write each clearing data to the idempotent data table. Alternatively, the number of idempotent data tables may be multiple. Thus, for each clearing data, the accounting server can select a target idempotent data table from the plurality of idempotent data tables according to the clearing data; the clearing data can be written to a selected target idempotent data table. The process of selecting the target idempotent data table by the accounting server can refer to the foregoing scenario example, and will not be described herein.
Step S13: and determining the reconciliation state of the clearing data according to the writing result of the clearing data.
In this embodiment, the reconciliation status may include an abnormal status and a status to be reconciled. The abnormal state may include, for example, a multi-account state, and the state to be checked may include, for example, a normal state and an error state. The following describes the multi-account status, normal status, and error status in one example scenario. In this scenario example, both the clearing data and the accounting data may include element values (e.g., order numbers) that can uniquely identify a business. For convenience of description, the element value may be referred to as a key element value. Then, for a certain clearing data, when there is no accounting data with the same key element value as the clearing data, it can be determined that there is no accounting data corresponding to the clearing data, and then it can be determined that the accounting state of the clearing data is a multi-account state; when the accounting data with the same key element value as the clearing data exists, the accounting data corresponding to the clearing data can be determined to exist, and then the checking state of the clearing data can be determined to be the state to be checked. Further, when there is accounting data having the same key element value as the clearing data and other element values between the clearing data and the accounting data are the same, the checking state of the clearing data can be determined to be a normal state; when there is accounting data having the same key element value as the clearing data, but there is other element value different between the clearing data and the accounting data, the reconciliation status of the clearing data can be determined as an error status.
In this embodiment, the idempotent data table may be written with accounting data in advance. The accounting data in the idempotent data table corresponds to the accounting data in the accounting data table. The idempotent data table can include at least one field that sets a unique constraint. The clearing data may include an element value corresponding to the unique constraint field being set. So, for each clearing data, if the writing is successful, the clearing data is indicated to meet the unique constraint, namely, no accounting data corresponding to the clearing data exists, and the accounting server can determine that the accounting state of the clearing data is an abnormal state; if the writing fails, the accounting server can determine that the accounting state of the clearing data is a state to be checked, wherein the accounting state of the clearing data does not meet the unique constraint, namely the accounting server indicates that the accounting data corresponding to the clearing data exists.
In one implementation of this embodiment, after determining that the reconciliation status of the clearing data is an abnormal status, the accounting server may further write the clearing data into an abnormal data table. The exception data table may be used to hold clearing data for which the reconciliation status is an exception status. The accounting server may also write the clearing data to a clearing data table after determining that the reconciliation status of the clearing data is a status to be reconciled. The clearing data table is used for storing clearing data with checking states being states to be checked. In particular, the number of clearing tables may be one. The accounting server may thus write the clearing data to the clearing data table. Alternatively, the number of the clearing data tables may be plural. The accounting server may thus select a target clearing data table from the plurality of clearing data tables; the clearing data may be written to a selected target clearing data table. The process of selecting the target clearing data table by the accounting server may refer to the foregoing scenario example, and will not be described herein. It should be noted that, the accounting server may further identify the reconciliation status of the clearing data in the clearing data table by using other methods. For example, the accounting server may further perform a full table association query on the accounting data table and the clearing data table to further identify that the reconciliation status of the clearing data in the clearing data table is a normal status or an error status.
In the present description embodiment, the accounting server may receive the clearing data from the clearing house; the clearing data may be written to an idempotent data table, which may include at least one field for which a unique constraint is set, and pre-written with accounting data from a payment mechanism; the reconciliation status of the clearing data may be determined based on the written result of the clearing data. In this way, in this embodiment, the accounting server may check the accounting data piece by piece in combination with the unique constraint of the idempotent data table when the accounting data arrives, so as to avoid the influence of the accounting process on the database performance.
Please refer to fig. 4. The embodiment of the specification also provides a reconciliation device. The reconciliation device may include the following elements.
A receiving unit 20 for receiving clearing data from a clearing house;
a writing unit 22 for writing the clearing data into an idempotent data table; the idempotent data table comprises at least one field with unique constraint and is pre-written with accounting data from a payment mechanism;
a determining unit 24, configured to determine a reconciliation status of the clearing data according to a writing result of the clearing data.
Please refer to fig. 5. The embodiment of the specification also provides a server. The server may include a memory and a processor.
In this embodiment, the memory may be implemented in any suitable manner. For example, the memory may be a read-only memory, a mechanical hard disk, a solid state hard disk, or a usb disk. The memory may be used to store computer instructions.
In this embodiment, the processor may be implemented in any suitable manner. For example, the processor may take the form of, for example, a microprocessor or processor, and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), a programmable logic controller, and an embedded microcontroller, among others. The processor may execute the computer instructions to implement the steps of: receiving clearing data from a clearing house; writing the clearing data into an idempotent data table; the idempotent data table comprises at least one field with unique constraint and is pre-written with accounting data from a payment mechanism; and determining the reconciliation state of the clearing data according to the writing result of the clearing data.
It should be noted that, in the present specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment is mainly described in a different point from other embodiments. In particular, for the server embodiment and the device embodiment, since they are substantially similar to the method embodiment, the description is relatively simple, and reference is made to the partial description of the method embodiment for relevant points.
In addition, it will be appreciated that those skilled in the art, upon reading the present specification, may readily devise some or all of the embodiments that, although still within the scope of the disclosure and protection herein, may be combined without undue effort.
In the 90 s of the 20 th century, improvements to one technology could clearly be distinguished as improvements in hardware (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) or software (improvements to the process flow). However, with the development of technology, many improvements of the current method flows can be regarded as direct improvements of hardware circuit structures. Designers almost always obtain corresponding hardware circuit structures by programming improved method flows into hardware circuits. Therefore, an improvement of a method flow cannot be said to be realized by a hardware entity module. For example, a programmable logic device (Programmable Logic Device, PLD) (e.g., field programmable gate array (Field Programmable Gate Array, FPGA)) is an integrated circuit whose logic function is determined by the programming of the device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips 2. Moreover, nowadays, instead of manually manufacturing integrated circuit chips, such programming is mostly implemented with "logic compiler" software, which is similar to the software compiler used in program development and writing, and the original code before the compiling is also written in a specific programming language, which is called hardware description language (Hardware Description Language, HDL), but HDL is not only one, but a plurality of kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), lava, lola, myHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog2 are most commonly used at present. It will also be apparent to those skilled in the art that a hardware circuit implementing the logic method flow can be readily obtained by merely slightly programming the method flow into an integrated circuit using several of the hardware description languages described above.
The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. One typical implementation is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.
From the above description of embodiments, it will be apparent to those skilled in the art that the present description may be implemented in software plus a necessary general purpose hardware platform. Based on this understanding, the technical solution of the present specification may be embodied in essence or a part contributing to the prior art in the form of a software product, which may be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the method described in the embodiments or some parts of the embodiments of the present specification.
The specification is operational with numerous general purpose or special purpose computer system environments or configurations. For example: personal computers, server computers, hand-held or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
The description may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
Although the present specification has been described by way of example, it will be appreciated by those skilled in the art that there are many variations and modifications to the specification without departing from the spirit of the specification, and it is intended that the appended claims encompass such variations and modifications as do not depart from the spirit of the specification.