三种登录模型：单数据库方案(左)、增加应用服务器的方案(中)、增加数据镜像的方案(右)第一种是传统的单数据库方案。第二种是登录服务逻辑过大导致应用服务器资源紧张，同时数据库压力不大时，通过部署应用服务来提升系统整体处理能力的方案。

第三种则是在第二种的基础上用以应付数据库压力的典型措施，即传统的数据库镜像方案。

几乎所有的大型数据库系统/产品，以及流行的开源数据库解决方案都提供了数据库后台镜像的能力，通常也提供增量镜像服务。这些系统以及这一典型解决方案事实上工作得很好，但是它也同时带来了大量的存储开销，并且不恰当地为“构建以单一数据库中心为基础”的系统提供了支持。

源于“单一数据库”的数据在总量上的变化，使得我们从传统的“集中式”向“复制式"发展变得越来越不可取。而另一种途径，即从“集中式”向“分割式”过渡的方案开始渐行渐显，也就是所谓的分表分库，

其中，最下层“(总)用户数据库”是一种出于安全性考虑的可选策略。分表分库决定了登录服务与各个子数据库之间存在某种强关系，例如：□采用同一的分布策略；□使用规则化的方法将分布策略写入到应用端(登录服务)的数据存储逻辑；□通过较大的存储过程来将应用端的请求转化为多个表之间的关联查询。

这种强关系带来了更大的系统架构负担，也就是说，我们必须在(包含上述三种方案在内的)多种方案中权衡。但无论如何权衡，都涉及在应用或数据库的逻辑层上的设计，以及由此带来的、不可控的开发规模。yipindushu.com

反思这些变化背后的某些关联，“单一数据库”越来越明显地成为大系统灾难之源。而这是源于早期数据库应用(例如基于数据的三层解决方案)所带来的惯性思维。在我们面临的现实系统中，数据的性质在四个方面几乎在同时发生变化：其一，数据的碎片化和即时性；其二，数据向非结构化发展的趋势明显；其三，数据项次的量级，即数据笔数，随即时性以及系统处理能力的增强而快速增长；其四，数据与关联数据的不对等及其总量的规模化，例如一条微博可能附带一个视频文件。

这些数据性质的变化迫使我们在“数据库”之外寻求解决方案。其中，相对重要的原因是，数据库维护中对于“数据结构化”的要求以及实施基于数据库分布方案的代价，两者总的来说与重建一个数据存储系统基本相同。以上述的第四种情况为例，如果我们以前面提到的数据库方案来存储微博，那么附带视频文件的管理就要求对数据库存储与文件存储作统一设计；而当我们采用“镜像数据库”或“镜像文件存储”的方案来解决系统压力时，前端的内容管理与存取接口，乃至于系统整体就几乎要重新设计一番了。

当我们的思考不再局限于“数据库”时，“将数据作为一个系统结点”的思维方式开始走向前台，

在这样的系统模型中，登录服务与其他种种服务并列在应用层，它们与“数据结点"一样作为可部署对象参与系统规划①。在这一模型中，系统的分布与并发策略建立在结点之间的PD-IO关系之上，而“备1,…,备n”这样的数据镜像，就只是出于对数据安全性的考量，而非是应付IO压力的临时策略了。

【九】

在这样的视角下，我们将越来越趋向于对系统的可组织性与组织方式的观察。以一个实际的、传统的系统架构为例：对于整个系统,可以简单地描述为对“逻辑、数据及其交错关系”的求解。例如我们将上述模型中的“P-D关系”理解为某种数据层的提供方案，则可以得到的模型：①这样的思维框架是将所有的可部署对象作为结点，而并非唯只是数据结点。