Account dividing method, apparatus and device for electric vehicle battery swap station, and medium

Abstract

The embodiment of the invention discloses an account division method, device and equipment for an electric vehicle battery swap station and a medium, and the method comprises the steps: determining a first lock state of a to-be-divided resource of the electric vehicle battery swap station requested to be accessed by a user based on the account division operation of the user; if the first lock state of the resources to be subjected to account division of the electric vehicle battery swap station is unlocked, account division operation is executed on the resources to be subjected to account division of the electric vehicle battery swap station through a specified thread, and an account division result is obtained; and releasing the locked resources and updating the first lock state of the to-be-distributed resources of the electric vehicle battery swap station to be unlocked if the distribution operation is completed on the to-be-distributed resources of the electric vehicle battery swap station. According to the method, the account division operation is performed on the to-be-divided resources of the electric vehicle battery swap station through the specified thread, the competition and performance bottleneck problems caused by the fact that multiple threads access the same resource at the same time are avoided, and the efficiency of the account division operation is improved.

Description

[0001] This application claims priority from the Chinese patent application filed with the Chinese Patent Office on December 29, 2023, with the application number 202311867718.6 and the invention title "A Method, Device, Equipment and Medium for Revenue Sharing in an Electric Vehicle Battery Swap Station". The entire text of the above Chinese patent application is incorporated herein by reference. Technical Field

[0002] This specification relates to the technical field of new energy electric vehicle battery swapping, and particularly to a method, device, equipment and medium for revenue sharing in an electric vehicle battery swap station. Background Art

[0003] In an electric vehicle battery swap station, revenue sharing of the battery swap station for electric vehicles refers to the process of the battery swap station performing fee settlement and distribution processing on the resources it manages and provides. When performing revenue sharing, the battery swap station can calculate the receivable fees according to the preset charging method and rate rules based on the actual usage of users or vehicles. These fees may include service fees, battery replacement fees, etc. The revenue sharing process also includes generating bills, sending bill information to users, receiving payments from users, etc. The battery swap station settles accounts with users or vehicle owners according to the fee information in the bill to ensure the accuracy and timeliness of the fees. By sharing the revenue of the resources, the battery swap station of electric vehicles can effectively manage the resources and accurately calculate the fees, provide clear and understandable fee details and bill information for users, and also provide necessary data support for the operation and management of the battery swap station.

[0004] When performing revenue sharing in an electric vehicle battery swap station, batch operations may involve multiple threads or processes accessing the same resource simultaneously, which may lead to problems of competition and performance bottlenecks. Most existing technologies use mutex locks, and deadlock problems may occur when dealing with such concurrent access, resulting in the system being unable to work properly. For example, when performing revenue sharing operations, multiple threads simultaneously attempt to perform revenue sharing operations on the account of the same electric vehicle. Without an appropriate concurrent control mechanism, data inconsistency or calculation errors may occur. In addition, if a large number of revenue sharing operations occur simultaneously, it will lead to system performance bottlenecks and reduce the efficiency of revenue sharing operations. Summary of the Invention

[0005] One or more embodiments of this specification provide a method, device, equipment and medium for revenue sharing in an electric vehicle battery swap station to solve the technical problems raised in the background art.

[0006] One or more embodiments of this specification adopt the following technical solutions:

[0007] A method for revenue sharing in an electric vehicle battery swap station provided by one or more embodiments of this specification includes:

[0008] Based on the user's profit sharing operation, determine the first lock state of the resources to be profit shared in the electric vehicle swapping station that the user requests to access;

[0009] If the first lock state of the resources to be profit shared in the electric vehicle swapping station is unlocked, perform a profit sharing operation on the resources to be profit shared in the electric vehicle swapping station through a specified thread to obtain a profit sharing result;

[0010] After completing the profit sharing operation on the resources to be profit shared in the electric vehicle swapping station, release the locked resources and update the first lock state of the resources to be profit shared in the electric vehicle swapping station to unlocked.

[0011] It should be noted that the embodiments of this specification have the following beneficial effects through the above content:

[0012] Improve system performance: By performing a profit sharing operation on the resources to be profit shared in the electric vehicle swapping station through a specified thread, it avoids the competition and performance bottleneck problems caused by multiple threads accessing the same resource simultaneously, and improves the efficiency of the profit sharing operation.

[0013] Ensure data consistency: When performing a profit sharing operation, by locking the resources to be profit shared in the electric vehicle swapping station, it avoids the situation of data inconsistency or calculation errors caused by multiple threads performing profit sharing operations on the accounts of the same electric vehicle simultaneously, and ensures data consistency.

[0014] Avoid deadlock problems: By releasing the locked resources and updating the first lock state of the resources to be profit shared in the electric vehicle swapping station to unlocked, it avoids deadlock problems when dealing with concurrent access and ensures the normal operation of the system.

[0015] Further, the determining the first lock state of the resources to be profit shared in the electric vehicle swapping station that the user requests to access includes:

[0016] Obtain a batch resource access request corresponding to the user's profit sharing operation, and convert the batch resource access request into at least one distributed resource access request;

[0017] Determine the second lock state corresponding to each distributed resource access request;

[0018] When the second lock states corresponding to all the distributed resource access requests are locked, determine that the first lock state corresponding to the batch resource access request is locked.

[0019] It should be noted that the embodiments of this specification have the following beneficial effects through the above content:

[0020] Improve system efficiency: Converting the batch resource access request into a distributed resource access request can process multiple requests in parallel and improve the processing efficiency of the system.

[0021] Ensure data consistency: By determining the second lock status corresponding to each distributed resource access request, multiple requests accessing the same resource simultaneously can be avoided, thus ensuring data consistency.

[0022] Improve the scalability of the system: Distributed resource access requests can be processed on different nodes, improving the scalability of the system and enabling it to handle more requests.

[0023] Improve the reliability of the system: By determining the second lock status corresponding to each distributed resource access request, problems such as deadlocks can be avoided, improving the reliability of the system.

[0024] Preferably, before determining that the first lock status corresponding to the batch resource access request is locked when the second lock statuses corresponding to all the distributed resource access requests are locked, the method further includes: for each of the distributed resource access requests, determining the second lock status corresponding to the distributed resource access request;

[0025] When the second lock status corresponding to the distributed resource access request is unlocked, determining the resource competition status of the distributed resource access request;

[0026] Based on the resource competition status of the distributed resource access request, determining the resource locking method corresponding to the distributed resource access request;

[0027] Based on the resource locking method corresponding to the distributed resource access request, locking a part of the split account resources corresponding to the distributed resource access request and updating the second lock status corresponding to the distributed resource access request to the locked state.

[0028] It should be noted that through the above content, the embodiments of this specification have the following beneficial effects:

[0029] Improve system efficiency: By determining the resource competition status before locking and only locking the part of the split account resources that need to be locked, unnecessary locking operations are reduced, improving the efficiency of the system. Moreover, determining the resource locking method according to the resource competition status can allocate resources more reasonably, avoid resource waste, and further improve system efficiency.

[0030] Ensure data consistency: By locking a part of the split account resources, it is ensured that only one thread or process can access and modify these resources at the same time, avoiding data conflicts and inconsistencies. Moreover, the accurate resource locking method can ensure the integrity of the data and ensure that the data will not be accidentally modified or damaged during the processing.

[0031] Enhance the scalability of the system: The above method is applicable to distributed resource access requests, can effectively manage resource locking in a distributed system, and enhances the scalability of the system. At the same time, it can handle multiple concurrent distributed resource access requests, improving the performance and response ability of the system under high concurrency.

[0032] Improve the reliability of the system: By means of reasonable resource locking and updating the lock status, the possibility of deadlock is reduced, and the reliability of the system is improved. At the same time, the stable resource locking mechanism helps to ensure the normal operation of the system in various situations and reduces system failures caused by resource competition.

[0033] Optimize the user experience: An efficient resource locking and processing method can reduce the user waiting time, improve the response speed of the system to user requests, and enhance the user experience. At the same time, ensuring data consistency and integrity enables users to obtain accurate and reliable profit sharing results, enhancing users' trust in the system.

[0034] Furthermore, locking a part of the profit sharing resources corresponding to the distributed resource access request based on the resource locking method corresponding to the distributed resource access request includes:

[0035] When the resource locking method is the first locking method, lock a part of the profit sharing resources corresponding to the distributed resource access request through a specified thread;

[0036] And / or,

[0037] When the resource locking method is the second locking method, determine the resource competition queue for the profit sharing resources corresponding to the distributed resource access request;

[0038] Put the distributed resource access request into the resource competition queue to request and wait for resource allocation;

[0039] When the profit sharing resources corresponding to the distributed resource access request are requested, lock a part of the profit sharing resources corresponding to the distributed resource access request through a specified thread.

[0040] It should be noted that through the above content, the embodiments of this specification have the following beneficial effects:

[0041] Improve resource allocation efficiency: When the resource locking method is the first locking method, directly obtain resources by locking a part of the profit sharing resources through a specified thread, avoiding competition and waiting, and improving the efficiency of resource allocation. When the resource locking method is the second locking method, put the distributed resource access request into the resource competition queue and allocate resources in a certain order, avoiding disorderly competition and improving the efficiency of resource allocation.

[0042] Ensure data consistency: By specifying that a thread locks a resource, it is ensured that only one thread can access and modify these resources at the same time, avoiding data conflicts and inconsistencies and preventing multiple requests from modifying the resource simultaneously.

[0043] Further, the step of putting the distributed resource access request into the resource competition queue and waiting for resource allocation includes:

[0044] Based on the request weight parameter corresponding to the distributed resource access request, request the allocation of the corresponding resource to be accounted for in the resource competition queue to obtain a first resource request result;

[0045] In the case where the first resource request result fails, re-obtain the current lock state corresponding to the distributed resource access request;

[0046] In the case where the current lock state corresponding to the distributed resource access request is unlocked, determine the resource request waiting time of the distributed resource access request;

[0047] Based on the resource request waiting time and the request weight parameter, re-request the allocation of the corresponding resource to be accounted for in the resource competition queue to obtain a second resource request result;

[0048] In the case where the second resource request result fails, re-obtain the current lock state and re-request the allocation of the corresponding resource to be accounted for until the resource to be accounted for corresponding to the distributed resource access request is requested.

[0049] It should be noted that the embodiments of this specification have the following beneficial effects through the above content:

[0050] Improve the fairness of resource allocation: Request the allocation of resources to be accounted for in the resource competition queue based on the request weight parameter, making the resource allocation more fair and avoiding the situation where some requests cannot obtain resources for a long time due to low weights.

[0051] Avoid deadlocks and starvation: When the resource request result fails, re-obtain the current lock state and determine the resource request waiting time, and then re-request the allocation of resources based on the waiting time and the request weight parameter, avoiding the occurrence of deadlocks and starvation and improving the stability of the system.

