Call bill processing method and device, equipment, storage medium and computer program product

Abstract

The invention discloses a call ticket processing method and device, equipment, a storage medium and a computer program product, and is applied to the field of business support. The method comprises the following steps: acquiring ticket data; performing pricing processing on the call ticket data based on the type of the call ticket data to obtain a pricing list file; performing accumulated account processing on the pricing list file to obtain an accumulated account file; under the condition that the number of the accumulated account files exceeds the capacity configuration number of the database, the accumulated account files are merged according to the capacity configuration number to generate accumulated account summary files, so that the number of the accumulated account summary files is smaller than or equal to the capacity configuration number, and the number of submitted pricing lists is controlled to be within the capacity range calculated by the database; writing data in the accumulated account summary file into an accumulated account table to complete accumulated accounts; the problem of table locking is avoided, and the account accumulation efficiency is improved.

Description

Technical Field

[0001] This application belongs to the field of business support, and in particular relates to a call detail record (CDR) processing method, apparatus, equipment, storage medium, and computer program product. Background Technology

[0002] When the settlement system engages in business transactions with settlement objects (such as ordering services), the settlement system needs to customize the settlement pricing for call details (CDRs) generated by different services. For example, it might calculate fees based on local or remote mobile phone calls with other mobile or landline phones, call duration during off-peak or peak hours, and a per-hour rate, and then negotiate the pricing with the settlement object—that is, settle accounts with the settlement object. After pricing, the corresponding data is written to the accounting table (i.e., accounting) according to the fields required by the business report (such as CDR type, service type, settlement object, etc.). The accounting process involves grouping data with the same fields from the pricing list files obtained after pricing. During accounting, aggregation fields, also known as grouping fields, are defined. When the grouping fields are the same, other fields (such as CDR count, call duration, etc.) of the same record in the accounting table are updated. However, when multiple pricing list files have the same grouping fields, simultaneously updating other fields of the same record in the accounting table can lead to table locking.

[0003] Existing technologies avoid table locking issues by using modulo grouping, but this method consumes a lot of storage space and table locking still exists as call detail records (CDRs) volume continues to grow, resulting in low efficiency in batch pricing and billing. Summary of the Invention

[0004] This application provides a method, apparatus, device, storage medium, and computer program product for call detail record (CDR) processing to solve the problem of low efficiency in batch pricing and billing due to table locking.

[0005] In a first aspect, embodiments of this application provide a call detail record (CDR) processing method, including: Obtain call detail record (CDR) data; Based on the type of call detail record (CDR) data, batch pricing is performed on the CDR data to obtain a batch pricing list file. The price list document is processed by cumulative accounting to obtain a cumulative accounting document; If the number of cumulative ledger files exceeds the database's capacity configuration limit, the cumulative ledger files are merged according to the capacity configuration limit to generate a cumulative ledger summary file, so that the number of cumulative ledger summary files is less than or equal to the capacity configuration limit. Write the data from the summary file into the summary table to complete the summary.

[0006] In one feasible approach of the first aspect, the call detail record (CDR) data is processed for batch pricing based on its type to obtain a batch pricing list file, including: Based on the type of call detail record (CDR) data, the corresponding process performs batch pricing on the CDR data to obtain a batch pricing list file. Batch pricing according to the type of CDR data enables the batch pricing node to process CDR data in parallel, improving the efficiency of CDR data processing and increasing throughput.

[0007] In one possible implementation of the first aspect, before performing batch pricing processing on the call detail record (CDR) data based on its type to obtain a batch pricing list file, the method further includes: Check whether the batch pricing node includes the process corresponding to the type of call detail record (CDR) data; If the batch pricing node does not include a process corresponding to the type of call detail record (CDR) data, then create a process corresponding to that type.

