CN103164525B - Web应用发布方法和装置 - Google Patents

Abstract

本发明提供一种WEB应用发布方法和装置，涉及互联网技术。其中，WEB应用发布方法包括：后台接收更新数据；后台将更新数据存储于数据库，并发布关于更新数据的更新消息，以使接收到更新消息的前台能够通过数据库获取更新数据。通过本发明的实施方式，能够实现通过后台对前台页面进行全面的管理和维护。

Description

WEB应用发布方法和装置

技术领域

本发明涉及互联网技术，特别涉及一种WEB应用发布技术。

背景技术

大多数Web应用都会分为面向用户的前端信息展示部分（以下简称为前台）和后台管理部分（以下简称为后台）。管理员通过后台对数据进行维护，通过前台展示给网站用户。为了便于管理，一般情况下，后台和前台是分别部署在不同的服务器上的。其中，后台主要是提供给管理人员使用，结构相对稳定，变动较少。前台由于直接展示在用户面前，需要呈现更好的用户体验以吸引和留住更多的用户，并且前台应用也需要频繁的发布更新。同时，为了能够承受高负载和高并发带来的压力，会将大多数Web应用同时部署在多台服务器上。因此，会造成上线操作更加耗时的情况。如何有效地减少部署程序带来的操作，同时保证前台能够快速无误地更新，就显得十分重要了。

目前，在发布程序的方式上，以下述示例作为现有技术所采用的技术方案的举例来进行说明。对于多台应用服务器，为了避免在每台服务器上重复做上线操作，一般的做法是选定其中一台作为主服务器，将Web应用部署在这台服务器上，并通过如rsync的方式将应用同步到其它的从服务器上。为了保证从服务器能够与主服务器上的内容保持一致，需要在应用服务器上建立定时任务来执行这样的同步操作。

以上方式可以避免每次前端内容更新都需要在各个服务器上做相同的操作。但是，其缺点也是很明显的，例如主服务器和从服务器上的内容并不能实现完全实时同步等。另外，由于前台内容的发布需要人员手动操作，因此流程繁琐、效率十分低下。

发明内容

本发明实施例提供一种WEB应用发布方法和装置，以实现通过后台对前台内容进行全面的管理和维护。

一方面，本发明提供一种WEB应用发布方法，包括：后台接收更新数据；后台将更新数据存储于数据库，并发布关于更新数据的更新消息，以使接收到更新消息的前台能够通过数据库获取更新数据。

在一个实施例中，在后台发布关于更新数据的更新消息之前，该方法包括：后台查找更新数据与原有数据的区别；后台确定区别中能够被前台识别的识别特征；后台生成包括识别特征的更新消息。

在一个实施例中，后台通过消息队列发布更新消息，以使订阅更新消息的前台能够接收到更新消息。

在一个实施例中，后台通过非关系型数据库发布更新消息，以使订阅更新消息的前台能够接收到更新消息并从非关系型数据库获取更新数据，其中，非关系型数据库中的更新数据是通过与数据库同步而获取的。

在一个实施例中，后台在向前台发布更新消息之前向非关系型数据库发送同步指令，指示非关系型数据库从数据库同步更新数据，同步指令包括更新数据与原有数据之间的区别中能够被前台识别的识别特征，以使非关系型数据库从数据库同步与识别特征相对应的更新数据。

在一个实施例中，在后台更新数据之前该方法包括：针对前台的第一模型和第二模型分别建立第一数据表和第二数据表，其中，第一模型为整个前台，第二模型为组成第一模型的元素，第一数据表包括第一模型的相关描述信息，第二数据表包括第二模型的相关描述信息以及第二模型与第一模型之间的关系的相关信息；将第一数据表和第二数据表存储于数据库。

在一个实施例中，第一模型为站点，站点为整个前台，第二模型至少包括频道、页面和组件中的一种，其中，频道为组成频道的多个元素，页面为组成频道的多个元素，组件为组成页面的多个元素。

另一方面，本发明还提供一种用于WEB应用发布的装置，包括：更新模块，用于接收更新数据；数据存储模块，用于将更新数据存储于数据库；消息发布模块，用于发布关于更新数据的更新消息，以使接收到更新消息的前台能够通过数据库获取更新数据。

