CN114090597A

CN114090597A - Read-write separation method, apparatus, storage medium and program product

Info

Publication number: CN114090597A
Application number: CN202111312462.3A
Authority: CN
Inventors: 李明昊
Original assignee: Alibaba China Co Ltd
Current assignee: Alibaba China Co Ltd
Priority date: 2021-11-08
Filing date: 2021-11-08
Publication date: 2022-02-25

Abstract

The method of the application, through separating the domain model used by the business logic of the update class from the domain model used by the business logic of the query class, the first domain model and the second domain model are both simplified, when a business system is developed, a first code module can be developed based on the first domain model, a second code module can be developed based on the second domain model, and the separation of read-write codes is realized; the modification of the first domain model does not influence the realization of the query service logic, the modification of the second domain model does not influence the realization of the update service logic, the flexibility of the development of the service system is improved, the developed service system is more convenient to maintain and expand, and the maintainability and the expandability of the service system are improved.

Description

Read-write separation method, apparatus, storage medium and program product

Technical Field

The present application relates to computer technologies, and in particular, to a method, an apparatus, a storage medium, and a program product for read/write separation.

Background

In business systems such as sales and operation planning, e-commerce and the like, a large number of operations of adding (Create), inquiring (Retrieve), modifying (Update) and deleting (Delete), which are abbreviated as CRUD operations, exist. For a simpler business system, a single database table is directly inquired, and the business requirements can be met. In a large-scale business system, a data Model in a database is difficult to be consistent with a Model required by a business layer, so a Domain Model (Domain Model) is introduced, the Domain Model is also called a business object Model, the Domain Model is concentrated on analyzing the problem Domain, important business objects are excavated, the relation between the business objects is established, and developers develop program codes for realizing business logic based on the Domain Model.

However, in order to meet the business requirements of a large-scale business system, the domain model of the business system is often very complex, and the business system developed based on the complex domain model has poor expandability.

Disclosure of Invention

The application provides a read-write separation method, a device, a storage medium and a program product, which are used for improving the expandability of a service system.

In a first aspect, the present application provides a read-write separation method, including:

responding to the operation of an update class in a service system, and operating a first code module based on a first domain model in the service system, wherein the first domain model is used for realizing the service logic of the update class operation in the service system;

responding to the operation of the query class in the service system, and operating a second code module based on a second domain model in the service system, wherein the second domain model is used for realizing the service logic of the query class operation in the service system;

wherein the first domain model is different from the second domain model.

In a second aspect, the present application provides a read-write separation method, including:

responding to the operation of an update class in a service system, executing a command corresponding to the operation, and adding an event corresponding to the command;

executing the business logic corresponding to the event;

the command, the event and the business logic corresponding to the event are developed based on the first domain model, the program code of the business logic for realizing the query operation in the business system is developed based on the second domain model, and the first domain model is different from the second domain model.

In a third aspect, the present application provides a read-write separation apparatus, including:

the system comprises an updating unit, a first code module and a second code module, wherein the updating unit is used for responding to the operation of an updating class in a service system and operating the first code module based on a first domain model in the service system, and the first domain model is used for realizing the service logic of the operation of the updating class in the service system;

the query unit is used for responding to the operation of the query class in the service system and operating a second code module based on a second domain model in the service system, wherein the second domain model is used for realizing the service logic of the query class operation in the service system;

wherein the first domain model is different from the second domain model.

In a fourth aspect, the present application provides a read-write separation apparatus, including:

the event generating unit is used for responding to the operation of the update class in the service system, executing the command corresponding to the operation and adding the event corresponding to the command;

the event processing unit is used for executing the business logic corresponding to the event;

In a fifth aspect, the present application provides an electronic device, comprising: a processor, and a memory communicatively coupled to the processor;

the memory stores computer-executable instructions;

the processor executes computer-executable instructions stored by the memory to implement the method of any of the above aspects.

In a sixth aspect, the present application provides a computer-readable storage medium having stored thereon computer-executable instructions for implementing the method of any one of the above aspects when executed by a processor.

In a seventh aspect, the present application provides a computer program product comprising a computer program which, when executed by a processor, implements the method of any of the above aspects.

According to the read-write separation method, the read-write separation device, the storage medium and the program product, the field model used by the service logic of the update class is separated from the field model used by the service logic of the query class, the first field model and the second field model are both simplified, when a service system is developed, the first code module can be developed based on the first field model, the second code module can be developed based on the second field model, and the read-write code separation is realized; the modification of the first domain model does not influence the realization of the query service logic, the modification of the second domain model does not influence the realization of the update service logic, the flexibility of the development of the service system is improved, the developed service system is more convenient to maintain and expand, and the maintainability and the expandability of the service system are improved.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and together with the description, serve to explain the principles of the application.

FIG. 1 is an exemplary diagram of the general framework of a traditional domain model-based business system provided herein;

FIG. 2 is a schematic diagram of a system framework for implementing read-write separation according to an exemplary embodiment of the present application;

FIG. 3 is a flowchart of a read/write separation method according to an exemplary embodiment of the present application;

FIG. 4 is a flow chart of a method for read-write separation according to another exemplary embodiment of the present application;

FIG. 5 is a diagram illustrating a relationship between commands and events provided by an exemplary embodiment of the present application;

FIG. 6 is a flow chart of a method for read-write separation according to another exemplary embodiment of the present application;

FIG. 7 is an exemplary diagram of a state switching process for events provided by an exemplary embodiment of the present application;

