数据库订阅与发布谁用过.怎么设置

下面是按顺序列出配置复制的步骤:54com一、建立发布和分发服务器

[欢迎使用配置发布和分发向导]->[选择分发服务器]

->[使"@servername"成为它自己的分发服务器,SQLServer将创建分发数据库和日志]

->[制定快照文件夹]->[自定义配置]->[否,使用下列的默认配置]->[完成]

上述步骤完成后,会在当前"@servername"SQLServer数据库里建立了一个distribion库和

一个distributor_admin管理员级别的用户(我们可以任意修改密码)

服务器上新增加了四个作业:

[代理程序历史记录清除:]

[分发清除:]

[复制代理程序检查]

[重新初始化存在数据验证失败的订阅]

SQLServer企业管理器里多了一个复制监视器,当前的这台机器就可以发布、分发、订阅了。

我们再次在SQLServer企业管理器里[复制]->右键选择

->[配置发布、订阅服务器和分发],可以看到类似下图:

54ne我们可以在[发布服务器和分发服务器的属性]窗口

->[发布服务器]->[新增]->[确定]

->[发布数据库]->[事务]/[合并]->[确定]

->[订阅服务器]->[新增]->[确定]

把网络上的其它SQLServer服务器添加成为发布或者订阅服务器新增一台发布服务器的选项：

我这里新建立的JIN001发布服务器是用管理员级别的数据库用户test连接的，到发布服务器的管理链接要输入密码的可选框,默认的是选中的，在新建的JIN001发布服务器上建立和分发服务器FENGYU/FENGYU的链接的时需要输入distributor_admin用户的密码中国网管联盟>

编者按 ：本文由「高可用架构后花园」群讨论整理而成。

有人的地方，就有江湖

有江湖的地方，就有纷争

在电商等业务中，系统一般由多个独立的服务组成，如何解决分布式调用时候数据的一致性？

具体业务场景如下，比如一个业务 *** 作，如果同时调用服务 A、B、C，需要满足要么同时成功；要么同时失败。A、B、C 可能是多个不同部门开发、部署在不同服务器上的远程服务。

在分布式系统来说，如果不想牺牲一致性，CAP 理论告诉我们只能放弃可用性，这显然不能接受。为了便于讨论问题，先简单介绍下数据一致性的基础理论。

强一致

弱一致性

最终一致性

在工程实践上，为了保障系统的可用性，互联网系统大多将强一致性需求转换成最终一致性的需求，并通过系统执行幂等性的保证，保证数据的最终一致性。但在电商等场景中，对于数据一致性的解决方法和常见的互联网系统（如 MySQL 主从同步）又有一定区别，群友的讨论分成以下 6 种解决方案。

业务整合方案主要采用将接口整合到本地执行的方法。拿问题场景来说，则可以将服务 A、B、C 整合为一个服务 D 给业务，这个服务 D 再通过转换为本地事务的方式，比如服务 D 包含本地服务和服务 E，而服务 E 是本地服务 A ~ C 的整合。

优点： 解决（规避）了分布式事务。

缺点： 显而易见，把本来规划拆分好的业务，又耦合到了一起，业务职责不清晰，不利于维护。

由于这个方法存在明显缺点，通常不建议使用。

此方案的核心是将需要分布式处理的任务通过消息日志的方式来异步执行。消息日志可以存储到本地文本、数据库或消息队列，再通过业务规则自动或人工发起重试。人工重试更多的是应用于支付场景，通过对账系统对事后问题的处理。

消息日志方案的核心是保证服务接口的幂等性。

考虑到网络通讯失败、数据丢包等原因，如果接口不能保证幂等性，数据的唯一性将很难保证。

eBay 方式的主要思路如下。

Base：一种 Acid 的替代方案

此方案是 eBay 的架构师 Dan Pritchett 在 2008 年发表给 ACM 的文章，是一篇解释 BASE 原则，或者说最终一致性的经典文章。文中讨论了 BASE 与 ACID 原则在保证数据一致性的基本差异。

如果 ACID 为分区的数据库提供一致性的选择，那么如何实现可用性呢？答案是

BASE (basically available, soft state, eventually consistent)

BASE 的可用性是通过 支持局部故障 而不是系统全局故障来实现的。下面是一个简单的例子：如果将用户分区在 5 个数据库服务器上，BASE 设计鼓励类似的处理方式，一个用户数据库的故障只影响这台特定主机那 20% 的用户。这里不涉及任何魔法，不过它确实可以带来更高的可感知的系统可用性。