[0052] Improve the responsiveness of the system: By continuously re-requesting the allocation of resources until the corresponding resource to be accounted for is requested, the responsiveness of the system is improved, the waiting time of users is reduced, and the user experience is enhanced.

[0053] Preferably, the step of determining the resource request waiting time of the distributed resource access request includes:

[0054] Determine the initial retry time data corresponding to the distributed resource access request based on the user-specified waiting time corresponding to the distributed resource access request and the request weight parameter;

[0055] Determine the resource request waiting time of the distributed resource access request based on the first initial retry time in the initial retry time data;

[0056] And / or,

[0057] Determine the resource request waiting time of the distributed resource access request based on the position of the last initial retry time corresponding to the distributed resource access request in the initial retry time data;

[0058] And / or,

[0059] Obtain the historical retry time data of the request allocation resource failure based on the distributed resource access request, and generate the optimized current retry time data;

[0060] Determine the resource request waiting time of the distributed resource access request based on the first current retry time in the current retry time data.

[0061] It should be noted that the embodiments of this specification have the following beneficial effects through the above content:

[0062] Improve the flexibility of resource allocation: By determining the initial retry time data based on the user-specified waiting time and the request weight parameter, the user can set the waiting time according to their own needs and priorities, improving the flexibility of resource allocation.

[0063] Optimize the resource request waiting time: Determine the resource request waiting time based on the position of the last initial retry time in the initial retry time data, and the waiting time can be dynamically adjusted according to the previous retry situation, avoiding unnecessary waiting and improving the efficiency of resource requests.

[0064] Improve the success rate of resource allocation: By obtaining the historical retry time data and generating the optimized current retry time data, the retry time can be adjusted according to historical experience, improving the success rate of resource allocation.

[0065] Further, determining the first lock status of the resources to be settled in the electric vehicle swapping station requested by the user includes:

[0066] Store the relevant information of the electric vehicle swapping station settlement resources in a relational database, and create a lock table for managing thread locks. Each row in the lock table corresponds to an electric vehicle swapping station settlement resource, and is used to identify whether the resources corresponding to each row are locked;

[0067] Before the revenue sharing operation, check the first lock status of the resources to be revenue - shared in the electric vehicle swapping station according to the lock table.

[0068] It should be noted that the embodiments of this specification have the following beneficial effects through the above content:

[0069] Improve the accuracy of resource management: By storing the relevant information of the revenue - sharing resources of the electric vehicle swapping station in a relational database and creating a dedicated lock table to manage thread locks, it can accurately identify whether each resource is locked, avoiding resource conflicts and incorrect allocations.

[0070] Enhance the reliability of the system: Check the lock status of the resources before the revenue - sharing operation to ensure that the operation is performed only when the resources are not locked, reducing data inconsistency and errors caused by concurrent access and improving the reliability of the system.

[0071] Preferably, the method further includes:

[0072] Lock the resources to be revenue - shared in the electric vehicle swapping station during the revenue - sharing operation and update the lock status of the corresponding row in the lock table to locked;

[0073] After completing the revenue - sharing operation on the resources to be revenue - shared in the electric vehicle swapping station, update the lock status of the corresponding row in the lock table to unlocked;

[0074] And / or, the checking the first lock status of the resources to be revenue - shared in the electric vehicle swapping station according to the lock table includes:

[0075] Check whether the lock status of the resources to be revenue - shared in the electric vehicle swapping station in the lock table has been locked by other threads to obtain the lock status of the resources to be revenue - shared in the electric vehicle swapping station, and the lock status includes unlocked and locked.

[0076] It should be noted that the embodiments of this specification have the following beneficial effects through the above content:

[0077] Ensure data consistency: Lock the resources to be revenue - shared in the electric vehicle swapping station during the revenue - sharing operation, which can prevent other threads or processes from accessing or modifying the same resources before the revenue - sharing operation is completed, thus ensuring data consistency and integrity.

[0078] Prevent concurrent conflicts: By updating the lock status in the lock table, it is ensured that the resources will not be accessed simultaneously by other requests during the revenue - sharing operation, reducing data competition and conflict problems caused by concurrent operations.

[0079] Simplify resource management: Manage the lock status of resources through the lock table, which simplifies the resource management process. Developers and system administrators can easily monitor which resources are locked and the changes in the lock status.

[0080] Improve system response speed: After the profit sharing operation is completed, update the locking status of the lock table to unlocked in a timely manner, which can quickly release resources, enabling other requests to immediately access the resources, thereby improving the system's response speed and throughput.

[0081] Enhance system stability: Through the lock table mechanism, the system can operate stably under the condition of multi-user concurrent requests, reducing system crashes or errors caused by resource conflicts.

[0082] Facilitate error tracking: When the lock table records the locking status of resources, if an error or exception occurs, it is possible to quickly locate the specific locked resources, facilitating problem diagnosis and resolution.

[0083] Furthermore, if the resources to be profit-shared in the electric vehicle swapping station are locked, the method further includes:

[0084] After a preset time, re-check whether the lock status of the resources to be profit-shared in the electric vehicle swapping station in the lock table has been locked by other threads, and obtain the lock status of the resources to be profit-shared in the electric vehicle swapping station;

[0085] If the resources to be profit-shared in the electric vehicle swapping station are not locked, perform a profit sharing operation on the resources to be profit-shared in the electric vehicle swapping station through the specified thread to obtain a profit sharing result.

[0086] It should be noted that the embodiments of this specification have the following beneficial effects through the above content:

[0087] Improve the flexibility of resource allocation: If the resources to be profit-shared in the electric vehicle swapping station are locked, the method allows re-checking the lock status after a preset time. This means that even when the resources are locked, the system can immediately allocate them after the resources are unlocked, improving the flexibility of resource allocation.

[0088] Reduce waiting time: By re-checking the lock status after a preset time, the waiting time of users or the system when resources are locked can be reduced. If the resources are unlocked during the waiting period, the profit sharing operation can be immediately performed, thereby improving efficiency.

[0089] Furthermore, before performing a profit sharing operation on the resources to be profit-shared in the electric vehicle swapping station through the specified thread, the method further includes:

[0090] According to the real-time load situation of the electric vehicle swapping station, dynamically allocate the resources to be profit-shared in the electric vehicle swapping station to available threads for profit sharing operations.

[0091] It should be noted that the embodiments of this specification have the following beneficial effects through the above content:

[0092] Optimize resource utilization: By dynamically allocating the resources to be accounted for in the electric vehicle swapping station to available threads, it can ensure that resources (such as processing power) are utilized most effectively, avoiding waste of resources.

[0093] Improve response speed: By dynamically allocating resources according to the real-time load situation, it can quickly respond to the demands during high-load periods, reduce the waiting time of users, and improve the response speed of the system.

[0094] Preferably, the operation of accounting for the resources to be accounted for in the electric vehicle swapping station by specifying a thread includes:

[0095] Determine the thread resources required for the accounting operation according to the resources to be accounted for in the electric vehicle swapping station;

[0096] Create a thread group according to the required thread resources, and the thread group is used for concurrent processing of the accounting operation;

[0097] Allocate the resources to be accounted for in the electric vehicle swapping station to the corresponding threads according to the thread group and the accounting strategy, so as to perform the accounting operation on the allocated resources to be accounted for.

[0098] It should be noted that the embodiments of this specification have the following beneficial effects through the above content:

[0099] Improve processing efficiency: By determining the thread resources required for the accounting operation and creating a thread group for concurrent processing, the efficiency of the accounting operation can be significantly improved, and the overall processing time can be reduced.

[0100] Optimize resource usage: By dynamically creating a thread group according to the demand for accounting resources, it can ensure that the system resources are used most optimally, avoiding resource idleness or over-allocation.

[0101] An accounting device for an electric vehicle swapping station provided by one or more embodiments of this specification, the device includes:

[0102] A lock state determination unit, based on the user's accounting operation, determines the first lock state of the resources to be accounted for in the electric vehicle swapping station requested by the user;

[0103] Accounting operation, if the first lock state of the resources to be accounted for in the electric vehicle swapping station is unlocked, perform the accounting operation on the resources to be accounted for in the electric vehicle swapping station by specifying a thread to obtain an accounting result;

[0104] A lock state update unit, if the accounting operation on the resources to be accounted for in the electric vehicle swapping station is completed, release the locked resources and update the first lock state of the resources to be accounted for in the electric vehicle swapping station to unlocked.

[0105] A revenue sharing device for an electric vehicle swapping station provided by one or more embodiments of this specification includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein, the memory stores instructions executable by the at least one processor, and when the instructions are executed by the at least one processor, the at least one processor is enabled to: based on the revenue sharing operation of a user, determine the first lock state of the revenue sharing resources of the electric vehicle swapping station that the user requests to access; if the first lock state of the revenue sharing resources of the electric vehicle swapping station is unlocked, perform a revenue sharing operation on the revenue sharing resources of the electric vehicle swapping station through a specified thread to obtain a revenue sharing result; if after completing the revenue sharing operation on the revenue sharing resources of the electric vehicle swapping station, release the locked resources and update the first lock state of the revenue sharing resources of the electric vehicle swapping station to unlocked.

[0106] A non-volatile computer storage medium provided by one or more embodiments of this specification stores computer-executable instructions, and when the computer-executable instructions are executed by a computer, the computer is enabled to: based on the revenue sharing operation of a user, determine the first lock state of the revenue sharing resources of the electric vehicle swapping station that the user requests to access; if the first lock state of the revenue sharing resources of the electric vehicle swapping station is unlocked, perform a revenue sharing operation on the revenue sharing resources of the electric vehicle swapping station through a specified thread to obtain a revenue sharing result; if after completing the revenue sharing operation on the revenue sharing resources of the electric vehicle swapping station, release the locked resources and update the first lock state of the revenue sharing resources of the electric vehicle swapping station to unlocked.

[0107] The above at least one technical solution adopted by the embodiments of this specification can achieve the following beneficial effects:

[0108] Improve system performance: By performing a revenue sharing operation on the revenue sharing resources of the electric vehicle swapping station through a specified thread, it avoids the competition and performance bottleneck problems caused by multiple threads accessing the same resource simultaneously, and improves the efficiency of the revenue sharing operation.

[0109] Ensure data consistency: When performing a revenue sharing operation, by locking the revenue sharing resources of the electric vehicle swapping station, it avoids the situation of data inconsistency or calculation errors caused by multiple threads simultaneously performing revenue sharing operations on the accounts of the same electric vehicle, and ensures data consistency.

[0110] Avoid deadlock problems: By releasing the locked resources and updating the first lock state of the revenue sharing resources of the electric vehicle swapping station to unlocked, it avoids deadlock problems when dealing with concurrent access and ensures the normal operation of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0111] To more clearly illustrate the technical solutions in the embodiments of this specification or the prior art, the following will briefly introduce the accompanying drawings required for use in the description of the embodiments or the prior art. Obviously, the accompanying drawings in the following description are only some embodiments recorded in this specification. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings. In the drawings:

