数据库架构

   很少谈架构方面的事情，主要是因为这确实是个对知识面和知识深度要求很高的领域，无论是开发语言的选择、代码的架构，服务器的搭配、网络的架构、数据库的架构还是第三方软件的选用等，每一方面都是个很大的方向，每个方向都值得一个人去研究一辈子；每每看到某某网站的首席架构师之类的人（不过很多是海绵派），总觉得那就是乐于做技术的人的终极目标，总是有种崇拜感。

 

   限于工作和知识的局限性，以及抱着对各位朋友负责的态度，本文谈论的架构仅限于数据库方面，而且是基于SQLserver数据库来谈的，以免误导各位。

 

   SQLServer经过这些年的发展，其实已经有很多很好的技术可以使用，如Replication、SSB、Cluster、Mirroring等（可以参考我在SQLServer DBA 三十问和SQLServer 高可用、高性能和高保护延伸 中的一些技术方面的知识），而且这些技术在可靠性方面已经通过了市场的认可，有很多公司在为提高其程序的可靠性、安全性和高效性等方面或多或少的采用了其中的某些技术，以下就我接触过的这些技术方面的应用，主要针对网站这种流量很大，读多写少的应用，就数据库架构方面做些探讨，希望对各位有所帮助，如有不对的地方，欢迎大家指正和交流。

 

数据库架构需要考虑的问题：

1. 数据可靠和一致性；
2. 数据容灾；
3. 当数据量和访问压力变大时，方便扩充；
4. 高度可用，出问题时能及时恢复，无单点故障；
5. 不应因为某一台机器出现问题，导致整网性能的急剧下降；
6. 方便维护；

 

关于下面架构的说明：

1. 核心服务器采用Cluster，还采用了SSD做磁盘阵列（SSD可存放索引等数据）；
2. 核心服务器的数据变更通过SSB，分发到两台Replication的主机中（这一步可以先对数据进行粗加工，加工成方便用户查询的数据形式，然后再通过SSB包装后分发），使用了两台SSB分发机，既可以分担压力，也可以实现无单点故障；SSB可用保证核心库的数据和Replication主机数据一致；当然这一步也可以直接使用Replication来实现，但对核心服务器的压力会有所增加；
3. 接下来将Replication主机的数据通过分发服务器分别分发到三台订阅机，也就是QUERYDB服务器；
4. 六台QUERYDB通过F5控制访问，同时在前段加了台MemoryCache的服务器，增加缓存，减少查询的压力（这一部分很多公司使用了搜索引擎方面的技术，将数据库中的数据生成XML文件，再通过索引文件来查找数据）；
5. B3和B4两台SSB的作用是做QUERYDB到核心服务器的SSB消息转发，SSB消息既能从QUERYDB发送到核心服务器，同时也能从核心服务器发送到QUERYDB；这样有啥用呢？用处大了，因为核心服务器只有一台，我们如果把网站的所有操作都集中到核心服务器处理，那在业务高峰时期，数据变更非常频繁，核心服务器压力必定非常大，很可能抗不住，为预防这样的问题，我们势必要把部分压力分担出去，于是我们可以在用户做注册、下单等操作时，先将操作放到QUERYDB中，再通过SSB把消息发送给核心服务器，核心服务器接受到SSB消息后，会先放到队列中，然后一个个处理，这样核心服务器就不会因为同时处理过多的请求，而产生当机的风险，同时核心服务器处理完信息后，会将这些数据的变动通过Replication分发到每台QUERYDB中去，这样QUERYDB的数据还是会和核心服务器保持一致，实现了通过QUERYDB来记录操作，然后运用SSB技术来分压的效果；因为QUERYDB有六台（还可以扩展），QUERYDB上SSB压力都分散了，所以也不会给QUERYDB带来很大的压力（可能消息会有小的延时，应该尽量在SSB通道上使用光纤网络）；即便核心服务器当机了，还是可以进行查询数据、注册和下订单等操作，SSB会一直保留消息。
6. 架构2是两个异地机房之间的架构，和架构1类似。