文章中描述了一个最常见的场景，如果产生了一笔交易，需要在交易表增加记录，同时还要修改用户表的金额。这两个表属于不同的远程服务，所以就涉及到分布式事务一致性的问题。

文中提出了一个经典的解决方法，将主要修改 *** 作以及更新用户表的消息 放在一个本地事务 来完成。同时为了避免重复消费用户表消息带来的问题，达到多次重试的幂等性， 增加一个更新记录表 updates_applied 来记录已经处理过的消息。

系统的执行伪代码如下

（点击可全屏缩放）

基于以上方法，在第一阶段，通过本地的数据库的事务保障，增加了 transaction 表及消息队列 。

在第二阶段，分别读出消息队列（但不删除），通过判断更新记录表 updates_applied 来检测相关记录是否被执行，未被执行的记录会修改 user 表，然后增加一条 *** 作记录到 updates_applied，事务执行成功之后再删除队列。

通过以上方法，达到了分布式系统的最终一致性。进一步了解 eBay 的方案可以参考文末链接。

随着业务规模不断地扩大，电商网站一般都要面临拆分之路。就是将原来一个单体应用拆分成多个不同职责的子系统。比如以前可能将面向用户、客户和运营的功能都放在一个系统里，现在拆分为订单中心、代理商管理、运营系统、报价中心、库存管理等多个子系统。

拆分首先要面临的是什么呢？

最开始的单体应用所有功能都在一起，存储也在一起。比如运营要取消某个订单，那直接去更新订单表状态，然后更新库存表就 ok 了。因为是单体应用，库在一起，这些都可以在一个事务里，由关系数据库来保证一致性。

但拆分之后就不同了，不同的子系统都有自己的存储。比如订单中心就只管理自己的订单库，而库存管理也有自己的库。那么运营系统取消订单的时候就是通过接口调用等方式来调用订单中心和库存管理的服务了，而不是直接去 *** 作库。这就涉及一个『 分布式事务 』的问题。

分布式事务有两种解决方式

1 优先使用异步消息。

上文已经说过，使用异步消息 Consumer 端需要实现幂等。

幂等有两种方式， 一种方式是业务逻辑保证幂等 。比如接到支付成功的消息订单状态变成支付完成，如果当前状态是支付完成，则再收到一个支付成功的消息则说明消息重复了，直接作为消息成功处理。

另外一种方式如果业务逻辑无法保证幂等，则要增加一个去重表或者类似的实现 。对于 producer 端在业务数据库的同实例上放一个消息库，发消息和业务 *** 作在同一个本地事务里。发消息的时候消息并不立即发出，而是向消息库插入一条消息记录，然后在事务提交的时候再异步将消息发出，发送消息如果成功则将消息库里的消息删除，如果遇到消息队列服务异常或网络问题，消息没有成功发出那么消息就留在这里了，会有另外一个服务不断地将这些消息扫出重新发送。

2 有的业务不适合异步消息的方式，事务的各个参与方都需要同步的得到结果。 这种情况的实现方式其实和上面类似，每个参与方的本地业务库的同实例上面放一个事务记录库。

比如 A 同步调用 B，C。A 本地事务成功的时候更新本地事务记录状态，B 和 C 同样。如果有一次 A 调用 B 失败了，这个失败可能是 B 真的失败了，也可能是调用超时，实际 B 成功。则由一个中心服务对比三方的事务记录表，做一个最终决定。假设现在三方的事务记录是 A 成功，B 失败，C 成功。那么最终决定有两种方式，根据具体场景：

对 b 场景做一个特殊说明：比如 B 是扣库存服务，在第一次调用的时候因为某种原因失败了，但是重试的时候库存已经变为 0，无法重试成功，这个时候只有回滚 A 和 C 了。

那么可能有人觉得在业务库的同实例里放消息库或事务记录库，会对业务侵入，业务还要关心这个库，是否一个合理的设计？

实际上可以依靠运维的手段来简化开发的侵入，我们的方法是让 DBA 在公司所有 MySQL 实例上预初始化这个库，通过框架层（消息的客户端或事务 RPC 框架）透明的在背后 *** 作这个库，业务开发人员只需要关心自己的业务逻辑，不需要直接访问这个库。

总结起来，其实两种方式的根本原理是类似的，也就是 将分布式事务转换为多个本地事务，然后依靠重试等方式达到最终一致性 。