fig. 8 is an exemplary diagram of a system framework for implementing event development based on an SDK access framework according to an exemplary embodiment of the present application;

FIG. 9 is a block diagram of an exemplary read/write separation method according to an exemplary embodiment of the present application;

FIG. 10 is a schematic diagram of event playback processing provided by an exemplary embodiment of the present application;

fig. 11 is a framework diagram of an example of a service system of a read-write separation method according to an example embodiment of the present application;

FIG. 12 is a schematic structural diagram of a read/write separation apparatus according to an exemplary embodiment of the present application;

FIG. 13 is a schematic structural diagram of a read/write separation apparatus according to another exemplary embodiment of the present application;

FIG. 14 is a schematic structural diagram of a read/write separation apparatus according to another exemplary embodiment of the present application;

fig. 15 is a schematic structural diagram of an electronic device according to an example embodiment of the present application.

With the above figures, there are shown specific embodiments of the present application, which will be described in more detail below. These drawings and written description are not intended to limit the scope of the inventive concepts in any manner, but rather to illustrate the inventive concepts to those skilled in the art by reference to specific embodiments.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.

The terms referred to in this application are explained first:

a domain model: also known as conceptual models, domain object models, analytical object models, are visual representations of conceptual classes within a domain or objects in the real world. It focuses on analyzing the problem domain itself, exploring important business domain concepts, and establishing relationships between the business domain concepts.

Event: is an operation that can be recognized by the control, such as pressing a decision button, selecting a radio button or a check box. Each control has an event which can be recognized by the control, such as loading, clicking, double-clicking and other events of a form, a text change event of an edit box (text box) and the like. In this embodiment, a plurality of events and event handlers of the events are configured in advance, and the event handlers of the events are used to implement business logic of the events.

Sales and operation plan (S & OP): according to the sales plan, good product inventory, reservation purchase quantity and the like of upstream goods, various data indexes of the goods dimension of N days in the future are predicted through calculation, operation can determine whether the current capacity supports activities or not by referring to the indexes, and if the capacity is insufficient, the plan is allocated or changed in time.

Furthermore, the terms "first", "second", etc. are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. In the description of the following examples, "plurality" means two or more unless specifically limited otherwise.

In this application, the operation of updating a class refers to an operation that requires adding, modifying, or deleting data in a service system, and a service logic of the operation of updating a class generates a write request to a database when being executed. The business logic of the update class refers to the business logic of the update class operation. The query-class operation refers to an operation that only queries data in the service system, and does not need to add, modify or delete data. The business logic of the query class operation, when executed, generates a read request to the database. The business logic of the query class refers to the business logic of the query class operation.

For early service systems, service functions are simple, and a single database table can be directly queried by a data access layer (hierarchy), so that service requirements can be met.

However, in a large-scale business system in the fields of sales and operation planning, electronic commerce, and the like, the business function of the business system is complicated, and it is difficult for a data Model in a database to be consistent with a Model required by a business layer, and thus a Domain Model (Domain Model) has been introduced. In order to meet the service requirements of a large-scale service system, the domain model of the service system is often very complex, and the expandability of the service system developed based on the complex domain model is poor.

Illustratively, the domain model of the traditional business system based on the domain model is designed based on the overall business requirements of the business system, and needs to satisfy the business requirements of the update class and the query class simultaneously. The general framework of a traditional business system based on a domain model is shown in fig. 1, wherein an update operation and a query operation in the business system correspond to the same domain model, and the update and query of business data are realized based on the same domain model.

In a business system developed based on a domain Model, a data access layer needs to convert a data Model and a domain Model back and forth, but the domain Model is often different from a data Model in a specific domain, and a View Model (View Model) needs to be introduced, wherein the View Model can be combined with different domain models and contains attributes of all combined domain models. When a large number of connections (Join) are required to be made to a database, a Data Transfer Object (DTO for short) needs to be assembled based on a view model by an inquiry method in a Data access layer, and Data preloading is performed to improve system performance, where preloaded Data includes attributes of a large number of unnecessary domain models, occupies a large amount of memory, and needs to be maintained, thereby increasing performance consumption.

The read-write separation method provided by the application aims to solve the technical problems in the prior art, can be applied to business systems such as sales and operation plans and electronic commerce, and is particularly suitable for large-scale business systems with complex business logic.

The following describes the technical solutions of the present application and how to solve the above technical problems with specific embodiments. The following several specific embodiments may be combined with each other, and details of the same or similar concepts or processes may not be repeated in some embodiments. Embodiments of the present application will be described below with reference to the accompanying drawings.

Fig. 2 is a schematic diagram of a system framework for implementing read-write separation according to an example embodiment of the present application. In this implementation, as shown in fig. 2, the framework of the business system based on the domain model includes a first domain model and a second domain model, where the first domain model is a domain model set for the business requirement of the update class and used for implementing the business logic of the update class, and the second domain model is a domain model set for the business requirement of the query class and used for implementing the business logic of the query class, and the domain model used by the business logic of the update class is separated from the domain model used by the business logic of the query class.

Compared with the field model in the traditional service system, the first field model and the second field model are greatly simplified, the updating service logic is developed based on the first field model, the query service logic is developed based on the second field model, read-write code separation is realized, the modification of the first field model does not influence the development of the query service logic, the modification of the second field model does not influence the development of the updating service logic, the situation that one of the query service logic or the updating service logic is modified in the CRUD mode to cause the other party to have problems can be prevented, the flexibility of service system development and version iteration is improved, and the developed service system is more convenient to expand.

