EhCache 分布式缓存缓存集群

一 缓存系统简介         EhCache 是一个纯 Java 的进程内缓存框架 具有快速 精干等特点 是 Hibernate 中默认的 CacheProvider         EhCache 应用架构图 下图是 EhCache 在应用程序中的位置

         EhCache 的主要特性有         快速 精干         简单         多种缓存策略         缓存数据有两级 内存和磁盘 因此无需担心容量问题         缓存数据会在虚拟机重启的过程中写入磁盘         可以通过 RMI 可插入 API 等方式进行分布式缓存         具有缓存和缓存管理器的侦听接口         支持多缓存管理器实例 以及一个实例的多个缓存区域         提供 Hibernate 的缓存实现         由于 EhCache 是进程中的缓存系统 一旦将应用部署在集群环境中 每一个节点维护各自的缓存数据 当某个节点对缓存数据进行更新 这些更新的数据无法在其它节点 享 这不仅会降低节点运行的效率 而且会导致数据不同步的情况发生 例如某个网站采用 A B 两个节点作为集群部署 当 A 节点的缓存更新后 而 B 节点缓存尚未更新就可能出现用户在浏览页面的时候 一会是更新后的数据 一会是尚未更新的数据 尽管我们也可以通过 Session Sticky 技术来将用户锁定在某个节点上 但对于一些交互性比较强或者是非 Web 方式的系统来说 Session Sticky 显然不太适合         所以就需要用到 EhCache 的集群解决方案         从 版本开始 Ehcache可以使用分布式的缓存了 EhCache 从 版本开始 支持五种集群方案 分别是         Terracotta        RMI        JMS        JGroups        EhCache Server        其中的三种最为常用集群方式 分别是 RMI JGroups 以及 EhCache Server 本文主要介绍RMI的方式         分布式这个特性是以plugin的方式实现的 Ehcache自带了一些默认的分布式缓存插件实现 这些插件可以满足大部分应用的需要 如果需要使用其他的插件那就需要自己开发了 开发者可以通过查看distribution包里的源代码及JavaDoc来实现它 尽管不是必须的 在使用分布式缓存时理解一些ehcahce的设计思想也是有帮助的 这可以参看分布式缓存设计的页面 以下的部分将展示如何让分布式插件同ehcache一起工作         下面列出的是一些分布式缓存中比较重要的方面         你如何知道集群环境中的其他缓存？        分布式传送的消息是什么形式？        什么情况需要进行复制？增加（Puts） 更新（Updates）或是失效（Expiries）？        采用什么方式进行复制？同步还是异步方式？        为了安装分布式缓存 你需要配置一个PeerProvider 一个CacheManagerPeerListener         它们对于一个CacheManager来说是全局的 每个进行分布式 *** 作的cache都要添加一个cacheEventListener来传送消息

    二 集群缓存概念及其配置         正确的元素类型        只有可序列化的元素可以进行复制 一些 *** 作 比如移除 只需要元素的键值而不用整个元素 在这样的 *** 作中即使元素不是可序列化的但键值是可序列化的也可以被复制         成员发现（Peer Discovery）        Ehcache进行集群的时候有一个cache组的概念 每个cache都是其他cache的一个peer 没有主cache的存在 刚才我们问了一个问题 你如何知道集群环境中的其他缓存？这个问题可以命名为成员发现（Peer Discovery）         Ehcache提供了两种机制用来进行成员发现 就像一辆汽车 手动档和自动档 要使用一个内置的成员发现机制要在ehcache的配置文件中指定cacheManagerPeerProviderFactory元素的class属性为        net sf ehcache distribution RMICacheManagerPeerProviderFactory         自动的成员发现        自动的发现方式用TCP广播机制来确定和维持一个广播组 它只需要一个简单的配置可以自动的在组中添加和移除成员 在集群中也不需要什么优化服务器的知识 这是默认推荐的         成员每秒向群组发送一个 心跳 如果一个成员 秒种都没有发出信号它将被群组移除 如果一个新的成员发送了一个 心跳 它将被添加进群组         任何一个用这个配置安装了复制功能的cache都将被其他的成员发现并标识为可用状态         要设置自动的成员发现 需要指定ehcache配置文件中cacheManagerPeerProviderFactory元素的properties属性 就像下面这样         peerDiscovery=automatic        multicastGroupAddress=multicast address | multicast host name        multicastGroupPort=port        timeToLive= （timeToLive属性详见常见问题部分的描述）        示例        假设你在集群中有两台服务器 你希望同步sampleCache 和sampleCache 每台独立的服务器都要有这样的配置         配置server 和server         <cacheManagerPeerProviderFactoryclass= net sf ehcache distribution RMICacheManagerPeerProviderFactory properties= peerDiscovery=automatic multicastGroupAddress= />multicastGroupPort= timeToLive= 手动进行成员发现        进行手动成员配置要知道每个监听器的IP地址和端口 成员不能在运行时动态地添加和移除 在技术上很难使用广播的情况下就可以手动成员发现 例如在集群的服务器之间有一个不能传送广播报文的路由器 你也可以用手动成员发现进行单向的数据复制 只让server 知道server 而server 不知道server         配置手动成员发现 需要指定ehcache配置文件中cacheManagerPeerProviderFactory的properties属性 像下面这样         peerDiscovery=manual rmiUrls=//server:port/cacheName //server:port/cacheName …        rmiUrls配置的是服务器cache peers的列表 注意不要重复配置         示例        假设你在集群中有两台服务器 你要同步sampleCache 和sampleCache 下面是每个服务器需要的配置         配置server         <cacheManagerPeerProviderFactoryclass= net sf ehcache distribution RMICacheManagerPeerProviderFactory properties= peerDiscovery=manual />rmiUrls=//server : /sampleCache |//server : /sampleCache         配置server         <cacheManagerPeerProviderFactoryclass= net sf ehcache distribution RMICacheManagerPeerProviderFactory properties= peerDiscovery=manual />rmiUrls=//server : /sampleCache |//server : /sampleCache 配置CacheManagerPeerListener        每个CacheManagerPeerListener监听从成员们发向当前CacheManager的消息 配置CacheManagerPeerListener需要指定一个CacheManagerPeerListenerFactory 它以插件的机制实现 用来创建CacheManagerPeerListener         cacheManagerPeerListenerFactory的属性有         class – 一个完整的工厂类名         properties – 只对这个工厂有意义的属性 使用逗号分隔         Ehcache有一个内置的基于RMI的分布系统 它的监听器是RMICacheManagerPeerListener 这个监听器可以用        RMICacheManagerPeerListenerFactory来配置         <cacheManagerPeerListenerFactoryclass= net sf ehcache distribution RMICacheManagerPeerListenerFactory properties= hostName=localhost port= />socketTimeoutMillis= 有效的属性是         hostname （可选） – 运行监听器的服务器名称 标明了做为集群群组的成员的地址 同时也是你想要控制的从集群中接收消息的接口

        在CacheManager初始化的时候会检查hostname是否可用         如果hostName不可用 CacheManager将拒绝启动并抛出一个连接被拒绝的异常         如果指定 hostname将使用InetAddress getLocalHost（） getHostAddress（）来得到         警告 不要将localhost配置为本地地址 因为它在网络中不可见将会导致不能从远程服务器接收信息从而不能复制 在同一台机器上有多个CacheManager的时候 你应该只用localhost来配置         port – 监听器监听的端口         socketTimeoutMillis （可选） – Socket超时的时间 默认是 ms 当你socket同步缓存请求地址比较远 不是本地局域网 你可能需要把这个时间配置大些 不然很可能延时导致同步缓存失败         配置CacheReplicators        每个要进行同步的cache都需要设置一个用来向CacheManagerr的成员复制消息的缓存事件监听器 这个工作要通过为每个cache的配置增加一个cacheEventListenerFactory元素来完成         <! Sample cache named sampleCache ><cache name= sampleCache maxElementsInMemory= eternal= false timeToIdleSeconds= timeToLiveSeconds= overflowToDisk= false ><cacheEventListenerFactory class= net sf ehcache distribution RMICacheReplicatorFactory properties= replicateAsynchronously=true replicatePuts=true replicateUpdates=true replicateUpdatesViaCopy=false replicateRemovals=true /></cache>class – 使用net sf ehcache distribution RMICacheReplicatorFactory        这个工厂支持以下属性         replicatePuts=true | false – 当一个新元素增加到缓存中的时候是否要复制到其他的peers 默认是true         replicateUpdates=true | false – 当一个已经在缓存中存在的元素被覆盖时是否要进行复制 默认是true         replicateRemovals= true | false – 当元素移除的时候是否进行复制 默认是true         replicateAsynchronously=true | false – 复制方式是异步的（指定为true时）还是同步的（指定为false时） 默认是true         replicatePutsViaCopy=true | false – 当一个新增元素被拷贝到其他的cache中时是否进行复制指定为true时为复制 默认是true         replicateUpdatesViaCopy=true | false – 当一个元素被拷贝到其他的cache中时是否进行复制（指定为true时为复制） 默认是true         你可以使用ehcache的默认行为从而减少配置的工作量 默认的行为是以异步的方式复制每件事 你可以像下面的例子一样减少RMICacheReplicatorFactory的属性配置         <! Sample cache named sampleCache All missing RMICacheReplicatorFactory properties default to true ><cache name= sampleCache maxElementsInMemory= eternal= true overflowToDisk= false memoryStoreEvictionPolicy= LFU ><cacheEventListenerFactory class= net sf ehcache distribution RMICacheReplicatorFactory /></cache>        常见的问题        Windows上的Tomcat        有一个Tomcat或者是JDK的bug 在tomcat启动时如果tomcat的安装路径中有空格的话 在启动时RMI监听器会失败 参见 bin/waA =ind &L=rmi users&P= 和 doc/faq howto bugs/l         由于在Windows上安装Tomcat默认是装在 Program Files 文件夹里的 所以这个问题经常发生         广播阻断        自动的peer discovery与广播息息相关 广播可能被路由阻拦 像Xen和VMWare这种虚拟化的技术也可以阻拦广播 如果这些都打开了 你可能还在要将你的网卡的相关配置打开 一个简单的办法可以告诉广播是否有效         那就是使用ehcache remote debugger来看 心跳 是否可用         广播传播的不够远或是传得太远        你可以通过设置badly misnamed time to live来控制广播传播的距离 用广播IP协议时 timeToLive的值指的是数据包可以传递的域或是范围 约定如下         是限制在同一个服务器        是限制在同一个子网        是限制在同一个网站        是限制在同一个region        是限制在同一个大洲        是不限制        译者按 上面这些资料翻译的不够准确 请读者自行寻找原文理解吧         在Java实现中默认值是 也就是在同一个子网中传播 改变timeToLive属性可以限制或是扩展传播的范围    

