Method, device and equipment for checking assets of battery swap station and medium

Abstract

The embodiment of the invention discloses a battery swap station asset checking method, device and equipment and a medium, and the method comprises the steps: obtaining a batch lock of a target region through a distributed lock service when the asset checking is carried out on the target region of a battery swap station, and recording the state of the batch lock of the target region as a holding lock; and performing asset detail data checking on the target area according to the batch lock. According to the embodiment of the invention, the batch locks of the target area are obtained by using the distributed lock service, so that the same area is ensured not to be modified by other users at the same time during the checking operation, and the problem of writing dirty data is avoided.

Description

[0001] This application claims priority based on the invention patent application filed with the China National Intellectual Property Administration on December 29, 2023, with the application number 202311867345.2 and the invention title "Inventory Method, Device, Equipment and Medium for Battery Swap Station Assets". The entire content 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 an inventory method, device, equipment and medium for battery swap station assets. Background Art

[0003] With the continuous development of the electric vehicle industry, the number of electric vehicle battery swap stations has also been increasing. As an important place for electric vehicle battery replacement, the digital management of station assets has become increasingly important. The role of resource inventory in an electric vehicle battery swap station is to accurately record and update important information such as the battery inventory quantity, battery type, and battery capacity in the swap station. This information is crucial for the normal operation and management decision-making of the battery swap station. Through resource inventory, station managers can timely grasp the battery stock situation and carry out inventory management, production scheduling, and supply and demand forecasting. At the same time, resource inventory also helps to ensure the quality and safety of batteries, timely detect and update aging, damaged, or ineffective batteries, and provide efficient and reliable charging and battery swapping services.

[0004] However, in the prior art, when a large number of data concurrent inventory operations need to be synchronized, there will be a problem of concurrent write dirty data, that is, when multiple users perform inventory operations on the same resource simultaneously, it may lead to data conflicts and chaos, thereby affecting the accuracy and reliability of the inventory results. Summary of the Invention

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

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

[0007] An inventory method for battery swap station assets provided by one or more embodiments of this specification includes:

[0008] When conducting an asset inventory of the target area of the battery swap station, obtain a batch lock for the target area through a distributed lock service and record the batch lock status of the target area as holding the lock;

[0009] Conduct an asset detail data inventory of the target area according to the batch lock.

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

[0011] Avoid concurrent write of dirty data: By using the distributed lock service to obtain the batch locks for the target area, it is ensured that during the inventory operation, the same area will not be modified by other users simultaneously, thus avoiding the problem of writing dirty data.

[0012] Improve data accuracy: Due to the batch lock mechanism, each user can only read the data in the current locked state during the inventory, which can ensure the accuracy of the inventory data because it is not affected by other concurrent operations.

[0013] Enhance data reliability: Using batch locks can prevent data conflicts and chaos, improve the reliability of data processing, and ensure the stability and credibility of the inventory results.

[0014] Optimize concurrent processing ability: While holding the lock, batch data inventory can be performed on the target area, which can improve the inventory efficiency and reduce the time waste caused by concurrent operations.

[0015] Furthermore, when performing an asset inventory on the target area of the battery swapping station, obtaining the batch lock for the target area through the distributed lock service includes:

[0016] When performing an asset inventory on the target area of the battery swapping station, determine the batch resource access request corresponding to the target area;

[0017] Convert the batch resource access request into at least one distributed resource access request, and determine the distributed lock status corresponding to each distributed resource access request;

[0018] When the distributed lock status corresponding to all the distributed resource access requests is locked, obtain the batch lock corresponding to the target area.

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

[0020] Prevent data concurrent conflicts: Through the distributed lock service, it is ensured that the data in the target area will not be modified by other concurrent operations during the inventory, thus avoiding data inconsistency and conflicts.

[0021] Improve data consistency: Before obtaining the batch lock, ensure that all relevant distributed resource access requests have been locked, which guarantees the integrity of the data during the inventory process.

[0022] Enhance data accuracy: Since other operations are locked during the inventory, users can obtain consistent and unmodified data, which improves the accuracy of the inventory results.

[0023] Simplify concurrent control logic: Convert batch resource access requests into distributed resource access requests and manage the lock status of each request, which simplifies the concurrent control logic and makes the system design clearer.

[0024] Preferably, before obtaining the batch lock corresponding to the target area when the distributed lock statuses corresponding to all the distributed resource access requests are locked, the method further includes:

[0025] For each of the distributed resource access requests, determine the distributed lock status corresponding to the distributed resource access request;

[0026] When the distributed lock status corresponding to the distributed resource access request is unlocked, determine the resource competition status of the distributed resource access request;

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

[0028] Based on the resource locking method corresponding to the distributed resource access request, lock the partial inventory resources corresponding to the distributed resource access request and update the distributed lock status corresponding to the distributed resource access request to the locked state.

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

[0030] Fine-grained resource management: By determining the status and evaluating the resource competition status of each distributed resource access request, more fine-grained resource management can be achieved, improving resource utilization efficiency.

[0031] Dynamic resource locking strategy: According to the resource competition status, the resource locking method can be dynamically determined, which helps to adopt more effective locking strategies when resources are scarce and reduce resource contention.

[0032] Optimize performance: By selecting the locking method, unnecessary lock waiting time can be reduced, thereby optimizing the system performance and improving the efficiency of the inventory operation.

[0033] Improve data integrity: Before locking a specific resource, ensure that its lock status is unlocked, which helps to prevent data from being modified by other operations during the inventory process and guarantees data integrity.

[0034] Further, the locking of the partial inventory 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, a specified thread locks a part of the inventory resources corresponding to the distributed resource access request;

[0036] and / or,

[0037] When the resource locking method is the second locking method, determine the resource competition queue for the inventory 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 inventory resources corresponding to the distributed resource access request are requested, a specified thread locks a part of the inventory resources corresponding to the distributed resource access request.