Based on the system framework shown in fig. 2, by separating the domain model used by the service logic of the update class from the service logic of the query class, when the service system is developed, a first code module may be developed based on the first domain model, and a second code module may be developed based on the second domain model, where the first code module is used to implement the service logic of the update class operation in the service system, and the second code module is used to implement the service logic of the query class operation in the service system.

Fig. 3 is a flowchart of a read-write separation method according to an example embodiment of the present application. As shown in fig. 3, the read-write separation method provided by the present application includes the following specific steps:

and step S31, responding to the operation of the update class in the service system, and operating a first code module based on a first domain model in the service system, wherein the first domain model is used for realizing the service logic of the update class operation in the service system.

Alternatively, the step S31 can be implemented by a method of implementing the business logic of the update class operation based on the existing domain model.

Optionally, the step S31 can also be implemented by using the method provided by any embodiment of the embodiment corresponding to fig. 4 and the subsequent method embodiment in this application, for details, see the content of the embodiment corresponding to fig. 4 and the subsequent method embodiment.

Step S32, responding to the operation of query class in the service system, operating a second code module based on a second domain model in the service system, wherein the second domain model is used for realizing the service logic of query class operation in the service system; wherein the first domain model is different from the second domain model.

This step S32 can be implemented by a method of implementing business logic of query class operation based on the existing domain model.

In the embodiment of the application, by separating the domain model used by the service logic of the update class from the domain model used by the service logic of the query class, the first domain model and the second domain model are both simplified, and when a service system is developed, a first code module can be developed based on the first domain model, and a second code module can be developed based on the second domain model, so that read-write code separation is realized; the modification of the first domain model does not influence the realization of the query service logic, the modification of the second domain model does not influence the realization of the update service logic, the flexibility of the development of the service system is improved, the developed service system is more convenient to maintain and expand, and the maintainability and the expandability of the service system are improved.

In an optional implementation manner, based on the system framework shown in fig. 2, separation of the read-write databases may be implemented, that is, two databases are configured, and data synchronization of the two databases is implemented. The first database and the second database are respectively used for referring to the two databases, and the second database is kept synchronous with the business data in the first database.

The first database is a data writing database, and when the business data needs to be updated, the business data in the first database is updated. In the above step S31, in response to the operation of the update class in the business system, when the first code module based on the first domain model in the business system is executed, the business data in the first database is updated.

The second database is a read database, and when the service data needs to be read, the service data is read from the second database. In the above step S32, when the second code module based on the second domain model in the business system is executed in response to the operation of the query class in the business system, the business data is read from the second database.

Alternatively, the first database and the second database may be implemented by different types of databases; alternatively, the first database and the second database may be implemented using the same type of database. The types of the first database and the second database can be configured and customized, and are not limited in detail here.

For example, the first database may be a non-relational database and the second database may be a relational database; alternatively, the first database and the second database may both be relational databases.

Optionally, data synchronization of the two databases may be realized by adopting a synchronous manner or an asynchronous manner, and configuration and adjustment may be specifically performed according to the needs of the service system, which is not specifically limited herein.

Illustratively, according to the business requirements of the business system, if it is necessary to ensure strong consistency between the second database for reading data and the first database for writing data, the synchronization between the first database and the second database is implemented in a synchronous manner. For example, when the business data in the first database changes, the changed business data in the first database is synchronized to the second database in real time.

Illustratively, if the final consistency of the second database for reading data and the first database for writing data can be accepted according to the business requirements of the business system, the synchronization of the first database and the second database is realized in an asynchronous mode. For example, the data in the first database is synchronized to the second database at a specified time interval, wherein the specified time interval can be set and adjusted according to the actual requirements of the service system.

The separation of the read-write database is realized while the separation of the read-write code is realized, the updating data and the query data are realized based on different databases, the efficiency of writing data into the database and reading data from the database can be improved, and the performance of a service system can be improved while the data security is ensured.

In another alternative embodiment, based on the system framework shown in fig. 2, a first code model based on the first domain model and a second code module based on the second domain model share a database. By realizing the separation of the read-write codes, the service system is easier to maintain and expand, the same database is read and written simultaneously, and the problem of read-write data consistency is not required to be considered.

Optionally, if the first code model based on the first domain model and the second code module based on the second domain model share a database, in the database, the database table corresponding to the first domain model may be different from the database table corresponding to the second domain model, and the consistency of the same service data in different database tables is maintained.

Fig. 4 is a flowchart of a read-write separation method according to another exemplary embodiment of the present application. Based on the system framework shown in fig. 2, in this embodiment, in the first code module of the service logic that implements the operation of the update class in the service system, the operation of the update class on the database is encapsulated as a command, the service logic corresponding to the command is encapsulated as an event, and the event is triggered to be executed to implement the corresponding service logic. The business logic corresponding to the event is also the business logic corresponding to the command corresponding to the event.

As shown in fig. 4, the method for read-write separation provided in this embodiment includes the following specific steps:

and step S41, responding to the operation of the update class in the service system, executing the command corresponding to the operation, and adding the event corresponding to the command.

The command corresponding to the operation is a command obtained by encapsulating the operation of the update class in the service system. The event is developed according to the business logic corresponding to the command, and the business logic corresponding to the command is realized when the event is executed, namely the business logic of the event is the business logic corresponding to the command.

In this embodiment, in a development stage of a business system, a plurality of commands are generated by encapsulation according to an update class operation in the business system, each command corresponds to a class of update operation, an event corresponding to each command and an event handler of the event are developed, and a data handler of the event is used to implement a business logic corresponding to the event. And realizing the development of the update operation of the application layer based on the packaged command.

