一家零售上市公司的IT框架，请教各位老师

各位前辈或老师：
我是一家零售上市公司的IT管理人员，对J2EE等一些框架有些粗浅的认识。
我们的公司现在使用的系统架构是传统的C/S，前端Delphi后端用的是SQLSERVER2000，目前公司年销售已达到100亿，对系统的要求月来越高
目前公司整体IT框架是，200家门店前端总共4000台POS收款机，门店系统由Delphi+SQLSERVER2000，C/S架构，总部也是这样的C/S架构，做了个单服务器热备，服务器是IBM小型机，进销存数据通过IBM MQ上传总部系统。这种架构当前我们遇到了瓶颈，比如数据实时性较差，总部系统性能也跟不上业务要求，门店硬件软件维护量大，每天的ETL任务都无法按时完成。
我想请教的是这种门店与总部分离的架构是否需要革新，比较适合的架构是怎么样的？
我们的困惑是：
1.是否有必要使用分布式框架，因门店业务比较繁忙，客流量较高，如果门店服务器集中到总部采用大集群的方式，使POS机直连总部中间件服务器，这样万一断网怎么处理？
2.是否需要改用ORACLE数据库，是否有必要上数据库的RAC。
3.对于大型零售企业的话请问目前最为合适的架构是什么，业界有什么比较好的案例，谢谢。

[该贴被lojhome于2010-09-02 03:35修改过]

2010年09月02日 03:32 "lojhome"的内容

是否有必要使用分布式框架，因门店业务比较繁忙，客流量较高，如果门店服务器集中到总部采用大集群的方式，使POS机直连总部中间件服务器，这样万一断网怎么处理？
2.是否需要改用ORACLE数据库，是否有必要上数据库的RAC。
3.对于大型零售企 ...

由于你已经采取传统的C/S架构，走上了集中式计算的路径，不能回头了，所以，条件限制你没有必要再回头选择分布式。

分布式和传统集中式都适合大型零售企业，关键是成本以及零售企业的成长速度，如果追求低成本，高增长速度，选择分布式；反之集中式。

btw:国外零售企业由于没有中国这么爆发增长，都是慢条斯理，所以，一般采取集中式比较合适，但是如果把这套经验搬到中国，就不一样了。这就是现实中洋枪洋炮水土不服的原因。

觉得应该在 200 个下级服务器和 IBM小型机找瓶颈做优化。
或者在后端集群几台机器做中间存储再传回小型机。。。。请教一下IBM小型机装sql server ? db2吧

谢谢老师了

应该新开发一套系统，然后新开的店逐步都用这套，然后老系统和这套暂时都用同一个库。
等新系统稳定之后，逐渐剃掉老的。

否则总有一天会承受不了的

我做过类似的系统，也是连锁零售企业，店铺数百家，分布在全国各地。
我们采用的是三层架构，每家店铺在本地都有一个临时数据库，数据每天定时向总部上传下载，使用WebService交换数据。目前看起来，效果不错。
就你的三个问题，说说我的一点看法：
1.先尝试用三层架构，再辅助缓存，看看能不能解决问题。如果不是别无它法了，尽量不要做分布式；
2.本地缓存很有必要，因为中国的网络环境不稳定；
3.双机热备，防止突发宕机，冷备也行，反正本地有缓存；
4.sqlserver足够了，我们就是用sqlserver2005；
5.大数据的访问尽量分页，一些大数据的统计尽量在深夜执行，缓存结果，第二天浏览；
6.我觉得连锁零售企业，还是三层架构比较适合，要上分布式也尽量做成无状态的。

一点浅见，我们可以再探讨。

1）门店软硬件维护成本高
门店软件架构可采用REST的方式来改进，每台POS上的客户端软件仅仅是一个界面层，所有的业务逻辑都汇总在服务器端来实现，并且通过API的方式提供给界面层使用，这样可适当降低部分软件升级的工作。
门店的软硬件可考虑采用一些监控管理软件来进行管理，例如微软的SCCM等（或者你们自己开发也行）。这样可以在一个集中的地方实时观察各门店系统的系统资源以及软件运行情况。
2）ETL任务不及时，导致总部的数据不能“实时地”反映企业的销售情况
这里的问题可能牵涉到门店系统与总部系统的数据同步设计，以及你们ETL子系统的设计有关了。对于数据同步方面，可将数据同步的频率设高，并在传输时压缩数据来提高效率。在ETL任务中需要做个测试，看看瓶颈在哪里，我碰到最多的情形就是ETL中有大量的数据库的操作，这样当然会降低效率，可以考虑采用采用MapReduce来实现ETL，计算完成后再将结果import入数据库，这样效率会高非常多。