集群环境要考虑的几件事情

     做web应用，发到线上是集群环境。有几件事情要考虑。
     1：cache
     本地cache不能保证多个server的内存同时被更新，面试经常遇到的山寨做法是server1有数据update，则同步写db，然后在server1，server2，servern定期扫描db变化，把需要更新的数据更新到sever2.。。
这种搞法不能保持数据的抢一致性。

        于是出现了分布式cache，就是多个cache做数据的同步，比如著名的oscahe项目。
        是个一个广泛采用的高性能的J2EE缓存框架，OSCache能用于任何Java应用程序的普通的缓存解决方案。OSCache有以下特点：缓存任何对象，你可以不受限制的缓存部分jsp页面或HTTP请求，任何java对象都可以缓存。OSCache采用广播方式实现分布式环境下消息的通知,目前两种比较流行的做法是使用 JMS和JGROUPS。广播的做法受限于网络的广播模式，另外n个server，两两之间需要同步，消耗不小。
      使用广泛的Ehcache 从1.2 之后就支持了集群。
     Ehcache is an open source, standards-based cache used to boost performance, offload the database and simplify scalability. Ehcache is robust, proven and full-featured, which has made it the most popular Java-based cache with 100,000’s of production deployments.
      Ehcache 后来采用了Terracotta Server Array ("TSA") 做cache的分布式解决方案（ coherency, JTA, HA, scale and high performance. It is available as open source or with additional features in the Ehcache EX and FX product editions.）
       Ehcache 有分布式cache和cache复制2类方案。分布式cache采用Terracotta。Terracotta允许多个CacheManagers和他们的cache对象在多个jvm中共享数据。

采用数据复制的方式是另外一类选择 下图1为不冗余存储的方式，而图2使用负载均衡+冗余存储。

  

      
    集中式缓存以memcahe最为知名，有独立的cache server，client可以自己选择算法来做cache server的负载均衡。Memcached 是一个高性能的集中式对象缓存系统，用于动态Web应用以减轻数据库负载。它通过在内存中缓存数据和对象来减少读取数据库的次数，从而提供动态、数据库驱动网站的速度。Memcached基于一个存储键/值对的hashmap。其守护进程（daemon ）是用C写的，但是可以用任何语言来编写，并通过memcached协议与守护进程通信。但是它并不提供冗余（例如，复制其hashmap条目）。

   2：调度任务

   类似于java timer或者quartz这样的东东在单机环境可以允许的好好的，在集群环境需要解决一个任务只被一个服务器执行的问题。

    Quartz本身提供了cluster的支持，Quartz是通过借助关系数据库和JDBC作业存储来实现集群管理的。

　　集群通过故障切换和负载平衡的功能，能给调度器带来高可用性和伸缩性。目前集群只能工作在JDBC- Jobstore (JobStoreTX 或者JobStoreCMT)方式下，从本质上来说，是使集群上的每一个节点通过共享同一个数据库来工作的（Quartz通过启动两个维护线程来维护数据 库状态实现集群管理，一个是检测节点状态线程，一个是恢复任务线程）。

　　负载平衡是自动完成的，集群的每个节点会尽快触发任务。当一个触发器的触发时间到达时，第一个节点将会获得任务（通过锁定），成为执行任务的节点。

　　故障切换的发生是在当一个节点正在执行一个或者多个任务失败的时候。当一个节点失败了，其他的节点会检 测到并且标识在失败节点上正在进行的数据库中的任务。任何被标记为可恢复（任务详细信息的"requests recovery"属性）的任务都会被其他的节点重新执行。没有标记可恢复的任务只会被释放出来，将会在下次相关触发器触发时执行。

   优势：配置简单，HA。

   劣势：任务job在web server上没有隔离，不适合对多个web server或者task server做隔离的负载均衡，扩容。比如某应用有100台sever，则100个schedule server需要共享db，其实是不必要的浪费。

   Gearman是另一款开源的通用的分布式任务分发框架，自己本身不做任何实际的工作。它可以将一个个的任务分发给其他的物理机器或者进程，，因为相较于Hadoop而言，Gearman更偏重于任务的分发而不是执行。

   部署图如下所示

    

    job server只负责分发工作，一般来讲client和worker可以在同一个srever中。

    Gearman 的job分为Background job和Non-background job，对于后者client端在job执行的整个过程中，与job server端的链接都是保持着的，这也给job完成后job server返回执行结果给client提供了通路。同时，在job执行过程当中，client端还可以发起job status的查询。当然，这需要worker端的支持的。Non-background job对于client需要知道job执行进展或者最后拿到结果的作业不实为一个好的卖点。（care refer：)

   采用配置中心》消息中心》业务服务器job执行，包括消息回执，重试是Gearman 模式的改良版。异步消息不需要client和job server建立长连接，而是完全采用p/s模式，通过异步消息回执来确定job是否执行成功，失败会重试。

  坊间有专利描述分布式任务搞法。

  

    3：集群环境的session

   这块由负载均衡服务器解决 不赘述。如果webserver后面有多级app server做不同的业务处理，则需要解决分布式session传递的问题。

  4：序列生成器

  全局唯一，集群环境，高效（使用乐观锁），如果在oracle数据库可以直接使用sequence来解决问题。 

 对于文章，通过分段获取来降低访问数据库的成本，在id必须连续的情况下不适用，可以根据具体需求考量。比如某些业务id="order"+sequence,此时sequence就有具体业务含义了。采用悲观锁可以保证sequence唯一，但效率受影响。可以采用时间戳/版本记录的乐观锁来解决此问题。