Distributed system high availability test method, device, equipment, storage medium and program product

Abstract

The invention provides a distributed system high-availability test method, which can be applied to the technical field of big data, and comprises the following steps: obtaining a test pressure request which is used for carrying out high-availability test on a to-be-tested system; based on the test pressure request, monitoring to obtain an event corresponding to the test pressure request, and establishing a connection with the to-be-tested system; after connection with the to-be-tested system, creating a plurality of IO processing threads; the IO read-write event is processed in a non-blocking IO mode through each IO processing thread, and a response result of the to-be-tested system is obtained; and based on the response result of the to-be-tested system, verifying the high availability characteristic of the to-be-tested system. The invention further provides a distributed system high-availability testing device and equipment, a storage medium and a program product.

Description

Technical Field

[0001] The present disclosure relates to the field of big data technology and can be applied to the financial field. More specifically, it relates to a distributed system high-availability testing method, device, equipment, storage medium and program product. Background Art

[0002] In order to verify the stability and reliability of the system under high load and failure conditions, stress testing is usually required. Commonly used test stress generation tools include LoadRunner (automatic load tool), Jmeter (performance testing tool), etc., which all use synchronous methods to generate and send test requests, wait for the response of the system under test, and process the response results. The entire process is executed serially. At present, the existing technology uses a blocking IO model for network communication and simulates multiple virtual users through multi-threading. The working mode of each thread is request-wait-response.

[0003] However, there are two main problems with the test stress generated by this technology. First, a large amount of CPU and thread resources of the stress generator are wasted in the waiting process. Second, in the high-availability test scenario of the distributed system, a failure of the tested system may cause the response time to become longer. At this time, a large number of stress generating threads are blocked in the process of waiting for a response, resulting in a significant reduction in the number of active stress generating threads, which in turn causes the generated test pressure to decrease, and cannot meet the requirements of the high-availability test scenario. Summary of the invention

[0004] In view of the above problems, the present disclosure provides a distributed system high-availability testing method, apparatus, device, storage medium and program product.

[0005] According to a first aspect of the present disclosure, a distributed system high-availability testing method is provided, including: obtaining a test stress request, the test stress request is used to perform a high-availability test on the system to be tested; based on the test stress request, monitoring and obtaining an event corresponding to the test stress request, and establishing a connection with the system to be tested; after connecting with the system to be tested, creating multiple IO processing threads; processing IO read and write events in a non-blocking IO manner by each IO processing thread to obtain a response result of the system to be tested; and verifying the high-availability characteristics of the system to be tested based on the response result of the system to be tested.

[0006] According to an embodiment of the present disclosure, each IO processing thread processes IO read and write events in a non-blocking IO manner to obtain a response result of the system to be tested, including: each IO processing thread processes IO write events in a non-blocking IO manner, and the write event is data for sending test pressure to the system to be tested; and each IO processing thread processes IO read events in a non-blocking IO manner, and the read event is reading the response result data returned by the system to be tested.

[0007] According to an embodiment of the present disclosure, sending test pressure data to a system to be tested includes: sending the test pressure data to the system to be tested according to a preset concurrency number and a sending interval according to test configuration information.

[0008] According to an embodiment of the present disclosure, based on the response result of the system to be tested, the high availability characteristics of the system to be tested are verified, including: based on the response result obtained by each IO processing thread in a non-blocking IO manner, the high availability characteristics of the system to be tested are verified by adopting a thread pool method.

[0009] According to an embodiment of the present disclosure, based on a test pressure request, an event corresponding to the test pressure request is monitored and a connection with the system to be tested is established, including: based on the test pressure request, an event corresponding to the test pressure request is monitored; when the event is a connection event, a connection with the system to be tested is established.

[0010] According to an embodiment of the present disclosure, when the event is a connection event, a single-threaded event selector is used to establish a connection with the system to be tested.

