Tại sao Akka tốt cho đồng thời?

Tôi chưa quen với Akka và khuôn khổ diễn viên - Tôi chắc chắn rằng tôi đang thiếu một cái gì đó rõ ràng, xin vui lòng chấp nhận lời xin lỗi của tôi trước.

Tôi tiếp tục đọc rằng một trong những điểm chính để chọn Akka là cách nó quản lý đồng thời.

Tôi không rõ tại sao Akka lại đặc biệt đến thế; Tôi hiểu rằng có nhiều diễn viên nhỏ rất nhẹ và nhanh; tuy nhiên, làm thế nào điều này có thể giúp tôi khi hai người dùng lưu một biểu mẫu cùng một lúc?

Tôi vẫn không cần một số loại khóa đồng thời (bi quan / lạc quan / vv ..) chứ?

Một trong những lợi thế của các mô hình xử lý thông báo như các tác nhân và tác nhân là các vấn đề tương tranh truyền thống (chủ yếu là đồng bộ hóa trạng thái chia sẻ) không còn là vấn đề nữa. Các diễn viên có thể giữ trạng thái riêng tư và cập nhật nó một cách tự do mà không cần khóa. Khung diễn viên đảm bảo rằng chỉ có một tin nhắn được xử lý tại một thời điểm. Với xử lý nối tiếp, mã có thể được viết theo cách không khóa.

Trong ví dụ của bạn về việc người dùng lưu một biểu mẫu, giả sử diễn viên đang giữ Danh sách một số dữ liệu từ mỗi biểu mẫu, diễn viên có thể cập nhật danh sách mà không cần khóa, bởi vì khung đảm bảo rằng chỉ có một biểu mẫu sẽ được xử lý tại một thời điểm. Theo truyền thống, bạn sẽ phải khóa xung quanh danh sách truy cập hoặc sử dụng danh sách đồng thời.

Chiến lược đồng thời là một vấn đề hơi khác và vẫn là trách nhiệm của bạn (không có chiến lược nào là chiến lược phổ biến nhất). Để thay đổi ví dụ của bạn một chút, giả sử rằng cả hai người dùng đều cố gắng cập nhật phiên bản biểu mẫu CÙNG cùng một lúc. Không có chiến lược đồng thời, các thay đổi của một người sẽ ghi đè lên chiến lược khác (có thể là chiến thắng cuối cùng). Điều đó tốt, nhưng tốt nhất điều này dẫn đến hành vi không mong muốn cho người dùng có thay đổi bị ghi đè. Nếu họ xem biểu mẫu họ vừa thay đổi, nó sẽ có các giá trị không mong muốn (từ người dùng khác). Tệ nhất (khi chúng ta không chỉ nói về cập nhật biểu mẫu, mà những thứ như đơn đặt hàng vận chuyển) nó có thể dẫn đến tổn thất các loại (thời gian, doanh thu, v.v.).

Sử dụng chiến lược đồng thời giúp xác định các trường hợp này và có thể giải quyết chúng dựa trên các quy tắc kinh doanh. Ví dụ, Optimistic Concurrency có người dùng gửi phiên bản của biểu mẫu mà nó đang cập nhật. Khi diễn viên tiến hành xử lý thay đổi, thông báo rằng người dùng thứ 2 nghĩ rằng họ đang cập nhật Phiên bản 5 khi biểu mẫu thực sự ở Phiên bản 6 vì bản cập nhật của người dùng đầu tiên. Bây giờ ít nhất chúng tôi có thể thông báo cho người dùng thứ 2 rằng biểu mẫu đã thay đổi kể từ khi họ bắt đầu chỉnh sửa nó. Hoặc bất cứ quy tắc nào doanh nghiệp muốn thực thi ở đó.

