A method of processing parking payment information and an electronic device

Abstract

The application relates to the field of intelligent parking, and relates to a method for processing parking payment information and an electronic device, which are applied to a parking charging system. The parking charging system comprises a main server, a first server and a second server. The method comprises the following steps: the first server receives a parking payment request sent by a client; the first server generates parking payment information according to the parking payment request; the first server sends the payment information and user information of the client to the main server; the first server sends the payment information to the second server; when the main server determines that the first server cannot process the parking payment information, the main server instructs the second server to process the parking payment information. The above method can quickly recover the processing of parking payment information.

Description

Technical Field

[0001] This application relates to the field of smart parking, and more particularly to a method and electronic device for processing parking payment information. Background Technology

[0002] As is well known, since unattended parking lots rely entirely on online payment for parking fees, the stability of these online payment platforms is extremely important. The stability of the online payment platform depends on the stability of the cloud server. The cloud server may handle tens of thousands of online payment orders every moment. If the cloud server fails for a period of time—for example, if it malfunctions while processing parking payment information—drivers will be unable to complete their online payment and thus unable to leave the parking lot. This situation will not only cause severe congestion at the entrances and exits of many parking lots but also provide drivers with an extremely poor experience.

[0003] Therefore, how to quickly restore the processing of parking payment information is an urgent problem to be solved. Summary of the Invention

[0004] This application provides a method and electronic device for processing parking payment information, which can quickly restore the processing of parking payment information.

[0005] In a first aspect, a method for processing parking payment information is provided, applied to a parking fee collection system, the parking fee collection system comprising: a main server, a first server, and a second server, the method comprising: the first server receiving a parking payment request sent by a client; the first server generating parking payment information based on the parking payment request; the first server sending the parking payment information and the client's user information to the main server; the first server sending the parking payment information to the second server; and when the main server determines that the first server cannot process the parking payment information, the main server instructing the second server to process the parking payment information.

[0006] The first server promptly synchronizes parking payment information to both the primary and second servers. Upon receiving the parking payment information, the primary server monitors the first server's processing of it. If the primary server detects that the first server is unable to process the payment information, it immediately instructs the second server to retrieve the pre-synchronized parking payment information and continue processing it. The second server does not store user information and is dedicated solely to processing parking payment information. Compared to processing parking payment information through a general-purpose server (primary server), using the second server allows for faster recovery of the processing flow, thus improving the user experience.

[0007] Optionally, the master server determines that the first server cannot process the parking payment information by: the master server receiving a first query request sent by the client, the first query request being used to query the processing progress of the parking payment information; the master server sending a second query request to the first server based on the first query request, the second query request being used to query the processing progress of the parking payment information; and when the master server does not receive a response from the first server within a preset time period, the master server determines that the first server cannot process the parking payment information.

[0008] In this embodiment, the master server responds to the first query request by querying the first server for the processing progress of parking payment information. When the master server does not receive a response from the first server within a preset time period, it determines that the first server has failed. Subsequently, it can promptly instruct the second server to process the parking payment information, thereby avoiding long waiting times for users to complete the payment and improving the user experience.

[0009] Optionally, the parking payment request is an order generation request, and the parking payment information is a parking consumption order.

[0010] Optionally, the parking payment request is an order prepayment request, and the parking payment information is the parking prepayment fee.

[0011] Optionally, the parking payment request is an order payment query request, and the parking payment information is the order payment result.

[0012] Optionally, the first server sends the parking payment information and the client's user information to the main server, including: the first server sends the parking payment information and the client's user information to the main server through a data transmission service (DTS).

[0013] In this embodiment, the first server uses DTS to back up parking payment information and client user information to the main server in a timely manner, thereby avoiding the situation where parking payment information is lost due to the failure of the first server, which would prevent users from completing online payment of parking fees.

[0014] Optionally, the first server sending the parking payment information to the second server includes: the first server sending the parking payment information to the second server via Data Transmission Service (DTS).