[0011] The second aspect of the present disclosure provides a distributed system high-availability testing device, including: a request acquisition module, used to obtain a test stress request, the test stress request is used to perform a high-availability test on the system to be tested; a connection establishment module, used to monitor and obtain events corresponding to the test stress request based on the test stress request, and establish a connection with the system to be tested; a thread creation module, used to create multiple IO processing threads after connecting to the system to be tested; an event read and write module, used to process IO read and write events in a non-blocking IO manner through each IO processing thread to obtain a response result of the system to be tested; a verification module, used to verify the high availability characteristics of the system to be tested based on the response result of the system to be tested.

[0012] According to an embodiment of the present disclosure, the verification module includes a business logic processing unit, wherein: the business logic processing unit is used to verify the high availability characteristics of the system to be tested by adopting a thread pool method based on the response results obtained by each IO processing thread in a non-blocking IO manner.

[0013] A third aspect of the present disclosure provides an electronic device, comprising: one or more processors; a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the above method.

[0014] The fourth aspect of the present disclosure further provides a computer-readable storage medium on which a computer program or instruction is stored, and when the computer program or instruction is executed by a processor, the steps of the above method are implemented.

[0015] The fifth aspect of the present disclosure also provides a computer program product, including a computer program or instructions, which implement the steps of the above method when the computer program or instructions are executed by a processor. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The above contents and other objects, features and advantages of the present disclosure will become more apparent through the following description of the embodiments of the present disclosure with reference to the accompanying drawings, in which:

[0017] Figure 1 The following schematically shows an application scenario diagram of a distributed system high availability testing method according to an embodiment of the present disclosure;

[0018] Figure 2 A flowchart of a distributed system high availability testing method according to an embodiment of the present disclosure is schematically shown;

[0019] Figure 3 Schematically shows a flow chart of connecting with a system to be tested according to an embodiment of the present disclosure;

[0020] Figure 4 Schematically shows an event-driven architecture diagram according to an embodiment of the present disclosure;

[0021] Figure 5 A flowchart of an IO read / write event processing method according to an embodiment of the present disclosure is schematically shown;

[0022] Figure 6 A structural block diagram schematically shows a distributed system high availability testing device according to an embodiment of the present disclosure; and

[0023] Figure 7 A block diagram of an electronic device suitable for implementing a distributed system high-availability testing method according to an embodiment of the present disclosure is schematically shown. DETAILED DESCRIPTION

[0024] Hereinafter, embodiments of the present disclosure will be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the present disclosure. In the following detailed description, for ease of explanation, many specific details are set forth to provide a comprehensive understanding of the embodiments of the present disclosure. However, it is apparent that one or more embodiments may also be implemented without these specific details. In addition, in the following description, descriptions of known structures and technologies are omitted to avoid unnecessary confusion of the concepts of the present disclosure.

[0025] In the technical solution of the present disclosure, the user information (including but not limited to user personal information, user image information, user device information, such as location information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved are all information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data comply with relevant laws, regulations and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0026] It should be noted that in the embodiments of the present application, certain software, components, models and other existing solutions in the industry may be mentioned, and they should be regarded as exemplary. Their purpose is only to illustrate the feasibility of implementing the technical solution of the present application, but it does not mean that the applicant has or will necessarily use the solution.

[0027] In the scenario of using personal information for automated decision-making, the methods, devices, and systems provided by the embodiments of the present disclosure provide users with corresponding operation portals for users to choose to agree or reject the automated decision-making results; if the user chooses to reject, the expert decision-making process will be entered. The expression "automated decision-making" here refers to the activity of automatically analyzing and evaluating a person's behavioral habits, interests and hobbies, or economic, health, credit status, etc. through computer programs, and making decisions. The expression "expert decision-making" here refers to the activity of making decisions by people who specialize in a certain field, have specialized experience, knowledge and skills, and have reached a certain level of professionalism.

