A distributed call bill batch pricing method and system based on IGNITE memory database

Abstract

The present application provides a distributed bill pricing method and system based on IGNITE memory database. The method includes: uploading the source table data of the data synchronization event to the data table of the Ignite memory database to complete static data synchronization; writing the monitored changes to the corresponding data table of the Ignite memory database to complete dynamic data synchronization; synchronizing the partition ID of the data table of the data synchronization event and the data table of the monitored changes to complete bill pricing; according to the primary key of the data table to be audited, reading the data corresponding to the data in the table to be audited in the data table of the Ignite memory database, and comparing each field to complete the data audit. The present invention can save historical versions of data; can avoid retrieving the latest table partition every time a business query is made; and can reduce the memory usage of the Ignite database cluster.

Description

Technical Field

[0001] The present application relates to the field of computer technology, in particular to the field of big data processing and distributed computing technology, and more particularly to a distributed call bill batch pricing method, system, electronic device and storage medium based on an IGNITE memory database. Background Art

[0002] The bill batching program needs to frequently query the database during the bill processing process, so it is necessary to use memory for data caching to speed up processing performance. In the prior art, the batching program obtains user data, resource instance data and other information by querying the shared memory database. The data structure of the shared memory database is similar to that of a relational database, and data synchronization is performed by monitoring the binlog information of the main database. This technical solution has the following problems:

[0003] 1. The shared memory database depends on the system environment of a server. The bill pricing program must be deployed on the same server as the shared memory database. When the bill pricing system is heavily loaded and system expansion is required, the shared memory database and bill pricing program need to be deployed on a new server. The data initialization time of the shared memory database is long and cannot be expanded quickly. And because the new server also needs to cache all data in memory, the expansion cost is high.

[0004] 2. When using multiple servers for batch pricing of call bills, it is difficult to ensure the consistency of the shared memory data of each server because the shared memory data of each server is independent of each other. The risk of data inconsistency increases with the number of servers.

[0005] Since the shared memory database does not have clustering capabilities, all data needs to be stored in the memory of a server. When the amount of data increases, the only way to deal with it is to expand vertically by expanding the memory of the server, which is very costly. Summary of the invention

[0006] The purpose of the present invention is to provide a distributed call bill batch pricing method and system based on IGNITE memory database.

[0007] According to a first aspect of the present invention, a distributed call bill batch pricing system based on an IGNITE memory database is provided, comprising:

[0008] Step S1, receiving a data synchronization event that is timed or triggered by a condition, uploading the source table data of the data synchronization event to the data table of the Ignite memory database, and completing static data synchronization;

[0009] Step S2: Monitor the database Binlog on the source database server and write the monitored changes to the data table of the corresponding Ignite memory database to complete dynamic data synchronization;

[0010] Step S3, regularly read the data partition table of the Ignite memory database, synchronize the data table of the data synchronization event and the partition ID of the monitored changed data table, and complete the call bill batch pricing;

[0011] Step S4: According to the primary key of the data table to be audited, read the data corresponding to the data in the table to be audited from the data table of the Ignite memory database, and compare each field to complete the data audit.

[0012] According to the method of the first aspect of the present invention, in step S1, receiving a data synchronization event that is timed or triggered by a condition, uploading the source table data of the data synchronization event to a data table in the Ignite memory database, and completing static data synchronization includes:

[0013] Receive a data synchronization event that is scheduled or triggered by a condition, including the table name of the data synchronization event;

[0014] Exporting source table data of the data synchronization event;

[0015] Upload the source table data to the Ignite in-memory database;

[0016] Update the partition ID of the corresponding data table in the data partition table of the Ignite memory database;

[0017] Send data synchronization event messages to the Ignite data partition message queue.

[0018] According to the method of the first aspect of the present invention, in step S2, monitoring the database Binlog on the source database server and writing the monitored changes into the data table of the corresponding Ignite memory database to complete dynamic data synchronization include:

[0019] Monitor the database Binlog on the source database server and send the monitored changes to the Ignite data partition message queue;

[0020] Receives monitored change messages from the Ignite data partition message queue, and writes the changes in the message to the data table of the corresponding Ignite in-memory database.

[0021] According to the method of the first aspect of the present invention, in step S2, the method further includes:

[0022] Write the monitored changes to the log for record keeping.