[0008] In one possible implementation of the first aspect, the method may further include: Get the memory resources occupied by the call detail record (CDR) data, and the memory resources occupied by the thread corresponding to the type of CDR data created; If the memory resources occupied by the call detail record (CDR) data and the memory resources occupied by the creation thread meet the resource usage information of the pricing node, a thread corresponding to the CDR data type is created. This thread then performs pricing processing on the CDR data to obtain the pricing list file. After obtaining the CDR data, it checks whether the pricing node includes a thread corresponding to the CDR data type, i.e., it determines whether the CDR data is a newly added type. If the CDR data is a newly added type, it checks whether the memory resources occupied by the CDR data and the memory resources occupied by the creation thread meet the resource usage information of the pricing node. If so, a thread corresponding to the CDR data type is created. This increases the number of threads for multi-threaded concurrent processing, improving pricing efficiency through parallel processing. Furthermore, creating threads based on the resource usage information of the pricing node maximizes the utilization of the pricing node's resources, improving its resource utilization rate.

[0009] Secondly, embodiments of this application provide a call detail record (CDR) processing apparatus, comprising: The acquisition unit is used to acquire call detail record (CDR) data. The batch pricing processing unit is used to perform batch pricing processing on call detail records (CDRs) based on their type, and to obtain a batch pricing list file. The accumulator unit is used to perform accumulator processing on the price list file to obtain the accumulator file. The merging unit is used to merge the cumulative ledger files according to the capacity configuration number when the number of cumulative ledger files exceeds the capacity configuration number of the database, so that the number of cumulative ledger summary files is less than or equal to the capacity configuration number. The write unit is used to write the data from the summary file into the summary table to complete the summary.

[0010] Thirdly, embodiments of this application provide a terminal device, which includes: a processor and a memory storing computer program instructions; the processor executes the computer program instructions to implement the call detail record (CDR) processing method as described in the first aspect.

[0011] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the call detail record (CDR) processing method as described in the first aspect.

[0012] Fifthly, embodiments of this application provide a computer program product in which instructions, when executed by a processor of an electronic device, cause the electronic device to perform the call detail record (CDR) processing method as described in the first aspect.

[0013] This application provides a method, apparatus, device, storage medium, and computer program product for call detail record (CDR) processing. The method involves acquiring CDR data; performing batch pricing processing on the CDR data based on its type to obtain a batch pricing list file; performing cumulative accounting processing on the batch pricing list file to obtain a cumulative accounting file; and, if the number of cumulative accounting files exceeds the database's capacity configuration, merging the cumulative accounting files according to the capacity configuration to generate a cumulative accounting summary file, ensuring that the number of cumulative accounting summary files is less than or equal to the capacity configuration, thereby controlling the number of submitted batch pricing lists within the database's computational capacity. Finally, the data in the cumulative accounting summary file is written into the cumulative accounting table to complete the accounting process. This avoids table locking issues and improves accounting efficiency. Attached Figure Description

[0014] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0015] Figure 1 This is a schematic diagram of a batch pricing and accounting process provided in an embodiment of this application; Figure 2 This is a schematic flowchart of a call detail record (CDR) processing method provided in an embodiment of this application; Figure 3 This is a schematic flowchart of a batch pricing and accounting method provided in an embodiment of this application; Figure 4 This is a schematic diagram illustrating a dynamic creation of a batch pricing thread provided in an embodiment of this application; Figure 5This is a schematic diagram illustrating the compilation and merging of quotation list documents provided in an embodiment of this application; Figure 6 This is a schematic diagram illustrating the writing of an accounting file to a database according to an embodiment of this application; Figure 7 This is a schematic diagram illustrating a cumulative file aggregation and merging process provided in an embodiment of this application; Figure 8 This is a schematic diagram of a call detail record (CDR) processing device provided in an embodiment of this application; Figure 9 This is a schematic diagram of the structure of a terminal device provided in an embodiment of this application. Detailed Implementation

[0016] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0017] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0018] To better understand the technical solution, we will first introduce the settlement system, batch pricing, cumulative accounting, table locking, and modulo grouping method of this application.

[0019] The settlement system primarily handles settlements for intra-network, inter-network, and intra-provincial personalized services. Intra-network settlements cover all business settlements with provincial companies and specialized companies nationwide. Inter-network settlements include voice, data, and SMS / MMS service settlements with China Telecom, China Unicom, and China Broadcasting Network. Intra-provincial personalized service settlements flexibly support changes in intra-provincial business, involving traditional mobile internet providers, system integrators (SIs), service providers (SPs), and content providers (CPs).

