我想大家都已经知道生命周期是什么。我们出生，生活，死亡……事实上，对于Aflresco Nodes来说，这是完全一样的！好吧，至少从最终用户的角度来看。但是，这背后究竟是怎么回事？这就是我将在这篇文章中尝试解释的内容。

首先，什么是Alfresco节点？对于大多数人来说，Node只是存储在Alfresco中的文档，但实际上不仅仅如此：Alfresco中的所有内容都是一个Node！节点具有定义其属性的类型，并且还具有与其他节点的某些关联。这是一个非常简短的描述，但是我们不需要了解节点到底是什么来了解生命周期过程。因此，如上所述，Alfresco节点具有自己的生命周期，但它仅比三个简单步骤复杂一点。

请注意，在这篇文章中，我将使用$ ALF_HOME作为alfresco安装位置的引用（例如/opt/alfresco-4.2.c），并使用$ ALF_DATA作为alf_data位置的引用。默认情况下，alf_data文件夹为$ ALF_HOME / alf_data /。

一、创建

在这篇文章中，我将使用一个文档作为Alfresco节点来轻松理解该过程。因此，此生命周期从创建一个名为“ Test_Lifecycle.docx”的新文档开始，其创建日期如下：2015年2月1日，16：45。

在Alfresco中创建文档时，将完成三件事：

文件系统：此文件的内容存储在Alfresco“内容存储”中。默认情况下，内容存储在$ ALF_DATA / contentstore下。该文件实际上放置在此文件夹下的某个位置，具体取决于创建时间，并且为此文件指定了ID。对于我们的文件，它将是：$ ALF_DATA / contentstore / 2015/2/1/16/45 / 408a6980-237e-4315-88cd-6955053787c3.bin。
数据库：此文件的数据存储在Alfresco数据库中。实际上，在数据库中，主要使用其NodeRef或NodeID来引用此文档。我们可以在Alfresco Web界面的文档详细信息页面（文档的网络预览）上看到此NodeRef：http：// HOSTNAME：PORT / share / share / page / document-details？nodeRef = workspace：// SpacesStore / 09a8bd9f -0246-47a8-9701-29436c7d29a6。请注意，NodeRef包含一个UUID，但与Content Store一侧的ID不同。此外，数据库中还有一个属性，该属性将NodeRef链接到Alfresco的Content Store的ID，以便能够检索内容文件。
索引：在搜索引擎中为此文件创建了一个索引（对于Alfresco的旧版本可以是Lucene，对于较新的版本可以是Solr）。该索引在“工作区”存储区中。

二、更新，审阅，批准，发布…

创建文档后，他的生活就真正开始了。您可以手动或通过不同的过程自动更新/查看/批准/发布它。所有这些动作都是文档有效期的一部分。从管理的角度来看，这里没有太多要说的。

三、删除–用户级别

当不再需要文档时，无论出于何种原因，具有足够权限的用户都可以将其删除。对于我们的示例，假设用户使用2015年2月20日15:30（创建后19天）的Alfresco共享Web界面删除了文件“ Test_Lifecycle.docx”。使用Web Interface或Web Services删除文档时，将调用“ nodeService.deleteNode”方法。那么我们的“三件事”发生了什么？

FS：内容存储库上没有任何更改。文件内容仍然在这里。
DB：在DB端，NodeRef从工作空间：// SpacesStore / 09a8bd9f-0246-47a8-9701-29436c7d29a6更改为archive：// SpacesStore / 09a8bd9f-0246-47a8-9701-29436c7d29a6（“ store_id”字段已更改为“ alf_node”表）。
索引：与搜索索引相同：索引从“工作区”存储区移至“档案”存储区。
实际上，当用户从Alfresco的Web界面删除文档时，该文档只是移至“全局垃圾桶”中。默认情况下，所有用户都可以在Alfresco Explorer中访问此全局垃圾箱，以恢复他们可能误删除的文档。当然，他们看不到所有文档，而只能看到与它们相关的文档。在Alfresco Share上，此全局垃圾桶的访问权限在share-config.xml文件中配置，默认情况下，在大多数版本中，只有管理员可以访问它。

避免此全局垃圾箱的唯一方法是，通过对文档应用“ cm：temporary”方面，以编程方式删除文档，然后在其上调用“ nodeService.deleteNode”。这样，该文档将从UI中删除，而不会放入全局垃圾箱中。

四、删除–管理级别

我在这里所说的“管理级别”是默认情况下发生的第二级删除。此级别是从全局垃圾箱中删除文档。如果文档仍在全局垃圾箱中，则管理员（或用户，如果您使用的是Alfresco Explorer）仍可以还原文档。如果文档是“未删除”的，则它将返回之前的精确位置，当然，该文档的元数据和索引也将从“存档”存储区移至“工作区”存储区，以恢复活跃状态。

2015年4月1日上午8:05（在用户级别删除后的40天），管理员决定从全局垃圾箱中删除“ Test_Lifecycle.docx”。这可以手动或以编程方式完成。此外，还有一些现有的加载项，可以将其配置为自动删除XX天之前的垃圾箱中的元素。这次，称为“ NodeArchiveService.purgeArchiveNode”方法（在某些较旧的Alfresco版本中为archiveService.purge）。那么这次我们的“三件事”发生了什么？