[0023] According to the method of the first aspect of the present invention, in step S3, the data partition table of the Ignite memory database is read at a fixed time, the data table of the data synchronization event is synchronized and the partition ID of the data table of the monitored change is synchronized, and the batch pricing of the call list is completed, including:

[0024] Receive messages from the Ignite data partition message queue and store the partition ID of the data table in the local cache;

[0025] Apply business code to query the Ignite in-memory database, find the latest data partition based on the table name and partition ID of the data table, and use SQL to query the data;

[0026] Read the data partition table of the Ignite memory database regularly, synchronize the data table of data synchronization events and the partition ID of the data table of monitored changes.

[0027] According to the method of the first aspect of the present invention, in step S4, according to the primary key of the data table to be audited, the data corresponding to the data in the table to be audited is read out from the data table of the Ignite memory database, and each field is compared, and the data audit is completed, including:

[0028] Receive data audit events, including the table name of the data to be audited;

[0029] Batch read data from the audit data table;

[0030] According to the primary key of the data table to be audited, read the corresponding data from the Ignite data table and compare each field;

[0031] To compare different data, perform update operations in the Ignite data table.

[0032] According to the method of the first aspect of the present invention, in step S4, the method further includes:

[0033] Update the data audit record and record the number of data that failed the comparison.

[0034] The second aspect of the present invention discloses a distributed call bill batch pricing system based on the IGNITE memory database; the system comprises:

[0035] The first processing module, i.e., the static data synchronization system, is configured to receive a data synchronization event that is timed or triggered by a condition, and upload the source table data of the data synchronization event to the data table of the Ignite memory database to complete the static data synchronization;

[0036] The second processing module, i.e., the dynamic data synchronization system, is configured to monitor the database Binlog on the source database server and write the monitored changes to the data table of the corresponding Ignite memory database to complete dynamic data synchronization;

[0037] The third processing module, i.e., the bill batch pricing system, is configured to periodically read the data partition table of the Ignite memory database, synchronize the data table of the data synchronization event and the partition ID of the monitored changed data table, and complete the bill batch pricing;

[0038] The fourth processing module, i.e., the data audit system is configured to read the data corresponding to the data in the table to be audited in the data table of the Ignite in-memory database according to the primary key of the table to be audited, and compare each field to complete the data audit.

[0039] According to a third aspect of the present invention, the present application shows an electronic device, which includes: a processor; a memory for storing instructions executable by the processor; wherein the processor is configured to execute the method described in any one of the above aspects.

[0040] In a fourth aspect of the present invention, the present application shows a non-temporary computer-readable storage medium, when the instructions in the storage medium are executed by a processor of an electronic device, the electronic device is enabled to execute the method described in any of the above aspects.

[0041] In a fifth aspect of the present invention, the present application shows a computer program product. When instructions in the computer program product are executed by a processor of an electronic device, the electronic device is enabled to execute the method described in any one of the above aspects.

[0042] It can be seen from the above scheme that the embodiment of the present invention provides a distributed call bill batch pricing method and system based on the IGNITE memory database, which has the following beneficial effects:

[0043] By using the Ignite in-memory database in the call bill batch pricing process, the cluster has the advantages of good horizontal scalability and low expansion cost.

[0044] By using the Ignite distributed memory database, it has the advantage of strong data consistency in the call bill batch pricing cluster.

[0045] By storing different versions of table data in different data partitions, historical data can be retained, making it easier to troubleshoot problems.

[0046] By utilizing the message queue function of the Ignite memory database to synchronize data partition ID information, it avoids actively retrieving table partition information during business queries, and has the characteristics of high query performance.

[0047] By using the native persistence function of the Ignite in-memory database, cold data can be stored on disk, which has the advantages of less memory usage and low cost. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] Figure 1 A flowchart of a distributed call bill batch pricing method based on an IGNITE memory database provided according to an embodiment;

[0049] Figure 2 A static data synchronization flow chart provided according to an embodiment;

[0050] Figure 3 A dynamic data synchronization flow chart provided according to an embodiment;

[0051] Figure 4 A flowchart of bill pricing provided according to an embodiment;

[0052] Figure 5 A data audit flow chart provided according to an embodiment;

[0053] Figure 6 A structural diagram of a distributed call bill batch pricing system based on an IGNITE memory database according to an embodiment of the present invention;

[0054] Figure 7 is a block diagram of an electronic device of the present application;