[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, a specified thread locks a part of the inventory resources, and 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 request is put into the resource competition queue, and resources are allocated in a certain order, avoiding disorderly competition and improving the efficiency of resource allocation.

[0042] Ensure data consistency: By locking resources with a specified thread, 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.

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

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

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

[0046] 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;

[0047] Based on the resource request waiting time and the request weight parameter, re-request the allocation of the corresponding resources to be inventoried 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 resources to be inventoried until the resources to be inventoried corresponding to the distributed resource access request are 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 inventoried in the resource competition queue based on the request weight parameter, making 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 resources to be inventoried are requested, the responsiveness of the system is improved, the waiting time of users is reduced, and the user experience is enhanced.

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

[0054] 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;

[0055] 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;

[0056] And / or,

[0057] 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;

[0058] And / or,

[0059] Obtain the historical retry time data of the request for resource allocation failure based on the distributed resource access request, and generate 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 request weight parameters, users 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 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.

[0065] Furthermore, before conducting an asset inventory of the target area of the battery swapping station, the method further includes:

[0066] Divide the battery swapping station into multiple areas according to business needs and the characteristics of the battery swapping station;

[0067] Create a regional lock table in a preset database to record the batch lock status of each area through the regional lock table;

[0068] Create a distributed lock service to acquire and release the batch locks of each area through the distributed lock service;

[0069] and / or

[0070] Recording the batch lock status of the target area as holding a lock includes: recording the batch lock status of the target area as holding a lock in the regional lock table.

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

[0072] Improve the inventory efficiency: By dividing the battery swapping station into multiple areas, the inventory work can be organized more efficiently, making the inventory process more orderly and reducing unnecessary time and resource waste.

[0073] Enhance resource management: Creating a regional lock table and a distributed lock service enables effective management of the batch lock status of the battery swapping station, helping to avoid data conflicts and ensuring the accuracy of inventory data.

[0074] Simplified lock management: The use of the regional lock table and the distributed lock service simplifies the lock management process, making the operations of acquiring and releasing locks more automated and standardized.

[0075] Improved data consistency: By recording the batch lock status as held, it is ensured that during the inventory process, resources in the same area will not be modified by other operations, thus guaranteeing data consistency.

[0076] Furthermore, acquiring the batch lock for the target area through the distributed lock service includes:

[0077] Initiating an acquisition request for the batch lock of the target area by calling the distributed lock service;

[0078] Querying the batch lock status of the target area in the regional lock table according to the acquisition request;

[0079] If the batch lock status of the target area is unlocked, acquire the batch lock for the target area;

[0080] And / or,

[0081] If the batch lock status of the target area is locked, the method further includes:

[0082] After a preset time, initiate a new acquisition request for the batch lock of the target area by calling the distributed lock service;

[0083] Querying the batch lock status of the target area in the regional lock table according to the newly initiated acquisition request;

[0084] If the batch lock status of the target area is unlocked, acquire the batch lock for the target area.

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

[0086] Guaranteed data consistency: Through the distributed lock service, it is ensured that during batch operations in the target area, the data will not be modified by other concurrent operations, thus maintaining data consistency.

[0087] Avoided concurrent conflicts: Acquiring the lock when the batch lock is unlocked can prevent multiple operations from accessing the same resource simultaneously, reducing the risk of concurrent conflicts and data inconsistency.

[0088] Improved system responsiveness: When the batch lock is locked by other operations, the system does not fail immediately but waits for a period of time and then retries to acquire the lock, which improves the system's responsiveness and user experience.

[0089] Enhance the fault tolerance of the system: If an operation fails to acquire a lock, the system can automatically attempt to reacquire the lock, which enhances the fault tolerance of the system.

[0090] Optimize resource utilization: By regularly checking the lock status and retrying to acquire it, the system can better adapt to the dynamically changing resource access requirements and optimize resource utilization.

[0091] Reduce waiting time: When the lock is held briefly, the system does not wait indefinitely but retries after a preset time, which reduces unnecessary waiting time.

[0092] Furthermore, the inventory of asset detail data for the target area according to the batch lock includes:

[0093] When holding the batch lock, inventory the asset detail data of the target area through multiple threads;

[0094] Preferably, the inventory of asset detail data for the target area includes:

[0095] Set the inventory of asset detail data as multiple subtasks and coordinate the concurrent execution of the inventory of asset detail data through a distributed task queue;

[0096] Preferably, the inventory of asset detail data for the target area includes:

[0097] Through an asynchronous message queue, convert the inventory of asset detail data for the target area into an asynchronous task and process the asynchronous task to complete the inventory of asset detail data for the target area.

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

[0099] Improve concurrent processing ability: By simultaneously inventorying the asset detail data of the target area through multiple threads, the data processing speed can be significantly improved, especially when facing a large amount of data.

[0100] Task decomposition and optimization: Setting the inventory of asset detail data as multiple subtasks helps decompose complex large tasks into small tasks, which is convenient for management and optimization.

[0101] Coordination of the distributed task queue: Using a distributed task queue to coordinate the concurrent execution of subtasks can better utilize cluster resources and improve the overall processing efficiency.

[0102] Load balancing: Through a distributed task queue, the balanced distribution of task loads can be achieved, avoiding overloading of a single node and improving the stability and reliability of the system.

[0103] Asynchronous processing improves performance: By converting the inventory task into an asynchronous task through an asynchronous message queue, waiting time can be reduced and the responsiveness of the system can be improved.

[0104] Optimized resource utilization: Asynchronous task processing allows the system to continue executing other tasks while waiting for IO operations (such as database writes) to complete, thus optimizing the utilization of CPU and IO resources.

[0105] An inventory device for battery swapping station assets provided by one or more embodiments of this specification, the device includes:

[0106] An acquisition unit, when performing an asset inventory of the target area of the battery swapping station, obtains the batch lock of the target area through a distributed lock service and records the batch lock status of the target area as holding the lock;

[0107] An inventory unit, performs an inventory of asset detail data for the target area according to the batch lock.

[0108] An inventory device for battery swapping station assets provided by one or more embodiments of this specification, includes:

[0109] At least one processor; and,

[0110] A memory communicatively connected to the at least one processor; wherein,

[0111] 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:

[0112] When performing an asset inventory of the target area of the battery swapping station, obtain the batch lock of the target area through a distributed lock service and record the batch lock status of the target area as holding the lock;

[0113] Perform an inventory of asset detail data for the target area according to the batch lock.

[0114] 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, it can be enabled to:

[0115] When performing an asset inventory of the target area of the battery swapping station, obtain the batch lock of the target area through a distributed lock service and record the batch lock status of the target area as holding the lock;

[0116] Perform an inventory of asset detail data for the target area according to the batch lock.

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

[0118] Avoid concurrent dirty data writing: By using a distributed lock service to obtain batch locks for the target area, it is ensured that during the inventory operation, the same area will not be modified by other users simultaneously, thus avoiding the problem of dirty data writing.

[0119] Improve data accuracy: Due to the batch lock mechanism, each user can only read the data in the current locked state during the inventory, which can ensure the accuracy of the inventory data because it is not affected by other concurrent operations.

[0120] Enhance data reliability: Using batch locks can prevent data conflicts and chaos, improve the reliability of data processing, and ensure the stability and credibility of the inventory results.

[0121] Optimize concurrent processing ability: In the state of holding the lock, batch data inventory can be performed on the target area, which can improve the inventory efficiency and reduce the time waste caused by concurrent operations. BRIEF DESCRIPTION OF THE DRAWINGS

[0122] In order to more clearly illustrate the technical solutions in the embodiments of this specification or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the 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:

[0123] Figure 1 It is a schematic flowchart of a method for inventorying the assets of a power exchange station provided by one or more embodiments of this specification;

[0124] Figure 2 It is a schematic flowchart of a method for inventorying the assets of a power exchange station provided by one or more embodiments of this specification;

[0125] Figure 3 It is a schematic structural diagram of a device for inventorying the assets of a power exchange station provided by one or more embodiments of this specification;

[0126] Figure 4 It is a schematic structural diagram of a device for inventorying the assets of a power exchange station provided by one or more embodiments of this specification;

[0127] Figure 5 It is a schematic structural diagram of a device for inventorying the assets of a power exchange station provided by one or more embodiments of this specification. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0128] The embodiments of this specification provide a method, device, equipment, and medium for inventorying the assets of a power exchange station.

[0129] As the business continues to develop, more and more sites are opened, and the digital management of site assets becomes increasingly prominent. The need for inventory management in daily operations is becoming more and more prominent. When synchronizing a large number of data concurrent inventory operations, there will be a problem of concurrent writing of dirty data. If a distributed lock is added, it can solve the problem of concurrent operation of dirty data for a single inventory list detail operation. However, if multiple inventory list details are operated simultaneously, a deadlock problem will occur with a single locking scheme.

[0130] In order to enable the personnel in the technical field 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 a part of the embodiments of this specification, rather than all the 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 scope of protection of this specification.

[0131] Figure 1 It is a schematic flow diagram of a method for inventorying the assets of a battery swapping station provided for one or more embodiments of this specification. This process can be executed by the inventory system of the battery swapping station assets. Some input parameters or intermediate results in the process allow manual intervention and adjustment to help improve accuracy.

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

[0133] S102, according to business needs and the characteristics of the battery swapping station, divide the battery swapping station into multiple areas.

