日期:2014-05-17  浏览次数:20466 次

sql2005 负载问题
数据库为:sql2005
我们数据库的主要操作是验证注册码,卡的数量是不断上升的,而且每张卡每分钟可能会去验证多次,验证完成后,可能需要修改这张卡的信息。

现在单个数据库遇到瓶颈了,想多增服务器,请问我要用到什么技术,有什么好的解决办法?

我在网上看了关于sql2005 数据同步多服务器的技术,一台发布服务器,多台订阅服务器,可以实现数据同步。
多台服务器分流验证,这样就会导致订阅服务器也要修改数据,似乎不符合。

请问我应该怎么做?
sql2005 数据库负载均衡

------解决方案--------------------
可以在一台发布服务器上去修改数据,而验证主要是查询数据,这个可以在订阅服务器上去查询
------解决方案--------------------
mark 很好很实际的问题!说不定哪天就碰到类似问题了。
你说的订阅发布我觉得应该是属于高可用性的范畴,应该不是性能负载平衡方面的。
------解决方案--------------------
一般的数据库复制技术,主要是实现读写分离的,往往是一台写,多台读
------解决方案--------------------
你的需求应该考虑将库拆分到多个服务器,上层通过自定义路由表来判断到哪台数据库服务器去验证数据。
------解决方案--------------------
一般的数据库复制技术,主要是实现读写分离的,往往是一台写,多台读 
------解决方案--------------------
我觉得可以考虑一下分布式计算,或者合并复制,主要思路还是把负载分摊到多台机器上
------解决方案--------------------
可以根据逻辑关系分拆啊,比如分成A,B,C,D库,不同的库对应不同的卡号区间。
------解决方案--------------------
可以在一台发布服务器上去修改数据,验证主要是查询数据
------解决方案--------------------
我先假想一下你们的业务模式,再按我假想的模式提出解决方案。
假设你们的业务流程是 内部开通可用卡号--用户持凭证验证卡号--更新卡片状态

这时如果你们被卡号无限增加的问题困扰,最应该做的是把大部分验证完的卡号放到其它的表或库中,从而保证可用卡号的数量被控制在某个能接受的范围内。

具体的实现可以用程序代码或作业完成,只要有足够的存储和合理的流转策略,性能不会是问题。
------解决方案--------------------
在做决定之前,先详细了解你所处的环境。
1、现在有多少卡,
2、注册码多次验证,平均每张注册卡验证多少次?
3、卡不断增长,每次增长范围是多少?
4、服务器真的存在瓶颈,瓶颈在哪里?CPU?内存?IO?
5、普通手段:T-SQL语句优化,索引优化,表分区,这些有没有尝试去做过?是否有效果?

最后才是硬件优化。
------解决方案--------------------
引用:
Quote: 引用:

我先假想一下你们的业务模式,再按我假想的模式提出解决方案。
假设你们的业务流程是 内部开通可用卡号--用户持凭证验证卡号--更新卡片状态

这时如果你们被卡号无限增加的问题困扰,最应该做的是把大部分验证完的卡号放到其它的表或库中,从而保证可用卡号的数量被控制在某个能接受的范围内。

具体的实现可以用程序代码或作业完成,只要有足够的存储和合理的流转策略,性能不会是问题。


我们有这个处理,卡过期后,用户可以清理过期注册码,清理后,转移到另外一张日志表。
主要的瓶颈是用户验证太频繁了,1分钟之内1张卡可以有多次验证。


验证主要是查询? 有多少是会修改的呢?
------解决方案--------------------
引用:
Quote: 引用:

可以根据逻辑关系分拆啊,比如分成A,B,C,D库,不同的库对应不同的卡号区间。


 

我本地测试了下复制订阅,发布服务器修改数据后,要大概3、4秒中后订阅服务器的数据才会更新。本地没有跑任何程序,为什么数据会滞后这么久


在那个计划中是,选的是每1秒,就复制不
------解决方案--------------------
因为我昨天也配置了一个同步和订阅,里面的复制间隔最小是每1秒,不知道你是不是选择了这个设置呢

因为你说你的服务器上没有跑程序,照理应该是马上就能同步过去的,昨天我设置的是1分钟间隔,基本上插入数据后,马上查询订阅服务器,数据就通不过去了