Call detail charging system, method, device and storage medium

Abstract

The application discloses a call bill charging system, method, equipment and storage medium. The charging system comprises a preprocessing module configured to acquire a call bill file; and a charging module comprising a charging master and a charging service. The charging master is a service consumer of an open source distributed service framework Dubbo, and the charging service is a service provider of the Dubbo. The charging master is configured to receive a charging quotation request about the call bill file, and the charging service is configured to respond to the charging quotation request and charge the call bill file. According to the call bill charging system, method, equipment and storage medium provided by the embodiment of the application, the call bill charging efficiency can be improved, and the charging delay problem can be improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of communication, in particular to a call bill charging system, method, device, equipment and storage medium. BACKGROUND

[0002] With the rapid development of international roaming business and 5G technology, the call bill charging scene is becoming more and more complex.

[0003] In the related art, the international gateway station can collect the international roaming bill file and send it to the clearing center, and the clearing center can perform charging and other processes on the international roaming bill. The inventor found that in the related art of call bill charging, each module directly interfaces through a database table to realize serial processing of the bill file in each module, and the processed bill information is usually stored in a relational database. There is a strong dependency between modules, and any abnormal module can cause delay in bill file charging and settlement.

[0004] In addition, the amount of international roaming business is increasing day by day, and the amount of bill processing needs to reach billions per day. During the peak period of business, bill processing and charging may be delayed, and file processing and charging delay will affect user experience, resulting in delay in international roaming user side voice and traffic deduction. SUMMARY

[0005] In order to solve the above technical problems or at least partially solve the above technical problems, the embodiments of the present application provide a call bill charging system, method, device, equipment and storage medium, which is beneficial to improve the efficiency of call bill charging and improve the problem of charging delay.

[0006] In a first aspect, the embodiments of the present application provide a call bill charging system, which comprises: a preprocessing module configured to obtain a bill file; a charging module, the charging module comprising a charging master and a charging service, the charging master being a service consumer of an open distributed service framework Dubbo, and the charging service being a service provider of Dubbo, the charging master being configured to receive a charging quotation request about the bill file, and the charging service being configured to respond to the charging quotation request and charge the bill file.

[0007] In a possible implementation manner of the first aspect, the system further comprises a Redis cluster of remote dictionary service, the Redis cluster being configured to receive the processed bill file sent by the preprocessing module and receive information of the charged bill file sent by the charging service;

[0008] The preprocessing module is specifically configured to: obtain the bill file, sequentially perform decoding verification, duplicate checking and bill sorting processing on the bill file, and write the processed bill file into the Redis cluster;

[0009] The charging service is specifically used for: in response to a charging pricing request, charging a processed bill file, feeding back information of the charged bill file to a Redis cluster, and feeding back a charging state to a charging master.

[0010] In a possible implementation of the first aspect, the system further includes a memory database, the memory database being configured to store charging states of a plurality of small files and charging processing configuration information, the small files being obtained by dividing the bill file according to a home location, and each small file including bill information of the home location to which the small file belongs.

[0011] In a possible implementation of the first aspect, the system further includes an autonomously controllable distributed database and a result processing module.

[0012] The autonomously controllable distributed database is configured to store and count intermediate data and result data in the bill file charging process.

[0013] The result processing module is configured to perform result processing according to the charged bill information and data of the autonomously controllable distributed database, the result processing including at least one of the following: result publishing, file issuing, and settlement counting.

[0014] Based on the same inventive concept, the embodiments of the present application further provide a bill charging method, the method including:

[0015] obtaining a bill file;

[0016] Based on an open source distributed service framework Dubbo, taking the charging master as a service consumer of Dubbo, the charging master receives a charging pricing request about the bill file;

[0017] taking the charging service as a service provider of Dubbo, the charging service charges the bill file in response to the charging pricing request.

[0018] In a possible implementation of the second aspect, the step of receiving, by the charging master, the charging pricing request about the bill file specifically includes:

[0019] The charging master receives the charging pricing request about the bill file from a charging file processing state table and / or a message queue, and dispatches the charging master; the charging file processing state table includes a processing state of the bill file.

[0020] The step of charging, by the charging service, the bill file in response to the charging pricing request specifically includes:

[0021] The charging service determines a charging standard corresponding to the bill file in response to the charging pricing request, and charges the bill file according to the charging standard.

[0022] In a possible implementation of the second aspect, after the call detail record file is acquired, the method further comprises:

[0023] The call detail record file is divided into a plurality of small files according to the home location, and each small file comprises call detail record information of the home location to which the small file belongs;

[0024] The step that the charging master receives the charging pricing request about the call detail record file specifically comprises:

[0025] The charging master receives the charging pricing request about the small file;

[0026] The step that the call detail record file is charged specifically comprises:

[0027] The call detail records of the plurality of small files are charged in parallel.

[0028] In a possible implementation of the second aspect, the step that the call detail records of the plurality of small files are charged in parallel specifically comprises:

[0029] The number of call detail record items of each user in the small file is determined;

[0030] The plurality of small files are evenly divided into a plurality of threads according to the number of call detail record items of each user, wherein the call detail record files to be charged of the same user are allocated into the same thread;

[0031] The plurality of threads are charged in parallel.

[0032] In a possible implementation of the second aspect, after the call detail record file is charged, the method further comprises:

[0033] Information of the call detail record file after charging is stored into a Redis cluster;

[0034] Information of the call detail record file after charging stored in the Redis cluster is synchronized

[0035] To a corresponding directory of a Hbase database and a distributed file system HDFS;

[0036] Intermediate data and result data of charging are stored and counted by using an autonomous and controllable distributed database, and source files are stored into a corresponding directory of the HDFS;

[0037] Data in the HDFS is mapped to a HIVE cluster;

[0038] According to data of the autonomous and controllable distributed database and the HIVE cluster, settlement statistics and file distribution are performed.

[0039] In a possible implementation of the second aspect, storing the call detail record information after charging into a corresponding directory of a Hbase database and a distributed file system HDFS comprises:

[0040] Write the billing after the bill information into the open source stream processing platform Kafka distributed message queue;

[0041] Synchronize the Kafka distributed message queue to the Hbase database through the computing engine Spark streaming;

[0042] Insert the Kafka distributed message queue into the Kafka corresponding distributed search engine ElasticSearch using the Hbase database, and store the Kafka distributed message queue to the corresponding directory of HDFS.

[0043] In a possible implementation of the second aspect, the bill file is billed, including:

[0044] Bill the bill file according to the tariff syntax tree.

[0045] Based on the same inventive concept, in a third aspect, the embodiments of the present application also provide an electronic device, characterized in that the device comprises a processor and a memory storing computer program instructions;

[0046] The processor executes the computer program instructions to realize the bill billing method as described in any one of the embodiments of the first aspect.

[0047] Based on the same inventive concept, in a fourth aspect, the embodiments of the present application also provide a computer readable storage medium, characterized in that the computer readable storage medium stores computer program instructions, and the computer program instructions are executed by the processor to realize the bill billing method as described in any one of the embodiments of the first aspect.

[0048] According to the bill billing system, method, device and storage medium provided by the embodiments of the present application, a set of distributed service scheduling architecture based on Dubbo is built, Dubbo is used for distributed scheduling in billing, Dubbo is structured in a layered manner, and using this manner can decouple between layers, that is, each module in the system is relatively independent, and can provide a high-performance bill billing mode to meet the requirement of fast billing, which is beneficial to improve the bill billing efficiency and improve the billing delay problem. In addition, the load balancing strategy of extending Dubbo can be supported to realize the load balancing of billing service, improve the billing efficiency, and at the same time can be dynamically expanded, has good scalability, and meets the business growth and peak processing requirements. BRIEF DESCRIPTION OF DRAWINGS

[0049] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiments of the present application. For those skilled in the art, other drawings can also be obtained without creative labor on the basis of these drawings.

[0050] Figure 1 is a structural schematic diagram of a bill charging system provided by an embodiment of the present application;

[0051] Figure 2 is a flow schematic diagram of a bill charging method provided by an embodiment of the present application;

[0052] Figure 3 is a structural schematic diagram of an open source distributed service framework for bill charging provided by an embodiment of the present application;

[0053] Figure 4 is a flow schematic diagram of a bill charging method provided by another embodiment of the present application;

[0054] Figure 5 is a structural schematic diagram of a tariff syntax tree for bill charging provided by an embodiment of the present application;

[0055] Figure 6 is a flow schematic diagram of a bill charging method provided by yet another embodiment of the present application;

[0056] Figure 7 is a structural schematic diagram of an electronic device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0057] The features and exemplary embodiments of the various aspects of the present application will be described in detail below with reference to the drawings. To make the purpose, technical solutions and advantages of the present application more clear, the present application will be further described in detail below with reference to the drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain the present application, but not to limit the present application. The present application can be implemented without some of the specific details by those skilled in the art. The following description of the embodiments is only to provide a better understanding of the present application by showing examples of the present application.

[0058] It should be noted that, in this document, relational terms such as first and second and the like can be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Moreover, the terms "comprises", "comprising", or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without more limitations, an element defined by the statement "comprising" does not exclude the existence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0059] To solve the prior art problems, the application embodiments provide a call charging system, method, device and computer storage medium. The call charging system, method, device and computer storage medium provided by the application embodiments will be described in detail below with reference to the drawings.

[0060] The system architecture and business scenarios described in the application embodiments are used to more clearly illustrate the technical solutions of the application embodiments, and do not constitute a limitation on the technical solutions provided by the application embodiments. Those skilled in the art can know that, with the evolution of network architecture and the appearance of new business scenarios, the technical solutions provided by the application embodiments are also applicable to similar technical problems. The systems and methods provided in the application embodiments are taken as examples for illustration in the call charging.

[0061] As shown in Figure 1 , Figure 1 A structure diagram of a call charging system provided by the application embodiments is shown. The call charging system 100 can include a preprocessing module 10 and a charging module 20.

[0062] The preprocessing module 10 is used to obtain call files. In the application, the call files can include international roaming call files. The preprocessing module 10 can obtain a large number of call files at a time.

[0063] The charging module 20 can include a charging master 201 and a charging service 202. The charging master 201 is a service consumer of an open source distributed service framework Dubbo, and the charging service 202 is a service provider of Dubbo. The charging master 201 can be used to receive a charging quotation request about the call files, and the charging service 202 can be used to respond to the charging quotation request and charge the call files.

