一直没搞懂，hibernate在集群环境下怎么工作

一直没搞懂，hibernate在集群环境下怎么工作

服务器集群就是指将很多服务器集中起来一起进行同一种服务，在客户端看来就像是只有一个服务器集群可以利用多个计算机进行并行计算从而获得很高的计算速度，也可以用多个计算机做备份，从而使得任何一个机器坏了整个系统还是能正常运行。
　　使用集群服务器构建的集群系统优点在于：
　　(1)统集群系统可解决所有的服务器硬件故障，当某一台服务器出现任何故障，如：硬盘、内存、CPU、主板、I/O板以及电源故障，运行在这台服务器上的应用就会切换到其它的服务器上。
　　(2)集群系统可解决软件系统问题，我们知道，在计算机系统中，用户所使用的是应用程序和数据，而应用系统运行在操作系统之上，操作系统又运行在服务器上。这样，只要应用系统、操作系统、服务器三者中的任何一个出现故障，系统实际上就停止了向客户端提供服务，比如我们常见的软件死机，就是这种情况之一，尽管服务器硬件完好，但服务器仍旧不能向客户端提供服务。而集群的最大优势在于对故障服务器的监控是基于应用的，也就是说，只要服务器的应用停止运行，其它的相关服务器就会接管这个应用，而不必理会应用停止运行的原因是什么。
　　(3)集群系统可以解决人为失误造成的应用系统停止工作的情况，例如：当管理员对某台服务器操作不当导致该服务器停机，因此运行在这台服务器上的应用系统也就停止了运行。由于集群是对应用进行监控，因此其它的相关服务器就会接管这个应用，提高了应用系统的稳定性。
　　2、常见问题
　　应用系统升级到集群服务器环境下，碰到的主要问题是Hibernate代理的主键在插入时，主键重复异常信息明显增多。通过对应用系统源代码进行分析，发现出现的问题主要为以下两方面。
　　2.1 Hibernate的Generator配置为increment
　　increment方式为Hibernate提供的一种内置的常用的主键生成器策略，此方式的实现机制为在当前应用实例中维持一个变量，以保存着当前的最大值，之后每次需要生成主键的时候将此值加1作为主键。这种方式可能产生的问题是：如果当前有多个实例访问同一个数据库，那么由于各个实例各自维护主键状态，不同实例可能生成同样的主键，从而造成主键重复异常。因此，如果同一数据库有多个实例访问，此方式必须避免使用。
　　目前我们的应用系统环境为最简单的集群方式：两台was，一台数据库的方式。所以当有并发情况访问系统且两个请求又被分发给两台was时，假设当前数据库id最大为40，两台was分别会产生两条id为41的数据导致插入失败(Duplicate entry主键重复)。
　　Increment主键生成器的org.hibernate.id.IncrementGenerator类里面，是使用select max(columnName)from tableName的方式来获取。原来的程序一直运行很好，但是在用两个was来负载均衡后却出现问题。为什么?IncrementGenerator类里面的generate()方法虽然被声明成了synchronized，但现在两个Tomcat分别运行在两台服务器的两个独立的Java虚拟机里，显然问题在这里，synchronized只能在一个独立的Java虚拟机内部有效。所以,在两个Tomcat中用select max同时取主键，就相当于在没有synchronized的保护下，并发时就会取出相同的值，再insert就会发生dumplicate entry的错误。
　　2.2 Hibernate的cache配置策略问题
　　Hibernate的cache是他提高效率的主要原因，比如我load，save的各种数据都会在缓存起来，用id标识，当我下次再次查询的时候，它会把id的集合都查出来，然后在缓存中遍历，如果都遍历到了，将不再访问数据库。显然这在集群环境下，也是小概率事件，但是这不影响数据正确完整，真正影响数据的是read-write cache。
　　Hibernate的缓存分为一级缓存和二级缓存，二级缓存需要特殊配置，通常情况下不用，一级缓存就包括上一个段落说的情况，分为read-only cache和read-write cache。Read-only cache只读的缓存会导致性能上的波动，却不影响数据，在上一段落已经举例说明。Read-write cache读写缓存则会影响数据逻辑，比如我在缓存里放入一个值名对叫flag=1来标识我已经具有操作权限，放入was1了但是下次请求可能发到was2上去了，结果我找不到这个值，导致我认为自己没权限，或者我想修改他却找不到它的值了。