[0134] In the embodiments of this specification, business requirements and the characteristics of the battery swapping station may include the scale, layout, battery inventory situation, and specific requirements of the inventory operation of the battery swapping station. Regarding the above-mentioned division of the battery swapping station into multiple areas, the following specific implementation solutions can be adopted:

[0135] Analyze the characteristics of the battery swapping station and formulate a division plan: Based on business requirements and the characteristics of the battery swapping station, conduct induction and analysis. Consider factors such as the geographical location, battery inventory quantity, battery type, battery capacity, replacement equipment, etc. of the battery swapping station, and formulate a division plan.

[0136] Divide the battery swapping station into multiple areas: According to the formulated division plan, divide the battery swapping station into multiple areas. The area division can be carried out according to factors such as geographical location, battery type, equipment distribution, etc. Ensure the rationality and operability of the division of each area.

[0137] Set area identifiers: Set unique identifiers for each divided area to facilitate subsequent identification and management when inventorying asset detail data for each area. Area codes or names can be used as area identifiers.

[0138] Update system configuration and database: Update the system configuration and database according to the divided regions. Ensure that the system can identify and operate on the divided regions, and associate the region identifiers with the corresponding data.

[0139] S104, Create a region lock table in the preset database to record the batch lock status of each region through the region lock table.

[0140] In the embodiments of this specification, the above-mentioned creation of the region lock table can be implemented through the following specific implementation schemes:

[0141] Determine the database type: First, the type of database used can be determined, such as MySQL, Oracle, SQLServer, etc. The database can be created when updating the system configuration and database as described above.

[0142] Create the region lock table structure: According to the syntax specifications of the preset database, create a new table to record the batch lock status of each region. For example, a table named "region lock table" can be created, which includes the following fields: region ID, lock status, lock start time, lock release time, etc.

[0143] Design the constraints of the region lock table: According to the requirements, a uniqueness constraint can be set for the region ID field to ensure that there is only one record for each region. At the same time, appropriate data types and constraints can also be set for other fields to ensure the integrity and correctness of the data.

[0144] Insert initial data: According to the requirements, initial data can be inserted into the region lock table, that is, the initial lock status of each region. According to the actual situation, the lock status of some regions can be set to locked or unlocked, and the start time of the lock and the expected release time can be recorded.

[0145] Implement the management function of the region lock: According to the system requirements, implement the management function of the region lock, including locking a specific region, releasing the lock of a specific region, querying the lock status of a specific region, etc. This can be achieved by writing corresponding SQL statements or using database management tools.

[0146] Update the region lock table: If necessary, the data in the region lock table can be updated according to the business logic. For example, when the locking time of a certain region exceeds the set time limit, the lock is automatically released.

[0147] Other operations involved: According to specific requirements, other operations can also be considered, such as querying the list of locked regions, querying the list of unlocked regions, querying the locking situation within a certain time period, etc.

[0148] S106. Create a distributed lock service to acquire and release batch locks for each region through the distributed lock service.

[0149] In the embodiments of this specification, the above-mentioned creation of the distributed lock service can be implemented through the following specific implementation methods:

[0150] Design the distributed lock service architecture: A suitable distributed lock service architecture can be designed. Common distributed lock implementation methods can be used, such as distributed locks based on databases, distributed locks based on Redis, etc. Select the most suitable distributed lock service according to requirements and available resources.

[0151] Integrate the distributed lock service: Integrate the selected distributed lock service into the system according to the selected distributed lock service. This may include operations such as introducing relevant dependency libraries, configuring service connections, and authentication.

[0152] Create a regional lock object: Create a regional lock object to manage batch locks for each region according to the usage method of the distributed lock service. The regional lock object can include fields such as region ID, lock status, lock start time, lock release time, etc.

[0153] Acquire the regional lock: When a batch operation needs to be performed on a certain region, acquire the lock for the corresponding region by calling the interface of the distributed lock service. This may involve calling the API provided by the distributed lock service and passing parameters such as the region ID.

[0154] Execute the batch operation: Once the regional lock is acquired, the batch operation can be performed. According to specific business requirements, execute the corresponding batch operation logic.

[0155] Release the regional lock: When the batch operation is completed, release the lock for the corresponding region by calling the interface of the distributed lock service. Similarly, this may involve calling the API provided by the distributed lock service and passing parameters such as the region ID.

[0156] Exception handling: For the operations of acquiring and releasing the regional lock, an appropriate exception handling mechanism needs to be added. For example, handle exceptions such as lock acquisition timeout, lock acquisition failure, lock release failure, etc., to ensure the robustness and reliability of the system.

[0157] Concurrency control: When using the distributed lock service, the issue of concurrency control needs to be considered. The distributed lock service usually provides various mechanisms, such as blocking locks, optimistic locks, etc., to handle concurrency conflicts and race conditions, ensuring that multiple operations do not perform batch operations on the same region simultaneously.

[0158] S108. When conducting an asset inventory of the target region of the battery swapping station, acquire the batch lock of the target region through the distributed lock service and record the batch lock status of the target region as locked in the regional lock table.

[0159] In the embodiments of this specification, for the asset inventory of the target area of the above-mentioned battery swapping station, the following specific implementation solutions can be adopted:

[0160] Confirm the target area information: First, the target area of the battery swapping station can be confirmed, including information such as the area ID and area name.

[0161] Initiate a request to obtain the batch lock for the target area: Call the API provided by the distributed lock service to initiate a request to obtain the batch lock for the target area. Pass parameters such as the area ID of the target area so that the distributed lock service can perform corresponding processing.

[0162] Query the batch lock status of the target area: In the distributed lock service, query the relevant area lock table in the database by calling the database to query the batch lock status of the target area. Use the area ID as the query condition to obtain the batch lock status of the target area.

[0163] Judge the batch lock status of the target area: Check the obtained batch lock status of the target area.

[0164] Record the batch lock status of the target area: Record the batch lock status of the target area as holding the lock in the area lock table. Update the batch lock status field corresponding to the target area in the area lock table and set it to holding the lock.

[0165] Furthermore, when obtaining the batch lock for the target area through the distributed lock service in one or more embodiments of this specification, a request to obtain the batch lock for the target area can be initiated by calling the distributed lock service; query the batch lock status of the target area in the area lock table according to the obtain request; if the batch lock status of the target area is unlocked, obtain the batch lock for this area.

[0166] It should be noted that for the above-mentioned obtaining of the batch lock for the target area through the distributed lock service, the following specific implementation steps can be adopted:

[0167] Initiate a request to obtain the batch lock for the target area by calling the distributed lock service: Use the API provided by the distributed lock service to initiate a request to obtain the batch lock for the target area. Pass parameters such as the area ID of the target area so that the distributed lock service can perform corresponding processing.

[0168] Query the batch lock status of the target area in the area lock table according to the obtain request: In the distributed lock service, according to the target area ID in the obtain request, query the area lock table by calling the database to query the batch lock status of the target area.

[0169] Judge the batch lock status of the target area: Check the batch lock status of the obtained target area. If the batch lock status is unlocked, continue to execute the following steps to obtain the batch lock of the target area. If the batch lock status is locked, it may be necessary to wait or take other measures, which are processed according to specific business requirements.

[0170] Obtain the batch lock of the target area: If the batch lock status of the target area is unlocked, use the API provided by the distributed lock service to obtain the batch lock of this area. By calling the API provided by the distributed lock service and passing parameters such as the target area ID, the batch lock of the target area can be obtained.

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

[0172] Data consistency: By obtaining the batch lock, it can be ensured that during the inventory operation, only one user can perform write operations on the target area, avoiding data conflicts and chaos caused by multiple users writing simultaneously, and ensuring the accuracy and reliability of the inventory results.