[0064] For example, the charging master is a service consumer of Dubbo, responsible for receiving a charging quotation request, and can be called through a Dubbo interface. The charging service is a service provider of Dubbo, and can publish services by integrating a Dubbo interface.

[0065] According to the call charging system provided by the application embodiments, a distributed service scheduling architecture based on Dubbo is built. Dubbo is used for distributed scheduling of charging. Dubbo is structured in a layered manner. Using this manner can decouple between layers, that is, the modules in the system are relatively independent, and can provide a high-performance call charging mode to meet the requirement of fast charging, improve the efficiency of call charging, and improve the problem of charging delay. In addition, the load balancing strategy of extended Dubbo can be supported to realize load balancing of the charging service, improve the charging efficiency, and at the same time, can be dynamically expanded, and has good scalability to meet the requirements of business growth and peak processing.

[0066] In addition, because Dubbo is a high-performance, lightweight open source Java RPC framework, it is very easy to use Dubbo distributed service scheduling framework for the call billing, which only needs to be simply configured to use, so that the application can realize the output and input functions of the service through the high-performance RPC. If other open source distributed service scheduling frameworks are used, the code development difficulty is increased, the development cycle is longer, the development cost is more, other frameworks involve more components, system maintenance is difficult, and the billing performance is difficult to achieve the same effect as Dubbo. The Dubbo distributed service scheduling framework has good scalability, and the number of machines for deploying billing master and billing service instances can be dynamically increased, and the billing master and billing service instances can be dynamically deleted, thereby improving the utilization of machines and the billing performance.

[0067] In some examples, please continue to refer to Figure 1 The call billing system provided by the embodiment of the present application can further include a Redis cluster 30, which can be used to receive the processed call file sent by the preprocessing module 10 and receive the information of the call file after billing sent by the billing service 202. The preprocessing module 10 can be specifically used to: obtain the call file, sequentially perform decoding verification, duplicate checking, and call sorting processing on the call file, and write the processed call file into the Redis cluster 30. The billing service 202 can be specifically used to: respond to the billing pricing request of the billing master 201, charge the preprocessed call file, and feed back the information of the call file after billing to the Redis cluster, and feed back the billing state to the billing master.

[0068] In the embodiment of the present application, because Redis is an in-memory key-value type database, by using the Redis cluster type database, the read-write efficiency of the intermediate file can be improved, which is beneficial to solve the concurrent input-output (IO) problem of the database, and the input-output intermediate file of each service of the call billing is stored by using Redis, which is beneficial to meet the high-performance processing requirement of the call billing.

[0069] As an example, the call file is an international roaming call file, and the preprocessing module 10 can be specifically used to: sequentially perform decoding verification, duplicate checking, and call sorting on the international roaming call file.

[0070] For example, first, the international roaming call file is decoded and file-level checked, then the call file after decoding and checking is correctly processed for duplicate checking, and then the call file after duplicate checking is processed for call sorting.

[0071] Exemplarily, in the duplicate checking process, different fields can be spliced according to different users, and a unique key value can be generated, and the key value can be inserted into a duplicate checking table in batches for duplicate checking processing. If a single file that violates the uniqueness constraint appears, it indicates that the record is a duplicate single, the record of the single can be found in the cache and marked as a duplicate single, and subsequent single processing can be continued.

[0072] After duplicate checking, normal single files can be subjected to single sorting processing. For example, the single files can be divided into multiple small files according to the user's home province and city, and each small file can contain international roaming single file information belonging to the home province. Specifically, each small file can contain fields such as user, home province, call start time, call end time, call duration, opposite number, and traffic. The preprocessing module 10 can store the field information of the small single files after division into the Redis cluster according to certain rules.

[0073] In some embodiments, please refer to Figure 1 The single billing system can further include a memory database 40, which can be used to store billing states of multiple small files and billing processing configuration information, the small files being divided from the single files according to the home location, each small file including single information of the home location to which the small file belongs, and each small file exemplarily further including user information, subscription relationship, billing public reference bureau data, and billing cumulative amount data.

[0074] The application introduces the memory key-value database Redis to store the detailed information, and uses the memory database to store user information, subscription relationship, billing public reference bureau data, and billing cumulative amount data, which can improve the read-write efficiency of the files, solve the concurrent IO problem of the database, improve the system performance, and meet the requirements of high performance, robustness, and stable single level query.

[0075] As an example, the memory database can have high availability.

[0076] The memory database can include a billing file processing state table and a billing processing configuration table.

[0077] The billing file processing state table is used to record the processing state of the small files. For example, the billing file processing state table can include multiple items from the following:

[0078] 0: waiting for processing;

[0079] 1: being processed;

[0080] 2: file processing is completed and accepted;

[0081] 3: file processing is completed, and the entire file is rejected for billing;

[0082] 4: Read from the Redis cluster to the data is empty, billing fails;

[0083] 5: Read from the Redis cluster to the data quantity is inconsistent with the number of bill sheets in pre-processing statistics, billing fails;

[0084] 6: Can not find the rate, billing fails;

[0085] 7: Result publishing;

[0086] 8: Result publishing is completed;

[0087] 9: Pre-processing pre-success state, no billing notification.

[0088] The billing processing configuration table information can include province code, city code, bill sheet source, instance, processing thread number, file queue name, etc.

