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

步骤。docker部署，可实现在集群中进行快速分发和快速部署的任务，docker部署和源码部署有步骤的不同，源码部署视乎步骤比docker少，源码部署不仅要安装项目所依赖的语言环境，还要安装组件环境，一些组件安装起来是很麻烦的，远没有docker来的简单方便。

CentOS与Redhat关系

RedHat一直都提供源代码的发行方式，CentOS就是将RedHat发行的源代码重新编译一次，形成一个可使用的二进制版本。由于Linux的源代码是GNU，所以从获得RedHat的源代码到编译成新的二进制，都是合法。只是RedHat是商标，所以必须在新的发行版里将RedHat的商标去掉。

RedHat对这种发行版的态度是：“我们其实并不反对这种发行版，真正向我们付费的用户，他们重视的并不是系统本身，而是我们所提供的商业服务。”所以，CentOS可以得到RedHat的所有功能，甚至是更好的软件。但CentOS并不向用户提供商业支持，当然也不负上任何商业责任。

如果你要将你的RedHat转到CentOS上，因为你不希望为RedHat升级而付费。当然，你必须有丰富UNIX使用经验，因此，RedHat的商业技术支持对你来说并不重要。但如果你是单纯的业务型企业，那么还是建议你选购RedHat软件并购买相应服务。这样可以节省你的IT管理费用，并可得到专业服务。

一句话，选用CentOS还是RedHat，取决于你所在公司是否拥有相应的技术力量：

1、完全可以把CentOS理解为RedHatAS系列！它完全就是对RedHatAS进行改进后发布的，各种 *** 作、使用和RedHat没有区别

2、CentOS完全免费，不存在像RedHatAS系列那样需要序列号的问题

3、CentOS独有的yum命令支持在线升级，可以即时更新系统，不像RedHat那样需要花钱购买支持服务

4、CentOS修正了许多RedHatAS的BUG

5、CentOS版本说明：

CentOS40等同于RedHatAS4

CentOS41等同于RedHatAS4U1

CentOS42等同于RedHatAS4U2

CentOS43等同于RedHatAS4U3

CentOS44等同于RedHatAS4U4

RedHat

Redhat有两大Linux产品系列：免费和收费

1）免费的FedoraCore系列

主要用于桌面版本，提供了较多新特性的支持。

RedHat公司的产品中，有RedHatLinux（如Redhat8、9）和针对企业发行的版本RedHatEnterpriseLinux，都能够通过网络FTP免费的获得并使用，但是在2003年的时候，RedHatLinux停止了开发，这也是为什么没有Redhat10的原因，它的项目有FedoraProject这个项目所取代，并以FedoraCore这个名字发行并提供普通用户免费使用。FedoraCore这个Linux发行版更新很快，大约半年左右就有新的版本出来，目前的版本是FedoraCore6，这个FedoraCore试验的韵味比较浓厚，每次发行都有新的功能被加入到其中，得到的成功结果将被采用道RHEL的发布中。虽说这样，频繁的被改进更新的不安定产品对于企业来说并不是最好的选择，大多数企业还是会选择有偿的RHEL产品。

2）收费的Enterprise系列

这个系列分成：AS/ES/WS等分支。RedHatEnterpriseLinux：redhat的企业版本，简写RHEL。包括如下版本：

1、RedHatEnterpriseLinuxAS

RedHat企业LinuxAS(AdvancedServer)是企业Linux解决方案中最高端的产品，它专为企业的关键应用和数据中心而设计。RedHat企业LinuxAS是唯一支持IBMi系列，p系列和z系列/S-390系统的产品。在IntelX86平台上，RedHat企业LinuxAS可以支持2个以上CPU和大于8GB的内存。

典型的RedHat企业LinuxAS应用环境如下：

数据库和数据库应用软件；WEB和中间件；CRM，ERP，SCM

2、RedHatEnterpriseLinuxESRedHat企业LinuxES(EntryServer)

为IntelX86市场提供了一个从企业门户到企业中层应用的服务器 *** 作系统。它支持1-2CPU和小于8GB内存的系统。它提供了与RedHat企业LinuxAS同样的性能，区别仅在于它支持更小的系统和更低的成本。

