robbin 对Hibernate集群的理解!和疑问

没有什么特殊需要配置的，和单机一样的，就是你用Hibernate开发的程序要检查一遍，把一些不能在集群中用的功能替换掉，例如read-write cache不能用，ID生成器有几个不能用在集群中诸如此类。


不明白说的 read-write cache不能用 具体指什么啊?
指不能用eccache?那hibernate不就成了单纯的dao的一种实现了吗?

原帖
http://www.iteye.com/topic/341



2.还有一个问题啊
除了ejb和corbar 外,好象Hibernate和spring webwork都不支持分布式!
如果我对分布式理解没错的话,分布就是把不同的功能模块,分布的放在不同的server上!
a业务就去a机器,如果a业务用到b业务,就去b机调用b业务!但我觉得spring 这些也可以啊!
甚至纯jsp也可以啊!分别启动两台服务器
a,b a机放一个search页面,然后输入搜索条件,做些必要的处理,点提交,就提交给b机
这不是也把分布了吗?或者a机的,search功能需要用到b机的某些个模块,完全可以在a机上通过访问url
后者用webservice的方式得到b机模块返回的数据!然后这不是也是分步了吗?


并且.分布式在容灾方面非常不好!还不如用集群负载均衡来应付大并发来的直接啊!不是很明白哎
不知道有没有人愿意答啊

评论

7 楼 Godlikeme 2008-10-26  

扯那么多没用，回头好好看看j2ee design and development。
集群与否和技术关系不大，是应用整体架构的事情，检查应用中有状态，有同步，有缓存的逻辑，用替换成无状态，集群cache，数据库同步等技术解决。

6 楼 Gavin.Chen 2008-10-25  

不被骂不知醒嘛，以后发言会注意的，谢谢各位指点了，呵呵
成为像你们一样的牛人是我的目标，但路很难走，见谅一下
但是很多时候单看别人的文章是不能帮自己快速地领会的，新人也需要发表自己的见解，虽很肤浅，但是我觉得这样才能让自己了解到自己的不足，让自己的知识组织得更好一点，大家怎么认为？新人怎么才能出头

5 楼 Norther 2008-10-25  

Gavin.Chen 写道

　　假如你的项目要分三个模块给不在同一个地方的三组人分别进行开发与维护，分别对应三个数据库，每个数据库存放不同的东西，数据库放在不同的服务器上，并且放在网络的不同地方，但是这三个模块需经常交换数据，或互相调用各自的方法，面对这样的需求，你会怎么去做。

　　当然你可以将三个模块放到一台超强的服务器上，将三个数据库合并成一个更大的数据库，要是数据库数据量大，一个硬盘放不下去，也可以组成磁盘阵列去解决。。。很多时候对一些问题可以有很多的解决方案。

　　但是，业务上的变化是千变万化的，每一个公司都有各自的业务流程，不同的客户也会提出不同的需求，大多数时候软件必须根据实际的业务需求进行设计。所以，假如三个模块必须放在三台不同的服务器，不同的服务器分别放在三个不同的地方，三个数据库也必须分开存放，此时，你必须想一些方法去解决，具体有什么方法去解决呢。

　　从软件开发的角度，你不能单单提供一个可以看的页面（你总不可能在其中一个模块的某个方法运行需要其它模块的数据，而叫一些人用URL进行search查询，然后再输进到那个方法里面去吧），而必须提供可以便利地进行数据交换的途径，如果你实现了这么一个系统，可以随意地让你不同的模块放在不同的地方，而最终能够正常相互调用，这就是分布式系统了。

　　从你所提出的几种途径中，也可以做到进行数据的功能，比如用jsp，你可以用jsp输出必要的数据，然后另一端通过url获得这些数据，再进行分析使用。你还可以用web service实现这一功能，每一个功能提供一个web service，然后另一端通过访问web service，调用某些方法，从而获得相应的数据。

　　是的，以上两个都可以实现这样的功能，但是，细究想想，假如模块间有非常多的方法要相互调来调去，你用上面两个方法去实现，你得要花多长时间，你用url方法进行交互的话，别人是不是也能未经许可就可以轻易访问到？你怎样保证数据的安全，开发的成本的如何？

　　Spring对此也提供了几个解决方案，其中一个就是RMI，RMI是远程方法调用，做起来也可以实现分布效果，但是在开发难度很高，效果也不是很理想。

　　EJB就能较好地实现分布式，它压根就是为了解决分存式系统开发而诞生的，虽然许许多多的人都说EJB很烂，比不上Spring+hibernate。。。。。

    是啊，EJB开发难度大，程序写起来复杂，而且各种容器大多要收费，而且还是不小的一笔费用，而且在EJB2.1与更前的一些EJB版本中，有些方法的实现简直可以达到无法忍受的地步。

