Tôi có một trang web hiển thị một lượng lớn dữ liệu từ máy chủ. Giao tiếp được thực hiện thông qua ajax.

Mỗi khi người dùng tương tác và thay đổi dữ liệu này (Giả sử người dùng A đổi tên thứ gì đó), nó sẽ yêu cầu máy chủ thực hiện hành động và máy chủ trả về dữ liệu mới đã thay đổi.

Nếu người dùng B truy cập trang cùng lúc và tạo một đối tượng dữ liệu mới, nó sẽ lại thông báo cho máy chủ thông qua ajax và máy chủ sẽ quay lại với đối tượng mới cho người dùng.

Trên trang của A, chúng tôi có dữ liệu với một đối tượng được đổi tên. Và trên trang của B, chúng ta có dữ liệu với một đối tượng mới. Trên máy chủ, dữ liệu có cả đối tượng được đổi tên và đối tượng mới.

Tôi có những tùy chọn nào để giữ trang đồng bộ với máy chủ khi nhiều người dùng đang sử dụng đồng thời?

Các tùy chọn như khóa toàn bộ trang hoặc chuyển toàn bộ trạng thái cho người dùng trên mọi thay đổi đều được tránh.

Nếu nó hữu ích, trong ví dụ cụ thể này, trang web gọi một webmethod tĩnh chạy một thủ tục được lưu trữ trên cơ sở dữ liệu. Thủ tục được lưu trữ sẽ trả về bất kỳ dữ liệu nào mà nó đã thay đổi và không còn nữa. Webmethod tĩnh sau đó chuyển tiếp trả về của thủ tục đã lưu trữ cho máy khách.

Chỉnh sửa tiền thưởng:

Làm thế nào để bạn thiết kế một ứng dụng web nhiều người dùng sử dụng Ajax để giao tiếp với máy chủ nhưng tránh được các vấn đề về đồng thời?

Tức là quyền truy cập đồng thời vào chức năng và dữ liệu trên cơ sở dữ liệu mà không có bất kỳ rủi ro nào về dữ liệu hoặc tham nhũng trạng thái

Tổng quat:

• Giới thiệu
• Kiến trúc máy chủ
• Kiến trúc khách hàng
• Cập nhật trường hợp
• Trường hợp cam kết
• Trường hợp xung đột
• Hiệu suất & khả năng mở rộng

Chào Raynos,

Tôi sẽ không thảo luận về bất kỳ sản phẩm cụ thể nào ở đây. Những gì những người khác đã đề cập là một bộ công cụ tốt để xem qua (có thể thêm node.js vào danh sách đó).

Từ quan điểm kiến ​​trúc, bạn dường như có cùng một vấn đề có thể thấy trong phần mềm kiểm soát phiên bản. Một người dùng kiểm tra thay đổi một đối tượng, một người dùng khác muốn thay đổi cùng một đối tượng theo cách khác => xung đột. Bạn phải tích hợp các thay đổi của người dùng vào các đối tượng đồng thời có thể cung cấp các bản cập nhật kịp thời và hiệu quả, phát hiện và giải quyết các xung đột như ở trên.

Nếu tôi ở trong vị trí của bạn, tôi sẽ phát triển một cái gì đó như thế này:

1. Phía máy chủ:

• Xác định mức độ hợp lý mà bạn sẽ xác định cái mà tôi gọi là "tạo tác nguyên tử" (trang? Đối tượng trên trang? Giá trị bên trong đối tượng?). Điều này sẽ phụ thuộc vào máy chủ web, phần cứng cơ sở dữ liệu & bộ nhớ đệm, # người dùng, # đối tượng, v.v. Không phải là một quyết định dễ thực hiện.

• Đối với mỗi hiện vật nguyên tử có:

  • một id duy nhất trên toàn ứng dụng
  • một id phiên bản tăng dần
  • một cơ chế khóa cho quyền ghi (có thể là mutex)
  • một lịch sử nhỏ hoặc "bản ghi thay đổi" bên trong bộ đệm nhạc chuông (bộ nhớ dùng chung hoạt động tốt cho những người đó). Một cặp khóa-giá trị duy nhất cũng có thể ổn mặc dù ít khả năng mở rộng hơn. xem http://en.wikipedia.org/wiki/Circular_buffer