[0028] An embodiment of the present disclosure provides a distributed system high-availability testing method, including: obtaining a test stress request, the test stress request is used to perform a high-availability test on the system to be tested; based on the test stress request and a preset event-driven architecture, a non-blocking IO model is used to asynchronously generate and continuously send test stress to the system to be tested, to obtain a response result of the system to be tested; based on the response result of the system to be tested, the high-availability characteristics of the system to be tested are verified.

[0029] Through the embodiments of the present invention, the problem that the existing technology wastes a lot of CPU and thread resources of the generator and compressor and cannot meet the needs of high-availability test scenarios is solved. Through this method, there is no need to wait for the response of the system under test to return, and stable test pressure can be continuously generated according to the predetermined frequency and concurrency. At the same time, the results of normal responses are processed, which can meet the needs of high-availability test scenarios of distributed systems and make more effective use of generator and compressor resources.

[0030] Figure 1 The application scenario diagram of the distributed system high availability testing method according to the embodiment of the present disclosure is schematically shown.

[0031] like Figure 1 As shown, the application scenario 100 according to this embodiment may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 is used to provide a medium for a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 may include various connection types, such as wired, wireless communication links, or optical fiber cables, etc.

[0032] The user can use the first terminal device 101, the second terminal device 102, and the third terminal device 103 to interact with the server 105 through the network 104 to receive or send messages, etc. Various communication client applications can be installed on the first terminal device 101, the second terminal device 102, and the third terminal device 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social platform software, etc. (only for example).

[0033] The first terminal device 101, the second terminal device 102, and the third terminal device 103 may be various electronic devices having display screens and supporting web browsing, including but not limited to smart phones, tablet computers, laptop computers, desktop computers, and the like.

[0034] The server 105 may be a server that provides various services, such as a background management server (only as an example) that provides support for websites browsed by users using the first terminal device 101, the second terminal device 102, and the third terminal device 103. The background management server may analyze and process the received data such as user requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal device.

[0035] It should be noted that the distributed system high availability test method provided in the embodiment of the present disclosure can generally be executed by the server 105. Accordingly, the distributed system high availability test device provided in the embodiment of the present disclosure can generally be set in the server 105. The distributed system high availability test method provided in the embodiment of the present disclosure can also be executed by a server or server cluster that is different from the server 105 and can communicate with the first terminal device 101, the second terminal device 102, the third terminal device 103 and / or the server 105. Correspondingly, the distributed system high availability test device provided in the embodiment of the present disclosure can also be set in a server or server cluster that is different from the server 105 and can communicate with the first terminal device 101, the second terminal device 102, the third terminal device 103 and / or the server 105.

[0036] It should be understood that Figure 1The number of terminal devices, networks and servers in the embodiment is only for illustration. Any number of terminal devices, networks and servers may be provided according to implementation requirements.

[0037] The following will be based on Figure 1 The scene described by Figure 2~Figure 5 The distributed system high availability testing method of the disclosed embodiment is described in detail.

[0038] Figure 2 The flowchart of the distributed system high availability testing method according to the embodiment of the present disclosure is schematically shown.

[0039] like Figure 2 As shown, the distributed system high availability testing method may further include operations S210 to S250.

[0040] In operation S210 , a test stress request is obtained, where the test stress request is used to perform a high availability test on the system to be tested.

[0041] In an embodiment of the present disclosure, a test stress request may be an input instruction, and through the test stress request or instruction, the software or the system to be tested (such as a distributed system) is tested to evaluate the performance and stability of the distributed system by simulating a high load or high concurrency environment. The goal of stress testing is to identify the bottlenecks of the distributed system and its behavior under extreme conditions to ensure that the system can withstand the expected user load.

[0042] Exemplarily, the test stress request may include a test stress script, and the test stress script may include data such as multiple scenarios. By executing the test stress script, a high availability test is performed on the system to be tested (eg, a distributed system).

[0043] For another example, in stress testing, by executing the test stress script, the stress generator (also called load generator or load testing tool) is run to simulate user activities or system load, and the high availability test of the system to be tested is performed to evaluate the performance of the system, application or network under high load. By simulating the abnormality of the system, it is verified whether the system can provide services normally (or provide services in a degraded manner), and whether the system can recover to the operating state before the abnormality occurs after the abnormality is recovered.