　　但是一切就在此打住吧，你要开发以上的系统，或者比以上系统复杂更多更多的，比如有成百上千个模块，分布在世界各地，数据库遍地方，模块间就数不清的方法间要进行调用，安全性要求更高，时间要求更紧。。。。。。如果你认为不会有这样的系统存在，那样你就错了，银行就是其中一个例子，当今国内的银行在全国各地都有部门，它们的系统比上面所打的比方更加复杂，安全性要求更高，如果你的资料不能在其它地方获得，你的钱不能从另一个城市取到，你还会像现在这样频繁使用银行？如果你的银行资料可以轻易地在网上用过URL被他人获得，我看你还敢不敢存钱到银行！当然，与银行系统类似的系统大有所在呢

　　你用Spring+hibernate想想怎么实现这些功能吧，如果你能想到很好的解决方案，那你就努力开发出来，然后大卖，赚大钱吧，如果你想不出来，去了解EJB有什么解决方案吧，再去看看那些大的软件企业的收费的中间件能提供的功能吧，你去看看那些EJB容器倒底能干些什么好事出来吧，你去了解一下那些大公司有多少技术牛B在研究开发这些中间件吧，然后再算算买这些中间件与自己组织这些一些人开发出类似的功能，实现相同的效果，所需要的成本的比较如何。在你把很多事情慢慢地想清楚的时候，答案就出来了，还是EJB好！

　　其实说白了，做中上级系统，甚至是超大级系统，EJB绝对是当前首选，成本是最低，至于开发小型应用，大把大把的框架可供你选择，当然，Spring+hibernate是比较热门的。EJB在不断的发展中，也在不断地吸收这些流行框架的设计理念，并将其引入到自身中，但不能说EJB就是落后了，淘汰了，跟人家后腿了，它们是不能相提并论的，这是EJB在不断地完善自身，使开发更加简便，为您节省更多的成本，但它的功能却仍在不断的增强，而原来的功能依然健壮，现在还没有一个可以替代EJB的优秀框架出现，而EJB下的中间件却己经得到了长足的发展了。

　　至于以后会变成怎么样，谁都没法说，事实才能证明一切，但目前，做不同的产品得选择不同的框架，适合的框架，如果只是静态网页，别用框架了，直接上HTML，如果只有一两个简单页面的动态网页，直接上JSP+JDBC吧，如果是小型网页系统，JSP+HIBERNATE挺不错，再复杂点，就把JSP换成Struts或者其它的框架，中间业务再插个SPRING，效果很好，总之就是根据项目需要，选择一个最佳，成本最低的解决方案，不能盲目地去选择所谓的优秀流行框架，每样东西学习都是需要成本的，功能越强大的产品，往往概念越多，学习曲线越高，能做到大的，肯定有它优秀的设计理念在里头，尝试去了解更多吧

建议你先去了解什么是分布式，EJB是如何实现分布式的，以及EJB和RMI的关系，别再这误人子弟的了，辛辛苦苦写了这么多东西，语气跟教授一样，但内容完全是瞎扯淡嘛。

4 楼 robbin 2008-10-25  

这坟挖的！ 2003年的Hibernate和2008年的Hibernate是一回事吗？ 缓存功能能一样吗？

3 楼 taupo 2008-10-25  

read-write cache不能用

robbin的意思是，hibernate的二级缓存有一个read-write策略，如果做集群，这个策略就不能用

2 楼 taupo 2008-10-25  

Gavin.Chen 写道

　　假如你的项目要分三个模块给不在同一个地方的三组人分别进行开发与维护，分别对应三个数据库，每个数据库存放不同的东西，数据库放在不同的服务器上，并且放在网络的不同地方，但是这三个模块需经常交换数据，或互相调用各自的方法，面对这样的需求，你会怎么去做。

　　当然你可以将三个模块放到一台超强的服务器上，将三个数据库合并成一个更大的数据库，要是数据库数据量大，一个硬盘放不下去，也可以组成磁盘阵列去解决。。。很多时候对一些问题可以有很多的解决方案。

　　但是，业务上的变化是千变万化的，每一个公司都有各自的业务流程，不同的客户也会提出不同的需求，大多数时候软件必须根据实际的业务需求进行设计。所以，假如三个模块必须放在三台不同的服务器，不同的服务器分别放在三个不同的地方，三个数据库也必须分开存放，此时，你必须想一些方法去解决，具体有什么方法去解决呢。

　　从软件开发的角度，你不能单单提供一个可以看的页面（你总不可能在其中一个模块的某个方法运行需要其它模块的数据，而叫一些人用URL进行search查询，然后再输进到那个方法里面去吧），而必须提供可以便利地进行数据交换的途径，如果你实现了这么一个系统，可以随意地让你不同的模块放在不同的地方，而最终能够正常相互调用，这就是分布式系统了。