[0015] In this embodiment, the first server uses DTS to synchronize parking payment information to the second server in a timely manner. When the first server fails and the user is unable to complete the online payment of parking fees, the master server can immediately instruct the second server to retrieve the previously synchronized parking payment information and continue to process the parking payment information, so as to reduce the time the user waits to pay parking fees and thus improve the user experience.

[0016] In a second aspect, an apparatus for generating reports is provided, including a module for performing any of the methods in the first aspect.

[0017] Thirdly, an electronic device is provided, including a processor and a memory, the memory for storing a computer program, and the processor for calling and running the computer program from the memory, causing the electronic device to perform the method described in any one of the first aspects.

[0018] Fourthly, a computer-readable storage medium is provided that stores a computer program, which, when executed by a processor, causes the processor to perform the method described in any one of the first aspects.

[0019] For the beneficial effects in the second, third and fourth aspects of this application, see the beneficial effects in the first aspect. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a schematic flowchart of the method for processing parking payment information in an embodiment of the present invention;

[0022] Figure 2 This is a schematic diagram of the parking fee collection system in an embodiment of the present invention;

[0023] Figure 3 This is a schematic diagram of the structure of another parking fee collection system in an embodiment of the present invention;

[0024] Figure 4 This is a schematic diagram illustrating the process of synchronizing parking payment information using Kafka in an embodiment of the present invention;

[0025] Figure 5 This is a schematic diagram of a device for processing parking payment information in an embodiment of the present invention;

[0026] Figure 6This is a schematic diagram of the structure of an electronic device in an embodiment of the present invention. Detailed Implementation

[0027] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0028] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0029] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0030] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0031] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0032] With the rapid adoption of unmanned parking lots, most rely entirely on online mobile payments for parking fees. Therefore, these parking lots are placing increasingly higher demands on the stability of online payment platforms. For example, unmanned parking lots use a parking fee collection system to process online payments from drivers; the stability of this system depends on the stability of the cloud server. As is well known, the cloud server may handle tens of thousands of online payment orders simultaneously. If the cloud server malfunctions during this period—for instance, if it fails to process parking payment information—drivers will be unable to complete their online payments and thus unable to exit the parking lot. This situation not only causes severe congestion at many parking lot entrances and exits but also provides drivers with an extremely poor experience. Therefore, how to quickly restore the processing of parking payment information is an urgent problem to be solved.

[0033] The present application will now be described in further detail with reference to the accompanying drawings and specific embodiments.

[0034] Figure 1 This is a flowchart illustrating the method for processing parking payment information in this application embodiment. The method for processing parking payment information provided in this application embodiment is applied to a parking fee collection system 200, such as... Figure 2 As shown, the parking fee collection system 200 includes: a main server 201, a first server 202, and a second server 203. The main server 201 is used to synchronize parking payment information sent by the first server 202 and user information of the client 204, and to control the switching of the first server 202 to the second server 203. The first server 202 is used to store and process user parking payment information, and the second server 203 is used to synchronize parking payment information sent by the first server 202. The order service database on the first server 202 is used to store user parking payment information. The order microservice database on the second server 203 is a micro-database specifically used to store and process parking payment information synchronized from the first server 203 to the second server 203. The main server 201 communicates with the first server 202 and the second server 203 respectively.