For example, after various events and event handlers required in the business system are developed, registration information of the various events may be stored in a cache, so as to register the events. The event for completing the event registration may be triggered when the corresponding command is executed, and the event handler for executing the event implements the business logic corresponding to the event.

When developing update class operations at the application layer, each update class operation may be implemented using one command, or each update class operation may be implemented in combination with multiple commands, facilitating interfacing with other services and systems.

In the service system using process, responding to the operation of the update class in the service system, executing one or more commands corresponding to the operation, generating an event corresponding to the command when each command is executed, and realizing the service logic corresponding to the event when the event is executed.

In this embodiment, one command corresponds to one or more events, and when executed, the command generates the corresponding event. The relationship between the command and the event at least comprises the following steps:

(1) a command may generate an event;

(2) one command can generate a plurality of events, the plurality of events have no dependency relationship, and the execution sequence of the plurality of events does not influence the result;

(3) one command can generate a plurality of events, the plurality of events have dependency relationships, and the plurality of events need to be executed according to a specified sequence.

The relationship of the command to the generated event is illustratively described below in conjunction with FIG. 5. As shown in fig. 5, the command is represented by a square and the event generated by the command is represented by a circle, and as shown in the leftmost rectangle box of fig. 5, one command can generate one event; as shown in the rectangular frame in the middle of fig. 5, one command may generate two events without dependency relationship, and the execution sequence of the two events does not affect the result; as shown in the rightmost rectangle of FIG. 5, a command may generate two events having a dependency relationship, which need to be executed in a specified order.

Step S42, executing the business logic corresponding to the event; the command, the event and the business logic corresponding to the event are developed based on a first domain model, the program code of the business logic for realizing the query operation in the business system is developed based on a second domain model, and the first domain model is different from the second domain model.

The second domain model can be constructed according to the use mode of data, can be page-oriented and can also be interacted with a back-end system, and is not limited by the structure of the first domain model, so that the query logic can be simplified, and the performance of the system can be improved.

In the embodiment of the application, the updating operation in the service system is packaged into the command, the service logic corresponding to the command is packaged into the event, the corresponding service logic is realized when the event is triggered to be executed, the updating operation issuing event at the upper layer of the service system is realized through the decoupling of the command and the event, the decoupling of the service logic corresponding to the event execution realization operation is realized, the development of processing logic related to the event corresponding to the command only needs to consider the issuing of the event, the specific realization and execution of the service logic of the event do not need to be considered, and the flexibility of the service system development and the expandability of the service system are improved.

Fig. 6 is a flowchart of a read-write separation method according to another exemplary embodiment of the present application. On the basis of the corresponding embodiment of fig. 4, in another example embodiment of the present application, after an event corresponding to a command is newly added, event data of the event is stored. When the business logic corresponding to the event is executed, the event data of the event is read through the event processor, the event processing program of the event is obtained according to the event data, and the event processing program of the event is executed, wherein the event processing program is used for realizing the business logic corresponding to the event and realizing the decoupling of the event issuing and the event execution.

As shown in fig. 6, the method for read-write separation provided in this embodiment includes the following specific steps:

and step S61, responding to the operation of the update class in the service system, executing the command corresponding to the operation, and adding the event corresponding to the command.

For example, after various events and event handlers required in the business system are developed, registration information of the various events may be stored in a cache, so as to register the events. The event for completing the event registration may newly add an event corresponding to the command when the corresponding command is executed, and store event data of the event. And the event processor executes an event processing program of the event according to the event data, so that business logic corresponding to the event is realized.

(1) a command may generate an event;

Step S62 stores the event data of the event in an incremental storage manner.

In this step, after the command corresponding to the operation is executed and the event corresponding to the command is newly added, the event data of the event can be stored in an adding manner, so that the event data is stored according to the sequence of the event generation.

Wherein the event data of the event may include: event identification, event type, event context, event generation time. In addition, if the event exception retry mechanism is supported, the event data of the event may further include the retry number of the event and the retry event. The event data specifically includes information of the event, and may be configured according to the needs of the service system, which is not specifically limited herein.

For example, event data of an event may be stored in a data table, and the information included in the event data is as shown in table 1 below:

TABLE 1

Event ID	Event type	Number of abnormal retries	Retry time interval	Context information
					1	Product cooperation	3	5	{…}
2	Business collaboration	3	5	{…}
					3	Bin collaboration	3	5	{…}
4	National syndication	3	5	{…}
					…	…	…	…	…

As shown in fig. 1, the event ID is used to distinguish different events that have been generated, and one event can be uniquely determined based on the event ID and the event type.

It should be noted that, in table 1, it is only exemplified that the event data includes an event ID, an event type, an abnormal retry number, a retry time interval, and context information, and the event data may further include a time when the event is generated, a start event of an abnormal retry of the event, and the like, which is not limited herein.

In a conventional business system, when the update operation on the database is frequent in a short time, the processing result of the multiple operations is coordinated, the final result after the multiple operations is updated into the database, and the database does not record the processing process of each operation.

For example, a certain data a in the database is subjected to the following operations in a short time: increase 100, decrease 50, increase 200, the end result of three operations is to increase a by 250. If the time interval between the three operations is short, when the cooperative processing is performed, the data a in the database is increased 250 according to the final result of the three operations, instead of performing the update processing three times for each operation, and the update log of the database records the information updated once.

In this embodiment, for each operation of an update class, a command corresponding to the operation is executed, an event corresponding to the command is added newly, event data of the event is stored, and the event data corresponding to the operation of each update class is stored.