三 RMI方式缓存集群/配置分布式缓存         RMI 是 Java 的一种远程方法调用技术 是一种点对点的基于 Java 对象的通讯方式 EhCache 从 版本开始就支持 RMI 方式的缓存集群 在集群环境中 EhCache 所有缓存对象的键和值都必须是可序列化的 也就是必须实现 java io Serializable 接口 这点在其它集群方式下也是需要遵守的         下图是 RMI 集群模式的结构图

         采用 RMI 集群模式时 集群中的每个节点都是对等关系 并不存在主节点或者从节点的概念 因此节点间必须有一个机制能够互相认识对方 必须知道其它节点的信息 包括主机地址 端口号等 EhCache 提供两种节点的发现方式 手工配置和自动发现 手工配置方式要求在每个节点中配置其它所有节点的连接信息 一旦集群中的节点发生变化时 需要对缓存进行重新配置         由于 RMI 是 Java 中内置支持的技术 因此使用 RMI 集群模式时 无需引入其它的 Jar 包 EhCache 本身就带有支持 RMI 集群的功能 使用 RMI 集群模式需要在 ehcache xml 配置文件中定义 cacheManagerPeerProviderFactory 节点         分布式同步缓存要让这边的cache知道对方的cache 叫做Peer Discovery（成员发现） EHCache实现成员发现的方式有两种         手动查找        A 在ehcache xml中配置PeerDiscovery成员发现对象        Server 配置 配置本地hostName port是 分别监听 : 的mobileCache和 : 的mobileCache 注意这里的mobileCache是缓存的名称 分别对应着server server 的cache的配置         <xml version= encoding= gbk ><ehcache xmlns:xsi= instance xsi:noNamespaceSchemaLocation= ehcache xsd >        <diskStore path= java io tmpdir />        <!         集群多台服务器中的缓存 这里是要同步一些服务器的缓存        server hostName: port: cacheName:mobileCache        server hostName: port: cacheName:mobileCache        server hostName: port: cacheName:mobileCache        注意 每台要同步缓存的服务器的RMI通信socket端口都不一样 在配置的时候注意设置        >        <! server 的cacheManagerPeerProviderFactory配置 >        <cacheManagerPeerProviderFactory        class= net sf ehcache distribution RMICacheManagerPeerProviderFactory         properties= hostName=localhost         port=         socketTimeoutMillis=         peerDiscovery=manual         rmiUrls=// : /mobileCache|// : /mobileCache         /></ehcache>以上注意cacheManagerPeerProviderFactory元素出现的位置在diskStore下   

    同样在你的另外 台服务器上增加配置        Server 配置本地host port为 分别同步 : 的mobileCache和 : 的mobileCache        <! server 的cacheManagerPeerProviderFactory配置 ><cacheManagerPeerProviderFactory        class= net sf ehcache distribution RMICacheManagerPeerProviderFactory         properties= hostName=localhost         port=         socketTimeoutMillis=         peerDiscovery=manual         rmiUrls=// : /mobileCache|// : /mobileCache />Server 配置本地host port为 分别同步 : 的mobileCache缓存和 : 的mobileCache缓存        <! server 的cacheManagerPeerProviderFactory配置 ><cacheManagerPeerProviderFactory        class= net sf ehcache distribution RMICacheManagerPeerProviderFactory         properties= hostName=localhost         port=         socketTimeoutMillis=         peerDiscovery=manual         rmiUrls=// : /mobileCache|// : /mobileCache />这样就在三台不同的服务器上配置了手动查找cache的PeerProvider成员发现的配置了 值得注意的是你在配置rmiUrls的时候要特别注意url不能重复出现 并且端口 地址都是对的         如果指定 hostname将使用InetAddress getLocalHost（） getHostAddress（）来得到         警告 不要将localhost配置为本地地址 因为它在网络中不可见将会导致不能从远程服务器接收信息从而不能复制 在同一台机器上有多个CacheManager的时候 你应该只用localhost来配置         B 下面配置缓存和缓存同步监听 需要在每台服务器中的ehcache xml文件中增加cache配置和cacheEventListenerFactory cacheLoaderFactory的配置        <defaultCache maxElementsInMemory= eternal= false timeToIdleSeconds= timeToLiveSeconds= overflowToDisk= false /><!         配置自定义缓存        maxElementsInMemory:缓存中允许创建的最大对象数        eternal:缓存中对象是否为永久的 如果是 超时设置将被忽略 对象从不过期         timeToIdleSeconds:缓存数据空闲的最大时间 也就是说如果有一个缓存有多久没有被访问就会被销毁 如果该值是 就意味着元素可以停顿无穷长的时间         timeToLiveSeconds:缓存数据存活的时间 缓存对象最大的的存活时间 超过这个时间就会被销毁 这只能在元素不是永久驻留时有效 如果该值是 就意味着元素可以停顿无穷长的时间         overflowToDisk:内存不足时 是否启用磁盘缓存         memoryStoreEvictionPolicy:缓存满了之后的淘汰算法         每一个小时更新一次缓存（ 小时过期） ><cache name= mobileCache         maxElementsInMemory=         eternal= false         overflowToDisk= true         timeToIdleSeconds=         timeToLiveSeconds=         memoryStoreEvictionPolicy= LFU >        <!         RMI缓存分布同步查找 class使用net sf ehcache distribution RMICacheReplicatorFactory        这个工厂支持以下属性         replicatePuts=true | false – 当一个新元素增加到缓存中的时候是否要复制到其他的peers 默认是true         replicateUpdates=true | false – 当一个已经在缓存中存在的元素被覆盖时是否要进行复制 默认是true         replicateRemovals= true | false – 当元素移除的时候是否进行复制 默认是true         replicateAsynchronously=true | false – 复制方式是异步的 指定为true时 还是同步的 指定为false时 默认是true         replicatePutsViaCopy=true | false – 当一个新增元素被拷贝到其他的cache中时是否进行复制 指定为true时为复制 默认是true         replicateUpdatesViaCopy=true | false – 当一个元素被拷贝到其他的cache中时是否进行复制 指定为true时为复制 默认是true         asynchronousReplicationIntervalMillis=         >        <! 监听RMI同步缓存对象配置 注册相应的的缓存监听类 用于处理缓存事件 如put remove update 和expire >        <cacheEventListenerFactory        class= net sf ehcache distribution RMICacheReplicatorFactory         properties= replicateAsynchronously=true />        replicatePuts=true         replicateUpdates=true         replicateUpdatesViaCopy=false         replicateRemovals=true         <! 用于在初始化缓存 以及自动设置 >        <bootstrapCacheLoaderFactory class= net sf ehcache bootstrap BootstrapCacheLoaderFactory /></cache>        C 这样就完成了 台服务器的配置 下面给出server 的完整的ehcache xml的配置        <xml version= encoding= gbk ><ehcache xmlns:xsi= instance xsi:noNamespaceSchemaLocation= ehcache xsd >        <diskStore path= java io tmpdir />        <!    

    集群多台服务器中的缓存 这里是要同步一些服务器的缓存        server hostName: port: cacheName:mobileCache        server hostName: port: cacheName:mobileCache        server hostName: port: cacheName:mobileCache        注意每台要同步缓存的服务器的RMI通信socket端口都不一样 在配置的时候注意设置        >        <! server 的cacheManagerPeerProviderFactory配置 >        <cacheManagerPeerProviderFactory        class= net sf ehcache distribution RMICacheManagerPeerProviderFactory         properties= hostName=localhost         port=         socketTimeoutMillis=         peerDiscovery=manual         rmiUrls=// : /mobileCache|// : /mobileCache         />        <defaultCache maxElementsInMemory= eternal= false timeToIdleSeconds= timeToLiveSeconds= overflowToDisk= false />        <!         配置自定义缓存        maxElementsInMemory:缓存中允许创建的最大对象数        eternal:缓存中对象是否为永久的 如果是 超时设置将被忽略 对象从不过期         timeToIdleSeconds:缓存数据空闲的最大时间 也就是说如果有一个缓存有多久没有被访问就会被销毁         如果该值是 就意味着元素可以停顿无穷长的时间         timeToLiveSeconds:缓存数据存活的时间 缓存对象最大的的存活时间 超过这个时间就会被销毁         这只能在元素不是永久驻留时有效 如果该值是 就意味着元素可以停顿无穷长的时间         overflowToDisk:内存不足时 是否启用磁盘缓存         memoryStoreEvictionPolicy:缓存满了之后的淘汰算法         每一个小时更新一次缓存（ 小时过期）        >        <cache name= mobileCache         maxElementsInMemory=         eternal= false         overflowToDisk= true         timeToIdleSeconds=         timeToLiveSeconds=         memoryStoreEvictionPolicy= LFU >        <!         RMI缓存分布同步查找 class使用net sf ehcache distribution RMICacheReplicatorFactory        这个工厂支持以下属性         replicatePuts=true | false – 当一个新元素增加到缓存中的时候是否要复制到其他的peers 默认是true         replicateUpdates=true | false – 当一个已经在缓存中存在的元素被覆盖时是否要进行复制 默认是true         replicateRemovals= true | false – 当元素移除的时候是否进行复制 默认是true         replicateAsynchronously=true | false – 复制方式是异步的 指定为true时 还是同步的 指定为false时 默认是true         replicatePutsViaCopy=true | false – 当一个新增元素被拷贝到其他的cache中时是否进行复制 指定为true时为复制 默认是true         replicateUpdatesViaCopy=true | false – 当一个元素被拷贝到其他的cache中时是否进行复制 指定为true时为复制 默认是true         asynchronousReplicationIntervalMillis=         >        <! 监听RMI同步缓存对象配置 注册相应的的缓存监听类 用于处理缓存事件 如put remove update 和expire >        <cacheEventListenerFactory        class= net sf ehcache distribution RMICacheReplicatorFactory         properties= replicateAsynchronously=true />        replicatePuts=true         replicateUpdates=true         replicateUpdatesViaCopy=false         replicateRemovals=true         <! 用于在初始化缓存 以及自动设置 >        <bootstrapCacheLoaderFactory class= net sf ehcache bootstrap BootstrapCacheLoaderFactory />        </cache></ehcache> 自动发现        自动发现配置和手动查找的方式有一点不同 其他的地方都基本是一样的 同样在ehcache xml中增加配置 配置如下        <! 搜索某个网段上的缓存timeToLive        是限制在同一个服务器        是限制在同一个子网        是限制在同一个网站        是限制在同一个region        是限制在同一个大洲        是不限制 ><cacheManagerPeerProviderFactory        class= net sf ehcache distribution RMICacheManagerPeerProviderFactory         properties= peerDiscovery=automatic multicastGroupAddress=         multicastGroupPort= timeToLive= /> lishixinzhi/Article/program/Java/hx/201311/25706

