22,209
社区成员
发帖
与我相关
我的任务
分享设计难题:领导的方案和我的方案哪种更优?
[环境]
有多台高性能数据库服务器组成一个中央服务器集群,提供核心共享数据库,可以认为中央服务器是绝对安全的.另外有若干台数据库服务器供业务访问.
[业务流程介绍]
办理某业务时需要对信用额度进行检测和操作.各种业务对额度的访问频繁.大致流程如下:
业务服务器:提交单据时,判断信用额度减冻结额度是否大于0,大于0则增加冻结额度,信用额度余额不变,业务继续.小于0则禁止提交,中止操作.
中央服务器:单据确认成功时,判断信用额度余额是否足够,足够则取消提交时的额度冻结,即冻结额度减少,同时也扣除信用额度.额度不足则禁止确认,中止操作.
[目的]
现在做一个设计,保证对这些额度数据的高可用性和高性能.
方案A:
设计一个表,存在于中央服务器,有冻结额度和信用额度余额字段(当然还有其他基本信息).业务服务器对额度的操作都在这个集群上完成.数据流程同上文中介绍.
当一台业务服务器挂掉时,立刻切换到其他业务服务器操作.依然保持对额度信息的访问.
方案B:
分别设计一张信用额度表和一张冻结额度表.
信用额度余额表存在于中央服务器.冻结额度表存在于业务服务器.
为防止业务服务器挂掉而无法访问冻结额度.再增加一组业务服务器的备份服务器,用事务同步将所有业务服务器中的冻结额度实时备份至备份服务器.当业务服务器挂掉时,立即切换至其他业务服务器,并访问备用服务器的冻结额度信息.
关于备用服务器的另一个变招是,将所有业务服务器的冻结额度数据与备用服务器做合并同步,这样能减少问题的复杂度,但可能造成数据的延迟.
数据流程:
发生业务提交单据时,分别读取业务服务器上冻结额度与中央服务器信用额度,判断可用余额是否足够,若余额足够,则增加业务服务器上的冻结额度,若不够,则禁止操作.
当确认单据时,读取中央服务器的信用额度,若足够,则扣除额度,并且访问业务服务器,取消单据的冻结额度.若额度不足,则禁止操作.
文字比较多,简洁表达一下就是,方案A将冻结额度和信用额度存储在中央服务器,对冻结额度的更改和对信用额度的更改都在中央服务器上进行,实现简单,缺点是对冻结额度和信用额度的更改都在中央服务器,增加中央服务器压力.
而方案B是将冻结额度与信用额度分开存储.对冻结额度的更改只在业务服务器上进行,保证了冻结额度的高效访问,分解了了对额度的访问,也一定程度减少中央服务器压力.缺点是实现复杂,可能会有延迟和不可靠性,跨服务器操作有损性能.而且需要增加另一个备用服务器作实时同步.
提问:
1:到底哪种方案更合理呢?
2:是否有更优方案?
3:猜猜哪种方案是我的,哪种方案是领导的?
有多台高性能数据库服务器组成一个中央服务器集群,提供核心共享数据库,可以认为中央服务器是绝对安全的.另外有若干台数据库服务器供业务访问.
[业务流程介绍]
办理某业务时需要对信用额度进行检测和操作.各种业务对额度的访问频繁.大致流程如下:
业务服务器:提交单据时,判断信用额度减冻结额度是否大于0,大于0则增加冻结额度,信用额度余额不变,业务继续.小于0则禁止提交,中止操作.
中央服务器:单据确认成功时,判断信用额度余额是否足够,足够则取消提交时的额度冻结,即冻结额度减少,同时也扣除信用额度.额度不足则禁止确认,中止操作.
[目的]
现在做一个设计,保证对这些额度数据的高可用性和高性能.
方案A:
设计一个表,存在于中央服务器,有冻结额度和信用额度余额字段(当然还有其他基本信息).业务服务器对额度的操作都在这个集群上完成.数据流程同上文中介绍.
当一台业务服务器挂掉时,立刻切换到其他业务服务器操作.依然保持对额度信息的访问.
方案B:
分别设计一张信用额度表和一张冻结额度表.
信用额度余额表存在于中央服务器.冻结额度表存在于业务服务器.
为防止业务服务器挂掉而无法访问冻结额度.再增加一组业务服务器的备份服务器,用事务同步将所有业务服务器中的冻结额度实时备份至备份服务器.当业务服务器挂掉时,立即切换至其他业务服务器,并访问备用服务器的冻结额度信息.
关于备用服务器的另一个变招是,将所有业务服务器的冻结额度数据与备用服务器做合并同步,这样能减少问题的复杂度,但可能造成数据的延迟.
数据流程:
发生业务提交单据时,分别读取业务服务器上冻结额度与中央服务器信用额度,判断可用余额是否足够,若余额足够,则增加业务服务器上的冻结额度,若不够,则禁止操作.
当确认单据时,读取中央服务器的信用额度,若足够,则扣除额度,并且访问业务服务器,取消单据的冻结额度.若额度不足,则禁止操作.
文字比较多,简洁表达一下就是,方案A将冻结额度和信用额度存储在中央服务器,对冻结额度的更改和对信用额度的更改都在中央服务器上进行,实现简单,缺点是对冻结额度和信用额度的更改都在中央服务器,增加中央服务器压力.
而方案B是将冻结额度与信用额度分开存储.对冻结额度的更改只在业务服务器上进行,保证了冻结额度的高效访问,分解了了对额度的访问,也一定程度减少中央服务器压力.缺点是实现复杂,可能会有延迟和不可靠性,跨服务器操作有损性能.而且需要增加另一个备用服务器作实时同步.
提问:
1:到底哪种方案更合理呢?
2:是否有更优方案?
3:猜猜哪种方案是我的,哪种方案是领导的?
...全文
请发表友善的回复…
发表回复
zhouzhijian888 2012-09-04
- 打赏
- 举报
你的也可行 ， 但是还听领导的， 数据量 不大 ，安全的情况下，还是a ，你所想的比较全面，分摊压力问题在短期内不会出现。
fengxiaohan211 2012-09-04
- 打赏
- 举报
还是选了领导的啊
三断笛 2012-09-04
- 打赏
- 举报
[Quote=引用 16 楼 的回复:]
引用 15 楼 的回复:
当然是领导的，领导的永远是对的，相信我，兄弟
相对于领导,我更喜欢优秀的设计
[/Quote]
昨天领导定下方案了.
公布结果,顺便附上我给领导发的邮件分析.
太长了,进我博客查看:
http://blog.csdn.net/xxyj6450/article/details/7933399
引用 15 楼 的回复:
当然是领导的，领导的永远是对的，相信我，兄弟
相对于领导,我更喜欢优秀的设计
[/Quote]
昨天领导定下方案了.
公布结果,顺便附上我给领导发的邮件分析.
太长了,进我博客查看:
http://blog.csdn.net/xxyj6450/article/details/7933399
zhazhuzhao 2012-09-04
- 打赏
- 举报
访问量和更新量上面一看，A最合适；B无疑把实现成本、实施成本、维护成本都抬高了一截，而且用不上那么多并发的。
sql2015 2012-09-04
- 打赏
- 举报
方案B并发性高
三断笛 2012-09-03
- 打赏
- 举报
[Quote=引用 12 楼 的回复:]
楼主的集群是怎么配的，能达到什么样的效果？
事务同步将会有5-10s 的延迟。
个人建议第二种，但是可以第二种应该是 查询db
很多频繁的查询都用从机去判断。
减少主机的查询，主机同步到丛机，从机可以有很多。。
但是你这种连贯性的动作 不适合放在两台服务器上搞。同步本身石油延迟的。
[/Quote]
B方案中,冻结额度信息放在业务服务器,余额信息放在中央服务器.这个过程是不用事务同步的.只是业务服务器的备份是事务同步的,但做到了实时同步.不过多台业务服务器实时同步到一台备用服务器还是有难度的,这个是要想办法的.
楼主的集群是怎么配的，能达到什么样的效果？
事务同步将会有5-10s 的延迟。
个人建议第二种，但是可以第二种应该是 查询db
很多频繁的查询都用从机去判断。
减少主机的查询，主机同步到丛机，从机可以有很多。。
但是你这种连贯性的动作 不适合放在两台服务器上搞。同步本身石油延迟的。
[/Quote]
B方案中,冻结额度信息放在业务服务器,余额信息放在中央服务器.这个过程是不用事务同步的.只是业务服务器的备份是事务同步的,但做到了实时同步.不过多台业务服务器实时同步到一台备用服务器还是有难度的,这个是要想办法的.
三断笛 2012-09-03
- 打赏
- 举报
[Quote=引用 11 楼 的回复:]
信息严重不足哦，最重要的数据量和预算都没有说明
方案没有好坏之分，只有是否适合
数据量不大则方案a，预算不足则方案b
你估计方案b吧，技术人员往往少考虑预算
[/Quote]
好,多提供些数据.
目前这个额度的数据大约有2000行.每个店一行记录.但是随着业务扩展会有所增长,若干年后算1万吧.
现在的业务规模是算平均每天每店一单(不要笑,事实上还没有),随着业务发展,若干年后平均每天每店算10单吧.
不同方案读写数据库次数分析:
方案A:
1.提交时,业务服务器跨服务器读取1次中央服务器,取得冻结额度和信用额度,判断额度是否足够.
2.提交时,业务服务器向中央服务器跨服务器写入冻结额度1次.
3.确认时,中央服务器本地读取信用额度1次判断
4.再跨服务器写入冻结额度1次,和更新本地信用额度1次.
总计跨服务器写入2次,跨服务器读取1次,本地写入1次.本地读取1次,一共5次.
业务服务器发生故障时,中央服务器无需任何改动.业务服务器只需切换服务器即可.
方案B:
当冻结额度存储在业务服务器上,而信用额度存储在业务服务器上时,业务流程如下:
1.提交时,业务服务器本地读取冻结额度1次,跨服务器读取信用额度1次.以判断额度.
2.提交时,业务服务器本地写入冻结额度1次.以更新额度.
3.确认时,中央服务器本地读取信用额度1次,跨服务器读取冻结额度1次.
4.确认时,中央服务器本地写入信用额度1次,跨服务器写入冻结额度1次.
这里总计跨服务器写入1次,本地写入2次,跨服务器读取2次,本地读取2次,共计7次.
业务服务器发生故障时,业务立刻切换到其他服务器,同时从备用服务器取回数据,修改主服务器回写数据的接口,不再写回故障机器,转至新机器.
信息严重不足哦，最重要的数据量和预算都没有说明
方案没有好坏之分，只有是否适合
数据量不大则方案a，预算不足则方案b
你估计方案b吧，技术人员往往少考虑预算
[/Quote]
好,多提供些数据.
目前这个额度的数据大约有2000行.每个店一行记录.但是随着业务扩展会有所增长,若干年后算1万吧.
现在的业务规模是算平均每天每店一单(不要笑,事实上还没有),随着业务发展,若干年后平均每天每店算10单吧.
不同方案读写数据库次数分析:
方案A:
1.提交时,业务服务器跨服务器读取1次中央服务器,取得冻结额度和信用额度,判断额度是否足够.
2.提交时,业务服务器向中央服务器跨服务器写入冻结额度1次.
3.确认时,中央服务器本地读取信用额度1次判断
4.再跨服务器写入冻结额度1次,和更新本地信用额度1次.
总计跨服务器写入2次,跨服务器读取1次,本地写入1次.本地读取1次,一共5次.
业务服务器发生故障时,中央服务器无需任何改动.业务服务器只需切换服务器即可.
方案B:
当冻结额度存储在业务服务器上,而信用额度存储在业务服务器上时,业务流程如下:
1.提交时,业务服务器本地读取冻结额度1次,跨服务器读取信用额度1次.以判断额度.
2.提交时,业务服务器本地写入冻结额度1次.以更新额度.
3.确认时,中央服务器本地读取信用额度1次,跨服务器读取冻结额度1次.
4.确认时,中央服务器本地写入信用额度1次,跨服务器写入冻结额度1次.
这里总计跨服务器写入1次,本地写入2次,跨服务器读取2次,本地读取2次,共计7次.
业务服务器发生故障时,业务立刻切换到其他服务器,同时从备用服务器取回数据,修改主服务器回写数据的接口,不再写回故障机器,转至新机器.
三断笛 2012-09-03
- 打赏
- 举报
[Quote=引用 15 楼 的回复:]
当然是领导的，领导的永远是对的，相信我，兄弟
[/Quote]
相对于领导,我更喜欢优秀的设计
当然是领导的，领导的永远是对的，相信我，兄弟
[/Quote]
相对于领导,我更喜欢优秀的设计
zgxer 2012-09-03
- 打赏
- 举报
当然是领导的，领导的永远是对的，相信我，兄弟
三断笛 2012-09-02
- 打赏
- 举报
[Quote=引用 5 楼 的回复:]
中央服务器是绝对安全的？
包括负荷、性能肯定没问题？
那应该是A比较好
[/Quote]
必需保证中心服务器的高可用性.否则所有业务无法办理.
中央服务器是绝对安全的？
包括负荷、性能肯定没问题？
那应该是A比较好
[/Quote]
必需保证中心服务器的高可用性.否则所有业务无法办理.
haitao 2012-09-02
- 打赏
- 举报
中央服务器是绝对安全的？
包括负荷、性能肯定没问题？
那应该是A比较好
包括负荷、性能肯定没问题？
那应该是A比较好
發糞塗牆 2012-09-02
- 打赏
- 举报
[Quote=引用 3 楼 的回复:]
引用 2 楼 的回复:
我觉得方案B会比较好一点，因为你提到【访问频繁】，把压力分摊到下面的服务器会比较好一点。在判断时，对中央服务器顶多只是一个读操作，会减轻很多负担，判断完成后才到插入或者更新操作。
你这里的方案有点像发布/订阅功能。对于业务频繁的系统，这样能减轻负担。至于是谁的方案我就不猜了，对我没意义。
冻结额度和信用额度分分别存储在中央服务器和业务服务器,对信用额度的更……
[/Quote]具体业务我不了解，但是如果访问频繁的话，分摊负载是一个好事情。不要全部都放到一个服务器上就行了。而更新其实相对于查询来说，仅仅是小部分而已。
引用 2 楼 的回复:
我觉得方案B会比较好一点，因为你提到【访问频繁】，把压力分摊到下面的服务器会比较好一点。在判断时，对中央服务器顶多只是一个读操作，会减轻很多负担，判断完成后才到插入或者更新操作。
你这里的方案有点像发布/订阅功能。对于业务频繁的系统，这样能减轻负担。至于是谁的方案我就不猜了，对我没意义。
冻结额度和信用额度分分别存储在中央服务器和业务服务器,对信用额度的更……
[/Quote]具体业务我不了解，但是如果访问频繁的话，分摊负载是一个好事情。不要全部都放到一个服务器上就行了。而更新其实相对于查询来说，仅仅是小部分而已。
以学习为目的 2012-09-02
- 打赏
- 举报
[Quote=引用 6 楼 的回复:]
引用 5 楼 的回复:
中央服务器是绝对安全的？
包括负荷、性能肯定没问题？
那应该是A比较好
必需保证中心服务器的高可用性.否则所有业务无法办理.
[/Quote]
那还是选择A方案吧
引用 5 楼 的回复:
中央服务器是绝对安全的？
包括负荷、性能肯定没问题？
那应该是A比较好
必需保证中心服务器的高可用性.否则所有业务无法办理.
[/Quote]
那还是选择A方案吧
汤姆克鲁斯 2012-09-02
- 打赏
- 举报
楼主的集群是怎么配的，能达到什么样的效果？
事务同步将会有5-10s 的延迟。
个人建议第二种，但是可以第二种应该是 查询db
很多频繁的查询都用从机去判断。
减少主机的查询，主机同步到丛机，从机可以有很多。。
但是你这种连贯性的动作 不适合放在两台服务器上搞。同步本身石油延迟的。
事务同步将会有5-10s 的延迟。
个人建议第二种，但是可以第二种应该是 查询db
很多频繁的查询都用从机去判断。
减少主机的查询，主机同步到丛机，从机可以有很多。。
但是你这种连贯性的动作 不适合放在两台服务器上搞。同步本身石油延迟的。
昵称被占用了 2012-09-02
- 打赏
- 举报
信息严重不足哦，最重要的数据量和预算都没有说明
方案没有好坏之分，只有是否适合
数据量不大则方案a，预算不足则方案b
你估计方案b吧，技术人员往往少考虑预算
方案没有好坏之分，只有是否适合
数据量不大则方案a，预算不足则方案b
你估计方案b吧，技术人员往往少考虑预算
SQL77 2012-09-02
- 打赏
- 举报
个人感觉如果就是上面的只是信用额度。冻结额度的业务处理。放中央服务应该OK了。
如果还有其他的业务处理。换成方案2处理也不失一种好办法。分解压力。
具体的还要看你们的访问量。数据量等因素确定选择哪种方案能应对
如果还有其他的业务处理。换成方案2处理也不失一种好办法。分解压力。
具体的还要看你们的访问量。数据量等因素确定选择哪种方案能应对
發糞塗牆 2012-09-02
- 打赏
- 举报
[Quote=引用 8 楼 的回复:]
引用 7 楼 的回复:
引用 6 楼 的回复:
引用 5 楼 的回复:
中央服务器是绝对安全的？
包括负荷、性能肯定没问题？
那应该是A比较好
必需保证中心服务器的高可用性.否则所有业务无法办理.
那还是选择A方案吧
A固然有高可用性.但是对A的频繁访问会增加中央服务器的负担.
[/Quote]所以我说把压力分摊会比较好咯。就像移动、电信这些公司，他们都不会把数据汇总到总公司，而是以省公司为单位存放。
引用 7 楼 的回复:
引用 6 楼 的回复:
引用 5 楼 的回复:
中央服务器是绝对安全的？
包括负荷、性能肯定没问题？
那应该是A比较好
必需保证中心服务器的高可用性.否则所有业务无法办理.
那还是选择A方案吧
A固然有高可用性.但是对A的频繁访问会增加中央服务器的负担.
[/Quote]所以我说把压力分摊会比较好咯。就像移动、电信这些公司，他们都不会把数据汇总到总公司，而是以省公司为单位存放。
三断笛 2012-09-02
- 打赏
- 举报
[Quote=引用 7 楼 的回复:]
引用 6 楼 的回复:
引用 5 楼 的回复:
中央服务器是绝对安全的？
包括负荷、性能肯定没问题？
那应该是A比较好
必需保证中心服务器的高可用性.否则所有业务无法办理.
那还是选择A方案吧
[/Quote]
A固然有高可用性.但是对A的频繁访问会增加中央服务器的负担.
引用 6 楼 的回复:
引用 5 楼 的回复:
中央服务器是绝对安全的？
包括负荷、性能肯定没问题？
那应该是A比较好
必需保证中心服务器的高可用性.否则所有业务无法办理.
那还是选择A方案吧
[/Quote]
A固然有高可用性.但是对A的频繁访问会增加中央服务器的负担.
三断笛 2012-09-01
- 打赏
- 举报
[Quote=引用 2 楼 的回复:]
我觉得方案B会比较好一点，因为你提到【访问频繁】，把压力分摊到下面的服务器会比较好一点。在判断时，对中央服务器顶多只是一个读操作，会减轻很多负担，判断完成后才到插入或者更新操作。
你这里的方案有点像发布/订阅功能。对于业务频繁的系统，这样能减轻负担。至于是谁的方案我就不猜了，对我没意义。
[/Quote]
冻结额度和信用额度分分别存储在中央服务器和业务服务器,对信用额度的更新会写入中央服务器哦!
我觉得方案B会比较好一点，因为你提到【访问频繁】，把压力分摊到下面的服务器会比较好一点。在判断时，对中央服务器顶多只是一个读操作，会减轻很多负担，判断完成后才到插入或者更新操作。
你这里的方案有点像发布/订阅功能。对于业务频繁的系统，这样能减轻负担。至于是谁的方案我就不猜了，对我没意义。
[/Quote]
冻结额度和信用额度分分别存储在中央服务器和业务服务器,对信用额度的更新会写入中央服务器哦!
發糞塗牆 2012-09-01
- 打赏
- 举报
我觉得方案B会比较好一点，因为你提到【访问频繁】，把压力分摊到下面的服务器会比较好一点。在判断时，对中央服务器顶多只是一个读操作，会减轻很多负担，判断完成后才到插入或者更新操作。
你这里的方案有点像发布/订阅功能。对于业务频繁的系统，这样能减轻负担。至于是谁的方案我就不猜了，对我没意义。
你这里的方案有点像发布/订阅功能。对于业务频繁的系统，这样能减轻负担。至于是谁的方案我就不猜了，对我没意义。
加载更多回复（1）