[0020] This means that when conducting business transactions with other operators, service providers, content providers, etc., such as voice calls, SMS / MMS, data traffic, subscriptions, etc., the settlement system (such as the NGBOSS system) needs to perform customized settlement pricing for the call detail records (CDRs) generated by different services. For example, for calls between local or remote mobile and landline numbers in the CDR, the call detail record price is calculated based on the call duration during off-peak or peak hours, and the resulting pricing is settled with other operators. Alternatively, for product subscriptions on a monthly basis, the CDR subscription amount is allocated according to a revenue sharing ratio, and the amount is distributed among the mobile operator and the cooperating provider, which is the pricing.

[0021] After pricing is approved, key data required by downstream business reports, such as call detail record (CDR) type, service type, settlement object, number of CDRs, call duration, and settlement amount, are written to the cumulative ledger table. The cumulative ledger table is defined as aggregated fields such as the cumulative number of CDRs, call duration, and settlement amount when key data is identical. During this process, CDR type, service type, and settlement object are used as grouping fields. When grouping fields are identical, the number of CDRs, call duration, and settlement amount for the same record in the cumulative ledger table are updated. If multiple committed transactions use the same grouping fields and simultaneously update the same record in the cumulative ledger table, a table lock situation may occur.

[0022] For example, there is already a continuous monthly call detail record in the cumulative billing table. The service type is A, the enterprise code is 1001, the mobile revenue share ratio is 0.6, and the partner revenue share ratio is 0.4, as shown in Table 1.

[0023] Table 1 Number 1 and number 2 both renewed their subscriptions to service A through 1001, generating two call detail records (CDRs) for this service. Since the settlement and accounting process does not require number details, after the pricing is approved, the CDR type, service type, enterprise code, mobile revenue sharing ratio, partner revenue sharing ratio, amount, mobile revenue sharing amount, and partner revenue sharing amount are written to the accounting table. When writing to the accounting table, it is discovered that the dimension "CDR type, service type, enterprise code, mobile revenue sharing ratio, and partner revenue sharing ratio" already has a record. The two CDRs simultaneously update the amount, mobile revenue sharing amount, and partner revenue sharing amount of the same database table record, resulting in a table lock.

[0024] To address this issue, the current technical solution involves adding a modulo grouping field to the cumulative ledger table. The modulo grouping method uses the file sequence number; for example, taking the modulo of 30 involves dividing the file sequence number by 30 and performing a remainder operation, writing the remainder to the cumulative ledger table. This way, file 1 has a modulo value of 1, file 2 has a modulo value of 2, resulting in two separate records, and updates to the aggregation field do not conflict. However, using the modulo grouping method consumes a significant amount of storage space; for example, taking the modulo of 30 would increase the number of records by 30 times. Although this method consumes a lot of storage space, it can avoid table locking and improve the efficiency of cumulative ledger processing when the data volume is small.

[0025] As business continues to grow and call detail records (CDRs) volume increases, table locking issues may still occur. For example, when processing files with sequence numbers 1, 31, and 61 simultaneously, the modulo operation result in a value of 1 for all of them. These files contain a large number of CDR records that have been settled and approved with enterprise code 1001. When the approved records are written to the database table, they will all update the same record, which will also cause table locking issues, affecting the efficiency of billing and consequently the efficiency of overall settlement.

[0026] Based on this, embodiments of this application provide a call detail record (CDR) processing method, including an apparatus, device, storage medium, and computer program product. The method involves acquiring CDR data; performing batch pricing processing on the CDR data based on its type to obtain a batch pricing list file; performing cumulative accounting processing on the batch pricing list file to obtain a cumulative accounting file; and, if the number of cumulative accounting files exceeds the database's capacity configuration limit, merging the cumulative accounting files according to the capacity configuration limit to generate a cumulative accounting summary file, ensuring that the number of cumulative accounting summary files is less than or equal to the capacity configuration limit, thereby controlling the number of submitted batch pricing lists within the database's computational capacity. Finally, the data in the cumulative accounting summary file is written into the cumulative accounting table to complete the cumulative accounting process. This avoids table locking issues and improves cumulative accounting efficiency.

[0027] The call detail record (CDR) processing method provided in this application is applied to a settlement system, which can be a distributed settlement system. The distributed settlement system includes multiple pricing nodes, and each pricing node is used for multi-process CDR pricing accumulation to improve pricing accumulation efficiency.