• Một thành phần máy chủ hoặc máy chủ giả có thể cung cấp các thay đổi liên quan đến người dùng được kết nối một cách hiệu quả. Observer-Pattern là người bạn của bạn cho điều này.

2. Phía khách hàng:

• Một ứng dụng khách javascript có thể có một HTTP-Connection chạy lâu dài với máy chủ đã nói ở trên hoặc sử dụng tính năng thăm dò nhẹ.

• Thành phần trình cập nhật tạo phần mềm javascript làm mới nội dung trang web khi ứng dụng khách javascript được kết nối thông báo về những thay đổi trong lịch sử tạo phần mềm đã xem. (một lần nữa mẫu người quan sát có thể là một lựa chọn tốt)

• Một thành phần tạo tác giả javascript có thể yêu cầu thay đổi một tạo tác nguyên tử, cố gắng có được khóa mutex. Nó sẽ phát hiện nếu trạng thái của cấu phần phần mềm đã bị thay đổi bởi người dùng khác chỉ vài giây trước đó (thời gian chờ của ứng dụng khách javascript và các yếu tố quy trình cam kết trong) bằng cách so sánh các phần mềm tạo phiên bản-phiên bản-id của máy khách đã biết và phiên bản-id tạo tác-phiên bản-id của máy chủ hiện tại.

• Một trình giải quyết xung đột javascript cho phép con người đưa ra quyết định thay đổi-là-đúng-nhất. Bạn có thể không muốn chỉ nói với người dùng "Ai đó nhanh hơn bạn. Tôi đã xóa thay đổi của bạn. Hãy khóc đi.". Nhiều tùy chọn từ các khác biệt kỹ thuật khá hoặc các giải pháp thân thiện với người dùng hơn dường như có thể.

Vậy nó sẽ lăn như thế nào ...

Trường hợp 1: loại sơ đồ trình tự để cập nhật:

• Trang kết xuất trình duyệt
• javascript "nhìn thấy" các cấu phần phần mềm có ít nhất một trường giá trị, duy nhất- và một id phiên bản
• ứng dụng khách javascript bắt đầu, yêu cầu "xem" lịch sử tạo tác được tìm thấy bắt đầu từ các phiên bản tìm thấy của chúng (các thay đổi cũ hơn không thú vị)
• Quy trình máy chủ ghi nhận yêu cầu và liên tục kiểm tra và / hoặc gửi lịch sử
• Các mục lịch sử có thể chứa các thông báo đơn giản "tạo tác x đã thay đổi, khách hàng vui lòng yêu cầu dữ liệu" cho phép khách hàng thăm dò ý kiến ​​độc lập hoặc tập dữ liệu đầy đủ "tạo tác x đã thay đổi thành giá trị foo"
• javascript Artifact-updater thực hiện những gì nó có thể để tìm nạp các giá trị mới ngay khi chúng được biết là đã cập nhật. Nó thực thi các yêu cầu ajax mới hoặc được cung cấp bởi ứng dụng khách javascript.
• Các trang nội dung DOM được cập nhật, người dùng được thông báo tùy ý. Lịch sử tiếp tục theo dõi.

Trường hợp 2: Bây giờ để cam kết:

• Arti-committer biết giá trị mới mong muốn từ đầu vào của người dùng và gửi một yêu cầu thay đổi đến máy chủ
• serveride mutex được mua lại
• Máy chủ nhận được thông báo "Này, tôi biết trạng thái của tạo tác x từ phiên bản 123, hãy để tôi đặt nó thành giá trị xin vui lòng."
• Nếu phiên bản Máy chủ của cấu phần phần mềm x bằng (không thể nhỏ hơn) 123, giá trị mới được chấp nhận, một id phiên bản mới là 124 sẽ được tạo.
• Thông tin trạng thái mới "được cập nhật lên phiên bản 124" và tùy chọn foo giá trị mới được đặt ở đầu bộ đệm chuông của tạo tác x (changelog / history)
• serveride mutex được phát hành
• yêu cầu người cam kết giả rất vui khi nhận được xác nhận cam kết cùng với id mới.
• trong khi đó thành phần máy chủ bên máy chủ tiếp tục thăm dò / đẩy bộ đệm chuông đến các máy khách được kết nối. Tất cả các máy khách đang xem bộ đệm của tạo tác x sẽ nhận được thông tin và giá trị trạng thái mới trong độ trễ thông thường của chúng (Xem trường hợp 1.)

