我今天,为什么会提出这个问题.因为在做过的项目中,有2个大项目,发现性能瓶颈都是出现在数据库上. 当然这瓶颈出现在数据库上,也有一部分原因是我们一些开发人员,在开发的时候,写的语句有一定的问题. 但除了这些外,我们也确实发现,数据库这一块是我们的瓶颈来的,我们的应用程序有用F5负载均衡,但数据库没有做负载均衡.因为微软的数据库并没有实现负载均衡,而用第三方的,也不是很放心.其实解决这个数据库瓶颈,也是有几个方面可做.
- 是使用缓存,把一些常用的,数据变化不大的数据放在缓存里面,这个我们当时在做优化的时候也有做,效果还是可以的.
- 是把数据库分到不同的服务器上.我们当时才用的是多数据库的方式.然而遗憾的是,我们当时做了很多夸库查询,主要是跟基础库的连接.所以这方案的实施成本会大很多.
- 是最原始的方法,就是增加服务器的配置了.
- 是进行读写分离,其实我觉的,这也是一个比较好的方案在解决sql server 数据库的负载均衡.而这方案的成本也是比较低廉的. 不过这东西需要在编程的时候,就要设置读和写的连接分开.
有关读写分离,其实我也没有真正的在实践中操作过,不知道哪位网友有类似的经验,跟大家分享一下,尤其在开发过程中配到过的问题,能跟大家分享一下,我只是通过查资料,得出我的读写分离方案.其中可能有什么错误的地方,也请各位网友,多多指教一下.我查了资料,查到的sql sever 的读写操作也有2种方案.
- 是,通过镜像技术,通过只读,访问AlwaysOn的辅助副本. 不过这方案会有延时,而且时间会比较大.对于这种方案,我感觉比较适合于对数据敏感度不高的报表.
- 是通过事务复制的技术来做,这个东西虽然也会有一定的延时,但总的来说延时很小,基本上是达到实时的.对于大部分场景都是适合的. 除非是非常敏感的数据.如访问量统计,签入迁出(这时候的对于数据的读和写的操作,都只能针对主数据库了).
因此只要我们在编程的时候,把读和写的连接分开,我们就可以在后期对数据库实施读写分离的操作了.
以上是我关于sql server 读写分离操作的一些理解,当然也是还没有实践过的,只是写出来,跟广大网友共同探讨一下.