[0035] For example, a user uses the parking fee payment system 200 to pay for parking. The user sends a parking fee payment request to the first server 202 through the client 204. This parking fee payment request includes a parking consumption order generation request and corresponding user information. The first server 202 responds to the parking fee payment request and generates parking payment information. While processing the parking payment information, the first server 202 synchronizes the parking payment information and the corresponding user information to the main server 201 and also synchronizes the parking payment information to the second server 203. Under normal circumstances, the first server 202 processes the parking payment information and sends the processing result (e.g., a successful payment result) to the parking lot's vehicle management system. The vehicle management system determines whether to open the gate (e.g., open the gate) to allow the vehicle to leave the parking lot based on the processing result (e.g., a successful payment result). When the first server 202 malfunctions and cannot process the parking payment information, the main server 201 instructs the second server 203 to process the parking payment information. Since the second server 203 is only used to store parking payment information and not other information (such as user's basic personal information, user's parking consumption history, etc.), and is specifically used to process parking payment information, compared to processing parking payment information through a general server (main server 201), processing parking payment information through the second server 203 can quickly restore the parking payment information processing process. The aforementioned second server 203 processes the parking payment information and sends the processing result (e.g., a successful payment result) to the parking lot's vehicle management system, which determines whether to open the gate (e.g., open the gate) to allow the vehicle to leave the parking lot based on the processing result (e.g., a successful payment result).

[0036] For example, the aforementioned main server 201 is a public database server storing parking payment information from all regions of the country. It stores parking payment information sent by other servers and corresponding user information; it also stores configuration information for different servers processing parking payment information from different regions. The user information includes: basic user information, user parking consumption history, and user parking fee settlement records. The aforementioned public database server includes: a basic public database and an order public database. The basic public database stores basic vehicle information (e.g., license plate number, parking time, parking location), the aforementioned configuration information, and the aforementioned user information; the order public database stores parking payment information. For example, the first server 201 is responsible for parking payment information in South China, the third server is responsible for parking payment information in North China, and the fourth server is responsible for parking payment information in Southwest China. The main server 201 stores the configuration information for different servers processing parking payment information from different regions, so that users can easily query the servers processing parking payment information from different regions.

[0037] For example, the aforementioned main server 201, first server 202, and second server 203 are physically isolated from each other, meaning that data loss on any one server does not affect the data on the other two servers. The first server 201 only processes parking payment information within its designated area and synchronizes this information to both the main server 201 and the second server 203. For instance, the first server 201 might only process parking payment information for the South China region; parking payment information for other regions would be processed by other servers, which would also synchronize the parking payment information for those regions to both the main server 201 and the second server 203.

[0038] The master server 201 will constantly monitor the processing of parking payment information by the first server 201. Once the master server 201 detects that the first server 201 is malfunctioning and unable to process the parking payment information, it will switch the access address of the client 204 requesting the first server 201 to generate parking payment information to the second server 203, and control the second server 203 to respond to the parking fee payment request sent by the client 204. The second server 203 generates parking order information based on the parking payment request.

[0039] For example, the main server 201, the first server 202, and the second server 203 all employ a multi-level caching design, such as using local caching, Redis caching, and database storage, where each storage method is independent. When client 203 queries the server for parking payment information A, the server first checks the local cache. If parking payment information A is not found in the local cache, the server then checks the Redis cache. If parking payment information A is not found in the Redis cache, the server finally queries the database to determine if parking payment information A exists. If parking payment information A is also not found in the database, the server will issue an alert to promptly notify maintenance personnel that the server is malfunctioning and requires immediate attention.

[0040] For example, the main server 201, the first server 202 and the second server 203 mentioned above can be a single server or a server cluster. There is no limitation on this. Users can choose the combination of servers according to the actual application scenario.

[0041] like Figure 1 As shown, the method for processing parking payment information in this embodiment includes:

[0042] S101, the first server receives the parking payment request sent by the client.

[0043] For example, such as Figure 2As shown, a user on client 204 uses a parking application (e.g., the Jie Parking application) to send a parking payment request to the first server 202; the first server 202 receives the parking payment request and responds to it. For example, the first server 202 is responsible for processing parking payment information in South China. After parking in parking lot A, a user in South China sends a parking payment request X to the first server 202 through the Jie Parking application on their mobile phone; the first server 202 responds to the parking payment request X.

[0044] S102, the first server generates parking payment information based on the parking payment request.