[0044] In operation S220, based on the test pressure request, an event corresponding to the test pressure request is monitored and a connection with the system to be tested is established.

[0045] In operation S230 , after connecting to the system to be tested, multiple IO processing threads are created.

[0046] In operation S240, each IO processing thread processes the IO read and write events in a non-blocking IO manner to obtain a response result of the system to be tested.

[0047] The embodiments of the present invention are described in detail below in conjunction with an application scenario in which a high availability test is performed on a system to be tested by running a compressor to simulate user activities or system loads.

[0048] In the embodiments of the present disclosure, based on the test stress request and the preset event-driven architecture, a non-blocking IO model is adopted to asynchronously generate and continuously send the test stress to the system to be tested, and obtain the response result of the system to be tested.

[0049] Figure 3 The flowchart of connecting with the system to be tested according to an embodiment of the present disclosure is schematically shown. Figure 4 The event-driven architecture diagram according to an embodiment of the present disclosure is schematically shown.

[0050] like Figure 3 As shown, in an embodiment of the present disclosure, based on a test pressure request, monitoring an event corresponding to the test pressure request and establishing a connection with the system to be tested may further include operations S310 to S320.

[0051] In operation S310 , based on the test pressure request, an event corresponding to the test pressure request is monitored.

[0052] In operation S320, when the event is a connection event, a connection with the system to be tested is established.

[0053] In an embodiment of the present disclosure, based on a test stress request, an event corresponding to the test stress request is monitored, and when the event is a connection event, a connection with the system to be tested is established. After the connection is established, test stress data is sent to the system to be tested by adopting a non-blocking IO method, and a response result of the system to be tested is obtained.

[0054] In the embodiments of the present disclosure, a non-blocking IO model is used for asynchronous processing. Asynchronous processing is a common programming mode used to process operations that take a long time to complete, such as network requests, file reading and writing, or complex computing tasks. In asynchronous processing, operations are submitted to a message queue, and then the program can continue to perform other tasks without waiting for the operation to complete. This approach can improve the performance and response speed of the system, while also improving the user experience. Figure 4 As shown, based on the preset event-driven architecture, the overall control of high-availability testing of distributed systems is achieved by monitoring, distributing and processing various events, which is described in detail below.

[0055] Specifically, based on the test stress request, the listener (such as the reactor component) listens to the event corresponding to the test stress request. At this time, the first listener listens to the connection event, and the connection with the distributed system to be tested is established. After the connection with the distributed system to be tested is established, the test stress data is sent to the system to be tested by using a non-blocking IO method, and the response result of the system to be tested is obtained.

[0056] It should be noted that when the event is a connection event, a single-threaded event selector is used to establish a connection with the system to be tested.

[0057] Through the embodiments of the present disclosure, a single thread is implemented to simulate the connection establishment and network IO events of multiple virtual users based on a non-blocking IO model, thereby making full use of the threads and CPU resources of the compressor.

[0058] For example, after the connection with the distributed system to be tested is established, when the test stress request is subsequently obtained, the listener will listen again to capture the event, and perform different distribution and processing according to the event type. For example, at this time, the event type can be divided into connection events and IO read and write events. Separate the connection event from the IO read and write event to avoid the time-consuming IO read and write event blocking the connection event processing, and initiate as many test requests as possible within a unit time.

[0059] Figure 5 The flowchart of the IO read and write event processing method according to the embodiment of the present disclosure is schematically shown.

[0060] like Figure 5 As shown, in an embodiment of the present disclosure, after the connection is established, the IO read and write event processing, that is, sending the test pressure data to the system to be tested in a non-blocking IO manner and obtaining the response result of the system to be tested, can further include operations S510~S520.

[0061] In operation S510, each IO processing thread processes an IO write event in a non-blocking IO manner, where the write event is data of a test pressure being sent to the system to be tested.

