共计 1729 个字符，预计需要花费 5 分钟才能阅读完成。
这期内容当中丸趣 TV 小编将会给大家带来有关如何进行数据库的架构整体分析，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。
很少谈架构方面的事情，主要是因为这确实是个对知识面和知识深度要求很高的领域，无论是开发语言的选择、代码的架构，服务器的搭配、网络的架构、数据库的架构还是第三方软件的选用等，每一方面都是个很大的方向，每个方向都值得一个人去研究一辈子；每每看到某某网站的首席架构师之类的人（不过很多是海绵派），总觉得那就是乐于做技术的人的终极目标，总是有种崇拜感。
限于工作和知识的局限性，以及抱着对各位朋友负责的态度，本文谈论的架构仅限于数据库方面，而且是基于 SQLserver 数据库来谈的，以免误导各位。
SQLServer
SQLServer 经过这些年的发展，其实已经有很多很好的技术可以使用，如 Replication、SSB、Cluster、Mirroring 等（可以参考我在 SQLServerDBA 三十问和 SQLServer 高可用、高性能和高保护延伸中的一些技术方面的知识），而且这些技术在可靠性方面已经通过了市场的认可，有很多公司在为提高其程序的可靠性、安全性和高效性等方面或多或少的采用了其中的某些技术，以下就我接触过的这些技术方面的应用，主要针对网站这种流量很大，读多写少的应用，就数据库架构方面做些探讨，希望对各位有所帮助，如有不对的地方，欢迎大家指正和交流。
数据库架构需要考虑的问题：
数据可靠和一致性；
数据容灾；
当数据量和访问压力变大时，方便扩充；
高度可用，出问题时能及时恢复，无单点故障；
不应因为某一台机器出现问题，导致整网性能的急剧下降；
方便维护；
关于下面架构的说明：
核心服务器采用 Cluster，还采用了 SSD 做磁盘阵列（SSD 可存放索引等数据）；
核心服务器的数据变更通过 SSB，分发到两台 Replication 的主机中（这一步可以先对数据进行粗加工，加工成方便用户查询的数据形式，然后再通过 SSB 包装后分发），使用了两台 SSB 分发机，既可以分担压力，也可以实现无单点故障；SSB 可用保证核心库的数据和 Replication 主机数据一致；当然这一步也可以直接使用 Replication 来实现，但对核心服务器的压力会有所增加；
接下来将 Replication 主机的数据通过分发服务器分别分发到三台订阅机，也就是 QUERYDB 服务器；
六台 QUERYDB 通过 F5 控制访问，同时在前段加了台 MemoryCache 的服务器，增加缓存，减少查询的压力（这一部分很多公司使用了搜索引擎方面的技术，将数据库中的数据生成 XML 文件，再通过索引文件来查找数据）；
B3 和 B4 两台 SSB 的作用是做 QUERYDB 到核心服务器的 SSB 消息转发，SSB 消息既能从 QUERYDB 发送到核心服务器，同时也能从核心服务器发送到 QUERYDB；这样有啥用呢？用处大了，因为核心服务器只有一台，我们如果把网站的所有操作都集中到核心服务器处理，那在业务高峰时期，数据变更非常频繁，核心服务器压力必定非常大，很可能抗不住，为预防这样的问题，我们势必要把部分压力分担出去，于是我们可以在用户做注册、下单等操作时，先将操作放到 QUERYDB 中，再通过 SSB 把消息发送给核心服务器，核心服务器接受到 SSB 消息后，会先放到队列中，然后一个个处理，这样核心服务器就不会因为同时处理过多的请求，而产生当机的风险，同时核心服务器处理完信息后，会将这些数据的变动通过 Replication 分发到每台 QUERYDB 中去，这样 QUERYDB 的数据还是会和核心服务器保持一致，实现了通过 QUERYDB 来记录操作，然后运用 SSB 技术来分压的效果；因为 QUERYDB 有六台（还可以扩展），QUERYDB 上 SSB 压力都分散了，所以也不会给 QUERYDB 带来很大的压力（可能消息会有小的延时，应该尽量在 SSB 通道上使用光纤网络）；即便核心服务器当机了，还是可以进行查询数据、注册和下订单等操作，SSB 会一直保留消息。
上述就是丸趣 TV 小编为大家分享的如何进行数据库的架构整体分析了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注丸趣 TV 行业资讯频道。