现在比较大型点的系统基本上是APDB的架构:AP指应用程序,DB指数据库端

AP放在一个服务器上,DB放在另一个服务器上

当一个系统比较大,访问的用户数量比较多的时候,比如QQ,上亿用户

这时一个服务器就吃不消了,这样就想到多个服务器跑同一个AP应用

DB端也一样

linux集群指的就是多个服务器跑同一个AP应用,系统管理员的工作

数据库集群指的就是多个服务器跑同一个DB数据库数据库管理员的工作

linux集群基础就要熟悉linux系统

数据库集群基础就要熟悉具体的数据库如oracle,db2,sysbasemysql等

0基础可以学,只是要花时间0基础想搞到集群估计得花3个月时间这还是要有环境的,有人指导才行

集群（Cluster）是由两台或多台节点机（服务器）构成的一种松散耦合的计算节点集合，为用户提

供网络服务或应用程序(包括数据库、Web服务和文件服务等)的单一客户视图，同时提供接近容错机的故

障恢复能力。集群系统一般通过两台或多台节点服务器系统通过相应的硬件及软件互连，每个群集节点都

是运行其自己进程的独立服务器。这些进程可以彼此通信，对网络客户机来说就像是形成了一个单一系统，协同起来向用户提供应用程序、系统资源和数据。除了作为单一系统提供服务，集群系统还具有恢复服务

