Đồng bộ hóa giữa hai hệ thống bằng MongoDB làm thay đổi

Chúng tôi đang phát triển hai hệ thống liên quan. Một trong số chúng (A) sẽ được cài đặt trên máy của khách hàng của chúng tôi. (B) còn lại sẽ được sử dụng bởi tổ chức của tôi.

Mỗi hệ thống có cơ sở dữ liệu riêng (quan hệ) và lược đồ của chúng khác nhau. Tuy nhiên, cả hai hệ thống phải được đồng bộ hóa. Ngoài ra, một số thay đổi trong B phải được xuất sang tất cả các hệ thống loại A và chỉ khác cho một hệ thống cụ thể.

Một số khách hàng không có kết nối Internet, do đó, trong một số trường hợp, việc đồng bộ hóa phải được thực hiện thông qua trao đổi tệp.

Vì vậy, chúng tôi đang lên kế hoạch để giải quyết vấn đề này như sau:

1. Mỗi hệ thống duy trì một thay đổi cơ sở dữ liệu của nó. Chúng tôi đang lên kế hoạch triển khai nó với MongoDB.
2. Khi một hệ thống khởi tạo quy trình đồng bộ hóa, nó sẽ lấy tất cả các thay đổi được thực hiện từ nhật ký. Nếu hệ thống là B, các thay đổi được truy xuất tùy thuộc vào điểm đến. Sau đó, hệ thống tuần tự hóa chúng theo định dạng XML và cuối cùng, gửi chúng (thông qua tệp hoặc mạng).
3. Khi điểm cuối khác nhận được bộ thay đổi, nó sẽ hủy kích hoạt chúng. Sau đó, hệ thống thực hiện một số biến đổi trên dữ liệu, có thể cần thiết và cuối cùng, ghi lại các thay đổi. Trong bước này, nếu cần thiết, hệ thống phải giải quyết các xung đột có thể tồn tại.
4. Cuối cùng, hệ thống máy thu gửi các thay đổi của nó (và các sản phẩm khác của giải quyết xung đột).

Là phương pháp này khả thi, có thể mở rộng và thanh lịch? Những thay đổi hoặc bổ sung bạn sẽ thực hiện?

Nếu bạn chưa làm như vậy, bạn có thể thấy thú vị khi đọc các hệ thống hướng sự kiện, tìm nguồn cung ứng sự kiện và tính nhất quán cuối cùng. Hệ thống bạn đang mô tả có nhiều điểm tương đồng với các mẫu này, đó là một điều tốt.

Cách tiếp cận của bạn nghe có vẻ tốt, đặc biệt:

• Việc sử dụng một thay đổi được đặt hàng có nghĩa là quá trình đồng bộ hóa chỉ có thể truy xuất các thay đổi được thực hiện kể từ lần thay đổi được nhìn thấy lần cuối. Điều này sẽ giảm thời gian xử lý giúp khả năng mở rộng và sẽ cho phép bạn xây dựng đồng bộ hóa gần như thời gian thực trong trường hợp có kết nối internet.
• Khách hàng không có kết nối internet buộc bạn phải suy nghĩ về việc xử lý đồng bộ hóa chậm và không theo thứ tự ngay bây giờ, thay vì dựa vào đồng bộ hóa nhanh và vô tình kết thúc với các vấn đề về khả năng mở rộng.

Nếu không biết thêm về mô hình miền, tôi đoán rằng việc giải quyết xung đột là phần sẽ gây rắc rối cho bạn nhất. Tôi sẽ dành thời gian suy nghĩ về cách giải quyết từng loại xung đột. Đặc biệt:

• Một số xung đột sẽ yêu cầu giải quyết người dùng?
• Là hệ thống khách hàng sẽ luôn là nơi chính xác để giải quyết xung đột?
• Có thể xảy ra xung đột trong hệ thống B sau bước 4 khi hệ thống khách hàng gửi các thay đổi của nó không?

Mỗi hệ thống duy trì một thay đổi cơ sở dữ liệu của nó. Chúng tôi đang lên kế hoạch triển khai nó với MongoDB.

Bạn có thể sử dụng một cửa hàng sự kiện . Có bất kỳ cập nhật dữ liệu sẽ tạo ra một sự kiện mới trong cửa hàng.

Khi một hệ thống khởi tạo quy trình đồng bộ hóa, nó sẽ lấy tất cả các thay đổi đã thực hiện từ nhật ký. Nếu hệ thống là B, các thay đổi được truy xuất phụ thuộc vào đích. Sau đó, hệ thống tuần tự hóa chúng theo định dạng XML và cuối cùng, gửi chúng (thông qua tệp hoặc mạng).

Bạn có thể sử dụng bất kỳ cơ chế nào để gửi sự kiện, nhưng sẽ dễ dàng hơn khi sử dụng xe buýt nếu có thể nếu bạn không phải xử lý các tệp. Thông thường chúng có thể được cấu hình để giữ tin nhắn cho đến khi có kết nối để gửi nó.

Khi điểm cuối khác nhận được bộ thay đổi, nó sẽ hủy kích hoạt chúng. Sau đó, hệ thống thực hiện một số biến đổi trên dữ liệu, có thể cần thiết và cuối cùng, ghi lại các thay đổi. Trong bước này, nếu cần thiết, hệ thống phải giải quyết các xung đột có thể tồn tại.

Đơn giản chỉ cần áp dụng các sự kiện cho các đối tượng miền của bạn.

Cuối cùng, hệ thống máy thu gửi các thay đổi của nó (và các sản phẩm khác của giải quyết xung đột).

Sử dụng cách tiếp cận tương tự.