[0028] The cumulative pricing record for each pricing node's dialog file is as follows: Figure 1 As shown, after receiving the call detail record (CDR) file, the pricing node processes the CDR file according to the process corresponding to its type, resulting in a pricing list file, also known as a list file. The type can include, for example, CDR type, service type, or settlement object.

[0029] Because the pricing process is performed based on type-based dialog box files, the pricing results for the same type (e.g., settlement object) will be distributed across various list files after the pricing process. If the pricing results from the list files are directly accumulated, table locking will inevitably occur. Therefore, the list files are accumulated and summarized by aggregating and merging records with identical grouping fields, such as dialog box type, business type, and settlement object. Records with identical grouping fields such as cumulative amount and duration are also aggregated to obtain an accumulated file. The accumulated file is then written to the accumulated table in the database, avoiding table locking and improving the efficiency of the accumulated process.

[0030] The call detail record (CDR) processing method provided in this application is described in detail below. Figure 2 As shown, the call detail record (CDR) processing method includes S110 to S140.

[0031] S110, retrieve call detail records (CDRs).

[0032] Call detail record (CDR) data refers to the CDR file described above. CDR data can include the type of CDR data, which can include CDR type, service type, and settlement object, among other things.

[0033] Call detail records (CDRs) can be categorized into several types, including inter-network voice calls, inter-network SMS / MMS calls, roaming voice calls, roaming data calls, one-time subscription CDRs with service providers, and continuous monthly subscription CDRs. For example, continuous monthly subscription CDRs may include services such as Migu Music, IPTV value-added services, and mobile reading. Settlement parties can include telecom operators, service providers, and content providers.

[0034] S120 performs batch pricing processing on the call detail record (CDR) data based on its type to obtain a batch pricing list file.

[0035] like Figure 1 As shown, after obtaining the call detail record (CDR) file, the CDR file is processed for batch pricing according to its type. In one embodiment, each batch process corresponds to one type, and each batch process can handle one dimension of CDR services, as shown in Table 2. In Table 2, the batch pricing process is created according to modules, CDR types, service types, stage objects, etc.

[0036] In one embodiment, each batch process may include multiple threads to process one type of call detail record (CDR) data in parallel to improve the efficiency of batch processing.

[0037] Table 2 In one embodiment, such as Figure 3 As shown, before detecting the type of call detail record (CDR) data and performing batch pricing processing on the CDR data to obtain the batch pricing list file, the method further includes: S160, Detect whether the batch pricing node includes the process corresponding to the type of the call detail record data.

[0038] S170: If the pricing node does not include a process corresponding to the type of call detail record (CDR) data, create a process corresponding to the type, and process the CDR data through the process to obtain the pricing list file.

[0039] After acquiring call detail record (CDR) data, the batching node checks whether it includes a thread corresponding to the CDR data type. This determines whether the CDR data is of a newly added type (e.g., a new CDR type or a new service type). If the CDR data is of a newly added type, a process corresponding to that type is created. By automatically monitoring the CDR data type and dynamically adding processes when the CDR data is of a newly added type, the efficiency of batching processing is improved by processing multiple types of CDR data in parallel.

[0040] exist Figure 2 and / or Figure 3 Based on the illustrated embodiments, in one embodiment, the method may further include S180 and S190.

[0041] S180, obtain the memory resources occupied by the call detail record (CDR) data, and the memory resources occupied by the thread corresponding to the type of CDR data creation.

[0042] The memory resources occupied by call detail record (CDR) data are the size of the CDR data itself.

[0043] In one embodiment, the settlement and pricing application retrieves the resource usage information of the pricing nodes from a Redis cache. This resource usage information in the Redis cache is monitored and stored in real-time by a pricing resource monitoring system. Figure 4 As shown. In Figure 4 In the process, the pricing resource monitoring obtains the resource usage information of each process machine (i.e., the pricing node) in real time. The resource usage information can include the memory usage of the pricing node, the resource usage of the central processing unit, system time, and other information.

[0044] S190: If the memory resources occupied by the call detail record (CDR) data and the memory resources occupied by the creation thread meet the resource usage information of the pricing node, a thread corresponding to the type of CDR data is created, and the CDR data is processed through the thread to obtain the pricing list file.

