我们虚构的应用将是每天24小时一直在线。在流量上将会有浪涌和波峰，随着美国的东西海岸起床时间不同，每天会有两次波峰。而且我们的波峰足够高，从而能够在平缓期进行维护操作，但不能停机，只能减少容量来做这些维护操作。停机会直接影响系统底线。将来，我们会扩展到欧洲和亚洲，从而停机就更不可行了。会有季节性的高流量，在某些流行网站的首页也可能会提到我们，从而导致流量骤增。没关系一一我们可以将功能降级，而不是垮掉。
数据库的读操作将占95%，而写占5%。多数写操作都是单行的，会有一些复杂查询。这些查询会非常耗时，为了提高效率，不得不把一些汇总预先计算出来，或对某些数据做非规范化处理，这将是一个非非常耗CPU的过程。我们将把这些耗时的分析工作的成本分推到整天，这样一来，所用的数据会稍微有些过时。有日时候使用这些过时的数据是没问题的，而有的时候，我们不得不在一天之内对数据进行逐步的增量更新。
数据库模式的问题还没有解决；应用还没有成熟，正在快速开发中，包括数据库模式也在不断变化。结果就是必须进行在线部署。从而不得不在生产环境中运行 ALTER TABLE，作为更新数据库模式的例行手段，而且还不能影响可用性。我们知道数据会越来越大，而ALTER花费的时间也会越来越长，以至于长到无法忍受。
持续增长的负载会超过单台服务器的能力。能走多远并不重要，因为只有三个数:零、1和多。无论如何，我们都不认为应用会增长到互联网的规模，所以我们会考虑几台到几十台之间的情况。
在一定范围内的数据丢失是可以接受的。如果一台服务器消失了一段时间，将会损失一小笔钱，但将会无颜面对管理机构。不管怎么说，我们还是强烈希望数据库服务器是高可用的，要求一年的容机时间加起来不要超过一天。因为，5分钟的宕机时间比损失5分钟的数据要昂贵得多。
为了灾难恢复的目的，我们要求数据库在最坏情况下能够恢复到昨天的数据，而在多数情况下，我们当然希望能够恢复到刚才的数据，使损失的数据不多于几秒钟。希望通常情况下恢复过程不要超过一小时，而在最坏情况，如损失大量的数据或服务器，则希望恢复时间不多于一天。
团队对数据库只有一般的能力，我们的团队实际上是 Ruby on Rails的专家，所以高级的数据库问题还是需要外部的帮助。系统管理团队也非常优秀，但同样不太擅长数据库。
记住这些，我们来看看如何满足这些需求。
易于成功的事情
开始研究特定的架构之前，我想指出一些需要计划划的事情，而不管最终的架构是什么：
● 要做的第一件事是增加缓存层。memcached非常好用，使用 memcached可以为数据库减轻太多的负载，不用它简直太蠢了。
● 不要让用户产生异常情况，如有10000个好友，或者1000张.照片。对于你认为成本昂贵的那些关键区域，要限制规模，不要允许无限制的增长，就可以将事情保持在合理的范围内，而不会等到出现问题时，再向那些导致异常的人发火。防患于未然，就不会出现令人惊讶的事情，从而也就构成了良好的用户体验的一部分。
● 对待需求要小心，不要将自己的网站建设标准立得高于用户的期望，不要为应用构建太昂贵的功能。显示搜索结果的精确数量，以及精确的搜索结果页面，就是一个经典的错误。Google不这样做，所以你也不需要这样做。
本文地址：//www.xrqsnxx.com//article/3318.html
