A method and system for reading and writing cloud-native distributed state storage databases with anti-blocking

Abstract

The present application relates to the field of cloud native technology, and provides an anti-blocking cloud native distributed state storage database reading and writing method and system. The method includes: when the amount of pending write tasks of the first cloud native distributed state storage database is greater than the first preset threshold or the write task processing delay is greater than the second preset threshold, determining the first resource object type that causes the above situation; deploying a second cloud native distributed state storage database in the container cloud platform; in response to the second resource object type corresponding to the read and write request matching the first resource object type, indicating that the read and write request points to the second cloud native distributed state storage database. In this way, the read and write requests that may cause the cloud native distributed state storage database to be blocked are transferred, which fundamentally and dynamically solves the problem of write blocking of the cloud native distributed state storage database, and improves the availability of the cloud native distributed state storage database and the resource utilization of the container cloud platform.

Description

Technical Field

[0001] The present application relates to the field of cloud native technology, and in particular to an anti-blocking cloud native distributed state storage database reading and writing method, system, computer-readable storage medium and electronic device. Background Art

[0002] The cloud-native distributed state storage database is a distributed database system deployed in the container cloud platform and used to store the state data of the container cloud platform, such as ETCD in the Kubernetes cluster.

[0003] With the continuous development of cloud-native technology, the scale of container cloud platforms used by enterprises is also expanding. Managing large-scale container cloud platforms will generate a large amount of state data, which will put tremendous pressure on the cloud-native distributed state storage database responsible for storing the state data of the container cloud platform. Once the pressure is too great and the cloud-native distributed state storage database is blocked, the subsequent read and write requests of the cloud-native distributed state storage database will be affected.

[0004] In the related technology, the cloud-native distributed state storage database is installed on a higher-performance disk, or the state data is split according to different resource object types and stored in different pre-deployed cloud-native distributed state storage databases, or when the control node of the cloud-native distributed state storage database fails, the read and write requests are switched to the working node.

[0005] However, none of the above methods can fundamentally and dynamically solve the problem of write blocking in cloud-native distributed state storage databases based on the writing status of state data.

[0006] Therefore, it is necessary to provide an improved technical solution to address the above-mentioned deficiencies in the prior art. Summary of the invention

[0007] The purpose of this application is to provide an anti-blocking cloud-native distributed state storage database reading and writing method, system, computer-readable storage medium and electronic device to solve or alleviate the problems existing in the above-mentioned prior art.

[0008] In order to achieve the above objectives, this application provides the following technical solutions:

[0009] The embodiment of the present application provides an anti-blocking cloud native distributed state storage database reading and writing method, including:

[0010] In response to the amount of pending write tasks of the first cloud native distributed state storage database being greater than a first preset threshold or the delay in processing the write tasks being greater than a second preset threshold, determining a first resource object type corresponding to a first write request that causes the amount of pending write tasks of the first cloud native distributed state storage database to be greater than the first preset threshold or the delay in processing the write tasks to be greater than the second preset threshold;

[0011] The first cloud native distributed state storage database is distributedly deployed in multiple first container groups, and the first container groups are located in multiple first nodes of the container cloud platform; the first resource object type has one or more types;

[0012] Deploying a second cloud-native distributed state storage database in the container cloud platform;

[0013] In response to the second resource object type corresponding to the read / write request matching the first resource object type, indicating that the read / write request is directed to the second cloud-native distributed state storage database.

[0014] In the above solution, the second cloud-native distributed state storage database is deployed in the container cloud platform, including:

[0015] The same number of first containers are started in the first container group according to the number of the first resource object types, and a second cloud-native distributed state storage database is deployed in each of the first containers.

[0016] In the above solution, the second cloud-native distributed state storage database is deployed in the container cloud platform, including:

[0017] The same number of second container groups are started in the container cloud platform according to the number of the first resource object types, and a second cloud-native distributed state storage database is deployed in each of the second container groups.

[0018] In the above solution, starting the same number of second container groups in the container cloud platform according to the number of the first resource object type includes:

[0019] Selecting at least one second node in the container cloud platform;

[0020] The same number of the second container groups is started in the at least one second node according to the number of the first resource object type, and a second cloud-native distributed state storage database is deployed in each of the second nodes.

[0021] In the above solution, the selecting at least one second node in the container cloud platform includes:

[0022] Detecting whether the remaining hardware resources of the container cloud platform are greater than a third preset threshold;

[0023] In response to the remaining hardware resources of the container cloud platform being less than or equal to the third preset threshold, selecting at least one third node from the spare nodes and incorporating the node into the management of the container cloud platform;

[0024] The third node is selected as the second node.

[0025] In the above solution, after deploying the second cloud-native distributed state storage database in the container cloud platform, the method further includes:

[0026] Obtain a mapping relationship between the first resource object type and the second cloud-native distributed state storage database, and an access path to the second cloud-native distributed state storage database;

[0027] Correspondingly,

[0028] The read / write request is a second write request, and the indication that the read / write request points to the second cloud-native distributed state storage database is specifically:

[0029] Determine, according to a mapping relationship between the first resource object type and the second cloud-native distributed state storage database, a corresponding relationship between the second write request and the second cloud-native distributed state storage database;

[0030] According to the access path of the second cloud-native distributed state storage database, the second resource object is written into the second cloud-native distributed state storage database.

[0031] In the above solution, after deploying the second cloud-native distributed state storage database in the container cloud platform, the method further includes:

[0032] Obtaining the deployment time of the second cloud-native distributed state storage database;

[0033] Correspondingly,

[0034] The read / write request is a read request, and the read request includes a keyword identifier, and the indication that the read / write request points to the second cloud-native distributed state storage database is specifically:

[0035] According to the keyword identifier, determining all query results corresponding to the keyword identifier from the first cloud native distributed state storage database and the second cloud native distributed state storage database;

[0036] A final query result is determined according to the deployment time of the second cloud-native distributed state storage database and all the query results, and the final query result is returned as a processing result of the read request.

[0037] The embodiment of the present application also provides an anti-blocking cloud native distributed state storage database read-write system, including:

[0038] A determination unit, configured to determine, in response to the amount of pending write tasks of the first cloud native distributed state storage database being greater than a first preset threshold or the write task processing delay being greater than a second preset threshold, a first resource object type corresponding to a first write request that causes the amount of pending write tasks of the first cloud native distributed state storage database to be greater than the first preset threshold or the write task processing delay to be greater than the second preset threshold;

[0039] The first cloud native distributed state storage database is distributedly deployed in multiple first container groups, and the first container groups are located in multiple first nodes of the container cloud platform; the first resource object type has one or more types;

[0040] A deployment unit, configured to deploy a second cloud-native distributed state storage database in the container cloud platform;

[0041] An indication unit is configured to indicate that the read / write request points to the second cloud-native distributed state storage database in response to a second resource object type corresponding to the read / write request matching the first resource object type.

