[环境]
有多台高性能数据库服务器组成一个中央服务器集群,提供核心共享数据库,可以认为中央服务器是绝对安全的.另外有若干台数据库服务器供业务访问.
[业务流程介绍]
办理某业务时需要对信用额度进行检测和操作.各种业务对额度的访问频繁.大致流程如下:
业务服务器:提交单据时,判断信用额度减冻结额度是否大于0,大于0则增加冻结额度,信用额度余额不变,业务继续.小于0则禁止提交,中止操作.
中央服务器:单据确认成功时,判断信用额度余额是否足够,足够则取消提交时的额度冻结,即冻结额度减少,同时也扣除信用额度.额度不足则禁止确认,中止操作.
[目的]
现在做一个设计,保证对这些额度数据的高可用性和高性能访问,当然也要保证数据的准确性.
方案A:
设计一个表,存在于中央服务器,有冻结额度和信用额度余额字段(当然还有其他基本信息).业务服务器对额度的操作都在这个集群上完成.数据流程同上文中介绍.
当一台业务服务器挂掉时,立刻切换到其他业务服务器操作.依然保持对额度信息的访问.
方案B:
分别设计一张信用额度表和一张冻结额度表.
信用额度余额表存在于中央服务器.冻结额度表存在于业务服务器.
为防止业务服务器挂掉而无法访问冻结额度.再增加一组业务服务器的备份服务器,用事务同步将所有业务服务器中的冻结额度实时备份至备份服务器.当业务服务器挂掉时,立即切换至其他业务服务器,并访问备用服务器的冻结额度信息.
关于备用服务器的另一个变招是,将所有业务服务器的冻结额度数据与备用服务器做合并同步,这样能减少问题的复杂度,但可能造成数据的延迟.
数据流程:
发生业务提交单据时,分别读取业务服务器上冻结额度与中央服务器信用额度,判断可用余额是否足够,若余额足够,则增加业务服务器上的冻结额度,若不够,则禁止操作.
当确认单据时,读取中央服务器的信用额度,若足够,则扣除额度,并且访问业务服务器,取消单据的冻结额度.若额度不足,则禁止操作.
文字比较多,简洁表达一下就是,方案A将冻结额度和信用额度存储在中央服务器,对冻结额度的更改和对信用额度的更改都在中央服务器上进行,实现简单,缺点是对冻结额度和信用额度的更改都在中央服务器,增加中央服务器压力.
而方案B是将冻结额度与信用额度分开存储.对冻结额度的更改只在业务服务器上进行,保证了冻结额度的高效访问,分解了了对额度的访问,也一定程度减少中央服务器压力.缺点是实现复杂,可能会有延迟和不可靠性,跨服务器操作有损性能.而且需要增加另一个备用服务器作实时同步.
提问:
1:到底哪种方案更合理呢?
2:是否有更优方案?
3:猜猜哪种方案是我的,哪种方案是领导的?
补充一些数据:
目前这个额度的数据大约有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次.
业务服务器发生故障时,业务立刻切换到其他服务器,同时从备用服务器取回数据,修改主服务器回写数据的接口,不再写回故障机器,转至新机器.
-------------------------------------------------------------------------------------------------------------------------------------------
补我发给领导的邮件:
X总:
我认为冻结额度还是应该放在中央服务器.原因如下:
对信用额度模块的设计目的是保证信用额度数据的高可用性(即数据的持续访问,不因任何一个节点故障而导致无法访问),高性能访问以及准确性.
一:高可用性:
在我们的系统环境中,首先应当认为中央服务器(组)是可用性最高的,必须保证在任何情况下中央服务器(组)是正常可用的,一旦出现故障,不仅是信用额度模块,所有业务都将不能办理.
中央服务器组绝对的高可用性是信用额度信息必须放在中央服务器的第一个原因,这样才能保证额度信息的高可用性.
所以不需要假设中央服务器当机的情况.不存在,也绝不容许存在.即便存在,那信用额度数据无法访问,整个信用额度模块照样无法运行.
若冻结额度存储在业务服务器,则无法保证业务服务器的可用性,当业务服务器故障时可能造成冻结额度的丢失.当然,可以增加备用服务器,实时备份所有业务服务器上的冻结额度.
但是,当业务服务器故障时,业务切换到其他业务服务器,此时业务服务器需访问备份服务器取得额度数据,这就带来了6个问题:
1.各业务服务器如何向备用服务器实时合并同步冻结额度?
2.中央服务器向业务服务器回写冻结额度数据如何现实?
3.若因为业务服务器故障而造成备用服务器数据同步不完全怎么办?
4.当业务服务器发生故障,中央服务器因为无法将冻结额度回写业务服务器,造成中央服务器事务锁定,甚至造成中央服务器整个过程无法执行怎么办?(当存储过程中一个链接服务器失效时,整个存储过程将无法编译和执行)
5.业务服务器怎样快速转向备用服务器读取数据?
6.假设解决了第2点的问题,当业务服务器故障时,中央服务器确认单据时如何回写冻结额度数据?一部分向业务服务器写,一部分向备用服务器写?
此时因为业务服务器故障,业务切换,多个区域会共用一台业务服务器,该业务服务器原来只访问自己的冻结额度,中央服务器也只能写回该区域的冻结额度数据,现在如何保证多个区域在同一台业务服务器上操作,而冻结额度一台在业务服务器,一台在备用服务器时,冻结额度的回写和访问?
二:高性能:
当额度数据存储在中央服务器时,业务流程如下:
1.提交时,业务服务器跨服务器读取1次中央服务器,取得冻结额度和信用额度,判断额度是否足够.
2.提交时,业务服务器向中央服务器跨服务器写入冻结额度1次.
3.确认时,中央服务器本地读取信用额度1次判断
4.再跨服务器写入冻结额度1次,和更新本地信用额度1次.
总计跨服务器写入2次,跨服务器读取1次,本地写入1次.本地读取1次,一共5次 业务服务器发生故障时,中央服务器无需任何改动.业务服务器只需切换服务器即可.
当冻结额度存储在业务服务器上,而信用额度存储在业务服务器上时,业务流程如下:
1.提交时,本地读取冻结额度1次,跨服务器读取信用额度1次.以判断额度.
2.提交时,本地写入冻结额度1次.以更新额度.
3.确认时,本地读取信用额度1次,跨服务器读取冻结额度1次.
4.确认时,本地写入信用额度1次,跨服务器写入冻结额度1次.
这里总计跨服务器写入1次,本地写入2次,跨服务器读取2次,本地读取2次,共计7次.
不难算出冻结额度放在业务服务器时,对中央服务器的操作不但没有减少,反而增加,而且也增加了本地操作.
不仅如此,还增加了跨服务器的操作.跨服务器分布式事务所造成的性能损失更多.
三:准确性:
信用额度存储在中央服务器,对信用额度的操作都在同一台服务器上进行,本地事务可靠性高.可以更好地保证在没有程序漏洞的情况下数据的完整性,一致性和持久性.
当信用额度保存在中央服务器而冻结额度保存在业务服务器时,若业务服务器发生故障,需要转向备用服务器访问,如第一段时所述,该如何对业务服务器冻结额度进行操作?操作的不可预见性和复杂性及易造成数据的错误.
尤其如和一段中所述,大大增加了实现的复杂度和不稳定性,对冻结额度的存储将很不可靠,而且很可能因为中央服务器依赖业务服务器冻结额度,当业务服务器故障时(可能可以在短时间内转移)牵连中央服务器运行.
综上所述,我认为应该将信用额度存储在中央服务器.
而且同上所述,对号码所处理同样有这些问题,号码也不应存储在业务服务器.
改善方案:
既然可备用服务器来备份号码和信用额度,既然要减少对中央服务器的压力,为何不直接将信用额度和号码存储在专用的服务器(组),这样垂直地分割数据既减少了中央服务器的压力,也保证了号码和信用额度的安全,这比存储在业务服务器好得多.
------------------------------------------------------------------------------------------------------------------------------------
最终结果:领导选择自己的方案,B方案.