Mô hình diễn viên có thể được sử dụng để cô lập nhà nước có thể thay đổi từ thế giới bên ngoài. Khi bạn có một trạng thái có thể thay đổi (ví dụ như một đăng ký toàn cục của các ID được gán cho nhiều tiến trình đồng thời), bạn có thể bao bọc trạng thái có thể thay đổi đó bên trong một Actor và làm cho khách hàng giao tiếp với Actor thông qua việc truyền thông điệp. Bằng cách đó, chỉ có nam diễn viên truy cập trực tiếp trạng thái có thể thay đổi và như bạn nói, các thông điệp khách hàng xếp hàng để được đọc và xử lý từng cái một. Điều quan trọng đối với tin nhắn là không thay đổi.
Để tránh hàng đợi bị đầy, điều quan trọng là việc xử lý tin nhắn (react, receive, v.v.) càng ngắn càng tốt.nhiệm vụ lâu dài nên được trao tắt để một diễn viên khác:
1. Actor A receives a message M from sender S
2. A spawns a new actor C
3. A sends (S, f(M)) to C
4. In parallel:
4a. A starts processing the next message.
4b. C does the long-running or dangerous (IO) task,
When finished, sends the result to S,
and C terminates.
Một số lựa chọn thay thế trong quá trình này:
- C gửi
(S, result) trở lại Một người chuyển tiếp đến S
- A giữ một ánh xạ
ActorRef C => (Sender S, Message M)so in case it sees C fail, nó có thể thử lại xử lý M với một diễn viên mới.
Vì vậy, để tóm tắt, một diễn viên là đa luồng đến mức mà nhiều khách hàng có thể gửi nó nhiều tin nhắn từ chủ đề khác nhau, và nó được đảm bảo rằng các diễn viên sẽ xử lý tất cả các thông báo serially (mặc dù thứ tự có thể tùy thuộc vào các ràng buộc không quá nghiêm ngặt khác nhau). Lưu ý rằng khi Mã số react của diễn viên , trong một thời điểm nhất định, nó chỉ được thực hiện trên một chuỗi cho trước (bạn có thể hình dung rằng diễn viên nhảy từ chuỗi này sang luồng khác khi trình lập lịch biểu phù hợp, nhưng điều này là một chi tiết kỹ thuật). Lưu ý: Trạng thái nội bộ vẫn không cần đồng bộ hóa, vì Actors guarantee happens-before semantics giữa các thông báo xử lý.
Tính song song đạt được bằng cách có nhiều diễn viên hoạt động song song, thường tạo thành supervisor hierarchies hoặc balancing workload.
Lưu ý rằng nếu tất cả những gì bạn cần là tính toán đồng thời/không đồng bộ, nhưng bạn không có hoặc có thể loại bỏ trạng thái toàn cầu, Futures are a better composing và khái niệm dễ dàng hơn.
Đây là một lời giải thích tuyệt vời, cảm ơn! – Brian
Câu trả lời hay. Tôi sẽ thêm rằng trong khi các phản ứng của một diễn viên có thể chạy trên các chủ đề khác nhau (và do đó sẽ 'thường' bị các vấn đề về bộ nhớ), bạn thực sự không cần đồng bộ hóa quyền truy cập vào trạng thái của tác nhân. Điều này là do khung diễn viên đã làm như vậy trước khi thực hiện một diễn viên. Xem http://stackoverflow.com/questions/1031167/should-my-scala-actors-properties-be-marked-volatile –
Rất vui khi được trợ giúp. Régis: Cảm ơn, đã cập nhật văn bản chính xác hơn. – ron