器级故障的能力。集群系统还可通过在集群中继续增加服务器的方式，从内部增加服务器的处理能力，并

通过系统级的冗余提供固有的可靠性和可用性。

二、集群的分类：

1、高性能计算科学集群：

以解决复杂的科学计算问题为目的的IA集群系统。是并行计算的基础，它可以不使用专门的由十至

上万个独立处理器组成的并行超级计算机，而是采用通过高速连接来链接的一组1/2/4CPU的IA服务器，并且在公共消息传递层上进行通信以运行并行应用程序。这样的计算集群，其处理能力与真正超级并行

机相等，并且具有优良的性价比。

2、负载均衡集群：

负载均衡集群为企业需求提供更实用的系统。该系统使各节点的负载流量可以在服务器集群中尽可

能平均合理地分摊处理。该负载需要均衡计算的应用程序处理端口负载或网络流量负载。这样的系统非

常适合于运行同一组应用程序的大量用户。每个节点都可以处理一部分负载，并且可以在节点之间动态

分配负载，以实现平衡。对于网络流量也如此。通常，网络服务器应用程序接受了大量入网流量，无法

迅速处理，这就需要将流量发送给在其它节点。负载均衡算法还可以根据每个节点不同的可用资源或网

络的特殊环境来进行优化。

一般来说，如果只是为了学习RabbitMQ或者验证业务工程的正确性那么在本地环境或者测试环境上使用其单实例部署就可以了，但是出于MQ中间件本身的可靠性、并发性、吞吐量和消息堆积能力等问题的考虑，在生产环境上一般都会考虑使用RabbitMQ的集群方案。

