Tôi muốn nhiều người dùng chỉnh sửa cùng một tài liệu. Vấn đề tôi gặp phải là khi một người dùng mới tham gia, anh ta có thể thấy một tài liệu lỗi thời. Làm cách nào để đảm bảo rằng người dùng mới nhận được những thay đổi gần đây nhất?

Một số giải pháp tôi nghĩ ra:

• Tiết kiệm cho mọi thay đổi. Tôi không thích giải pháp này vì nó sẽ làm chậm mọi thứ trên UI và tải trên db.

• Khi người dùng mới tham gia, kích hoạt lưu trên tất cả các máy khách khác. Sau khi khách hàng khác lưu, tải tài liệu. Với điều này có thể vẫn còn mâu thuẫn.

Bất kỳ đề nghị khác sẽ hữu ích.

CẬP NHẬT: Sau khi xem xét giải pháp được đề xuất, Google Realtime API, tôi phát hiện ra rằng:

1. Người dùng ứng dụng của bạn phải có Google Drive và cấp cho bạn quyền truy cập vào ổ đĩa của họ . Điều này có thể tốt nhất hiện tại luồng UI khó xử hoặc ngăn người dùng không có Google Drive sử dụng tính năng thời gian thực.

2. Tất cả các cài đặt chia sẻ được thực hiện về phía bạn, phải được sao chép cho tài liệu Google.

CẬP NHẬT 2: Để hoàn thành mục tiêu, tôi đã đi với Firebase của Google

Google Drive

Nếu bạn đang cố gắng tạo phiên bản tài liệu google của riêng mình, tôi khuyên bạn nên xem API thời gian thực của Google . Google gần đây đã phát hành điều này với mục đích cho phép các nhà phát triển khác sử dụng cùng các công cụ họ đã làm để cho phép cộng tác theo thời gian thực. Điều này sẽ cho phép bạn tiết kiệm thời gian cho sự phát triển của bạn và có được một sản phẩm hoạt động sớm hơn.

Bạn có thể dễ dàng lấy dữ liệu trong tài liệu và đẩy dữ liệu vào cơ sở dữ liệu của mình theo định kỳ hoặc để cơ sở dữ liệu là 'người tham gia' của trao đổi, chỉ cần lắng nghe và ghi lại tất cả các thay đổi. Nó cũng cho phép người dùng xác định cấu trúc dữ liệu của riêng họ mà sau đó có thể sử dụng được trong API thời gian thực, do đó bạn có thể tự do mở rộng nó khi bạn thấy phù hợp.

Không phải Google Drive

Vì vậy, theo nghiên cứu của bạn, Google Drive không phải là một lựa chọn. Điều đó tốt, nhưng nó sẽ khó khăn hơn và có thể không hoạt động tốt, tùy thuộc vào số tiền bạn đưa vào.

Đây là một chiến lược chung tôi sẽ sử dụng để thực hiện vấn đề này:

1. Có máy chủ là bộ ghép kênh truyền thông. Mỗi người nói chuyện với máy chủ và máy chủ sẽ gửi thông tin đó cho mọi người khác. Bằng cách này, máy chủ luôn có chế độ xem tài liệu cập nhật nhất.

2. Tìm một thuật toán / mô-đun của bên thứ ba để giải quyết xung đột. Giải quyết xung đột là khó khăn và là điều vẫn chưa hoàn hảo. Làm điều này một mình có thể dễ dàng tăng phạm vi của dự án là quá lớn. Nếu bạn không thể sử dụng thuật toán của bên thứ ba, tôi khuyên bạn chỉ nên cho phép một người dùng chỉnh sửa một khu vực thời gian để người dùng phải có được khóa trước khi chỉnh sửa một khu vực hoặc bạn có nguy cơ phá hủy một người dùng khác làm việc sẽ rất già, rất nhanh

3. Khi một người dùng mới tham gia, hãy cung cấp cho họ tài liệu gần đây nhất và tự động bắt đầu truyền các lệnh cho họ. Máy chủ có chế độ xem gần đây nhất và do đó có thể tự động xử lý.

4. Sao lưu vào cơ sở dữ liệu trong khoảng thời gian nhất định. Quyết định tần suất bạn muốn sao lưu (cứ sau 5 phút hoặc có thể cứ sau 50 thay đổi.) Điều này cho phép bạn duy trì bản sao lưu mà bạn mong muốn.

Vấn đề: Đây không phải là một giải pháp hoàn hảo, vì vậy đây là một số vấn đề bạn có thể gặp phải.

1. Thông lượng của máy chủ có thể làm tắc nghẽn hiệu suất

2. Quá nhiều người đọc / viết có thể làm quá tải máy chủ