[0055] Figure 8 It is a block diagram of a computer-readable storage medium of the present application. DETAILED DESCRIPTION

[0056] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0057] Glossary

[0058] Apache Ignite: An open source distributed in-memory database that supports key-value pairs and relational table data structures. It also supports transactions, native persistence and other functions.

[0059] Call bill price: A call bill refers to the usage information generated by the cloud resource instance used by the customer in the cloud service. Call bill price refers to the calculation of the customer's payable amount, discount amount and other data based on the call bill information.

[0060] Shared memory database: A memory database implemented using the shared memory function in the Unix system. When a business program needs to read data from the database, it must first connect to the shared memory slice and then directly read the data in it.

[0061] Binlog (Binary Log): Binary log contains events that describe database changes, such as table creation operations or table data changes. The main uses of Binlog are data replication and data recovery.

[0062] Therefore, how to provide a distributed call bill batch pricing method, system, electronic device and storage medium based on the IGNITE memory database has become a technical problem that urgently needs to be solved in this field.

[0063] This application solves the following problems by replacing the shared memory database used by the billing price program in the billing service with the Ignite distributed memory database:

[0064] The shared memory database depends on the system environment of a server, and the bill batch pricing program must be deployed on the same server as the shared memory database. When the bill batch pricing system is heavily loaded and system expansion is required, the shared memory database and the bill batch pricing program need to be deployed on a new server. The data initialization time of the shared memory database is long, and it is not possible to expand quickly. And because the new server also needs to cache all data in memory, the expansion cost is high.

[0065] When using multiple servers for batch pricing of call bills, it is difficult to ensure the consistency of the shared memory data of each server because the shared memory data of each server is independent of each other. The risk of data inconsistency increases with the number of servers.

[0066] Since the shared memory database does not have clustering capabilities, all data needs to be stored in the memory of a server. When the amount of data increases, the only way to deal with it is to expand vertically by expanding the memory of the server, which is very costly.

[0067] Embodiment 1:

[0068] According to a first aspect of the present invention, the present invention discloses a distributed call bill batch pricing method based on an IGNITE memory database. Figure 1 FIG. 1 is a flow chart of a distributed call bill batch pricing method based on an IGNITE memory database according to an embodiment of the present invention. Figure 1 As shown, the method includes:

[0069] Step S1, receiving a data synchronization event that is timed or triggered by a condition, uploading the source table data of the data synchronization event to the data table of the Ignite memory database, and completing static data synchronization;

[0070] In step S1, a data synchronization event is received that is timed or triggered by a condition, and the source table data of the data synchronization event is uploaded to the data table of the Ignite in-memory database to complete static data synchronization.

[0071] In some embodiments, in step S1, Figure 2 As shown, the receiving of a data synchronization event that is timed or triggered by a condition, uploading the source table data of the data synchronization event to the data table of the Ignite memory database, and completing static data synchronization include:

[0072] Receive a data synchronization event that is scheduled or triggered by a condition, including the table name of the data synchronization event;

[0073] Exporting source table data of the data synchronization event;

[0074] Upload the source table data to the Ignite in-memory database;

[0075] Update the partition ID of the corresponding data table in the data partition table of the Ignite memory database;

[0076] Send data synchronization event messages to the Ignite data partition message queue.

[0077] Step S2: Monitor the database Binlog on the source database server and write the monitored changes to the data table of the corresponding Ignite memory database to complete dynamic data synchronization;

[0078] In step S2, the database Binlog is monitored on the source database server, and the monitored changes are written to the data table of the corresponding Ignite memory database to complete dynamic data synchronization.

[0079] In some embodiments, in step S2, Figure 3 As shown, the source database server monitors the database Binlog. If a SQL with a specific Hint is detected, the monitored changes are written to the data table of the corresponding Ignite memory database. The dynamic data synchronization is completed including:

[0080] Monitor the database Binlog on the source database server and send the monitored changes to the Ignite data partition message queue;

[0081] Receive the monitored change message from the Ignite data partition message queue, and write the change in the message to the data table of the corresponding Ignite in-memory database;

[0082] Write the monitored changes to the log for record keeping.

[0083] Step S3, regularly read the data partition table of the Ignite memory database, synchronize the data table of the data synchronization event and the partition ID of the monitored changed data table, and complete the call bill batch pricing;