[0042] An embodiment of the present application also provides a computer-readable storage medium on which a computer program is stored. The computer program is an anti-blocking cloud-native distributed state storage database reading and writing method as described above.

[0043] An embodiment of the present application also provides an electronic device, comprising: a memory, a processor, and a program stored in the memory and executable on the processor, wherein when the processor executes the program, the anti-blocking cloud-native distributed state storage database reading and writing method as described above is implemented.

[0044] Beneficial effects:

[0045] In the present application, the writing status of the first cloud native distributed state storage database is monitored. When the amount of pending write tasks of the first cloud native distributed state storage database is greater than the first preset threshold or the delay of writing task processing is greater than the second preset threshold, the first resource object type corresponding to the first write request that causes the amount of pending write tasks of the first cloud native distributed state storage database to be greater than the first preset threshold or the delay of writing task processing is greater than the second preset threshold is determined; then, the second cloud native distributed state storage database is deployed in the container cloud platform; finally, when the second resource object type corresponding to the subsequent read and write request matches the first resource object type, the read and write request is indicated to point to the second cloud native distributed state storage database. In this way, according to the writing status of the first cloud native distributed state storage database, the first resource object type that causes the blockage is determined, and the read and write requests with the resource object type matching it in the subsequent read and write requests are pointed to the second cloud native distributed state storage database. The second cloud native distributed state storage database is independent of the first cloud native distributed state storage database, thereby dynamically solving the blocking problem of the first cloud native distributed state storage database and ensuring the normal processing of subsequent read and write requests. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] The drawings constituting part of the present application are used to provide a further understanding of the present application. The exemplary embodiments and descriptions of the present application are used to explain the present application and do not constitute an improper limitation on the present application. Among them:

[0047] Figure 1 A flowchart of an anti-blocking cloud-native distributed state storage database reading and writing method provided according to some embodiments of the present application;

[0048] Figure 2 A logical schematic diagram of processing read and write requests of a cloud-native distributed state storage database through a read and write management system according to some embodiments of the present application;

[0049] Figure 3 A logical schematic diagram of deploying a second cloud-native distributed state storage database in a first container group according to some embodiments of the present application;

[0050] Figure 4 A logical schematic diagram of deploying a second cloud-native distributed state storage database in a second container group on a first node according to some embodiments of the present application;

[0051] Figure 5 A logical schematic diagram of deploying a second cloud-native distributed state storage database on a second node according to some embodiments of the present application;

[0052] Figure 6A logical schematic diagram of deploying a second cloud-native distributed state storage database when the first container group provided in some embodiments of the present application is a static container group;

[0053] Figure 7 A logical schematic diagram of deploying a second cloud-native distributed state storage database when the first container group provided in some embodiments of the present application is a common container group;

[0054] Figure 8 A logical diagram of processing a write request according to some embodiments of the present application;

[0055] Fig. 9 A logical diagram of processing a read request according to some embodiments of the present application;

[0056] Fig.10 A schematic diagram of the structure of an anti-blocking cloud-native distributed state storage database read-write system provided according to some embodiments of the present application;

[0057] Fig.11 A schematic diagram of the structure of an electronic device provided according to some embodiments of the present application;

[0058] Fig.12 A hardware structure diagram of an electronic device provided according to some embodiments of the present application. DETAILED DESCRIPTION

[0059] The present application will be described in detail below with reference to the accompanying drawings and in conjunction with embodiments. Each example is provided by way of explanation of the present application and does not limit the present application. In fact, it will be clear to those skilled in the art that modifications and variations may be made in the present application without departing from the scope or spirit of the present application. For example, a feature shown or described as a part of an embodiment may be used in another embodiment to produce yet another embodiment. Therefore, it is desired that the present application includes such modifications and variations within the scope of the appended claims and their equivalents.

[0060] In the following description, the terms "first / second / third" involved are merely used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first / second / third" can be interchanged with a specific order or sequence where permitted, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0061] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which the present disclosure belongs. The terms used herein are only for the purpose of describing the embodiments of the present disclosure and are not intended to limit the present disclosure.

[0062] As described in the background technology, the cloud-native distributed state storage database is a distributed database system deployed in the container cloud platform and used to store the state data of the container cloud platform. The state data of all nodes in the entire container cloud platform are stored in the cloud-native distributed state storage database.

[0063] With the continuous development of cloud-native technology, the scale of container cloud platforms used by enterprises has also continued to expand. Currently in production practice, container cloud platforms consisting of dozens or even hundreds of nodes have emerged. Managing container cloud platforms with such a large number of nodes puts tremendous pressure on the cloud-native distributed state storage database responsible for storing state data.

[0064] In the related art, the above problems are solved by the following methods:

[0065] Method 1: Install the cloud-native distributed state storage database on a higher-performance disk to improve hardware performance, thereby optimizing the read and write performance of the cloud-native distributed state storage database at the physical level.

[0066] Method 2: Split the state data storage according to the different resource object types corresponding to the state data, and store the state data of different resource object types in different pre-deployed cloud-native distributed state storage databases. In other words, read and write requests for different resource object types are responded to by different cloud-native distributed state storage databases, thereby dispersing the pressure on a single cloud-native distributed state storage database.

[0067] Method 3: The cloud-native distributed state storage database is a distributed database system consisting of control nodes and working nodes. When the cloud-native distributed state storage database can process read and write requests normally, the control node responds to various read and write requests and synchronizes the data stored in the control node to the cloud-native distributed state storage database of other nodes in real time. When the control node fails, the cloud-native distributed state storage database immediately switches the read and write requests to the working node, and the cloud-native distributed state storage database in the working node responds to the read and write requests to avoid affecting the reading and writing of all state data when the control node fails.

[0068] However, the above technical solution cannot dynamically solve the problem of write blocking of cloud native distributed state storage database according to the writing situation of state data. Specifically, in method 1, higher performance disks also have performance ceilings. As the cluster scale expands, the performance of the hardware will still be bottlenecked, resulting in write blocking of cloud native distributed state storage database. In method 2, the pressure of a single cloud native distributed state storage database is dispersed to multiple cloud native distributed state storage databases. However, on the one hand, different resource object types have different write pressures. For resource object types with less write pressure, pre-deploying corresponding cloud native distributed state storage databases will lead to a waste of container cloud platform resources to a certain extent; on the other hand, when new resource object types cause write blocking, this method cannot be handled dynamically, and the administrator needs to redeploy the corresponding cloud native distributed state storage database, which has poor flexibility. In method 3, although the high availability of cloud native distributed state storage database is achieved by switching nodes, the node switching is performed when the control node fails, and it still cannot solve the problem of how to respond to subsequent requests when the control node is blocked from writing.