[0045] By determining whether the memory resources occupied by the call detail record (CDR) data and the memory resources occupied by the creation thread meet the resource usage information of the pricing node, and if so, creating the thread corresponding to the type of CDR data, the number of threads for multi-threaded concurrent processing is increased, thereby improving the efficiency of pricing. At the same time, creating threads based on the resource usage information of the pricing node can maximize the utilization of the pricing node's resources, thus improving the resource utilization rate of the pricing node.

[0046] In one embodiment, the resource usage information of the batching node includes memory usage and CPU resource utilization. The specific process for determining whether the memory resources occupied by call detail record (CDR) data and the memory resources occupied by the creation thread meet the resource usage information of the batching node is as follows: Determine whether the sum of the memory resources occupied by CDR data and the memory resources occupied by the creation thread is less than the total memory usage, and whether the CPU resource utilization is less than a preset threshold; if the sum of the memory resources occupied by CDR data and the memory resources occupied by the creation thread is less than the total memory usage, and the CPU resource utilization is less than the preset threshold, then determine that the memory resources occupied by CDR data and the memory resources occupied by the creation thread meet the resource usage information of the batching node.

[0047] In this embodiment, the total memory resources occupied by call detail record (CDR) data and the memory resources occupied by thread creation are compared with the total memory usage. If the total resource usage is less than the total memory usage (e.g., 95% memory utilization), it indicates that there is still storage space available, and more data can be stored. If the CPU's resource utilization is less than a preset threshold (e.g., 90% resource utilization), it indicates that the CPU can handle more computation, and more threads can be created to process more computations. If the CPU's resource utilization is greater than the preset threshold, it indicates that the CPU load is already high, and adding more threads to process CDR data would affect processing speed. In one embodiment, the creation of batch pricing threads can be executed multiple times to bring the batch pricing node to its maximum load threshold, maximizing the utilization of the batch pricing node's resources and improving its resource utilization rate. Simultaneously creating more batch pricing threads to perform batch pricing processing in parallel improves the efficiency of batch pricing processing.

[0048] In one example, if the billing node is a C11 model machine with 384GB of memory, billing a single call detail record (CDR) file for inter-network voice communication consumes approximately 3MB of memory.

[0049] Machine memory size (MB) = 384 * 1024 = 393216MB 95% of the machine's memory size = 393216MB * 0.95 = 373555.2MB Monitor the memory and CPU consumption of the pricing machine, and record the monitoring results in a Redis cache for quick real-time retrieval during pricing. If the current memory usage is 373550.2MB, plus the memory consumption of call detail records (CDRs) of 3MB, which is less than 373555.2MB, and the CPU load is less than 90%, then create a batch pricing thread.

[0050] If a roaming traffic bill is processed at this time, it will consume about 7MB of memory. Since 373553.2MB plus 7MB is greater than 95% of the total memory resources (373555.2MB), the billing process will not continue to create threads.

[0051] It should be noted that the machine memory size is configured in the shared file system configuration file, and the batch pricing process reads from the configuration file, which can flexibly adapt to various machine models in the batch pricing cluster.

[0052] S130, perform cumulative processing on the price list file to obtain the cumulative file.

[0053] After obtaining the price list file, merge the identical records in the same grouping field in the price list file, as described above, to obtain the cumulative ledger file.

[0054] In one embodiment, after processing call detail record (CDR) data through various types of processes and threads to obtain batch CDR files, information such as the CDR file name, thread number, process number, and CDR file type (e.g., CDR type, service type, settlement object) can be recorded in the Redis cache.

[0055] Because the pricing process is performed according to the type of dialog box file, the pricing results for the same type (such as settlement object) will be distributed across various pricing list files after the pricing process. If the pricing results from the pricing list files are directly accumulated, table locking will inevitably occur. Therefore, the pricing list files are accumulated and summarized by aggregating and merging records with the same grouping fields, such as dialog box type, business type, and settlement object. Records with the same grouping fields are also aggregated, along with aggregated fields such as cumulative amount and duration, to obtain an accumulated file. The accumulated file is then written to the accumulated table in the database, avoiding table locking and improving the efficiency of the accumulated process.

