数据库架构小知识

　　不知道大家有没有发现，在IT中很多领域都有自己独特的架构，但是又不是每个人都能很好的理解它们各自的架构，因为这确实是个对知识面和知识深度要求很高的领域，无论是开发语言的选择、代码的架构，服务器的搭配、网络的架构、数据库的架构还是第三方软件的选用等，每一方面都是个很大的方向，每个方向都值得一个人去研究一辈子！下面小编就为大家讲一讲一点关于数据库架构的内容吧！

　　SQLServer经过这些年的发展，其实已经有很多很好的技术可以使用，如Replicatio、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会一直保留消息。

　　架构2是两个异地机房之间的架构，和架构1类似。

　　数据库架构一般从简单到复杂的过程：

　　1、一主一从

　　由一台主库和一台从库组成，从库只用作备份和容灾，当主库出现故障时，从库就手动变成主库

　　随着压力的增加，加上了memcached

　　2、一主多从

　　通过添加多个从库来分流查询压力

　　3、随着数据量的增加，读写压力都迅速增加，

　　进行数据库拆分，将数据存放到不同的数据库服务器中。

　　小编结语：

      以上就是小编对于数据库知识的一些总结！更多内容尽在课课家教育~~