在一个实施例中，该装置还包括：查找模块，用于在消息发布模块发布关于更新数据的更新消息之前查找更新数据与原有数据的区别；确定模块，用于确定区别中能够被前台识别的识别特征；消息生成模块，用于生成包括识别特征的更新消息。

在一个实施例中，消息发布模块通过消息队列发布更新消息，以使订阅更新消息的前台能够接收到更新消息。

在一个实施例中，消息发布模块通过非关系型数据库发布更新消息，以使订阅更新消息的前台能够接收到更新消息并从非关系型数据库获取更新数据，其中，非关系型数据库中的更新数据是通过与数据库同步而获取的。

在一个实施例中，该装置还包括：同步模块，用于在向前台发布更新消息之前向非关系型数据库发送同步指令，指示非关系型数据库从数据库同步更新数据，同步指令包括更新数据与原有数据之间的区别中能够被前台识别的识别特征，以使非关系型数据库从数据库同步与识别特征相对应的更新数据。

在一个实施例中，该装置还包括：数据表建立模块，用于在接收更新数据之前针对前台的第一模型和第二模型分别建立第一数据表和第二数据表，其中，第一模型为整个前台，第二模型为组成第一模型的元素，第一数据表包括第一模型的相关描述信息，第二数据表包括第二模型的相关描述信息以及第二模型与第一模型之间的关系的相关信息；存储模块，用于将第一数据表和第二数据表存储于数据库。

在一个实施例中，第一模型为站点，站点为整个前台，第二模型至少包括频道、页面和组件中的一种，其中，频道为组成频道的多个元素，页面为组成频道的多个元素，组件为组成页面的多个元素。

基于以上技术方案，通过在后台和前台之间增加更新数据的消息机制，后台可以将要修改的数据存储于数据库。通过发布/订阅的模式，前台可以在接收到关于更新数据的消息之后从数据库获取更新数据。因此，根据本发明的实施例可以通过后台对前台内容进行全面的管理和维护，各前台服务器可以独立地与数据库进行交互，不会存在数据不一致的情况。各前台服务器之间也没有依赖关系。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，并不构成对本发明的限定。在附图中：

图1是根据本发明实施例的WEB应用发布方法的流程图；

图2是根据本发明实施例的应用场景的示意图；

图3是根据本发明另一实施例的应用场景的示意图；

图4是根据本发明另一实施例的WEB应用发布方法的流程图；

图5是根据本发明实施例的用于WEB应用发布的装置的结构示意图；

图6是根据本发明另一实施例的用于WEB应用发布的装置的结构示意图；

图7是根据本发明又一实施例的用于WEB应用发布的装置的结构示意图；

图8是根据本发明又一实施例的用于WEB应用发布的装置的结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下面结合附图对本发明实施例作进一步详细说明。在此，本发明的示意性实施例及其说明用于解释本发明，但并不作为对本发明的限定。

现在将参考附图进一步详细描述本发明。本发明可以许多不同的形式来实现，不应该被理解为仅限于此处所阐述的实施例。这些实施例只作为示例提供，以便为本领域技术人员提供对本发明的完全理解。

图1是根据本发明实施例的WEB应用发布方法100的流程图。

在步骤102中，后台接收更新数据。

在步骤104中，后台将更新数据存储于数据库。

在步骤106中，后台发布关于更新数据的更新消息。

在步骤108中，接收到更新消息的前台通过数据库获取更新数据。

基于以上技术方案，通过在后台和前台之间增加更新数据的消息机制，后台可以将要修改的数据存储于数据库。通过发布/订阅的模式，前台可以在接收到关于更新数据的消息之后从数据库获取更新数据。因此，根据本发明的实施例可以通过后台对前台内容进行全面的管理和维护，各前台服务器可以独立地与数据库进行交互，不会存在数据不一致的情况。各前台服务器之间也没有依赖关系。

优选地，在本实施例中，当有多台前台服务器存在时，各前台服务器单独与数据库进行交互，前台服务器之间没有主从关系，主从服务器在进行同步操作时由于受到网络延迟和数据传输速度的影响，并受限于定时任务存在的时间间隔，因此在主服务器和从服务器上的内容并不能完全实时同步，本实施例中各前台服务器直接与数据库连接，避免了个前台服务器之间数据不一致的情况。

