CN115473968B - Call record processing method and device - Google Patents

Abstract

The invention provides a ticket processing method and a ticket processing device, wherein the method comprises the following steps: the method comprises the steps of obtaining an identifier of a user to be processed, and distributing the identifier of the user to be processed to a plurality of intermediate ends, so that each intermediate end respectively obtains user ticket data corresponding to the identifier of the user to be processed, which is distributed and obtained from a database; acquiring user ticket data sent by each intermediate end, and distributing the user ticket data to a plurality of message middleware so that each message middleware can respectively determine rollback user ticket data from the user ticket data distributed by the message middleware; and acquiring the call ticket data of the rollback user sent by each message middleware, and sending all call ticket data of the rollback user to the target charging system, so that the call ticket rollback is rapidly processed, the time required for carrying out the call ticket rollback is reduced, and the call ticket rollback efficiency is improved.

Description

Call record processing method and device

Technical Field

The embodiments of the present invention relate to the field of communication technology, and in particular to a call record processing method and device.

Background technique

Call bill rollback refers to the situation where some users are charged incorrectly due to rate changes, etc., and the price needs to be re-rated based on the user's communication details, i.e. the call bill data.

In the prior art, when performing call bill rollback, after obtaining the to-be-processed user ID, the electronic device sequentially obtains the call bill data corresponding to each to-be-processed user ID from the distributed database, and obtains the call bill data of the rolled-back user from the call bill data. After obtaining the call bill data of the rolled-back user, it is input into the billing system so that the billing system re-batch prices according to the call bill data of the rolled-back user.

However, since the call bill data corresponding to the pending user identifier and the call bill data of the rolled-back user are obtained in sequence, it takes a long time to obtain the data, which results in a long time required for call bill rollback and low call bill rollback efficiency.

Summary of the invention

The embodiment of the present invention provides a call record processing method and device to solve the technical problem of low call record fallback efficiency in the prior art.

In a first aspect, an embodiment of the present invention provides a method for processing a call record, including:

Obtaining the identifier of the user to be processed, and distributing the identifier of the user to be processed to multiple intermediate terminals, so that each intermediate terminal respectively obtains user call record data corresponding to the identifier of the user to be processed allocated to it from the database;

Acquire user call list data sent by each middle end, and distribute the user call list data to multiple message middlewares, so that each message middleware can respectively determine the fallback user call list data from the user call list data distributed to it;

Obtain the fallback user call list data sent by each message middleware, and send all fallback user call list data to the target billing system.

In a possible design, distributing the user call record data to a plurality of message middlewares includes:

Obtain the hash value range corresponding to each message middleware, and determine the hash value corresponding to each user call record data;

For each user call record data, the message middleware to which the user call record data belongs is determined according to the hash value corresponding to the user call record data; wherein the hash value corresponding to the user call record data is within the hash value range corresponding to the message middleware to which the user call record data belongs.

In a possible design, determining the hash value corresponding to each user call record data includes:

For each user call record data, the key field corresponding to the user call record data is obtained, and a hash calculation is performed on the key field to obtain the hash value corresponding to the user call record data.

In one possible design, the method further includes:

The weight corresponding to each message middleware is obtained, and the hash value interval corresponding to each message intermediate value is determined according to the weight corresponding to each message middleware.

In a possible design, distributing the user call record data to a plurality of message middlewares includes:

The user call record data is evenly distributed to each message middleware.

In a possible design, distributing the identifier of the to-be-processed user to multiple intermediate terminals includes:

The identifiers of the users to be processed are evenly distributed to each intermediate end.

In a second aspect, an embodiment of the present invention provides a call record processing device, including:

An information acquisition module, used to acquire the identifier of the user to be processed, and distribute the identifier of the user to be processed to multiple intermediate terminals, so that each intermediate terminal respectively acquires the user call record data corresponding to the identifier of the user to be processed allocated to it from the database;

A processing module, used for acquiring user call bill data sent by each intermediate end, and distributing the user call bill data to a plurality of message middlewares, so that each message middleware can respectively determine the fallback user call bill data from the user call bill data distributed to it;

The processing module is used to obtain the fallback user call list data sent by each message middleware, and send all the fallback user call list data to the target billing system.

In a possible design, the processing module is further used for:

Obtain the hash value range corresponding to each message middleware, and determine the hash value corresponding to each user call record data;