[0045] For example, such as Figure 2 As shown, after receiving the parking payment request sent by the aforementioned parking software, the first server 202 generates parking payment information based on the parking payment request. For example, the first server 202 is responsible for processing parking payment information in South China. After a user in South China completes parking at parking lot A, they send a parking payment request X to the first server 202 through the Jietingche app on their mobile phone; the first server 202 generates parking payment information Y based on the parking payment request X.

[0046] For example, the parking payment request is an order generation request, and the parking payment information is a parking consumption order. The aforementioned order generation request is used to request the server to generate a parking consumption order for the user. Figure 2 As shown, after receiving the order generation request sent by the parking software, the first server 202 generates a parking consumption order based on the order generation request. For example, the first server 202 is responsible for processing parking payment information in the Southwest region. After a user in the Southwest region completes parking at parking lot B, they send an order generation request X1 to the first server 202 through the Jietingche app on their mobile phone; the first server 202 generates a parking consumption order Y1 based on the order generation request X1.

[0047] For example, the parking payment request is an order prepayment request, and the parking payment information is the parking prepayment fee. The aforementioned order prepayment request is used to request the server to generate the parking prepayment fee for the user. Figure 2As shown, after receiving the order prepayment request sent by the parking software, the first server 202 generates a parking prepayment fee based on the order prepayment request. For example, the first server 202 is responsible for processing parking payment information in North China. After a user in North China completes parking at parking lot C, the user pays for the parking consumption order generated by the first server 202 through the Jie Parking app on their mobile phone. When the user triggers the payment operation on the Jie Parking app, the Jie Parking app sends an order prepayment request X2 to the first server 202; the first server 202 generates a parking prepayment fee Y2 based on the order prepayment request X2.

[0048] For example, the parking payment request is an order payment query request, and the parking payment information is the order payment result. The aforementioned order payment query request is used to request the server to query the result of the user's parking consumption order payment. Figure 2 As shown, after receiving the order payment query request sent by the parking software, the first server 202 queries the payment result of the parking consumption order for the user based on the order payment query request and then feeds the payment result back to the user. For example, the first server 202 is responsible for processing parking payment information in North China. A user in North China completes parking at parking lot D and pays the parking fee, but the vehicle management software of parking lot D does not receive the payment result, so the user's vehicle cannot leave the parking lot. At this time, the user can send an order payment query request X3 to the first server 202 through the Jietingche app on their mobile phone. The first server 202 queries the payment result of the parking consumption order for the user based on the order payment query request X3 and then feeds the payment result back to the user.

[0049] S103, the first server sends parking payment information and client user information to the main server.

[0050] For example, the aforementioned parking payment information includes parking consumption orders, pre-paid parking fees, and order payment results; the aforementioned user information includes user personal information, vehicle identification, parking time, parking location, and payment method (e.g., WeChat Pay, bank card payment, Alipay, Huabei payment, etc.). For example, Figure 2 The client 204 sends user information and parking payment request to the first server 202; the first server 202 generates parking payment information based on the parking payment request; the first server 202 synchronizes the parking payment information and the corresponding user information to the main server 201; after receiving the parking payment information and the corresponding user information, the main server 201 stores the parking payment information in the order public database and the user information in the basic public database.

[0051] For example, the first server sends parking payment information and the client's user information to the main server via Data Transmission Service (DTS). Figure 2 As shown, the first server 202 can synchronize parking payment information and client 204's user information to the master server 201 via Data Transmission Service (DTS). Specifically, the first server 202 synchronizes the parking payment information to the order public database via DTS, and synchronizes the client 204's user information to the basic public database via DTS. The aforementioned order public database and basic public database can be MySQL, SQL Server, Oracle, Sybase, etc., and this application does not impose any limitations on them. Users can choose a suitable database according to their actual needs.