图2是根据本发明实施例的应用场景的示意图。在该应用场景中包括后台202、消息队列204、数据库206和前台208。

如图2所示，可以通过Java信息服务（JavaMessageService，简称为JMS）来实现更新，后台202在更新完成后，将更新数据存储到数据库206中，并自动发布与更新数据对应的更新消息，例如，后台202在接收到后台管理员输入的更新完成的指令后，无需额外发送指令，可以立即向数据库发送该更新数据，同时，查找更新数据和原有数据的区别，并确定该区别在更新数据的位置或ID，然后生成包含该位置或ID的更新消息，并将该更新消息发送给前台208。前台208接收到订阅的更新消息后根据更新消息查询数据库206，取出更新的内容，同时生成新的前台内容，实现更新，例如，更新数据共2000条，每条包括ID和内容，在一次更新数据中，仅改变了前台内容的呈现颜色，因此仅ID为10的对应内容与之前的内容不同，则更新消息中指明ID为10的对应内容有更新，前台208从更新数据中取出ID为10的对应内容，并生成新的前台内容。这种实施方式的优势在于结构简单，实现方便。

更优选地，在上一实施例中，前台208从更新数据中取出ID为10的对应内容后，先校验对应的内容和原内容是否相同，如果和原内容相同，则不会重新生成前台内容，例如，该内容的修改只是将原内容删除后重新写入，仅输入时间不同，其他内容均相同，那么不会生成新的前台内容。

图3是根据本发明另一实施例的应用场景的示意图。在该应用场景下，包括后台302、非关系型数据库304、关系型数据库306和前台308。

后台302是后台管理部分，可以部署多台前台服务器。后台302可以将更新数据存储到关系型数据库306，并向非关系型数据库304发送同步指令，仍结合上述示例进行说明，更新数据共2000条，仅ID为10的对应内容与之前的内容不同，则后台302向非关系型数据库304发出同步指令，指示非关系型数据库304仅从关系型数据库306里的更新数据中同步ID为10的这条内容，在此之后，后台302再通过非关系型数据库304发布关于更新数据的更新消息。在一个实施例中，非关系型数据库304可以是一个Key-Value数据库。另外，随着Key－Value数据库在Web应用中的广泛应用，也出现了许多优秀的数据库，比如MongoDB，MemcacheDB，Redis等。例如，本发明可以利用Redis作为存储结构，实现支持订阅/发布的消息机制、访问速度快且数据结构丰富的效果。

前台308是面向用户的前端信息展示部分，可以部署多台服务器。前台308在收到更新消息后，可以快速地从非关系型数据库304中获取更新数据相比于先前数据更新的内容。

在图3所示的实施例中采用了高并发和大数据量读取方面性能优秀的非关系型数据库304，从非关系型数据库304中读取数据的速度明显快于从关系型数据库306中读取数据，因此，关系型数据库304对关系型数据库306起到很好的补偿作用。相比于图2所示的实施例，图3所示的实施例即使在访问量变大或部署的前台服务器过多的时候，前台308不需要从关系型数据库306中查询更新的内容，例如，有100个人同时进一栋房子找东西，这100个人同时上楼会导致楼道的拥挤，而且每个人去不同的地方找东西也需要耗费一定时间，如果将这100个人需要的东西提前找出，并放在1楼的楼道口，则大大减少了这100个人找东西的时间，也不会导致楼道的拥挤，结合本实施例，即提高了数据传输的效率，而且减小了关系型数据库306的压力。

图4是根据本发明另一实施例的WEB应用发布方法400的流程图。

在步骤402中，将前台内容划分为应用于后台的不同的模型，模型包括第一模型和第二模型。其中，第一模型为整个前台，第二模型为组成第一模型的元素，一般是多个元素。

在一个实施例中，第一模型为站点，站点为整个前台，第二模型至少包括频道、页面和组件中的一种，其中，频道为组成站点的多个元素，页面为组成频道的多个元素，组件为组成页面的多个元素。

例如，根据前台的展现形式，将前台内容划分为可以在后台表示的模型，包括将前台按结构划分为站点、频道、页面和组件。