交易创建的一般性流程

我们把交易创建流程抽象出一系列可扩展的功能点，每个功能点都可以有多个实现（具体的实现之间有组合/互斥关系）。把各个功能点按照一定流程串起来，就完成了交易创建的过程。

面临的问题

每个功能点的实现都可能会依赖外部服务。那么如何保证各个服务之间的数据是一致的呢？比如锁定优惠券服务调用超时了，不能确定到底有没有锁券成功，该如何处理？再比如锁券成功了，但是扣减库存失败了，该如何处理？

方案选型

服务依赖过多，会带来管理复杂性增加和稳定性风险增大的问题。试想如果我们强依赖 10 个服务，9 个都执行成功了，最后一个执行失败了，那么是不是前面 9 个都要回滚掉？这个成本还是非常高的。

所以在拆分大的流程为多个小的本地事务的前提下，对于非实时、非强一致性的关联业务写入，在本地事务执行成功后，我们选择发消息通知、关联事务异步化执行的方案。

消息通知往往不能保证 100% 成功；且消息通知后，接收方业务是否能执行成功还是未知数。前者问题可以通过重试解决；后者可以选用事务消息来保证。

所以目前只剩下需要实时同步做、有强一致性要求的业务场景了。在交易创建过程中，锁券和扣减库存是这样的两个典型场景。

要保证多个系统间数据一致，乍一看，必须要引入分布式事务框架才能解决。但引入非常重的类似二阶段提交分布式事务框架会带来复杂性的急剧上升；在电商领域，绝对的强一致是过于理想化的，我们可以选择准实时的最终一致性。

我们在交易创建流程中， 首先创建一个不可见订单 ，然后在同步调用锁券和扣减库存时，针对调用异常（失败或者超时），发出废单消息到MQ。如果消息发送失败，本地会做时间阶梯式的异步重试；优惠券系统和库存系统收到消息后，会进行判断是否需要做业务回滚，这样就准实时地保证了多个本地事务的最终一致性。

业界常用的还有支付宝的一种 xts 方案，由支付宝在 2PC 的基础上改进而来。主要思路如下，大部分信息引用自官方网站。

分布式事务服务简介

分布式事务服务 (Distributed Transaction Service, DTS) 是一个分布式事务框架，用来保障在大规模分布式环境下事务的最终一致性。DTS 从架构上分为 xts-client 和 xts-server 两部分，前者是一个嵌入客户端应用的 JAR 包，主要负责事务数据的写入和处理；后者是一个独立的系统，主要负责异常事务的恢复。

核心特性

传统关系型数据库的事务模型必须遵守 ACID 原则。在单数据库模式下，ACID 模型能有效保障数据的完整性，但是在大规模分布式环境下，一个业务往往会跨越多个数据库，如何保证这多个数据库之间的数据一致性，需要其他行之有效的策略。在 JavaEE 规范中使用 2PC (2 Phase Commit, 两阶段提交) 来处理跨 DB 环境下的事务问题，但是 2PC 是反可伸缩模式，也就是说，在事务处理过程中，参与者需要一直持有资源直到整个分布式事务结束。这样，当业务规模达到千万级以上时，2PC 的局限性就越来越明显，系统可伸缩性会变得很差。基于此，我们采用 BASE 的思想实现了一套类似 2PC 的分布式事务方案，这就是 DTS。DTS在充分保障分布式环境下高可用性、高可靠性的同时兼顾数据一致性的要求，其最大的特点是保证数据最终一致 (Eventually consistent)。

简单的说，DTS 框架有如下特性：

以下是分布式事务框架的流程图

实现

与 2PC 协议比较

1 电商业务

公司的支付部门，通过接入其它第三方支付系统来提供支付服务给业务部门，支付服务是一个基于 Dubbo 的 RPC 服务。

对于业务部门来说，电商部门的订单支付，需要调用

从业务规则上需要同时保证业务数据的实时性和一致性，也就是支付成功必须加积分。

我们采用的方式是同步调用，首先处理本地事务业务。考虑到积分业务比较单一且业务影响低于支付，由积分平台提供增加与回撤接口。

具体的流程是先调用积分平台增加用户积分，再调用支付平台进行支付处理，如果处理失败，catch 方法调用积分平台的回撤方法，将本次处理的积分订单回撤。

(点击可以全屏缩放)

2 用户信息变更

分布式服务对衍生的配套系统要求比较多，特别是我们基于消息、日志的最终一致性方案，需要考虑消息的积压、消费情况、监控、报警等。

