Seda Introduction and Source code interpretation (i)

Introduction:

--------------------------------------------------------------------------------------------------------------- -----------------------------------------------------

/*

* The content of the split line is purely reference

* Original Author: Zhu Zhiguang

* Original address: http://larryzhu.bokee.com/6779982.html

*/

First, the preface

Staged Event driven Architecture (SEDA) is an excellent high-performance Internet server architecture model studied at the University of California, Berkeley. Its design objectives are: to support large-scale concurrent processing, simplify system development, support processing monitoring, support system resource management. This article will first introduce two network server architecture models that are widely used. The Seda is then described in detail.

Two, the current popular concurrent processing programming model

1. Multi-threaded server (threaded)

How it works: For each request,dispatcher, a thread is created and assigned to it. The thread is responsible for handling this request. This way is also known as (Thread-per-request).

Advantages: The execution granularity is the entire process flow. The processing logic is clear and easy to develop.

Disadvantage: The number of threads that cause concurrent execution is too large as processing requests are increasing. The excessive number of threads causes the system to have too much overhead in thread scheduling and resource contention. Cause the system performance to drop dramatically. resulting in decreased system processing capacity.

Improvement measures: Thread pool (bounded thread pools)

The system can create up to a certain number of threads. When all threads are saturated, the newly arrived processing request can only wait, or be discarded.

Disadvantages:

The execution granularity is still the complete processing flow. It is difficult to detect the root cause of system performance bottleneck and adjust accordingly.

2. Event-driven concurrent processing (Event-driven concurrency)

The processing process is split into multiple steps, each of which is implemented as a finite state machine (FSM).

How it works: All processing requests Enter the system as an event. The scheduler is responsible for passing it to the corresponding FSM. The processing result of the FSM is also exported to scheduler in event form. The new event will again be forwarded to the next FSM by scheduler. Until the processing is complete.

Advantages:

1, with the increase in processing volume, the system load is linear growth. When the system saturation processing capacity is reached. The processing power of the system will not decrease.

2, because the various processing steps are implemented independently, can be very easy to carry out system monitoring and adjustment.

Disadvantages:

The design and implementation of scheduler is too complex. Different implementations are required for different applications and logical changes in the system.

iii. structure of Seda

(approximate to Event-driven concurrency, but without scheduler)

Separate each processing step into a stage.

Stage structure:

1, an event Queue to accept input;

2, an application developer written by the event Handler;

3. A controller is used to control the execution process. Includes number of concurrent threads, batch quantity, ...;

4, a thread pool for concurrent processing;

Stage input is obtained through event queue. Stage output is pushed to the event queue of Other stage in event form. This connection between stage is specified by the application developer.

The problem: The Event queue reduces the coupling between modules, but reduces the response speed.

Iv. Summary of:

The Seda architecture splits the entire processing of the application into multiple steps, namely stage. Each stage can be developed independently. At the same time, communication between stage through event queue can reduce the coupling. Can adapt to the future system logic changes at a very small cost.

At the same time, the system provides standard resource control, so that the application developers only need to focus on implementing the internal logic of event handler. Without the need to focus on multithreading, resource sharing 、...

The operation of each stage can be monitored and adjusted at run time. -----------------------------------------------------------------------Split Line----------------------------------------------- -------------------------------------

Recently, I also read this paper from Harvard "1", originally wanted to translate, translated about one-fifth, regrets the length of the article, the speed of the slow, coupled with their own things more, the enthusiasm is decreasing, also do not want to go on.

In fact, we should draw on the idea of its design (although some people think that it has a strong academic flavor, and did not take into account the practical application of the complex logic), the fact that Taobao open source Netty "2" (an event-based asynchronous communication framework) is the standard Seda architecture.

Source Analysis

There are already some introductions and studies about Seda on the Internet. In the paper, refers to a seda based implementation--sandstorm, recently also looked at the source. Recently want to launch their own source of the project interpretation (source code at the end to provide downloads).

The following figure is the Sandstorm Open Interface (located in Package:seda.sandstorm.api), although I've tried to make the UML diagram clearer, but because of the complexity of the relationship, it seems a bit confusing.

Next, let's split it up and see what each interface offers:

Stageif: Represents the layer of an application. Applications do not implement Stageif directly, but implement Eventhandlerif. Stageif is used by an event handler to access other layers. Examples of Stageif are obtained by Manageif.getstage ().

Eventhandlerif: Represents an event handler, the base unit of the sandstorm component. It is a basic interface that all modules of an application need to implement.

Sourceif,sinkif,Queueif These three interfaces are used to implement event queues. Inheritance relationships See the following figure:

Wherein, SINKIF and Sourceif represent the ends of a queue respectively. Sinkif means "slot", which is visualized as a "sink" connected to the front layer, where events are "flowing" into the queue, so it only supports the event's queued operation. Sourceif represents the "source side", which is understood as the "event source" We want to get from the event queue for processing, so it only supports outbound operations. Queueif directly inherits the two interfaces and does not increase its own extra operations, creating a "queue".

As you can see, this design is very flexible. It does not directly in the physical implementation of a data structure of the queue, but with the implementation of the team, out of the operation of the logical implementation of a "queue." This gives you two benefits, you can implement the logic of the team and the teams, and as long as you get the interface, you get the "power" to join the event and team out.

Queueelementif: Represents an event base interface, and since Queueif represents an event queue, its elements are naturally an event. Any defined "event" must implement the interface. Some definition events have been provided for the following figure:

classqueueelementif: An event based on "rank";

sinkcloggedevent: Sink is blocked event (triggers the event when sink is full or if certain conditions prevent a given element from being serviced);

sinkclosedevent: This event indicates that a sink has been closed, either the application intentionally closed, or an error condition has been accidentally closed. When a sink is no longer serviced, it is considered closed;

sinkdrainedevent: This event indicates that a sink has been processed;

sinkflushedevent: This event indicates that a given sink is successfully refreshed and is typically generated by an invocation of a sinkif.flush ().

Profilerif: A profilerif represents a trace of the system's behavior, and if the system is running in trace logging mode, the application can get a handle on the Profilerif (by calling Managerif.getprofiler ()) ；

Profilableif: An object that implements Profilableif can be tracked by a profilerif. Typically, this means that the object has an assigned size (such as queue length, list length, memory size, and so on); Managerif: This is a management interface that provides access to some of the above interfaces;

It provides some run-time services to the application;

Signalif: It is also an event that represents a signal event, and all events that need to implement a signal notification need to implement it;

stagesinitializedsignal: It is an implementation of the Signalif that represents all the layers specified in the Sandstorm configuration file, or in Init () The layer created based on the specified initialization configuration during the invocation of the method has already been instantiated. Note that the extra layer can be created after the instantiation is complete;

Signalmgrif: Instantiation or control of the system-level "signal", the message event that the layer may wish to use;

Enqueuepredicateif: The join assertion interface, which allows the user to specify a method that masks elements when performing a queue operation on sink-either accepted or rejected. This scheme can be used to implement many interesting "conditional loading" strategies, such as simple threshold control, rate control, and credit based flow control. Note: The queued assertion runs in the context of Enqueue (), which means it must be simple and fast;

Configdataif: It is used to pass configuration parameters to the layer, and when a layer is instantiated, a configdataif is passed to its Init method;

Singlethreadedeventhandlerif: null interface, which indicates the system, an event handler must be single-threaded;

Source Download

Seda-release

Seda-eclipse project can be run directly

Reference

"1": http://www.eecs.harvard.edu/~mdw/papers/seda-sosp01.pdf

"2": http://rdc.taobao.com/team/jm/archives/423