[0112] Figure 1 It is a schematic flowchart of a profit sharing method for an electric vehicle swap station provided by one or more embodiments of this specification;

[0113] Figure 2 It is a schematic flowchart of a profit sharing method for an electric vehicle swap station provided by one or more embodiments of this specification;

[0114] Figure 3 It is a schematic structural diagram of a profit sharing device for an electric vehicle swap station provided by one or more embodiments of this specification;

[0115] Figure 4 It is a schematic structural diagram of a profit sharing device for an electric vehicle swap station provided by one or more embodiments of this specification;

[0116] Figure 5 It is a schematic structural diagram of a profit sharing device for an electric vehicle swap station provided by one or more embodiments of this specification. Detailed implementation manners

[0117] The embodiments of this specification provide a profit sharing method, device, equipment and medium for an electric vehicle swap station.

[0118] To enable those skilled in the art to better understand the technical solutions in this specification, the following will clearly and completely describe the technical solutions in the embodiments of this specification in conjunction with the accompanying drawings in the embodiments of this specification. Obviously, the described embodiments are only some embodiments of this specification, rather than all embodiments. Based on the embodiments of this specification, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of this specification.

[0119] Figure 1 It is a schematic flowchart of a profit sharing method for an electric vehicle swap station provided by one or more embodiments of this specification. This process can be executed by the profit sharing system of the electric vehicle swap station. Some input parameters or intermediate results in the process allow manual intervention and adjustment to help improve accuracy.

[0120] The method flow steps of the embodiments of this specification are as follows:

[0121] S102. Store the relevant information of the revenue sharing resources of the electric vehicle swapping station in a relational database, and create a lock table for managing thread locks. Each row in the lock table corresponds to a revenue sharing resource of an electric vehicle swapping station, and is used to identify whether the resource corresponding to each row is locked.

[0122] In the embodiments of this specification, a relational database can be created to store the relevant information of the revenue sharing resources of the electric vehicle swapping station. A table can be created in the database to store the information of the revenue sharing resources of the electric vehicle swapping station, including the unique identifier of the resource, relevant data, etc. At the same time, the embodiments of this specification also need to create a lock table for managing thread locks. Each row of the lock table corresponds to a revenue sharing resource of an electric vehicle swapping station, and the following fields can be added to the table:

[0123] Resource identifier: Used to uniquely identify the revenue sharing resources of the electric vehicle swapping station.

[0124] Lock status: Used to identify whether the resource is locked, and a boolean type field or an enumeration type field can be used to represent it. When creating the lock table, insert a row of data for each revenue sharing resource of the electric vehicle swapping station, and initialize the lock status to unlocked. Ensure that the resource identifier in the lock table corresponds to the unique identifier of the revenue sharing resource of the electric vehicle swapping station in the table, so that subsequent locking and unlocking operations can correctly locate the resource. When locking or unlocking the revenue sharing resources of the electric vehicle swapping station is required, it is achieved by updating the lock status of the corresponding row in the lock table.

[0125] Through the above implementation steps, the relevant information of the revenue sharing resources of the electric vehicle swapping station can be stored in a relational database, and the status of the thread lock can be managed by creating a lock table. In this way, it can be ensured that when performing the revenue sharing operation, the lock status of the resources can be correctly managed, and multiple threads are prevented from operating on the same resource simultaneously, thereby ensuring the accuracy of the revenue sharing operation and data consistency.

[0126] S104. Before the revenue sharing operation, check the lock status of the revenue sharing resources to be divided of the electric vehicle swapping station according to the lock table.

[0127] In the embodiments of this specification, when checking the lock status of the revenue sharing resources to be divided of the electric vehicle swapping station according to the lock table, it can be checked whether the lock status of the revenue sharing resources to be divided of the electric vehicle swapping station in the lock table has been locked by other threads, and the lock status of the revenue sharing resources to be divided of the electric vehicle swapping station is obtained. The lock status includes unlocked and locked.

[0128] It should be noted that the specific implementation steps for the above content are as follows:

[0129] Obtain the unique identifier of the resource to be split (such as resource ID or other identifier). Query the "lock table" in the relational database and find the corresponding row according to the unique identifier of the resource to be split. Check the lock status field in this row to determine whether the lock status of the resource to be split has been locked by other threads. If the lock status is locked, it means that the resource to be split has been locked by other threads and the split operation cannot be performed. You can take waiting or skipping operations according to the specific situation. If the lock status is unlocked, it means that the resource to be split is available and the split operation can be performed.

[0130] Through the above implementation steps, the lock status of the resources to be split in the electric vehicle swapping station can be checked according to the lock status recorded in the "lock table". This can avoid multiple threads operating on the same resource simultaneously, ensuring the accuracy and data consistency of the split operation.

[0131] It should be noted that the embodiments of this specification can have the following beneficial effects through the above methods:

[0132] Avoid competition and performance bottlenecks: By using the lock table to check the lock status of the resources to be split in the electric vehicle swapping station, it is possible to avoid competition and performance bottleneck problems caused by multiple threads or processes accessing the same resource simultaneously. The split operation will only be executed when the resource is not locked by other threads, thus reducing the possibility of concurrent conflicts and improving the performance and throughput of the system.

[0133] Data consistency: By checking the lock status of the resources to be split in the lock table, it is possible to determine whether the resource has been locked by other threads. This can avoid multiple threads splitting the same electric vehicle account simultaneously, thus avoiding situations that may lead to data inconsistency or calculation errors and ensuring the accuracy and consistency of the split operation.

[0134] Deadlock avoidance: Traditional mutex locks may cause deadlock problems when dealing with concurrent access, while by using the lock table to manage thread locks, the occurrence of deadlocks can be effectively avoided. By checking the lock status of the resources to be split in the lock table, it is possible to determine whether the resource has been locked by other threads before performing the split operation, thus avoiding the possibility of deadlocks.

[0135] In summary, checking the lock status of the resources to be split in the electric vehicle swapping station according to the lock table has the beneficial effects of avoiding competition and performance bottlenecks, maintaining data consistency, and avoiding deadlocks. This method can effectively control the concurrent access to resources by checking the lock status of the resources to be split, improving the reliability, performance, and efficiency of the system.

[0136] Further, in one or more embodiments of this specification, if the resources to be accounted for in the electric vehicle swapping station are locked, after a preset time, re-check whether the lock status of the resources to be accounted for in the electric vehicle swapping station in the lock table has been locked by other threads to obtain the lock status of the resources to be accounted for in the electric vehicle swapping station; if the resources to be accounted for in the electric vehicle swapping station are not locked, perform an accounting operation on the resources to be accounted for in the electric vehicle swapping station through a specified thread to obtain an accounting result.

[0137] It should be noted that the specific implementation steps for the above content are as follows:

[0138] If the resources to be accounted for in the electric vehicle swapping station are locked, it means that the resources to be accounted for have been locked by other threads, and the lock status is re-checked after a preset time. After waiting for the preset time, query the "lock table" again, and find the corresponding row according to the unique identifier of the resources to be accounted for. Check the lock status field in this row again to obtain the latest lock status of the resources to be accounted for. If the lock status of the resources to be accounted for in the electric vehicle swapping station is locked, it means that the resources to be accounted for are still locked by other threads and the accounting operation cannot be performed. Operations such as waiting or skipping can be taken according to the specific situation. If the lock status of the resources to be accounted for in the electric vehicle swapping station is not locked, it means that the resources to be accounted for are available, and the accounting operation can be performed through a specified thread to obtain an accounting result.

[0139] Through the above implementation steps, the lock status of the resources to be accounted for in the electric vehicle swapping station can be checked according to the lock status recorded in the "lock table". If the resources are locked, the lock status can be re-checked after a preset time; if the resources are not locked, the accounting operation can be performed through a specified thread. This can ensure that when performing the accounting operation, the lock status of the resources can be correctly managed, avoiding multiple threads operating on the same resource simultaneously, thereby ensuring the accuracy and data consistency of the accounting operation.

[0140] It should be noted that the embodiments of this specification can have the following beneficial effects through the above methods:

[0141] Exception handling: If the resources to be accounted for in the electric vehicle swapping station have been locked by other threads, the method further includes re-checking the lock status of the resources to be accounted for in the electric vehicle swapping station after a preset time. By re-checking the lock status, it can be timely discovered whether the lock status of the resources has changed, avoiding performance losses caused by long-term waiting. This can ensure that the accounting operation can be performed in a timely manner after the resources are unlocked, improving the reliability and efficiency of the system.

[0142] Improving concurrency performance: By re-checking the lock status after a preset time, it is possible to avoid performance bottlenecks caused by resources being locked by other threads for a long time. Once it is found that the resources have been unlocked, the specified thread can immediately perform the accounting operation, improving concurrency performance and resource utilization.

[0143] Data consistency: By rechecking the lock status, it can be timely detected whether the lock status of the resource has changed. This can avoid other threads from modifying or operating on the resource during the period when the resource to be split the account is locked, ensuring data consistency.

[0144] In summary, by rechecking the lock status of the resource to be split the account after a preset time, this method can improve the concurrency performance of the system, ensure data consistency, and effectively avoid performance bottlenecks caused by resource locking. This can enhance the reliability and efficiency of the system, ensuring that the account splitting operation of the electric vehicle swapping station can proceed normally.

[0145] S106, if the resource to be split the account of the electric vehicle swapping station is not locked, perform the account splitting operation on the resource to be split the account of the electric vehicle swapping station through a specified thread to obtain the account splitting result.

[0146] In the embodiments of this specification, before performing the account splitting operation, the detailed information of the resource to be split the account, including the resource amount, account information, etc., can be obtained by querying relevant data sources (such as relational databases), and the account splitting operation is performed in a specified thread, including calculating the account splitting result, updating relevant data, etc. According to specific requirements, the account splitting result can be stored in relevant data sources, such as updating database records or generating corresponding logs.

[0147] S108, lock the resource to be split the account of the electric vehicle swapping station during the execution of the account splitting operation, and update the locking status of the corresponding row in the lock table to locked.

[0148] S110, if after completing the account splitting operation on the resource to be split the account of the electric vehicle swapping station, release the locked resource and update the locking status of the corresponding row in the lock table to unlocked.

[0149] In the embodiments of this specification, the specific implementation steps of the above S108 and S110 are as follows:

[0150] According to the needs of performing the account splitting operation, find the corresponding row in the lock table and set its locking status to locked. During the period of locking the resource, other operations are prohibited from modifying or accessing the resource. Perform the account splitting operation, calculate the account splitting amount and allocate it to the corresponding account. After the account splitting operation is completed, release the locked resource and set the locking status of the corresponding row in the lock table to unlocked. After unlocking, other operations can modify or access the resource. At the same time, regularly check the lock table. If it is found that the resource is not unlocked for a long time or an abnormal situation occurs, corresponding processing is performed, such as manual unlocking or resetting the locking status. In addition, a log recording function can be added to the monitoring system to record each operation of locking and unlocking the resource for tracking and troubleshooting problems.