For example, a certain data a in the database is subjected to the following operations in a short time: increase 100, decrease 50, increase 200, the end result of three operations is to increase a by 250. Even if the interval time between three operations is short, corresponding event data is recorded for each operation when the cooperative processing is performed.

Optionally, based on the stored event data, the data of the historical events can be found at any time, so as to provide a data base for the examination of the business system; the performance of the business system can be analyzed, operation information can be viewed, and behavior trends can be analyzed; the event playback function can also be implemented for data recovery and the like.

Alternatively, the stored event data may be a snapshot of the event, which may enable fast event playback.

Optionally, the event data may be stored in a database, specifically, a database where the service data is located, or the event data and the service data are stored separately. In addition, the type of the database for storing the event data may be configurable, and may be a custom database, which is not specifically limited herein.

The event data stored in this embodiment includes information about all update behaviors to the service data, and may be used as an operation log of the service system to implement playback of the service system.

And step S63, reading the event data of the event through the event processor, acquiring an event processing program of the event according to the event data, and executing the event processing program of the event, wherein the event processing program is used for realizing the business logic corresponding to the event.

In this embodiment, the event data of the event is read by the event handler, the event handler of the event is acquired according to the event data, and the event handler of the event is executed, thereby implementing the decoupling of the event issuing and the event execution.

Alternatively, events may be executed in a synchronized manner by the event handler. After executing the command corresponding to the operation, adding an event corresponding to the command, storing event data of the event, synchronously processing the event according to the event data through the event processor, and executing an event processing program of the event.

Alternatively, events may be executed in an asynchronous manner by the event handler. And after executing the command corresponding to the operation, newly adding the event corresponding to the command, and storing the event data of the event. By the event handler, events that have not been executed can be handled centrally, one time period apart, based on the stored event data.

Alternatively, events and linkage between events can be performed to form an event stream, and linkage between events can be realized through configuration of the events. For example, after the execution of the event a is finished, the execution of the event B is triggered, the execution of the event B can trigger the execution of the event C, and the event A, B, C forms an event stream in an interlocking manner.

In a conventional business system, if a button is repeatedly clicked on a page for multiple times or an operation is frequently performed within a certain time period, a database is frequently updated by repeated or frequent operations within a short time period, and conflicts or mutual interference may exist. In the embodiment, the process of issuing the event by executing the command corresponding to the operation is decoupled from the process of executing the event, so that the process of generating the event by the system user interface can be carried out without interference, the conflict can be avoided by executing the processing logic corresponding to the event by the event processor, the performance and the expandability of the service system can be greatly improved, and particularly for a user presentation layer, the performance of the service system is greatly improved.

Optionally, based on a configured event exception retry mechanism, an exception retry of an event may be implemented. With the event manager, the specified type of exception that needs to be retried, as well as the number of retries and the retry interval, can be configured for each event that is developed. If an exception occurs in the process of executing the business logic corresponding to the event (i.e., the process of executing the event), and the occurred exception belongs to the specified type, step S64 needs to be executed based on the exception retry mechanism, and the business logic corresponding to the event is re-executed; and if the occurred exception does not belong to the specified type, the business logic corresponding to the event does not need to be executed again, and the event execution fails.

And step S64, if the abnormal of the appointed type occurs when the business logic corresponding to the event is executed, re-executing the business logic corresponding to the event according to the abnormal retry times and retry time interval corresponding to the event.

The specified type, the number of abnormal retries corresponding to the event, and the retry time interval may be configured and adjusted through the front-end page, which is not limited herein.

In this step, if an exception of a specified type occurs while executing the event handler of the event, that is, an exception of a specified type occurs while executing the service logic corresponding to the event, processing is performed according to an event exception handling mechanism, and the service logic corresponding to the event is re-executed.

If the business logic corresponding to the event still has the abnormality and the actual retry number is less than the configured abnormal retry number when the business logic corresponding to the event is re-executed, re-executing the business logic corresponding to the event again until the event is successfully executed or the actual retry number is greater than or equal to the configured abnormal retry number, the event is still abnormal in execution and is not retried again, and the event is failed in execution.

Alternatively, state management of events may be implemented based on a configured event state management mechanism. The event data may include event status. And updating the event state in the event data according to the processing stage of the event.

Exemplary, configurable event states include: initialization, in-process, success, failure. When the event corresponding to the command is added newly, the state of the event is initialized, the event data of the event is stored, and the state of the event recorded in the event data is the initialized state. After the event processor reads the event data of the event, the state of the event is updated to be in process, and the event processor executes the processing logic corresponding to the event. And when the execution of the business logic corresponding to the event is successful, the event processor updates the state of the event to be successful. And when the execution of the business logic corresponding to the event fails, the event processor updates the state of the event to failure.

Further, if the event exception retry mechanism is configured, the state of the event may further include: and (6) abnormal. When the business logic corresponding to the event is executed, an exception occurs, and according to an event exception retry mechanism, if the business logic corresponding to the event does not need to be executed again, the state of the event is updated to failure; if the business logic corresponding to the event needs to be executed again, updating the state of the event to be abnormal; after the business logic corresponding to the event is successfully executed, updating the state of the event to be successful; and if the business logic corresponding to the event still cannot be successfully executed after the event is abnormally retried, updating the state of the event into failure.

Alternatively, based on the event state management mechanism, in step S63, when the event handler reads the event data, it may determine whether the event has been processed (i.e. executed) according to the event state in the event data. The event processor can read the event data with the event state as initialization, so as to acquire the event data to be processed.

