2009-06-09 17 views
12

Một trong các tính năng của mô hình diễn viên trong Erlang là phân phối trong suốt. Trừ khi tôi hiểu sai, khi bạn gửi thông điệp giữa các diễn viên, về mặt lý thuyết bạn không nên giả định rằng họ đang ở trong cùng một không gian quy trình hoặc thậm chí là đồng đặt trên cùng một máy vật lý.Sự hỗ trợ của Erlang đối với phân phối * trong suốt * của các tác nhân tác động đến thiết kế ứng dụng như thế nào?

Tôi luôn bị ấn tượng rằng các hệ thống chịu lỗi, phân phối yêu cầu thiết kế ứng dụng cẩn thận để giải quyết các vấn đề cố hữu xung quanh ordering/causalityconsensus (trong số những người khác).

Tôi khá chắc chắn rằng Erlang không hứa sẽ giải quyết các lớp này của các vấn đề một cách minh bạch, vì vậy câu hỏi của tôi là, làm thế nào để các nhà phát triển Erlang đối phó với điều này? Bạn có thiết kế ứng dụng của mình như thể tất cả các diễn viên đang ở trong cùng một không gian quy trình và sau đó chỉ giải quyết các vấn đề phân phối khi đến lúc thực sự phân phối chúng?

Nếu vậy, là này minh bạch tính năng phân phối của Erlang thực sự chỉ quan tâm đến giao thức dây sử dụng để nhắn tin từ xa và không thực sự suốt theo nghĩa là một ứng dụng phân tán đúng vẫn đòi hỏi thiết kế cẩn thận trong lớp ứng dụng?

Trả lời

3

Bạn đúng rằng erlang vốn không giải quyết được vấn đề Đặt hàng/Quan hệ nhân quả hoặc Đồng thuận. Điều gì erlang làm trừu tượng cho bạn là sự khác biệt giữa việc gửi tin nhắn đến các nút cục bộ hoặc từ xa.

Tôi không chắc chắn thực sự có thể giải quyết những vấn đề đó trong thiết kế ngôn ngữ hay không. Đó là đúng hơn thuộc về một khuôn khổ. Khung công tác OTP có một số công cụ để trợ giúp điều đó. Thực sự mặc dù nó phần nào phụ thuộc vào vấn đề cụ thể mà bạn đang giải quyết.

Đối với một ví dụ về thực hiện cái nhìn Erlang VectorClock tại distributerl Erlang OTP giám sát cũng có thể cung cấp một số cơ sở hạ tầng cần thiết cho sự đồng thuận nhưng có một số nghĩ rằng đồng thuận là điều không thể trong thông điệp không đồng bộ thông qua hệ thống phân phối. Xem trang wiki được tham chiếu của bạn để biết thêm thông tin về điều đó.

3

Erlang thực sự, giải quyết những vấn đề này một cách minh bạch. Nó có thể làm điều này bởi vì nó là một ngôn ngữ chức năng với các biến không thay đổi (một lần gán). Nó sử dụng Actor model cho đồng thời, và được thiết kế đặc biệt để cho phép trao đổi nóng mã và lập trình đồng thời mà không cần lập trình viên phải lo lắng về synchronization.

Các Wikipedia article thực sự có một mô tả khá tốt về điều này. Đó là sự hiểu biết của tôi rằng Ericsson đã phát minh ra ngôn ngữ như một cách thiết thực để lập trình các thiết bị chuyển mạch điện thoại song song.

+1

Re: synchronicity, tôi đã đề cập đến các mối quan hệ nhân quả và các vấn đề đặt hàng sự kiện phát sinh trong các hệ thống phân tán chịu lỗi nhiều hơn "đồng bộ hóa dữ liệu". Tôi sẽ xem liệu tôi có thể làm rõ phần đó một chút không. –

3

Erlang hứa hẹn những điều (http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf mục 3.1 (39-40)):

  • Tất cả mọi thứ là một quá trình.
  • Quy trình được phân tách mạnh.
  • Quá trình tạo và hủy là quá trình hoạt động nhẹ.
  • Tin nhắn là cách duy nhất để các quá trình tương tác.
  • Quy trình có tên duy nhất.
  • Nếu bạn biết tên của một quá trình, bạn có thể gửi một tin nhắn.
  • Quy trình không chia sẻ tài nguyên.
  • Xử lý lỗi không phải là cục bộ.
  • Quy trình thực hiện những gì chúng được cho là phải làm hoặc thất bại.

và phần còn lại tùy thuộc vào bạn. Nếu bạn muốn biết lý do tại sao xem chương 2. Một thời gian ngắn, bạn có thể gửi tin nhắn để xử lý nếu bạn biết PID của nó ngay cả khi nó là trên một mảnh HW. Bạn không thể chắc chắn nếu thư đến nơi trừ khi bạn nhận được phản hồi với bí mật chung. Bạn có thể chắc chắn rằng bạn sẽ nhận được thông báo lỗi khi quá trình thất bại khi bạn giám sát (hoặc liên kết) nó. Đó là những yếu tố cơ bản mà bạn có thể xây dựng những gì bạn muốn.

+1

Cảm ơn bạn đã liên kết. Tôi nghĩ nó nhắc lại quan điểm của tôi rằng "sự phân bố trong suốt" của Erlang thực sự chỉ là "thông điệp từ xa trong suốt". Tôi đồng ý với @ {Jeremy Wall} rằng có vấn đề nảy sinh khi bạn phân phối các hệ thống không thể giải quyết một cách minh bạch. Ví dụ: những người được nêu trong bài báo này: http://research.sun.com/techrep/1994/smli_tr-94-29.pdf –

Các vấn đề liên quan