[0084] In step S3, the data partition table of the Ignite memory database is read regularly, the data table of the data synchronization event and the partition ID of the data table of the monitored changes are synchronized, and the call bill batch pricing is completed.

[0085] In some embodiments, in step S3, Figure 4 As shown, the data partition table of the Ignite memory database is read regularly, the data table of the synchronization data synchronization event and the partition ID of the data table of the monitored changes are synchronized, and the batch price of the call list is completed, including:

[0086] Receive messages from the Ignite data partition message queue and store the partition ID of the data table in the local cache;

[0087] Apply business code to query the Ignite in-memory database, find the latest data partition based on the table name and partition ID of the data table, and use SQL to query the data;

[0088] Read the data partition table of the Ignite memory database regularly, synchronize the data table of data synchronization events and the partition ID of the data table of monitored changes.

[0089] Step S4: According to the primary key of the data table to be audited, read the data corresponding to the data in the table to be audited from the data table of the Ignite memory database, and compare each field to complete the data audit.

[0090] In step S4, according to the primary key of the data table to be audited, the data corresponding to the data in the table to be audited is read out from the data table of the Ignite memory database, and each field is compared to complete the data audit.

[0091] In some embodiments, in step S4, Figure 5 As shown, according to the primary key of the data table to be audited, the data corresponding to the data in the table to be audited is read out from the data table of the Ignite memory database, and each field is compared. The data audit is completed including:

[0092] Receive data audit events, including the table name of the data to be audited;

[0093] Batch read data from the audit data table;

[0094] According to the primary key of the data table to be audited, read the corresponding data from the Ignite data table and compare each field;

[0095] For different data, update operations are performed in the Ignite data table;

[0096] Update the data audit record and record the number of data that failed the comparison.

[0097] Embodiment 2:

[0098] The invention discloses a distributed call bill batch pricing system based on IGNITE memory database. Figure 6 FIG. 4 is a structural diagram of a distributed call bill batch pricing system based on an IGNITE memory database according to an embodiment of the present invention; Figure 6 As shown, the system 100 includes:

[0099] The first processing module 101, i.e., the static data synchronization system is configured to receive a data synchronization event that is timed or triggered by a condition, upload the source table data of the data synchronization event to the data table of the Ignite memory database, and complete the static data synchronization;

[0100] The second processing module 102, i.e., the dynamic data synchronization system is configured to monitor the database Binlog on the source database server, write the monitored changes into the data table of the corresponding Ignite memory database, and complete the dynamic data synchronization;

[0101] The third processing module 103, i.e., the bill batch pricing system is configured to periodically read the data partition table of the Ignite memory database, synchronize the data table of the data synchronization event and the partition ID of the monitored changed data table, and complete the bill batch pricing;

[0102] The fourth processing module 104, i.e., the data auditing system is configured to read out the data corresponding to the data in the table to be audited in the data table of the Ignite memory database according to the primary key of the table to be audited, and compare each field to complete the data audit.

[0103] According to the system of the second aspect of the present invention, the first processing module 101 is specifically configured as follows: Figure 2 As shown, the receiving of a data synchronization event that is timed or triggered by a condition, uploading the source table data of the data synchronization event to the data table of the Ignite memory database, and completing static data synchronization include:

[0104] Receive a data synchronization event that is scheduled or triggered by a condition, including the table name of the data synchronization event;

[0105] Exporting source table data of the data synchronization event;

[0106] Upload the source table data to the Ignite in-memory database;

[0107] Update the partition ID of the corresponding data table in the data partition table of the Ignite memory database;

[0108] Send data synchronization event messages to the Ignite data partition message queue.

[0109] According to the system of the second aspect of the present invention, the second processing module 102 is specifically configured as follows: Figure 3 As shown, the source database server monitors the database Binlog. If a SQL with a specific Hint is detected, the monitored changes are written to the data table of the corresponding Ignite memory database. The dynamic data synchronization is completed including:

[0110] Monitor the database Binlog on the source database server and send the monitored changes to the Ignite data partition message queue;

[0111] Receive the monitored change message from the Ignite data partition message queue, and write the change in the message to the data table of the corresponding Ignite in-memory database;

[0112] Write the monitored changes to the log for record keeping.

[0113] According to the system of the second aspect of the present invention, the third processing module 103 is specifically configured as follows: Figure 4 As shown, the data partition table of the Ignite memory database is read regularly, the data table of the synchronization data synchronization event and the partition ID of the data table of the monitored changes are synchronized, and the batch price of the call list is completed, including:

