同往常一样，你最好界说你的需求，特殊是，把那些超越你的规模从而成为别人的问题的内容写成文档。假如这一步搞清晰了，你就帮了每小我的年夜忙。你对详谁应当解决问题决议得越快，则谁人工资解决问题而做的预算和筹划也就越快。所以，让我们例建一个设想的Web运用作为示例，非正式地把需求列出来。

我们虚构的运用将是天天24小时一向在线。在流量大将会有浪涌和波峰，跟着美国的器械海岸起床时光分歧，天天会有两次波峰。并且我们的波峰足够高，从而可以或许在平缓期进行保护操作，但不克不及停机，只能削减容量来做这些保护操作。停机遇直接影响体系底线。未来，我们会扩大到欧洲和亚洲，从而停机就更弗成行了。会有季候性的高流量，在某些风行网站的首页也可能会提到我们，从而导致流量骤增。没紧要一一我们可以将功效降级，而不是垮失落。

数据库的读操作将占95%，而写占5%。多半写操作都是单行的，会有一些庞杂查询。这些查询会异常耗时，为了进步效力，不得不把一些汇总预先盘算出来，或对某些数据做非规范化处置，这将是一个非异常耗CPU的进程。我们将把这些耗时的剖析工作的成天职推到成天，如许一来，所用的数据会稍微有些过时。有日时刻应用这些过时的数据是没问题的，而有的时刻，我们不得不在一天之内对数据进行慢慢的增量更新。

数据库模式的问题还没有解决；运用还没有成熟，正在快速开辟中，包含数据库模式也在赓续变更。成果就是必需进行在线安排。从而不得不在临盆情况中运行ALTERTABLE，作为更新数据库模式的例行手腕，并且还不克不及影响可用性。我们知道数据会越来越年夜，而ALTER消费的时光也会越来越长，以至于长到无法忍耐。

连续增加的负载会跨越单台办事器的才能。能走多远并不主要，因为只有三个数:零、1和多。无论若何，我们都不以为运用会增加到互联网的范围，所以我们会斟酌几台到几十台之间的情形。

在必定规模内的数据丧失是可以接收的。假如一台办事器消逝了一段时光，将会丧失一小笔钱，但将会无颜面临治理机构。不管怎么说，我们照样强烈愿望数据库办事器是高可用的，请求一年的容机时光加起来不要跨越一天。因为，5分钟的宕机时光比丧失5分钟的数据要昂贵得多。

为了灾害恢复的目标，我们请求数据库在最坏情形下可以或许恢复到昨天的数据，而在多半情形下，我们当然愿望可以或许恢复到适才的数据，使丧失的数据不多于几秒钟。愿望平日情形下恢复进程不要跨越一小时，而在最坏情形，如丧失年夜量的数据或办事器，则愿望恢复时光不多于一天。

团队对数据库只有一般的才能，我们的团队现实上是RubyonRails的专家，所以高等的数据库问题照样须要外部的赞助。体系治理团队也异常优良，但同样不太善于数据库。

记住这些，我们来看看若何知足这些需求。

易于胜利的工作

开端研讨特定的架构之前，我想指出一些须要筹划划的工作，而不管最终的架构是什么：

● 要做的第一件事是增长缓存层。memcached异常好用，应用memcached可认为数据库减轻太多的负载，不消它的确太蠢了。

● 不要让用户发生异常情形，若有10000个石友，或者1000张.照片。对于你以为成本昂贵的那些症结区域，要限制范围，不要许可无穷制的增加，就可以将工作坚持在合理的规模内，而不会比及涌现问题时，再向那些导致异常的人发火。防患于未然，就不会涌现令人惊奇的工作，从而也就组成了优越的用户体验的一部门。

● 看待需求要当心，不要将本身的网站扶植尺度立得高于用户的期望，不要为运用构建太昂贵的功效。显示搜刮成果的准确数目，以及准确的搜刮成果页面，就是一个经典的毛病。Google不如许做，所以你也不须要如许做。