[0062] In operation S520, each IO processing thread processes an IO read event in a non-blocking IO manner, where the read event is to read response result data returned by the system under test.

[0063] Specifically, after connecting to the system to be tested, multiple IO processing threads are created. Exemplarily, the number of IO processing threads to be created is determined based on the system's load capacity and performance requirements. Generally speaking, it can be determined based on the number of CPU cores or the expected number of concurrent requests. In order to manage the life cycle of threads, for example, a thread pool can be used, which can effectively control the creation and destruction of threads and improve resource utilization.

[0064] like Figure 4 As shown, for example, the connection event is handled by the acceptor component, and a connection is established with the distributed system under test. An acceptor thread listens to multiple connections in a non-blocking IO manner. After successfully establishing a connection with the system under test, multiple IO_handler threads are created. IO read and write events are, for example, handled by multiple IO_handler threads, and each IO_handler processing thread processes IO write events in a non-blocking IO manner, where the write event is the data for sending the test pressure to the system under test. IO read events are processed in a non-blocking IO manner by each IO_handler processing thread, where the read event is the response result data returned by the system under test.

[0065] In an embodiment of the present disclosure, according to the test configuration information, the test pressure data is sent to the system to be tested according to the preset concurrency number and sending interval.

[0066] Through the embodiments of the present disclosure, connection events are separated from IO read and write events. Connection events are processed by a single-threaded event selector, and read and write events are processed by multiple worker threads, each of which is processed in a non-blocking IO manner, and the read and write operations of IO events are processed by their own event selectors. Here, each worker thread has its own event queue, and data is isolated from each other, completely avoiding performance waste caused by data synchronization.

[0067] S250: Based on the response result of the system to be tested, verify the high availability characteristics of the system to be tested.

[0068] In an embodiment of the present disclosure, based on the response result of the system to be tested, the high availability characteristics of the system to be tested are verified, including: based on the response result obtained by each IO processing thread in a non-blocking IO manner, the high availability characteristics of the system to be tested are verified by adopting a thread pool method.

[0069] Exemplarily, after each IO processing thread processes the read event, the response result of the corresponding thread will be obtained. For example, after reading the complete response result data, IO_handler calls, for example, the business processing logic component Business_handler to process the response result data, including decoding, verification, etc. to obtain the high availability index of the system.

[0070] In the embodiments of the present disclosure, common indicators include, for example: response time, the speed at which the system responds to a request; reachability, whether the system can successfully respond to a request within a certain period of time; error rate, the proportion of failed requests; recovery time: the time required for the system to return to normal after a failure occurs.

[0071] Specifically, all response results are collected and analyzed, such as drawing a response time distribution graph to view the fluctuation of response time; calculating reachability and error rate to evaluate the stability of the system under different loads; and analyzing the system recovery time and effectiveness of the recovery strategy in failure scenarios.

[0072] In the embodiments of the present disclosure, in order to ensure that the system continues to maintain high availability, real-time monitoring can also be implemented to collect runtime data, and the system configuration can be continuously adjusted and the code optimized according to the monitoring results.

[0073] Therefore, the test business processing logic is separated from the IO read and write events to avoid the backlog of IO read and write queues and high memory usage. Regardless of whether the distributed system under test is abnormal or the response time is fast or slow, it will not block the test pressure generation, and can continuously generate stable test pressure to meet the requirements of high-availability test scenarios for distributed systems.

[0074] Based on the above-mentioned distributed system high availability testing method, the present disclosure also provides a distributed system high availability testing device. Figure 6 The device is described in detail.

[0075] Figure 6 The structural block diagram of a distributed system high availability testing device according to an embodiment of the present disclosure is schematically shown.

[0076] like Figure 6 As shown, the distributed system high availability testing device 600 of this embodiment includes a request acquisition module 610 , a connection establishment module 620 , a thread creation module 630 , an event reading and writing module 640 and a verification module 650 .