[0052] Optionally, such as Figure 3 As shown, the first server 202 can also send parking payment information and client user information to the main server 201 asynchronously through the Kafka data processing platform. Specifically, the first server 202 synchronizes (i.e., writes) the parking payment information to the order public database asynchronously through the Kafka data processing platform, and synchronizes (i.e. writes) the client 204's user information to the basic public database asynchronously through the Kafka data processing platform. Figure 3 (For illustration). The Kafka data processing platform mentioned above synchronizes parking payment information and client 204 user information to the master server 201 by subscribing to order data; the subscription order data is the data that subscribes to parking payment information and client 204 user information.

[0053] In this embodiment, the first server 202 uses DTS to synchronize parking payment information and user information of the client 204 to the main server 201 in a timely manner, thereby avoiding the situation where the parking payment information is lost due to the failure of the first server 202, which would prevent the user from completing the online payment of parking fees.

[0054] S104, the first server sends parking payment information to the second server.

[0055] For example, such as Figure 2 The client 204 sends a parking payment request to the first server 202; the first server 202 generates parking payment information based on the parking payment request; the first server 202 synchronizes the parking payment information to the second server 203; after receiving the parking payment information, the second server 203 stores the parking payment information in the order microservice database on the second server 203.

[0056] For example, the first server sends parking payment information to the second server via Data Transmission Service (DTS). Figure 2 As shown, the first server 202 can synchronize parking payment information to the second server 203 via DTS. Specifically, the first server 202 synchronizes the parking payment information to the order microservice database on the second server 203 via DTS. This order microservice database can be MySQL, SQL Server, Oracle, Sybase, etc., and this application does not impose any limitations on it. Users can choose a suitable database according to their actual needs.

[0057] In this embodiment, the first server 202 uses DTS to synchronize parking payment information to the second server 203 in a timely manner. When the first server 202 fails and the user is unable to complete the online payment of parking fees, the master server 201 can immediately instruct the second server 203 to retrieve the previously synchronized parking payment information and continue to process the parking payment information, so as to reduce the time the user waits to pay parking fees and thus improve the user experience.

[0058] S105, when the master server determines that the first server cannot process the parking payment information, the master server instructs the second server to process the parking payment information.

[0059] For example, under normal circumstances, the first server processes parking payment information and synchronizes it to both the master server and the second server. Once the master server detects that the first server is malfunctioning and unable to process the parking payment information, it immediately instructs the second server to process the parking payment information to ensure that the user can successfully complete the payment of parking fees.

[0060] For example, such as Figure 2As shown, after receiving an order generation request from client 204, the first server 202 generates a parking consumption order based on the request. The first server 202 sends this parking consumption order to client 204. However, if the user hasn't yet initiated a pre-payment request based on this parking consumption order, the first server 202 malfunctions. At this point, the main server 201 has switched the address through which client 204 accesses the first server 202 to the second server 203. The user then needs to refresh the order generation page on client 204 to see the parking consumption order. The regenerated parking consumption order is sent to client 204 by the second server 203 through the access address between the second server 203 and client 204. Furthermore, the user can access the parking consumption order through client 204... 04. Initiate a prepayment request for the parking consumption order and send the prepayment request to the second server 203 through the access address between the second server 203 and the client 204. The second server 203 will retrieve the parking consumption order corresponding to the prepayment request and generate a prepayment fee for the user based on the parking consumption order and the prepayment request. The second server 203 will send the prepayment fee to the client 204 through the access address between the second server 203 and the client 204. At this time, the user can complete the payment of the parking fee according to the prepayment fee and thus successfully leave the parking lot.

[0061] For example, such as Figure 2 As shown, the first server 202 has generated a parking prepayment fee for the user based on the order prepayment request sent by the client 204, and the user has initiated a prepayment based on the parking prepayment fee but has not yet successfully paid (for example, the user has not yet entered the password or the network suddenly disconnected). At this time, the first server 202 fails, and the main server 201 has switched the address through which the client 204 accesses the first server 202 to the second server 203. At this time, the user needs to refresh the prepayment fee generation page of the client 204 to see the parking prepayment fee. The regenerated parking prepayment fee is the first... The second server 203 sends the payment to the client 204 through the access address between the second server 203 and the client 204; at this time, the user pays the parking prepayment fee through the client 204 (for example, by selecting Alipay payment and entering the Alipay password to complete the payment); the user's payment result for the parking prepayment fee is sent to the second server 203 through the access address between the second server 203 and the client 204; the second server 203 sends the payment completion result to the parking lot's vehicle management system; the vehicle management system opens the gate according to the payment completion result, and the user exits the parking lot smoothly.