Optionally, based on the event state in the stored event data, the event with execution failure can be conveniently inquired, so that the problem in the service system can be timely found, and the maintenance of the service system is facilitated.

For example, fig. 7 provides an exemplary diagram of a state switching flow of an event, as shown in fig. 7, an initial state of the event is an "initialization" state, and when an event handler reads event data of the event or starts to execute processing logic corresponding to the event, the state of the event is updated from "initialization" to "in-process"; and after the event processing is finished, judging the next state of the event according to the processing result, and if the business logic execution of the event is successful, updating the state of the event to be successful. And if an exception occurs in the process of executing the business logic of the event and an exception retry is not needed, updating the state of the event to be 'failure'. If an exception occurs in the execution process of the business logic of the event and exception retry is needed, updating the state of the event to be 'abnormal', and after the business logic corresponding to the event is successfully executed, updating the state of the event to be 'successful'; after the abnormal retry is finished, the business logic corresponding to the event is not successfully executed, and the state of the event is updated to 'failure'.

In this embodiment, the event processor configures and operates the event related information based on an SDK (Software Development Kit) access framework and a general operation and maintenance configuration page, so that the difficulty in developing event-driven operations can be reduced.

Exemplarily, fig. 8 provides an exemplary diagram of a system framework for implementing event development based on an SDK access framework, and as shown in fig. 8, the system framework implements functions of event registration, event addressing routing, event state management, event exception retry and the like based on the SDK access framework, and provides an API for an event to a service system, and the service system implements a corresponding operation on the event by calling the API for the event.

In the development stage of the business system, a plurality of commands are generated by encapsulation according to the updating class operation in the business system, and each command corresponds to one class of updating operation; and developing the event corresponding to each command and the business logic of the event. And after the event development is finished, registering the event, and storing the registration information of the event into a cache.

Event registration: means that registration information of the event is saved in a cache. The registration information of the event may contain event type, service logic addressing information, etc.

The event type is also the type of the command corresponding to the event, the event types of different events are different, and based on the event type of the event, one event can be uniquely determined.

The service logic addressing information comprises addressing information of the service logic corresponding to the event, and the storage position of the service logic corresponding to the event can be determined according to the service logic addressing information, so that the service logic corresponding to the event can be read.

In addition, the registration information of the event may also include other required information, which may be specifically set and adjusted according to the scene needs of the service system, and is not specifically limited herein.

Event addressed routing: the method is a process of determining a storage location of a service logic corresponding to an event according to registration information of the event when the event needs to be executed.

Event state management: the state of the event is configured in advance in the development phase of the business system, and in the using process of the business system, the state of the event is updated according to the processing phase of the event for the event (namely, the instance of the event) generated when the command is executed. Illustratively, the state of the event may include: initialization, in-process, execution success, execution exception, execution failure, etc. The events include which states can be configured and adjusted according to the needs of the business system, and are not specifically limited herein.

Event exception retry: if the specified exception occurs in the process of executing the business logic of the event, the business logic of the event can be re-executed according to the configured retry times and the retry time interval until the event is successfully executed; or the retry time reaches the configured retry time and the execution is not successful, the event execution fails.

In this embodiment, the operation on the event includes at least one of the following: adding, executing and inquiring. The operation of the event has a corresponding API, and the adding, executing and inquiring operations of the event respectively correspond to the adding API, the executing API and the inquiring API of the event.

The adding of the event refers to adding event data of the event when a command corresponding to the event is executed, and adding the event data by calling an adding API of the event. The execution of the event refers to executing the business logic corresponding to the event, and the business logic corresponding to the event is executed by calling the execution API of the event. The query of the event refers to querying relevant information of the event, such as configuration information of the event and the like. And querying the relevant information of the event by calling a query API of the event.

In addition, in order to support a plurality of access parties to access different service systems, data source isolation and application isolation can be provided, and the behaviors and data of different access parties are not shared. Illustratively, databases and application codes of service systems of different access parties may be deployed on physical devices corresponding to the access parties, so as to implement physical isolation.

Exemplarily, fig. 9 provides an exemplary framework of the read-write separation method, and as shown in fig. 9, in response to an operation of an update class in the service system, a command corresponding to the operation is executed, event data of an event corresponding to the newly added command is stored, and a state of the event is recorded in the event data. The event handler reads the event (reads the business logic of the event), executes the business logic corresponding to the event, and updates the state of the event. And when the business logic of the event is executed, writing the updating result into the business data. And responding to the query request of the business system, and querying the business data.

In the method for separating read from write provided by this embodiment, the operation of the update class in the service system is encapsulated as a command, the service logic corresponding to the command is encapsulated as an event, and the event is triggered and executed to implement the corresponding service logic, so that the service system is switched from data drive to event drive, and command and event decoupling can be implemented in the development stage of the service system.

The read-write separation method provided by the embodiment is particularly suitable for systems which need to separately optimize query performance and write performance, especially systems which have very high read/write ratio and need lateral expansion. All operations related to the update class of the database in the service system are realized by executing commands corresponding to the operations and triggering events corresponding to the commands, the processes of executing the commands and executing the events can be asynchronous, all updating behaviors related to service data are contained in specific events, and the playback function of the events can be realized by storing the event data of all the events, so that the playback of the service system is realized.

Furthermore, by realizing code separation of the update operation and the query operation, the performance, expandability and safety of the service system are improved, high flexibility can be kept in the evolution (version iteration) of the system, the modification of the first field model does not influence the implementation of the query service logic, and the modification of the second field model does not influence the implementation of the update service logic; and by storing the event data of all events, which behavior or operation in the system causes the state change of the system can be traced based on the event data.