其中，站点可以是整个前台，该模型主要是为了程序的重用性而设计。在一个实施例中，一个前台可以由一个站点组成。在另一个实施例中，多个前台可以共用一个后台，共用一套数据结构和程序逻辑，而只是展示形式不一样，这时可以考虑通过增加多个站点的形式来实现。

频道可以是组成站点的主要元素，一个站点可以包括多个频道。

页面可以是组成频道的元素，与前台的展示页面相对应。在一个实施例中，根据不同的前台内容表现形式，可以将页面划分为主页、列表页、详情页和导航页。每个频道模型都可以由这四种页面组成。在一个实施例中，每个频道都可以有子频道。

组件可以是组成页面的部分，与页面中的版块对应。可以根据页面展示的内容与展示形式将页面划分为一个或多个组件。组件可以与一些可重用的代码块关联，并可以通过参数来改变展示的内容和样式。

在步骤404中，针对第一模型和第二模型建立第一数据表和第二数据表，第一数据表包括第一模型的相关描述信息，第二数据表包括第二模型的相关描述信息以及第二模型与第一模型之间的关系的相关信息。

例如：针对站点、频道、页面和组件建立站点表、频道表、页面表、模板表和页面模板关系表等。

其中，站点表可以是一个相对简单的模型，仅包括基本的站点信息，如名称，描述，创建人，创建时间等。

频道表是频道相关的数据模型，除了基本信息之外，还可以有一些重要的关联信息，包括频道所属的站点，频道的父节点（顶层频道的父节点为空），频道的四个页面（主页、列表页、详情页和导航页）的ID（初始化为空）等。

页面表是页面的数据模型，除基本信息外，还可以包括一些特有的属性，比如页面所属的频道，页面类型（首页/列表页/详情页/导航页），页面内容等。

模板表是组件的数据模型，可以用于存储一些可复用的网页代码以供页面使用。除基本信息外，模板表还可以包括模板的内容属性。另外由于模板是可复用的，所以其与页面之间可以是多对多的关系，不属于某个特定的页面。

页面模板关系表可以用于记录组件与页面之间的对应关系。

在步骤406中，将第一数据表和第二数据表存储于数据库。

在一个实施例中，在存储之前，可以将例如页面和组件的第二模型中所包含的数据进行压缩。例如，可以选择源自Apache的Avro数据序列化系统，以提供丰富的数据结构和快速可压缩的二进制数据形式。考虑到页面和组件模型中包含网页代码的情况，所以数据量会比较大，如果不对数据作任何处理便存储于数据库中，那么大数据量在读取上还是会受到一些影响。由于存储的都是一些文本信息，所以可以在存储时，可以先对数据进行压缩，在读取时先解压再处理，这样使性能得到了进一步的提升。

在步骤408中，后台接收更新数据。在一个实施例中，在对数据的更新中，对于采用SpringMVC框架的系统可以采用Freemarker来编写组件。

在前台内容的布局方案中，可以采用配置灵活对底层支持较好的布局技术，例如：Tiles和Sitemesh等。例如，可以将页面全部由以Tiles方式表述的组件组成，在配置文件中可以有一些默认的关于这些组件的参数设置，可以在前台内容中修改或者增加某些参数而不用修改配置文件，使得组件具有极大的灵活性。另外，由于Tiles的组件代码具有一定的规范，格式也相对固定，所以组件代码完全可以自动生成，而无需手动编辑代码，因此能够简化和方便运营人员的管理。

在一个实施例中，后台可以对接收到的更新数据进行有效性和合法性检验，因此能够消除由于人为操作原因导致的线上问题，减少上线风险。

在步骤410中，后台将更新数据存储于数据库。

在步骤412中，后台发布关于更新数据的更新消息。在一个实施例中，后台可以通过消息队列发布更新消息。在另一实施例中，后台也可以通过非关系型数据库发布更新消息。

在步骤414中，订阅关于更新消息的前台接收关于更新数据的更新消息。

在步骤416中，前台获取更新数据以实现对前台所呈现的内容的更新。在一个实施例中，前台通过消息队列获取更新消息后，可以从数据库获取更新数据。在另一实施例中，前台通过非关系型数据库获取更新消息后，可以从该非关系型数据库获取更新数据。其中，非关系型数据库中的更新数据通过数据库对非关系型数据库的同步操作而获得。在一个实施例中，由于往非关系型数据库中同步的内容并不需要实时进行，所以也可以通过手动触发的方式来将关系型数据库中的内容同步到非关系型数据库中。