For each user call record data, the message middleware to which the user call record data belongs is determined according to the hash value corresponding to the user call record data; wherein the hash value corresponding to the user call record data is within the hash value range corresponding to the message middleware to which the user call record data belongs.

In a possible design, the processing module is further used for:

For each user call record data, the key field corresponding to the user call record data is obtained, and a hash calculation is performed on the key field to obtain the hash value corresponding to the user call record data.

In a possible design, the processing module is further used for:

The weight corresponding to each message middleware is obtained, and the hash value interval corresponding to each message intermediate value is determined according to the weight corresponding to each message middleware.

In a possible design, the processing module is further used for:

The user call record data is evenly distributed to each message middleware.

In a possible design, the information acquisition module is further used to:

The identifiers of the users to be processed are evenly distributed to each intermediate end.

In a third aspect, an embodiment of the present invention provides an electronic device, including: at least one processor and a memory;

The memory stores computer-executable instructions;

The at least one processor executes the computer-executable instructions stored in the memory, so that the at least one processor executes the call record processing method as described in the first aspect and various possible designs of the first aspect.

In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium, in which computer execution instructions are stored. When a processor executes the computer execution instructions, the call record processing method described in the first aspect and various possible designs of the first aspect is implemented.

In a fifth aspect, an embodiment of the present invention provides a computer program product, including a computer program. When the computer program is executed by a processor, it implements the call record processing method as described in the first aspect and various possible designs of the first aspect.

The present invention provides a call bill processing method and device. When the identifier of a user to be processed is obtained, it indicates that a fallback user needs to be determined from the users to be processed. Then, the identifier of the user to be processed is allocated to an intermediate end, so that each intermediate end respectively obtains user call bill data corresponding to the identifier of the user to be processed allocated to it from a database, that is, each intermediate end is only responsible for searching for user call bill data corresponding to some of the users to be processed, and each intermediate end can search at the same time, so as to realize parallel acquisition of user call bill data and reduce the time required for acquiring user call bill data. After the user call bill data corresponding to the user to be processed is obtained, the user call bill data corresponding to the user to be processed is allocated to a message middleware, so that each message middleware respectively determines the fallback user call bill data from the user call bill data allocated to it, that is, determines the fallback user from the users to be processed. Since each message middleware is only responsible for searching for fallback users from some of the users to be processed, and each message middleware can search at the same time, the fallback user, that is, the parallel acquisition of fallback user call bill data is realized, so as to reduce the time required for acquiring fallback user call bill data. Receive the rolled-back user call sheet data sent by each message middleware, and send it to the target billing system so that the target billing system can re-price the rolled-back user call sheet data, realize fast processing of call sheet rollback, reduce the time required for call sheet rollback, and improve the efficiency of call sheet rollback.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

FIG1 is a schematic diagram of an existing call record processing process provided by an embodiment of the present invention;

FIG2 is a flow chart of a method for processing a call slip according to an embodiment of the present invention;

FIG3 is a second flow chart of a method for processing a call slip according to an embodiment of the present invention;

FIG4 is a schematic diagram of the structure of a call record processing device provided in an embodiment of the present invention;

FIG. 5 is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present invention.

Detailed ways

In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

FIG. 1 is a schematic diagram of an existing call record processing process provided by an embodiment of the present invention. As shown in FIG. 1 , the existing call record processing process includes the following steps:

(I) The upstream system transmits the collected communication call record files of the users, i.e. the users to be processed, to the billing system.

(ii) After the batch pricing program in the billing system processes the user's communication call record file, it inputs the accumulated amount, bill and other data into the memory database, and generates a detailed data file, i.e., a file containing the call record data, and sends it to the warehousing program.

(3) The warehousing program inputs the detailed order data file into the distributed database, namely the Hbase database.

(IV) When it is necessary to obtain the call bill data of the rolled-back user, the rollback program, that is, the electronic device obtains the call bill data corresponding to the pending user identifier from the distributed database one by one, that is, obtains the call bill data of the pending user, and cyclically executes the data query operation according to the rollback rule to extract the call bill data of the rolled-back user from the call bill data of the pending user.

(V) The rollback program deletes the data in the relevant tables of the memory database according to the acquired user accumulation, bills and other data, and writes the extracted call list data of the rolled-back user into a file, so that the pricing program in the billing system can use the call list data of the rolled-back user in the file to re-process the pricing.