Trường hợp 3: đối với xung đột:

• người cam kết tạo tác biết giá trị mới mong muốn từ đầu vào của người dùng và gửi một yêu cầu thay đổi đến máy chủ
• trong khi đó, một người dùng khác đã cập nhật thành công cùng một cấu phần phần mềm (xem trường hợp 2.) nhưng do các độ trễ khác nhau, người dùng khác của chúng tôi vẫn chưa biết điều này.
• Vì vậy, một mutex bên máy chủ được mua (hoặc đợi cho đến khi người dùng "nhanh hơn" thực hiện thay đổi của mình)
• Máy chủ nhận được thông báo "Này, tôi biết trạng thái của tạo tác x từ phiên bản 123, hãy để tôi đặt nó thành giá trị foo."
• Trên Máy chủ, phiên bản của tạo tác x hiện đã là 124 rồi. Khách hàng yêu cầu không thể biết giá trị mà anh ta sẽ ghi đè.
• Rõ ràng là Máy chủ phải từ chối yêu cầu thay đổi (không tính vào các ưu tiên ghi đè can thiệp thần thánh), giải phóng mutex và đủ tử tế để gửi lại id phiên bản mới và giá trị mới trực tiếp cho máy khách.
• đối mặt với một yêu cầu cam kết bị từ chối và một giá trị mà người dùng yêu cầu thay đổi chưa biết, trình cam kết tạo tác javascript đề cập đến trình giải quyết xung đột sẽ hiển thị và giải thích vấn đề cho người dùng.
• Người dùng, được trình bày với một số tùy chọn bởi trình giải quyết xung đột thông minh JS, được cho phép một nỗ lực khác để thay đổi giá trị.
• Khi người dùng đã chọn một giá trị mà anh ta cho là đúng, quá trình bắt đầu lại từ trường hợp 2 (hoặc trường hợp 3 nếu người khác nhanh hơn)

Một số từ về Hiệu suất & Khả năng mở rộng

HTTP Polling so với HTTP "push"

• Thăm dò ý kiến ​​tạo ra các yêu cầu, một yêu cầu trên giây, 5 yêu cầu trên giây, bất cứ điều gì bạn coi là độ trễ chấp nhận được. Điều này có thể khá tàn nhẫn đối với cơ sở hạ tầng của bạn nếu bạn không định cấu hình (Apache?) Và (php?) Của mình đủ tốt để trở thành những bộ khởi động "nhẹ". Bạn nên tối ưu hóa yêu cầu bỏ phiếu trên máy chủ để nó chạy trong thời gian ngắn hơn nhiều so với độ dài của khoảng thời gian bỏ phiếu. Chia nhỏ thời gian chạy đó có thể có nghĩa là giảm tải toàn bộ hệ thống của bạn lên đến 50%,
• Đẩy mạnh thông qua HTTP (webworkers giả sử là quá xa để hỗ trợ chúng) sẽ yêu cầu bạn phải có một apache / lighthttpd xử lý có sẵn cho mỗi người dùng mọi lúc . Bộ nhớ thường trú dành riêng cho mỗi quá trình này và tổng bộ nhớ hệ thống của bạn sẽ là một giới hạn mở rộng rất nhất định mà bạn sẽ gặp phải. Giảm dung lượng bộ nhớ của kết nối sẽ là cần thiết, cũng như hạn chế số lượng CPU và I / O liên tục thực hiện trong mỗi công việc này (bạn muốn có nhiều thời gian ngủ / nhàn rỗi)

mở rộng quy mô phụ trợ

• Quên cơ sở dữ liệu và hệ thống tệp, bạn sẽ cần một số loại phụ trợ dựa trên bộ nhớ chia sẻ cho việc thăm dò thường xuyên (nếu máy khách không thăm dò trực tiếp thì mỗi quy trình máy chủ đang chạy sẽ thực hiện)
• nếu bạn sử dụng memcache, bạn có thể mở rộng quy mô tốt hơn, nhưng nó vẫn đắt
• Mutex cho các cam kết phải hoạt động toàn cầu ngay cả khi bạn muốn có nhiều máy chủ giao diện người dùng để cân bằng tải.