[0056] In one embodiment, the accumulator application reads the process ID, thread ID, and manifest file name from the Redis cache, and creates multiple accumulator processes (e.g., based on the batch process ID) at the batch process ID level. Figure 1As shown), each accumulator process periodically processes the batch price list file corresponding to the batch price process number, and accumulates and summarizes the batch price results of multiple batch price list files to obtain an accumulator file, such as... Figure 5 As shown.

[0057] S140: If the number of cumulative ledger files exceeds the capacity configuration limit of the database, the cumulative ledger files are merged according to the capacity configuration limit to generate a cumulative ledger summary file, so that the number of cumulative ledger summary files is less than or equal to the capacity configuration limit.

[0058] Normally, after generating the cumulative accounting file, it can be committed to the database and written to the database tables. During peak business periods, the more settlement call details are generated, the more cumulative accounting files will be generated for the same business. When the database's computing power is insufficient to support the continuous connection to the database and the submission of transactions to write data for a large number of cumulative accounting files for the same business, a bottleneck in cumulative accounting efficiency will be encountered. Figure 6 As shown. In Figure 6 In the process of writing the ledger file 1 to the database table, a ledger file 2 with the same business logic as ledger file 1 is received. At this time, the database's computing power may be insufficient to support the writing of ledger file 2 with the same business logic as ledger file 1.

[0059] In this scenario, the database capacity configuration quantity can be obtained from the database capacity configuration. This quantity can be configured according to the call detail record (CDR) service type, the number of file records, and the number of database nodes. The database capacity configuration quantity represents the database's computing power. A batch accumulation algorithm is used to determine if the number of accumulated files exceeds the database capacity configuration quantity. If so, the accumulated files are merged according to the capacity configuration quantity to generate an accumulated summary file. Figure 7 As shown.

[0060] In one embodiment, multiple summary files can be merged to obtain a summary file.

[0061] In one example, call detail record (CDR) service A is stored in the database computing node 1. The accumulating process processes the accumulating files for this service in real time. The current accumulating file contains 400,000 records, and the computing capacity (TPS) of node 1 is 50,000 transactions per second. First, the N accumulating files are aggregated and merged to reduce the number of records. If the number of records after aggregation and merging is 200,000, then the files are split into 4 files based on the TPS and submitted to the data table in batches.

[0062] S150: Write the data from the summary file into the summary table to complete the summary.

[0063] Finally, the data from the summary file is written into the database table, namely the summary table, to complete the summary process.

[0064] This application provides a method for call detail record (CDR) processing, which involves acquiring CDR data; performing batch pricing processing on the CDR data based on its type to obtain a batch pricing list file; performing cumulative accounting processing on the batch pricing list file to obtain a cumulative accounting file; and, if the number of cumulative accounting files exceeds the database's capacity configuration limit, merging the cumulative accounting files according to the capacity configuration limit to generate a cumulative accounting summary file, ensuring that the number of cumulative accounting summary files is less than or equal to the capacity configuration limit, thereby controlling the number of submitted batch pricing lists within the database's computing capacity. The data in the cumulative accounting summary file is then written into the cumulative accounting table to complete the cumulative accounting process. This avoids table locking issues and improves cumulative accounting efficiency.

[0065] Based on the same inventive concept, embodiments of this application also provide a call detail record (CDR) processing apparatus, such as... Figure 8 As shown, the device may include: Acquisition unit 210 is used to acquire call detail record (CDR) data; The pricing processing unit 220 is used to perform pricing processing on the call detail record (CDR) data based on the type of the CDR data to obtain a pricing list file; The accumulator unit 230 is used to perform accumulator processing on the batch price list file to obtain an accumulator file; The merging unit is used to merge the accumulated files according to the capacity configuration number to generate an accumulated summary file when the number of accumulated files exceeds the capacity configuration number of the database, so that the number of accumulated summary files is less than or equal to the capacity configuration number. The writing unit 240 is used to write the data in the cumulative summary file into the cumulative table to complete the cumulative accounting.

[0066] In one embodiment, the pricing processing unit 220 is specifically used to perform pricing processing on the call detail record (CDR) data based on the process corresponding to the type of the CDR data, and obtain a pricing list file.