[0069] It can be seen that the above-mentioned related technologies are unable to dynamically solve the problem of cloud-native distributed state storage database write blocking according to the writing status of state data to respond normally to subsequent requests.

[0070] To this end, the present application provides an anti-blocking cloud-native distributed state storage database reading and writing method, system, computer-readable storage medium and electronic device, which monitors the data writing situation of a first cloud-native distributed state storage database in real time. When it is monitored that the amount of pending write tasks of the first cloud-native distributed state storage database is greater than a first preset threshold or the write task processing delay is greater than a second preset threshold, the first resource object type corresponding to the first write request that causes the amount of pending write tasks of the first cloud-native distributed state storage database to be greater than the first preset threshold or the write task processing delay to be greater than the second preset threshold is determined; then a second cloud-native distributed state storage database independent of the first cloud-native distributed state storage database is deployed in the container cloud platform as a dedicated cloud-native distributed state storage database for processing data corresponding to the first resource object, thereby dynamically reducing the pressure on the first cloud-native distributed state storage database according to the data writing situation, solving the problem of write blocking in the first cloud-native distributed state storage database from the root, and improving resource utilization.

[0071] Exemplary Methods

[0072] The present application embodiment provides an anti-blocking cloud native distributed state storage database reading and writing method, such as Figure 1As shown, the method includes:

[0073] Step S101, in response to the amount of pending write tasks of the first cloud native distributed state storage database being greater than a first preset threshold or the write task processing delay being greater than a second preset threshold, determine the first resource object type corresponding to the first write request that causes the amount of pending write tasks of the first cloud native distributed state storage database to be greater than the first preset threshold or the write task processing delay to be greater than the second preset threshold.

[0074] Among them, the first cloud-native distributed state storage database is distributedly deployed in multiple first container groups, and the first container groups are located in multiple first nodes of the container cloud platform.

[0075] It should be understood that the first cloud-native distributed state storage database, as a distributed database, can be distributedly deployed in multiple nodes in the container cloud platform. The container group used to deploy the first cloud-native distributed state storage database in each node is called the first container group, and the node on which the first container group is deployed is called the first node.

[0076] In an embodiment of the present application, a first cloud-native distributed state storage database is containerized and deployed in a container cloud platform, and data writing status of the first cloud-native distributed state storage database is monitored. When it is monitored that the amount of pending write tasks of the first cloud-native distributed state storage database is greater than a first preset threshold or the write task processing delay is greater than a second preset threshold, the first resource object type corresponding to the first write request that causes the amount of pending write tasks of the first cloud-native distributed state storage database to be greater than the first preset threshold or the write task processing delay to be greater than the second preset threshold is determined.

[0077] Specifically, see Figure 2 , a first cloud native distributed state storage database is containerized and deployed in a container cloud platform, and a receiver, a read-write manager, and a monitor are containerized and deployed. The receiver, the read-write manager, and the monitor together constitute a read-write management system of the cloud native distributed state storage database, so that the read-write management system monitors the data writing status of the first cloud native distributed state storage database.

[0078] The receiver interacts with the container cloud platform unified interface to receive read and write requests from the container cloud platform unified interface and reply to the container cloud platform unified interface with the request result. In addition, the receiver is also used to forward the read and write requests to the read and write manager.

[0079] The read-write manager performs corresponding read and write operations on the cloud-native distributed state storage database based on the read and write requests issued by the receiver, and returns the results to the receiver.

[0080] Here, the read / write request includes a write request and a read request. Specifically, the write request includes an add data request, a delete data request, and a modify data request, and the read request is a query data request.

[0081] The monitor is used to monitor the operating status of the first cloud native distributed state storage database. Once it is monitored that the amount of pending write tasks in the first cloud native distributed state storage database is greater than the first preset threshold or the write task processing delay is greater than the second preset threshold, that is, the write pressure is too high or the write is blocked, it is determined that the first resource object type corresponding to the first write request that causes the amount of pending write tasks in the first cloud native distributed state storage database to be greater than the first preset threshold or the write task processing delay to be greater than the second preset threshold.

[0082] It can be understood that the monitor monitors the operating status of the first cloud native distributed state storage database, including but not limited to monitoring various operating indicators and disk throughput pressure of the cloud native distributed state storage database, for example, information such as the amount of pending tasks, delays and throughput. Among them, the amount of pending tasks specifically includes the amount of pending write tasks and the amount of pending read tasks, the delay specifically includes information such as the average delay per request task and the average network round-trip delay, and the throughput specifically includes information such as the average disk IO volume per second and the average read and write request task volume per second. By monitoring the above information in real time, it is possible to promptly determine whether the cloud native distributed state storage database is blocked from writing.

[0083] In an embodiment of the present application, the first resource object type has one or more types. The read-write management system dynamically identifies the different resource object types corresponding to the first write request that causes the first cloud-native distributed state storage database to be blocked, and identifies them as the first resource object type.

[0084] In actual applications, when the monitor detects that writing to the first cloud-native distributed state storage database is blocked, the first resource object type corresponding to the first write request that caused the write blockage is determined, and the data corresponding to the first resource object type is defined as "hot data". At the same time, the first resource object type is synchronized to the read-write manager so that the "hot data" can be processed accordingly in subsequent read-write requests.

[0085] Furthermore, a first cloud native distributed state storage database is containerized and deployed in the container cloud platform. For example, the container cloud platform may be a Kubernetes cluster. A first ETCD is containerized and deployed in the Kubernetes cluster. The first ETCD stores all state data of the Kubernetes cluster. In order to monitor the data writing status of the first ETCD, a receiver, a read / write manager, and a monitor are containerized and deployed in the Kubernetes cluster. The three together constitute an ETCD read / write management system.

[0086] Among them, the receiver directly interacts with the API-Server component of the Kubernetes cluster, receives read and write requests from the API-Server component, and replies to the API-Server component with request results.

[0087] The read / write manager performs corresponding read / write operations on etcd according to the read / write requests sent by the receiver and returns the results to the receiver.

[0088] The monitor is used to monitor the operating status of the first ETCD. Once it is monitored that the amount of pending write tasks of the first ETCD is greater than the first preset threshold or the write task processing delay is greater than the second preset threshold, the resource object type corresponding to the first write request that causes the amount of pending write tasks of the first ETCD to be greater than the first preset threshold or the write task processing delay to be greater than the second preset threshold will be marked (i.e., recorded as the first resource object type), and the data corresponding to this type of resource object will be defined as "hot data".

[0089] Step S102: deploy a second cloud-native distributed state storage database in the container cloud platform.

[0090] In an embodiment of the present application, when the monitor detects that the amount of pending write tasks of the first cloud native distributed state storage database is greater than the first preset threshold or the delay in processing the write tasks is greater than the second preset threshold, in order to share the pressure of the first cloud native distributed state storage database, a second cloud native distributed state storage database is deployed in the container cloud platform. The second cloud native distributed state storage database is a database independent of the first cloud native distributed state storage database. As a cloud native distributed state storage database dedicated to processing "hot data", it can process read and write requests for "hot data" separately, so that the first cloud native distributed state storage database can respond to other subsequent read and write requests without being affected by "hot data".