[0089] It can be understood that the memory database 40 stores the detailed data of the bill file.

[0090] Specifically, the pre-processing module 10 divides the bill file into multiple small files, then stores the information of the small files to be rated after the division into the billing file processing state table of the memory database, and finally reads the billing processing configuration table information of the memory database, and transmits the information of each small file to be rated to the corresponding message queue, that is, transmits the billing rating request to the corresponding message queue. After the pre-processing process is completed, the billing rating request can be notified to the billing master through the message queue.

[0091] In some embodiments, please continue to refer to Figure 1 The bill billing system can also include an autonomous controllable distributed database 50 and a result processing module 60.

[0092] The autonomous controllable distributed database 50 can be used to store and count intermediate data and result data in the bill file billing process. The result processing module 60 can be used to process the results according to the bill information after billing and the data of the autonomous controllable distributed database 50. The result processing includes at least one of the following: result publishing, file issuing, and settlement statistics.

[0093] In the embodiments of the present application, by setting the autonomous controllable distributed database and the result processing module, a big data component is introduced to publish the bill data, issue the file, and perform settlement statistics, which helps to improve the settlement statistical efficiency and avoid the delay of account debiting.

[0094] In summary, the application introduces various database storage schemes, uses the memory key-value database Redis to store the input and output intermediate files of each service in charging, uses the memory database to store user information, subscription relationship, charging public bureau data, and charging cumulative amount, etc., stores the result data in the self-controllable distributed database, improves the read and write efficiency of the intermediate file, solves the concurrent IO problem of the database, improves the system performance, and meets the requirements of high performance, robustness, and stable call record level query.

[0095] Based on the same inventive concept, the application also provides a call record charging method. The call record charging method provided by each embodiment of the application can be implemented by a call record charging system. To avoid repetition, the specific implementation process of the call record charging can refer to the introduction of the call record charging method provided by each embodiment.

[0096] As shown in Figure 2 The call record charging method provided by the application can include S11-S13.

[0097] S11, obtaining a call record file;

[0098] S12, based on the open source distributed service framework Dubbo, taking the charging master as a service consumer of Dubbo, and the charging master receiving a charging quotation request about the call record file;

[0099] S13, taking the charging service as a service provider of Dubbo, and the charging service responding to the charging quotation request and charging the call record file.

[0100] The specific implementation of each step will be described in detail below.

[0101] According to the call record charging method provided by the application, a distributed service scheduling architecture based on Dubbo is built, Dubbo is used for distributed scheduling in charging, Dubbo is structured in a layered manner, and using this manner can decouple each layer, that is, each module in the system is relatively independent and can provide a high-performance call record charging mode to meet the requirement of fast charging, which is beneficial to improve the call record charging efficiency and improve the charging delay. In addition, the load balancing strategy of extending Dubbo can be supported to realize the load balancing of the charging service, improve the charging efficiency, and at the same time, it can be dynamically expanded and has good scalability to meet the requirements of business growth and peak processing.

[0102] In addition, because Dubbo is a high-performance, lightweight open source Java RPC framework, the use of the Dubbo distributed service scheduling framework in the call billing has very small technical difficulty, and only needs to be simply configured to be used, so that the application can realize the output and input functions of the service through the high-performance RPC. If other open source distributed service scheduling frameworks are used, the code development difficulty is increased, the development cycle is longer, the development cost is more, the other frameworks involve more components, the system maintenance is difficult, and the billing performance is difficult to achieve the same effect as Dubbo. The use of the Dubbo distributed service scheduling framework has good scalability, and the billing master and the billing service instance can be dynamically increased in the machine deployment, and the billing master and the billing service instance can be dynamically deleted, so that the machine utilization rate is improved and the billing performance is improved.

[0103] The specific implementation of S11-S13 will be introduced below.

[0104] First, S11 is introduced.

[0105] The call file is an international roaming call file.

[0106] For example, S11 can specifically include: obtaining the call file, and sequentially performing decoding verification, duplication checking, and call sorting on the call file. The specific implementation of decoding verification, duplication checking, and call sorting on the call file can be referred to the above introduction of the preprocessing module 10, and will not be described in detail here.

[0107] S12 and S13 are introduced next.

[0108] In order to better understand the present application, the Dubbo architecture in the present application is introduced first.

[0109] From the perspective of the service model, Dubbo can abstract two roles of a service provider (Provider) and a service consumer (Consumer), and the Dubbo architecture for call billing provided in the embodiments of the present application is as shown in Figure 3 .

[0110] Figure 3 The roles of the nodes in the figure are as follows:

[0111] Provider: a service provider that exposes services. The billing service is a service provider.

[0112] Consumer: a service consumer that calls remote services. The billing master is a service consumer.

[0113] Registry: a registration center for service registration and discovery. The zookeeper cluster is a registration center.

[0114] Monitor: statistical service call times and call time monitoring center. Dubbo-admin is used as the monitoring center.

[0115] Container: service running container. Spring is used as the service running container.

[0116] Specifically, spring is used as the container, Dubbo is a distributed service framework, for example, only jar files of Dubbo can be added to the classpath, and Dubbo is loaded by spring, that is, Dubbo information is configured in the spring configuration file, including providers, consumers, registration centers and the like, and specific configuration information is set according to actual needs, which is not limited in the present application.