In partitioned databases, trading some consistency for availability can lead to dramatic improvements in scalability

英文版 ： >1技术层面上，云服务器租赁服务属于IaaS
依据《信息安全技术云计算服务安全指南》，云计算行业服务分为IaaS、PaaS、SaaS。IaaS，基础设施即服务，主要提供电脑基础设施和虚拟设备等，主要用户是系统管理员，阿里云是典型的IaaS。在IaaS模式中，云服务提供者仅有技术能力对服务器进行整体关停或空间释放(即“强行删除服务器内全部数据”)，而对用户利用云基础设施开设的网站和网络应用中存储的具体信息无法进行直接控制。而信息存储空间服务实际上是则是综合门户平台、电商平台、媒体平台、网盘等利用了云计算服务租用服务器后对外提供的服务。两者对信息的控制能力不同。
2法律层面上，云计算拿的是第一类增值电信业务许可
根据《电信业务分类目录》阿里云公司提供的云服务器租赁服务属于“互联网数据中心业务(B11)”，与提供“互联网接入服务业务(B14)”的中国联通、中国电信等同属于“第一类增值电信业务”，属于底层网络技术服务，而信息存储空间服务属于该目录中“第二类增值电信业务”中的“信息服务业务(B25)”。
因此，作为用户不需过度担心自身企业的数据安全问题。
阿里云的云服务器租赁服务不同于信息存储空间服务，阿里云无权调取服务器内的数据，更无权配合行政、司法部门提供数据。信息存储空间服务是指网络服务提供者为服务对象提供信息存储空间，供服务对象通过信息网络向公众提供作品、表演、录音录像制品。

统计数据安全管理制度1

1、由网管员负责建立数据备份系统，防止系统、数据的丢失。由专人负责数据备份工作，并认真填写备份日志。

2、一旦发生数据丢失或数据破坏等情况，必须由网管员进行备份数据的恢复，以免造成不必要的麻烦或更大的损失。

3、数据备份的主要内容为：网络服务器端 *** 作系统、系统及应用软件、数据库信息、网站信息、文档数据库、共享资源平台。

4、备份具体工作为将以上信息存储于磁介质及光盘上。

5、文件服务器实行双硬盘同时工作，硬盘问做镜像备份。

备份的时间为：

网络 *** 作系统每月底备份一次：

应用系统每次修改后备份一次，并保留最新的版本：

每星期备份服务器上的用户数据：

每月将用户数据刻录到光盘，作为历史数据保存：

如遇系统由重大改动或更新，需在改动之后当日进行备份

6、数据备份由网络系统管理员负责实施。并记录下备份的内容、时间。

7、备份数据及相关的数据档案统一保存在网络管理中心。未经领导批准不得外借。

8、如遇服务器遭受攻击或网络病毒，造成数据丢失或系统崩溃，需要进行数据恢复，需由网络通管理员执行恢复程序。同时将具体情况做记录。

9、数据备份和数据存储用的磁介质要严格管理、妥善保存。

统计数据安全管理制度2

数据中心作为主机托管的提供者，应尽力保障数据中心环境中的网络设备和服务器能够稳定、可靠地运行，从而达到高水平的管理，向客户提供高质量的服务。作为数据中心的客户，有责任和义务来了解数据中心的管理制度，并遵守数据中心的有关规范，从而确保数据中心的正常运作，也为保障客户系统的安全运行创造了良好的环境和基础。

　更换服务器也是SEO常见问题。有不少站长询问更换服务器会不会影响网站排名。只要 *** 作得当，网站转移到另一架服务器上，不会对排名有任何影响。除非你倒霉地把网站转移到了一个已经被搜索引擎惩罚的IP地址上。整架服务器IP被搜索引擎惩罚的概率非常低。
正确的服务器转移过程是:
1、做一个完整备份，包括数据库和所有程序、页面、文件，以防万一；
2、将DNS(域名服务器)TTL设置为很短，如几分钟。TTL控制DNS服务器的缓存时间，设置为很短时间，所有ISP及搜索引擎将随时查看DNS信息，而不是使用缓存中的IP地址；
3、 注册新主机账号，上传文件；
4、确认所有文件在新服务器上一切运转正常后，更改域名服务器，将域名解析到新服务器IP地址，同时旧服务器上的网站保持运行。一些用户贡献内容的网站，可以考虑旧服务器上暂时关闭用户发布新内容，以防万一转移过程出现问题，可能会造成新发布的数据丢失；
5、在新服务器上检查日志文件，确认搜索引擎蜘蛛开始爬行新服务器上的页面后，说明转移己经完成。域名解析理论上最长需要三天时间，当然为保险起见，也可以再多等两三天，确保所有搜索引擎蜘蛛都知道网站己经转移到新的服务器和IP地址；
6、确认解析过程完成，旧服务器上己经没有任何用户及搜索引擎蜘蛛的访问后，旧服务器账号可以关闭，转移过程完成。
整个服务器转移过程中，网站一直是可以正常访问的，因而不会对爬行、收录、排名有任何影响。

