Tôi sẽ chia thành các điểm mà tôi hy vọng sẽ có ý nghĩa. Tôi có thể đang băm nhỏ một chút về những gì tôi đã viết trong The Hitchhiker's Guide to Concurrency. Bạn có thể muốn đọc cái đó để biết chi tiết về lý do đằng sau cách truyền thông điệp được thực hiện trong Erlang.
1. truyền nhắn
nhắn qua trong Erlang được thực hiện thông qua các thông điệp không đồng bộ được gửi vào hộp thư (một loại hàng đợi để lưu trữ dữ liệu). Có hoàn toàn không giả định về việc liệu một tin nhắn đã được nhận hay chưa, hoặc thậm chí là nó đã được gửi đến một quá trình hợp lệ. Điều này là do có thể giả định [ở cấp độ ngôn ngữ] mà ai đó có thể muốn xử lý một tin nhắn trong có thể chỉ 4 ngày và thậm chí sẽ không thừa nhận sự tồn tại của nó cho đến khi nó đạt tới một trạng thái nhất định.
Một ví dụ ngẫu nhiên về điều này có thể là để tưởng tượng một quy trình chạy dài kéo dài dữ liệu trong 4 giờ. Nếu nó thực sự thừa nhận nó đã nhận được một tin nhắn nếu nó không thể đối xử với nó? Có lẽ nó nên, có lẽ không. Nó thực sự phụ thuộc vào ứng dụng của bạn. Như vậy, không có giả định được thực hiện. Bạn có thể có một nửa thư của mình không đồng bộ và chỉ một thư không phải là thư.
Erlang hy vọng bạn gửi một thông báo xác nhận (và đợi nó bằng một khoảng thời gian chờ) nếu bạn cần. Các quy tắc phải thực hiện với định thời gian và định dạng trả lời được để lại cho người lập trình để chỉ định - Erlang không thể giả định bạn muốn xác nhận về việc nhận tin nhắn, khi công việc được hoàn thành, cho dù nó khớp hay không (thông báo có thể khớp trong 4 giờ khi một phiên bản mới của mã được tải nóng), v.v.
Để làm cho nó ngắn gọn, cho dù tin nhắn không được đọc, không nhận được hoặc bị gián đoạn bởi ai đó kéo phích cắm trong khi nó đang trong quá cảnh không quan trọng nếu bạn không muốn nó. Nếu bạn muốn nó quan trọng, bạn cần phải thiết kế một logic trên các quy trình.
Gánh nặng thực hiện giao thức thông báo mức cao giữa các quy trình Erlang được trao cho người lập trình.
2. giao thức nhắn
Như bạn nói, những tin nhắn được lưu trữ trong bộ nhớ tạm thời: nếu một quá trình chết, tất cả các tin nhắn nó đã không đọc chưa bị mất. Nếu bạn muốn nhiều hơn, có nhiều chiến lược khác nhau. Một vài trong số đó là:
- Đọc tin nhắn nhanh nhất có thể và ghi vào đĩa nếu cần, gửi lại xác nhận và xử lý sau. So sánh điều này với phần mềm xếp hàng như RabbitMQ và ActiveMQ với hàng đợi liên tục.
- Sử dụng các nhóm quy trình để sao chép các thư trên một nhóm quy trình trên nhiều nút. Tại thời điểm này, bạn có thể nhập ngữ nghĩa giao dịch.Cái này được sử dụng cho cơ sở dữ liệu mnesia cho các giao dịch cam kết;
- Đừng cho rằng bất cứ điều gì đã hoạt động cho đến khi bạn nhận được xác nhận rằng mọi thứ đều ổn hoặc thông báo lỗi
- Kết hợp các nhóm quá trình và thông báo lỗi. Nếu một quá trình đầu tiên không xử lý được một nhiệm vụ (vì nút bị hỏng), một thông báo sẽ được VM gửi tự động đến một quá trình không thành công để xử lý nó. Phương pháp này đôi khi được sử dụng với các ứng dụng đầy đủ để xử lý các lỗi phần cứng.
Tùy thuộc vào nhiệm vụ hiện tại, bạn có thể sử dụng một hoặc nhiều thao tác này. Tất cả chúng đều có thể thực hiện trong Erlang và trong nhiều trường hợp, các mô-đun đã được viết để thực hiện việc nâng hạng nặng cho bạn.
Vì vậy, điều này có thể trả lời câu hỏi của bạn. Bởi vì bạn tự mình thực hiện các giao thức, đó là lựa chọn của bạn cho dù thư được gửi nhiều lần hay không.
3. lỗi khoan nhượng
Chọn một trong những chiến lược trên không phụ thuộc vào những gì lỗi khoan nhượng có nghĩa là bạn là gì. Trong một số trường hợp, mọi người muốn nói rằng "không có dữ liệu nào bị mất, không có tác vụ nào bị lỗi". Những người khác sử dụng khả năng chịu lỗi để nói "người dùng không bao giờ thấy sự cố". Trong trường hợp hệ thống Erlang, ý nghĩa thông thường là giữ cho hệ thống hoạt động: có thể có một người dùng đơn lẻ bỏ cuộc gọi điện thoại thay vì để mọi người bỏ nó.
Ở đây ý tưởng là sau đó để cho những thứ thất bại, nhưng giữ phần còn lại chạy. Để đạt được điều này, có một vài điều VM cung cấp cho bạn:
- Bạn có thể biết khi nào một quá trình chết và tại sao nó đã làm
- Bạn có thể buộc các quá trình phụ thuộc vào nhau để cùng chết nếu một trong số họ đi sai
- bạn có thể chạy một logger tự động đăng mỗi ngoại lệ còn tự do cho bạn, và thậm chí xác định riêng
- Nodes của bạn có thể được theo dõi để bạn biết khi họ đi xuống (hoặc bị ngắt kết nối)
- bạn có thể khởi động lại quá trình không thành công (hoặc gr oups của các quá trình thất bại)
- Có toàn bộ các ứng dụng khởi động lại trên các nút khác nhau nếu một trong những thất bại
- Và thứ hơn rất nhiều hơn với khuôn khổ OTP
Với những công cụ này và một vài trong số các module thư viện chuẩn của xử lý khác nhau kịch bản cho bạn, bạn có thể thực hiện khá nhiều những gì bạn muốn trên các ngữ nghĩa không đồng bộ của Erlang, mặc dù nó thường trả tiền để có thể sử dụng định nghĩa của Erlang về khả năng chịu lỗi.
4. Một vài lưu ý
ý kiến cá nhân của tôi ở đây là nó khá khó khăn để có giả định nhiều hơn những gì tồn tại trong Erlang trừ khi bạn muốn ngữ nghĩa giao dịch thuần túy. Một vấn đề bạn sẽ luôn gặp rắc rối là với các nút đi xuống.Bạn không bao giờ có thể biết được họ có đi xuống vì máy chủ thực sự bị lỗi hoặc do mạng không thành công.
Trong trường hợp xảy ra sự cố máy chủ, chỉ cần thực hiện lại các tác vụ thật dễ dàng. Tuy nhiên với một tách ròng, bạn phải chắc chắn rằng một số hoạt động quan trọng không được thực hiện hai lần, nhưng không bị mất một trong hai.
Nó thường sôi xuống CAP theorem mà về cơ bản cung cấp cho bạn 3 lựa chọn, trong đó bạn phải chọn hai:
- quán
- khoan dung Partition
- Availability
Tùy thuộc vào nơi bạn tự định vị, các phương pháp tiếp cận khác nhau sẽ là cần thiết. Định lý CAP thường được sử dụng để mô tả cơ sở dữ liệu, nhưng tôi tin rằng các câu hỏi tương tự sẽ được hỏi bất cứ khi nào bạn cần mức độ chịu lỗi khi xử lý dữ liệu.
Sự hiểu biết của tôi là khi một quá trình chết, và được respawned, bất cứ điều gì nó đã làm mà không được thông qua trở lại cần phải được làm lại. –
Rõ ràng là công việc chưa hoàn thành cần được làm lại ... Tôi nghĩ bạn đang đề xuất rằng trách nhiệm của ứng dụng là khởi động lại các tác vụ chưa hoàn thành (có thể là do hoàn thành theo dõi và gửi lại tin nhắn không thành công). Đó có phải là ý bạn không? Ai đó có thể xác nhận điều này từ kinh nghiệm? – joshng