[0151] Through the above implementation steps, it is possible to effectively lock the resources to be divided in the electric vehicle swapping station during the account splitting operation, and timely update the locking status of the corresponding row in the lock table. After the account splitting operation is completed, the locked resources are released, and the locking status is set to unlocked, ensuring the correct processing and security of the resources.

[0152] It should be noted that in the embodiments of this specification, a relational database and a lock table are used to manage the resources to be divided, which can achieve concurrent control of multiple threads or processes accessing the same resource simultaneously. By using the lock table to identify and manage the status of resources, it is possible to prevent multiple threads from performing account splitting operations on the same resource simultaneously, avoiding competition and data inconsistency problems. At the same time, the embodiments of this specification using the lock table can avoid the deadlock problems that may be caused by traditional mutex locks. Through the mechanism of locking and releasing resources row by row, it can be ensured that only one thread operates on each resource, avoiding the situation of waiting for each other to release the lock. Moreover, in the embodiments of this specification, by locking and releasing the resources to be divided, the competition for concurrent access can be effectively reduced, improving the performance of the system. Using a relational database to store resource information enables fast querying and updating, further improving the efficiency of the account splitting operation. In addition, in the embodiments of this specification, through the lock table, it can be ensured that when performing the account splitting operation, the corresponding resource status is correctly managed and maintained. This can avoid data inconsistency or calculation errors, ensuring the accuracy and reliability of the account splitting results.

[0153] In summary, adopting the above account splitting method for the electric vehicle swapping station can achieve beneficial effects such as concurrent control, deadlock avoidance, performance improvement, and data consistency guarantee. This can solve problems such as resource conflicts, performance bottlenecks, and data inconsistency existing in the current swapping stations during account splitting, and improve the accuracy, efficiency, and reliability of the account splitting operation.

[0154] Furthermore, before a specified thread performs an account splitting operation on the resources to be divided in the electric vehicle swapping station in one or more embodiments of this specification, the resources to be divided in the electric vehicle swapping station can be dynamically allocated to available threads for account splitting operations according to the real-time load situation of the electric vehicle swapping station.

[0155] It should be noted that the specific implementation steps for the above content are as follows:

[0156] Obtain the real-time load situation of the electric vehicle battery swapping station, including information such as the number of currently used threads and the quantity of resources to be divided. Based on the real-time load situation, determine whether there are available threads for the division operation. If there are available threads, continue to execute; if there are no available threads, wait for a period of time and then make a judgment again. According to the number of available threads, evenly distribute the resources to be divided among each available thread. Load balancing algorithms can be used for distribution, such as round-robin, weighted distribution, etc. At the same time, transfer the information of the resources to be divided assigned to each thread to the corresponding thread and start the thread to execute the division operation. During the division operation, each thread independently processes its assigned resources without competing for shared resources. And after the division operation is completed, the division results of each thread can be collected and merged. Update the corresponding account information and allocate the division results to the corresponding accounts. According to the need, summarize and statistically analyze the division results or generate a report. In addition, regularly check the status and load situation of the threads, and dynamically adjust the number of threads and the resource allocation strategy according to the actual situation. Add a logging function to the monitoring system to record the execution situation and results of each division operation for tracking and troubleshooting problems.

[0157] Through the above implementation steps, according to the real-time load situation of the electric vehicle battery swapping station, the resources to be divided can be dynamically allocated to available threads for the division operation, achieving the effective utilization of resources and the efficient execution of the division operation.

[0158] It should be noted that the embodiments of this specification may have the following beneficial effects through the above methods:

[0159] Improve the concurrency performance of the system: By dynamically allocating the resources to be divided to available threads for the division operation according to the real-time load situation of the electric vehicle battery swapping station, the concurrency performance of the system can be effectively improved. In this way, the system resources can be fully utilized, the waiting time can be reduced, and the processing speed and efficiency of the division operation can be improved.

[0160] Balance the load: By dynamically allocating the resources to be divided to available threads, the problem of load imbalance caused by excessive concentration of resources in some threads can be avoided. In this way, the computing power of the system can be fully utilized, the workload of each thread can be balanced, and the overall performance and response ability of the system can be improved.

[0161] Avoid resource competition and conflicts: By dynamically allocating the resources to be divided to available threads, the competition and conflict problems caused by multiple threads accessing the same resource simultaneously can be effectively avoided. In this way, data inconsistency and calculation errors can be avoided, and the accuracy and reliability of the division operation can be improved.

[0162] Real-time performance optimization: By performing allocation optimization based on the real-time load situation of the electric vehicle battery swapping station, the resource allocation of the accounting operation can be adjusted in a timely manner to adapt to the changes in system load. This can improve the real-time performance of the system and maintain the stability and efficient operation of the system.

[0163] In summary, by dynamically allocating the resources to be accounted to available threads for the accounting operation according to the real-time load situation of the electric vehicle battery swapping station, the concurrency performance of the system can be improved, the load can be balanced, resource competition and conflicts can be avoided, and real-time performance optimization can be achieved. This can enhance the reliability, efficiency, and responsiveness of the system, ensuring that the accounting operation of the electric vehicle battery swapping station can be carried out efficiently and accurately.

[0164] Furthermore, when one or more embodiments of this specification perform the accounting operation on the resources to be accounted for the electric vehicle battery swapping station through specified threads, the thread resources required for the accounting operation can be determined according to the resources to be accounted for the electric vehicle battery swapping station; a thread group is created according to the required thread resources, and the thread group is used for concurrent processing of the accounting operation; according to the thread group and the accounting strategy, the resources to be accounted for the electric vehicle battery swapping station are allocated to the corresponding threads to perform the accounting operation on the allocated resources to be accounted.

[0165] It should be noted that the specific implementation steps for the above content are as follows:

[0166] Determine the thread resources required for the accounting operation according to the resources to be accounted for the electric vehicle battery swapping station, including the number of threads, the size of the thread pool, etc. Create a thread group according to the required thread resources for concurrent processing of the accounting operation. According to the accounting strategy, allocate the resources to be accounted for the electric vehicle battery swapping station to the corresponding threads. Load balancing algorithms can be used for allocation, such as round-robin, weight allocation, etc. At the same time, pass the information of the resources to be accounted allocated to each thread to the corresponding thread and start the thread to perform the accounting operation. During the accounting operation, each thread independently processes its allocated resources without competing for shared resources. After the accounting operation is completed, collect the accounting results of each thread and merge them. Update the corresponding account information and allocate the accounting results to the corresponding accounts.

[0167] It should be noted that the embodiments of this specification can have the following beneficial effects through the above methods:

[0168] Concurrent processing: By determining the thread resources required for the accounting operation according to the resources to be accounted for the electric vehicle battery swapping station and creating a thread group for concurrent processing, the concurrency performance of the accounting operation can be improved. This can process multiple accounting operations simultaneously, improving the throughput and responsiveness of the system.

[0169] Resource Optimization: By allocating the resources to be accounted according to the required thread resources and the profit-sharing strategy to the corresponding threads for processing, the allocation and utilization of resources can be optimized. This can avoid over-allocation or unreasonable allocation of resources and improve the utilization efficiency of system resources.

[0170] Improve System Efficiency: By performing concurrent profit-sharing operations on the allocated resources to be accounted, the system efficiency can be improved. Multiple threads perform profit-sharing operations on different resources simultaneously, reducing the waiting time and improving the processing speed and efficiency of the profit-sharing operations.

[0171] Avoid Competition and Conflicts: By allocating the resources to be accounted according to the thread group and the profit-sharing strategy, the problem of competition and conflicts caused by multiple threads accessing the same resource simultaneously can be avoided. This can avoid data inconsistency and calculation errors and improve the accuracy and reliability of the profit-sharing operations.

[0172] In summary, by determining the thread resources required for performing the profit-sharing operation according to the resources to be accounted in the electric vehicle swapping station and using thread groups for concurrent processing, the concurrent performance and system efficiency of the profit-sharing operation can be improved, the allocation and utilization of resources can be optimized, competition and conflicts can be avoided, and the profit-sharing operation of the electric vehicle swapping station can be carried out efficiently and accurately.

[0173] Furthermore, after creating a lock table for managing thread locks in one or more embodiments of this specification, the lock table can be stored in a distributed cache, and the concurrent control of the profit-sharing resources in the electric vehicle swapping station can be implemented through a distributed lock algorithm.

[0174] It should be noted that regarding the above content, the specific implementation steps are as follows:

[0175] For the lock table, select a suitable distributed cache storage solution, such as Redis, Memcached, etc., to store the data of the lock table. According to the selected distributed cache solution, perform the corresponding installation and configuration to ensure its normal operation. Create a key-value pair in the distributed cache and store the lock table in it so that all nodes can access and share it. Select a suitable implementation method in the distributed lock algorithm, such as the distributed lock based on Redis, the distributed lock based on Zookeeper, etc.

[0176] At the same time, before executing the profit-sharing operation, try to obtain the distributed lock in the selected distributed cache to ensure that only one thread can execute the profit-sharing operation. After successful acquisition, perform the profit-sharing operation on the profit-sharing resources in the electric vehicle swapping station and update the locking status of the corresponding row in the lock table. After the profit-sharing operation is completed, release the distributed lock to allow other threads to continue to obtain the lock and execute the profit-sharing operation.

[0177] Through the above implementation steps, a lock table for managing thread locks can be created and stored in the distributed cache. The distributed lock algorithm is used to implement the concurrent control of the revenue sharing resources in the electric vehicle swapping station, ensuring the accuracy and security of the revenue sharing operation.

[0178] It should be noted that the embodiments of this specification can have the following beneficial effects through the above methods:

[0179] Improve the system performance and concurrency ability: Using the distributed cache can cache the lock table data on multiple nodes, sharing the access pressure of the lock table. The distributed lock algorithm can ensure that when multiple threads or processes access the same resource simultaneously, only one thread or process can obtain the lock, and other threads or processes need to wait. This can effectively reduce contention and avoid deadlock problems, improving the system throughput and response speed.

[0180] Guarantee data consistency and accuracy: Through the control of the distributed lock, it can be ensured that only one thread or process can perform the revenue sharing operation on the account of the same electric vehicle at the same time, avoiding the situation of data inconsistency or calculation errors. At the same time, using the distributed cache can ensure the high availability and consistency of the lock table data, avoiding single point of failure and data inconsistency problems.

[0181] Improve the efficiency of the revenue sharing operation: Since the distributed cache and the distributed lock algorithm are adopted, the lock table can be stored on the nodes closer to the users, reducing the network communication overhead and improving the efficiency and response speed of the revenue sharing operation. At the same time, the fine-grained control of the distributed lock can avoid irrelevant threads or processes blocking and waiting for the lock, improving the resource utilization rate.

[0182] In summary, adopting the distributed cache and the distributed lock algorithm to implement the concurrent control of the revenue sharing resources in the electric vehicle swapping station can improve the system performance, guarantee data consistency and accuracy, and at the same time improve the efficiency of the revenue sharing operation.