服务器遭受攻击后的处理流程

安全总是相对的，再安全的服务器也有可能遭受到攻击。作为一个安全运维人员，要把握的原则是：尽量做好系统安全防护，修复所有已知的危险行为，同时，在系统遭受攻击后能够迅速有效地处理攻击行为，最大限度地降低攻击对系统产生的影响。下面是我整理的服务器遭受攻击后的处理流程：

一、处理服务器遭受攻击的一般思路

系统遭受攻击并不可怕，可怕的是面对攻击束手无策，下面就详细介绍下在服务器遭受攻击后的一般处理思路。

1 切断网络

所有的攻击都来自于网络，因此，在得知系统正遭受黑客的攻击后，首先要做的就是断开服务器的网络连接，这样除了能切断攻击源之外，也能保护服务器所在网络的其他主机。

2 查找攻击源

可以通过分析系统日志或登录日志文件，查看可疑信息，同时也要查看系统都打开了哪些端口，运行哪些进程，并通过这些进程分析哪些是可疑的程序。这个过程要根据经验和综合判断能力进行追查和分析。下面的章节会详细介绍这个过程的处理思路。

3 分析入侵原因和途径

既然系统遭到入侵，那么原因是多方面的，可能是系统漏洞，也可能是程序漏洞，一定要查清楚是哪个原因导致的，并且还要查清楚遭到攻击的途径，找到攻击源，因为只有知道了遭受攻击的原因和途径，才能删除攻击源同时进行漏洞的修复。

4 备份用户数据

在服务器遭受攻击后，需要立刻备份服务器上的用户数据，同时也要查看这些数据中是否隐藏着攻击源。如果攻击源在用户数据中，一定要彻底删除，然后将用户数据备份到一个安全的地方。

5 重新安装系统

永远不要认为自己能彻底清除攻击源，因为没有人能比黑客更了解攻击程序，在服务器遭到攻击后，最安全也最简单的方法就是重新安装系统，因为大部分攻击程序都会依附在系统文件或者内核中，所以重新安装系统才能彻底清除攻击源。

6 修复程序或系统漏洞

在发现系统漏洞或者应用程序漏洞后，首先要做的就是修复系统漏洞或者更改程序bug，因为只有将程序的漏洞修复完毕才能正式在服务器上运行。

7 恢复数据和连接网络

将备份的数据重新复制到新安装的服务器上，然后开启服务，最后将服务器开启网络连接，对外提供服务。

二、检查并锁定可疑用户

当发现服务器遭受攻击后，首先要切断网络连接，但是在有些情况下，比如无法马上切断网络连接时，就必须登录系统查看是否有可疑用户，如果有可疑用户登录了系统，那么需要马上将这个用户锁定，然后中断此用户的远程连接。

1 登录系统查看可疑用户

通过root用户登录，然后执行“w”命令即可列出所有登录过系统的用户，如图1-11所示。

通过这个输出可以检查是否有可疑或者不熟悉的用户登录，同时还可以根据用户名以及用户登录的源地址和它们正在运行的进程来判断他们是否为非法用户。

2 锁定可疑用户

一旦发现可疑用户，就要马上将其锁定，例如上面执行“w”命令后发现nobody用户应该是个可疑用户(因为nobody默认情况下是没有登录权限的)，于是首先锁定此用户，执行如下 *** 作：

[root@server ~]# passwd -l nobody

锁定之后，有可能此用户还处于登录状态，于是还要将此用户踢下线，根据上面“w”命令的输出，即可获得此用户登录进行的pid值， *** 作如下：

[root@server ~]# ps -ef|grep @pts/3

531 6051 6049 0 19:23 00:00:00 sshd: nobody@pts/3

[root@server ~]# kill -9 6051

这样就将可疑用户nobody从线上踢下去了。如果此用户再次试图登录它已经无法登录了。