另外，为了减少用户访问非关系型数据库的次数，在一个实施例中，可以在前台增加一层缓存，只有后台对模板内容进行更行后，缓存才失效。这样，可以加快响应速度。

根据本发明的实施例，还提供了一种用于WEB应用发布的装置500，该装置可用来执行后台的操作，图5是根据本发明实施例的用于WEB应用发布的装置500的结构示意图。装置500可以包括：更新模块502、数据存储模块504和消息发布模块506。

更新模块502，用于接收更新数据。

数据存储模块504，用于将更新数据存储于数据库。

消息发布模块506，用于发布关于更新数据的更新消息，以使得接收到更新消息的前台能够通过数据库获取更新数据。

图6是根据本发明另一实施例的用于WEB应用发布的装置600的结构示意图。装置600可以包括：更新模块602、数据存储模块604、消息发布模块606、数据表建立模块610和存储模块612。其中，对于更新模块602、数据存储模块604和消息发布模块606与如图5所示的相应模块具有相似的功能及技术特征处不再赘述。

数据表建立模块610，用于在接收更新数据之前针对前台的第一模型和第二模型分别建立第一数据表和第二数据表，其中，第一模型为整个前台，第二模型为组成第一模型的元素，一般是多个元素，第一数据表包括第一模型的相关描述信息，第二数据表包括第二模型的相关描述信息以及第二模型与第一模型之间的关系的相关信息。在一个实施例中，第一模型可以为站点，站点为整个前台。第二模型可以至少包括频道、页面和组件中的一种。

存储模块612，用于将第一数据表和第二数据表存储于数据库。

图7是根据本发明又一实施例的用于WEB应用发布的装置700的结构示意图。装置700可以包括：更新模块702、数据存储模块704、消息发布模块706、查找模块708、确定模块710和消息生成模块712。其中，对于更新模块702、数据存储模块704和消息发布模块706与如图5所示的相应模块具有相似的功能及技术特征处不再赘述。

查找模块708，用于在消息发布模块706发布关于更新数据的更新消息之前查找更新数据与原有数据的区别。

确定模块710，用于确定区别中能够被前台识别的识别特征。

消息生成模块712，用于生成包括识别特征的更新消息。

在该实施例中，消息发布模块706可以通过消息队列发布更新消息，以使得订阅更新消息的前台能够接收到更新消息，并且随后从数据库获取与识别特征相对应的更新数据。

图8是根据本发明又一实施例的用于WEB应用发布的装置800的结构示意图。装置800可以包括：更新模块802、数据存储模块804、消息发布模块806、查找模块808、确定模块810、消息生成模块812和同步模块814。其中，对于更新模块802、数据存储模块804、消息发布模块806、查找模块808、确定模块810、消息生成模块812与如图7所示的相应模块具有相似的功能及技术特征处不再赘述。

在该实施例中，消息发布模块806通过非关系型数据库发布更新消息，以使得订阅更新消息的前台能够接收到更新消息并从非关系型数据库获取更新数据，其中，非关系型数据库中的更新数据是通过与数据库同步而获取的。

同步模块814，用于在向前台发布更新消息之前向非关系型数据库发送同步指令，指示非关系型数据库从数据库同步更新数据，同步指令包括更新数据与原有数据之间的区别中能够被前台识别的识别特征，以使得非关系型数据库从数据库同步与识别特征相对应的更新数据。

本领域技术员人还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术员人可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器（RAM）、内存、只读存储器（ROM）、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

以上的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (12)

1.一种WEB应用发布方法，其特征在于，包括：

后台接收更新数据；

所述后台将所述更新数据存储于数据库，并发布关于所述更新数据的更新消息，以使接收到所述更新消息的前台能够通过所述数据库获取所述更新数据；

在后台接收更新数据之前，所述方法还包括：