[0117] The billing master receives the billing request for the call file, in other words, the billing master finds the file to be billed, then synchronously requests the billing service, waits for the billing to be completed, and then continues to process the next billing file.

[0118] The billing master here is multiple instances, the file to be billed can be multiple, and the billing service is multiple instances, and the call of the same user can be processed in series.

[0119] Dubbo is used for distributed scheduling, the billing master is used as a Dubbo service consumer, responsible for receiving the billing request, and calling through the Dubbo interface. The billing service is used as a Dubbo service provider, and can publish services by integrating the Dubbo interface. Dubbo is responsible for implementing distributed scheduling and load balancing and other functions, and provides transparent remote method invocation. All Dubbo service consumers and service providers must be registered in a unified registration center zookeeper, which is responsible for the governance of these services and the routing between service consumers (billing master) and service providers (billing service).

[0120] Through Dubbo, distributed scheduling billing between the billing master and the background service of multiple instances can be realized, and a jar file package provided by Dubbo is used, which is a non-intrusive jar file package, including a complete set of distributed service framework of Dubbo, and the service consumer and the service provider do not need to introduce any classes in the jar file package, only need to configure the name of the service consumer and the service provider, the implemented interface, the used communication protocol, the load balancing strategy, the fault tolerance strategy, the registration center and the like in the general spring configuration file, so as to realize the calling of the service consumer to the service provider. Through these configurations, load balancing, remote communication and cluster fault tolerance between the service consumer and the service provider are realized.

[0121] Specifically, the related service (e.g., charging service 1, charging service 2, …, charging service n) calling information can be stored in an in-memory database, and then a load balancing mechanism is implemented. The charging service acts as a service provider, and the charging master acts as a consumer of the charging service. The charging master can obtain a file from a file processing control table in the in-memory database. The file processing control table can be written with related information at the beginning of S11, including, for example, the charging file name, the pre-processing sorting time of the file, the file name to be sent, the call detail record source, the total number of call detail records of the file, the home province code, the home city, the pre-result publishing instance name, the charging start processing time, the charging completion processing time, the charging processing state, the charging service version for processing the file, and the like. The charging master updates the charging master distribution time and the identity of the master, and then calls the charging service for charging processing. After the charging service processing is completed, the charging processing state and the completion charging time in the file processing control table can be written back.

[0122] The charging master uses the Dubbo distributed service scheduling framework, and thus supports multiple processes. Different processes can be started on different machines, and different master processes can be responsible for distribution in different directions (which can be grouped). Each master process can perform a heartbeat mechanism with a heartbeat process. When the heartbeat discovers that a certain master process has no heartbeat response, an alarm is sent to the monitor to implement the charging master monitoring process.

[0123] In some examples, after S11, the call detail record charging method provided by the embodiments of the present application can further include: dividing the call detail record file into a plurality of small files according to the home location, each small file including call detail record information of the home location to which the small file belongs. Correspondingly, the step of receiving a charging pricing request for the call detail record file in S12 can specifically include: receiving a charging pricing request for the small file by the charging master. Correspondingly, the specific steps of charging the call detail record file in S13 can include: charging the call detail records of the plurality of small files in parallel. In this way, the charging efficiency can be further improved through parallel charging.

[0124] For example, the call detail record file can be divided into a plurality of small files according to the home province and city of the user, and each small file can contain international roaming call detail record file information belonging to the home province. Specifically, each small file can contain the fields of user, home province, call start time, call end time, call duration, opposite number, and traffic. The small call detail record files after the division can be stored in the Redis cluster according to certain rules. In addition, the information of the small files to be priced after the division can also be stored in the charging file processing state table of the in-memory database. The in-memory database can also include a charging processing configuration table.

[0125] Specifically, in S12, the charging master can use a memory database connection pool. After the charging master is started, the charging master can obtain the number of queues to be processed from the charging processing configuration table in the memory database according to the instance name, and then start a thread for each queue. The thread performs charging processing according to the service line, province code, and city code allocated to the thread as a query condition. The charging master can query the small files to be charged in the charging file processing state table, receive a charging pricing request, and call a charging service to perform charging pricing.

[0126] In S13, the charging service can perform charging processing on the small files to be charged in response to the charging pricing request from the charging master.

[0127] For example, each thread can perform short hibernation after processing a batch of files and continue to scan without exiting the thread. The charging master can deliver 1 to N small files to the charging service for charging pricing at a time, and the batch of files can be processed as a transaction. The charging master re-discovers the charging service at a regular time to ensure that newly added charging services can be discovered and called in time.

[0128] As an example, the result can be published as soon as the charging of each small file is completed, without waiting for the charging of other city small files of the file to be completed. The charging master delivers multiple small files to the charging service at a time, and the number of small files delivered can be controlled by the charging processing configuration table. The charging file can be taken out as a batch of files as a transaction, and multiple small files can be distributed to multiple threads for concurrent charging.

[0129] In some embodiments, the charging service can use an equal division algorithm to allocate the bills to perform charging processing, to speed up the overall processing efficiency of the bill charging. In S13, the step of parallel charging of the bills of the multiple small files can specifically include: determining the number of bill pieces of each user in the multiple small files; dividing the multiple small files into multiple threads according to the number of bill pieces of each user, wherein the bill files to be charged of the same user are allocated to the same thread; and performing parallel charging on the multiple threads.