[0173] Concurrent control: Through the mechanism of the distributed lock service, concurrent access can be controlled, avoiding multiple users obtaining the batch lock of the target area simultaneously, thereby effectively reducing the probability of concurrent conflicts and improving the concurrency of the system.

[0174] Furthermore, in one or more embodiments of this specification, if the batch lock status of the target area is locked, after a preset time, the distributed lock service can be called to re-initiate a request to obtain the batch lock of the target area; query the batch lock status of the target area in the area lock table according to the re-initiated request; if the batch lock status of the target area is unlocked, obtain the batch lock of this area.

[0175] It should be noted that regarding the above situation where the batch lock status of the target area is locked, the following specific implementation steps can be taken:

[0176] Judge that the batch lock status of the target area is locked: If the batch lock status is locked, it is necessary to wait for a preset time and then re-initiate the acquisition request.

[0177] Wait for the preset time: According to the preset time, suspend the program execution during the waiting period until the preset time arrives.

[0178] Re-initiate the acquisition request: After the preset time arrives, call the API provided by the distributed lock service again to re-initiate a request to obtain the batch lock of the target area. Pass parameters such as the area ID of the target area so that the distributed lock service can perform corresponding processing.

[0179] Query the batch lock status of the target area in the area lock table according to the re-initiated acquisition request: In the distributed lock service, according to the target area ID in the re-initiated acquisition request, call the database to query the area lock table to query the batch lock status of the target area.

[0180] Judge the batch lock status of the target area: Check the obtained batch lock status of the target area. If the batch lock status is unlocked, continue to execute the following operation of obtaining the batch lock of the target area. If the batch lock status is still locked, waiting or other measures may be required, and it will be processed according to specific business requirements.

[0181] Obtain the batch lock of the target area: If the batch lock status of the target area is unlocked, use the API provided by the distributed lock service to obtain the batch lock of this area. By calling the API provided by the distributed lock service and passing parameters such as the target area ID, the batch lock of the target area can be obtained.

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

[0183] Lock timeout processing: By re-initiating the lock acquisition request after a preset time, the deadlock problem caused by the lock being held for too long can be prevented. When the lock acquisition request has been in the locked state, the system can retry to acquire the lock after a certain time to prevent long-term waiting.

[0184] Enhanced availability: The process of re-acquiring the lock is based on the mechanism of the distributed lock service. Even if there are failures of the lock service nodes or network anomalies, the system can still re-initiate the lock acquisition request and obtain the correct lock status, improving the availability of the system.

[0185] Improve concurrency: By re-initiating the lock acquisition request, the concurrency of the system can be improved to a certain extent. If a user encounters a conflict when acquiring the lock, the system will re-attempt to acquire the lock after a certain time, which can avoid the user's long-term waiting and improve the efficiency of concurrent operations.

[0186] Enhance the stability of the system: Through the mechanism of re-acquiring the lock, problems such as lock service node failures or network anomalies can be effectively solved, preventing these problems from causing the system to crash or malfunction, and enhancing the stability of the system. The system can re-initiate the lock acquisition request after returning to normal, ensuring the normal progress of operations.

[0187] Generally speaking, by re-initiating the lock acquisition request, querying the lock status, and acquiring the lock when the status is unlocked, the availability, concurrency, and stability of the system can be improved, thereby solving the problem of concurrent writing of dirty data and ensuring the accuracy and reliability of the inventory results.

[0188] S110, conduct an inventory of the asset detail data for the target area based on the batch lock.

[0189] In the embodiments of this specification, once the batch lock for the target area is obtained, the operation of inventorying the asset detail data can be carried out. The specific operation can be as follows:

[0190] Query the asset detail data within the target area: The asset detail data can be recorded and updated, including information such as quantity, status, location, etc., and other related operations can be carried out, such as verifying data, calculating statistical information, etc.

[0191] Release the batch lock for the target area: After the operation of inventorying the asset detail data is completed, call the API of the distributed lock service to release the batch lock for the target area to ensure that other operations can perform batch operations on this target area again.

[0192] Furthermore, during the process of inventorying the asset detail data for the target area according to the batch lock in one or more embodiments of this specification, that is, when holding the batch lock, multi-threading is used to inventory the asset detail data for the target area.

[0193] It should be noted that regarding the above-mentioned inventory of the asset detail data, the specific operation can be as follows:

[0194] Inventory the asset detail data using multi-threading:

[0195] In the case of holding the batch lock for the target area, multi-threading technology can be used to inventory the asset detail data for the target area. Design a suitable multi-threading task model and allocate tasks to multiple threads for processing. Each thread can independently process a part of the asset detail data, for example, divide it according to asset classification, asset location, etc. Use appropriate synchronization mechanisms to ensure that the access and modification of data by multiple threads will not cause conflicts and data inconsistency problems.

[0196] Inventory operation: In each thread, according to the designed task model, conduct an inventory operation on the asset detail data allocated to this thread. Query and record the asset detail data, update relevant information, such as quantity, status, location, etc. Carry out other related operations, such as verifying data, calculating statistical information, etc.

[0197] Release the batch lock for the target area: After the operation of inventorying the asset detail data is completed, call the API of the distributed lock service to release the batch lock for the target area. Ensure that other operations can perform batch operations on this target area again.

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

[0199] Concurrent performance improvement: By using multi-threading to take inventory of the asset detail data in the target area, concurrent processing can be achieved, improving the efficiency and speed of the inventory operation. Different threads can process different data simultaneously, making full use of system and hardware resources and reducing the execution time of the inventory task.

[0200] Improved efficiency: The multi-threaded inventory operation can process multiple asset detail data simultaneously, reducing waiting time and the overhead of sequential execution. Compared with single-threaded operations, the multi-threaded inventory operation can complete data processing faster, improving the efficiency of the inventory operation.

[0201] Data consistency: By performing the multi-threaded inventory operation while holding a batch lock, it can be ensured that only one thread writes to the target area during the inventory, avoiding data conflicts and chaos caused by multiple threads writing simultaneously. This can ensure the accuracy and reliability of the inventory results.

[0202] Increased concurrency: By using the multi-threaded inventory operation, the asset detail data in multiple areas can be processed simultaneously, increasing the concurrency of the system. The inventory operations in different areas can be carried out concurrently, accelerating the inventory speed of the asset detail data and shortening the time of the entire inventory process.

[0203] In summary, by using multi-threading to take inventory of the asset detail data in the target area while holding a batch lock, concurrent performance, efficiency, and data consistency can be improved, while increasing the concurrency of the system, thereby solving the problem of concurrent write dirty data and ensuring the accuracy and reliability of the inventory results.

[0204] Furthermore, when taking inventory of the asset detail data in the target area in one or more embodiments of this specification, the asset detail data inventory can be set as multiple subtasks, and a distributed task queue can be used to coordinate the concurrent execution of the asset detail data inventory.

[0205] It should be noted that regarding the above-mentioned coordination of the concurrent execution of the asset detail data inventory through a distributed task queue, the following specific implementation steps can be adopted:

[0206] Set subtasks: Divide the target area into multiple smaller areas, and use each area as a subtask. Determine the content of the asset detail data inventory that each subtask should include.

[0207] Create a distributed task queue: Use a suitable distributed task queue tool, such as RabbitMQ, Kafka, etc., to create a task queue.

[0208] Define the task message format: Determine the message format for each subtask, including the task ID, subtask description, asset detail data to be inventoried, etc.

[0209] Publish task messages: Sequentially publish the messages of each subtask to the task queue.

[0210] Start the task executor: Create one or more task executors to listen for messages in the task queue.

[0211] Retrieve task messages: The task executor retrieves a task message to be executed from the task queue.

[0212] Execute subtasks: According to the content in the task message, execute the corresponding subtasks, that is, conduct an inventory of asset details data.

