发布时间：2022-10-09 00:00   您所在的位置： 网站首页 > 新闻资讯 > 建站智库

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

单主服务器，多从服务器。

相对主要是读操作的应用，传统的伸缩方法是对数据开展复制一一有的时候是多个复制这时候的伸缩可以很好地工作。使用复制从服务器分担主服务器的负载，并在从服务器上执行那些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应用，我还是坚持我的观点:分离应用程序和数据库，将数据库仅用来存储和检索数据。

本文章由新概念互动原创，如没特殊注明，转载请注明来自：http://www.jianzhan0.com/zhiku/76733.html

上一篇：网站维护是事务最多的工作负荷

下一篇：有风险的架构是什么？