[0114] Receive messages from the Ignite data partition message queue and store the partition ID of the data table in the local cache;

[0115] Apply business code to query the Ignite in-memory database, find the latest data partition based on the table name and partition ID of the data table, and use SQL to query the data;

[0116] Read the data partition table of the Ignite memory database regularly, synchronize the data table of data synchronization events and the partition ID of the data table of monitored changes.

[0117] According to the system of the second aspect of the present invention, the fourth processing module 104 is specifically configured as follows: Figure 5 As shown, according to the primary key of the data table to be audited, the data corresponding to the data in the table to be audited is read out from the data table of the Ignite memory database, and each field is compared. The data audit is completed including:

[0118] Receive data audit events, including the table name of the data to be audited;

[0119] Batch read data from the audit data table;

[0120] According to the primary key of the data table to be audited, read the corresponding data from the Ignite data table and compare each field;

[0121] For different data, update operations are performed in the Ignite data table;

[0122] Update the data audit record and record the number of data that failed the comparison.

[0123] In summary, the solution proposed in the present invention can use a static data synchronization system to fully update a data table with a small amount of data, thereby ensuring data consistency.

[0124] For data tables with large amounts of data, a dynamic data synchronization system is used. This system synchronizes data by monitoring the source database Binlog to ensure real-time data. A data audit system is used to ensure data consistency in dynamic data tables.

[0125] The bill batch pricing system is connected to the Ignite distributed memory database and uses SQL for data query.

[0126] The communication between the client and server of Ignite memory database is carried out through TCP, which is not dependent on the system environment. When expanding the cluster, the single batch price cluster and the Ignite database cluster can be expanded separately, which can improve the speed and flexibility of cluster expansion. It solves the problem of slow expansion speed.

[0127] All servers in the call bill batch pricing cluster are connected to the same Ignite database cluster, and the data accessed by each call bill batch pricing process remains consistent. This solves the problem of inconsistent data among nodes in the call bill batch pricing cluster.

[0128] Ignite in-memory database cluster can distribute data to each server node. When the cluster capacity is insufficient, it can be expanded horizontally by adding server nodes, reducing the expansion cost. It solves the problem of only being able to expand vertically and the high expansion cost.

[0129] By storing different versions of table data in different data partitions, historical versions of data can be saved and customized data cleanup frequency can be supported.

[0130] Use the message queue function of the Ignite in-memory database to synchronize the latest table partition ID. This can avoid retrieving the latest table partition every time a business query is made, thus improving query efficiency.

[0131] Through the native persistence function of Ignite in-memory database, cold data can be written to disk and only hot data can be stored in memory. This can reduce the memory usage of the Ignite database cluster and reduce costs.

[0132] It should be noted that, for the method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the order of the actions described, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all optional embodiments, and the actions involved are not necessarily required by the present application.

[0133] As for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0134] Embodiment 3:

[0135] An embodiment of the present application also provides an electronic device, including: a processor, a memory, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, the various processes of the above-mentioned method embodiment are implemented, and the same technical effect can be achieved. To avoid repetition, it will not be described here.

[0136] FIG7 is a block diagram of an electronic device 800 shown in the present application. For example, the electronic device 800 may be a mobile phone, a computer, a digital broadcast terminal, a messaging device, a game console, a tablet device, a medical device, a fitness device, a personal digital assistant, etc.

[0137] Reference Figure 7 , the electronic device 800 may include one or more of the following components: a processing component 802 , a memory 804 , a power component 806 , a multimedia component 808 , an audio component 810 , an input / output (I / O) interface 812 , a sensor component 814 , and a communication component 816 .

[0138] The processing component 802 generally controls the overall operation of the electronic device 800, such as operations associated with display, phone calls, data communications, camera operations, and recording operations. The processing component 802 may include one or more processors 820 to execute instructions to complete all or part of the steps of the above method. In addition, the processing component 802 may include one or more modules to facilitate the interaction between the processing component 802 and other components. For example, the processing component 802 may include a multimedia module to facilitate the interaction between the multimedia component 808 and the processing component 802.

[0139] The memory 804 is configured to store various types of data to support operations on the device 800. Examples of such data include instructions for any application or method operating on the electronic device 800, contact data, phone book data, messages, images, videos, etc. The memory 804 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0140] The power supply component 806 provides power to the various components of the electronic device 800. The power supply component 806 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the electronic device 800.