[0091] like Figure 3As shown, when a second cloud-native distributed state storage database is deployed in a container cloud platform, a possible implementation method is: starting the same number of first containers in the first container group according to the number of first resource object types, and deploying the second cloud-native distributed state storage database in each first container.

[0092] In the embodiment of the present application, the same number of first containers are started according to the number of first resource object types, each first resource object type corresponds to a first container, and the first containers are deployed in a first container group.

[0093] Among them, the first container group is the container group where the first cloud native distributed state storage database is located. The same number of first containers as the first resource object type is started in the first container group, and the second cloud native distributed state storage database is deployed in each first container, so that the second cloud native distributed state storage database and the first cloud native distributed state storage database are deployed in the same container group, so as to process "hot data" of different resource object types on the basis of fully utilizing the container group management resources.

[0094] It should be understood that there may be multiple types of first resource objects determined in step S101. The embodiment of the present application sets up the same number of second cloud-native distributed state storage databases to distribute the processing pressure of different types of resource object types to different second cloud-native distributed state storage databases to ensure that each second cloud-native distributed state storage database can individually process the read and write requests of its corresponding "hot data".

[0095] In an exemplary scenario, when the container cloud platform is a Kubernetes cluster, the first container is started in the first container group, specifically: a new container (Container) is started as the first container in the first container group (Pod) where the first ETCD is located, which is used to deploy a dedicated ETCD for processing "hot data". Here, the dedicated ETCD for processing "hot data" is called the second ETCD.

[0096] It should be noted that if there are multiple first resource object types corresponding to the write requests that cause excessive write pressure on the first ETCD or write blocking, the data corresponding to these first resource object types are all "hot data". In each first container group where the first ETCD is located, multiple first containers with the same number as the first resource object type are started respectively to deploy second ETCDs with different "hot data". The storage of "hot data" is separated according to the corresponding resource object types, thereby dispersing the write pressure of each second ETCD.

[0097] In the embodiment of the present application, different "hot data" are processed separately by the second ETCD, and the second ETCD and the first ETCD are deployed in the same container group, which not only reduces the pressure on the first ETCD and solves the problem of write blocking in the first ETCD from the root, but also directly starts a new container in the existing container group and deploys and manages the second ETCD in the existing container group, thereby making the deployment and management of the second ETCD convenient and quick, and avoiding the consumption of cluster resources by starting a new container group.

[0098] In addition, for container cloud platforms represented by Kubernetes, the container group (Pod) is the smallest scheduling unit in the container orchestration system. Deploying the first cloud-native distributed state storage database and the second cloud-native distributed state storage database in the same container group enables the container cloud platform to uniformly manage all cloud-native distributed state storage databases.

[0099] When deploying a second cloud-native distributed state storage database in the container cloud platform, another possible implementation is: starting the same number of second container groups in the container cloud platform according to the number of the first resource object type, and deploying the second cloud-native distributed state storage database in each second container group.

[0100] In an embodiment of the present application, a second container group is started in the container cloud platform, the number of second container groups is the same as the number of first resource object types, and a second cloud-native distributed state storage database is deployed in the business container of each second container group to process the "hot data" corresponding to each first resource object type respectively.

[0101] It should be noted that, compared with the above-mentioned implementation, this implementation also sets up a second cloud-native distributed state storage database with the same number as the first resource object type, and disperses the processing pressure of different types of resource object types to different second cloud-native distributed state storage databases to ensure that each second cloud-native distributed state storage database can independently process the read and write requests of its corresponding "hot data".

[0102] Different from the above implementation, this implementation deploys the second cloud native distributed state storage database in a second container group independent of the first container group, thereby unbinding the second cloud native distributed state storage database from the first cloud native distributed state storage database, allowing the container cloud platform to freely deploy the second cloud native distributed state storage database according to actual conditions.

[0103] Specifically, the aforementioned starting the same number of second container groups in the container cloud platform according to the number of the first resource object type includes: selecting at least one second node in the container cloud platform; starting the same number of second container groups in the at least one second node according to the number of the first resource object type.

[0104] Specifically, when deploying the second cloud-native distributed state storage database, you first need to select a node for deploying the second container group from all the nodes in the container cloud platform. Specifically, all the nodes in the container cloud platform can be divided into a first node on which the first container group is deployed and other nodes except the first node. For ease of explanation, the embodiment of the present application refers to the node for deploying the second container group as the second node.

[0105] When selecting a second node for deploying the second container group from all nodes of the container cloud platform, you can select the first node on which the first container group is deployed, or you can select other nodes other than the first node, which is not limited in this embodiment of the present application.

[0106] Based on the above description of the first cloud-native distributed state storage database, it can be known that the first cloud-native distributed state storage database is a distributed database that can be distributedly deployed in multiple first nodes in the container cloud platform. Similarly, the second cloud-native distributed state storage database can be deployed alone in a second node or distributed in multiple second nodes. The second node can be the first node on which the first container group is deployed, or it can be any node other than the first node.

[0107] When the second node is the first node on which the first container group is deployed, the same number of second container groups can be started in the first node according to the number of the first resource object type, and a second cloud-native distributed state storage database can be deployed in each second container group.

[0108] Specifically, Figure 4 As shown, the first node is the node where the first container group is located. According to the number of the first resource object type, the same number of second container groups are started in the first node, and a second cloud-native distributed state storage database is deployed in the business container of each second container group, so that the second cloud-native distributed state storage database and the first cloud-native distributed state storage database are deployed on the same node and in different container groups.

[0109] Exemplarily, when the container cloud platform is a Kubernetes cluster, the same number of second container groups are started in the first node according to the number of the first resource object type, specifically: according to the number of the first resource object type, a new container group is started in the first node where the first container group where the first ETCD is located as the second container group for deploying the second ETCD. Thus, the "hot data" that causes excessive writing pressure or writing blockage on the first ETCD is written into the second ETCD to reduce the pressure on the first ETCD, solving the problem of writing blockage on the first ETCD from the root.

[0110] When the second node is a node other than the first node, the same number of second container groups can be started in other nodes according to the number of the first resource object type, and a second cloud-native distributed state storage database can be deployed in each second container group.

[0111] Here, the second node is a node other than the first node where the first cloud native distributed state storage database is not deployed. Figure 5 , the second node is any other node in the container cloud platform except the first node; by starting the second container group of the same number as the first resource object type in the second node, and deploying the second cloud native distributed state storage database in the business container in each second container group. In this way, the second cloud native distributed state storage database is deployed in other nodes, so that the second cloud native distributed state storage database and the first cloud native distributed state storage database are respectively located on different nodes in the container cloud platform, and there will be no resource competition between them, thereby reducing the resource pressure of the first node and the pressure of the first cloud native distributed state storage database.