[0077] The request acquisition module 610 is used to acquire a test stress request, and the test stress request is used to perform a high availability test on the system to be tested. In one embodiment, the request acquisition module 610 can be used to perform the operation S210 described above, which will not be described in detail here.

[0078] The connection establishment module 620 is used to monitor and obtain events corresponding to the test pressure request based on the test pressure request, and establish a connection with the system to be tested. In one embodiment, the connection establishment module 620 can be used to perform the operation S220 described above, which will not be repeated here.

[0079] The thread creation module 630 is used to create multiple IO processing threads after being connected to the system to be tested. In one embodiment, the thread creation module 630 can be used to perform the operation S230 described above, which will not be described in detail here.

[0080] The event read / write module 640 is used to process IO read / write events in a non-blocking IO manner through each IO processing thread to obtain a response result of the system to be tested. In one embodiment, the event read / write module 640 can be used to perform the operation S240 described above, which will not be repeated here.

[0081] The verification module 650 is used to verify the high availability characteristics of the system to be tested based on the response result of the system to be tested. In one embodiment, the verification module 650 can be used to perform the operation S250 described above, which will not be described in detail here.

[0082] Specifically, the connection establishment module 620 includes an event connection unit and an event monitoring unit, wherein the event connection unit is used to establish a connection with the system to be tested; the event monitoring unit is used to monitor events and, according to the type of events, allocate connection events to the connection event processing unit and allocate IO events to the IO read and write event unit.

[0083] The thread creation module 630 includes a connection event processing unit, which is used to create multiple IO processing threads after connecting to the system to be tested.

[0084] The event read and write module 640 includes an IO read and write event unit, which is used to process IO write events in a non-blocking IO manner through each IO processing thread, where the write event is the data of the test pressure sent to the system under test, and to process IO read events in a non-blocking IO manner through each IO processing thread, where the read event is the response result data returned by the system under test.

[0085] In an embodiment of the present disclosure, the verification module 650 includes a business logic processing unit, wherein the business logic processing unit is used to verify the high availability characteristics of the system to be tested by adopting a thread pool method based on the response results obtained by each IO processing thread in a non-blocking IO manner.

[0086] According to an embodiment of the present disclosure, any multiple modules of the request acquisition module 610, the connection establishment module 620, the thread creation module 630, the event read and write module 640, and the verification module 650 can be combined in one module for implementation, or any one of the modules can be split into multiple modules. Alternatively, at least part of the functions of one or more of these modules can be combined with at least part of the functions of other modules and implemented in one module. According to an embodiment of the present disclosure, at least one of the request acquisition module 610, the connection establishment module 620, the thread creation module 630, the event read and write module 640, and the verification module 650 can be at least partially implemented as a hardware circuit, such as a field programmable gate array (FPGA), a programmable logic array (PLA), a system on a chip, a system on a substrate, a system on a package, an application specific integrated circuit (ASIC), or can be implemented by hardware or firmware such as any other reasonable way of integrating or packaging the circuit, or implemented in any one of the three implementation methods of software, hardware, and firmware, or in any appropriate combination of any of them. Alternatively, at least one of the request acquisition module 610, the connection establishment module 620, the thread creation module 630, the event reading and writing module 640 and the verification module 650 can be at least partially implemented as a computer program module, and when the computer program module is executed, the corresponding function can be executed.

[0087] Through the embodiments of the present disclosure, the distributed system high-availability test device solves the problem that the existing technology has a large waste of CPU and thread resources of the compressor and cannot meet the needs of high-availability test scenarios. Through the device, there is no need to wait for the response of the system to be tested to return, and stable test pressure can be continuously generated according to the predetermined frequency and concurrency, while processing the results of normal responses, which can meet the needs of distributed system high-availability test scenarios and make more effective use of compressor resources.

[0088] Figure 7 A block diagram of an electronic device suitable for implementing a distributed system high-availability testing method according to an embodiment of the present disclosure is schematically shown.