[0183] Furthermore, the revenue sharing resources in one or more embodiments of this specification of the electric vehicle swapping station include the battery swapping area information and the vehicle account information of the electric vehicle swapping station; the battery swapping area information of the electric vehicle swapping station is used to record the number of times and related information of battery replacement for each electric vehicle; the vehicle account information is used to record the consumption information of each electric vehicle using the services of the swapping station, and the consumption situation includes one or more of the recharge amount, consumption records, and balance.

[0184] It should be noted that the embodiments of this specification can have the following beneficial effects through the above methods:

[0185] Accurate revenue sharing and settlement: The vehicle account information records the consumption information of each electric vehicle using the service of the battery swapping station, including the recharge amount, consumption records, balance, etc. The battery swapping station can use this information to perform accurate revenue sharing and settlement operations, ensuring that the consumption of each electric vehicle can be accurately calculated and recorded, thus avoiding problems such as failed revenue sharing and settlement errors, and improving the accuracy and reliability of revenue sharing.

[0186] Improve the accuracy of revenue sharing: The information in the battery swapping area of the electric vehicle battery swapping station records the number of times and related information of battery replacement for each electric vehicle. By combining the information in the battery swapping area with the revenue sharing operation, the battery swapping station can accurately calculate the revenue sharing for each electric vehicle based on the number of battery replacements and related information. This can avoid revenue sharing errors caused by the lack of information in the battery swapping area and improve the accuracy and reliability of revenue sharing.

[0187] Provide the basis for revenue sharing: The information in the battery swapping area can serve as an important basis in the revenue sharing process. It can provide detailed information about the battery replacement situation of electric vehicles, such as the replacement frequency and replacement time of each vehicle. In this way, the battery swapping station can reasonably allocate and adjust the revenue sharing strategy according to the information in the battery swapping area to ensure that the usage situation of each vehicle can be reasonably revenue shared and settled.

[0188] Figure 2 A flowchart of a revenue sharing method for an electric vehicle battery swapping station provided for one or more embodiments of this specification. This process can also be executed by the revenue sharing system of the electric vehicle battery swapping station. Some input parameters or intermediate results in the process allow manual intervention and adjustment to help improve accuracy.

[0189] S202, based on the user's revenue sharing operation, determine the first lock status of the resources to be revenue shared of the electric vehicle battery swapping station requested by the user.

[0190] In the embodiments of this specification, the batch resource access request corresponding to the user's revenue sharing operation can be obtained first, and the batch resource access request can be converted into at least one distributed resource access request; determine the second lock status corresponding to each distributed resource access request; when the second lock status corresponding to all distributed resource access requests is locked, determine that the first lock status corresponding to the batch resource access request is locked.

[0191] It should be noted that for the above content, the following specific implementation solutions can be adopted:

[0192] Obtain the user's request: When the user initiates a revenue sharing operation, the system first receives the user's batch resource access request. These requests may include multiple related resources that need to be revenue shared.

[0193] Convert to Distributed Resource Access Requests: Convert the user's batch resource access requests into at least one distributed resource access request. This may involve breaking down large batch operations into small, manageable requests for processing in a distributed system.

[0194] Determine the Second Lock Status: For each distributed resource access request, the system needs to determine the corresponding second lock status. This may involve checking whether the resource has been locked by other processes or threads.

[0195] Check the Lock Status: The system traverses all distributed resource access requests and checks whether the second lock status corresponding to each request is locked. This may require using a distributed lock management mechanism such as Redis, Zookeeper, etc.

[0196] Batch Request Locking Condition: If the second lock status corresponding to all distributed resource access requests is locked, the system can proceed to the next step. If the lock status of any request is not locked, the system may need to wait, retry, or notify the user that the request has failed.

[0197] Determine the First Lock Status: Once the lock status of all distributed resource access requests is locked, the system determines that the first lock status corresponding to the batch resource access request is locked. This generally means that the batch operation can be safely executed without conflicting with other concurrent operations.

[0198] It should be noted that through the above content, the embodiments of this specification have the following beneficial effects:

[0199] Improve System Efficiency: Converting batch resource access requests into distributed resource access requests allows multiple requests to be processed in parallel, improving the system's processing efficiency.

[0200] Ensure Data Consistency: By determining the second lock status corresponding to each distributed resource access request, multiple requests accessing the same resource simultaneously can be avoided, thus ensuring data consistency.

[0201] Improve System Scalability: Distributed resource access requests can be processed on different nodes, improving the system's scalability and enabling it to handle more requests.

[0202] Improve System Reliability: By determining the second lock status corresponding to each distributed resource access request, problems such as deadlocks can be avoided, improving the system's reliability.

[0203] Further, before determining that the first lock status corresponding to the batch resource access request is locked when the second lock status corresponding to all the distributed resource access requests is locked, for each of the distributed resource access requests, the second lock status corresponding to the distributed resource access request may be determined; when the second lock status corresponding to the distributed resource access request is unlocked, the resource competition status of the distributed resource access request may be determined; based on the resource competition status of the distributed resource access request, the resource locking method corresponding to the distributed resource access request may be determined; based on the resource locking method corresponding to the distributed resource access request, a part of the split account resources corresponding to the distributed resource access request may be locked, and the second lock status corresponding to the distributed resource access request may be updated to the locked status.

[0204] It should be noted that for the above content, the following specific implementation solutions may be adopted:

[0205] Check the lock status of the distributed resource access request: For each distributed resource access request, use a distributed lock mechanism (such as Redis, Zookeeper, etc.) to determine whether the second lock status corresponding to it is locked. If it is found that the second lock status corresponding to a certain distributed resource access request is unlocked, the following steps need to be taken:

[0206] Determine the resource competition status: Check the resource competition status of this request, which usually involves checking the access of other concurrent requests to this resource.

[0207] Determine the resource locking method: According to the resource competition status, determine the most suitable resource locking method.

[0208] Lock a part of the split account resources: Use the selected resource locking method to lock a part of the split account resources corresponding to the distributed resource access request.

[0209] Update the second lock status: Once the resource is locked, update the second lock status corresponding to this request to locked.

[0210] It should be noted that through the above content, the embodiments of this specification have the following beneficial effects:

[0211] Improve system efficiency: By determining the resource competition status before locking, only the part of the split account resources that need to be locked are locked, reducing unnecessary locking operations and improving the system efficiency. Moreover, determining the resource locking method according to the resource competition status can allocate resources more reasonably, avoid resource waste, and further improve the system efficiency.

[0212] Ensure data consistency: By locking part of the profit-sharing resources, it is ensured that only one thread or process can access and modify these resources at the same time, avoiding data conflicts and inconsistencies. Moreover, the accurate resource locking method can guarantee the integrity of the data, ensuring that the data will not be accidentally modified or damaged during the processing.

[0213] Enhance the scalability of the system: The above method is applicable to distributed resource access requests and can effectively manage resource locking in a distributed system, enhancing the scalability of the system. At the same time, it can handle multiple concurrent distributed resource access requests, improving the performance and response ability of the system under high concurrency.

[0214] Improve the reliability of the system: By means of a reasonable resource locking method and updating the lock status, the possibility of deadlocks is reduced, improving the reliability of the system. At the same time, the stable resource locking mechanism helps to ensure the normal operation of the system in various situations, reducing system failures caused by resource competition.

[0215] Optimize the user experience: An efficient resource locking and processing method can reduce the user waiting time, improve the response speed of the system to user requests, and enhance the user experience. At the same time, ensuring the consistency and integrity of the data enables users to obtain accurate and reliable profit-sharing results, enhancing users' trust in the system.

[0216] Furthermore, when locking part of the profit-sharing resources corresponding to the distributed resource access request based on the resource locking method corresponding to the distributed resource access request, in the case where the resource locking method is the first locking method, the part of the profit-sharing resources corresponding to the distributed resource access request can be locked by a specified thread. In the case where the resource locking method is the second locking method, a resource competition queue for the profit-sharing resources corresponding to the distributed resource access request can be determined; the distributed resource access request is placed in the resource competition queue to request and wait for resource allocation; in the case of obtaining the profit-sharing resources corresponding to the distributed resource access request, the part of the profit-sharing resources corresponding to the distributed resource access request is locked by a specified thread.

[0217] It should be noted that for the above content, the following specific implementation plans can be adopted:

[0218] Determine the resource locking method: It is necessary to first determine the resource locking method for each distributed resource access request, which may be the first locking method or the second locking method. Determining the resource locking method for each distributed resource access request is a process involving system design decisions. The following are several methods to determine the resource locking method:

[0219] Analyze business requirements: It is necessary to understand business requirements to determine appropriate resource locking strategies. The following are the specific contents for analyzing business requirements to determine resource locking methods:

[0220] Exclusive lock (the first locking method): Applicable to scenarios where it is necessary to ensure that a resource is accessed by only one request at a certain moment. For example, updating user account information.

[0221] Shared lock (the second locking method): Applicable to scenarios where multiple requests are allowed to read the same resource simultaneously but not modify it. For example, reading user account information.

[0222] Analysis of resource characteristics: Analyze the characteristics and access patterns of resources to determine the optimal locking strategy.

[0223] Furthermore, after determining the resource locking method for each distributed resource access request, the following specific implementation plan can be adopted:

[0224] If the resource locking method is the first locking method (exclusive lock), the implementation plan is as follows:

[0225] Thread specification: Specify a thread for the distributed resource access request.

[0226] Resource locking: Use this thread to perform exclusive locking on the partial share resources corresponding to the distributed resource access request.

[0227] Lock confirmation: After confirming that the resource locking is successful, update the resource status to locked.

[0228] If the resource locking method is the second locking method (contention lock), the implementation plan is as follows:

[0229] Resource contention queue: Create a resource contention queue to manage resource access requests waiting for locking. Ensure that the queue is sorted according to a certain strategy (such as first-come, first-served, priority, etc.).

[0230] Request queuing: Put the distributed resource access request into the resource contention queue. After the request is put into the queue, wait for resource allocation.

[0231] Resource allocation: When the resource is available, take out the request from the queue for resource allocation. When allocating resources, ensure that the resource is not occupied by multiple requests simultaneously.

[0232] Thread specification: Specify a thread for the distributed resource access request. Use this thread to lock the partial share resources corresponding to the distributed resource access request.

[0233] Lock confirmation: After confirming that the resource locking is successful, update the resource status to locked. Remove the request for the allocated resource from the queue.

[0234] It should be noted that the embodiments of this specification have the following beneficial effects through the above content:

[0235] Improve resource allocation efficiency: When the resource locking method is the first locking method, by specifying a thread to lock some of the split account resources, resources can be directly obtained, avoiding competition and waiting, and improving the efficiency of resource allocation. When the resource locking method is the second locking method, the distributed resource access requests are put into the resource competition queue, and resources are allocated in a certain order, avoiding disorderly competition and improving the efficiency of resource allocation.