RabbitMQ本身是基于Erlang编写，Erlang语言天生具备分布式特性（通过同步Erlang集群各节点的erlangcookie来实现）。因此，RabbitMQ天然支持集群。集群是保证可靠性的一种方式，同时可以通过水平扩展以达到增加消息吞吐量能力的目的。

下图为集群的示例：

上面图中采用三个节点组成了一个RabbitMQ的集群，Exchange A（交换器）的元数据信息在所有节点上是一致的，而Queue（存放消息的队列）的完整数据则只会存在于它所创建的那个节点上。，其他节点只知道这个queue的metadata信息和一个指向queue的owner node的指针。

RabbitMQ集群会始终同步四种类型的内部元数据：

因此，当用户访问其中任何一个RabbitMQ节点时，通过rabbitmqctl查询到的queue／user／exchange/vhost等信息都是相同的。

为何RabbitMQ集群仅采用元数据同步的方式

RabbitMQ集群的工作原理图如下：

客户端直接连接队列所在节点

如果有一个消息生产者或者消息消费者通过amqp-client的客户端连接至节点1进行消息的发布或者订阅，那么此时的集群中的消息收发只与节点1相关。

客户端连接的是非队列数据所在节点

如果消息生产者所连接的是节点2或者节点3，此时队列1的完整数据不在该两个节点上，那么在发送消息过程中这两个节点主要起了一个路由转发作用，根据这两个节点上的元数据转发至节点1上，最终发送的消息还是会存储至节点1的队列1上。同样，如果消息消费者所连接的节点2或者节点3，那这两个节点也会作为路由节点起到转发作用，将会从节点1的队列1中拉取消息进行消费。