[0062] For example, such as Figure 2As shown, the user has completed the prepayment for the parking fee. However, before the parking lot's vehicle management system receives the payment result, the first server 202 malfunctions, and the main server 201 switches the address for client 204 to access the first server 202 to the second server 203. At this time, when the user sends an order payment query request to the server through client 204, the order payment query request is sent to the second server 203 through the access address between the second server 203 and client 204. The second server 203 queries the payment status of the corresponding parking consumption order based on the order payment query request and sends the query result to client 204 through the access address between the second server 203 and client 204, so as to inform the user of the payment status of the parking consumption order in a timely manner.

[0063] Optionally, after processing the parking payment information, the second server 203 can report the processing status to the main server 201 so that the main server 201 can promptly understand the status of the parking fee payment.

[0064] For example, the master server determines that the first server cannot process parking payment information by: the master server receiving a first query request sent by the client, the first query request being used to query the processing progress of the parking payment information; the master server sending a second query request to the first server based on the first query request, the second query request being used to query the processing progress of the parking payment information; and when the master server does not receive a response from the first server within a preset time period, the master server determines that the first server cannot process the parking payment information. The first query request includes: an order payment result query request and an order details query request, wherein the order payment result query request is used by the client to query the master server for the order payment result, and the order details query request is used by the client to query the master server for the order processing details; the second query request includes: an order payment result processing request and an order processing details request, wherein the order payment result processing request is used by the master server to query the first server for the order payment result, and the order processing details request is used by the master server to query the first server for the order processing details.

[0065] For example, such as Figure 2As shown, after a user pays the pre-payment for parking, the parking lot has not yet opened the gate for the user's vehicle. At this time, the user can send an order payment result query request to the main server 201 through the order query service provided by the parking application software on client 204. The main server 201 then sends an order payment result processing request to the first server 202 based on the order payment result processing request. The first server 202 queries the order service database on the first server 202 based on the order payment result processing request and sends the query result of the order payment result back to the main server 201. If the first server 202 does not receive the above-mentioned order payment result query result within a preset time period (e.g., within 2 seconds), the main server 201 determines that the first server 202 has malfunctioned and cannot process the user's parking payment information. Subsequently, it promptly instructs the second server 203 to process the parking payment information, avoiding a long waiting time for the user to complete the payment, thereby improving the user experience.

[0066] In summary, the first server promptly synchronizes parking payment information to both the main server and the second server. Upon receiving the parking payment information, the main server monitors the first server's processing of it. If the main server detects that the first server is unable to process the parking payment information, it immediately instructs the second server to retrieve the pre-synchronized parking payment information and continue processing it. The second server does not store user information and is dedicated solely to processing parking payment information. Compared to processing parking payment information through a general-purpose server (the main server), using the second server allows for faster recovery of the parking payment processing flow, thereby improving the user experience.

[0067] To facilitate understanding, the following will be combined with... Figure 3 The following example illustrates the process steps of the method for processing parking payment information provided in this application:

[0068] (1) A user temporarily parks in Parking Lot A in South China through the Jietingche app on client 204. The Jietingche app uses a distribution service to send a parking payment request to a server (e.g., the first server 202). The app determines which server should process the user's parking payment request based on the area where the user is parking. For example, the first server 202 is responsible for processing parking payment information for parking lots in South China. When a user parks in a parking lot in South China, the user's parking payment request should be sent to the first server 202 for processing.

