基于web粒度可配编辑锁设计.docVIP

基于web粒度可配编辑锁设计 　　摘要：提出了多人同时编辑同一web页面会引起版本冲突，抽象出问题的模型，针对问题设计了一种普通编辑锁，借助Ajax技术，有效地解决了多人同时编辑同一web页面版本冲突问题，同时也避免的传统编辑锁长时间锁定被编辑页面的弊端。进一步提出粒度可配的编辑锁，除能有效解决普通编辑锁能解决的问题外，还可以通过配置细粒度来锁定更少的资源，使没必要被锁的资源处于可被编辑状态，提高系统被编辑的效率和缩短了其他用户的等待时间。 　　关键词：web；多人协作；版本冲突；编辑锁；粒度可配；细粒度 　　中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2017）26-0059-02 　　随着大规模协作时代的到来，发动社区内成员共同编辑协作，集众人之力，发挥每个人的特长，高质量地完成某项任务是一件非常有意义的事情。基于“多人协作”的主要工具为wiki[1]，比较有代表性的有维基百科[2]、TraceWiki、HdWiki等[3]，这些工具允许多人编辑同一词条，每编辑一次生成一个版本。近几年来，基于web多人协作平台的迅速发展，相关研究非常多，主要研究焦点集中在一些宏观方面：比如在某方面的应用[4]，组织模型[5]等。大多忽视了微观小问题的研究，比如：多人同时编辑同一页面时，发生冲突了怎么办？本文通过抽象出多人同时编辑同一web页面存在冲突问题的模型，设计出数据库表，借助ajax技术，解决这个问题。 　　1 普通编辑锁的设计 　　1.1 问题抽象 　　存在多人同时协作时的场景：某wiki网站，用户A在编辑词条A，用户B也在编辑词条A，此时，后提交的将覆盖前面提交的?热荩?造成冲突。如果词条很长，网站对词条进行了处理，将其分段，用户A编辑词条A的第一段，用户B同时编辑词条A的第二段，此时则不会造成冲突。 　　根据上述场景，将问题进行抽象，对于协作者来讲，不管是机构、客户端、网站用户等统统定义为用户user，对于被编辑的对象不管是文章还是页面上的某个模块，只要是可以被单独编辑的对象，统统定义为资源resource，问题就抽象为user通过对resource加锁独享的问题。 　　1.2 数据库设计 　　数据库被简化成三张表：user{userId，userName}；resource{resourceId， resourceName ，content}；lock{lockId，userId，resourceId（unique），startTime，state，heartBeatTime}，User表和resource表在一般系统中已经存在，只需添加lock表即可。其简单的ER图如图1所示。 　　每一个可被编辑的资源在lock表中最多对应一条记录，这个可以利用数据库的唯一索引，将lock表中的resourceId设置为唯一索引来实现。 　　1.3 编辑锁工作流程设计 　　在配置文件中设置两个可配置项：一是超时时间timeout一是心跳频率heartbeat，通过timeout来解决资源被恶意或无意长期锁定的问题，通过heartbeat来确定ajax（web页面和服务器之间的异步通信[6]，可以在页面无刷新的情况下完成数据在客户端和服务器之间的交互）向服务器推送最新编辑时间的频率。用户请求对某一资源编辑及编辑中和编辑结束，编辑锁的工作流程如图2所示。 　　其中“insert记录”是指往lock表中新添加一条记录，userId为申请编辑的用户id，resourceId为被编辑的资源的id，startTime和heartBeatTime均为系统当前时间，state为1，表示此锁可用。 　　“update记录”是指更新lock表中的此资源对应锁记录，主要是userId为此次申请锁定的用户id，startTime和heartBeatTime更新为系统当前时间，state更新为1，表示此锁可用。 　　判断lock表中该资源“记录有效”的依据为：1）state状态为0视为无效；2）state状态为1，比较当前时间与heartBeatTime之间的差值，如果该值大于heartbeat，视为无效；3）state状态为1，比较当前时间与heartBeatTime之间的差值，如果该值小于heartbeat，但startTime与当前时间之间的差值大于timeout，视为无效；4）state状态为1，比较当前时间与heartBeatTime之间的差值，如果该值小于heartbeat，但startTime与当前时间之间的差值小于timeout，视为有效。 　　2 粒度可配编辑锁的设计 　　如果resource的粒度被划分越大，资源越安全，但资源被锁定的概率越大，编辑效率越低，如何锁定小粒度的资源，让