[0141] The multimedia component 808 includes a screen that provides an output interface between the electronic device 800 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense the boundaries of the touch or slide action, but also detect the duration and pressure associated with the touch or slide operation. In some embodiments, the multimedia component 808 includes a front camera and / or a rear camera. When the device 800 is in an operating mode, such as a shooting mode or a video mode, the front camera and / or the rear camera may receive external multimedia data. Each front camera and the rear camera may be a fixed optical lens system or have a focal length and optical zoom capability.

[0142] The audio component 810 is configured to output and / or input audio signals. For example, the audio component 810 includes a microphone (MIC), and when the electronic device 800 is in an operating mode, such as a call mode, a recording mode, and a voice recognition mode, the microphone is configured to receive an external audio signal. The received audio signal can be further stored in the memory 804 or sent via the communication component 816. In some embodiments, the audio component 810 also includes a speaker for outputting audio signals.

[0143] I / O interface 812 provides an interface between processing component 802 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include but are not limited to: a home button, a volume button, a start button, and a lock button.

[0144] The sensor assembly 814 includes one or more sensors for providing various aspects of status assessment for the electronic device 800. For example, the sensor assembly 814 can detect the open / closed state of the device 800, the relative positioning of components, such as the display and keypad of the electronic device 800, and the sensor assembly 814 can also detect the position change of the electronic device 800 or a component of the electronic device 800, the presence or absence of contact between the user and the electronic device 800, the orientation or acceleration / deceleration of the electronic device 800, and the temperature change of the electronic device 800. The sensor assembly 814 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. The sensor assembly 814 may also include an optical sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor assembly 814 may also include an accelerometer, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

[0145] The communication component 816 is configured to facilitate wired or wireless communication between the electronic device 800 and other devices. The electronic device 800 can access a wireless network based on a communication standard, such as WiFi, a carrier network (such as 2G, 3G, 4G or 5G), or a combination thereof. In an exemplary embodiment, the communication component 816 receives a broadcast signal or broadcast operation information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 816 also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technologies.

[0146] In an exemplary embodiment, the electronic device 800 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the above methods.

[0147] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 804 including instructions, and the instructions can be executed by a processor 820 of an electronic device 800 to perform the above method. For example, the non-transitory computer-readable storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.

[0148] Embodiment 4:

[0149] The embodiment of the present application also provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, each process of the above method embodiment is implemented, and the same technical effect can be achieved. To avoid repetition, it is not repeated here. The computer-readable storage medium is, for example, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0150] Figure 8 19 is a block diagram of a computer-readable storage medium 1900 shown in the present application. For example, the computer-readable storage medium 1900 may be provided as a server.

[0151] Reference Figure 8 , the computer-readable storage medium 1900 includes a processing component 1922, which further includes one or more processors, and a memory resource represented by a memory 1932 for storing instructions, such as an application, that can be executed by the processing component 1922. The application stored in the memory 1932 may include one or more modules, each corresponding to a set of instructions. In addition, the processing component 1922 is configured to execute instructions to perform the above method.

[0152] The computer readable storage medium 1900 may also include a power supply component 1926 configured to perform power management of the computer readable storage medium 1900, a wired or wireless network interface 1950 configured to connect the computer readable storage medium 1900 to a network, and an input / output (I / O) interface 1958. The computer readable storage medium 1900 may operate based on an operating system stored in the memory 1932, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™ or the like.

[0153] It should be noted that, in this article, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or device including the element.

[0154] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, a magnetic disk, or an optical disk), and includes a number of instructions for a terminal (which can be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) to execute the methods described in each embodiment of the present application.

[0155] The embodiments of the present application are described above in conjunction with the accompanying drawings, but the present application is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of the present application, ordinary technicians in this field can also make many forms without departing from the purpose of the present application and the scope of protection of the claims, all of which are within the protection of the present application.

[0156] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed in the present application can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0157] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0158] In the embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0159] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0160] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0161] If the functions are implemented in the form of software functional units 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 a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as USB flash drives, mobile hard drives, ROM, RAM, magnetic disks, or optical disks.