[0236] Ensure data consistency: By specifying a thread to lock resources, it is ensured that only one thread can access and modify these resources at the same time, avoiding data conflicts and inconsistencies, and preventing multiple requests from modifying resources simultaneously.

[0237] Furthermore, when the distributed resource access request is put into the resource competition queue to request and wait for resource allocation, based on the request weight parameter corresponding to the distributed resource access request, the corresponding to-be-split account resources can be requested for allocation in the resource competition queue to obtain a first resource request result; in the case where the first resource request result fails, the current lock state corresponding to the distributed resource access request is re-obtained; in the case where the current lock state corresponding to the distributed resource access request is unlocked, the resource request waiting time of the distributed resource access request is determined; based on the resource request waiting time and the request weight parameter, the corresponding to-be-split account resources are re-requested for allocation in the resource competition queue to obtain a second resource request result; in the case where the second resource request result fails, the current lock state is re-obtained and the corresponding to-be-split account resources are re-requested for allocation until the to-be-split account resources corresponding to the distributed resource access request are requested.

[0238] It should be noted that regarding the above content, the following specific implementation schemes can be adopted:

[0239] Initialize the resource competition queue: Create a resource competition queue to manage requests waiting for resource allocation. Ensure that the queue can be sorted by request weight or other logics for priority.

[0240] Request weight parameter: Assign a weight parameter to each distributed resource access request, which reflects the importance and urgency of the request.

[0241] Insert the request into the queue: When a distributed resource access request arrives, insert it into the resource competition queue according to its weight parameter.

[0242] The resource allocation process is as follows:

[0243] First resource request: Take out the first request from the queue (sorted by weight). Try to allocate the corresponding resources to be divided. If the request passes, subsequent operations can continue; if it fails, perform the following operations.

[0244] Re-acquire lock status: Obtain the lock status of the current distributed resource access request. If the lock status is unlocked, perform the following operations.

[0245] Calculate waiting time: Calculate the waiting time since the last request failed.

[0246] Second resource request: Based on the current waiting time and request weight parameters, re-request the allocation of the corresponding resources to be divided in the resource competition queue. If the request passes, subsequent operations can continue; if it fails, perform the following operations.

[0247] Repeat attempts: If the result of the second resource request fails, repeat the process of acquiring the lock status and re-requesting resource allocation until the request is successful or the maximum number of attempts is reached.

[0248] Resource request result processing: When the request is successful, allocate resources and update the request status to "allocated". If the request fails, the reason for failure can be recorded and processed according to policies (such as retry, degradation, etc.).

[0249] Resource release: Once the profit sharing operation is completed, release the allocated resources and remove the request from the queue.

[0250] It should be noted that through the above content, the embodiments of this specification have the following beneficial effects:

[0251] Improve the fairness of resource allocation: Request the allocation of resources to be divided in the resource competition queue based on the request weight parameters, making resource allocation more fair and avoiding the situation where some requests cannot obtain resources for a long time due to low weight.

[0252] Avoid deadlock and starvation phenomena: When the resource request result fails, re-acquire the current lock status and determine the resource request waiting time, and then re-request resource allocation based on the waiting time and request weight parameters, avoiding the occurrence of deadlock and starvation phenomena and improving the stability of the system.

[0253] Improve the responsiveness of the system: By continuously re-requesting resource allocation until the corresponding resources to be divided are requested, the responsiveness of the system is improved, the waiting time of users is reduced, and the user experience is enhanced.

[0254] Further, when determining the resource request waiting time of the distributed resource access request, the initial retry time data corresponding to the distributed resource access request may be determined based on the user-specified waiting time corresponding to the distributed resource access request and the request weight parameter; the resource request waiting time of the distributed resource access request may be determined based on the first initial retry time in the initial retry time data; and / or, the resource request waiting time of the distributed resource access request may be determined based on the position of the last initial retry time corresponding to the distributed resource access request in the initial retry time data; and / or, historical retry time data of resource request allocation failure based on the distributed resource access request may be obtained, and optimized current retry time data may be generated; the resource request waiting time of the distributed resource access request may be determined based on the first current retry time in the current retry time data.

[0255] It should be noted that regarding the above content, the following specific implementation solutions may be adopted:

[0256] 1. Determine the initial retry time data: An algorithm needs to be established to determine the initial retry time for each distributed resource access request. The following are the steps:

[0257] 1.1 User-specified waiting time: Read the user-specified waiting time, which can be directly specified by the user when making the request or a default value.

[0258] 1.2 Request weight parameter: Read the request weight parameter, which may reflect the urgency or importance of the request.

[0259] 1.3 Calculate the initial retry time: Use the user-specified waiting time and the request weight parameter to calculate the initial retry time. This may involve some mathematical models, for example: - Initial retry time = User-specified waiting time * Request weight coefficient - The request weight coefficient can be dynamically adjusted according to factors such as the historical performance of the request and the system load.

[0260] 2. Determine the resource request waiting time: Based on the initial retry time data, we can determine the resource request waiting time. The following are two possible implementation methods:

[0261] 2.1 Based on the first initial retry time: Directly use the first value in the initial retry time data as the resource request waiting time.

[0262] 2.2 Based on the position of the last initial retry time: If there is historical retry data, select an appropriate retry time as the resource request waiting time according to the position of the last initial retry time in the initial retry time data.

[0263] 3. Obtain historical retry time data: To optimize the retry strategy, historical retry time data can be utilized:

[0264] 3.1 Collect historical retry data: Collect the retry time data for each failed resource allocation request.

[0265] 3.2 Generate optimized current retry time data: Analyze the historical retry data to find effective retry time patterns, and then generate optimized current retry time data.

[0266] It should be noted that the embodiments of this specification have the following beneficial effects through the above content:

[0267] Improve the flexibility of resource allocation: By determining the initial retry time data based on the user-specified waiting time and request weight parameters, users can set the waiting time according to their own needs and priorities, improving the flexibility of resource allocation.

[0268] Optimize the resource request waiting time: Determine the resource request waiting time based on the position of the last initial retry time in the initial retry time data, and the waiting time can be dynamically adjusted according to previous retry situations, avoiding unnecessary waiting and improving the efficiency of resource requests.

[0269] Improve the success rate of resource allocation: By obtaining historical retry time data and generating optimized current retry time data, the retry time can be adjusted based on historical experience, improving the success rate of resource allocation.

[0270] S204, if the first lock status of the resources to be settled in the electric vehicle swapping station is unlocked, perform the settlement operation on the resources to be settled in the electric vehicle swapping station through a specified thread to obtain the settlement result.

[0271] S206, after completing the settlement operation on the resources to be settled in the electric vehicle swapping station, release the locked resources and update the first lock status of the resources to be settled in the electric vehicle swapping station to unlocked.

[0272] In the embodiments of this specification, the following specific implementation schemes can be adopted:

[0273] Check the lock status: Before performing the settlement operation, check whether the first lock status of the resources is unlocked through the lock mechanism.

[0274] Lock the resources: If the first lock status is unlocked, lock the resources through the lock mechanism to ensure that the resources will not be accessed by other threads during the settlement operation.

[0275] Perform the settlement operation: After the resources are locked, perform the settlement operation, which may include updating financial records, battery power allocation, etc.

[0276] Release the lock: After the profit sharing operation is completed, release the lock so that other threads can access the resource.

[0277] Process the profit sharing result: Obtain the profit sharing result and update the system status according to the result. If the profit sharing is successful, record the success information; if it fails, record the error information and consider retrying or notifying the relevant parties.

[0278] Furthermore, when determining the first lock status of the profit sharing resource of the electric vehicle swapping station requested by the user to be accessed, the relevant information of the profit sharing resource of the electric vehicle swapping station can be stored in a relational database, and a lock table for managing thread locks is created. Each row in the lock table corresponds to a profit sharing resource of an electric vehicle swapping station, and is used to identify whether the resource corresponding to each row is locked; before the profit sharing operation, check the first lock status of the profit sharing resource of the electric vehicle swapping station according to the lock table.

[0279] In the embodiments of this specification, the following specific implementation solutions can be adopted:

[0280] 1. Database design

[0281] First, two tables need to be designed: one is an information table for storing the profit sharing resources of the electric vehicle swapping station, and the other is a lock table for managing thread locks.

[0282] a. The profit sharing resource information table (`accounting_resources`) includes: `resource_id`: the primary key, uniquely identifying each resource; `resource_name`: the name or description of the resource; `resource_type`: the resource type, such as charging pile, battery, etc.; `resource_status`: the current status of the resource, such as idle, in use, maintenance, etc.

[0283] b. The lock table (`resource_locks`) includes `lock_id`: the primary key, uniquely identifying each lock; `resource_id`: the foreign key, associated with the `resource_id` in the `accounting_resources` table, indicating which resource this lock corresponds to; `is_locked`: a boolean value, indicating whether the resource is locked, 1 means locked, 0 means not locked; `locked_by`: identifying the thread or user that locks the resource.

[0284] 2. Function implementation steps

[0285] a. Database connection and operation

[0286] Connect to the database: Use an appropriate database connection library (such as MySQL, PostgreSQL, etc.) to connect to the database.

[0287] Query resource information: According to the user request, query the detailed information of the corresponding resource in the ˋaccounting_resourcesˋ table.

[0288] b. Check the lock status

[0289] Query the lock table: According to the ˋresource_idˋ of the resource to be operated, query the corresponding lock status in the ˋresource_locksˋ table.

[0290] Judge the lock status: Check the ˋis_lockedˋ field. If it is 1, it means the resource is locked. At this time, it is necessary to process according to the business logic (such as waiting, reporting an error, etc.).

[0291] c. Set the lock

[0292] Set the lock status: If the resource is not locked (ˋis_lockedˋ is 0), set ˋis_lockedˋ to 1 and record

[0293] the ˋlocked_byˋ information.

[0294] Update the lock table: Write the new lock status into the ˋresource_locksˋ table.

[0295] d. Profit sharing operation

[0296] Execute profit sharing: After the resource is locked, execute the corresponding profit sharing operation.

[0297] e. Release the lock

[0298] Release the lock status: After the profit sharing operation is completed, reset the ˋis_lockedˋ field to 0 and clear the ˋlocked_byˋ information.

[0299] Update the lock table: Update the released lock status to the ˋresource_locksˋ table.

[0300] 3. Exception handling

[0301] When querying or operating the database, exception handling should be considered to ensure the robustness of the program.

[0302] When processing user requests, problems such as resource lock timeout and concurrent conflicts need to be considered.

[0303] Through the above steps, we can determine the first lock status of the profit-sharing resources of the electric vehicle swapping station accessed by the user request, and check the first lock status of the profit-sharing resources of the electric vehicle swapping station according to the lock table before the profit-sharing operation.

[0304] It should be noted that the embodiments of this specification have the following beneficial effects through the above content:

[0305] Improve the accuracy of resource management: By storing the relevant information of the accounting resources of the electric vehicle swapping station in a relational database and creating a dedicated lock table to manage thread locks, it is possible to accurately identify whether each resource is locked, avoiding resource conflicts and incorrect allocations.

[0306] Enhance the reliability of the system: Check the lock status of the resources before the accounting operation to ensure that the operation is only performed when the resources are not locked, reducing data inconsistency and errors caused by concurrent access and improving the reliability of the system.

[0307] Furthermore, in the embodiments of this specification, during the execution of the accounting operation, the resources to be accounted for in the electric vehicle swapping station are locked, and the lock status of the corresponding row in the lock table is updated to locked; if the accounting operation for the resources to be accounted for in the electric vehicle swapping station is completed, the lock status of the corresponding row in the lock table is updated to unlocked; and / or, when checking the first lock status of the resources to be accounted for in the electric vehicle swapping station according to the lock table, it is possible to check whether the lock status of the resources to be accounted for in the electric vehicle swapping station in the lock table has been locked by other threads to obtain the lock status of the resources to be accounted for in the electric vehicle swapping station, and the lock status includes unlocked and locked.

[0308] It should be noted that the embodiments of this specification have the following beneficial effects through the above content:

[0309] Ensure data consistency: Locking the resources to be accounted for in the electric vehicle swapping station during the execution of the accounting operation can prevent other threads or processes from accessing or modifying the same resources before the accounting operation is completed, thus ensuring the consistency and integrity of the data.

[0310] Prevent concurrent conflicts: By updating the lock status in the lock table, it is ensured that the resources will not be accessed simultaneously by other requests during the accounting operation, reducing data competition and conflict problems caused by concurrent operations.

[0311] Simplify resource management: Manage the lock status of resources through the lock table, simplifying the resource management process. Developers and system administrators can easily monitor which resources are locked and the changes in the lock status.

[0312] Improve the system response speed: After the accounting operation is completed, promptly update the lock status in the lock table to unlocked, which can quickly release the resources, enabling other requests to access the resources immediately, thereby improving the system response speed and throughput.

[0313] Enhance system stability: Through the mechanism of locking tables, the system can operate stably under the condition of multi-user concurrent requests, reducing system crashes or errors caused by resource conflicts.

[0314] Facilitate error tracking: When the lock table records the locking status of resources, if an error or exception occurs, it is possible to quickly locate the specific locked resources, facilitating problem diagnosis and solution.

[0315] Furthermore, if the resources to be settled accounts for the electric vehicle swapping station are locked, after a preset time, re-check whether the lock status of the resources to be settled accounts for the electric vehicle swapping station in the lock table has been locked by other threads, and obtain the lock status of the resources to be settled accounts for the electric vehicle swapping station; if the resources to be settled accounts for the electric vehicle swapping station are not locked, perform the account settlement operation on the resources to be settled accounts for the electric vehicle swapping station through the specified thread to obtain the account settlement result.

[0316] It should be noted that the embodiments of this specification have the following beneficial effects through the above content:

[0317] Improve the flexibility of resource allocation: If the resources to be settled accounts for the electric vehicle swapping station are locked, the method allows re-checking the lock status after a preset time. This means that even when the resources are locked, the system can allocate them immediately after the resources are unlocked, improving the flexibility of resource allocation.

[0318] Reduce waiting time: By re-checking the lock status after a preset time, the waiting time of users or the system when resources are locked can be reduced. If the resources are unlocked during the waiting period, the account settlement operation can be performed immediately, thus improving efficiency.

[0319] Furthermore, before performing the account settlement operation on the resources to be settled accounts for the electric vehicle swapping station through the specified thread, the resources to be settled accounts for the electric vehicle swapping station can be dynamically allocated to available threads for the account settlement operation according to the real-time load situation of the electric vehicle swapping station.

[0320] It should be noted that the embodiments of this specification have the following beneficial effects through the above content:

[0321] Optimize resource utilization: By dynamically allocating the resources to be settled accounts for the electric vehicle swapping station to available threads, it can ensure that resources (such as processing capabilities) are utilized most effectively, avoiding resource waste.

[0322] Improve response speed: Dynamically allocating resources according to the real-time load situation can quickly respond to the demands during high-load periods, reduce user waiting time, and improve the response speed of the system.

[0323] Further, when the embodiment of this specification performs the accounting operation on the resources to be accounted for in the electric vehicle swapping station through a specified thread, it can determine the thread resources required for the accounting operation according to the resources to be accounted for in the electric vehicle swapping station; create a thread group according to the required thread resources, and the thread group is used for concurrent processing of the accounting operation; and allocate the resources to be accounted for in the electric vehicle swapping station to the corresponding threads according to the thread group and the accounting strategy, so as to perform the accounting operation on the allocated resources to be accounted for.

[0324] It should be noted that the embodiment of this specification has the following beneficial effects through the above content:

[0325] Improve processing efficiency: By determining the thread resources required for the accounting operation and creating a thread group for concurrent processing, the efficiency of the accounting operation can be significantly improved, and the overall processing time can be reduced.

[0326] Optimize resource utilization: Dynamically creating a thread group according to the requirements of the accounting resources can ensure that the system resources are optimally utilized, avoiding resource idleness or over-allocation.

[0327] It should be noted that the embodiment of this specification can solve the performance and deadlock problems encountered in concurrent batch operations. In batch operations, multiple threads or processes may access the same resource simultaneously, resulting in competition and performance bottlenecks. At the same time, if a traditional single-lock mechanism, such as a mutex lock, is used, it may lead to deadlock problems and make the system unable to work properly.

[0328] It should be noted that the embodiment of this specification proposes an implementation of a batch distributed lock based on the accounting management operation. In this scheme, the accounting submission operation is used as the basis for locking resources. Specifically, each resource has a unique identifier, such as the ID or name of the resource. When multiple threads or processes need to access the same resource, they will first perform an asset inventory operation to check whether the resource has been locked by other threads or processes. If the resource has been locked, the current thread or process needs to wait until the resource is released. If the resource is not locked, the current thread or process can continue to execute the operation and lock the resource during the execution.

[0329] By using the implementation of the batch distributed lock based on the accounting management operation, multiple threads or processes can be prevented from accessing the same resource simultaneously, thereby improving the concurrent processing ability of the system. In addition, this scheme can also effectively solve the deadlock problem that may be caused by a single lock, because each resource is independently locked and will not conflict with the locking status of other resources.

[0330] In summary, this implementation scheme can effectively improve the performance and stability of the system, especially in the case of high concurrency and large-scale operations.

[0331] It should be noted that a solution in the embodiments of this specification is to adopt a segmented lock mechanism. That is, multiple sub-bill detail data are divided into several small batches for processing. Each small batch can independently lock, perform operations, and release the lock. This can avoid the deadlock problem caused by simultaneously operating on multiple sub-bill details. Additionally, an optimistic lock based on version numbers can also be adopted to parallelize the operations, thereby improving the efficiency of concurrent processing.

[0332] It should be noted that the batch lock mechanism is a method for solving the competition problem of concurrent operations on batch resources. When synchronously submitting a large amount of data concurrently, if a method of obtaining multiple locks individually is used, it is prone to lock competition problems, resulting in the writing of dirty data and also reducing the performance of the program. The batch lock mechanism effectively avoids the lock competition problem by obtaining the locks of multiple resources at once. In addition, the batch lock mechanism can also ensure that the business integration code is non-invasive, that is, the business logic does not need to be modified.

[0333] It should be noted that compared with the method of obtaining multiple locks individually, the batch lock mechanism has higher performance. Especially when dealing with a large number of resources, the performance advantage of the batch lock mechanism is more obvious. In addition, the batch lock mechanism also solves the deadlock waiting problem that may occur when concurrently obtaining batch lock resources once, thereby improving the reliability and performance of the program.

[0334] Figure 3 FIG. is a schematic structural diagram of a sub-billing device for an electric vehicle swapping station provided for one or more embodiments of this specification. The device includes: a storage creation unit 202, an inspection unit 204, a sub-billing unit 206, a first update unit 208, and a second update unit 210.

[0335] The storage creation unit 202 stores the relevant information of the sub-billing resources of the electric vehicle swapping station in a relational database and creates a lock table for managing thread locks. Each row in the lock table corresponds to a sub-billing resource of the electric vehicle swapping station and is used to identify whether the resource corresponding to each row is locked; the inspection unit 204 checks the lock status of the sub-billing resources of the electric vehicle swapping station to be sub-billed according to the lock table before the sub-billing operation; the sub-billing unit 206, if the sub-billing resources of the electric vehicle swapping station to be sub-billed are not locked, performs a sub-billing operation on the sub-billing resources of the electric vehicle swapping station through a specified thread to obtain a sub-billing result; the first update unit 208 locks the sub-billing resources of the electric vehicle swapping station to be sub-billed during the sub-billing operation and updates the lock status of the corresponding row in the lock table to locked; the second update unit 210, if the sub-billing operation on the sub-billing resources of the electric vehicle swapping station to be sub-billed is completed, releases the locked resources and updates the lock status of the corresponding row in the lock table to unlocked.

[0336] Figure 4A profit-sharing device for an electric vehicle swapping station provided for one or more embodiments of this specification, the device comprising: a lock status determination unit 402, a profit-sharing operation 404, and a lock status update unit 406.

[0337] The lock status determination unit 402 determines a first lock status of the profit-sharing resources of the electric vehicle swapping station that the user requests to access based on the user's profit-sharing operation; the profit-sharing operation 404, if the first lock status of the profit-sharing resources of the electric vehicle swapping station is unlocked, performs a profit-sharing operation on the profit-sharing resources of the electric vehicle swapping station through a specified thread to obtain a profit-sharing result; the lock status update unit 406, if after completing the profit-sharing operation on the profit-sharing resources of the electric vehicle swapping station, releases the locked resources and updates the first lock status of the profit-sharing resources of the electric vehicle swapping station to unlocked.

[0338] Figure 5 A schematic structural diagram of a profit-sharing device for an electric vehicle swapping station provided for one or more embodiments of this specification, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to: store information related to the profit-sharing resources of the electric vehicle swapping station in a relational database and create a lock table for managing thread locks, each row in the lock table corresponding to a profit-sharing resource of the electric vehicle swapping station for identifying whether the resources corresponding to each row are locked; before the profit-sharing operation, check the lock status of the profit-sharing resources of the electric vehicle swapping station to be divided according to the lock table; if the profit-sharing resources of the electric vehicle swapping station to be divided are not locked, perform a profit-sharing operation on the profit-sharing resources of the electric vehicle swapping station to be divided through a specified thread to obtain a profit-sharing result; lock the profit-sharing resources of the electric vehicle swapping station to be divided during the profit-sharing operation and update the locking status of the corresponding row in the lock table to locked; if after completing the profit-sharing operation on the profit-sharing resources of the electric vehicle swapping station to be divided, release the locked resources and update the locking status of the corresponding row in the lock table to unlocked.