[0112] In addition, since the second node can be either the first node or any node other than the first node, when selecting at least one second node, the container cloud platform administrator is allowed to specify at least one node in the container cloud platform as the second node, or the container cloud platform can select at least one node with the highest score as the second node based on the score of each node, where the score of each node is determined based on the remaining hardware resources of the node.

[0113] It should be noted that in addition to the nodes in the container cloud platform, there are usually several spare nodes. When the remaining hardware resources of all nodes in the container cloud platform reach the bottom line, the container cloud platform is allowed to manage the spare nodes as a node in the container cloud platform. When the remaining hardware resources of the container cloud platform are sufficient, the spare nodes are in a dormant state to reduce the power consumption of the container cloud platform.

[0114] Accordingly, when deploying the second cloud-native distributed state storage database, if the remaining hardware resources of all nodes in the container cloud platform reach the bottom line, it is necessary to deploy the second cloud-native distributed state storage database on the spare node of the container cloud platform. Specifically, it is necessary to first incorporate the spare node into the container cloud platform for management, and then the monitor starts the second container group on the spare node.

[0115] As an example, when the container cloud platform is a Kubernetes cluster, the same number of second container groups are started in the second node according to the number of the first resource object type to deploy a second cloud-native distributed state storage database. Specifically, at least one second node is selected in the Kubernetes cluster, and the same number of second container groups are started in the second node according to the number of the first resource object type, and a second ETCD is deployed in the business container of each second container group.

[0116] The second node can be any node in the Kubernetes cluster or a standby node outside the Kubernetes cluster.

[0117] For deploying the second ETCD on any node in the Kubernetes cluster, the monitor can directly start a new container group on the node as the second container group.

[0118] To deploy the second ETCD on a standby node outside the Kubernetes cluster, you need to first include the standby node in the Kubernetes cluster management, and then the monitor starts a new container group on the standby node as the second container group.

[0119] Furthermore, in order to accurately determine whether it is necessary to deploy the second cloud-native distributed state storage database in the backup node, selecting at least one second node in the container cloud platform specifically includes the following steps: detecting whether the remaining hardware resources of the container cloud platform are greater than a third preset threshold; in response to the remaining hardware resources of the container cloud platform being less than or equal to the third preset threshold, selecting at least one third node from the backup nodes and incorporating it into the management of the container cloud platform; and selecting the third node as the second node.

[0120] Here, the remaining hardware resources of the container cloud platform can be the idle amount of the container cloud platform CPU, or the idle amount of the memory, or the idle amount of the disk. Correspondingly, the third preset threshold can be the minimum CPU idle value, the minimum memory idle value, or the minimum disk idle value.

[0121] When the remaining hardware resources of the container cloud platform are greater than the third preset threshold, it means that the remaining hardware resources of the container cloud platform are relatively sufficient to meet the resource requirements for deploying the second cloud-native distributed state storage database. At this time, there is no need to include the spare nodes in the container cloud platform management.

[0122] When the hardware resources of the container cloud platform are less than or equal to the third preset threshold, it means that the remaining hardware resources of the container cloud platform have reached the bottom line. At this time, at least one third node is selected from the backup nodes outside the container cloud platform and incorporated into the management of the container cloud platform to provide hardware resources, and the third node is used as the second node. In other words, when the writing of the first cloud native distributed state storage database is blocked and the hardware performance of the container cloud platform is bottlenecked, the second cloud native distributed state storage database is deployed on the backup node outside the container cloud platform to reduce the resource competition caused by the deployment of the second cloud native distributed state storage database on the first cloud native distributed state storage database.

[0123] For example, in a Kubernetes cluster, when a bottleneck in the hardware performance of the Kubernetes cluster is detected, at least one third node can be selected from the Kubernetes cluster and incorporated into the Kubernetes system management to provide hardware resources. In other words, when the writing of "hot data" is blocked and the hardware performance of the Kubernetes cluster is bottlenecked, the second ETCD is preferentially deployed on a standby node outside the Kubernetes cluster where the first ETCD is not deployed.

[0124] Furthermore, when the first cloud native distributed state storage database is containerized and deployed in the container cloud platform, the first container group where the first cloud native distributed state storage database is located can be either a common container group or a static container group.

[0125] Exemplarily, a normal container group may be a normal Pod in a Kubernetes cluster, and a static container group may be a static Pod in a Kubernetes cluster. The static Pod is directly managed by the Kubelet component of the first node, and the operation of the static Pod does not require the API-Server component, while the operation of the normal Pod requires the API-Server component to be called.

[0126] See also Figure 6 If the first container group where the first ETCD is located is a Static Pod, when it is necessary to start the first container in the first container group to deploy the second ETCD, the monitor can start the first container in the first container group where the first ETCD is located by directly modifying the Static Pod configuration file.

[0127] When it is necessary to start the second container group in the second node to deploy the second ETCD, the monitor adds the Static Pod configuration file in the second node to start the second container group in the second node.

[0128] When it is necessary to start the second container group on the standby node to deploy the second ETCD, the monitor can add the Static Pod configuration file in the standby node to start a new container group in the node as the second container group. It can be understood that when the standby node is outside the Kubernetes cluster, the standby node is first included in the Kubernetes cluster management, and then the monitor can add the Static Pod configuration file in the standby node to start a new container group in the node, that is, the second container group.

[0129] See also Figure 7 If the first container group where the first ETCD is located is a normal Pod, when it is necessary to start the first container in the first container group to deploy the second ETCD, the monitor calls the API-Server component of the Kubernetes cluster to start the first container in the first container group where the first ETCD is located.

[0130] When it is necessary to start the second container group on the second node to deploy the second ETCD, the monitor calls the API-Server component of the Kubernetes cluster to start the second container group on the second node.

[0131] Similarly, when it is necessary to start the second container group on the standby node to deploy the second ETCD, the monitor calls the API-Server component of the Kubernetes cluster to start the second container group on the standby node. It can be understood that when the standby node is outside the Kubernetes cluster, the standby node is first included in the Kubernetes cluster management, and then the monitor calls the API-Server component of the Kubernetes cluster to start the second container group on the standby node.

[0132] Step S103: In response to the second resource object type corresponding to the read / write request matching the first resource object type, indicating that the read / write request points to the second cloud-native distributed state storage database.

[0133] In an embodiment of the present application, the receiver continuously receives read and write requests from the unified interface of the container cloud platform, and when the second resource object type corresponding to the read and write request matches the first resource object type, the read and write request is indicated to point to the second cloud native distributed state storage database. In this way, the "hot data" that causes excessive write pressure or write blockage in the first cloud native distributed state storage database will be pointed to the second cloud native distributed state storage database, so as to reduce the pressure on the first cloud native distributed state storage database and solve the problem of write blockage in the cloud native distributed state storage database from the root. In addition, different types of resource objects are processed separately by different second cloud native distributed state storage databases, which disperses the pressure on each second cloud native distributed state storage database and improves the availability of the cloud native distributed state storage database.