针对所述前台的第一模型和第二模型分别建立第一数据表和第二数据表，其中，所述第一模型为整个所述前台，所述第二模型为组成所述第一模型的元素，所述第一数据表包括所述第一模型的相关描述信息，所述第二数据表包括所述第二模型的相关描述信息以及所述第二模型与第一模型之间的关系的相关信息；所述前台为面向用户的前端信息展示部分，所述第一模型和所述第二模型是对前台内容进行划分得到的可以在后台表示的模型；

将所述第一数据表和所述第二数据表存储于所述数据库。

2.根据权利要求1所述的方法，其特征在于，在所述后台发布关于所述更新数据的更新消息之前，所述方法包括：

所述后台查找所述更新数据与原有数据的区别；

所述后台确定所述区别中能够被所述前台识别的识别特征；

所述后台生成包括所述识别特征的所述更新消息。

3.根据权利要求1或2所述的方法，其特征在于，所述后台通过消息队列发布所述更新消息，以使订阅所述更新消息的所述前台能够接收到所述更新消息。

4.根据权利要求1或2所述的方法，其特征在于，所述后台通过非关系型数据库发布所述更新消息，以使订阅所述更新消息的所述前台能够接收到所述更新消息并从所述非关系型数据库获取所述更新数据，其中，所述非关系型数据库中的所述更新数据是通过与所述数据库同步而获取的。

5.根据权利要求4所述的方法，其特征在于，还包括：

所述后台在向所述前台发布所述更新消息之前向所述非关系型数据库发送同步指令，指示所述非关系型数据库从所述数据库同步所述更新数据，所述同步指令包括所述更新数据与原有数据之间的区别中能够被所述前台识别的识别特征，以使所述非关系型数据库从所述数据库同步与所述识别特征相对应的更新数据。

6.根据权利要求1所述的方法，其特征在于，所述第一模型为站点，所述站点为整个所述前台，所述第二模型至少包括频道、页面和组件中的一种。

7.一种用于WEB应用发布的装置，其特征在于，包括：

更新模块，用于接收更新数据；

数据存储模块，用于将所述更新数据存储于数据库；

消息发布模块，用于发布关于所述更新数据的更新消息，以使接收到所述更新消息的前台能够通过所述数据库获取所述更新数据；

所述装置还包括：

数据表建立模块，用于在接收更新数据之前针对所述前台的第一模型和第二模型分别建立第一数据表和第二数据表，其中，所述第一模型为整个所述前台，所述第二模型为组成所述第一模型的元素，所述第一数据表包括所述第一模型的相关描述信息，所述第二数据表包括所述第二模型的相关描述信息以及所述第二模型与第一模型之间的关系的相关信息；所述前台为面向用户的前端信息展示部分，所述第一模型和所述第二模型是对前台内容进行划分得到的可以在后台表示的模型；

存储模块，用于将所述第一数据表和所述第二数据表存储于所述数据库。

8.根据权利要求7所述的装置，其特征在于，所述装置还包括：

查找模块，用于在所述消息发布模块发布关于所述更新数据的更新消息之前查找所述更新数据与原有数据的区别；

确定模块，用于确定所述区别中能够被所述前台识别的识别特征；

消息生成模块，用于生成包括所述识别特征的所述更新消息。

9.根据权利要求7或8所述的装置，其特征在于，所述消息发布模块通过消息队列发布所述更新消息，以使订阅所述更新消息的所述前台能够接收到所述更新消息。

10.根据权利要求7或8所述的装置，其特征在于，所述消息发布模块通过非关系型数据库发布所述更新消息，以使订阅所述更新消息的所述前台能够接收到所述更新消息并从所述非关系型数据库获取所述更新数据，其中，所述非关系型数据库中的所述更新数据是通过与所述数据库同步而获取的。

11.根据权利要求10所述的装置，其特征在于，所述装置还包括：

同步模块，用于在向所述前台发布所述更新消息之前向所述非关系型数据库发送同步指令，指示所述非关系型数据库从所述数据库同步所述更新数据，所述同步指令包括所述更新数据与原有数据之间的区别中能够被所述前台识别的识别特征，以使所述非关系型数据库从所述数据库同步与所述识别特征相对应的更新数据。

12.根据权利要求7所述的装置，其特征在于，所述第一模型为站点，所述站点为整个所述前台，所述第二模型至少包括频道、页面和组件中的一种。