[0069] (2) After parking, the user pays the parking fee through the Jietingche app. When the first server 202 is functioning normally, the user sends a parking payment request W1 to the first server 202 using the Jietingche app on the client 204; the first server 202 generates parking payment information based on the parking payment request W1 and synchronizes the parking payment information to the second server 203 and the main server 201 respectively. When the first server 202 malfunctions, the first server 202 cannot generate parking payment information based on the parking payment request W1, such as... Figure 3 As shown by the dashed line, at this point, the main server 201 instructs the second server 203 to process the parking payment information. For example, if a user temporarily parks in parking lot B in North China, the parking payment request W2 sent by the user on client 204 using the Jietingche app should be sent to the third server 301; the third server 301 then processes the user's parking payment request W2. The main server 201, the first server 202, the second server 203, and the third server 301 employ a multi-level caching design, such as using local caching, Redis caching, and MySQL database storage. It should be noted that the way servers in other regions process parking payment information is similar to that of the first server 202, and will not be elaborated further here.

[0070] Figure 5 This is a schematic diagram of the device 500 for processing parking payment information provided in this application. The device 500 includes a receiving module 501, a generating module 502, a sending module 503, and a determining module 504, wherein...

[0071] The receiving module 501 is used for the first server to receive parking payment requests sent by the client;

[0072] The generation module 502 is used by the first server to generate parking payment information based on the parking payment request;

[0073] The sending module 503 is used for the first server to send parking payment information and client user information to the main server; it is also used for the first server to send parking payment information to the second server.

[0074] The determination module 504 is used to instruct the second server to process the parking payment information when the master server determines that the first server cannot process the parking payment information.

[0075] For details on the specific methods by which device 500 processes parking payment information and the beneficial effects thereof, please refer to [link to relevant documentation]. Figure 1 The relevant descriptions in the method embodiments shown.

[0076] Figure 6 A schematic diagram of the structure of an electronic device provided in this application is shown. Figure 6 The dashed lines indicate that the unit or module is optional. Electronic device 600 can be used to implement the methods described in the above method embodiments. Electronic device 600 can be a server or a chip.

[0077] Electronic device 600 includes one or more processors 601, which enable electronic device 600 to implement Figure 1 The method described in the corresponding method embodiment. Processor 601 can be a general-purpose processor or a dedicated processor. For example, processor 601 can be a central processing unit (CPU). The CPU can be used to control the electronic device 600, execute software programs, and process data from the software programs. The electronic device 600 may also include a communication unit 605 for implementing signal input (reception) and output (transmission).

[0078] For example, electronic device 600 may be a chip, communication unit 605 may be the input and / or output circuit of the chip, or communication unit 605 may be the communication interface of the chip, and the chip may be a component of electronic device.

[0079] For example, the communication unit 605 may be a transceiver of the electronic device 600, or the communication unit 605 may be a transceiver circuit of the electronic device 600.

[0080] The electronic device 600 may include one or more memories 602, on which a program 604 is stored. The program 604 can be executed by a processor 601 to generate instructions 603, causing the processor 601 to execute the method described in the above method embodiments according to the instructions 603. Optionally, the memory 602 may also store data. Optionally, the processor 601 may also read data stored in the memory 602, which may be stored at the same memory address as the program 604, or it may be stored at a different memory address than the program 604.

[0081] The processor 601 and memory 602 can be configured separately or integrated together, for example, integrated on a system-on-chip (SOC) of an electronic device.

[0082] The specific manner in which the processor 601 executes the method for processing parking payment information can be found in the relevant description in the method embodiments.

[0083] It should be understood that the steps of the above method embodiments can be implemented by hardware logic circuits or software instructions in the processor 601. The processor 601 may be a CPU, a digital signal processor (DSP), a field programmable gate array (FPGA), or other programmable logic devices, such as discrete gate, transistor logic devices, or discrete hardware components.

[0084] This application also provides a computer program product that, when executed by processor 601, implements the methods described in any of the method embodiments of this application.