However, since the call bill data corresponding to the pending user identifier is obtained and the call bill data of the rolled-back user is extracted from the call bill data of the pending user, they are all processed one by one in sequence, which results in a longer time for obtaining the data, reducing the efficiency of call bill rollback, thereby affecting the progress of billing and user perception.

Therefore, in response to the above problems, the technical concept of the present invention is to improve the above steps (iv) and (v), that is, when obtaining the call bill data corresponding to the pending user identifier, the middle end is used to query the distributed database in parallel to obtain the call bill data corresponding to the pending user identifier from the distributed database, thereby improving the efficiency of obtaining the call bill data. And when the data query operation is cyclically executed according to the fallback rule to extract the call bill data of the rolled-back user from the call bill data of the pending user, the message middleware is used for parallel extraction to achieve the efficiency of screening the call bill data of the rolled-back user. Since the efficiency of obtaining the call bill data of the pending user and the efficiency of extracting the call bill data of the rolled-back user are both improved, the processing efficiency of the call bill rollback can be further improved, the progress of the billing can be guaranteed, and the user can obtain the relevant communication fees in a timely manner, ensuring the user's satisfaction and high user experience.

The following is a detailed description of the technical solution of the present invention and how the technical solution of the present invention solves the above-mentioned technical problems with specific examples. The following specific examples can be combined with each other, and the same or similar concepts or processes may not be repeated in some examples. The examples of the present invention will be described below in conjunction with the accompanying drawings.

FIG2 is a flow chart of a method for processing a call slip according to an embodiment of the present invention. The execution subject of this embodiment may be an electronic device, and specifically, may be a rollback program. As shown in FIG2 , the method includes:

S201. Obtain an identifier of a user to be processed, and distribute the identifier of the user to be processed to multiple intermediate terminals, so that each intermediate terminal obtains user call record data corresponding to the identifier of the user to be processed distributed to it from a database.

In this embodiment, when it is necessary to search for users who need to be re-priced, i.e., rolled-back users, from users, i.e., users to be processed, the identifier of the user to be processed is obtained, and the user call list data corresponding to each user to be processed is searched using the identifier of each user to be processed, thereby determining the rollback users from the users to be processed using the user call list data of the users to be processed.

In order to improve the efficiency of searching for user call bill data, the identifiers of the users to be processed are assigned to multiple intermediate ends, each intermediate end is only responsible for processing the identifiers of some of the users to be processed among all the users to be processed, and each intermediate end can perform processing synchronously, that is, for each intermediate end, the intermediate end only searches the database for the user call bill data corresponding to the identifier of the user to be processed that is assigned to it, and sends the found user call bill data to the electronic device, that is, sending the found user call bill data of the user to be processed to the electronic device, thereby realizing parallel acquisition of user call bill data, instead of searching the user call bill data of the users to be processed from the database one by one, reducing the time required for acquiring user call bill data, thereby improving the efficiency of acquiring user call bill data.

In any embodiment, optionally, when the identifiers of the users to be processed are given to a plurality of intermediate terminals respectively, the identifiers of the users to be processed are evenly distributed to the intermediate terminals.

Specifically, the number of intermediate terminals and the number of all users to be processed, that is, the number of identifiers of all users to be processed, are obtained, and the number to be processed corresponding to each intermediate terminal is determined according to S1=N1/N2, so as to allocate the identifiers of the users to be processed using the number to be processed corresponding to each intermediate terminal. Among them, S1 is the number to be processed corresponding to the intermediate terminal, N1 is the number of identifiers of all users to be processed, and N2 is the number of all intermediate terminals. For example, if the number of identifiers of users to be processed is 200,000 and the number of intermediate terminals is 5, then the number to be processed corresponding to each intermediate terminal is 40,000, that is, each intermediate terminal is responsible for processing the identifiers of 40,000 users to be processed, that is, searching the database for the user call list data corresponding to the identifiers of the 40,000 users to be processed, that is, searching for the user call list data of the 40,000 users to be processed.

The database is a distributed database that stores detailed data of multiple users, namely, call data. The middle end includes computers, servers and other terminal devices with data processing capabilities.

S202: Obtain user call bill data sent by each intermediate end, and distribute the user call bill data to multiple message middlewares, so that each message middleware determines the rollback user call bill data from the user call bill data distributed to it.