[0067] In one embodiment, the device may further include a detection unit and a creation unit.

[0068] The detection unit is used to detect whether the batch pricing node includes the process corresponding to the type of the call detail record data; A creation unit is used to create a process corresponding to the type of call detail record data when the batch pricing node does not include a process corresponding to the type of call detail record data.

[0069] In one embodiment, the pricing node is any one of the pricing nodes in the distributed settlement system.

[0070] In one embodiment, the acquisition unit 210 is further configured to acquire the memory resources occupied by the call detail record data and the memory resources occupied by the thread that creates the call detail record data type. The creation unit is further configured to create a thread corresponding to the type of the call detail record (CDR) data, provided that the memory resources occupied by the CDR data and the memory resources occupied by the creation thread meet the resource usage information of the pricing node. This thread is used by the pricing processing unit to perform pricing processing on the CDR data and obtain a pricing list file.

[0071] In one embodiment, the acquisition unit 210 is further configured to acquire resource usage information of the batch node from the Redis cache, wherein the resource usage information of the batch node in the Redis cache is monitored and stored in real time through batch resource monitoring, and the resource usage information may include information such as the memory usage of the batch node, the resource usage information of the central processing unit, and the system time.

[0072] In one embodiment, the resource usage information of the batch node includes memory usage and central processing unit resource utilization. The apparatus may further include a judgment unit and a determination unit.

[0073] The judgment unit is used to determine whether the total memory resources occupied by the call detail record data and the memory resources occupied by the creation thread are less than the memory usage resources, and whether the resource utilization rate of the central processing unit is less than a preset threshold. The determining unit is configured to determine the memory resources occupied by the call detail record (CDR) data and the memory resources occupied by the creation thread when the sum of the memory resources occupied by the CDR data and the memory resources occupied by the creation thread is less than the total memory resources used, and the resource utilization rate of the central processing unit is less than a preset threshold, thereby satisfying the resource usage information of the batch pricing node.

[0074] In one embodiment, the acquisition unit 210 is also used to acquire the number of database capability configurations through the accounting application.

[0075] Figure 8 The various modules in the device shown can achieve Figure 2 and Figure 3 The various steps involved, and the corresponding technical effects achieved, will not be elaborated upon here for the sake of brevity.

[0076] Figure 9 A schematic diagram of the hardware structure of the terminal device provided in an embodiment of this application is shown.

[0077] The terminal device may include a processor 301 and a memory 302 storing computer program instructions.

[0078] Specifically, the processor 301 may include a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0079] Memory 302 may include mass storage for data or instructions. For example, and not limitingly, memory 302 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. In one instance, memory 302 may include removable or non-removable (or fixed) media, or memory 302 may be non-volatile solid-state memory. Memory 302 may be internal or external to the integrated gateway disaster recovery device.

[0080] In one example, memory 302 may include read-only memory (ROM), random access memory (RAM), disk storage media device, optical storage media device, flash memory device, electrical, optical, or other physical / tangible memory storage device. Thus, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method for testing communication network failures according to this disclosure.

[0081] The processor 301 reads and executes computer program instructions stored in the memory 302 to achieve... Figure 2 and Figure 3 The method for processing call details in the illustrated embodiment.

[0082] In one example, the terminal device may also include a communication interface 303 and a bus 304. Wherein, for example... Figure 9 As shown, the processor 301, memory 302, and communication interface 303 are connected through bus 304 and complete communication with each other.

[0083] The communication interface 303 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0084] Bus 304 includes hardware, software, or both, that couples components of an end device together. For example, and not as a limitation, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 304 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0085] Furthermore, in conjunction with the communication network fault testing method in the above embodiments, this application embodiment can provide a computer storage medium for implementation. The computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the call detail record (CDR) processing methods in the above embodiments.

[0086] This application also provides a computer program product, including a computer program, which, when executed, implements any of the call detail record (CDR) processing methods described in the above embodiments.