　　从你所提出的几种途径中，也可以做到进行数据的功能，比如用jsp，你可以用jsp输出必要的数据，然后另一端通过url获得这些数据，再进行分析使用。你还可以用web service实现这一功能，每一个功能提供一个web service，然后另一端通过访问web service，调用某些方法，从而获得相应的数据。

　　是的，以上两个都可以实现这样的功能，但是，细究想想，假如模块间有非常多的方法要相互调来调去，你用上面两个方法去实现，你得要花多长时间，你用url方法进行交互的话，别人是不是也能未经许可就可以轻易访问到？你怎样保证数据的安全，开发的成本的如何？

　　Spring对此也提供了几个解决方案，其中一个就是RMI，RMI是远程方法调用，做起来也可以实现分布效果，但是在开发难度很高，效果也不是很理想。

　　EJB就能较好地实现分布式，它压根就是为了解决分存式系统开发而诞生的，虽然许许多多的人都说EJB很烂，比不上Spring+hibernate。。。。。

    是啊，EJB开发难度大，程序写起来复杂，而且各种容器大多要收费，而且还是不小的一笔费用，而且在EJB2.1与更前的一些EJB版本中，有些方法的实现简直可以达到无法忍受的地步。

　　但是一切就在此打住吧，你要开发以上的系统，或者比以上系统复杂更多更多的，比如有成百上千个模块，分布在世界各地，数据库遍地方，模块间就数不清的方法间要进行调用，安全性要求更高，时间要求更紧。。。。。。如果你认为不会有这样的系统存在，那样你就错了，银行就是其中一个例子，当今国内的银行在全国各地都有部门，它们的系统比上面所打的比方更加复杂，安全性要求更高，如果你的资料不能在其它地方获得，你的钱不能从另一个城市取到，你还会像现在这样频繁使用银行？如果你的银行资料可以轻易地在网上用过URL被他人获得，我看你还敢不敢存钱到银行！当然，与银行系统类似的系统大有所在呢

　　你用Spring+hibernate想想怎么实现这些功能吧，如果你能想到很好的解决方案，那你就努力开发出来，然后大卖，赚大钱吧，如果你想不出来，去了解EJB有什么解决方案吧，再去看看那些大的软件企业的收费的中间件能提供的功能吧，你去看看那些EJB容器倒底能干些什么好事出来吧，你去了解一下那些大公司有多少技术牛B在研究开发这些中间件吧，然后再算算买这些中间件与自己组织这些一些人开发出类似的功能，实现相同的效果，所需要的成本的比较如何。在你把很多事情慢慢地想清楚的时候，答案就出来了，还是EJB好！

　　其实说白了，做中上级系统，甚至是超大级系统，EJB绝对是当前首选，成本是最低，至于开发小型应用，大把大把的框架可供你选择，当然，Spring+hibernate是比较热门的。EJB在不断的发展中，也在不断地吸收这些流行框架的设计理念，并将其引入到自身中，但不能说EJB就是落后了，淘汰了，跟人家后腿了，它们是不能相提并论的，这是EJB在不断地完善自身，使开发更加简便，为您节省更多的成本，但它的功能却仍在不断的增强，而原来的功能依然健壮，现在还没有一个可以替代EJB的优秀框架出现，而EJB下的中间件却己经得到了长足的发展了。

　　至于以后会变成怎么样，谁都没法说，事实才能证明一切，但目前，做不同的产品得选择不同的框架，适合的框架，如果只是静态网页，别用框架了，直接上HTML，如果只有一两个简单页面的动态网页，直接上JSP+JDBC吧，如果是小型网页系统，JSP+HIBERNATE挺不错，再复杂点，就把JSP换成Struts或者其它的框架，中间业务再插个SPRING，效果很好，总之就是根据项目需要，选择一个最佳，成本最低的解决方案，不能盲目地去选择所谓的优秀流行框架，每样东西学习都是需要成本的，功能越强大的产品，往往概念越多，学习曲线越高，能做到大的，肯定有它优秀的设计理念在里头，尝试去了解更多吧

我-顶你个肺

1 楼 Gavin.Chen 2008-10-25  

　　假如你的项目要分三个模块给不在同一个地方的三组人分别进行开发与维护，分别对应三个数据库，每个数据库存放不同的东西，数据库放在不同的服务器上，并且放在网络的不同地方，但是这三个模块需经常交换数据，或互相调用各自的方法，面对这样的需求，你会怎么去做。

　　当然你可以将三个模块放到一台超强的服务器上，将三个数据库合并成一个更大的数据库，要是数据库数据量大，一个硬盘放不下去，也可以组成磁盘阵列去解决。。。很多时候对一些问题可以有很多的解决方案。