典型的RedHat企业LinuxES应用环境如下：

公司WEB架构；网络边缘应用(DHCP,DNS,防火墙等)；邮件和文件/打印服务；中小规模数据库和部门应用软件

3、RedHatEnterpriseLinuxWS

RedHat企业LinuxWS(Workstation)是RedHat企业LinuxAS和ES的桌面/客户端合作伙伴。RedHat企业LinuxWS支持1-2CPU的intel和AMD系统，是桌面应用的最佳环境。它包含各种常用的桌面应用软件(Office工具，邮件，即时信息，浏览器等)，可以运行各种客户-服务器配置工具，软件开发工具和各种应用软件(例如EDA和Oil/Gas应用软件)。RedHat企业LinuxWs和服务器产品由同样的源代码编译而成，但它不提供网络服务功能(如DNS和DHCP)，它只适合作客户端应用。

AS、ES、WS关系

AdvancedServer，缩写即AS。AS在标准Linux内核的基础上，做了性能上的增强，并提高了可靠性，集成了众多常见服务器的驱动程序。可轻松识别IBM/DELL/HP等常见机架式服务器的磁盘阵列卡等设备。AS主要版本2x/3x/4x，也就是我们所说的AS3/AS4，每一个版本还有若干个升级，例如最早推出的AS4后，遇到了一些更新。此时就会发布AS4Update1，以后还会陆续有AS4Update2/Update3等出现简称AS4u1/AS4u2/AS4u3等。这和微软的发布形式也是非常类似的，微软的WindowsNT4从SP1出到SP6，Windows2000从SP1出到SP4等。AS这些Update版本所包含的主要程序包版本都有一定差别，最好不要混用，否则很容易出现问题。Prima和Plesk的安装包，对于各种发行版都有了针对性的设计在下载页面上，通常都会标识出来，支持哪些版本和哪些update的系统。

ES，是AS的精简版本。他与常见的AS系列的区别是，AS支持到4路以上CPU，而ES只能支持两路CPU。AS和ES在大多数程序包上并无区别，只在内核等少数软件包上有差异。AS和ES的售价差别比较大，通常ES用在随服务器一同购买的OEM版本中。例如购买DELL服务器，搭配的Linux会是ES系列。如果要搭配AS系列，则需要多花数千元。

WS，是ES的进一步简化版，主要针对企业内部的桌面办公市场，国内较少采用。

Redhat的FedoraCoreLinux和EnterpriseLinux，都需要遵循GNU协议，即需要发布自己的源代码。所以，对于免费的FedoraCoreLinux，从Redhat网站上可以直接下载ISO刻盘，还能下载到SRPM的ISO，即程序包源码光盘。对于收费的EnterpriseLinux系列，是一款商业产品，所以网站上不能下载到ISO文件，需要购买正式授权方可。由于EnterpriseLinux也需要遵循GNU协议，故必须发布源代码。所以在Redhat的网站上，可以获得AS/ES/WS系列的SRPM源码ISO文件。这些文件可以被自由的下载，修改代码，重新编译使用。

CentOS

CommunityENTerpriseOperatingSystem的项目诞生，它的缩写既是CentOS。CentOS社区将Redhat的网站上的所有源代码下载下来，进行重新编译。重新编译后，由于AS/ES/WS是商业产品，必须将所有Redhat的Logo和标识改成自己的CentOS标识。比如将AS4原版的SRPM源码编译后，就成为了CentOS40。AS4Update1的源码编译后，就成为了CentOS41。AS4Update2的源码编译后，就成为了CentOS42。同理，CentOS的3x/4x都对应着相应的版本。

所以，CentOS就是Redhat的AS/ES/WS的免费版本。使用CentOS，可以获得和AS/ES相同的性能和感受。CentOS除了提供标准的编号1~4或者1~5的若干张ISO以外，还提供了最小化1CD的Server光盘。用Server光盘安装好的系统，就是一个最小化的Linux内核加上常用的>

CentOS与REDHAT区别：

1GPL就是Linux内核所采用的软件许可证，GPL的特点是：你拿人家的代码修改用了，必须把修改后的代码公布。