[0089] like Figure 7As shown, the electronic device 700 according to an embodiment of the present disclosure includes a processor 701, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 702 or a program loaded from a storage part 707 to a random access memory (RAM) 703. The processor 701 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or a related chipset and / or a dedicated microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 701 may also include an onboard memory for caching purposes. The processor 701 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of the present disclosure.

[0090] In RAM 703, various programs and data required for the operation of electronic device 700 are stored. Processor 701, ROM 702 and RAM 703 are connected to each other via bus 704. Processor 701 performs various operations of the method flow according to the embodiment of the present disclosure by executing the program in ROM 702 and / or RAM 703. It should be noted that the program can also be stored in one or more memories other than ROM 702 and RAM 703. Processor 701 can also perform various operations of the method flow according to the embodiment of the present disclosure by executing the program stored in one or more memories.

[0091] According to an embodiment of the present disclosure, the electronic device 700 may further include an input / output (I / O) interface 705, which is also connected to the bus 704. The electronic device 700 may further include one or more of the following components connected to the I / O interface 705: an input portion 706 including a keyboard, a mouse, etc.; an output portion 707 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage portion 707 including a hard disk, etc.; and a communication portion 709 including a network interface card such as a LAN card, a modem, etc. The communication portion 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to the I / O interface 705 as needed. A removable medium 711, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 710 as needed, so that a computer program read therefrom is installed into the storage portion 707 as needed.

[0092] The present disclosure also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or may exist independently without being assembled into the device / apparatus / system. The above computer-readable storage medium carries one or more programs, and when the above one or more programs are executed, the method according to the embodiment of the present disclosure is implemented.

[0093] According to an embodiment of the present disclosure, the computer-readable storage medium may be a non-volatile computer-readable storage medium, for example, it may include but is not limited to: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the present disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program, which may be used by or in combination with an instruction execution system, an apparatus or a device. For example, according to an embodiment of the present disclosure, the computer-readable storage medium may include the ROM 702 and / or RAM 703 described above and / or one or more memories other than ROM 702 and RAM 703.

[0094] The embodiment of the present disclosure also includes a computer program product, which includes a computer program, and the computer program contains program code for executing the method shown in the flowchart. When the computer program product is run in a computer system, the program code is used to enable the computer system to implement the method provided by the embodiment of the present disclosure.

[0095] The above functions defined in the system / device of the embodiment of the present disclosure are performed when the computer program is executed by the processor 701. According to the embodiment of the present disclosure, the system, device, module, unit, etc. described above can be implemented by a computer program module.

[0096] In one embodiment, the computer program may rely on tangible storage media such as optical storage devices, magnetic storage devices, etc. In another embodiment, the computer program may also be transmitted and distributed in the form of signals on a network medium, and downloaded and installed through the communication part 709, and / or installed from the removable medium 711. The program code contained in the computer program may be transmitted using any appropriate network medium, including but not limited to: wireless, wired, etc., or any suitable combination of the above.

[0097] In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 709, and / or installed from the removable medium 711. When the computer program is executed by the processor 701, the above functions defined in the system of the embodiment of the present disclosure are performed. According to the embodiment of the present disclosure, the system, device, means, module, unit, etc. described above can be implemented by a computer program module.

[0098] According to an embodiment of the present disclosure, the program code for executing the computer program provided by the embodiment of the present disclosure can be written in any combination of one or more programming languages. Specifically, these computing programs can be implemented using high-level process and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, Java, C++, python, "C" language or similar programming languages. The program code can be executed entirely on the user computing device, partially on the user device, partially on the remote computing device, or entirely on the remote computing device or server. In the case of a remote computing device, the remote computing device can be connected to the user computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computing device (for example, using an Internet service provider to connect through the Internet).