3. Mọi người có thể không đồng bộ nếu tin nhắn bị mất, vì vậy bạn có thể muốn đảm bảo rằng bạn đồng bộ hóa tại các điểm thông thường. Điều này có nghĩa là gửi lại toàn bộ tin nhắn, có thể tốn kém, nhưng nếu không mọi người có thể không có cùng một tài liệu và không biết nó.

Tôi muốn giới thiệu 1 bản sao liên tục của tài liệu trên máy chủ. Khi một máy khách kết nối với máy chủ, bạn đưa ra một UPDATElệnh cho máy khách đó với tất cả các thay đổi.

Cập nhật WorkFlow

Người dùng gây ra thay đổi kích hoạt -> Máy khách gửi UPDATEđến Máy chủ -> Máy chủ gửi UPDATEtới Khách hàng

Kích hoạt khả thi

1. Nhấp chuột vào người dùng
2. Người dùng hoàn thành một nhiệm vụ cụ thể
   • Kết thúc chỉnh sửa một ô
   • Kết thúc chỉnh sửa một câu / đoạn / dòng
3. Người dùng nhấp vào Hoàn tác
4. Người dùng nhấn phím Return
5. Người dùng nhập một khóa (lưu trên mỗi thay đổi)

Cập nhật thực hiện

Tôi sẽ đề nghị có thể tạo lại tài liệu bằng một loạt các UPDATElệnh để máy chủ lưu trữ mỗi CẬP NHẬT và khi một máy khách mới kết nối máy khách có thể được gửi một loạt các bản cập nhật và chính nó có thể tạo lại tài liệu để hiển thị người dùng. Ngoài ra, bạn cũng có thể có một SAVElệnh riêng biệt và CẬP NHẬT là những thay đổi tạm thời có thể được sử dụng cho UNDOcác yêu cầu và SAVE thực sự lưu trữ nó để được mở lại nếu máy chủ bị đóng hoặc tất cả các máy khách bị ngắt kết nối.

1) Hãy xem Knockout.js

Nó tuân theo mẫu MVVM và sẽ tự động đưa ra các thông báo đến Chế độ xem dựa trên các thay đổi đối với Mô hình. Ví dụ, nhìn vào mảng có thể quan sát của họ để cung cấp thêm một chút thông tin về cách họ làm điều đó.

2) Kết hợp điều đó với SignalR và bây giờ bạn sẽ có khả năng gửi thông báo cho những người dùng khác đang làm việc trên tài liệu. Từ trang web của họ:

SignalR cũng cung cấp API cấp cao, rất đơn giản để thực hiện máy chủ cho RPC máy khách (gọi các hàm JavaScript trong trình duyệt của máy khách của bạn từ mã .NET phía máy chủ) trong ứng dụng ASP.NET của bạn, cũng như thêm các móc nối hữu ích để quản lý kết nối , ví dụ: kết nối / ngắt kết nối các sự kiện, nhóm kết nối, ủy quyền.

Vì vậy, bạn sẽ cần phải có một số móc ở cấp mô hình của mình trong Knockout.js để thực hiện một số cuộc gọi SignalR mỗi khi có thay đổi. Các khách hàng khác sẽ nhận được thông báo từ SignalR và sau đó kích hoạt một sự thay đổi tương ứng trong họ bản sao của mô hình, mà sẽ đẩy lùi lên đến Xem họ.

Đó là một sự kết hợp thú vị của hai khung công tác và bạn sẽ có thể tìm kiếm và thu thập thêm thông tin để xử lý các chi tiết.

Ví dụ, đây dụ CodeProject đặc biệt các địa chỉ Co Working UIs and Continuous Clientsđó có vẻ là chính xác những gì bạn đang cố gắng để làm.

Các ứng dụng web thời đại mới có thể cần cung cấp trải nghiệm người dùng thời đại mới - và nên xử lý các tình huống khách hàng hợp tác và liên tục đúng cách. Điều này liên quan đến việc đảm bảo rằng giao diện người dùng tự đồng bộ hóa chính xác trên các thiết bị và trên toàn bộ người dùng để đảm bảo trạng thái của ứng dụng và giao diện người dùng được duy trì "như hiện tại".

Bài đăng trên blog này có vẻ là một điểm vào một loạt các bài đăng trên blog thảo luận về việc sử dụng hai gói và tương phản với cách tiếp cận ASP.NET truyền thống. Có thể cung cấp một số điểm để xem xét trong khi bạn đang thiết kế trang web của mình.

Bài đăng trên blog này có vẻ cơ bản hơn một chút và cung cấp nền tảng cho việc kết hợp hai gói.

