sql2005 负载问题

[skystar100]

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

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

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

请问我应该怎么做？

[LongRui888]

引用 26 楼 skystar100 的回复:

[quote=引用 19 楼 guguda2008 的回复:] 我先假想一下你们的业务模式，再按我假想的模式提出解决方案。 假设你们的业务流程是 内部开通可用卡号--用户持凭证验证卡号--更新卡片状态 这时如果你们被卡号无限增加的问题困扰，最应该做的是把大部分验证完的卡号放到其它的表或库中，从而保证可用卡号的数量被控制在某个能接受的范围内。 具体的实现可以用程序代码或作业完成，只要有足够的存储和合理的流转策略，性能不会是问题。

我们有这个处理，卡过期后，用户可以清理过期注册码，清理后，转移到另外一张日志表。 主要的瓶颈是用户验证太频繁了，1分钟之内1张卡可以有多次验证。[/quote] 验证主要是查询？ 有多少是会修改的呢？

[The Big Short]

酱油10分

[skystar100]

引用 27 楼 yupeigu 的回复:

[quote=引用 26 楼 skystar100 的回复:] [quote=引用 19 楼 guguda2008 的回复:] 我先假想一下你们的业务模式，再按我假想的模式提出解决方案。 假设你们的业务流程是 内部开通可用卡号--用户持凭证验证卡号--更新卡片状态 这时如果你们被卡号无限增加的问题困扰，最应该做的是把大部分验证完的卡号放到其它的表或库中，从而保证可用卡号的数量被控制在某个能接受的范围内。 具体的实现可以用程序代码或作业完成，只要有足够的存储和合理的流转策略，性能不会是问题。

我们有这个处理，卡过期后，用户可以清理过期注册码，清理后，转移到另外一张日志表。 主要的瓶颈是用户验证太频繁了，1分钟之内1张卡可以有多次验证。[/quote] 验证主要是查询？ 有多少是会修改的呢？[/quote] 查询/修改=9/1 吧 我本地测试了下复制订阅，发布服务器修改数据后，要大概3、4秒中后订阅服务器的数据才会更新。本地没有跑任何程序，为什么数据会滞后这么久

[skystar100]

引用 14 楼 SmithLiu328 的回复:

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

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

[LongRui888]

引用 31 楼 skystar100 的回复:

[quote=引用 14 楼 SmithLiu328 的回复:] 可以根据逻辑关系分拆啊，比如分成A，B，C，D库，不同的库对应不同的卡号区间。

我本地测试了下复制订阅，发布服务器修改数据后，要大概3、4秒中后订阅服务器的数据才会更新。本地没有跑任何程序，为什么数据会滞后这么久[/quote] 在那个计划中是，选的是每1秒，就复制不

[LongRui888]

因为我昨天也配置了一个同步和订阅，里面的复制间隔最小是每1秒，不知道你是不是选择了这个设置呢 因为你说你的服务器上没有跑程序，照理应该是马上就能同步过去的，昨天我设置的是1分钟间隔，基本上插入数据后，马上查询订阅服务器，数据就通不过去了

[haitao]

多读一写，但是同步延时还是比较大的 看应用能否接受 或者按卡id分范围，不同id段的卡，引导到不同的服务器

[2534165940]

拿点积分,谢谢。

[haitao]

引用 41 楼 skystar100 的回复:

[quote=引用 35 楼 sz_haitao 的回复:] 多读一写，但是同步延时还是比较大的 看应用能否接受 或者按卡id分范围，不同id段的卡，引导到不同的服务器

延时不能接受，如果考虑根据ID段分数据库的话，不好管理，而且我也不知道这张卡是哪个ID段的，还是要去查询数据库，而且数据库出问题了也不知道[/quote] 刷得卡的id，就知道它属于哪个段（库、表）了 数据库出问题了也不知道？这个与分库无关了

[blackkettle]

继续围观中

[674464952]

看的不太明白，能不能具体一下。

[a413110291]

牛人牛人牛人

[nettman]

学习

[KevinLiu]

引用 31 楼 skystar100 的回复:

[quote=引用 14 楼 SmithLiu328 的回复:] 可以根据逻辑关系分拆啊，比如分成A，B，C，D库，不同的库对应不同的卡号区间。

我本地测试了下复制订阅，发布服务器修改数据后，要大概3、4秒中后订阅服务器的数据才会更新。本地没有跑任何程序，为什么数据会滞后这么久[/quote] 导致复制滞后的原因非常多，网络，IO，Blocking，VLS等等，建议参考MSDN的文章一步一步查原因。

[skystar100]

引用 19 楼 guguda2008 的回复:

我先假想一下你们的业务模式，再按我假想的模式提出解决方案。 假设你们的业务流程是 内部开通可用卡号--用户持凭证验证卡号--更新卡片状态 这时如果你们被卡号无限增加的问题困扰，最应该做的是把大部分验证完的卡号放到其它的表或库中，从而保证可用卡号的数量被控制在某个能接受的范围内。 具体的实现可以用程序代码或作业完成，只要有足够的存储和合理的流转策略，性能不会是问题。

卡在使用期间，一直在不停的验证，似乎不好把卡放到其他表中，而且卡过期之后是可以续费的

[skystar100]

引用 35 楼 sz_haitao 的回复:

多读一写，但是同步延时还是比较大的 看应用能否接受 或者按卡id分范围，不同id段的卡，引导到不同的服务器

第一种有延时就不考虑了； 第二种方法应该怎么做？我怎么知道一串卡密的ID是在哪个范围内？不还是要先查下数据表吗？

[skystar100]

引用 46 楼 SmithLiu328 的回复:

[quote=引用 31 楼 skystar100 的回复:] [quote=引用 14 楼 SmithLiu328 的回复:] 可以根据逻辑关系分拆啊，比如分成A，B，C，D库，不同的库对应不同的卡号区间。

我本地测试了下复制订阅，发布服务器修改数据后，要大概3、4秒中后订阅服务器的数据才会更新。本地没有跑任何程序，为什么数据会滞后这么久[/quote] 导致复制滞后的原因非常多，网络，IO，Blocking，VLS等等，建议参考MSDN的文章一步一步查原因。[/quote] 分库后，如果用户要查询他所有的卡，获取此用户的数据不是要去各个服务器调数据？

[haitao]

引用 49 楼 skystar100 的回复:

[quote=引用 35 楼 sz_haitao 的回复:] 多读一写，但是同步延时还是比较大的 看应用能否接受 或者按卡id分范围，不同id段的卡，引导到不同的服务器

第一种有延时就不考虑了； 第二种方法应该怎么做？我怎么知道一串卡密的ID是在哪个范围内？不还是要先查下数据表吗？[/quote] 卡密的ID？直接按id的 后2位 分表或分服务器，不行吗？

[我只是来偷代码的]

顶一下 楼主说得很好

[wangsufu77]