Introduction to Actor Model __actor

Brief Introduction

Actor this model was presented by Carl Hewitt in 1973, Gul Agha published in 1986 technical Report "ACTORS:A Model of Concurrent computation in distributed Systems", Actor model is a common model in concurrent programming, and many development languages provide native support, such as Erlang,scala. actor Features

-actor refers to a basic computational unit in which everything is actor. Actor and actor do not share memory, there is no mutual invocation, only message notification, actor data state entirely by their own maintenance;
-actor can be simply understood as the whole of data, behavior and message, the data refers to the internal state and context, the behavior refers to the logical processing method, the message refers to the type message that can be processed;
-Fault tolerant, Erlang introduces " As it collapses, "the philosophical idea that this part of the key code is monitored, the sole responsibility of the monitor is to know what after the code crashes (such as resetting the Unit code to normal), actor also for their own monitoring strategy, such as the occurrence of abnormal restart actor, so that it can heal;
-Distributed features, a actor to another actor send messages, it does not care whether it is local or remote, as long as the message can be reached on the line, which allows us to build a cluster system on multiple machines;
-The relationship between threads, the idea of the actor model is more abstract than the thread update, and its underlying implementation is implemented by the thread pool, but the shadow of thread is not visible in the programming process. actor Behavior can create other actor, the overall actor system is rendered as a tree structure, with a top-level root node that itself is created and supervised by the parent actor, sends messages to other actor, and specifies the behavior of the message when it arrives. Task Scheduling

The task scheduling method of actor model is divided into thread scheduling and event-based scheduling, and the general implementation will be based on event scheduling.
Thread-based scheduling refers to assigning a thread to each actor, which is simpler to implement, but the disadvantages are obvious, because the number of threads in the operating system is limited and the cost of the thread is greater because the actor is bound to the thread.
Event-based scheduling is the binding of the actor to the thread pool, so that the resource utilization will be more reasonable, but the whole scheduling process will be more complex. Why the Actor model appears

The actor model appears in response to concurrent business scenarios for distributed systems. Concurrency and parallelism are two similar and different concepts, concurrency refers to a period of time multiple business processes from the beginning to the end of the process, parallel refers to a number of business processes at the same time, you can clearly see that concurrency and parallel the biggest difference is whether it is at the same time.
In order to deal with the concurrent business scenario, the general system adopts the multithreading scheme, which improves the throughput of the receiving request, and the backend makes full use of the computing resources of the machine. This method can be divided into FIFO queue push mode and message-driven mode two kinds, either way there is a situation where the data is shared between threads, such as shared cache information or queue messages, where there is a global share of data that requires synchronization, and synchronization can lead to performance loss and pessimistic lock problems.
Actor model is a good solution to the problem of data sharing, because the actor itself to maintain its own data state, not subject to other actor interference will not modify other actor, only by receiving messages for processing requests, but this through the multi-layer actor between processing will inevitably lead to communication loss, But for the distributed system is affirmative, need to the business and actor model between the design of a good granularity division, not too large and too small.