In this embodiment, after receiving the user call bill data of the to-be-processed users sent by each intermediate end, that is, after receiving the user call bill data corresponding to the identifiers of the to-be-processed users assigned to each intermediate end, the electronic device distributes all the user call bill data to multiple message middlewares, and each message middleware is only responsible for part of the user call bill data in all the user call bill data, that is, for each message middleware, the message middleware filters the user call bill data that needs to be rolled back from the user call bill data that is assigned to it, that is, the assigned user call bill data, according to the rollback rule, to obtain the rollback user call bill data, that is, determine the rollback user from the assigned to-be-processed users according to the user call bill data of the to-be-processed users. After the rollback users, that is, the rollback user call bill data, are screened out, the rollback user call bill data, the rollback user call bill data is sent to the electronic device to realize parallel query of the rollback user call bill data, that is, to realize parallel query of the to-be-processed users that need to be rolled back.

In this embodiment, optionally, when distributing user call record data to multiple message middlewares, the distribution can be performed in two ways.

One way is to evenly distribute the user call record data, that is, evenly distribute the user call record data to each message middleware.

Specifically, the number of message middleware and the number of all user call list data are obtained, that is, the number of identifiers of all users to be processed, and the corresponding number of to-be-processed data of each message middleware is determined according to S2=N1/N3, so as to allocate user call list data using the corresponding number of to-be-processed data of each message middleware, that is, the number of user call list data allocated in each message middleware is the corresponding number of to-be-processed data of the message middleware. Among them, S2 is the corresponding number of to-be-processed data of the message middleware, N1 is the number of identifiers of all users to be processed, that is, all user call list data, and N3 is the number of all message middleware.

Another way is to allocate according to the processing capability of the message middleware, that is, weight.

Optionally, the fallback rule is a fallback condition, which is a condition defined by relevant personnel for screening users with billing problems, including screening date, fallback problem type, etc. The fallback problem type indicates the type of billing problem, such as rate change. For example, the fallback rule includes a screening date and a problem type, where the screening date is January 20, and the fallback problem type is call rate change. When screening fallback users according to the fallback rule, users who made calls on January 20 are actually determined.

Optionally, user call bill data represents the user's communication detail data, which includes user identification, bill and other data.

In addition, optionally, after receiving the user call bill data of the to-be-processed users sent by each intermediate end, the user call bill data is aggregated to obtain all user call bill data, that is, to obtain the user call bill data of all the to-be-processed users.

In addition, optionally, after filtering out the call sheet data of the rolled-back user from the database, the related call sheet data of the rolled-back user in the memory database is deleted to avoid duplication of the call sheet data during subsequent storage.

S203: Acquire the call sheet data of the rolled-back users sent by each message middleware, and send all the call sheet data of the rolled-back users to the target billing system.

In this embodiment, the message middleware determines the fallback user call sheet data from the user call sheet data, that is, after screening the fallback user from the to-be-processed users, the user call sheet data of the fallback user, that is, the fallback user call sheet data, is sent to the electronic device. After receiving the fallback user call sheet data sent by all the message middleware, the electronic device indicates that it is necessary to use the fallback user call sheet data corresponding to the fallback user for re-pricing, that is, to re-bill the fallback user, and then sends all the received user call sheet data to the target billing system, so that the target billing system re-prices according to the user call sheet data to realize call sheet fallback.

Optionally, when the target billing system re-rates, it is actually the pricing program in the target billing system that performs the pricing.

It can be understood that the operations performed by the above-mentioned message middleware (for example, screening rollback users) are actually performed by the terminal corresponding to the message middleware, that is, the terminal where the message middleware is located.

In this embodiment, when querying the call list data of the user to be processed from the database, multiple middle terminals are used for parallel query to improve the efficiency of obtaining the call list data. When determining the fallback user from the user to be processed, that is, determining the fallback user's call list data from the call list data, multiple message middlewares are used for parallel determination to improve the fallback user, that is, the efficiency of obtaining the fallback user's call list data, thereby improving the efficiency of the fallback processing. And when transmitting the fallback user's call list data, the message transmission method is adopted instead of the file transmission, so as to avoid using only one output channel for transmission, which greatly improves the data transmission efficiency and further improves the efficiency of the fallback processing.