[0213] Update the task status: After the subtask is executed, update the task status to mark the subtask as completed.

[0214] Check the task status: The task executor periodically checks the task status to determine whether there are still subtasks to be executed.

[0215] Execute other subtasks: If there are still subtasks to be executed, continue to retrieve task messages from the task queue and execute the next subtask.

[0216] Complete the inventory of asset details data: When all subtasks in the task queue are executed, it indicates that the inventory of asset details data is completed.

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

[0218] Improved concurrency performance: By splitting the inventory task into multiple subtasks and using a distributed task queue to coordinate concurrent execution, parallel processing can be achieved, improving the efficiency and speed of the inventory operation. Different subtasks can be executed simultaneously, making full use of system and hardware resources and reducing the execution time of the inventory task.

[0219] System scalability: By using a distributed task queue, the processing capacity of tasks can be flexibly expanded. More task execution nodes can be added as needed, or more task queues can be added to handle more inventory tasks, thus improving the scalability of the system.

[0220] Task scheduling and coordination: By using a distributed task queue, task scheduling and coordination can be achieved. Each subtask can be allocated and executed according to priorities or other scheduling algorithms, ensuring the balanced distribution and sequential execution of the inventory task and improving the coordination of tasks.

[0221] Exception handling and retry mechanism: In a distributed task queue, an exception handling and retry mechanism can be implemented. When an exception or failure occurs during the execution of a subtask, the task can be re-put into the queue for retry to ensure the completion and accuracy of the task.

[0222] Increasing concurrency: By using a distributed task queue, the asset detail data inventory tasks in multiple regions can be processed simultaneously, improving the concurrency of the system. The inventory tasks in different regions can be executed concurrently, accelerating the inventory speed of the asset detail data and shortening the time of the entire inventory process.

[0223] In summary, by setting the inventory task as multiple subtasks and using a distributed task queue to coordinate concurrent execution, the concurrent performance, system scalability, and task scheduling coordination can be improved. At the same time, the concurrency of the system is increased, thus solving the problem of concurrent write dirty data and ensuring the accuracy and reliability of the inventory results.

[0224] Furthermore, when conducting an inventory of asset detail data for a target region in one or more embodiments of this specification, the inventory of the asset detail data for the target region can be transformed into an asynchronous task through an asynchronous message queue, and the asynchronous task can be processed to complete the inventory of the asset detail data for the target region.

[0225] It should be noted that regarding the above-mentioned inventory of asset detail data for the target region through an asynchronous message queue, the following specific implementation steps can be adopted:

[0226] Configure the asynchronous message queue: Select a suitable asynchronous message queue tool, such as RabbitMQ, Kafka, etc., and perform corresponding configuration and deployment.

[0227] Define the message format: Determine the message format, including task ID, target region description, asset detail data, etc.

[0228] Create a message producer: Develop a message producer program for sending asynchronous task messages to the message queue. In the program, transform the inventory of the asset detail data for the target region into an asynchronous task and send the task message to the message queue.

[0229] Create a message consumer: Develop a message consumer program for listening to the task messages in the message queue.

[0230] Receive the message: The message consumer program receives the task message to be processed from the message queue.

[0231] Execute the task: According to the content in the task message, execute the corresponding asset detail data inventory task.

[0232] Update the task status: After the task is executed, update the task status to mark that the task is completed.

[0233] Check the task status: The message consumer program regularly checks the task status to determine whether there are still tasks to be executed.

[0234] Handle other tasks: If there are still tasks to be executed, continue to receive task messages from the message queue and execute the next task.

[0235] Complete the inventory of asset detail data: When all tasks in the message queue are executed, it means that the inventory of asset detail data in the target area is completed.

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

[0237] Improved concurrency performance: By converting the inventory of asset detail data into asynchronous tasks, the execution and return of tasks can be decoupled, thereby improving the concurrency performance of the system. Multiple asynchronous tasks can be executed simultaneously, making full use of system resources and improving the efficiency and speed of the inventory operation.

[0238] System scalability: Since an asynchronous message queue is used for task processing, multiple task processing nodes can be easily extended and deployed to handle more inventory tasks. This improves the scalability of the system and enables dynamic adjustment of the task processing ability according to requirements.

[0239] Asynchronous task processing: The characteristics of asynchronous tasks can enable the inventory tasks to be processed in the background without affecting the user's real-time operations. By converting the inventory tasks into asynchronous tasks, the user's interaction response speed can be improved and the user experience can be enhanced.

[0240] Error handling and retry mechanism: When using an asynchronous message queue for task processing, error handling and retry mechanisms can be implemented in case of errors or failures. If an asynchronous task fails, the task can be re-put into the message queue for retry to ensure the completion and accuracy of the task.

[0241] System decoupling: By converting the inventory of asset detail data into asynchronous tasks, the correlation and dependence between different modules can be reduced. The use of asynchronous task processing and message queues enables better decoupling between modules, improving the maintainability and flexibility of the system.

[0242] In summary, by converting the inventory of asset detail data into asynchronous tasks and using an asynchronous message queue for processing, the concurrency performance, system scalability can be improved, asynchronous task processing and error handling can be achieved, and the decoupling of the system can be enhanced, thereby solving the problem of concurrent writing of dirty data and ensuring the accuracy and reliability of the inventory results.

[0243] Furthermore, the asset detail data in multiple regions of one or more embodiments of this specification includes one or more of the battery inventory quantity, battery type, battery capacity, and replacement equipment.

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

[0245] Monitor inventory status: By regularly taking inventory of the battery inventory quantities in multiple areas, the inventory status of the batteries can be better monitored and managed. The inventory-taking operation can provide accurate inventory quantity data, helping to replenish inventory in a timely manner and avoid inventory shortages or surpluses.

[0246] Optimize battery management: Through the inventory-taking operation, information on the battery types and battery capacities in multiple areas can be obtained. This can help with the effective management and optimization of the batteries, such as allocating batteries according to the needs of different areas, replacing or phasing out low-capacity batteries, etc.

[0247] Ensure equipment integrity: By taking inventory of the replacement equipment, the integrity of the equipment can be ensured. This can help detect problems such as missing, damaged, or incorrectly replaced equipment, and take corrective measures in a timely manner to ensure the accuracy and reliability of equipment management.

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

[0249] Concurrent conflict resolution: By dividing the battery swapping station into multiple areas and using area lock tables and distributed lock services, the problem of concurrent write dirty data that may occur when multiple users take inventory of the same resource simultaneously can be effectively solved. Using the distributed lock service can achieve the acquisition and release of batch locks for each area, ensuring that only one user can take inventory of the target area at the same time, and avoiding data conflicts and chaos.

[0250] Improve the accuracy of asset inventory: By using area lock tables and batch locks to take inventory of the target area, it can be ensured that the data in this area will not be modified or accessed by other users during the inventory-taking process, thereby improving the accuracy and reliability of the asset inventory. By recording the batch lock status of the target area, the progress of the inventory-taking operation can be tracked and monitored.

[0251] Improve the efficiency of resource inventory: By dividing the battery swapping station into multiple areas and using the distributed lock service to achieve the acquisition and release of batch locks for each area, more efficient resource inventory can be achieved. The inventory-taking operations in different areas can be carried out in parallel, reducing the serial waiting time and improving the inventory-taking efficiency.

[0252] Improve system stability: By using the distributed lock service and area lock tables, the stability and reliability of the system can be improved. The distributed lock service can be responsible for handling concurrent lock requests, avoiding single-point failure and performance bottleneck problems in traditional lock mechanisms. The area lock table can record and manage the batch lock status of each area, ensuring the consistency and integrity of the inventory-taking operation.

