下面的数据库架构，以我的经验，是比拟有把握的。

单主办事器，多从办事器。

对于重要是读操作的运用，传统的伸缩办法是对数据进行复制一一有的时刻是多个复制这时刻的伸缩可以很好地工作。应用复制从办事器分管主办事器的负载，并在从办事器上履行那些CPU耗时的操作。

对于从办事器，要比你履行例交运维义务所须要的数目要多加一台，将这台办事器用于特定义务。从这台办事器上做备份，然后再将备份恢复归去，测试看有没有问题。在这台办事器上运行耗时的cron功课，以对数据进行汇总，将这些汇总数据用于数据剖析的查询，然后将成果导出，再批量导人到主办事器。应用基于会话的读写分别策略，以分管主办事器的SELECT查询。这些工作要在运用法式性命周期的早期就开端做。假如一台从办事器掉效了，将这台从办事器的工作转到另一台从办事器即可，因为从办事器之间并没有什么差别。对这种简略的掉效转移，可以应用各类负载平衡器来实现。

固然这种架构很好，但仍然存在一些令人头痛的问题:不轻易实现离线的数据库模式更新，因为平日数据库模式更新是在主办事器上完成的，在更新时会壅塞对正在进行更新的表的拜访。而在ALTERTABLE敕令复制到从办事器上时，复制可能会延迟，如许所分管的主办事器负载的数据就会过时或延迟。这种主-从架构很难主动实现主办事器的故障转移，因为主办事器和从办事器的设置装备摆设是纷歧样的，所以，一旦主办事器掉效，则必需手工进行掉效转移。不外，这种单一故障点现实上并不那么软弱，跟着从办事器越来越多，从办事器的掉效会比主办事器的掉效更为常见。

主办事器一主办事器复制，外加从办事器。

这种方法现实上与ー台主办事器加多台从办事器的架构一样，但这时刻主办事器自己也成为了从办事器。这种架构的重要长处是，在协同同的主办事器之间更轻易实现掉效转移和掉效转回。这解决了那些令人头痛的问题，如在线更新数据库模式。重要的缺陷是，向两台主办事器进行写人存在风险，会导致数据存在某种纷歧致性，这种纷歧致很难防备，涌现了纷歧致也很难解决。除非你特殊当心，并应用特权级别进行限制，不然，的确就是等待着导致这种纷歧致的毛病的产生。

功效分区。

跟着运用的增加，这却是个好主张。将运用中成本最高的那些部门移到特定的办事器或特定办事器的集群上，例如，将会话存储从主办事器上分别。我经常看到“会话”表吃失落了与其感化不成比例例的年夜量时光。为剖析查询别的树立一个集群，假如须要的话，应用同样的导出导人策略，将汇总成果导入主运用法式集群。将Sphinx或Solr集群用于搜刮。时光以及测量对象会告知你，运用中哪些部门的成本最高，假如预先不清晰，则造成延迟的那部门就是了。这种架构对运用的支撑会比拟久长。

除了前面列出的有把握的架构之外，我想下面的建议更有把握。同任何工作一样，一旦你懂得了规矩，就会经常发明规矩被损坏的情形，但我以为，除非有很好的来由，不然，这些设法主意不该该被丢弃。

掉效转移和负载平衡。

应用负载平衡器，或者浮动的虚拟P地址。就像你知道的，掉效转移是很难实现的。假如有高等的负载平衡器，就用上，或者应用对等的解决计划，即在办事器之间转移IP地址，假如做得适合的话，这种计划很好，并且也不贵。

不消应用DNS或运用法式逻辑。一开端似乎很合理，但立时就会酿成梦魇。应用DNS查询P地址是没问题的，但不要应用DNS去实现掉效转移。换言之，将DNS作为静态的体系看待，不要依附于更新DNS、设置装备摆设文件、运用法式中的代码或诸如斯类的任何器械。

不要主动化得太多，只读办事器很轻易实现掉效转移，而可写的办事器就可贵多。不要试图构建主动化的掉效转移。有些工作应当由人来完成。清晨3点被唤醒做掉效转移，总比6点的时刻被唤醒，然后在接下来的3天没日没夜地试图恢复数据，要好得多。

ACID仍然是有意义的。

从一开端就应用全事务型体系。非事务型体系的假设可能已经深深地植入了运用法式的代码中，很难查找与解决了。尔后期再切换为事务型体系，会导致许多麻烦，如逝世锁、锁期待超时，以及其他预想不到的行动。

高可用性请求快速而靠得住的灾害恢复，所以在MYSQL中，要应用INNODB作为存储引擎，但不要用外键、触发器、视图或存储进程，因为这些器械会导致复制问题、机能问题、备份以及其他许多问题。不要将MYISAM用于读写数据，因为会导致灾害，而恢复起来则须要相当长的时光。

应用准确的对象。

对每颗钉子来说，数据库都可能成为锤子。这可不是个好主张。不要使数据库处于症结路径上，如不要将其用于队列(队列不克不及很好地映射到数据库中，并且也是我看到的最常见的麻烦之一)。不要将运用法式的静态信息放入数据库中，如设置装备摆设信息、可以放人缓存或运用法式代码中的静态查找信息、存储映像。数据库应当存储数据，而非运用法式自己。

将数据库简略化，因为这是最难于伸缩，也是最昂贵的资本。尽可能应用文件和cron功课。例如，在存入数据库之前，将数据预先辈行汇总。用简略的剧本或GNU敕令行对象

做汇总，比用网站扶植数据库快几个数目级!要细心研讨UNIX的焦点对象，如sed、awk、sort和unqo这种做法，扈从Oracle或SQLServerl的世界中学到的做法比起来，的确就是对着干。在Oracle或SQLServer的世界中，运用法式只是一种树立在年夜范围的数据库之上的表示逻辑，而数据库充斥了表、视图、触发器、存储进程以及每一项渺小的营业逻辑。对于庞杂的营业运用，这种集中化的做法有时刻是适合的，并且我本身就在如许的情况中工作过。然则，对于Web运用，我照样保持我的不雅点:分别运用法式和数据库，将数据库仅用来存储和检索数据。