1 磁盘节点

将配置信息和元信息存储在磁盘上（单节点系统必须是磁盘节点，否则每次重启RabbitMQ之后所有的系统配置信息都会丢失）。

2 内存节点

将配置信息和元信息存储在内存中。性能是优于磁盘节点的。

RabbitMQ要求集群中至少有一个磁盘节点，当节点加入和离开集群时，必须通知磁盘节点（如果集群中唯一的磁盘节点崩溃了，则不能进行创建队列、创建交换器、创建绑定、添加用户、更改权限、添加和删除集群节点）。总之如果唯一磁盘的磁盘节点崩溃，集群是可以保持运行的，但不能更改任何东西。因此建议在集群中设置两个磁盘节点，只要一个可以，就能正常 *** 作。

普通集群模式，并不保证队列的高可用性。尽管交换机、绑定这些可以复制到集群里的任何一个节点，但是队列内容不会复制。虽然该模式解决一项目组节点压力，但队列节点宕机直接导致该队列无法应用，只能等待重启。所以要想在队列节点宕机或故障也能正常应用，就要复制队列内容到集群里的每个节点，也就是必须要创建镜像队列。篇幅有限，RabbitMQ镜像队列原理只能后面再分享了，感兴趣的朋友可以关注下！

集群主要分成三大类 （高可用集群， 负载均衡集群，科学计算集群）