Trong trường hợp cập nhật một biểu mẫu, có lẽ bạn không quan tâm nhiều đến sự tương tranh (tôi đoán vậy). Nhưng trong các trường hợp khác, nó có thể là một điều rất quan trọng để ít nhất có thể kiểm tra và xử lý các vi phạm. Bạn thậm chí có thể muốn bỏ qua vi phạm đồng thời, như nếu người dùng thay đổi các phần khác nhau (để tiếp tục tương tự biểu mẫu). Hoặc nếu thay đổi có tác động lớn đến doanh nghiệp (một đơn đặt hàng lớn), bạn muốn chấp nhận và giải quyết các xung đột nhỏ sau này (ví dụ: cập nhật thông tin liên hệ hàng năm chưa được hoàn thành).

Tôi tin rằng Akka có một số khía cạnh khác như cách nó xử lý các thất bại, người giám sát, v.v ... đó là những cân nhắc quan trọng đối với các tín đồ.

Tôi sẽ viết về Mô hình diễn viên nói chung (không chỉ Akka) so với các mô hình đồng thời khác như đồng thời dựa trên khóa cổ điển và bộ nhớ giao dịch gọn gàng.

Ưu điểm

1. Khái niệm dễ hiểu hơn và sử dụng

   • Khóa đồng thời dựa trên là khó khăn; đặc biệt là rất khó để làm cho đúng bởi vì có nhiều khái niệm để hiểu và sử dụng để chính xác và hiệu quả: khóa, semaphores, chủ đề, đồng bộ hóa, loại trừ lẫn nhau, rào cản bộ nhớ, vv

   • Diễn viên, mặt khác là một khái niệm trừu tượng hơn; bạn có diễn viên gửi và nhận tin nhắn. Không cần phải nắm bắt và sử dụng các khái niệm cấp thấp như hàng rào bộ nhớ.

2. Thực thi bất biến

   • Mutability là nguồn gốc của nhiều lỗi và lỗi trong lập trình, đặc biệt là trong các ứng dụng đa luồng. Mô hình diễn viên giải quyết vấn đề này bằng cách thực thi bất biến.

3. Ít bị lỗi

   • Vì hai lý do trên.

4. Có hiệu quả

   • Không hiệu quả bằng văn bản khóa tốt nhưng nói chung hiệu quả hơn bộ nhớ giao dịch phần mềm.

5. Dễ dàng mở rộng

   • Về mặt lý thuyết ít nhất, ứng dụng nên mở rộng khá tốt bằng cách thêm nhiều diễn viên để thực hiện công việc của bạn. Với khóa dựa là khá khó khăn để mở rộng quy mô.

Nhược điểm

1. Không phải tất cả các ngôn ngữ dễ dàng thực thi bất biến;

   • Erlang, ngôn ngữ mà các tác nhân phổ biến đầu tiên có tính bất biến ở cốt lõi của nó nhưng Java và Scala (thực ra là JVM) không thực thi tính bất biến.

2. Vẫn còn khá phức tạp

   • Các diễn viên dựa trên một mô hình lập trình không đồng bộ, không đơn giản và dễ mô hình hóa trong tất cả các kịch bản; đặc biệt khó xử lý các lỗi và các tình huống lỗi.

3. Không ngăn chặn bế tắc hoặc chết đói

   • Hai diễn viên có thể ở trong trạng thái chờ tin nhắn từ người khác; do đó bạn có một bế tắc giống như với các khóa, mặc dù dễ gỡ lỗi hơn nhiều. Với bộ nhớ giao dịch tuy nhiên bạn được đảm bảo bế tắc miễn phí.

4. Không hiệu quả lắm

   • Do tính bất biến được thi hành và vì nhiều tác nhân phải chuyển sang sử dụng cùng một chủ đề nên các tác nhân sẽ không hiệu quả như đồng thời dựa trên khóa.

Phần kết luận

Đồng thời dựa trên khóa là hiệu quả nhất nhưng khó lập trình và dễ bị lỗi; bộ nhớ giao dịch phần mềm rõ ràng nhất, dễ lập trình và ít xảy ra lỗi nhưng nó cũng kém hiệu quả nhất. Các diễn viên đang ở đâu đó ở giữa hai mô hình này với tất cả các khía cạnh: dễ lập trình, hiệu quả và khả năng phát hiện lỗi.