如何让SQL Server支持高并发环境

zenny

跟我以前做过的一个商用房地产网站类似。 我来从系统架构简单谈一下吧。
一共有四台ＳＱＬ　ＳＥＲＶＥＲ，　7台只读，　一台读写。　每天做ｒｅｐｌｉｃａｔｉｏｎ，　另外有dedicated distributor 一台，  在解决ｒｅｐｌｉｃａｔｉｏｎ　的时候，　我选用fusion IO 的解决方案， 我们以前做replication ， 需要7个小时， 现在只需要40分钟。

中间件是自己开发的 task dispatcher， 根据IP 分配 不同的servers， 东部四台， 西部四台。  可读写的在东部。

Peak time 7500 trans/sec.

lzyrj

luckyrandom 发表于 2012-9-12 11:44
不见得软件供应商、系统集成商、专业数据库服务商等等就很牛人，特别是对技术性的东西，毕竟多数在外抛头露 ...

：）有道理，当然也有很多人是从技术高手的身份转过去滴。
首先，“适当拉长促销的时间段，减少对系统的压力”绝对是解决问题的好思路，好方法。
其次，如果仅仅在数据库端考虑问题，这个有点偏颇，当然，文中也提到了“硬件，架构”
最后，SQL SERVER的性能还是很靠谱的，但是就算再难，碰到这种情况，还是要在整体架构（硬，软件）上做优化，但要注意的是，这样一来，原有的程序要经过相当的改动，带来了不好估量的风险。

lzyrj

kelsoncong 发表于 2012-9-12 11:48
是的，其实现在国内的技术水平已经很高了，PUB走出去的几个还是很厉害的。
欧洲那个专业的数据库服务商提 ...

恩，当初就是一个oracle高手推荐我到PUB的

guobaoguo163com

我感觉首先需要检查性能的瓶颈在哪里。如果是IO跟不上可以从以下几方面进行优化。
1、将读写多的数据表单建成独立的文件组。
2、增加磁盘以提高读写能力。

rattbell

markup

finalarrow

z2chen 发表于 2012-9-24 09:25
根据我做开发的经验，发现很多很多的问题其实都能用很少的资源就能完成，可惜大家写程序的时候都不愿花时间 ...

非常专业.

179485704

grantguan 发表于 2012-9-13 11:53
replication 其实是背后有agent 在运作，这个时间可以自己定义，大数据量不要说实时，每天一次都吃力，出 ...

1千多的并发，每张表大的有几十G，从来没发生过你所说的问题
请问下你用的是哪种方式的Replication?

grantguan

179485704 发表于 2013-1-9 16:28
1千多的并发，每张表大的有几十G，从来没发生过你所说的问题
请问下你用的是哪种方式的Replication?

开始用transactional publication, 后来听唐云先生说要用Snapshot publication，效果都不理想，你用的那种Replication?

kisshexuxia

楼主最后的总结呢

yantao_14

看完,结贴