From the above description, it can be seen that when the identifier of the user to be processed is obtained, it indicates that the fallback user needs to be determined from the users to be processed. Then, the identifier of the user to be processed is assigned to the intermediate end, so that each intermediate end obtains the user call bill data corresponding to the identifier of the user to be processed assigned to it from the database, that is, each intermediate end is only responsible for finding the user call bill data corresponding to some of the users to be processed, and each intermediate end can search at the same time, so as to realize the parallel acquisition of user call bill data and reduce the time required for acquiring user call bill data. After obtaining the user call bill data corresponding to the user to be processed, the user call bill data corresponding to the user to be processed is assigned to the message middleware, so that each message middleware can determine the fallback user call bill data from the user call bill data assigned to it, that is, determine the fallback user from the users to be processed. Since each message middleware is only responsible for finding the fallback user from some of the users to be processed, and each message middleware can search at the same time, the fallback user, that is, the parallel acquisition of the fallback user call bill data is realized, and the time required for acquiring the fallback user call bill data is reduced. Receive the rolled-back user call sheet data sent by each message middleware, and send it to the target billing system so that the target billing system can re-price the rolled-back user call sheet data, realize fast processing of call sheet rollback, reduce the time required for call sheet rollback, and improve the efficiency of call sheet rollback.

FIG3 is a second flow chart of the method for processing a call sheet provided by an embodiment of the present invention. Based on the embodiment of FIG2 , when allocating user call sheet data to the message middleware, the user call sheet data to be processed by the message middleware can be determined according to the processing capability of the message middleware, that is, the weight. This process will be described below in conjunction with a specific embodiment. As shown in FIG3 , the method includes:

S301, obtaining the identifier of the user to be processed, and distributing the identifier of the user to be processed to multiple intermediate terminals, so that each intermediate terminal obtains user call record data corresponding to the identifier of the user to be processed distributed to it from the database.

S302: Obtain user call record data sent by each intermediate end.

S303: Obtain the hash value interval corresponding to each message middleware, and determine the hash value corresponding to each user call record data.

In this embodiment, when allocating user call record data to each message middleware, that is, when determining the message middleware to which each user call record data belongs, the hash value corresponding to each user call record data is calculated so as to utilize the hash value range to which the hash value corresponding to each user call record data belongs to determine the message middleware to which each user call record data belongs.

In this embodiment, optionally, when calculating the hash value corresponding to each user call bill data, for each user call bill data, the key field corresponding to the user call bill data is obtained, and the key field is hashed to obtain the hash value corresponding to the user call bill data.

Specifically, for each user call bill data, key fields are extracted from the user call bill data, and a hash calculation is performed on the key fields using a preset hash function to obtain a hash value corresponding to the user call bill data, that is, to obtain a hash value of the user to be processed corresponding to the user call bill data.

Among them, the preset hash function is an existing hash function, which can be set according to actual needs and is not limited here.

Optionally, the key field may be a user ID, that is, an ID of the user to be processed, and specifically, may be the last four digits of the user ID.

In addition, optionally, when determining the hash value interval corresponding to the message middleware, that is, the hash value interval that the message middleware is responsible for, it can be determined in the following two ways.

One way is that relevant personnel set the hash value interval corresponding to each message middleware, that is, the hash value interval responsible for each message middleware is directly set by humans, so as to realize the rapid setting of the hash value interval.

Another way is to obtain the weight corresponding to each message middleware, and determine the hash value interval corresponding to each message middleware according to the weight corresponding to each message middleware.

Specifically, the weight coefficient corresponding to each message middleware is obtained, so as to determine the hash value interval that each message middleware is responsible for by using the weight coefficient corresponding to each message middleware.

Furthermore, when using the weight coefficient to determine the hash value interval that the message middleware is responsible for, it can be determined according to the weight hash mapping table, that is, for each message middleware, the hash value interval corresponding to the weight coefficient corresponding to the message middleware is searched from the weight hash mapping table to obtain the hash value interval corresponding to the message middleware.

Optionally, when using the weight coefficient to determine the hash value interval that the message middleware is responsible for, the value space of the consistent hash function H is set to 0-9999, and the hash value that each message middleware is responsible for is calculated according to the formula hash(N)=∑ _i=1,...,n 10000*w _n to obtain the hash value interval corresponding to each message middleware. Wherein, w _n represents the weight of the nth message middleware, and the number of message middleware is N.

Optionally, the weight system of the message middleware is determined according to the performance of the message middleware, that is, the terminal corresponding to the message middleware. Specifically, it is assigned to the message middleware by relevant personnel or electronic equipment according to the backend performance analysis report of the message middleware.