[0087] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0088] The functional blocks shown in the above block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or text segments used to perform the required tasks. Programs or text segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, read-only memory (ROM), flash memory, erasable read-only memory (EROM), floppy disks, compact disc read-only memory (CD-ROM), optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Text segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0089] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0090] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0091] The above are merely specific embodiments of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A method for processing call detail records (CDRs), characterized in that, include: Obtain call detail record (CDR) data; Based on the type of the call detail record (CDR) data, the CDR data is processed for batch pricing to obtain a batch pricing list file. The batch price list file is processed to obtain an inventory file; If the number of accumulated files exceeds the database's capacity configuration limit, the accumulated files are merged according to the capacity configuration limit to generate an accumulated summary file, so that the number of accumulated summary files is less than or equal to the capacity configuration limit. Write the data from the summary file into the summary table to complete the summary.

2. The method according to claim 1, characterized in that, The process of processing call detail records (CDRs) based on their type to obtain a pricing list file includes: Based on the type of the call detail record (CDR) data, the corresponding process performs batch pricing processing on the CDR data to obtain a batch pricing list file.

3. The method according to claim 2, characterized in that, Before performing batch pricing processing on the call detail record (CDR) data based on its type to obtain a batch pricing list file, the method further includes: Detect whether the batch pricing node includes the process corresponding to the type of the call detail record data; If the batch pricing node does not include a process corresponding to the type of call detail record (CDR) data, then create a process corresponding to that type.

4. The method according to claim 3, characterized in that, The pricing node is any one of the pricing nodes in the distributed settlement system.

5. The method according to any one of claims 1 to 4, characterized in that, Also includes: Obtain the memory resources occupied by the call detail record (CDR) data, and the memory resources occupied by the thread corresponding to the type of the CDR data created; If the memory resources occupied by the call detail record (CDR) data and the memory resources occupied by the creation thread meet the resource usage information of the pricing node, a thread corresponding to the type of the CDR data is created, and the CDR data is processed for pricing through the thread to obtain a pricing list file.

6. The method according to claim 5, characterized in that, Before creating a thread corresponding to the type of call detail record (CDR) data, provided that the memory resources occupied by the CDR data and the memory resources occupied by the creation thread meet the resource usage information of the batch pricing node, the method includes: Resource usage information of batch nodes is obtained from the Redis cache, wherein the resource usage information of batch nodes in the Redis cache is monitored and stored in real time through batch resource monitoring.

7. The method according to claim 5, characterized in that, The resource usage information of the pricing node includes memory usage and CPU resource utilization. Before the thread corresponding to the type of the call detail record data is created, the method includes: Determine whether the total memory resources occupied by the call detail record data and the memory resources occupied by the creation thread are less than the total memory usage, and whether the resource utilization rate of the central processing unit is less than a preset threshold; If the total memory resources occupied by the call detail record (CDR) data and the memory resources occupied by the creation thread are less than the total memory resources used, and the resource utilization rate of the central processing unit is less than a preset threshold, then the memory resources occupied by the CDR data and the memory resources occupied by the creation thread are determined to meet the resource usage information of the batch pricing node.

8. The method according to any one of claims 1 to 4, characterized in that, If the number of accumulated ledger files exceeds the database's capacity configuration limit, before merging the accumulated ledger files according to the capacity configuration limit to generate an accumulated ledger summary file, the method further includes: The database capability configuration quantity is obtained through the accounting application.

9. A call detail record (CDR) processing apparatus, characterized in that, include: The acquisition unit is used to acquire call detail record (CDR) data. The pricing processing unit is used to perform pricing processing on the call detail record (CDR) data based on the type of the CDR data to obtain a pricing list file. The accumulator unit is used to perform accumulator processing on the batch price list file to obtain an accumulator file; The merging unit is used to merge the accumulated files according to the capacity configuration number to generate an accumulated summary file when the number of accumulated files exceeds the capacity configuration number of the database, so that the number of accumulated summary files is less than or equal to the capacity configuration number. The writing unit is used to write the data from the cumulative summary file into the cumulative table to complete the cumulative accounting.

10. A terminal device, characterized in that, The terminal device includes: a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, it implements the call detail record (CDR) processing method as described in any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions, which, when executed by a processor, implement the call detail record (CDR) processing method as described in any one of claims 1-8.

12. A computer program product, characterized in that, When the instructions in the computer program product are executed by the processor of the electronic device, the electronic device performs the call detail record (CDR) processing method as described in any one of claims 1-8.

Images