In an optional implementation manner of this embodiment, event data of all events is stored, and besides providing the event data point storage and query functions, according to the event data, an event corresponding to at least one event data may be re-executed, so as to implement the event playback function.

Illustratively, as shown in fig. 10, for the generated event 1, event 2, … …, event N +1, and event N +2, the event playback process may be performed from any event according to the stored event data.

Optionally, the event data includes an event generation time. One example of an event playback function is:

acquiring event data of an event generated before a specified time point according to event generation time in the event data; initializing initial service data of a service system to a database; and sequentially executing the service logic of each event generated before the specified time point according to the event data of the event generated before the specified time point and the sequence of the event generated to restore the service data in the database to the service data of the specified time point.

The service data in the database can be restored to any time point through the playback function of the event.

The event playback can be realized by taking out all event data at a specified time point, putting the event data into the context of the event, calling the business logic corresponding to the event, and generating the business state at the specific time point so as to restore the business data to the specified time point.

Alternatively, a correction operation of the undo operation can be implemented based on the playback function of the event. For example, at the first time when the modification operation on the data b is completed, a undo operation on the previous operation is performed, and event data of an event corresponding to the undo operation is recorded. And executing the event again according to the event data of the event corresponding to the revocation operation, namely revoking the previous revocation operation and recovering the service data at the first moment.

The event data of all events are stored in an increasing mode, the event data comprise context information of the events, the event playback function is realized based on the stored event data, the events can be read and put into the context, the service logic corresponding to the execution events is called again, the service data are recovered to any appointed time point, and the safety of the service data is improved.

For example, the embodiment corresponding to fig. 3 may be combined with the embodiment corresponding to fig. 4 to form a solution of separating read and write codes, and a new technical solution is implemented by adopting a manner of encapsulating commands and events for the operation of the update class. In addition, the embodiment corresponding to fig. 3 may be combined with the embodiment corresponding to fig. 6 to obtain a new technical solution, which is not described herein again.

Fig. 11 is a framework diagram of an example of a service system of the read-write separation method provided in the present application. As shown in fig. 11, a service system in an S & OP scenario provides a visualized S & OP user interface and provides the following two different domain models: the method comprises the steps of updating a model and a query model, wherein the updating model is used as a first domain model and is used for realizing business logic of updating operation; the query model is used as a second domain model for realizing business logic of query operation. The command service is developed based on the first field model, commands corresponding to the updating operations are provided, corresponding asynchronous events are generated when the commands are executed, the asynchronous events refer to events which can be asynchronously executed with the events, the asynchronous execution function of the events is supported, and business functions such as exporting, cooperating and recalculating can be achieved. And performing event processing through the event processor, executing the business logic corresponding to the event, and updating the business data in the database through the data access layer in the process of executing the business logic corresponding to the event. And developing a query service based on the second domain model, wherein the query service is used for realizing business logic of query operation and querying business data in the business database through the data access layer. In addition, the service system also supports the function of storing event snapshots, the event snapshots can be stored in a self-defined database, and the event playback function can be realized based on the event snapshots.

Fig. 12 is a schematic structural diagram of a read-write separation apparatus according to an example embodiment of the present application. The read-write separation device provided by the embodiment of the application can execute the processing flow provided by the read-write separation method embodiment. As shown in fig. 12, the read/write separation apparatus 120 includes: an updating unit 121 and a querying unit 122.

Specifically, the updating unit 121 is configured to run a first code module based on a first domain model in the service system in response to an operation of an update class in the service system, where the first domain model is used to implement a service logic of the update class operation in the service system.

And the query unit 122 is configured to, in response to the operation of the query class in the service system, run a second code module based on a second domain model in the service system, where the second domain model is used to implement a service logic of the query class operation in the service system.

Wherein the first domain model is different from the second domain model.

Optionally, the first code module updates the service data in the first database during running; and the second code module reads the service data from a second database during running, the second database and the first database are different databases, and the service data in the second database and the first database are kept synchronous.

The apparatus provided in the embodiment of the present application may be specifically configured to execute the method flow provided in the embodiment corresponding to fig. 3, and specific functions are not described herein again.

Fig. 13 is a schematic structural diagram of a read-write separation apparatus according to another exemplary embodiment of the present application. The read-write separation device provided by the embodiment of the application can execute the processing flow provided by the read-write separation method embodiment. As shown in fig. 13, the read/write separation apparatus 130 includes: an event generation unit 131 and an event processing unit 132.

Specifically, the event generating unit 131 is configured to, in response to an operation of updating a class in the business system, execute a command corresponding to the operation, and add an event corresponding to the command.

And the event processing unit 132 is configured to execute a service logic corresponding to the event.

The command, the event and the business logic corresponding to the event are developed based on a first domain model, the program code of the business logic for realizing the query operation in the business system is developed based on a second domain model, and the first domain model is different from the second domain model.

The apparatus provided in the embodiment of the present application may be specifically configured to execute the method flow provided in the embodiment corresponding to fig. 4, and specific functions are not described herein again.

Fig. 14 is a schematic structural diagram of a read-write separation apparatus according to another exemplary embodiment of the present application. In addition to the embodiment corresponding to fig. 13, in this embodiment, as shown in fig. 14, the read-write separation apparatus 130 further includes:

an event data management unit 133 for: event data for the event is stored in increments.