[0130] The bill files of the same user are allocated to the same thread, which can prevent the problem of cumulative amount error caused by concurrent charging.

[0131] Specifically, the S11 obtains the call record file after decoding and checking, duplicate checking, and call record sorting, and writes the processed call record file into the Redis cluster. The billing master can read a batch of call records from the Redis cluster, and in the process of parsing the read call record file, the number of call records of each user in the batch of call record files can be counted, and then the call records are distributed to the thread link. The call records are distributed by using the equal distribution algorithm. When each call record is distributed to a thread, the number of subsequent call records of the user of the call record is counted, so that the number of subsequent call records distributed to the thread can be predicted, recorded, and sorted after each call record is distributed. The thread with the smallest number of pre-distributed call records is taken as the distribution thread of the next call record, so as to further distribute the call records to the threads, and thus the overall processing efficiency of the call record billing is improved.

[0132] For example, in the S12, the step of receiving the billing pricing request of the call record file by the billing master can specifically include: receiving the billing pricing request of the call record file by the billing master from the billing file processing state table and / or the message queue, and scheduling the billing master; wherein the billing file processing state table includes the processing state of the call record file.

[0133] In the S12, the step of billing the call record file in response to the billing pricing request can specifically include: determining the billing standard corresponding to the call record file in response to the billing pricing request, and billing the call record file according to the billing standard.

[0134] As an example, as shown in Figure 4 , the billing master can be started first. The billing master supports polling the memory database billing file processing state table and listening to the message queue to obtain the small file to be billed, so as to receive the billing pricing request. The billing master schedules the billing service through Dubbo.

[0135] As introduced above, the obtained call detail record file is stored in the Redis cluster after a series of preprocessing, that is, the Redis cluster stores the detailed information of the call detail record file. The billing service can read the detailed information from the Redis cluster, and parse the information read from the Redis cluster to determine the billing standard corresponding to the call detail record file. For example, it can be checked whether the call to be billed exists a usable subscription relationship. If there exists an international roaming subscription relationship, the specific package product subscribed by the user can be taken as the billing standard, so that the specific package product subscribed by the user is priced according to the specific package product subscribed by the user, and the usage amount of the subscribed package product is accumulated. If no international roaming product is subscribed, the international roaming basic fee can be taken as the billing standard, so that the international roaming basic fee is priced according to the international roaming basic fee, and the usage amount of the basic fee is accumulated after pricing. After the billing service completes the pricing of the call detail record file, the information in the billing file processing state table in the memory database can be updated, and the billing state can be returned to the billing master.

[0136] The inventor finds that when the international roaming call detail record is priced, the user in the call detail record can have multiple international roaming subscription products or multiple user basic fee conditions, so in S13, the specific steps of billing the call detail record file can include: billing the call detail record file according to the cost syntax tree. In this way, the billing accuracy can be improved.

[0137] Specifically, the architecture diagram of the cost syntax tree adopted by the present application can be as shown in Figure 5 The cost syntax tree can include multiple operation rules. Specifically:

[0138] MUT: indicates a mutual exclusion relationship. If the left node is not established, the right node cost calculation result is taken; if the left node is established, the left node cost calculation result is taken.

[0139] ADD: indicates a superposition relationship: on the basis of the left node discount, the right node discount is calculated.

[0140] MAX: indicates taking the optimal fee of the left and right nodes.

[0141] MIN: indicates taking the worst fee of the left and right nodes

[0142] Each leaf node of the syntax tree can correspond to a billing cost (that is, a subscription product) subscribed by the user. The default relationship between the billing costs can be MUT. The child billing cost relationship is configured on the billing cost syntax expression. The billing cost defines the priority, and when constructing the syntax tree, the entire syntax tree is generated according to the cost priority from large to small and the principle of left first and right second, which ensures that the syntax tree cost is executed according to the priority size in the case of left subtree priority.

[0143] In some embodiments, after the session file billing, the method provided by the embodiments of the present application can further include: storing the information of the billed session file to a Redis cluster; synchronizing the information of the billed session file stored by the Redis cluster to a corresponding directory of a Hbase database and a distributed file system HDFS; storing and counting the intermediate data and result data of the billing by using the self-controllable distributed database, and storing the source file to the corresponding directory of the HDFS; mapping the data in the HDFS to a HIVE cluster; and performing settlement statistics and file distribution according to the data of the self-controllable distributed database and the HIVE cluster. In this way, after the billing is completed, the result publishing, file distribution, settlement statistics and the like of the billing small file are performed, and by introducing the Hbase and the big data computing capability, the system query statistics and analysis capability can be optimized.

[0144] As an example, the specific steps of storing the information of the billed session file to the corresponding directory of the Hbase database and the distributed file system HDFS can include: writing the information of the billed session file to a distributed message queue of an open source stream processing platform Kafka; synchronizing the distributed message queue of the Kafka to the Hbase database by using a computing engine Spark streaming; inserting the distributed message queue of the Kafka to a corresponding distributed search engine ElasticSearch of the Kafka by using the Hbase database, and storing the distributed message queue of the Kafka to the corresponding directory of the HDFS.