[0134] In some embodiments, in order to enable the second cloud native distributed state storage database to process write requests corresponding to "hot data", after the second cloud native distributed state storage database is deployed in the container cloud platform, the method also includes: obtaining the mapping relationship between the first resource object type and the second cloud native distributed state storage database, and the access path of the second cloud native distributed state storage database. Correspondingly, the read and write request is a second write request, indicating that the read and write request points to the second cloud native distributed state storage database, specifically: according to the mapping relationship between the first resource object type and the second cloud native distributed state storage database, determine the corresponding relationship between the second write request and the second cloud native distributed state storage database; according to the access path of the second cloud native distributed state storage database, write the second resource object into the second cloud native distributed state storage database.

[0135] In an embodiment of the present application, a mapping relationship between a first resource object type and a second cloud-native distributed state storage database, as well as an access path to the second cloud-native distributed state storage database, is obtained through a monitor. Specifically, the monitor monitors the write status of the first cloud-native distributed state storage database in real time. When it is detected that the write pressure of the first cloud-native distributed state storage database is too high or the write is blocked, the first resource object type that causes the excessive write pressure or the write is blocked is marked, and the second cloud-native distributed state storage database is deployed in the container cloud platform according to the number of the first resource object type, and the mapping relationship between the first resource object type and the second cloud-native distributed state storage database, as well as the access path to the second cloud-native distributed state storage database, are obtained at the same time.

[0136] In actual applications, after the monitor obtains the mapping relationship between the first resource object type and the second cloud-native distributed state storage database and the access path of the second cloud-native distributed state storage database, it also synchronizes the above information and the first resource object type corresponding to the "hot data" to the read-write manager to realize the management of "hot data" related information.

[0137] In an embodiment of the present application, when the read-write request is a second write request, the correspondence between the second write request and the second cloud-native distributed state storage database is determined based on the mapping relationship between the first resource object type and the second cloud-native distributed state storage database; and the second resource object is written to the second cloud-native distributed state storage database based on the access path of the second cloud-native distributed state storage database.

[0138] Specifically, Figure 8 As shown, the processing flow of the second write request is described in detail in the scenario of the second cloud-native distributed state storage database deployed in the first container group.

[0139] See also Figure 8 ,After completing the creation of the second cloud native distributed ,state storage database, the receiver continues to receive write requests from the ,unified interface of the container cloud platform and forwards the write requests to the read-write ,manager.

[0140] The read-write manager identifies the type of the resource object pointed to by the write request to determine the second resource object type.

[0141] Exemplarily, in a Kubernetes cluster, the read-write manager can identify the type of resource object pointed to by the write request according to the request path of the write request (such as / registry / events / ns / *) to determine the type of the second resource object pointed to by the write request.

[0142] Subsequently, the read / write manager compares the second resource object type with the first resource object type according to the first resource object type corresponding to the “hot data” synchronized by the monitor to determine whether the second resource object type matches the first resource object type.

[0143] When the second resource object type matches the first resource object type, the correspondence between the second write request and the second cloud native distributed state storage database is determined based on the mapping relationship between the first resource object type and the second cloud native distributed state storage database; according to the access path of the second cloud native distributed state storage database, the second resource object is written into the second cloud native distributed state storage database.

[0144] It can be understood that the cloud-native distributed state storage database has a multi-version concurrency control (MVCC) feature. Therefore, the content written to the cloud-native distributed state storage data (including the first cloud-native distributed state storage data and the second cloud-native distributed state storage data) is an update to the data.

[0145] When the second resource object type does not match the first resource object type, indicating that the second resource object type is not related to "hot data", the second write request is directed to the first cloud-native distributed state storage database, that is, the update to the data is written to the first cloud-native distributed state storage database.

[0146] After the second cloud-native distributed state storage database is deployed in the container cloud platform, in order to respond to the data query request (i.e., read request) to obtain the correct query result, in some embodiments, the method further includes: obtaining the deployment time of the second cloud-native distributed state storage database. Correspondingly, the read-write request is a read request, and the read request includes a keyword identifier, indicating that the read-write request points to the second cloud-native distributed state storage database, specifically: according to the keyword identifier, all query results corresponding to the keyword identifier are determined from the first cloud-native distributed state storage database and the second cloud-native distributed state storage database; the final query result is determined according to the deployment time of the second cloud-native distributed state storage database and all query results, and the final query result is returned as the processing result of the read request.

[0147] In an embodiment of the present application, after the second cloud native distributed state storage database is deployed, the deployment time of the second cloud native distributed state storage database is obtained through the monitor, and the deployment time of the second cloud native distributed state storage database is synchronized to the receiver.

[0148] Specifically, Fig. 9 As shown, the processing flow of the read request is described in detail in the scenario of the second cloud-native distributed state storage database deployed in the first container group.

[0149] See also Fig. 9 After completing the creation of the second cloud native distributed state storage database, the receiver continues to receive a read request, i.e., a data query request, from the container cloud platform unified interface. The data query request includes a keyword identifier, such as a key for query. After receiving the read request, the receiver forwards the read request to the read-write manager.

[0150] The read-write manager identifies the type of the resource object pointed to by the read request to determine the second resource object type.

[0151] Exemplarily, in a Kubernetes cluster, the read-write manager can identify the type of resource object pointed to by the read request according to the request path of the read request (such as / registry / events / ns / *) to determine the second resource object type of the read request.

[0152] Subsequently, the read / write manager compares the second resource object type with the first resource object type according to the first resource object type corresponding to the “hot data” synchronized by the monitor to determine whether the second resource object type matches the first resource object type.

[0153] When the second resource object type matches the first resource object type, all query results corresponding to the Key are determined from the first cloud native distributed state storage database and the second cloud native distributed state storage database using the Key according to the mapping relationship between the first resource object type and the second cloud native distributed state storage database and the access path of the second cloud native distributed state storage database; the final query result is determined according to the deployment time of the second cloud native distributed state storage database and all query results, and the final query result is returned to the receiver as the processing result of the read request.

[0154] Here, with the help of the MVCC characteristics of the cloud-native distributed state storage database, the receiver can determine the latest query result based on the deployment time of the second cloud-native distributed state storage database and all query results as the final query result corresponding to the Key. In this way, the MVCC characteristics of the cloud-native distributed state storage database are fully utilized. When querying data, all corresponding data is read from the first cloud-native distributed state storage database and the second cloud-native distributed state storage database, and the latest query data is determined based on all corresponding data as the processing result of the read request, so that the data stored in different cloud-native distributed state storage databases can be queried uniformly.