FS：内容存储库上仍然没有任何更改。文件内容仍然在这里。
DB：在DB端，文档仍然存在，但是某些引用/字段（不是全部）已删除。当仅在“ alf_node”表上清空某些字段时，“ alf_content_data”表上的所有引用都将被删除。对于Alfresco 4.0及更低版本，表“ alf_node”上的“ node_deleted”字段从0更改为1。在较新版本的Alfresco上，“ node_deleted”已不存在，但节点的QNAME（字段“ type_qname_id” ）“ alf_node”表上的）从51（“内容”）更改为140（“已删除”）。因此，该节点现在已从全局垃圾箱中删除，而Alfresco知道该节点现在可以安全地删除了，但是现在不能这样做……一旦设置了“ node_deleted”或“ type_qname_id”，则“ alf_content_url”上的“ orphan_time”字段该文档的表也从NULL更改为当前的unix时间戳（+ gmt偏移量）。
索引：此节点的搜索索引已删除。
如您所见，文件系统和数据库中仍有一些剩余元素。这就是为什么我们生命周期中的最后一步……

五、删除–更进一步

如您所见，文档“ Test_Lifecycle.docx”现在被视为“孤立”节点。默认情况下，在Alfresco上，所有孤立节点的保护期为14天。这意味着在此期间，孤立的节点将完全不会被触摸。当然，可以在Alfresco配置文件上轻松更改此值。那么14天后会发生什么呢？实际上，实际上每天凌晨4点（同样，默认情况下可以更改...），一个计划的作业（“ contentStoreCleaner”）会扫描Alfresco中是否有14天以上的孤立节点。因此，在2015年4月15日04:00，计划的作业开始运行，它的作用如下：

FS：内容文件从$ ALF_DATA / contentstore /移至$ ALF_DATA / contentstore.deleted /
DB：在DB端，文档仍在此处，但是“ alf_content_url”表（此表包含orphan_time并引用了FS位置）上与此文档相关的行已删除。
索引：无所事事，搜索索引已被删除。
您可以通过在alfresco-global.properties配置文件中设置“ system.content.eagerOrphanCleanup = true”来避免将文档放在“ contentstore.deleted”文件夹中的步骤。如果这样做，则14天后，文件系统上的文档不会移动，而是会被删除。

六、删除–最后！

如前所述，在Alfresco数据库上（尤其是在“ alf_node”表上）仍然有一些对“ Test_Lifecycle.docx”文档的引用。另一个计划的作业，nodeServiceCleanup每天在21:00运行，以清理与已删除30天以上的节点（孤立节点）有关的所有内容。因此，结果如下：

FS：内容文件仍位于$ ALF_DATA / contentstore.deleted /文件夹中
DB：DB终于干净了！
索引：无所事事，搜索索引已被删除。

七、其他

这么多步骤，不是吗！如前所述，剩下要做的就是从$ ALF_DATA / contentstore.deleted /文件夹中删除内容文件。您可能认为在XX天后还有一项工作可以为您完成该任务，但实际情况并非如此，Alfresco中没有任何东西可以从该位置删除内容文件。结果，如果您要清理文件系统，则必须自己完成。

例如，在Unix上，您可以简单地创建一个crontab条目：

50 23 * * * $ALF_HOME/scripts/cleanContentStoreDeleted.sh

然后创建此脚本。以下是可以解决问题的内容的示例，但是您可以在脚本中放入想要/需要的内容，以根据需要删除内容或创建备份：

#!/bin/bash

CS_DELETED=$ALF_DATA/contentstore.deleted/

# Remove all files from contentstore.deleted older than 30 days
find $CS_DELETED -type f -mtime +30 | xargs rm 2> /dev/null
# Remove all empty folders from contentstore.deleted older than 60 days
find $CS_DELETED -type d -mtime +60 -empty | xargs rm -r 2> /dev/null

请注意，您应该确保文件夹“ $ ALF_DATA / contentstore.deleted”存在。当我这样说时，我的意思是您必须绝对确定它存在。也请不要删除“ contentstore”文件夹下的任何内容，也不要删除“ contentstore.deleted”文件夹本身！

您可能想知道为什么清理垃圾箱时不能自动清理数据库，以及为什么文件内容也保留14天……所以我可以向您保证，原因有很多，主要原因是出于备份/还原性能方面的考虑。我将不作详细解释，但是基本上，由于默认情况下14天都不会触摸文件内容，因此这意味着您最多可以还原14天的数据库，而数据库仍将与文件系统保持一致，而无需进行任何操作。恢复FS！当然，如果您这样做，您将丢失最近14天上传/更改的文档，因为您的数据库在14天之前不知道这些文件。但是，您仅可以使用增量备份来备份/还原最近14天创建的内容文件。

例如：今天（2015年5月5日），我想备份FS（仅过去14天），那么我将必须备份$ ALF_DATA / contentstore / 2015/5中的所有文件夹，并且我还必须备份所有$ ALF_DATA / contentstore / 2015/4内的文件夹，其文件夹名称大于或等于30（4月的天数）+ 5（5月的天数）– 14 =21。
我希望此帖子足够清楚，因为它的确可以很难理解有关Alfresco Node生命周期的所有信息并正确处理。