高可用集群( High Availability Cluster)

负载均衡集群(Load Balance Cluster)

科学计算集群(High Performance Computing Cluster)

1、高可用集群(High Availability Cluster)

常见的就是2个节点做成的HA集群，有很多通俗的不科学的名称，比如”双机热备”, “双机互备”, “双机”。高可用集群解决的是保障用户的应用程序持续对外提供服务的能力。 (请注意高可用集群既不是用来保护业务数据的，保护的是用户的业务程序对外不间断提供服务，把因软件/硬件/人为造成的故障对业务的影响降低到最小程度)。

2、负载均衡集群(Load Balance Cluster)

负载均衡系统：集群中所有的节点都处于活动状态，它们分摊系统的工作负载。一般Web服务器集群、数据库集群和应用服务器集群都属于这种类型。

负载均衡集群一般用于相应网络请求的网页服务器，数据库服务器。这种集群可以在接到请求时，检查接受请求较少，不繁忙的服务器，并把请求转到这些服务器上。从检查其他服务器状态这一点上看，负载均衡和容错集群很接近，不同之处是数量上更多。

3、科学计算集群(High Performance Computing Cluster)

高性能计算(High Perfermance Computing)集群，简称HPC集群。这类集群致力于提供单个计算机所不能提供的强大的计算能力。