[0085] The computer program product can be stored in memory 602, for example, program 604. Program 604 is finally converted into an executable object file that can be executed by processor 601 after processing such as preprocessing, compilation, assembly and linking.

[0086] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a computer, implements the methods described in any of the method embodiments of this application. The computer program may be a high-level language program or an executable object program.

[0087] The computer-readable storage medium is, for example, memory 602. Memory 602 can be volatile memory or non-volatile memory, or memory 602 can include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate Synchronous DRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), SynchLink DRAM (SLDRAM), and Direct Rambus RAM (DRRAM).

[0088] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process and technical effects of the above-described apparatus and equipment can be referred to the corresponding processes and technical effects in the foregoing method embodiments, and will not be repeated here.

[0089] In the several embodiments provided in this application, the systems, apparatuses, and methods disclosed can be implemented in other ways. For example, some features of the method embodiments described above can be ignored or not performed. The apparatus embodiments described above are merely illustrative; the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Multiple units or components can be combined or integrated into another system. Furthermore, the coupling between units or components can be direct coupling or indirect coupling, including electrical, mechanical, or other forms of connection.

[0090] The embodiments described above are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for processing parking payment information, characterized in that, The method is applied to a parking fee collection system, which includes a main server, a first server, and a second server. The first server receives a parking payment request sent by the client; The first server generates parking payment information based on the parking payment request; The first server sends the parking payment information and the client's user information to the main server; The first server sends the parking payment information to the second server, and the second server has a dedicated order microservice database for storing and processing parking payment information; The main server receives a first query request sent by the client, the first query request being used to query the processing progress of the parking payment information; The master server sends a second query request to the first server based on the first query request. The second query request is used to query the processing progress of the parking payment information. If the master server does not receive a response from the first server within a preset time period, the master server determines that the first server cannot process the parking payment information. The master server then switches the client's access address to the first server to the second server and instructs the second server to retrieve the previously synchronized parking payment information for processing.

2. The method according to claim 1, characterized in that, The parking payment request is an order generation request, and the parking payment information is a parking consumption order.

3. The method according to claim 1, characterized in that, The parking payment request is an order prepayment request, and the parking payment information is the parking prepayment fee.

4. The method according to claim 1, characterized in that, The parking payment request is an order payment query request, and the parking payment information is the order payment result.

5. The method according to claim 1, characterized in that, The first server sends the parking payment information and the client's user information to the main server, including: The first server sends the parking payment information and the client's user information to the main server via Data Transmission Service (DTS).

6. The method according to claim 1, characterized in that, The first server sends the parking payment information to the second server, including: The first server sends the parking payment information to the second server via Data Transmission Service (DTS).

7. A device for processing parking payment information, characterized in that, This device is applied to a parking fee collection system, which includes a main server, a first server, and a second server. The device includes a receiving module, a generating module, a sending module, and a determining module. The receiving module is used by the first server to receive parking payment requests sent by the client; The generation module is used by the first server to generate parking payment information based on the parking payment request. The sending module is used for the first server to send the parking payment information and the client's user information to the main server; it is also used for the first server to send the parking payment information to the second server, wherein the second server is equipped with an order microservice database specifically for storing and processing parking payment information; The determining module is used for the main server to receive a first query request sent by the client, the first query request being used to query the processing progress of the parking payment information; The master server sends a second query request to the first server based on the first query request. The second query request is used to query the processing progress of the parking payment information. If the master server does not receive a response from the first server within a preset time period, the master server determines that the first server cannot process the parking payment information. The master server then switches the client's access address to the first server to the second server and instructs the second server to retrieve the previously synchronized parking payment information for processing.

8. An electronic device, characterized in that, The electronic device includes a processor and a memory, the memory being used to store a computer program, and the processor being used to call and run the computer program from the memory, causing the electronic device to perform the method of any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, causes the processor to perform the method of any one of claims 1 to 6.

Images