[0162] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present 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. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A distributed call bill batch pricing method based on IGNITE memory database, characterized in that: include: Step S1, receiving a data synchronization event that is timed or triggered by a condition, uploading the source table data of the data synchronization event to the data table of the Ignite memory database, and completing static data synchronization; Step S2: Monitor the database Binlog on the source database server and write the monitored changes to the data table of the corresponding Ignite memory database to complete dynamic data synchronization; Step S3, regularly read the data partition table of the Ignite memory database, synchronize the data table of the data synchronization event and the partition ID of the monitored changed data table, and complete the call bill batch pricing; Step S4: According to the primary key of the data table to be audited, read the data corresponding to the data in the table to be audited from the data table of the Ignite memory database, and compare each field to complete the data audit.

2. The distributed call bill pricing method based on IGNITE memory database according to claim 1 is characterized in that: In step S1, receiving a data synchronization event that is timed or triggered by a condition, uploading the source table data of the data synchronization event to the data table of the Ignite memory database, and completing static data synchronization includes: Receive a data synchronization event that is scheduled or triggered by a condition, including the table name of the data synchronization event; Exporting source table data of the data synchronization event; Upload the source table data to the Ignite in-memory database; Update the partition ID of the corresponding data table in the data partition table of the Ignite memory database; Send data synchronization event messages to the Ignite data partition message queue.

3. The distributed call bill pricing method based on IGNITE memory database according to claim 1 is characterized in that: In step S2, the source database server monitors the database Binlog and writes the monitored changes into the data table of the corresponding Ignite memory database. The dynamic data synchronization is completed including: Monitor the database Binlog on the source database server and send the monitored changes to the Ignite data partition message queue; Receives monitored change messages from the Ignite data partition message queue, and writes the changes in the message to the data table of the corresponding Ignite in-memory database.

4. The distributed call bill pricing method based on IGNITE memory database according to claim 3 is characterized in that: In step S2, the method further includes: Write the monitored changes to the log for record keeping.

5. The distributed call bill pricing method based on IGNITE memory database according to claim 1 is characterized in that: In step S3, the data partition table of the Ignite memory database is read at a fixed time, the data table of the data synchronization event and the partition ID of the data table of the monitored change are synchronized, and the batch pricing of the call list is completed, including: Receive messages from the Ignite data partition message queue and store the partition ID of the data table in the local cache; Apply business code to query the Ignite in-memory database, find the latest data partition based on the table name and partition ID of the data table, and use SQL to query the data; Read the data partition table of the Ignite memory database regularly, synchronize the data table of data synchronization events and the partition ID of the data table of monitored changes.

6. The distributed call bill pricing method based on IGNITE memory database according to claim 5 is characterized in that: In step S4, according to the primary key of the data table to be audited, the data corresponding to the data in the table to be audited is read out from the data table of the Ignite memory database, and each field is compared. The data audit is completed including: Receive data audit events, including the table name of the data to be audited; Batch read data from the audit data table; According to the primary key of the data table to be audited, read the corresponding data from the Ignite data table and compare each field; To compare different data, perform update operations in the Ignite data table.

7. The distributed call bill pricing method based on IGNITE memory database according to claim 6 is characterized in that: In step S4, the method further includes: Update the data audit record and record the number of data that failed the comparison.

8. A distributed call bill batch pricing system based on IGNITE memory database, characterized in that: The system comprises: The first processing module, i.e., the static data synchronization system, is configured to receive a data synchronization event that is timed or triggered by a condition, and upload the source table data of the data synchronization event to the data table of the Ignite memory database to complete the static data synchronization; The second processing module, i.e., the dynamic data synchronization system, is configured to monitor the database Binlog on the source database server and write the monitored changes to the data table of the corresponding Ignite memory database to complete dynamic data synchronization; The third processing module, i.e., the bill batch pricing system, is configured to periodically read the data partition table of the Ignite memory database, synchronize the data table of the data synchronization event and the partition ID of the monitored changed data table, and complete the bill batch pricing; The fourth processing module, i.e., the data audit system is configured to read the data corresponding to the data in the table to be audited in the data table of the Ignite in-memory database according to the primary key of the table to be audited, and compare each field to complete the data audit.

9. An electronic device, characterized in that: The electronic device includes a memory and a processor, the memory stores a computer program, and when the processor executes the computer program, the steps in a distributed call bill batch pricing method based on an IGNITE memory database as described in any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by the processor, the steps in the distributed call bill batch pricing method based on the IGNITE memory database described in any one of claims 1 to 7 are implemented.

Images