2所有的Linux都是采用的GPL许可，GPL许可允许GPL软件卖钱，但必须公布源码，所以每个Linux发行版的代码都是全公开的，只是，使用这些代码的人必须也公开修改过的代码。

3Redhat的代码是公开的，但是他的二进制RPM包更新却不免费，这并不违反GPL许可。于是开始有人想到了建立CentOS项目。

4由于Redhat的源代码是公开的，所以CentOS项目的人拿来自己再编译，同样的代码，同样的编译器，编译出来的自然是同样的东西。只不过里面删除了Redhat的Logo以及相应信息，而核心的管理工具还是rpm，只是用一个免费的软件包管理器yum（yellowdogupdatemanager）替代了Redhat中的up2date，up2date更新是连接到Redhat的收费服务站点的，通过钱买来的服务代码通过认证。

5CentOS的使用者众多，因为世界范围内很多人想使用Redhat却有苦恼于Redhat的收费服务。现在CentOS在Linux发行版中排行前10，这个网页的第10个发行版本就是CentOS：TopTen

6从品质上来说，CentOS从理论上应该跟Redhat一样的，毕竟是同样的源码。

上面的6点足够说明CentOS了。

什么是FreeBSD：

FreeBSD是个完整的系统，所有ls、cd这样的小命令都是自己的项目组开发的，而Linux发行版本其实是下载一个Linux内核，下载GNU的Coreutils（包括了常用的核心小命令），自己定制的系统。你应该记得，前些天，我还自己手动编译了一套系统。FreeBSD是从44BSD演变过来的Unix-Like *** 作系统，并不是也使用Linux内核。

FreeBSD使用的软件许可证是BSDL，BSDL的特点是：你可以免费使用我的代码，基于我的代码修改后的代码你不必公开，使用我的代码出了问题你不要告我（原：don’tpayme,don’tsueme）。很多喜欢BSDL的人主要是因为他们认为只要代码能得到最大幅度的利用就是最好的，不象GPL，用了代码还要还。所以很多网络设备以及一些商业公司都赞助FreeBSD的开发，这是个完全免费的软件项目：org

参考Ceph官方安装文档

Openstack环境中，数据存储可分为临时性存储与永久性存储。

临时性存储：主要由本地文件系统提供，并主要用于nova虚拟机的本地系统与临时数据盘，以及存储glance上传的系统镜像；

永久性存储：主要由cinder提供的块存储与swift提供的对象存储构成，以cinder提供的块存储应用最为广泛，块存储通常以云盘的形式挂载到虚拟机中使用。

Openstack中需要进行数据存储的三大项目主要是nova项目（虚拟机镜像文件），glance项目（共用模版镜像）与cinder项目（块存储）。

下图为cinder，glance与nova访问ceph集群的逻辑图：

ceph与openstack集成主要用到ceph的rbd服务，ceph底层为rados存储集群，ceph通过librados库实现对底层rados的访问；

openstack各项目客户端调用librbd，再由librbd调用librados访问底层rados；
实际使用中，nova需要使用libvirtdriver驱动以通过libvirt与qemu调用librbd；cinder与glance可直接调用librbd；

写入ceph集群的数据被条带切分成多个object，object通过hash函数映射到pg（构成pg容器池pool），然后pg通过几圈crush算法近似均匀地映射到物理存储设备osd（osd是基于文件系统的物理存储设备，如xfs，ext4等）。

CEPH PG数量设置与详细介绍

在创建池之前要设置一下每个OSD的最大PG 数量

PG PGP官方计算公式计算器

参数解释：

依据参数使用公式计算新的 PG 的数目:
PG 总数= ((OSD总数100)/最大副本数)/池数
3x100/3/3=3333 ;舍入到2的N次幕为32

openstack集群作为ceph的客户端；下面需要再openstack集群上进行ceph客户端的环境配置

在openstack所有控制和计算节点安装ceph Octopus源码包，centos8有默认安装，但是版本一定要跟连接的ceph版本一致

glance-api 服务运行在3个控制节点， 因此三台控制节点都必须安装