[0253] In summary, this method for inventorying the assets of a battery swapping station can solve the problem of concurrent write dirty data, improve the accuracy and efficiency of resource inventory, enhance the stability and reliability of the system, and provide beneficial effects for the asset management and operation of electric vehicle battery swapping stations by dividing regions and adopting regional lock tables and distributed lock services.

[0254] Figure 2 FIG. is a schematic flowchart of a method for inventorying the assets of a battery swapping station provided by one or more embodiments of this specification. This process can be executed by an inventory system for the assets of a battery swapping station. Some input parameters or intermediate results in the process allow manual intervention and adjustment to help improve accuracy.

[0255] S202. When inventorying the assets of the target area of the battery swapping station, obtain the batch lock of the target area through the distributed lock service, and record the batch lock status of the target area as holding the lock.

[0256] In the embodiments of this specification, when inventorying the assets of the target area of the battery swapping station, determine the batch resource access request corresponding to the target area; convert the batch resource access request into at least one distributed resource access request, and determine the distributed lock status corresponding to each distributed resource access request; when the distributed lock statuses corresponding to all the distributed resource access requests are locked, obtain the batch lock corresponding to the target area.

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

[0258] Determine the target area: Clearly define the target area of the battery swapping station where asset inventory needs to be carried out.

[0259] Identify the batch resource access request: Determine all the batch resources that need to be accessed in the target area. These resources may be database records, files in the file system, or data in remote services, etc.

[0260] Convert the batch resource access request: Convert the identified batch resource access request into a distributed resource access request. This usually means splitting a single request into multiple independent requests, with each request targeting one resource in the target area.

[0261] Determine the distributed lock status: For each distributed resource access request, query or check the corresponding distributed lock status. The distributed lock status can be "locked", "unlocked", or "waiting". This can be achieved through a distributed lock service (such as locks in Redisson, ZooKeeper, etc.).

[0262] Check the lock status: Check the lock status of all distributed locks corresponding to the distributed resource access requests to ensure that they are all in the "locked" state. This usually means that all critical resources in the target area have been locked by other operations.

[0263] Obtain a batch lock: If the lock status of all distributed locks for the distributed resource access requests is "locked", then the batch lock corresponding to the target area can be obtained. The batch lock can be a special lock that is obtained when all relevant distributed locks are locked to ensure that the resources in the target area will not be modified by other operations during the inventory process.

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

[0265] Prevent data concurrency conflicts: Ensure that the data in the target area will not be modified by other concurrent operations during the inventory through the distributed lock service, thus avoiding data inconsistency and conflicts.

[0266] Improve data consistency: Ensure that all relevant distributed resource access requests have been locked before obtaining the batch lock, which guarantees the integrity of the data during the inventory process.

[0267] Enhance data accuracy: Since other operations are locked during the inventory, users can obtain consistent and unmodified data, which improves the accuracy of the inventory results.

[0268] Simplify the concurrency control logic: Convert batch resource access requests into distributed resource access requests and manage the lock status of each request, which simplifies the concurrency control logic and makes the system design clearer.

[0269] Furthermore, when the lock status of all distributed locks corresponding to the distributed resource access requests is locked, before obtaining the batch lock corresponding to the target area, for each distributed resource access request, determine the lock status of the distributed lock corresponding to the distributed resource access request; when the lock status of the distributed lock corresponding to the distributed resource access request is unlocked, determine the resource competition status of the distributed resource access request; based on the resource competition status of the distributed resource access request, determine the resource locking method corresponding to the distributed resource access request; based on the resource locking method corresponding to the distributed resource access request, lock the partial inventory resources corresponding to the distributed resource access request, and update the lock status of the distributed lock corresponding to the distributed resource access request to the locked state.

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

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

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

[0273] Determine the resource locking method: Based on the resource competition status, determine the most suitable resource locking method.

[0274] Lock part of the inventory resources: Use the selected resource locking method to lock the part of the inventory resources corresponding to the distributed resource access request.

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

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

[0277] Fine-grained resource management: By determining the status and evaluating the resource competition status of each distributed resource access request, more fine-grained resource management can be achieved, improving resource utilization efficiency.

[0278] Dynamic resource locking strategy: According to the resource competition status, the resource locking method can be dynamically determined, which helps to adopt more effective locking strategies in case of resource shortage and reduce resource contention.

[0279] Performance optimization: By selecting the locking method, unnecessary lock waiting time can be reduced, thereby optimizing the system performance and improving the efficiency of the inventory operation.

[0280] Improve data integrity: Before locking a specific resource, ensure that its lock status is unlocked, which helps to prevent data from being modified by other operations during the inventory process and guarantees data integrity.

[0281] Further, when locking some of the inventory 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, a specified thread is used to lock some of the inventory resources corresponding to the distributed resource access request. In the case where the resource locking method is the second locking method, a resource competition queue for the resources to be inventoried corresponding to the distributed resource access request is 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 resources to be inventoried corresponding to the distributed resource access request, a specified thread is used to lock some of the inventory resources corresponding to the distributed resource access request.

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

[0283] Determine the resource locking method: First, it is necessary to 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:

[0284] Analyze business requirements: It is necessary to understand the business requirements to determine the appropriate resource locking strategy. The following is the specific content of analyzing business requirements to determine the resource locking method:

[0285] Exclusive lock (the first locking method): It is 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.

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

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

[0288] Further, after determining the resource locking method for each distributed resource access request, the following specific implementation solutions can be adopted:

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

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

[0291] Resource locking: Use this thread to perform an exclusive lock on some of the inventory resources corresponding to the distributed resource access request.

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

[0293] If the resource locking method is the second locking method (competitive locking), the implementation plan is as follows:

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

[0295] Request enqueue: Put the distributed resource access request into the resource competition queue. After the request is enqueued, wait for resource allocation.

[0296] Resource allocation: When the resource is available, dequeue the request for resource allocation. When allocating resources, ensure that the resource cannot be occupied by multiple requests simultaneously.

[0297] Thread assignment: Assign a thread to the distributed resource access request. Lock the partial inventory resources corresponding to the distributed resource access request through this thread.

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

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

[0300] Improve resource allocation efficiency: When the resource locking method is the first locking method, by specifying a thread to lock the partial inventory resources, the resource 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, 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.

[0301] Ensure data consistency: By specifying a thread to lock the resources, ensure 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 resources simultaneously.

[0302] Further, when the distributed resource access request is placed in the resource competition queue and waits for resource allocation, based on the request weight parameter corresponding to the distributed resource access request, request to allocate the corresponding inventory resource in the resource competition queue to obtain a first resource request result; in the case where the first resource request result fails, re-obtain the current lock state corresponding to the distributed resource access request; 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; based on the resource request waiting time and the request weight parameter, re-request to allocate the corresponding inventory resource in the resource competition queue to obtain a second resource request result; in the case where the second resource request result fails, re-obtain the current lock state and re-request to allocate the corresponding inventory resource until the inventory resource corresponding to the distributed resource access request is requested.

[0303] 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 logic for priority.

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

[0305] 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.

[0306] The resource allocation process is as follows:

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

[0308] Re-obtain the lock state: Obtain the lock state of the current distributed resource access request. If the lock state is unlocked, perform the following operations.

[0309] Calculate the waiting time: Calculate the waiting time since the last request failure.

[0310] Second resource request: Based on the current waiting time and the request weight parameter, re-request to allocate the corresponding inventory resource in the resource competition queue. If the request passes, subsequent operations can continue; if it fails, perform the following operations.

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

[0312] 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 the failure can be recorded and processed according to strategies (such as retrying, degradation, etc.).

[0313] Resource release: Once the inventory operation is completed, release the allocated resources and remove the request from the queue.

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