[0155] When the second resource object type does not match the first resource object type, indicating that the second resource object type is not related to the "hot data", the Key is used to read the corresponding latest query result from the first cloud native distributed state storage database as the final query result corresponding to the Key.

[0156] In summary, in this application, the writing situation of the first cloud native distributed state storage database is monitored, and when it is monitored that the amount of pending write tasks of the first cloud native distributed state storage database is greater than the first preset threshold or the write task processing delay is greater than the second preset threshold, the first resource object type corresponding to the first write request that causes the amount of pending write tasks of the first cloud native distributed state storage database to be greater than the first preset threshold or the write task processing delay to be greater than the second preset threshold is determined; then, the second cloud native distributed state storage database is deployed in the container cloud platform; finally, when the second resource object type corresponding to the subsequent read and write requests matches the first resource object type, the read and write requests are indicated to point to the second cloud native distributed state storage database. In this way, according to the writing situation of the first cloud native distributed state storage database, the first resource object type that causes the blockage is determined, and the subsequent read and write requests are directed to the second cloud native distributed state storage database that is independent of the first cloud native distributed state storage database, thereby dynamically solving the blocking problem of the first cloud native distributed state storage database and ensuring the normal processing of subsequent read and write requests.

[0157] Exemplary Systems

[0158] The present application also provides an anti-blocking cloud native distributed state storage database read-write system, see Fig.10 , Fig.10 is a schematic diagram of the structure of an anti-blocking cloud native distributed state storage database read-write system provided according to some embodiments of the present application, such as Fig.10 As shown, the system includes: a determination unit 1001, a deployment unit 1002 and an instruction unit 1003. Among them:

[0159] Determination unit 1001 is configured to determine, in response to the amount of pending write tasks of the first cloud native distributed state storage database being greater than a first preset threshold or the write task processing delay being greater than a second preset threshold, a first resource object type corresponding to a first write request that causes the amount of pending write tasks of the first cloud native distributed state storage database to be greater than the first preset threshold or the write task processing delay to be greater than the second preset threshold.

[0160] Among them, the first cloud native distributed state storage database is distributedly deployed in multiple first container groups, the first container groups are located in multiple first nodes of the container cloud platform, and the first resource object type has one or more types.

[0161] The deployment unit 1002 is configured to deploy a second cloud-native distributed state storage database in the container cloud platform.

[0162] The indication unit 1003 is configured to indicate that the read / write request points to the second cloud-native distributed state storage database in response to the second resource object type corresponding to the read / write request matching the first resource object type.

[0163] The anti-blocking cloud-native distributed state storage database read-write system provided in the embodiments of the present application can implement the steps and processes of the anti-blocking cloud-native distributed state storage database read-write method of any of the above embodiments, and achieve the same technical effects, which will not be repeated here one by one.

[0164] Exemplary Devices

[0165] Fig.11 Schematic diagram of the structure of an electronic device provided according to some embodiments of the present application; Fig.11 As shown, the electronic device includes:

[0166] One or more processors 1101;

[0167] A computer-readable medium can be configured to store one or more programs 1102. When one or more processors 1101 execute one or more programs 1102, the following steps are implemented: in response to the amount of pending write tasks of the first cloud native distributed state storage database being greater than a first preset threshold or the write task processing delay being greater than a second preset threshold, determine the first resource object type corresponding to the first write request that causes the amount of pending write tasks of the first cloud native distributed state storage database to be greater than the first preset threshold or the write task processing delay to be greater than the second preset threshold; wherein the first cloud native distributed state storage database is distributedly deployed in multiple first container groups, and the first container groups are located in multiple first nodes of the container cloud platform; there are one or more first resource object types; deploy a second cloud native distributed state storage database in the container cloud platform; in response to the second resource object type corresponding to the read / write request matching the first resource object type, indicate that the read / write request points to the second cloud native distributed state storage database.

[0168] Fig.12 The hardware structure of the electronic device provided according to some embodiments of the present application; Fig.12 As shown, the hardware structure of the electronic device may include: a processor 1201 , a communication interface 1202 , a computer-readable medium 1203 and a communication bus 1204 .

[0169] The processor 1201 , the communication interface 1202 , and the computer-readable storage medium 1203 communicate with each other via a communication bus 1204 .

[0170] Optionally, the communication interface 1202 may be an interface of a communication module, such as an interface of a GSM module.

[0171] Among them, the processor 1201 can be specifically configured to: in response to the amount of pending write tasks of the first cloud native distributed state storage database being greater than the first preset threshold or the write task processing delay being greater than the second preset threshold, determine the first resource object type corresponding to the first write request that causes the amount of pending write tasks of the first cloud native distributed state storage database to be greater than the first preset threshold or the write task processing delay to be greater than the second preset threshold; wherein the first cloud native distributed state storage database is distributedly deployed in multiple first container groups, and the first container groups are located in multiple first nodes of the container cloud platform; there are one or more first resource object types; deploy a second cloud native distributed state storage database in the container cloud platform; in response to the second resource object type corresponding to the read and write request matching the first resource object type, indicate that the read and write request points to the second cloud native distributed state storage database.

[0172] The processor 1201 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc. It may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The disclosed methods, steps and logic block diagrams in the embodiments of the present application may be implemented or executed. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0173] The electronic device of the embodiment of the present application exists in various forms, including but not limited to:

[0174] (1) Mobile communication devices: These devices are characterized by their mobile communication functions and their main purpose is to provide voice and data communications. These terminals include: smart phones (e.g., iPhone), multimedia phones, functional phones, and low-end phones.

[0175] (2) Ultra-mobile personal computer devices: These devices fall into the category of personal computers, have computing and processing capabilities, and generally also have mobile Internet access features. These terminals include: PDA, MID and UMPC devices, such as iPad.

[0176] (3) Portable entertainment devices: These devices can display and play multimedia content. They include audio and video players (such as iPods), handheld game consoles, e-books, smart toys, and portable car navigation devices.

[0177] (4) Server: A device that provides computing services. The server consists of a processor, hard disk, memory, system bus, etc. The server is similar to a general computer architecture, but because it needs to provide highly reliable services, it has higher requirements in terms of processing power, stability, reliability, security, scalability, and manageability.

[0178] (5) Other electronic devices with data interaction functions.

[0179] It should be pointed out that, according to the needs of implementation, the various components / steps described in the embodiments of the present application can be split into more components / steps, or two or more components / steps or partial operations of components / steps can be combined into new components / steps to achieve the purpose of the embodiments of the present application.