cinder-volume 与 nova-compute 服务运行在3个计算（存储）节点； 因此三台计算节点都必须安装

将配置文件和密钥复制到openstack集群各节点

配置文件就是生成的cephconf；而密钥是 cephclientadminkeyring ，当使用ceph客户端连接至ceph集群时需要使用的密默认密钥，这里我们所有节点都要复制，命令如下

※Glance 作为openstack中镜像服务，支持多种适配器，支持将镜像存放到本地文件系统，>

本章开启 FastAPI 的源码阅读，FastAPI是当下python web中一颗新星，是一个划时代的框架。从诞生便是以快速和简洁为核心理念。
它继承于 Starlette ，是在其基础上的完善与扩展。详细内容可以翻看我之前的源码阅读。

openapi() 与 setup() 是在初始化阶段，对 OpenAPI 文档进行初始化的函数。
而 add_api_route() 一直到 trace() ，是关于路由的函数，它们都是直接对 router 的方法传参引用。所以这些放在解读 routingpy 时一并进行。

除了 Starlette 原生的参数，大量参数都是和API文档相关。
而路由从 Starlette 的 Router 换成了新式的 APIRouter

这两个概念查询了大量文档才搞明白。他们主要是关于文档与反向代理的参数。当使用了Nginx时等反向代理时，从Uvicorn直接访问，和从Nginx代理访问，路径可能出现不一致。比如Nginx中的Fastapi根目录是 127001/api/ ，而Uvicorn角度看是 127001:8000/ 。对于API接口来说，其实这个是没有影响的，因为服务器会自动帮我们解决这个问题。但对于API文档来说，就会出现问题。

因为当我们打开/docs时，网页会寻找 openapijson 。他的是写在html内部的，而不是变化的。这会导致什么问题？

例如当我们从Uvicorn访问 127001:8000/docs 时，他会寻找 /openapijson 即去访问 127001:8000/openapijson (了解前端的应该知道)

但是假如我们这时，从Nginx外来访问文档，假设我们这样设置Nginx:

我们需要访问 127001/api/docs ，才能从代理外部访问。而打开docs时，我们会寻找 openapijson 。

所以这时，它应该在 127001/api/openapi 这个位置存在。
但我们的浏览器不知道这些，他会按照 /openapijson ，会去寻 127001/openapijson 这个位置。所以他不可能找到 openapijson ，自然会启动失败。

这其实是openapi文档前端的问题。

root_path ，是用来解决这个问题的。既然 /openapijson 找不到，那我自己改成 /api/openapijson 不就成了么。
root_path 即是这个 /api ，这个是在定义时手动设置的参数。为了告诉FastAPI，它处在整个主机中的哪个位置。即告知 所在根目录 。这样，FastAPI就有了"自知之明"，乖乖把这个 前缀 加上。来找到正确的 openapijson

加上了 root_path ， openapijson 的位置变成了 /api/openapijson 。当你想重新用Uvicorn提供的地址从代理内访问时，他会去寻找哪？没错 127001:8000/api/openapijson ，但我们从代理内部访问，并不需要这个 前缀 ，但它还是 “善意” 的帮我们加上了，所以这时候内部的访问失灵了。

虽然我们不大可能需要从两个位置访问这个完全一样的api文档。但这点一定要注意。

我在翻官方文档时，看到他们把 root_path 吹得天花乱坠，甚至弃用了 openapi_prefix 参数。但最后是把我弄得晕头转向。

这样要提到 servers 这个参数，官方首先给了这么段示例，稍作修改。

当我们打开API文档时

我们可以切换这个 Servers 时，底下测试接口的发送链接也会变成相应的。

但是记住，切换这个server，下面的接口不会发送变化，只是发送的host会改变。
这代表，虽然可以通过文档，测试多个其他主机的接口。但是这些主机和自己之间，需要拥有一致的接口。这种情况通常像在 线上/开发服务器 或者 服务器集群 中可能出现。虽然不要求完全一致，但为了这样做有实际意义，最好大体上是一致的。

但是我们看到，这是在代理外打开的，如果我们想从代理内打开，需要去掉 root_path 。会发生什么？
我们将 root_path 注释掉：