[0339] A revenue sharing device for an electric vehicle battery swapping station provided by one or more embodiments of this specification includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein, the memory stores instructions executable by the at least one processor, and when the instructions are executed by the at least one processor, the at least one processor is enabled to: based on a revenue sharing operation of a user, determine a first lock state of the revenue sharing resources of the electric vehicle battery swapping station that the user requests to access; if the first lock state of the revenue sharing resources of the electric vehicle battery swapping station is unlocked, perform a revenue sharing operation on the revenue sharing resources of the electric vehicle battery swapping station through a specified thread to obtain a revenue sharing result; if after completing the revenue sharing operation on the revenue sharing resources of the electric vehicle battery swapping station, release the locked resources and update the first lock state of the revenue sharing resources of the electric vehicle battery swapping station to unlocked.

[0340] A non-volatile computer storage medium provided by one or more embodiments of this specification stores computer-executable instructions, and when the computer-executable instructions are executed by a computer, they are enabled to: store the relevant information of the revenue sharing resources of the electric vehicle battery swapping station in a relational database, and create a lock table for managing thread locks, where each row in the lock table corresponds to a revenue sharing resource of the electric vehicle battery swapping station and is used to identify whether the resources corresponding to each row are locked; before the revenue sharing operation, check the lock state of the revenue sharing resources of the electric vehicle battery swapping station to be shared according to the lock table; if the revenue sharing resources of the electric vehicle battery swapping station to be shared are not locked, perform a revenue sharing operation on the revenue sharing resources of the electric vehicle battery swapping station to be shared through a specified thread to obtain a revenue sharing result; lock the revenue sharing resources of the electric vehicle battery swapping station to be shared during the revenue sharing operation and update the locked state of the corresponding row in the lock table to locked; if after completing the revenue sharing operation on the revenue sharing resources of the electric vehicle battery swapping station to be shared, release the locked resources and update the locked state of the corresponding row in the lock table to unlocked.

[0341] A non-volatile computer storage medium provided by one or more embodiments of this specification stores computer-executable instructions, and when the computer-executable instructions are executed by a computer, they are enabled to: based on a revenue sharing operation of a user, determine a first lock state of the revenue sharing resources of the electric vehicle battery swapping station that the user requests to access; if the first lock state of the revenue sharing resources of the electric vehicle battery swapping station is unlocked, perform a revenue sharing operation on the revenue sharing resources of the electric vehicle battery swapping station through a specified thread to obtain a revenue sharing result; if after completing the revenue sharing operation on the revenue sharing resources of the electric vehicle battery swapping station, release the locked resources and update the first lock state of the revenue sharing resources of the electric vehicle battery swapping station to unlocked.

[0342] Each embodiment in this specification is described in a progressive manner. For the same or similar parts among the embodiments, reference can be made to each other, and the key point of each embodiment is to illustrate the differences from other embodiments. In particular, for the embodiments of the apparatus, device, and non-volatile computer storage medium, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments.

[0343] The specific embodiments of this specification have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve the desired results. Additionally, the processes depicted in the figures do not necessarily require the particular order or sequential order shown to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0344] The above description is only for one or more embodiments of this specification and is not intended to limit this specification. For those skilled in the art, various changes and modifications can be made to one or more embodiments of this specification. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of one or more embodiments of this specification shall be included within the scope of the claims of this specification.

Claims

1. A method for sharing accounts of an electric vehicle swapping station, characterized in that, The method includes: Based on the user's profit sharing operation, determining a first lock state of the profit sharing resources to be accessed by the user in the electric vehicle swapping station; If the first lock state of the profit sharing resources to be accessed by the user in the electric vehicle swapping station is unlocked, performing a profit sharing operation on the profit sharing resources to be accessed by the user in the electric vehicle swapping station through a specified thread to obtain a profit sharing result; After completing the profit sharing operation on the profit sharing resources to be accessed by the user in the electric vehicle swapping station, releasing the locked resources and updating the first lock state of the profit sharing resources to be accessed by the user in the electric vehicle swapping station to unlocked.

2. The revenue sharing method of the electric vehicle swapping station according to claim 1, wherein The determining the first lock state of the profit sharing resources to be accessed by the user in the electric vehicle swapping station includes: Obtaining a batch resource access request corresponding to the user's profit sharing operation and converting the batch resource access request into at least one distributed resource access request; Determining a second lock state corresponding to each of the distributed resource access requests; When the second lock states corresponding to all the distributed resource access requests are locked, determining that the first lock state corresponding to the batch resource access request is locked; Preferably, before determining that the first lock state corresponding to the batch resource access request is locked when the second lock states corresponding to all the distributed resource access requests are locked, the method further includes: for each of the distributed resource access requests, determining the second lock state corresponding to the distributed resource access request; When the second lock state corresponding to the distributed resource access request is unlocked, determining the resource competition state of the distributed resource access request; Based on the resource competition state of the distributed resource access request, determining the resource locking method corresponding to the distributed resource access request; Based on the resource locking method corresponding to the distributed resource access request, locking a part of the profit sharing resources corresponding to the distributed resource access request and updating the second lock state corresponding to the distributed resource access request to the locked state.

3. The revenue sharing method of the electric vehicle swapping station according to claim 2, wherein The locking a part of the profit sharing resources corresponding to the distributed resource access request based on the resource locking method corresponding to the distributed resource access request includes: When the resource locking method is the first locking method, locking a part of the profit sharing resources corresponding to the distributed resource access request through a specified thread; And / or When the resource locking method is the second locking method, determining a resource competition queue for the profit sharing resources to be accessed corresponding to the distributed resource access request; Putting the distributed resource access request into the resource competition queue to request and wait for resource allocation; When the profit sharing resources to be accessed corresponding to the distributed resource access request are requested, locking a part of the profit sharing resources corresponding to the distributed resource access request through a specified thread.

4. The revenue sharing method of the electric vehicle swapping station according to claim 3, wherein The putting the distributed resource access request into the resource competition queue to request and wait for resource allocation includes: Based on the request weight parameter corresponding to the distributed resource access request, requesting to allocate the corresponding profit sharing resources to be accessed in the resource competition queue to obtain a first resource request result; When the first resource request result fails, re-obtaining the current lock state corresponding to the distributed resource access request; When the current lock state corresponding to the distributed resource access request is unlocked, determine the resource request waiting time of the distributed resource access request; Based on the resource request waiting time and the request weight parameter, re-request the corresponding to-be-settled accounts resource in the resource competition queue to obtain a second resource request result; When the second resource request result fails, re-obtain the current lock state and re-request the corresponding to-be-settled accounts resource until the to-be-settled accounts resource corresponding to the distributed resource access request is requested; Preferably, determining the resource request waiting time of the distributed resource access request includes: Based on the user-specified waiting time corresponding to the distributed resource access request and the request weight parameter, determine the initial retry time data corresponding to the distributed resource access request; Based on the first initial retry time in the initial retry time data, determine the resource request waiting time of the distributed resource access request; and / or Based on the position of the last initial retry time corresponding to the distributed resource access request in the initial retry time data, determine the resource request waiting time of the distributed resource access request; and / or Obtain the historical retry time data of failed resource request allocation based on the distributed resource access request, and generate optimized current retry time data; Based on the first current retry time in the current retry time data, determine the resource request waiting time of the distributed resource access request.

5. The revenue sharing method for an electric vehicle battery swapping station according to claim 1, wherein Determine the first lock state of the to-be-settled accounts resource of the electric vehicle swapping station requested by the user, including: Store the relevant information of the electric vehicle swapping station's settled accounts resource in a relational database, and create a lock table for managing thread locks. Each row in the lock table corresponds to an electric vehicle swapping station's settled accounts resource, and is used to identify whether the resources corresponding to each row are locked; Before the settlement operation, check the first lock state of the to-be-settled accounts resource of the electric vehicle swapping station according to the lock table; Preferably, the method further includes: Lock the to-be-settled accounts resource of the electric vehicle swapping station during the settlement operation, and update the locking state of the corresponding row in the lock table to locked; If the settlement operation on the to-be-settled accounts resource of the electric vehicle swapping station is completed, update the locking state of the corresponding row in the lock table to unlocked; and / or, the checking the first lock state of the to-be-settled accounts resource of the electric vehicle swapping station according to the lock table includes: Check whether the lock state of the to-be-settled accounts resource of the electric vehicle swapping station in the lock table has been locked by other threads to obtain the lock state of the to-be-settled accounts resource of the electric vehicle swapping station, and the lock state includes unlocked and locked.

6. The revenue sharing method of the electric vehicle swapping station according to claim 5, wherein If the to-be-settled accounts resource of the electric vehicle swapping station is locked, the method further includes: After a preset time, re-check whether the lock state of the to-be-settled accounts resource of the electric vehicle swapping station in the lock table has been locked by other threads to obtain the lock state of the to-be-settled accounts resource of the electric vehicle swapping station; If the to-be-settled accounts resource of the electric vehicle swapping station is unlocked, perform a settlement operation on the to-be-settled accounts resource of the electric vehicle swapping station through the specified thread to obtain a settlement result.

7. The revenue sharing method of the electric vehicle swapping station according to claim 1, wherein Before performing the accounting operation on the resources to be accounted for in the electric vehicle swapping station by specifying a thread, the method further includes: Dynamically allocate the resources to be accounted for in the electric vehicle swapping station to available threads for the accounting operation according to the real-time load condition of the electric vehicle swapping station; Preferably, performing the accounting operation on the resources to be accounted for in the electric vehicle swapping station by specifying a thread includes: Determine the thread resources required for performing the accounting operation according to the resources to be accounted for in the electric vehicle swapping station; Create a thread group according to the required thread resources, where the thread group is used for concurrent processing of the accounting operation; According to the thread group and the accounting strategy, allocate the resources to be accounted for in the electric vehicle swapping station to the corresponding threads to perform the accounting operation on the allocated resources to be accounted for.

8. A revenue sharing device for an electric vehicle battery swapping station, characterized in that, The device includes: A lock state determination unit, which determines the first lock state of the resources to be accounted for in the electric vehicle swapping station requested by the user to be accessed based on the user's accounting operation; An accounting operation, if the first lock state of the resources to be accounted for in the electric vehicle swapping station is unlocked, perform the accounting operation on the resources to be accounted for in the electric vehicle swapping station by specifying a thread to obtain an accounting result; A lock state update unit, if after completing the accounting operation on the resources to be accounted for in the electric vehicle swapping station, release the locked resources and update the first lock state of the resources to be accounted for in the electric vehicle swapping station to unlocked.

9. A revenue sharing device for an electric vehicle battery swapping station, characterized in that, Includes: At least one processor; And, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can implement the accounting method of the electric vehicle swapping station according to any one of 1-7.

10. A non-volatile computer storage medium, characterized in that, Stores computer-executable instructions, and when the computer-executable instructions are executed by a computer, they can implement the accounting method of the electric vehicle swapping station according to any one of 1-7.

Images