S304. For each user call record data, determine the message middleware to which the user call record data belongs according to the hash value corresponding to the user call record data, wherein the hash value corresponding to the user call record data is within the hash value range corresponding to the message middleware to which the user call record data belongs.

In this embodiment, when the hash value corresponding to each user's call record data is calculated, that is, when the hash value corresponding to each user to be processed is calculated, for each user to be processed, the hash interval to which the hash value corresponding to the user to be processed belongs is determined, and the message middleware corresponding to the hash interval is determined as the message middleware that processes the user call record data of the user to be processed, so as to obtain the message middleware to which the user call record data of the user to be processed belongs, thereby realizing the distribution of user call record data.

S305: distribute the user call record data to the message middleware to which it belongs, so that the message middleware determines the rollback user call record data from the user call record data distributed to it.

S306: Acquire the rollback user call list data sent by each message middleware, and send all the rollback user call list data to the target billing system.

In this embodiment, when allocating user call record data to the message middleware, it is allocated to the message middleware according to the weight of the message middleware, that is, the processing capacity, so that the message middleware can quickly process the user call record data, that is, quickly filter out the rolled back user call record data from the user call record data, realize the rapid determination of the rolled back user call record data, and improve the data processing efficiency.

FIG. 4 is a schematic diagram of the structure of a call record processing device provided in an embodiment of the present invention. As shown in FIG. 4 , the call record processing device 400 includes: an information acquisition module 401 and a processing module 402 .

The information acquisition module 401 is used to obtain the identifier of the user to be processed and distribute the identifier of the user to be processed to multiple intermediate terminals, so that each intermediate terminal can obtain the user call list data corresponding to the identifier of the user to be processed allocated to it from the database.

The processing module 402 is used to obtain the user call record data sent by each intermediate end, and distribute the user call record data to multiple message middlewares, so that each message middleware can determine the rollback user call record data from the user call record data distributed to it.

The processing module 402 is used to obtain the rollback user call record data sent by each message middleware, and send all the rollback user call record data to the target billing system.

In another embodiment of the present invention, based on the embodiment shown in FIG. 4 above, the processing module 402 is further configured to:

Get the hash value range corresponding to each message middleware, and determine the hash value corresponding to each user call record data.

For each user call sheet data, the message middleware to which the user call sheet data belongs is determined according to the hash value corresponding to the user call sheet data, wherein the hash value corresponding to the user call sheet data is within the hash value interval corresponding to the message middleware to which the user call sheet data belongs.

In this embodiment, optionally, the processing module 402 is further configured to:

For each user call record data, obtain the key field corresponding to the user call record data, and perform hash calculation on the key field to obtain the hash value corresponding to the user call record data.

In this embodiment, optionally, the processing module 402 is further configured to:

The weight corresponding to each message middleware is obtained, and the hash value interval corresponding to each message intermediate value is determined according to the weight corresponding to each message middleware.

In any embodiment, optionally, the processing module 402 is further configured to:

Distribute user call record data evenly to each message middleware.

In any embodiment, optionally, the information acquisition module 401 is further used to:

Distribute the IDs of the users to be processed evenly to each intermediate end.

The call record processing device provided in the embodiment of the present invention can implement the call record processing method of the above embodiment. Its implementation principle and technical effect are similar and will not be repeated here.

Fig. 5 is a schematic diagram of the hardware structure of an electronic device provided by an embodiment of the present invention. As shown in Fig. 5, the electronic device 500 of this embodiment includes: a processor 501 and a memory 502;

The memory 502 is used to store computer-executable instructions;

The processor 501 is used to execute the computer-executable instructions stored in the memory to implement the various steps performed by the receiving device in the above embodiment. For details, please refer to the relevant description in the above method embodiment.

Optionally, the memory 502 may be independent or integrated with the processor 501 .

When the memory 502 is independently provided, the electronic device further includes a bus 503 for connecting the memory 502 and the processor 501 .

An embodiment of the present invention further provides a computer-readable storage medium, in which computer-executable instructions are stored. When a processor executes the computer-executable instructions, the call record processing method as described above is implemented.

An embodiment of the present invention further provides a computer program product, including a computer program, and when the computer program is executed by a processor, the call record processing method as described above is implemented.

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

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

In addition, each functional module in each embodiment of the present invention may be integrated into one processing unit, each module may exist physically separately, or two or more modules may be integrated into one unit. The above-mentioned module-composed unit may be implemented in the form of hardware or in the form of hardware plus software functional units.