mở rộng giao diện người dùng

• bất kể bạn đang thăm dò ý kiến ​​hay nhận được "lượt đẩy", hãy cố gắng lấy thông tin cho tất cả các phần mềm đã xem trong một bước.

chỉnh sửa "sáng tạo"

• Nếu khách hàng đang thăm dò ý kiến ​​và nhiều người dùng có xu hướng xem cùng một phần mềm, bạn có thể cố gắng xuất bản lịch sử của các phần mềm đó dưới dạng tệp tĩnh, cho phép apache lưu vào bộ nhớ cache, tuy nhiên, làm mới nó trên máy chủ khi các phần mềm thay đổi. Điều này đưa PHP / memcache ra khỏi trò chơi một số cho các yêu cầu. Lighthttpd rất hiệu quả trong việc cung cấp các tệp tĩnh.
• sử dụng mạng phân phối nội dung như cotendo.com để đẩy lịch sử tạo tác lên đó. Độ trễ đẩy sẽ lớn hơn nhưng khả năng mở rộng là một giấc mơ
• viết một máy chủ thực (không sử dụng HTTP) mà người dùng kết nối bằng java hoặc flash (?). Bạn phải giải quyết việc phục vụ nhiều người dùng trong một chuỗi máy chủ. Đạp xe qua các ổ cắm đang mở, làm (hoặc ủy quyền) công việc được yêu cầu. Có thể mở rộng quy mô thông qua các quy trình phân nhánh hoặc khởi động nhiều máy chủ hơn. Mutexes phải duy trì tính duy nhất trên toàn cầu.
• Tùy thuộc vào các tình huống tải, nhóm các máy chủ giao diện người dùng và phụ trợ của bạn theo phạm vi id tạo tác. Điều này sẽ cho phép sử dụng bộ nhớ liên tục tốt hơn (không có cơ sở dữ liệu nào có tất cả dữ liệu) và có thể mở rộng quy mô mutexing. Tuy nhiên, javascript của bạn phải duy trì kết nối đến nhiều máy chủ cùng một lúc.

Tôi hy vọng đây có thể là một khởi đầu cho những ý tưởng của riêng bạn. Tôi chắc chắn rằng có nhiều khả năng hơn. Tôi không chỉ hoan nghênh bất kỳ lời chỉ trích hoặc cải tiến nào đối với bài đăng này, wiki được kích hoạt.

Christoph Strasen

Tôi biết đây là một câu hỏi cũ, nhưng tôi nghĩ rằng tôi sẽ trả lời.

OT (chuyển đổi hoạt động) có vẻ phù hợp với yêu cầu của bạn về chỉnh sửa nhiều người dùng đồng thời và nhất quán. Đó là một kỹ thuật được sử dụng trong Google Documents (và cũng được sử dụng trong Google Wave):