[0099] The flow charts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each box in the flow chart or block diagram can represent a module, a program segment, or a part of a code, and the above-mentioned module, program segment, or a part of a code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flow chart, and the combination of the boxes in the block diagram or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0100] It will be appreciated by those skilled in the art that the features described in the various embodiments of the present disclosure may be combined and / or combined in a variety of ways, even if such combinations or combinations are not explicitly described in the present disclosure. In particular, without departing from the spirit and teachings of the present disclosure, the features described in the various embodiments of the present disclosure may be combined and / or combined in a variety of ways. All of these combinations and / or combinations fall within the scope of the present disclosure.

[0101] The embodiments of the present disclosure are described above. However, these embodiments are only for illustrative purposes and are not intended to limit the scope of the present disclosure. Although the embodiments are described above, this does not mean that the measures in the various embodiments cannot be used in combination to advantage. Without departing from the scope of the present disclosure, those skilled in the art may make a variety of substitutions and modifications, which should all fall within the scope of the present disclosure.

Claims

1. A distributed system high availability testing method, characterized in that: The method comprises: Obtain a test stress request, where the test stress request is used to perform a high availability test on the system to be tested; Based on the test pressure request, monitoring and obtaining an event corresponding to the test pressure request, and establishing a connection with the system to be tested; After connecting to the system to be tested, multiple IO processing threads are created; By processing the IO read and write events in a non-blocking IO manner through each of the IO processing threads, a response result of the system to be tested is obtained; Based on the response result of the system to be tested, the high availability characteristic of the system to be tested is verified.

2. The distributed system high availability testing method according to claim 1, characterized in that: The step of processing the IO read and write events in a non-blocking IO manner by each of the IO processing threads to obtain a response result of the system to be tested includes: Processing an IO write event in a non-blocking IO manner by each of the IO processing threads, wherein the write event is data for sending a test pressure to the system to be tested; and Each of the IO processing threads processes an IO read event in a non-blocking IO manner, and the read event is to read the response result data returned by the system under test.

3. The distributed system high availability testing method according to claim 2, characterized in that: The sending of the test pressure data to the system to be tested comprises: According to the test configuration information, the test pressure data is sent to the system to be tested according to the preset concurrency number and sending interval.

4. The distributed system high availability testing method according to claim 1 or 3, characterized in that: The verifying the high availability characteristic of the system to be tested based on the response result of the system to be tested includes: Based on the response result obtained by each IO processing thread in a non-blocking IO manner, the high availability characteristic of the system to be tested is verified by adopting a thread pool manner.

5. The distributed system high availability testing method according to claim 1, characterized in that: The monitoring, based on the test pressure request, obtaining an event corresponding to the test pressure request, and establishing a connection with the system to be tested includes: Based on the test pressure request, monitoring and obtaining an event corresponding to the test pressure request; When the event is a connection event, a connection with the system to be tested is established.

6. The distributed system high availability testing method according to claim 2, characterized in that: When the event is a connection event, a single-threaded event selector is used to establish a connection with the system to be tested.

7. A distributed system high availability testing device, characterized in that: The device comprises: A request acquisition module, used to acquire a test stress request, wherein the test stress request is used to perform a high availability test on the system to be tested; A connection establishing module, configured to monitor and obtain an event corresponding to the test pressure request based on the test pressure request, and establish a connection with the system to be tested; A thread creation module, used to create multiple IO processing threads after connecting to the system to be tested; An event reading and writing module, used for processing IO reading and writing events in a non-blocking IO manner through each of the IO processing threads to obtain a response result of the system to be tested; The verification module is used to verify the high availability characteristics of the system to be tested based on the response result of the system to be tested.

8. The distributed system high availability testing device according to claim 7, characterized in that: The verification module includes a business logic processing unit, wherein: The business logic processing unit is used to verify the high availability characteristics of the system to be tested by adopting a thread pool method based on the response result obtained by each IO processing thread in a non-blocking IO method.

9. An electronic device, comprising: one or more processors; a memory for storing one or more computer programs, It is characterized in that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 6.

10. A computer-readable storage medium having a computer program or instruction stored thereon, characterized in that: When the computer program or instruction is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

11. A computer program product comprising a computer program or instructions, characterized in that When the computer program or instruction is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images