[0145] As described above, the information of the billed session file can be fed back to the Redis cluster. Specifically, as shown in FIG. 6, the information of the billed session file can be first read from the Redis cluster, and then written to the distributed message queue of the open source stream processing platform Kafka by using the physical library synchronization. Figure 6

[0146] ​The distributed message queue of Kafka can be synchronized to the Hbase database through the computing engine Spark streaming, the distributed message queue in Kafka is inserted into the Hbase database, and then the message is inserted into the topic of the distributed search engine ElasticSearch corresponding to Kafka, the distributed search engine ElasticSearch synchronizes the message in the message queue of Kafka, and then the message is stored into the corresponding directory of the distributed file system HDFS. The data in the distributed file system HDFS is mapped into the HIVE table through the HIVE cluster synchronization timing. The query agent service can listen to the query request sent by the client, obtain the corresponding ROWKEY after receiving the request, and query the corresponding data from the HIVE cluster according to the ROWKEY and return the data to the client.

[0147] In this way, data can be read from the autonomous controllable distributed database cluster and the HIVE cluster, settlement statistics and file distribution are performed, the foreground and other application programs query data through the search agent service and the data query service, settlement reports are generated, and the settlement reports are used for business accounting.

[0148] According to the embodiment of the application, the Hbase cluster is used to store the billing bill details read from the Redis cluster, the autonomous controllable distributed database is used to store the statistical intermediate data and result data, the search engine ElasticSearch and the query language HQL are used to implement the settlement statistical function, the settlement statistical efficiency can be improved, and the accounting delay can be avoided. The ElasticSearch search engine is introduced to establish the secondary index of the bill table on the Hbase cluster, the query agent service is newly added, and the function of quickly querying the bill data in the Hbase cluster is implemented.

[0149] Based on the same inventive concept, the embodiment of the application further provides an electronic device. Figure 7 A hardware structure schematic diagram of the electronic device provided by the embodiment of the application is shown.

[0150] The electronic device can include a processor 701 and a memory 702 in which computer program instructions are stored.

[0151] Specifically, the processor 701 can include a central processing unit (CPU), or an application specific integrated circuit (ASIC), or can be configured as one or more integrated circuits that implement the embodiment of the application.

[0152] The memory 702 can include mass storage for data or instructions. As an example and not by way of limitation, the memory 702 can include a hard disk drive (HDD), a floppy disk drive, flash memory, an optical disc (e.g., a compact disc (CD) or a digital versatile disc (DVD)), a solid-state drive (SSD), a USB drive, or a combination of two or more of these. Where appropriate, the memory 702 can include removable or non-removable (or fixed) media. Where appropriate, the memory 702 can be internal or external to the integrated gateway disaster recovery appliance. In particular embodiments, the memory 702 is non-volatile, solid-state memory.

[0153] The memory can include read-only memory (ROM), random-access memory (RAM), magnetic disk storage mediums, optical storage mediums, flash memory devices, electrical, optical, or other physical / tangible memory storage devices. Thus, in general, the memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., a memory device) encoded with software that, when executed (by one or more processors), is operable to

[0154] The processor 701 implements the control method of the software robot in any of the above embodiments by reading and executing the computer program instructions stored in the memory 702.

[0155] In one example, the electronic device can further include a communication interface 703 and a bus 710. As shown, the processor 701, the memory 702, and the communication interface 703 are connected through the bus 710 and complete communication with each other. Figure 7

[0156] The communication interface 703 is mainly used to realize the communication between the modules, devices, units and / or equipment in the embodiments of the present application.

[0157] ​Bus 710 includes a hardware, software, or both that couples components of electronic device to each other. As an example and not by way of limitation, bus can include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an InfiniBand (IB) interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel 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 another suitable bus or a combination of two or more of these. Where appropriate, bus 710 can include one or more buses. Although this application describes and shows a particular bus, this application contemplates any suitable bus or interconnect.

[0158] The electronic device can execute the call charging method in the embodiments of the application, thereby realizing the call charging system and method described in combination Figure 1 and Figure 2 with the call charging method in the embodiments of the application.

[0159] In addition, in combination with the call charging method in the above embodiments, the embodiments of the application can provide a computer storage medium to realize. The computer storage medium has computer program instructions stored thereon; the computer program instructions are executed by a processor to realize any one of the call charging methods in the above embodiments.

[0160] It needs to be clear that the application is not limited to the specific configurations and processes described above and shown in the drawings. 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 the application is not limited to the specific steps described and shown, and those skilled in the art can make various changes, modifications and additions, or change the order between steps, after understanding the spirit of the application.

[0161] The functions noted in the description of the structural block diagrams above 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, functional cards, and the like. When implemented in software, the elements of the present application are program or code segments that are used to perform the required tasks. The program or code segments can be stored in a machine-readable medium or transmitted through a data signal carried in a carrier wave over a transmission medium or communication link. A "machine-readable medium" includes any medium that can store or transport information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, and the like. The code segments can be downloaded via computer networks such as the Internet, intranets, and the like.

[0162] It is also important to note that the examples mentioned in the present application describe some methods or systems based on a series of steps or devices. However, the present application is not limited to the order of the steps mentioned in the examples, that is, the steps can be performed in the order mentioned in the examples, or in a different order from the examples, or several steps can be performed simultaneously.

[0163] The computer program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other processing device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other processing device to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. These computer program instructions can also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other processing device to operate in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function / act specified in the flowchart and / or block diagram block or blocks.

