详析邮件服务器邮件存储和日志

本文以数据库的基本原理为基础，分析了exchange server的存储系统，并说明了各部分的作用。

一、is服务和ese的层次关系

is服务是exchange服务器中重要的服务之一，它控制着对邮箱和pf的存储操作请求，exchange服务器的存储实际上是由ese的数据库引擎来管理的。这个ese引擎是微软专门为保存非关系型数据而开发的，目前在微软的很多产品中都有广泛的应用，如：ad数据库、dhcp、wins、srs等等。

exchange的数据库是由edb文件、stm文件和log文件组成。在这些文件里，微软使用了“b+树”的内部数据结构。ese的引擎的任务之一，就是当is服务请求访问数据库的时候，把这些请求转化为对内部数据结构的读写访问。b+树的特点是能够对存储在硬盘上的数据提供快速访问能力。微软利用“b+树”作为ese的后台结构的主要原因，就是尽可能的提高访问数据时i/o性能。当然，这些结构对于exchange store来说是透明的。

另外，作为一个数据库系统，ese有责任提供事务级别的操作的支持，并维护数据库的完整性和一致性。对数据库系统而言，我们提到事务时，一般用acid来描述事务的特点。

a--atomic（原子的）：事务必须是全或全无的操作，要么全部成功更新，要么全部不被更新c--consistent（一致的）：一个成功提交的事务必须使数据库处于一个一致的状态。

i--isolated（孤立的）：所有未提交的更改都必须能够和其他事务孤立。

d--durable（持久的）：当事务一旦提交，所做的更改必须存储到稳定的介质上，防止系统失败导致的数据库不一致。（此点非常重要！！）

二、exchange 2000/2003存储系统的新特点

在ex5.5中，ese的版本为ese97，而在ex2000/2003里，ese版本已经升级ese98了。ese 引起在以下方面得到了改进：

* i/o性能进一步提高和优化

* 对日志文件增加了计算校验操作

* 提高了eseutil等工具的维护速度

而is也在以下方面有了更新：

* 在每个server上提供多个sg支持

* 数据库stm文件格式的引入，提高了internet邮件的性能

* wss的引入，用户可以使用多种协议访问数据库

三、edb和stm的关系

常有人问，edb文件是数据库，那stm文件是做什么用的？可以删除吗？

在ex5.5里，只有edb文件，因为在ex5.5发布时，微软主推的是内部邮件系统，因此其主要协议为mapi，这是微软的私有邮件西医，edb文件是专门为此协议优化过的。因此在ex5.5中，为了支持internet邮件，必须在每次处理internet邮件时，做一个格式转换。这显然带来了性能的损失。

在ex2000里，微软加大了对internet邮件的支持，这就是stm文件的来源。mapi格式是rpc 和二进制标准的，而stm是纯文本加上一些mime编码格式，这样的区别使得它们不可能存储在同一数据库里。因此ex2000中，微软开始使用edb和stm两个文件来分别保存两种格式的邮件。并且在两个文件之间建立了引用和关联。对于用户来说，它的邮箱实际上是跨越了edb 和stm文件共同组成的。另外，需要注意的是，edb文件中还保留着用户的邮箱结构。所以edb文件更加重要。那么edb和stm是怎么协同工作的呢？我们以几个情景来分析之。

情景一：用户使用outlook（mapi）发送接收邮件

在该情景下，用户将邮件通过mapi协议提交给数据库，直接被保存edb文件中。当用户通过mapi访问邮箱里的邮件时，如果被访问的邮件在edb里，直接返回，如果在stm里（如外来

邮件），则执行转换，将stm转换为edb文件格式，再返回用户。

情景二：用户使用标准smtp/pop3/imap4等协议访问

用户使用非mapi协议提交的邮件，内容保存在stm文件里，但是由于edb里有邮箱结构，stm 没有，因此系统会把邮件的重要信息提取出来，放在edb里。当用户用mapi提取邮件时，过程同上，当用户通过标准协议访问时，同样需要进行格式转换，转换为stm文件格式返回。这些转换是在后台发生的。对用户来说是透明的。通过上面的描述，你会看到，这两个文件是紧密联系的缺一不可。所以，在任何时间我们都不要单独操作这两个文件，它们是一个整体。同时也要注意的是，无论用户使用何方式访问邮箱，都需要向edb文件请求邮箱结构信息，这是需要注意的。

四、log文件的重大作用

在论坛里经常会看到有人说我的硬盘怎么很快就没了，一看原来是日志文件搞的鬼，于是就有人删除日志文件，甚至使用循环日志来强制减少日志，甚至有人提出这样的疑问，日志到底有什么用？是不是多余的？那我们来看看日志的重大作用。

对于一个sg来说，系统会产生一系列的日志，这些日志的扩展名为log，前缀一般是e00、e01……除了这些连续的日志文件外，还有一些特殊的日志文件（res1.log,res2.log,e0x.chk））），它们又有什么用呢？我们的管理员通常不喜欢备份这一操作，因此对这些日志是痛恨不已啊。那么微软在exchange数据库系统中引入日志的作用难道真的是多此一举吗？我们从以下几个方面来考察一下日志的作用：

1、作为一个企业级的邮件系统，必须要保证数据安全和完整。必须能够面对随时可能发生的意外灾难，把数据损失降低到最小。

2、必须提供高性能的邮件处理能力，对数据库中的邮件的事务操作在完成后必须马上（或是说立即）被记录在存储介质上（见前面的事务持久性说明）

3、灾难发生后，使用数据库备份恢复必须要返回到灾难发生前一刻的数据库状态（这是至关重要的！！）

现在我们来更进一步的看一下，当用户要修改邮箱中的内容时，被修改的内容首先被提取出来放到内存中，实际的修改是发生在内存里的，这是众所周知的，当修改完成后，这些内容必须被尽快写回存储介质，这样才表示一个事务成功完成了。

从事务的描述中我们可以看到，事务是具有原子特性的，为了保证数据库的一致和完整，事务必须全部成功或全部失败，如果事务失败，则必须回滚到事务开始的状态。而当邮件在内存中修改完成后，此时事务并没有完成（为什么呢？）因为一旦系统崩溃，这些修改就丢失了。所以要确保事务修改完成，必须尽快将修改写回到数据库里去（也就是硬盘上）。这也是事务的持久性要求。注意，我们这里说的第一时间或是尽快，是一个什么样的概念。如果我们直接修改edb文件，由于edb文件比较大，那么在硬盘上修改一个大文件，就需要花费大量的时间在等待和寻找数据存储块上（见操作系统原理），当系统出现高负载的繁忙状态时，这将是一个非常大的瓶颈。也就无法做到“尽快”了。那怎么办呢？所以数据库系统使用了日志，而日志通常很小（exchange的日志只有5mb），向这些文件写入修改结果是很快速的，因此当内存的修改完成后，这些结果就会立即写入日志中，以保证了事务的持久性。当成功写入日志后，该事务就成功完成了（现在在硬盘上了，不会因为当机丢失了）接下来，ese 引擎会在后台慢慢将这些日志里的修改记录写回真正的数据库里去（这对用户来说已经不是那么重要了），这就是日志的第一个作用：确保事务在第一时间（尽可能快的）保存到非易失存储器上（提供了事务持久性支持）。

根据上面的藐视，我们看到运行中的exchange数据库，是由三个部分组成的：

* 内存中已经完成处理还没有写会到日志里的内容（dirt page）

* 还没有写到数据库文件里的日志内容