什么是有把握的网站数据库架构？发布者：本站     时间：2019-11-01 14:11:21

下面的数据库架构，以我的经验，是比较有把握的。
 
单主服务器，多从服务器。

对于主要是读操作的应用，传统的伸缩方法是对数据进行复制一一有的时候是多个复制这时候的伸缩可以很好地工作。使用复制从服务器分担主服务器的负载，并在从服务器上执行那些CPU耗时的操作。

对于从服务器，要比你执行例行运维任务所需要的数量要多加一台，将这台服务器用于特定任务。从这台服务器上做备份，然后再将备份恢复回去，测试看有没有问题。在这台服务器上运行耗时的cron作业，以对数据进行汇总，将这些汇总数据用于数据分析的查询，然后将结果导出，再批量导人到主服务器。使用基于会话的读写分离策略，以分担主服务器的 SELECT查询。这些事情要在应用程序生命周期的早期就开始做。假如一台从服务器失效了，将这台从服务器的工作转到另一台从服务器即可，因为从服务器之间并没有什么区别。对这种简单的失效转移，可以使用各种负载均衡器来实现。



虽然这种架构很好，但仍然存在一些令人头痛的问题:不容易实现离线的数据库模式更新，因为通常数据库模式更新是在主服务器上完成的，在更新时会阻塞对正在进行更新的表的访问。而在 ALTER TABLE命令复制到从服务器上时，复制可能会延迟，这样所分担的主服务器负载的数据就会过期或延迟。这种主-从架构很难自动实现主服务器的故障转移，因为主服务器和从服务器的配置是不一样的，所以，一旦主服务器失效，则必须手工进行失效转移。不过，这种单一故障点实际上并不那么脆弱，随着从服务器越来越多，从服务器的失效会比主服务器的失效更为常见。

主服务器一主服务器复制，外加从服务器。

这种方式实际上与ー台主服务器加多台从服务器的架构一样，但这时候主服务器本身也成为了从服务器。这种架构的主要优点是，在协同同的主服务器之间更容易实现失效转移和失效转回。这解决了那些令人头痛的问题，如在线更新数据库模式。主要的缺点是，向两台主服务器进行写人存在风险，会导致数据存在某种不一致性，这种不一致很难防范，出现了不一致也很难解决。除非你特别小心，并使用特权级别进行限制，否则，简直就是期待着导致这种不一致的错误的发生。

功能分区。

随着应用的增长，这倒是个好主意。将应用中成本最高的那些部分移到特定的服务器或特定服务器的集群上，例如，将会话存储从主服务器上分离。我经常看到“会话”表吃掉了与其作用不成比例例的大量时间。为分析查询另外建立一个集群，如果需要的话，使用同样的导出导人策略，将汇总结果导入主应用程序集群。将 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或 SQL Serverl的世界中学到的做法比起来，简直就是对着干。在 Oracle或 SQL Server的世界中，应用程序只是一种建立在大规模的数据库之上的表现逻 辑，而数据库充满了表、视图、触发器、存储过程以及每一项细小的业务逻辑。对于复杂的业务应用，这种集中化的做法有时候是合适的，而且我自己就在这样的环境中工作过。但是，对于Web应用，我还是坚持我的观点:分离应用程序和数据库，将数据库仅用来存储和检索数据。