[0164] The above merely describes a specific implementation of the present application. Those skilled in the art can clearly understand the specific working processes of the system, modules and units described above for the convenience and brevity of description, and can refer to the corresponding processes in the foregoing method embodiments, which will not be described herein again. It should be understood that the protection scope of the present application is not limited to this, and any person skilled in the art can easily think of various equivalent modifications or replacements within the technical range disclosed by the present application, and these modifications or replacements should be covered within the protection scope of the present application.

Claims

1. A call billing system, characterized by, The system comprises: a preprocessing module configured to obtain a bill file; a charging module, the charging module comprising a charging master and a charging service, the charging master serving as a service consumer of a Dubbo, and the charging service serving as a service provider of the Dubbo, the charging master being configured to receive a charging request for the bill file, and the charging service being configured to respond to the charging request and charge the bill file; the charging master being configured to receive a charging request for a small file, the small file being obtained by dividing the bill file according to a place of origin, and each small file comprising bill information of the place of origin to which the small file belongs; the charging service being configured to charge the bill files in the small files in parallel; the charging service being configured to determine the number of bill files of each user in the small files, and distribute the small files to multiple threads according to the number of bill files of each user by using a uniform distribution algorithm, wherein the bill files to be charged of the same user are distributed to the same thread, and the multiple threads are charged in parallel.

2. The system of claim 1, wherein, The system further comprises a Redis cluster, which is configured to receive the processed bill file sent by the preprocessing module and receive the bill information after charging sent by the charging service; the preprocessing module is specifically configured to obtain a bill file, sequentially perform decoding verification, duplicate checking, and bill sorting on the bill file, and write the processed bill file into the Redis cluster; the charging service is specifically configured to respond to the charging request, charge the processed bill file, and feed back information of the bill file after charging to the Redis cluster and feed back a charging state to the charging master.

3. The system of claim 1, wherein, The system further comprises an in-memory database, which is configured to store charging states of multiple small files and charging processing configuration information, the small files being obtained by dividing the bill file according to a place of origin, and each small file comprising bill information of the place of origin to which the small file belongs.

4. The system of claim 2, wherein, The system further comprises an autonomous and controllable distributed database and a result processing module; the autonomous and controllable distributed database is configured to store and count intermediate data and result data in a charging process of the bill file; the result processing module is configured to perform result processing according to the bill information after charging and data of the autonomous and controllable distributed database, the result processing comprising at least one of the following: result publishing, file issuing, and settlement counting.

5. A method of charging a phone bill, characterized by, The method comprises: obtaining a bill file; based on a Dubbo, serving as a service consumer of the Dubbo, a charging master receives a charging request for the bill file; serving as a service provider of the Dubbo, a charging service responds to the charging request and charges the bill file; after the bill file is obtained, the method further comprises: dividing the bill file into multiple small files according to a place of origin, and each small file comprising bill information of the place of origin to which the small file belongs; The step of receiving the charging pricing request of the bill file by the charging master controller specifically comprises: The step of charging the bill file specifically comprises: The step of charging the bill file of the plurality of small files in parallel specifically comprises:

6. The method of claim 5, wherein, The step of charging the bill file of the plurality of small files in parallel specifically comprises: The step of receiving the charging pricing request of the bill file by the charging master controller specifically comprises: The charging master controller receives the charging pricing request of the bill file from a charging file processing state table and / or a message queue, and dispatches the charging service; wherein the charging file processing state table comprises the processing state of the bill file; The step of charging the bill file by the charging service in response to the charging pricing request specifically comprises:

7. The method of claim 5, wherein, The charging service determines the charging standard corresponding to the bill file in response to the charging pricing request, and charges the bill file according to the charging standard. After the step of charging the bill file, the method further comprises: Storing the information of the bill file after charging to a Redis cluster; Synchronizing the information of the bill file after charging stored by the Redis cluster to a corresponding directory of a Hbase database and a distributed file system HDFS; Storing and counting intermediate data and result data of charging by using an autonomous controllable distributed database, and storing a source file to the corresponding directory of the HDFS; Mapping the data in the HDFS to a HIVE cluster; 8. The method of claim 7, wherein, According to the data of the autonomous controllable distributed database and the HIVE cluster, performing settlement statistics and file delivery. The step of storing the bill information after charging to the corresponding directory of the Hbase database and the distributed file system HDFS comprises: Writing the bill information after charging to a distributed message queue of an open source stream processing platform Kafka; Synchronizing the distributed message queue of the Kafka to a Hbase database by a computing engine Spark streaming; 9. The method of claim 5, wherein, Inserting the distributed message queue of the Kafka to a distributed search engine ElasticSearch corresponding to the Kafka by the Hbase database, and storing the distributed message queue of the Kafka to the corresponding directory of the HDFS. The step of charging the bill file specifically comprises:

10. An electronic device, comprising: Charging the bill file according to a tariff syntax tree. The device comprises a processor and a memory storing computer program instructions; 11. A computer readable storage medium, characterized in that, The processor executes the computer program instructions to realize the bill charging method according to any one of claims 5 to 9. The computer readable storage medium stores computer program instructions, and the computer program instructions are executed by the processor to realize the bill charging method according to any one of claims 5 to 9.

Images