[0180] The above-mentioned method according to the embodiment of the present application can be implemented in hardware, firmware, or implemented as software or computer code that can be stored in a recording medium (such as a CD ROM, RAM, floppy disk, hard disk or magneto-optical disk), or implemented as a computer code originally stored in a remote recording medium or a non-temporary machine storage medium downloaded through a network and to be stored in a local recording medium, so that the method described herein can be stored in such software processing on a recording medium using a general-purpose computer, a dedicated processor or programmable or dedicated hardware (such as an ASIC or FPGA). It can be understood that a computer, a processor, a microprocessor controller or programmable hardware includes a storage component (e.g., RAM, ROM, flash memory, etc.) that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor or hardware, the anti-blocking cloud native distributed state storage database reading and writing method described herein is implemented. In addition, when a general-purpose computer accesses the code for implementing the method shown herein, the execution of the code converts the general-purpose computer into a dedicated computer for executing the method shown herein.

[0181] Those of ordinary skill in the art will appreciate that the units and method steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and constraints involved in the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the embodiments of the present application.

[0182] It should be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device and system embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiments.

[0183] The device and system embodiments described above are merely illustrative, wherein the units not shown as separate may or may not be physically separated, and the units not shown as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Those of ordinary skill in the art may understand and implement it without creative work.

[0184] The above description is only a preferred embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A method for reading and writing a cloud-native distributed state storage database with an anti-blocking feature, characterized in that: include: In response to the amount of pending write tasks of the first cloud native distributed state storage database being greater than a first preset threshold or the delay in processing the write tasks being greater than a second preset threshold, determining a first resource object type corresponding to a first write request that causes the amount of pending write tasks of the first cloud native distributed state storage database to be greater than the first preset threshold or the delay in processing the write tasks to be greater than the second preset threshold; The first cloud native distributed state storage database is distributedly deployed in multiple first container groups, and the first container groups are located in multiple first nodes of the container cloud platform; the first resource object type has one or more types; Deploying a second cloud-native distributed state storage database in the container cloud platform; In response to a second resource object type corresponding to the read / write request matching the first resource object type, indicating that the read / write request is directed to the second cloud-native distributed state storage database; After deploying the second cloud-native distributed state storage database in the container cloud platform, the method further includes: Obtain a mapping relationship between the first resource object type and the second cloud-native distributed state storage database, and an access path to the second cloud-native distributed state storage database; Correspondingly, The read / write request is a second write request, and the indication that the read / write request points to the second cloud-native distributed state storage database is specifically: Determine, according to a mapping relationship between the first resource object type and the second cloud-native distributed state storage database, a corresponding relationship between the second write request and the second cloud-native distributed state storage database; Writing the second resource object into the second cloud native distributed state storage database according to the access path of the second cloud native distributed state storage database; After deploying the second cloud-native distributed state storage database in the container cloud platform, the method further includes: Obtaining the deployment time of the second cloud-native distributed state storage database; Correspondingly, The read / write request is a read request, and the read request includes a keyword identifier, and the indication that the read / write request points to the second cloud-native distributed state storage database is specifically: According to the keyword identifier, determining all query results corresponding to the keyword identifier from the first cloud native distributed state storage database and the second cloud native distributed state storage database; A final query result is determined according to the deployment time of the second cloud-native distributed state storage database and the entire query results, and the final query result is returned as a processing result of the read request.

2. The anti-blocking cloud native distributed state storage database reading and writing method according to claim 1 is characterized in that: The deploying a second cloud-native distributed state storage database in the container cloud platform includes: The same number of first containers are started in the first container group according to the number of the first resource object types, and a second cloud-native distributed state storage database is deployed in each of the first containers.

3. The anti-blocking cloud native distributed state storage database reading and writing method according to claim 1 is characterized in that: The deploying a second cloud-native distributed state storage database in the container cloud platform includes: The same number of second container groups are started in the container cloud platform according to the number of the first resource object types, and a second cloud-native distributed state storage database is deployed in each of the second container groups.

4. The anti-blocking cloud native distributed state storage database reading and writing method according to claim 3 is characterized in that: The starting the same number of second container groups in the container cloud platform according to the number of the first resource object type includes: Selecting at least one second node in the container cloud platform; The same number of the second container groups is started in the at least one second node according to the number of the first resource object type.

5. The anti-blocking cloud native distributed state storage database reading and writing method according to claim 4 is characterized in that: The selecting at least one second node in the container cloud platform includes: Detecting whether the remaining hardware resources of the container cloud platform are greater than a third preset threshold; In response to the remaining hardware resources of the container cloud platform being less than or equal to the third preset threshold, selecting at least one third node from the spare nodes and incorporating the node into the management of the container cloud platform; The third node is selected as the second node.

6. An anti-blocking cloud native distributed state storage database read-write system, characterized in that: include: A determination unit, configured to determine, in response to the amount of pending write tasks of the first cloud native distributed state storage database being greater than a first preset threshold or the write task processing delay being greater than a second preset threshold, a first resource object type corresponding to a first write request that causes the amount of pending write tasks of the first cloud native distributed state storage database to be greater than the first preset threshold or the write task processing delay to be greater than the second preset threshold; The first cloud native distributed state storage database is distributedly deployed in multiple first container groups, and the first container groups are located in multiple first nodes of the container cloud platform; the first resource object type has one or more types; A deployment unit, configured to deploy a second cloud-native distributed state storage database in the container cloud platform; an indication unit, configured to indicate, in response to a second resource object type corresponding to a read / write request matching the first resource object type, that the read / write request points to the second cloud-native distributed state storage database; After the second cloud native distributed state storage database is deployed in the container cloud platform, the method further includes: Obtain a mapping relationship between the first resource object type and the second cloud-native distributed state storage database, and an access path to the second cloud-native distributed state storage database; Correspondingly, The read / write request is a second write request, and the indication that the read / write request points to the second cloud-native distributed state storage database is specifically: Determine, according to a mapping relationship between the first resource object type and the second cloud-native distributed state storage database, a corresponding relationship between the second write request and the second cloud-native distributed state storage database; Writing the second resource object into the second cloud native distributed state storage database according to the access path of the second cloud native distributed state storage database; After the second cloud native distributed state storage database is deployed in the container cloud platform, the method further includes: Obtaining the deployment time of the second cloud-native distributed state storage database; Correspondingly, The read / write request is a read request, and the read request includes a keyword identifier, and the indication that the read / write request points to the second cloud-native distributed state storage database is specifically: According to the keyword identifier, determining all query results corresponding to the keyword identifier from the first cloud native distributed state storage database and the second cloud native distributed state storage database; A final query result is determined according to the deployment time of the second cloud-native distributed state storage database and the entire query results, and the final query result is returned as a processing result of the read request.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that: The computer program is an anti-blocking cloud-native distributed state storage database reading and writing method as described in any one of claims 1 to 5.

8. An electronic device, characterized in that: include: A memory, a processor, and a program stored in the memory and executable on the processor, wherein when the processor executes the program, the anti-blocking cloud-native distributed state storage database reading and writing method as described in any one of claims 1 to 5 is implemented.

Images