The above-mentioned integrated module implemented in the form of a software function module can be stored in a computer-readable storage medium. The above-mentioned software function module is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor (English: processor) to perform some steps of the method described in each embodiment of the present application.

It should be understood that the processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), etc. A general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in the invention may be directly implemented as being executed by a hardware processor, or may be implemented by a combination of hardware and software modules in the processor.

The memory may include a high-speed RAM memory, and may also include a non-volatile storage NVM, such as at least one disk memory, and may also be a USB flash drive, a mobile hard disk, a read-only memory, a magnetic disk or an optical disk, etc.

The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, the bus in the drawings of the present application is not limited to only one bus or one type of bus.

The above storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk. The storage medium can be any available medium that can be accessed by a general or special purpose computer.

An exemplary storage medium is coupled to a processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can be located in an application specific integrated circuit (ASIC). Of course, the processor and the storage medium can also exist as discrete components in an electronic device or a main control device.

Those skilled in the art can understand that all or part of the steps of implementing the above-mentioned method embodiments can be completed by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, the steps of the above-mentioned method embodiments are executed; and the aforementioned storage medium includes: ROM, RAM, disk or optical disk and other media that can store program codes.

Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims (10)

1. A method for processing a call record, characterized by comprising: Acquire multiple identifiers of users to be processed, and distribute the multiple identifiers of the users to be processed to multiple intermediate terminals, wherein the identifiers of the users to be processed distributed to each intermediate terminal are different, so that each intermediate terminal respectively acquires user call record data corresponding to the identifiers of the users to be processed distributed to it from the database; Acquire user call list data sent by each middle end, and distribute the user call list data to multiple message middlewares, so that each message middleware can respectively determine the fallback user call list data from the user call list data distributed to it; Obtain the fallback user call list data sent by each message middleware, and send all fallback user call list data to the target billing system. 2. The method according to claim 1, characterized in that the step of distributing the user call record data to a plurality of message middlewares comprises: Obtain the hash value range corresponding to each message middleware, and determine the hash value corresponding to each user call record data; For each user call record data, the message middleware to which the user call record data belongs is determined according to the hash value corresponding to the user call record data; wherein the hash value corresponding to the user call record data is within the hash value interval corresponding to the message middleware to which the user call record data belongs. 3. The method according to claim 2, wherein determining the hash value corresponding to each user call record data comprises: For each user call record data, the key field corresponding to the user call record data is obtained, and a hash calculation is performed on the key field to obtain the hash value corresponding to the user call record data. 4. The method according to claim 2, characterized in that the method further comprises: The weight corresponding to each message middleware is obtained, and the hash value interval corresponding to each message intermediate value is determined according to the weight corresponding to each message middleware. 5. The method according to claim 1, characterized in that the step of distributing the user call record data to a plurality of message middlewares comprises: The user call record data is evenly distributed to each message middleware. 6. The method according to any one of claims 1 to 5, characterized in that the step of distributing the identifiers of the to-be-processed users to a plurality of intermediate terminals comprises: The identifiers of the users to be processed are evenly distributed to each intermediate end. 7. A call record processing device, characterized by comprising: An information acquisition module is used to acquire multiple identifiers of users to be processed, and allocate the multiple identifiers of the users to be processed to multiple intermediate terminals, and the identifiers of the users to be processed allocated to each intermediate terminal are different, so that each intermediate terminal respectively acquires user call list data corresponding to the identifiers of the users to be processed allocated to it from the database; A processing module, used for acquiring user call bill data sent by each intermediate end, and distributing the user call bill data to a plurality of message middlewares, so that each message middleware can respectively determine the fallback user call bill data from the user call bill data distributed to it; The processing module is used to obtain the fallback user call list data sent by each message middleware, and send all the fallback user call list data to the target billing system. 8. An electronic device, comprising: at least one processor and a memory; The memory stores computer-executable instructions; The at least one processor executes the computer-executable instructions stored in the memory, so that the at least one processor executes the call record processing method as described in any one of claims 1 to 6. 9. A computer-readable storage medium, characterized in that the computer-readable storage medium stores computer-executable instructions, and when a processor executes the computer-executable instructions, the call record processing method as described in any one of claims 1 to 6 is implemented. 10. A computer program product, comprising a computer program, characterized in that when the computer program is executed by a processor, the call record processing method according to any one of claims 1 to 6 is implemented.