Tiết lộ: Tôi không liên kết với bất kỳ liên kết nào ở trên, tôi cũng không thực sự đi sâu vào nội dung của chúng để xem âm thanh hay âm thanh của nó như thế nào.

Giải pháp là Chuyển đổi hoạt động (OT). Nếu bạn chưa từng nghe về nó, OT là một lớp các thuật toán thực hiện đồng thời nhiều trang web. OT giống như git thời gian thực. Nó hoạt động với bất kỳ độ trễ nào (từ 0 đến một kỳ nghỉ dài). Nó cho phép người dùng thực hiện các chỉnh sửa trực tiếp, đồng thời với băng thông thấp. OT cung cấp cho bạn sự thống nhất cuối cùng giữa nhiều người dùng mà không cần thử lại, không có lỗi và không có bất kỳ dữ liệu nào bị ghi đè.

Nhưng thực hiện OT là một nhiệm vụ khó khăn và tốn thời gian. Vì vậy, bạn có thể muốn sử dụng một thư viện bên ngoài như http://sharejs.org/ .

Nó chủ yếu phụ thuộc vào loại tài liệu của bạn và cách người dùng của bạn cộng tác.

Tuy nhiên, tôi sẽ:

1. thỉnh thoảng hãy để tất cả các máy khách gửi các thay đổi chưa được lưu đến máy chủ (tùy thuộc vào cách người dùng làm việc với các tài liệu).
2. máy chủ lưu trữ deltas trong phiên của người dùng (ngay cả đối với một khách hàng béo bạn cần một cái gì đó như phiên)
3. các khách hàng khác chỉnh sửa / xem cùng một tài liệu sẽ nhận được những thay đổi tạm thời hoặc ít nhất là một gợi ý rằng có thể có như vậy.

Ưu điểm:

• không cập nhật DB trừ khi ai đó nhấp vào 'lưu'
• sao lưu cho trường hợp máy khách gặp sự cố (trong khoảng thời gian phiên)
• máy chủ của bạn quyết định cách thức và dữ liệu nào để chuyển tiếp đến máy khách nào (ví dụ: bạn có thể bắt đầu tính năng chỉ bằng một ghi chú và sau đó thực hiện kết hợp và tô sáng tinh vi hơn)

Nhược điểm:

• không phải 'thời gian thực' - ví dụ: bạn gửi cứ sau 30 giây, nhưng ai đó gõ 3 câu trong thời gian đó.
• lưu lượng truy cập mạng nhiều hơn - phụ thuộc vào tài liệu và cộng tác của bạn
• có thể phiên lớn
• có thể nỗ lực tính toán cao nếu nhiều người dùng cộng tác và thực hiện nhiều thay đổi

Về cơ bản, những gì bạn đang hỏi là làm thế nào để đối phó với trạng thái đột biến được chia sẻ. Tiết kiệm là phần dễ dàng; nhưng làm thế nào để bạn đối phó với nhiều người chỉnh sửa cùng một thứ? Bạn muốn tất cả người dùng đang xem cùng một tài liệu trong khi đồng bộ hóa các chỉnh sửa đồng thời, tất cả trong thời gian thực.

Như bạn có thể đã thu thập, đó là một vấn đề khó khăn! Có một vài giải pháp thực dụng:

1. Sửa đổi yêu cầu ứng dụng của bạn để không cho phép chỉnh sửa đồng thời thực sự. Chỉnh sửa có thể được hợp nhất như với các hệ thống kiểm soát nguồn, với kết quả được phát cho mỗi khách hàng. Bạn có thể tự xây dựng cái này nhưng nó sẽ là trải nghiệm người dùng kém hơn.
2. Thuê ngoài việc đồng bộ hóa các đột biến trạng thái thành một giải pháp nguồn mở tích hợp với công nghệ hiện có của bạn. ShareDB là nhà lãnh đạo hiện tại trong không gian này. Nó dựa trên Chuyển đổi hoạt động và được sử dụng trong ít nhất một hệ thống sản xuất. Điều này sẽ giải quyết vấn đề tiết kiệm mà bạn quan tâm nhưng sẽ không giúp đỡ với bất kỳ tính năng UX bổ sung nào bắt buộc đối với bất kỳ ứng dụng hợp tác nào.
3. Sử dụng một nền tảng sẵn có như Convergence (từ chối trách nhiệm: Tôi là người sáng lập) để xử lý tất cả các bit khó khăn cho bạn. Bạn cũng sẽ nhận được các công cụ bổ sung để cộng tác theo thời gian thực như theo dõi con trỏ / chuột, lựa chọn và trò chuyện để nhanh chóng tạo ra trải nghiệm hợp tác vượt trội. Xem câu hỏi này để biết một loạt các công cụ hiện có.