　　但是，业务上的变化是千变万化的，每一个公司都有各自的业务流程，不同的客户也会提出不同的需求，大多数时候软件必须根据实际的业务需求进行设计。所以，假如三个模块必须放在三台不同的服务器，不同的服务器分别放在三个不同的地方，三个数据库也必须分开存放，此时，你必须想一些方法去解决，具体有什么方法去解决呢。

　　从软件开发的角度，你不能单单提供一个可以看的页面（你总不可能在其中一个模块的某个方法运行需要其它模块的数据，而叫一些人用URL进行search查询，然后再输进到那个方法里面去吧），而必须提供可以便利地进行数据交换的途径，如果你实现了这么一个系统，可以随意地让你不同的模块放在不同的地方，而最终能够正常相互调用，这就是分布式系统了。

　　从你所提出的几种途径中，也可以做到进行数据的功能，比如用jsp，你可以用jsp输出必要的数据，然后另一端通过url获得这些数据，再进行分析使用。你还可以用web service实现这一功能，每一个功能提供一个web service，然后另一端通过访问web service，调用某些方法，从而获得相应的数据。

　　是的，以上两个都可以实现这样的功能，但是，细究想想，假如模块间有非常多的方法要相互调来调去，你用上面两个方法去实现，你得要花多长时间，你用url方法进行交互的话，别人是不是也能未经许可就可以轻易访问到？你怎样保证数据的安全，开发的成本的如何？

　　Spring对此也提供了几个解决方案，其中一个就是RMI，RMI是远程方法调用，做起来也可以实现分布效果，但是在开发难度很高，效果也不是很理想。

　　EJB就能较好地实现分布式，它压根就是为了解决分存式系统开发而诞生的，虽然许许多多的人都说EJB很烂，比不上Spring+hibernate。。。。。

    是啊，EJB开发难度大，程序写起来复杂，而且各种容器大多要收费，而且还是不小的一笔费用，而且在EJB2.1与更前的一些EJB版本中，有些方法的实现简直可以达到无法忍受的地步。

　　但是一切就在此打住吧，你要开发以上的系统，或者比以上系统复杂更多更多的，比如有成百上千个模块，分布在世界各地，数据库遍地方，模块间就数不清的方法间要进行调用，安全性要求更高，时间要求更紧。。。。。。如果你认为不会有这样的系统存在，那样你就错了，银行就是其中一个例子，当今国内的银行在全国各地都有部门，它们的系统比上面所打的比方更加复杂，安全性要求更高，如果你的资料不能在其它地方获得，你的钱不能从另一个城市取到，你还会像现在这样频繁使用银行？如果你的银行资料可以轻易地在网上用过URL被他人获得，我看你还敢不敢存钱到银行！当然，与银行系统类似的系统大有所在呢

　　你用Spring+hibernate想想怎么实现这些功能吧，如果你能想到很好的解决方案，那你就努力开发出来，然后大卖，赚大钱吧，如果你想不出来，去了解EJB有什么解决方案吧，再去看看那些大的软件企业的收费的中间件能提供的功能吧，你去看看那些EJB容器倒底能干些什么好事出来吧，你去了解一下那些大公司有多少技术牛B在研究开发这些中间件吧，然后再算算买这些中间件与自己组织这些一些人开发出类似的功能，实现相同的效果，所需要的成本的比较如何。在你把很多事情慢慢地想清楚的时候，答案就出来了，还是EJB好！

　　其实说白了，做中上级系统，甚至是超大级系统，EJB绝对是当前首选，成本是最低，至于开发小型应用，大把大把的框架可供你选择，当然，Spring+hibernate是比较热门的。EJB在不断的发展中，也在不断地吸收这些流行框架的设计理念，并将其引入到自身中，但不能说EJB就是落后了，淘汰了，跟人家后腿了，它们是不能相提并论的，这是EJB在不断地完善自身，使开发更加简便，为您节省更多的成本，但它的功能却仍在不断的增强，而原来的功能依然健壮，现在还没有一个可以替代EJB的优秀框架出现，而EJB下的中间件却己经得到了长足的发展了。

　　至于以后会变成怎么样，谁都没法说，事实才能证明一切，但目前，做不同的产品得选择不同的框架，适合的框架，如果只是静态网页，别用框架了，直接上HTML，如果只有一两个简单页面的动态网页，直接上JSP+JDBC吧，如果是小型网页系统，JSP+HIBERNATE挺不错，再复杂点，就把JSP换成Struts或者其它的框架，中间业务再插个SPRING，效果很好，总之就是根据项目需要，选择一个最佳，成本最低的解决方案，不能盲目地去选择所谓的优秀流行框架，每样东西学习都是需要成本的，功能越强大的产品，往往概念越多，学习曲线越高，能做到大的，肯定有它优秀的设计理念在里头，尝试去了解更多吧