3 通过last命令查看用户登录事件

last命令记录着所有用户登录系统的日志，可以用来查找非授权用户的登录事件，而last命令的输出结果来源于/var/log/wtmp文件，稍有经验的入侵者都会删掉/var/log/wtmp以清除自己行踪，但是还是会露出蛛丝马迹在此文件中的。

三、查看系统日志

查看系统日志是查找攻击源最好的方法，可查的'系统日志有/var/log/messages、/var/log/secure等，这两个日志文件可以记录软件的运行状态以及远程用户的登录状态，还可以查看每个用户目录下的bash_history文件，特别是/root目录下的bash_history文件，这个文件中记录着用户执行的所有历史命令。

四、检查并关闭系统可疑进程

检查可疑进程的命令很多，例如ps、top等，但是有时候只知道进程的名称无法得知路径，此时可以通过如下命令查看：

首先通过pidof命令可以查找正在运行的进程PID，例如要查找sshd进程的PID，执行如下命令：

[root@server ~]# pidof sshd

13276 12942 4284

然后进入内存目录，查看对应PID目录下exe文件的信息：

[root@server ~]# ls -al /proc/13276/exe

lrwxrwxrwx 1 root root 0 Oct 4 22:09 /proc/13276/exe -> /usr/sbin/sshd

这样就找到了进程对应的完整执行路径。如果还有查看文件的句柄，可以查看如下目录：

[root@server ~]# ls -al /proc/13276/fd

通过这种方式基本可以找到任何进程的完整执行信息，此外还有很多类似的命令可以帮助系统运维人员查找可疑进程。例如，可以通过指定端口或者tcp、udp协议找到进程PID，进而找到相关进程：

[root@server ~]# fuser -n tcp 111

111/tcp: 1579

[root@server ~]# fuser -n tcp 25

25/tcp: 2037

[root@server ~]# ps -ef|grep 2037

root 2037 1 0 Sep23 00:00:05 /usr/libexec/postfix/master

postfix 2046 2037 0 Sep23 00:00:01 qmgr -l -t fifo -u

postfix 9612 2037 0 20:34 00:00:00 pickup -l -t fifo -u

root 14927 12944 0 21:11 pts/1 00:00:00 grep 2037

在有些时候，攻击者的程序隐藏很深，例如rootkits后门程序，在这种情况下ps、top、netstat等命令也可能已经被替换，如果再通过系统自身的命令去检查可疑进程就变得毫不可信，此时，就需要借助于第三方工具来检查系统可疑程序，例如前面介绍过的chkrootkit、RKHunter等工具，通过这些工具可以很方便的发现系统被替换或篡改的程序。

五、检查文件系统的完好性

检查文件属性是否发生变化是验证文件系统完好性最简单、最直接的方法，例如可以检查被入侵服务器上/bin/ls文件的大小是否与正常系统上此文件的大小相同，以验证文件是否被替换，但是这种方法比较低级。此时可以借助于Linux下rpm这个工具来完成验证， *** 作如下：

[root@server ~]# rpm -Va

L c /etc/pamd/system-auth

S5 c /etc/security/limitsconf

S5T c /etc/sysctlconf

S5T /etc/sgml/docbook-simplecat

S5T c /etc/logindefs

S5 c /etc/openldap/ldapconf

S5T c /etc/sudoers

5T c /usr/lib64/security/classpathsecurity

L c /etc/pamd/system-auth

S5 c /etc/security/limitsconf

S5 c /etc/ldapconf

S5T c /etc/ssh/sshd_config

对于输出中每个标记的含义介绍如下：

S 表示文件长度发生了变化

M 表示文件的访问权限或文件类型发生了变化

5 表示MD5校验和发生了变化

D 表示设备节点的属性发生了变化

L 表示文件的符号链接发生了变化

U 表示文件/子目录/设备节点的owner发生了变化

G 表示文件/子目录/设备节点的group发生了变化

T 表示文件最后一次的修改时间发生了变化

如果在输出结果中有“M”标记出现，那么对应的文件可能已经遭到篡改或替换，此时可以通过卸载这个rpm包重新安装来清除受攻击的文件。

不过这个命令有个局限性，那就是只能检查通过rpm包方式安装的所有文件，对于通过非rpm包方式安装的文件就无能为力了。同时，如果rpm工具也遭到替换，就不能通过这个方法了，此时可以从正常的系统上复制一个rpm工具进行检测。

;

---