[0315] Improve the fairness of resource allocation: Request the allocation of resources to be inventoried 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.

[0316] Avoid deadlocks and starvation phenomena: When the resource request result fails, re-obtain the current lock status 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 phenomena and improving the stability of the system.

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

[0318] Furthermore, 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 can be determined based on the user-specified waiting time corresponding to the distributed resource access request and the request weight parameter; 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 the request allocation of resources based on the distributed resource access request failing, generate the 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.

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

[0320] 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:

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

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

[0323] 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, such as: - 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 system load.

[0324] 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:

[0325] 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.

[0326] 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.

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

[0328] 3.1 Collect historical retry data: Collect the retry time data for each request that fails to allocate resources.

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

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

[0331] 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, users can set the waiting time according to their own needs and priorities, improving the flexibility of resource allocation.

[0332] 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.

[0333] 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 according to historical experience, thereby improving the success rate of resource allocation.

[0334] S204: performing an inventory of detailed asset data of the target area according to the batch lock.

[0335] It should be noted that, regarding the above S204, the following specific implementation scheme can be adopted:

[0336] Plan the inventory process: Develop a detailed inventory plan, including the inventory schedule, participants, required tools and resources, etc.

[0337] Resource preparation: Prepare the tools needed for inventory, such as inventory forms, scanning equipment, mobile computing devices (such as tablets or smartphones), etc. Ensure that inventory personnel are familiar with the inventory process and the use of tools.

[0338] Data synchronization: After locking the target area, synchronize the latest asset detail data to the mobile device of the inventory personnel.

[0339] Inventory execution: Instruct inventory personnel to conduct on-site inventory and use mobile devices to record asset information. Inventory personnel should count and record assets in a predetermined order and method.

[0340] Furthermore, before conducting an asset inventory of the target area of ​​the battery swap station, the battery swap station can be divided into multiple areas according to business needs and the characteristics of the battery swap station; a regional lock table is created in a preset database to record the batch lock status of each area through the regional lock table; a distributed lock service is created to acquire and release the batch locks of each area through the distributed lock service; and / or, recording the batch lock status of the target area as a held lock includes: recording the batch lock status of the target area as a held lock in the regional lock table.

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

[0342] Improve inventory efficiency: By dividing the battery swap station into multiple areas, the inventory work can be organized more efficiently, making the inventory process more orderly and reducing unnecessary waste of time and resources.

[0343] Enhanced resource management: Create regional lock tables and distributed lock services to effectively manage the batch lock status of battery swap stations, help avoid data conflicts, and ensure the accuracy of inventory data.

[0344] Simplified lock management: The use of regional lock tables and distributed lock services simplifies the lock management process, making the operations of acquiring and releasing locks more automated and standardized.

[0345] Improve data consistency: By recording the batch lock status as held, it ensures that during the inventory process, resources in the same area will not be modified by other operations, thus guaranteeing data consistency.

[0346] Furthermore, when obtaining the batch lock for the target area through the distributed lock service, the method can initiate a request to obtain the batch lock for the target area by calling the distributed lock service; query the batch lock status of the target area in the area lock table according to the obtain request; if the batch lock status of the target area is unlocked, obtain the batch lock for the target area; and / or, if the batch lock status of the target area is locked, the method further includes: after a preset time, initiate a new request to obtain the batch lock for the target area by calling the distributed lock service; query the batch lock status of the target area in the area lock table according to the newly initiated obtain request; if the batch lock status of the target area is unlocked, obtain the batch lock for the target area.

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

[0348] Guarantee data consistency: Through the distributed lock service, it ensures that data will not be modified by other concurrent operations during batch operations in the target area, thus maintaining data consistency.

[0349] Avoid concurrent conflicts: Obtaining the lock when the batch lock is unlocked can prevent multiple operations from accessing the same resource simultaneously, reducing the risk of concurrent conflicts and data inconsistency.

[0350] Improve system responsiveness: When the batch lock is locked by other operations, the system does not fail immediately but waits for a period of time and then retries to obtain the lock, which improves the system's responsiveness and user experience.

[0351] Enhance the fault tolerance of the system: If an operation fails to obtain the lock, the system can automatically attempt to obtain the lock again, which enhances the fault tolerance of the system.

[0352] Optimize resource utilization: By regularly checking the lock status and retrying to obtain it, the system can better adapt to the dynamically changing resource access requirements and optimize resource utilization.

[0353] Reduce waiting time: When the lock is held for a short time, the system does not wait indefinitely but retries after a preset time, which reduces unnecessary waiting time.

[0354] Further, when conducting an inventory of the asset detail data for the target area based on the batch lock, while holding the batch lock, the asset detail data of the target area is inventoried through multiple threads. When conducting an inventory of the asset detail data for the target area, the asset detail data inventory is set as multiple subtasks, and a distributed task queue is used to coordinate the concurrent execution of the asset detail data inventory. When conducting an inventory of the asset detail data for the target area, through an asynchronous message queue, the asset detail data inventory of the target area is transformed into an asynchronous task, and the asynchronous task is processed to complete the asset detail data inventory of the target area.

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

[0356] Improve concurrent processing ability: By simultaneously inventorying the asset detail data of the target area through multiple threads, the data processing speed can be significantly improved, especially when dealing with a large amount of data.

[0357] Task decomposition and optimization: Setting the asset detail data inventory as multiple subtasks helps decompose complex large tasks into small tasks, facilitating management and optimization.

[0358] Coordination of the distributed task queue: Using a distributed task queue to coordinate the concurrent execution of subtasks can better utilize cluster resources and improve the overall processing efficiency.

[0359] Load balancing: Through the distributed task queue, the task load can be evenly distributed, avoiding overloading of a single node and improving the stability and reliability of the system.

[0360] Asynchronous processing to improve performance: Transforming the inventory task into an asynchronous task through an asynchronous message queue can reduce waiting time and improve the responsiveness of the system.

[0361] Optimization of resource utilization: Asynchronous task processing allows the system to continue executing other tasks while waiting for IO operations (such as database writes) to complete, thereby optimizing the utilization of CPU and IO resources.

[0362] Figure 3 The structural schematic diagram of an inventory device for the assets of a battery swapping station provided by one or more embodiments of this specification. The device includes: a division unit 202, a lock table creation unit 204, a lock service creation unit 206, an acquisition unit 208, and an inventory unit 210.

[0363] The division unit 202 divides the battery swapping station into multiple areas according to business requirements and the characteristics of the battery swapping station;

[0364] The lock table creation unit 204 creates a regional lock table in a preset database to record the bulk lock status of each region through the regional lock table;

[0365] The lock service creation unit 206 creates a distributed lock service to acquire and release the bulk locks of each region through the distributed lock service;

[0366] The acquisition unit 208, when conducting an asset inventory of the target region of the swapping station, acquires the bulk lock of the target region through the distributed lock service and records the bulk lock status of the target region as holding the lock in the regional lock table;

[0367] The inventory unit 210 conducts an inventory of the asset detail data of the target region based on the bulk lock.

[0368] Figure 4 The structure diagram of an inventory device for the assets of a swapping station provided for one or more embodiments of this specification, the device includes: an acquisition unit 402 and an inventory unit 404.

[0369] The acquisition unit 402, when conducting an asset inventory of the target region of the swapping station, acquires the bulk lock of the target region through the distributed lock service and records the bulk lock status of the target region as holding the lock;

[0370] The inventory unit 404 conducts an inventory of the asset detail data of the target region based on the bulk lock.

[0371] Figure 5 The structure diagram of an inventory device for the assets of a swapping station provided for one or more embodiments of this specification, includes:

[0372] At least one processor; and,