Có một thư viện dựa trên JS để sử dụng Chuyển đổi hoạt động - ShareJS ( http://sharejs.org/ ), được viết bởi một thành viên từ nhóm Google Wave.

Và nếu bạn muốn, có một khuôn khổ web MVC đầy đủ - DerbyJS ( http://derbyjs.com/ ) được xây dựng trên ShareJS sẽ làm tất cả cho bạn.

Nó sử dụng BrowserChannel để giao tiếp giữa máy chủ và máy khách (và tôi tin rằng hỗ trợ WebSockets nên hoạt động - trước đây nó đã có trong đó thông qua Socket.IO, nhưng đã bị loại bỏ do các vấn đề của nhà phát triển với Socket.io) Tuy nhiên, hơi thưa thớt vào lúc này.

Tôi sẽ xem xét thêm dấu sửa đổi dựa trên thời gian cho mỗi tập dữ liệu. Vì vậy, nếu bạn đang cập nhật bảng db, bạn sẽ thay đổi dấu thời gian đã sửa đổi cho phù hợp. Sử dụng AJAX, bạn có thể so sánh dấu thời gian đã sửa đổi của ứng dụng khách với dấu thời gian của nguồn dữ liệu - nếu người dùng ở phía sau, hãy cập nhật màn hình. Tương tự như cách trang web này kiểm tra định kỳ một câu hỏi để xem liệu có ai khác đã trả lời hay không khi bạn đang nhập câu trả lời.

Bạn cần sử dụng kỹ thuật đẩy (còn được gọi là Sao chổi hoặc Ajax đảo ngược) để truyền bá các thay đổi cho người dùng ngay khi chúng được thực hiện với db. Kỹ thuật tốt nhất hiện có cho điều này dường như là Ajax long polling, nhưng nó không được hỗ trợ bởi mọi trình duyệt, vì vậy bạn cần dự phòng. May mắn thay, đã có các giải pháp xử lý điều này cho bạn. Trong số đó có: orbited.org và socket.io đã được đề cập.

Trong tương lai, sẽ có một cách dễ dàng hơn để làm điều này được gọi là WebSockets, nhưng vẫn chưa chắc chắn khi nào tiêu chuẩn đó sẽ sẵn sàng ra mắt vì có những lo ngại về bảo mật về trạng thái hiện tại của tiêu chuẩn.

Sẽ không có vấn đề đồng thời trong cơ sở dữ liệu với các đối tượng mới. Nhưng khi người dùng chỉnh sửa một đối tượng, máy chủ cần có một số logic để kiểm tra xem đối tượng đã được chỉnh sửa hay xóa trong thời gian chờ đợi hay chưa. Nếu đối tượng đã bị xóa, một lần nữa, giải pháp rất đơn giản: Chỉ cần hủy chỉnh sửa.

Nhưng vấn đề khó khăn nhất xuất hiện, khi nhiều người dùng đang chỉnh sửa cùng một đối tượng cùng một lúc. Nếu Người dùng 1 và 2 bắt đầu chỉnh sửa đối tượng cùng lúc, cả hai sẽ thực hiện chỉnh sửa trên cùng một dữ liệu. Giả sử những thay đổi Người dùng 1 đã thực hiện được gửi đến máy chủ đầu tiên trong khi Người dùng 2 vẫn đang chỉnh sửa dữ liệu. Sau đó, bạn có hai tùy chọn: Bạn có thể cố gắng hợp nhất các thay đổi của Người dùng 1 vào dữ liệu của Người dùng 2 hoặc bạn có thể nói với Người dùng 2 rằng dữ liệu của anh ta đã lỗi thời và hiển thị cho anh ta thông báo lỗi ngay khi dữ liệu của anh ta được gửi đến máy chủ. Tùy chọn thứ hai không thân thiện với người dùng ở đây, nhưng tùy chọn trước rất khó triển khai.

Một trong số ít triển khai thực sự làm được điều này lần đầu tiên là EtherPad , được Google mua lại. Tôi tin rằng sau đó họ đã sử dụng một số công nghệ của EtherPad trong Google Docs và Google Wave, nhưng tôi không thể nói chắc điều đó. Google cũng mở EtherPad có nguồn gốc, vì vậy có lẽ điều đó đáng để xem xét, tùy thuộc vào những gì bạn đang cố gắng làm.

Thực sự không dễ dàng để thực hiện điều này đồng thời chỉnh sửa nội dung, bởi vì không thể thực hiện các hoạt động nguyên tử trên web do độ trễ. Có thể bài viết này sẽ giúp bạn tìm hiểu thêm về chủ đề.

Cố gắng tự viết tất cả những điều này là một công việc lớn và rất khó để làm cho nó đúng. Một tùy chọn là sử dụng một khuôn khổ được xây dựng để giữ các máy khách đồng bộ với cơ sở dữ liệu và với nhau, trong thời gian thực.

Tôi thấy rằng khung công tác Meteor thực hiện tốt điều này ( http://docs.meteor.com/#reactivity ).

"Meteor bao hàm khái niệm lập trình phản ứng. Điều này có nghĩa là bạn có thể viết mã của mình theo phong cách mệnh lệnh đơn giản và kết quả sẽ tự động được tính toán lại bất cứ khi nào dữ liệu thay đổi mà mã của bạn phụ thuộc vào."

"Mẫu đơn giản này (tính toán phản ứng + nguồn dữ liệu phản ứng) có khả năng ứng dụng rộng rãi. Lập trình viên được lưu khỏi việc viết lệnh hủy đăng ký / đăng ký lại và đảm bảo chúng được gọi vào đúng thời điểm, loại bỏ toàn bộ các lớp mã truyền dữ liệu mà nếu không sẽ làm tắc nghẽn ứng dụng có logic dễ xảy ra lỗi. "

Tôi không thể tin rằng không ai đã đề cập đến Meteor . Đó chắc chắn là một khung công tác mới và chưa trưởng thành (và chỉ hỗ trợ chính thức một DB), nhưng nó đòi hỏi tất cả công việc và suy nghĩ khó khăn của một ứng dụng nhiều người dùng như người đăng đang mô tả. Trên thực tế, bạn KHÔNG thể KHÔNG xây dựng ứng dụng cập nhật trực tiếp mult-user. Đây là một bản tóm tắt nhanh:

• Mọi thứ đều có trong node.js (JavaScript hoặc CoffeeScript), vì vậy bạn có thể chia sẻ những thứ như xác thực giữa máy khách và máy chủ.
• Nó sử dụng websockets, nhưng có thể quay trở lại đối với các trình duyệt cũ hơn
• Nó tập trung vào các bản cập nhật ngay lập tức cho đối tượng cục bộ (tức là giao diện người dùng cảm thấy linh hoạt), với các thay đổi được gửi đến máy chủ trong nền. Chỉ các bản cập nhật nguyên tử mới được phép làm cho các bản cập nhật trộn đơn giản hơn. Cập nhật bị từ chối trên máy chủ được khôi phục.
• Như một phần thưởng, nó xử lý việc tải lại mã trực tiếp cho bạn và sẽ duy trì trạng thái người dùng ngay cả khi ứng dụng thay đổi hoàn toàn.

Meteor đủ đơn giản để tôi đề nghị bạn ít nhất hãy nhìn vào nó để có ý tưởng ăn cắp.

Những trang Wikipedia có thể giúp bổ sung quan điểm để tìm hiểu về đồng thời và máy tính đồng thời cho việc thiết kế một ajax ứng dụng web mà một trong hai Kéo hoặc đẩy trạng thái sự kiện ( EDA ) thông điệp trong một mẫu tin nhắn . Về cơ bản, các tin nhắn được sao chép tới những người đăng ký kênh phản hồi các sự kiện thay đổi và yêu cầu đồng bộ hóa.

• https://en.wikipedia.org/wiki/Category:Concurrency_control
• https://en.wikipedia.org/wiki/Distributed_concurrency_control
• https://en.wikipedia.org/wiki/CAP_theorem
• https://en.wikipedia.org/wiki/Operational_transformation
• https://en.wikipedia.org/wiki/Fallacy_of_Distributed_Computing

Có nhiều dạng phần mềm cộng tác dựa trên web đồng thời .

Có một số thư viện máy khách HTTP API cho etherpad-lite , một trình soạn thảo thời gian thực cộng tác .

django-realtime-sân chơi triển khai ứng dụng trò chuyện thời gian thực trong Django với nhiều công nghệ thời gian thực khác nhau như Socket.io .

Cả AppEngine và AppScale đều triển khai API kênh AppEngine ; khác với API thời gian thực của Google , được chứng minh bởi googledrive / realtime-sân chơi .

Kỹ thuật đẩy phía máy chủ là cách để thực hiện ở đây. Sao chổi là (hay là?) Một từ buzz.

Hướng cụ thể mà bạn thực hiện phụ thuộc nhiều vào ngăn xếp máy chủ của bạn và mức độ linh hoạt của bạn / nó. Nếu bạn có thể, tôi sẽ xem qua socket.io , cung cấp triển khai websockets trên nhiều trình duyệt, cung cấp một cách rất hợp lý để giao tiếp hai chiều với máy chủ, cho phép máy chủ đẩy các bản cập nhật cho máy khách.

Đặc biệt, hãy xem phần minh họa này của tác giả thư viện, nó thể hiện gần như chính xác tình huống mà bạn mô tả.