Đọc tài liệu ActiveMQ (chúng tôi đang sử dụng bản phát hành 5.3), tôi tìm thấy một phần về khả năng sử dụng bộ điều hợp persistence JDBC với ActiveMQ.Khi nào tôi nên sử dụng Bộ điều hợp Persistence JDBC trong ActiveMQ?
Lợi ích là gì? Liệu nó có cung cấp bất kỳ lợi ích nào về hiệu năng hay độ tin cậy không? Khi nào tôi nên sử dụng?
Theo ý kiến của tôi, bạn sẽ sử dụng JDBC kiên trì nếu bạn muốn có một nhà môi giới chuyển đổi dự phòng và bạn không thể sử dụng hệ thống tệp. Sự tồn tại của JDBC chậm hơn đáng kể (trong các thử nghiệm của chúng ta) hơn là ghi nhật ký cho hệ thống tệp. Đối với một nhà môi giới duy nhất, hệ thống tệp được ghi nhật ký là tốt nhất.
Nếu bạn đang chạy hai nhà môi giới trong một chuyển đổi chủ động/thụ động, hai nhà môi giới phải có quyền truy cập vào cùng một cửa hàng tạp chí/dữ liệu để người môi giới thụ động có thể phát hiện và tiếp quản nếu chính không thành công. Nếu bạn đang sử dụng hệ thống tệp được ghi nhật ký, thì các tệp phải nằm trên một ổ đĩa mạng chia sẻ của một số loại, sử dụng NFS, WinShare, iSCSI, v.v. Điều này thường yêu cầu thiết bị NAS cao cấp hơn nếu bạn muốn loại bỏ tệp chia sẻ một điểm thất bại.
Tùy chọn khác là bạn có thể trỏ cả nhà môi giới vào cơ sở dữ liệu mà hầu hết các ứng dụng đã có quyền truy cập. Sự cân bằng thường đơn giản ở mức giá của hiệu năng, vì sự tồn tại của JDBC được ghi nhận là chậm hơn trong các thử nghiệm của chúng tôi.
Chúng tôi chạy ActiveMQ trong cặp môi giới hoạt động/thụ động với sự kiên trì được ghi nhật ký thông qua một NFS gắn kết với một thiết bị NAS chuyên dụng, và nó hoạt động rất tốt cho chúng tôi. Chúng tôi có thể xử lý hơn 600 thông điệp/giây thông qua hệ thống của chúng tôi mà không có vấn đề gì.
Hey, việc sử dụng JDBC được ghi nhật ký có vẻ tốt hơn việc sử dụng JDBC bền vững chỉ vì việc ghi nhật ký nhanh hơn rất nhiều so với JDBC. Nó là tốt hơn so với chỉ journalled kiên trì chỉ cos 'bạn có một bản sao lưu bổ sung của các tin nhắn trong db. JDBC Journalled có lợi thế bổ sung rằng cùng một dữ liệu trong tạp chí được duy trì cho db sau này và điều này có thể được truy cập bởi các nhà phát triển khi cần thiết!
Tuy nhiên, khi bạn đang sử dụng cấu trúc liên kết ActiveMQ chính/phụ thuộc JDBC được ghi đè, bạn có thể sẽ mất thư vì bạn có thể có thư trong tạp chí chưa được nhập vào DB!
Nếu bạn có chính sách plugin phân phối lại tại chỗ và sử dụng thiết lập chính/phụ, trình lập lịch được sử dụng để phân phối lại.
Tính đến hôm nay, trình lập lịch biểu chỉ có thể được thiết lập trên cơ sở dữ liệu tệp chứ không phải trên JDBC. Nếu bạn không chú ý đến điều đó, bạn sẽ nhận tất cả các thư đang trong quá trình phân phối lại trong kịch bản HA và địa phương cho người môi giới.
https://issues.apache.org/jira/browse/AMQ-5238 là một vấn đề trong trình theo dõi vấn đề Apache yêu cầu bộ điều hợp lưu giữ JDBC cho schedulerdb. Bạn có thể bỏ phiếu cho nó để làm cho nó xảy ra.
Thực ra, ngay cả trên giải pháp AMQ HA hàng đầu, LevelDB + ZooKeeper, trình lên lịch được đưa ra khỏi trò chơi và được ghi lại để tạo sự cố (http://activemq.apache.org/replicated-leveldb-store.html ở cuối trang).
Trong một kịch bản JDBC, nó có thể được coi là không an toàn và không được hỗ trợ, nhưng ít nhất không được ghi chép rõ ràng, cách thiết lập kho dữ liệu cho chính sách gửi lại.
Yeap, đó chính xác là trải nghiệm của tôi. Trong các thử nghiệm của chúng tôi, sự tồn tại của JDBC chậm hơn nhiều lần so với tùy chọn journalling. Cảm ơn –