[0373] A memory communicatively connected to at least one processor; wherein,

[0374] The memory stores instructions executable by at least one processor, and the instructions are executed by at least one processor so that at least one processor can:

[0375] Divide the swapping station into multiple regions according to business needs and the characteristics of the swapping station;

[0376] Create a regional lock table in a preset database to record the bulk lock status of each region through the regional lock table;

[0377] Create a distributed lock service to acquire and release the bulk locks of each region through the distributed lock service;

[0378] When conducting an asset inventory of the target area of the swapping station, obtain the batch lock of the target area through the distributed lock service, and record the status of the batch lock of the target area as locked in the area lock table.

[0379] Conduct an inventory of the asset detail data of the target area according to the batch lock.

[0380] An inventory device for the assets of a swapping station provided by one or more embodiments of this specification includes:

[0381] At least one processor; and,

[0382] A memory communicatively connected to the at least one processor; wherein,

[0383] 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:

[0384] When conducting an asset inventory of the target area of the swapping station, obtain the batch lock of the target area through the distributed lock service, and record the status of the batch lock of the target area as locked;

[0385] Conduct an inventory of the asset detail data of the target area according to the batch lock.

[0386] 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 can:

[0387] Divide the swapping station into multiple areas according to business needs and the characteristics of the swapping station;

[0388] Create an area lock table in a preset database to record the status of the batch lock of each area through the area lock table;

[0389] Create a distributed lock service to obtain and release the batch lock of each area through the distributed lock service;

[0390] When conducting an asset inventory of the target area of the swapping station, obtain the batch lock of the target area through the distributed lock service, and record the status of the batch lock of the target area as locked in the area lock table;

[0391] Conduct an inventory of the asset detail data of the target area according to the batch lock.

[0392] 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 can:

[0393] When conducting an asset inventory of the target area of the power exchange station, obtain the batch lock for the target area through the distributed lock service, and record the status of the batch lock for the target area as holding the lock;

[0394] Conduct an inventory of the asset detail data for the target area according to the batch lock.

[0395] Each embodiment in this specification is described in a progressive manner. For the parts that are the same or similar among the embodiments, reference can be made to each other. Each embodiment focuses on the differences from other embodiments. In particular, for the embodiments of the device, equipment, 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 refer to the partial description of the method embodiments.

[0396] The specific embodiments of this specification are 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 executed in a different order than in the embodiments and still achieve the desired result. Additionally, the processes depicted in the figures do not necessarily require the specific order or sequential order shown to achieve the desired result. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0397] The above is only one or more embodiments of this specification and is not intended to limit this specification. For those skilled in the art, there can be various changes and modifications to one or more embodiments of this specification. Any modification, equivalent replacement, improvement, 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 inventorying the assets of a battery swapping station, characterized in that, The method includes: When conducting an asset inventory of the target area of the battery swapping station, obtain the batch lock for the target area through the distributed lock service, and record the status of the batch lock for the target area as holding the lock; Conduct an inventory of the asset detail data for the target area according to the batch lock.

2. The inventory method of the battery swapping station assets according to claim 1, wherein The step of "when conducting an asset inventory of the target area of the battery swapping station, obtain the batch lock for the target area through the distributed lock service" includes: When conducting an asset inventory of the target area of the battery swapping station, determine the batch resource access request corresponding to the target area; Convert the batch resource access request into at least one distributed resource access request, and determine the distributed lock status corresponding to each distributed resource access request; Obtain the batch lock corresponding to the target area when the distributed lock statuses corresponding to all the distributed resource access requests are locked; Preferably, before obtaining the batch lock corresponding to the target area when the distributed lock statuses corresponding to all the distributed resource access requests are locked, the method further includes: For each distributed resource access request, determine the distributed lock status corresponding to the distributed resource access request; When the distributed lock status corresponding to the distributed resource access request is unlocked, determine the resource competition status of the distributed resource access request; Based on the resource competition status of the distributed resource access request, determine the resource locking method corresponding to the distributed resource access request; Based on the resource locking method corresponding to the distributed resource access request, lock the partial inventory resources corresponding to the distributed resource access request, and update the distributed lock status corresponding to the distributed resource access request to the locked status.

3. The inventory method of the swap station assets according to claim 2, wherein The step of "based on the resource locking method corresponding to the distributed resource access request, lock the partial inventory resources corresponding to the distributed resource access request" includes: When the resource locking method is the first locking method, lock the partial inventory resources corresponding to the distributed resource access request through a specified thread; And / or When the resource locking method is the second locking method, determine the resource competition queue for the resources to be inventoried corresponding to the distributed resource access request; Put the distributed resource access request into the resource competition queue to request and wait for resource allocation; When the resources to be inventoried corresponding to the distributed resource access request are requested, lock the partial inventory resources corresponding to the distributed resource access request through a specified thread.

4. The inventory method of the replacement power station assets according to claim 3, wherein, The step of "put 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, request the allocation of the corresponding resources to be inventoried in the resource competition queue to obtain a first resource request result; When the first resource request result fails, re-obtain the current lock status corresponding to the distributed resource access request; When the current lock status 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 allocation of the corresponding resources to be inventoried in the resource competition queue to obtain a second resource request result; In the case where the second resource request result fails, re-obtain the current lock status and re-request the allocation of the corresponding resources to be inventoried until the resources to be inventoried corresponding to the distributed resource access request are 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 resource request allocation failure 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 inventory method for the swapping station assets according to claim 1, wherein, Before performing an asset inventory of the target area of the swap station, the method further includes: According to business needs and the characteristics of the swap station, divide the swap station into multiple areas; Create a regional lock table in a preset database to record the batch lock status of each area through the regional lock table; Create a distributed lock service to acquire and release the batch locks of each area through the distributed lock service; And / or, Recording the batch lock status of the target area as a held lock includes: recording the batch lock status of the target area as a held lock in the regional lock table.

6. The inventory method of the swap station assets according to claim 1, wherein The acquiring the batch lock of the target area through the distributed lock service includes: By calling the distributed lock service, initiate an acquisition request for acquiring the batch lock of the target area; Query the batch lock status of the target area in the regional lock table according to the acquisition request; If the batch lock status of the target area is unlocked, acquire the batch lock of the target area; And / or, If the batch lock status of the target area is locked, the method further includes: After a preset time, by calling the distributed lock service, re-initiate an acquisition request for acquiring the batch lock of the target area; Query the batch lock status of the target area in the regional lock table according to the re-initiated acquisition request; If the batch lock status of the target area is unlocked, acquire the batch lock of the target area.

7. The inventory method of the swap station assets according to claim 1, wherein, The performing an asset detail data inventory of the target area according to the batch lock includes: When holding the batch lock, perform an inventory of the asset detail data of the target area through multi-threading; Preferably, performing an asset detail data inventory of the target area includes: Set the inventory of asset detail data as multiple subtasks, and coordinate the concurrent execution of the inventory of asset detail data through a distributed task queue; Preferably, the inventory of asset detail data for the target area includes: Convert the inventory of asset detail data for the target area into an asynchronous task through an asynchronous message queue, and process the asynchronous task to complete the inventory of asset detail data for the target area.

8. An inventory device for the assets of a battery swapping station, characterized in that, The device includes: An acquisition unit, when performing an asset inventory of the target area of the battery swapping station, acquires a batch lock for the target area through a distributed lock service, and records the batch lock status of the target area as holding the lock; An inventory unit, performs an inventory of asset detail data for the target area according to the batch lock.

9. An inventory device for a power exchange station asset, 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 to enable the at least one processor to implement the inventory method of the battery swapping station assets described in 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 inventory method of the battery swapping station assets described in any one of 1-7.

Images