问题描述
由多个用户读/写操作。用户可以能够使只读即只对会话的创建者写的编辑器。你应该能够分享当前会话的链接，以增加更多的用户同时工作。它应该是并行（同步）和避免编辑冲突。建议的方法来做到这一点。请专注于正确的和可扩展的功能。应该有自动保存编辑应保持在每次保存更改/编辑。支持回滚到任何变化。必须有共享/喜欢的社交媒体功能。
Read/Write operations by multiple users.A user may be able to make the editor read only i.e only the creator of the session writes.You should be able to share the link of the current session to add more users to work on simultaneously.It should be concurrent(synchronization) and avoid editing conflicts. Suggest approach to do this.Please focus on a correct and scalable functionality.Should have auto saveEditor should maintain changes/edits on each save.Support rollback to any change.Must have share/like functionality for social media.
我能来与以下，需要帮助识别类来构建这样的类图：
I was able to come with the following, need help identifying classes to build a class diagram for this:
这将是一个客户端服务器的实现。
It will be a client server implementation.
有关网站，客户端可以用HTML5和Javascript。我们可以使用额外的JavaScript框架的具体要求（如angularjs）。
For website, client can be written in HTML5 and Javascript. We can use additional javascript frameworks for specific requirements(eg. angularjs).
有关发送请求的两种方法可供选择：1.请求/响应 - 发送的请求每一秒2.长池 - 做一个永不落幕的HTTP请求到服务器并通过它进行通信。这种方法将更快的方式是较早的一个，因为多个HTTP请求将无法进行。
For sending request two methods are available:1. Request/Response-- Sending request every second2. Long pooling -- Make a never ending http request to server and communicate through it. This method will be way faster that earlier one because multiple http request will not be made.
客户端它的工作将更改发送到服务器上固定的时间间隔（1秒）。客户端的工作，了解其他用户所做的更改，并显示相同的当前用户。
Its the work of client to send the changes to server on fixed interval (1 second). Its the work of client to understand the changes done by other users and display the same to current user.
服务器将暴露出其中将用于一个API - 获取当前文档 - 其响应将包含修改通过在同一文件的其他用户进行SendUpdate请求。我们会尝试捕捉三角洲和重新present在客户端的变化。
Server will be expose an API which will be used to-- Get current document-- SendUpdate request whose response will contain modification done by other users on same document. We will try and capture the delta and represent the changes on the client side.
服务器堆栈必须非常快（.node.js或golang将适用于这样的要求），因为它的响应时间非常短。数据应储存在存储器中，我们可以使用Redis的存储数据。我们可以在区间或在内存数据库也文件系统或不显式保存要求，保存数据。
Server Stack has to be very fast(.node.js or golang will be suitable for such requirement) because of its very short response time.Data should be stored in memory, we can use Redis to store data. We can on intervals or on explicit save requests, save data on the file system or non in memory databases also.
每个请求都将包含设置由客户端所做的更改。这些变化将被保存在Redis的一起时间戳。我们不会在数据库中存储整个文件中，我们将只存储了历史性的变化。由于Redis的是基于存储器，它需要非常少的资源来计算，从一组保存的更改最后文件。
Every request will contain set of changes made by client.These changes will be saved in Redis along with timestamp. We wont be store whole file in database, we will just store historic changes. As redis is based on memory, it will take very little resource to compute final document from set of stored changes.
有关每个文档都会有与之相关联的唯一ID。唯一的ID应该是足够长的时间。您可以创建一个URL的记事本一样example.com/notepad/{unique-id}这将加载客户端，然后装入与该唯一的ID文件。
For every document there will be unique id associated with it. Unique id should be long enough.You can create a url for notepads like example.com/notepad/{unique-id}This will load the client and then load the document related to that unique id.
对于每一个请求，这个唯一的ID将被发送到确定哪些文件正在编辑的用户。保存作为每一个变化被发送到数据库中，将被自动保存。
For every request this unique id will be send to identify which document is being edited by user.SaveAs every change is being sent to database, it will be auto saved.
还原你可以保持在AngularJs历史数据。如果你想在会话之间持久性，sotre数据保存到文件系统中。您还可以从服务器中使用API获取历史信息。它可以被撤销。
RevertYou can keep historic data in AngularJs. If you want persistance between sessions, sotre data to file system.You can also retrieve historic information from server using API. Which can be undone.
Facebook共享我们也可以使用FB图形API发布在用户的链接; S时间表或Facebook公开了一个sharer.php URL，它可以被用来分享帖子/分享用户的时间线的链接
Facebook ShareWe can also use FB graph api to post link in user;s timeline or Facebook exposes a sharer.php url, which can be used to share Post / Share a link in user's timeline.
可扩展性我们可以使用基于云的可扩展的解决方案，如Mmazon AWS EC2实例来实现这个解决方案。我们可以让Web服务器负载平衡器之后。我们必须保持Redis的作为单独的（大）的EC2实例。有可能是背后负载balanacer多个网络服务器。他们都将与Redis的实例进行通信。我们可以保持像CSS和JS的CDN静态数据（S3背后AWS CloudFront的）
ScalabilityWe can use cloud based scalable solutions like Mmazon AWS EC2 instances to implement this solution. We can keep webserver behind a load balancer.We have to keep redis as separate (large) ec2 instance. There can be multiple webserver behind load balanacer. All of them will be communicating with Redis instance.We can keep static data like css and js in CDN (AWS CloudFront behind S3)
推荐答案
这将是一个客户端服务器实现。
其中，服务器将暴露出将用于到
一个API - 获取当前文档
- 其响应对同一文件将包含修改完成由其他用户SendUpdate要求
It will be a client server implementation.
Where server will be expose an API which will be used to
-- Get current document
-- SendUpdate request whose response will contain modification done by other users on same document
客户端它的工作将更改发送到服务器上的固定间隔（比如1秒）。客户端的工作，了解其他用户所做的更改，并显示相同的当前用户。
Its the work of client to send the changes to server on fixed interval (say 1 second). Its the work of client to understand the changes done by other users and display the same to current user.
有关网站，客户端可以用HTML5和Javascript。您可以使用AngularJs如JavaScript框架相同。
对于发送请求两种方法可供选择：
1.同步
- 发送的请求每一秒
2.长池
- 做一个永不落幕的HTTP请求到服务器并通过它进行通信。这种方法将更快的方式是较早的一个，因为多个HTTP请求将无法进行。
For website, client can be written in HTML5 and Javascript. You can use AngularJs as javascript framework for the same.
For sending request two methods are available:
1. Synchronization
-- Sending request every second
2. Long pooling
-- Make a never ending http request to server and communicate through it. This method will be way faster that earlier one because multiple http request will not be made.
服务器堆栈必须非常快。 Node.js的或golang会因为其极短的响应时间适合这样的要求。
数据应该存储在内存中，你可以使用Redis的存储数据。
Server Stack has to be very fast. node.js or golang will be suitable for such requirement, because of its very short response time.
Data should be stored in memory, you can use Redis to store data.
每个请求都将包含设置由客户端所做的更改。
这些变化将被保存在Redis的一起时间戳。
你不会保存整个文件在数据库中，你应该只存储了历史性的变化。由于Redis的是基于存储器，它需要非常少的资源来计算，从一组保存的更改最后文件。
Every request will contain set of changes made by client.
These changes will be saved in Redis along with timestamp.
You wont store whole file in database, you should just store historic changes. As redis is based on memory, it will take very little resource to compute final document from set of stored changes.
这篇关于如何woud你设计一个Collabritive /共享的文本编辑器：关键点如下的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！