Tôi có một vai trò làm việc đơn giản trong Azure có một số xử lý dữ liệu trên cơ sở dữ liệu Azure của SQL. Nhân viên cơ bản thêm dữ liệu từ nguồn dữ liệu của bên thứ 3 vào cơ sở dữ liệu của tôi sau mỗi 2 phút. Khi tôi có hai trường hợp của vai trò, điều này rõ ràng tăng gấp đôi lên không cần thiết. Tôi muốn có 2 trường hợp cho dự phòng và thời gian hoạt động 99,95, nhưng không muốn cả hai xử lý cùng một lúc vì họ sẽ chỉ sao chép cùng một công việc. Có một mô hình tiêu chuẩn cho điều này mà tôi đang thiếu? Tôi biết tôi có thể đặt cờ trong cơ sở dữ liệu, nhưng tôi hy vọng có một cách dễ dàng hơn hoặc tốt hơn để quản lý điều này. Cảm ơnKiểm soát vai trò của nhân viên công việc đồng thời trong nhiều trường hợp
Trả lời
Khi đánh dấu được đề xuất, bạn có thể sử dụng hàng đợi Azure để đăng thông báo. Bạn có thể có thể hiện vai trò của nhân viên gửi một thông báo tiếp theo tới hàng đợi như là điều cuối cùng nó thực hiện khi xử lý thông báo hiện tại. Điều đó sẽ giải quyết vấn đề Mark đã nêu lên sự cần thiết phải có một semaphore. Trong thông điệp xếp hàng của bạn, bạn có thể nhúng dấu thời gian khi thông báo có thể được xử lý. Khi tạo thư mới, chỉ cần thêm hai phút vào thời gian hiện tại.
Và ... trong trường hợp không rõ ràng: trong trường hợp vai trò vai trò của nhân viên bị treo trước khi hoàn tất quá trình xử lý và không gửi lại tin nhắn xếp hàng mới, điều đó là tốt. Trong trường hợp này, thông báo hàng đợi hiện tại sẽ đơn giản xuất hiện trở lại trên hàng đợi và một cá thể khác sau đó tự do xử lý nó.
Hãy chắc chắn rằng bạn thực hiện một bộ lọc thông điệp độc, mặc dù: nếu một vai trò công nhân bị rơi vì thông điệp cụ thể đó, bạn không muốn nó được reposted đến hàng đợi hơn và hơn. Số lượng đăng lại (hoặc số lần đọc) có thể giúp bạn ở đó. – tijmenvdk
@tijmenvdk - đã đồng ý. –
Làm cách nào để bạn khởi động máy vĩnh viễn này? Nếu bạn có hai trường hợp của một vai trò bắt đầu cùng một lúc mà một người nên đăng bài thứ nhất? –
Không có cách nào dễ dàng để thực hiện việc này, tôi không nghĩ.
Bạn có thể sử dụng một semaphore như Mark đã đề cập, về cơ bản ghi lại sự bắt đầu và ngừng xử lý. Sau đó, bạn có thể có bất kỳ số lượng các trường hợp chạy, mỗi kiểm tra hồ sơ semaphore và chỉ hành động ra nếu semaphore cho phép nó.
Tuy nhiên, báo trước ở đây là điều gì sẽ xảy ra nếu một trong các trường hợp bị treo ở giữa quá trình xử lý và không bao giờ phát hành semaphore? Bạn có thể triển khai giá trị "hết giờ" sau khi các phiên bản khác sẽ cố gắng bắt đầu xử lý nếu không có thời gian mở khóa X. Ngoài ra, bạn có thể sử dụng dịch vụ giám sát của bên thứ ba như AzureWatch để xem các trường hợp không phản hồi trong Azure và bắt đầu phiên bản mới nếu số lượng "Sẵn sàng" trong trường hợp dưới 1. Điều này sẽ giúp bạn tiết kiệm một số tiền bằng cách không phải có 2 trường hợp và chạy tất cả thời gian, nhưng có một sự chậm trễ nhỏ giữa khi một thể hiện không thành công và khi một phiên bản mới được bắt đầu.
Một Semaphor như được đề xuất sẽ là cách để đi, mặc dù tôi có lẽ sẽ đi với một nhịp tim tim đơn giản trong cửa hàng blob.
Ý nghĩ khác là, nó cần thiết như thế nào? Nếu tải của bạn có thể duy trì được xuống trong một vài phút, có thể chỉ để cho vai trò tái chế?
Bắt nhỏ về giải pháp của David. Việc đăng lại tin nhắn đến hàng đợi sẽ xảy ra như là điều cuối cùng trên thực thi hiện tại để nếu máy bị treo dọc theo cách thông điệp hiện tại sẽ hết hạn và tái xuất hiện trên hàng đợi. Điều đó giả định rằng thông điệp ban đầu được nhìn thấy và yêu cầu một hoạt động de-queue để loại bỏ khỏi hàng đợi. Hàng đợi phải xảy ra trước khi chèn thông điệp mới vào hàng đợi. Nếu vai trò bị treo ở giữa 2 thao tác này, thì sẽ không còn các mã thông báo nào trong hệ thống và sẽ dừng lại. Kiểm tra song công ESB có vẻ giống như một cách tiếp cận khả thi, nhưng nó không có vẻ giống như xác định vì xe buýt chỉ có thể kiểm tra các thông điệp giống hệt nhau hiện có trong hàng đợi. Nhưng nếu một trong các thông điệp xuất hiện ngay sau khi thông báo trước bị xóa, có một cơ hội để kết thúc với 2 quy trình chạy song song.
Một giải pháp thay thế, nếu bạn có thể đủ khả năng, sẽ không bao giờ bỏ hàng đợi và chỉ cho thuê tin nhắn thông qua các hoạt động Peek. Bạn sẽ phải đảm bảo rằng thời gian chờ tàng hình không bao giờ vượt quá thời gian xử lý trong vai trò công nhân của bạn. Theo như tạo ra các mã thông báo ở nơi đầu tiên, cùng một chiến lược khởi động vai trò công nhân được mô tả trước khi kết hợp với kiểm tra song công ASB sẽ làm việc (vì các tin nhắn sẽ không bao giờ di chuyển từ hàng đợi).
- 1. Đồng bộ hóa vai trò của Azure
- 2. ServicePointManager.DefaultConnectionLimit trong vai trò công nhân
- 3. Vai trò web và vai trò của nhân viên trong dịch vụ đám mây/Node.js
- 4. Làm cách nào để kiểm tra vai trò của nhân viên công việc trên máy địa phương?
- 5. Vai trò và trường hợp Azure
- 6. Sử dụng SignalR trong Vai trò Công nhân Azure
- 7. Không đồng bộ/chờ đợi trong vai trò công nhân xanh làm cho vai trò tái chế
- 8. Trường hợp Azure và vai trò web
- 9. Cách chạy RavenDb trong Azure trong vai trò của nhân viên
- 10. Lập trình các cá thể mới của vai trò công nhân
- 11. Lấy URL DNS cho vai trò (công nhân) Azure
- 12. Nhiều hệ thống kiểm soát phiên bản đồng thời?
- 13. Các trang web được xuất bản lên Azure có vai trò của nhân viên không?
- 14. Yii framework: kiểm soát dựa trên vai trò truy cập
- 15. Cách triển khai chỉ vai trò công nhân/web trong Azure
- 16. Nhân viên nền công việc C#
- 17. Sử dụng Thread.Sleep hoặc Timer trong vai trò nhân viên Azure trong .NET?
- 18. Thành viên ASP.net - thêm vai trò
- 19. Làm cách nào để lưu trữ vai trò của nhân viên Azure cục bộ/trên tiền đề?
- 20. Cách bắt ngoại lệ không được giải quyết trong Vai trò của Windows Azure (Công nhân)
- 21. Kiểm soát truy cập dựa trên vai trò (RBAC) - .Net Component
- 22. Chỉ định vai trò gán vai trò cho người dùng trong MVC 4 qua hộp kiểm
- 23. Chủ đề công nhân là gì và vai trò của họ trong mẫu lò phản ứng là gì?
- 24. Nhiều vai trò người dùng trong Ruby on Rails
- 25. Ngăn chặn ngoại lệ không được giải quyết từ việc rớt xuống vai trò công nhân Azure
- 26. Cách lên lịch một tác vụ trong cửa sổ vai trò công nhân azure
- 27. Chạy vai trò Azure ở nhiều vùng?
- 28. PHP Daemon/môi trường công nhân
- 29. Vai trò của Designer.cs Tệp trong C#
- 30. Chuyển đổi tệp cấu hình với vai trò công nhân Azure
Vâng, bạn có thể đặt thông điệp kích hoạt trên hàng đợi Azure, bởi vì chỉ một khách hàng có thể đọc một tin nhắn tại một thời điểm. Tuy nhiên, điều này chỉ đặt ra câu hỏi về cách tạo những tin nhắn đó ngay từ đầu. Nếu bạn thực hiện điều đó từ Worker Roles theo các khoảng thời gian đã lên lịch, bạn có cùng một vấn đề một lần nữa bởi vì mỗi Role Worker đồng thời sẽ gửi cùng một thông điệp vào khoảng thời gian đó. Tôi không thể nghĩ ra một giải pháp cho điều này mà không liên quan đến một semaphore của một số loại. –