高性能计算分类：　

31、高吞吐计算(High-throughput Computing)

有一类高性能计算，可以把它分成若干可以并行的子任务，而且各个子任务彼此间没有什么关联。象在家搜寻外星人（ SETI@HOME – Search for Extraterrestrial Intelligence at Home ）就是这一类型应用。

这一项目是利用Internet上的闲置的计算资源来搜寻外星人。SETI项目的服务器将一组数据和数据模式发给Internet上参加SETI的计算节点，计算节点在给定的数据上用给定的模式进行搜索，然后将搜索的结果发给服务器。服务器负责将从各个计算节点返回的数据汇集成完整的 数据。因为这种类型应用的一个共同特征是在海量数据上搜索某些模式，所以把这类计算称为高吞吐计算。

所谓的Internet计算都属于这一类。按照 Flynn的分类，高吞吐计算属于SIMD（Single Instruction/Multiple Data）的范畴。

32、分布计算(Distributed Computing)

另一类计算刚好和高吞吐计算相反，它们虽然可以给分成若干并行的子任务，但是子任务间联系很紧密，需要大量的数据交换。按照Flynn的分类，分布式的高性能计算属于MIMD（Multiple Instruction/Multiple Data）的范畴。

下面说说这几种集群的应用场景：

高可用集群这里不多作说明。

想Dubbo是比较偏向于负载均衡集群，用过的猿友应该知道（不知道的可以自行了解一下），Dubbo同一个服务是可以有多个提供者的，当一个消费者过来，它要消费那个提供者，这里是有负载均衡机制在里面的。

搜索引擎Elasticsearch比较偏向于科学计算集群的分布计算。

而到这里，可能不少猿友都知道，集群的一些术语：集群容错、负载均衡。

我们以Dubbo为例：

集群容错（>

这么计算集群中的数据块:Hadoop大数据集群，就是对分布式计算和服务器集群的一次成功的实践，而学习大数据，Hadoop一直都是必学的一块重点。关于大数据技术基本概念，分布式计算与服务器集群，以上就为大家做了一个简单的介绍了。大数据快速发展，大数据技术也在不断迭代更新，但是分布式计算和服务器集群，仍然是必须掌握的重点技术概念

以上就是关于EhCache 分布式缓存/缓存集群全部的内容，包括:EhCache 分布式缓存/缓存集群、什么是数据库集群、浅谈数据库集群软件优缺点有哪些等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！