The event processing unit 132 is further configured to: reading event data of an event through the event processor, acquiring an event processing program of the event according to the event data, and executing the event processing program of the event, wherein the event processing program is used for realizing business logic corresponding to the event.

Optionally, the event data of the event comprises: the number of abnormal retries and the retry time interval corresponding to the event.

The event processing unit 132 is further configured to:

and if the specified type of abnormality occurs when the business logic corresponding to the event is executed, re-executing the business logic corresponding to the event according to the abnormal retry times and the retry time interval corresponding to the event.

Optionally, as shown in fig. 14, the read-write separation apparatus 130 further includes:

an event playback processing unit 134 for:

and re-executing the business logic of the event corresponding to at least one event data according to the stored event data.

Optionally, the event data includes an event generation time, and the event playback processing unit 134 is specifically configured to:

The apparatus provided in the embodiment of the present application may be specifically configured to execute the method flows provided in the embodiment corresponding to fig. 6 and any subsequent method embodiment, and specific functions are not described herein again.

According to the method and the device, the updating operation in the service system is packaged into the command, the service logic corresponding to the command is packaged into the event, the corresponding service logic is realized when the event is triggered to be executed, the service system is switched from data drive to event drive, the decoupling of the command and the event can be realized in the development stage of the service system, the development of processing logic related to the event corresponding to the command only needs to consider the issue of the event, the specific realization and execution of the service logic of the event do not need to be considered, and the development flexibility of the service system and the expandability of the service system are improved; furthermore, event data of all events are stored in an increasing mode, the event data comprise context information of the events, an event playback function is realized based on the stored event data, the events can be read and put into the context, the business logic corresponding to the execution events is called again, the business data are recovered to any appointed time point, and the safety of the business data is improved.

Fig. 15 is a schematic structural diagram of an electronic device according to an example embodiment of the present application. As shown in fig. 15, the electronic device 150 includes: a processor 151, and a memory 152 communicatively coupled to the processor.

Wherein the memory 152 stores computer-executable instructions; the processor 151 executes computer execution instructions stored in the memory 152 to implement the read-write separation method provided in any of the above method embodiments, and for specific functions and technical effects that can be achieved, reference is made to the above method embodiments, and details are not described herein again.

The present application further provides a computer-readable storage medium, in which computer-executable instructions are stored, and when the computer-executable instructions are executed by a processor, the computer-readable storage medium is configured to implement the read-write separation method provided by any one of the above method embodiments.

The present application further provides a computer program product, including a computer program, where the computer program is stored in a readable storage medium, and at least one processor of an electronic device can read the computer program from the readable storage medium, and the at least one processor executes the computer program to make the electronic device perform the read-write separation method provided by any of the above method embodiments.

In the several embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, a division of a unit is merely a logical division, and an actual implementation may have another division, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

Units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, or in a form of hardware plus a software functional unit.

The integrated unit implemented in the form of a software functional unit may be stored in a computer readable storage medium. The software functional unit is stored in a storage medium and includes several instructions to enable a computer device (which may be a personal computer, a server, or a network device) or a processor (processor) to execute some steps of the methods according to the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program codes, such as a usb disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.

It is obvious to those skilled in the art that, for convenience and simplicity of description, the foregoing division of the functional modules is merely used as an example, and in practical applications, the above function distribution may be performed by different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to perform all or part of the above described functions. For the specific working process of the device described above, reference may be made to the corresponding process in the foregoing method embodiment, which is not described herein again.

Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the application being indicated by the following claims.

It will be understood that the present application is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the application is limited only by the appended claims.

Claims

1. A method of read-write separation, comprising:

wherein the first domain model is different from the second domain model.

2. The method of claim 1, wherein,

the first code module updates the service data in the first database during running;

and the second code module reads service data from a second database during running, the second database and the first database are different databases, and the service data in the second database and the first database are kept synchronous.

3. A method of read-write separation, comprising:

executing the business logic corresponding to the event;

4. The method of claim 3, wherein the adding the event corresponding to the command further comprises:

storing event data for the event in an incremental store;

the executing the business logic corresponding to the event includes:

reading the event data of the event through an event processor, acquiring an event processing program of the event according to the event data, and executing the event processing program of the event, wherein the event processing program is used for realizing the business logic corresponding to the event.

5. The method of claim 4, wherein the event data for the event comprises: the number of abnormal retries and the retry interval corresponding to the event,

after the executing the service logic corresponding to the event, the method further includes:

and if the specified type of abnormality occurs during the execution of the business logic corresponding to the event, re-executing the business logic corresponding to the event according to the abnormal retry times and the retry time interval corresponding to the event.

6. The method of claim 4, wherein, after storing the event data for the event, further comprising:

7. The method of claim 6, wherein the event data includes event generation time, and the re-executing the business logic of the event corresponding to at least one event data according to the stored event data comprises:

acquiring event data of an event generated before a specified time point according to event generation time in the event data;

initializing initial service data of a service system to a database;

and according to the event data of the events generated before the appointed time point, sequentially executing the service logic of each event generated before the appointed time point according to the sequence of the event generated events so as to restore the service data in the database to the service data of the appointed time point.

8. An electronic device, comprising: a processor, and a memory communicatively coupled to the processor;

the memory stores computer-executable instructions;

the processor executes computer-executable instructions stored by the memory to implement the method of any of claims 1 to 6.

9. A computer readable storage medium having stored therein computer executable instructions for implementing the method of any one of claims 1 to 6 when executed by a processor.

10. A computer program product comprising a computer program which, when executed by a processor, implements the method of any one of claims 1 to 6.