如果想解决这个问题，只需要将自身手动加入到 Servers 中。

关于 root_path_in_servers ，当 root_path 和 servers 都存在时， root_path 会自动将自己加入到 servers 中。但如果这个置为False，就不会自动加入。(默认为True)

API文档实际上以字符串方式，在FastAPI内部拼接的。实际上就是传统的 模板(Templates) ，这个相信大家都很熟悉了。优点是生成时灵活，但缺点是不容易二次开发。fastapi提供了好几种文档插件，也可以自己添加需要的。

这么长一大串，实际上就一句话 selfrouteradd_api_route() ，其他剩下的那些我暂且省略的，其实基本都是这样的。就是调用router的一个功能。下面我用省略方式将它们列出。

可以看到有些在这里就做了闭包，实际上除了这里的'add_api_route()'他们最终都是要做闭包的。只是过程放在里router里。它们最终的指向都是 routeradd_api_route() ，这是一个添加真正将 endpoint 加入到路由中的方法。
FastAPI 添加路由的方式，在starlette的传统路由列表方式上做了改进，变成了装饰器式。

其实就是通过这些方法作为装饰器，将自身作为 endpoint 传入生成 route 节点，加入到 routes 中。

FastAPI的入口没有太大的变化，借用starlette的 await selfmiddleware_stack(scope, receive, send) 直接进入中间件堆栈。

Oracle数据库的特点
1开放性：
Oracle能在所有主流平台上运行(包括Windows)，完全支持所有的工业标准，采用完全开放策略，可以使客户选择最适合的解决方案，对开发商全力支持。
2可伸缩性，并行性：
Oracle的并行服务器通过使一组结点共享同一簇中的工作来扩展Windownt的能力，提供高可用性和高伸缩性的簇的解决方案。如果WindowsNT不能满足需要，用户可以把数据库移到UNIX中。Oracle的并行服务器对各种UNIX平台的集群机制都有着相当高的集成度。
3性能：
Oracle几乎是性能最高的关系型数据库，保持开放平台下的TPC-D和TPC-C的世界记录。
4客户端支持及应用模式：
Oracle支持多层次网络计算，支持多种工业标准，可以用ODBC、JDBC、OCI等网络客户连接。
5 *** 作性：
Oracle相对于其他RDBMS来讲较复杂，同时提供GUI和命令行，在WindowsNT和Unix下 *** 作相同。
6使用性：
Oracle具有相当长时间的开发经验，完全向下兼容。得到广泛的认可与应用，完全没有风险。
7安全性：
Oracle获得了最高认证级别的ISO标准认证。它提供多层安全性，包括用于评估风险、防止未授权的数据泄露、检测和报告数据库活动，以及通过数据驱动的安全性在数据库中实施数据访问控制的控制。
Oracle数据库的工作原理
1、在数据库服务器上启动Oracle实例。
2、应用程序在客户端的用户进程中运行，启用Oracle网络服务驱动器与服务器建立连接。
3、服务器运行Oracle网络服务驱动器，建立专用的服务器进程执行用户进程。
4、客户端提交事务。
5、服务器进程获取sql语句并检查共享池中是否有相似的sql语句，如果有，服务器进程再检查用户的访问权限；否则分配新的sql共享区分析并执行sql语句。
6、服务器从实际的数据文件或SGA中取得所需数据。
7、服务器进程在SGA中更新数据，进程DBWn在特定条件下将更新过的数据块写回磁盘，进程LGWR在重做日志文件中记录事务。
8、如果事务成功，服务器进程发送消息到应用程序中。
解释：
SGA(System Global Area)：是Oracle Instance的 基本组成部分，在实例启动时分配。是一组包含一个Oracle实例的数据和控制信息的共享内存结构，主要作用是用于存储数据库信息的一个内存区域。
DBWn(Database Writer)：Oracle数据库后台写入进程，是Oracle数据库实例中的一个进程。
LGWR(Log Writer)：也是Oracle的后台进程之一，LGWR的作用是把日志缓存区的数据从内存写到磁盘的REDO文件里，完成数据库对象创建、更新数据等 *** 作过程的记录。

---