分布式内存缓存系统的简单介绍

目录：

• 1、EhCache 分布式缓存/缓存集群
• 2、Tair 分布式缓存简介
• 3、分布式缓存的作用
• 4、分布式缓存的作用？
• 5、分布式存储最佳缓存比
• 6、什么是分布式存储系统？

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 //cacheclass – 使用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/wa?A =ind L=rmi usersP= 和 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

Tair 分布式缓存简介

Tair是由阿里巴巴自主研发的高性能高可用的分布式Key/Value结构数据存储系统，在阿里内部有着大规模的应用。

作为一个分布式系统，Tair由一个中心控制节点（config server）和一系列的服务节点（data server）组成，

Tair主要有下面三种存储引擎：

根据CAP理论，在分布式存储系统中，最多只能实现一致性、可靠性和分区容错性三点中的两点。而由于网络硬件肯定会出现延迟丢包等问题，所以分区容错性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡。

Tair 选择了一致性，同时采用**技术来提高可靠性，并且为了提高效率做了一些优化。事实上在没有错误发生的时候，tair 提供的是一种强一致性，但是在有data server发生故障的时候，客户有可能在一定时间窗口内读不到最新的数据，甚至发生最新数据丢失的情况。

Tair中的每个数据都包含版本号，版本号在每次更新后都会递增。这个特性可以帮助防止数据的并发更新导致的问题。version 机制是乐观锁常用的实现方式。

tair 的存储引擎可以是 MDB、LDB 或 RDB。它们使用缓存、内存或 SSD 硬盘（LDB） 来提升性能。

configserver 不是传统的中心节点，挂了对集群的服务无影响

Tair 使用一致性哈希作为负载均衡策略。

当有某台data server故障不可用的时候， config server会发现这个情况， config server负责重新计算一张新的桶在data server上的分布表， 将原来由故障机器服务的桶的访问重新指派到其它的data server中。这个时候， 可能会发生数据的迁移。比如原来由data server A负责的桶，在新表中需要由 B负责。而B上并没有该桶的数据， 那么就将数据迁移到B上来。同时config server会发现哪些桶的备份数目减少了， 然后根据负载情况在负载较低的data server上增加这些桶的备份。当系统增加data server的时候， config server根据负载，协调data server将他们控制的部分桶迁移到新的data server上。迁移完成后调整路由。当然系统中可能出现减少了某些data server 同时增加另外的一些data server。处理原理同上。 每次路由的变更，config server都会将新的配置信息推给data server。在客户端访问data server的时候， 会发送客户端缓存的路由表的版本号。如果data server发现客户端的版本号过旧，则会通知客户端去config server取一次新的路由表。如果客户端访问某台data server 发生了不可达的情况(该 data server可能宕机了)，客户端会主动去config server取新的路由表。

当迁移发生的时候， 我们举个例子， 假设data server A 要把桶 3，4，5 迁移给data server B。因为迁移完成前，客户端的路由表没有变化，客户端对 3， 4， 5 的访问请求都会路由到A。现在假设 3还没迁移， 4 正在迁移中， 5已经迁移完成。那么如果是对3的访问， 则没什么特别， 跟以前一样。如果是对5的访问， 则A会把该请求转发给B，并且将B的返回结果返回给客户，如果是对4的访问，在A处理，同时如果是对4的修改操作会记录修改log。当桶4迁移完成的时候，还要把log发送到B，在B上应用这些log。最终A B上对于桶4来说， 数据完全一致才是真正的迁移完成。当然如果是因为某data server宕机而引发的迁移， 客户端会收到一张中间临时状态的分配表。这张表中，把宕机的data server所负责的桶临时指派给有其备份data server来处理。 这个时候服务是可用的，但是负载可能不均衡。当迁移完成之后，才能重新达到一个新的负载均衡的状态。

分布式缓存的作用

分布式缓存能够处理大量的动态数据，因此比较适合应用在Web 2.0时代中的社交网站等需要由用户生成内容的场景。从本地缓存扩展到分布式缓存后，关注重点从CPU、内存、缓存之间的数据传输速度差异也扩展到了业务系统、数据库、分布式缓存之间的数据传输速度差异。

常用的分布式缓存包括Redis和Memcached。

Memcached

Memcached是一个高性能的分布式内存对象缓存系统，用于动态Web应用以减轻数据库负载。Memcached通过在内存中缓存数据和对象来减少读取数据库的次数，从而提高动态、数据库驱动网站的速度。

特点：哈希方式存储；全内存操作；简单文本协议进行数据通信；只操作字符型数据；集群由应用进行控制，采用一致性哈希算法。

限制性：数据保存在内存当中的，一旦机器重启，数据会全部丢失；只能操作字符型数据，数据类型贫乏；以root权限运行，而且Memcached本身没有任何权限管理和认证功能，安全性不足；能存储的数据长度有限，最大键长250个字符，储存数据不能超过1M。

Redis

Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。

特点：

Redis支持的数据类型包括：字符串、string、hash、set、sortedset、list；Redis实现持久化的方式：定期将内存快照写入磁盘；写日志；Redis支持主从同步。

限制性：单核运行，在存储大数据的时候性能会有降低；不是全内存操作；主从**是全量**，对实际的系统运营造成了一定负担。

分布式缓存的作用？

分布式缓存主要用于在高并发环境下，减轻数据库的压力，提高系统的响应速度和并发吞吐。当大量的读、写请求涌向数据库时，磁盘的处理速度与内存显然不在一个量级，因此，在数据库之前加一层缓存，能够显著提高系统的响应速度，并降低数据库的压力。作为传统的关系型数据库，MySQL提供完整的ACID操作，支持丰富的数据类型、强大的关联查询、where语句等，能够非常客易地建立查询索引，执行复杂的内连接、外连接、求和、排序、分组等操作，并且支持存储过程、函数等功能，产品成熟度高，功能强大。但是，对于需要应对高并发访问并且存储海量数据的场景来说，出于对性能的考虑，不得不放弃很多传统关系型数据库原本强大的功能，牺牲了系统的易用性，并且使得系统的设计和管理变得更为复杂。这也使得在过去几年中，流行着另一种新的存储解决方案——NoSQL，它与传统的关系型数据库最大的差别在于，它不使用SQL作为查询语言来查找数据，而采用key-value形式进行查找，提供了更高的查询效率及吞吐，并且能够更加方便地进行扩展，存储海量数据，在数千个节点上进行分区，自动进行数据的**和备份。在分布式系统中，消息作为应用间通信的一种方式，得到了十分广泛的应用。消息可以被保存在队列中，直到被接收者取出，由于消息发送者不需要同步等待消息接收者的响应，消息的异步接收降低了系统集成的耦合度，提升了分布式系统协作的效率，使得系统能够更快地响应用户，提供更高的吞吐。

当系统处于峰值压力时，分布式消息队列还能够作为缓冲，削峰填谷，缓解集群的压力，避免整个系统被压垮。垂直化的搜索引擎在分布式系统中是一个非常重要的角色，它既能够满足用户对于全文检索、模糊匹配的需求，解决数据库like查询效率低下的问题，又能够解决分布式环境下，由于采用分库分表，或者使用NoSQL数据库，导致无法进行多表关联或者进行复杂查询的问题。

分布式存储最佳缓存比

作者：深入细节的 SmartX 一线技术团队

近日，VMware 发布了 vSAN 8，对存储架构进行了重大更新。其中最主要的变化，即引入了新的 Express Storage Architecture（ESA）架构：用“存储池”替代了原存储架构（OSA）中的“磁盘组”，并不再需要专用 SSD 承担缓存加速功能，一定程度上避免了 8.0 之前版本中的专用缓存盘利用率低、易发生缓存击穿等问题。

而值得一提的是，在 vSAN 大版本更新之前，SmartX 即通过统一缓存空间和智能冷热数据管理优化了分布式存储缓存机制，有效规避了上述问题。本文将通过重点解读 vSAN（以 vSAN 7 为例）和 SmartX 分布式块存储组件 ZBS* 缓存机制的原理，并测试对比两种缓存机制下虚拟机性能表现，让读者更好地了解两种技术实现机制的区别对业务可能带来的实际影响。

* ZBS 内置于 SmartX 超融合软件 SMTX OS，可与 SmartX 原生虚拟化 ELF 搭配提供服务。

本文重点

vSAN 7 采用划分读写缓存空间的机制，将缓存磁盘按照容量占比划分为写缓冲区（30%）和读缓存区（70%）。这种方式可能出现缓存利用率低、在访问数据量过大时导致缓存击穿，进而引起性能下降等问题。

ZBS 采用统一缓存空间的机制，并通过 2 级 LRU 算法对冷热数据进行管理，在充分利用缓存容量的同时避免了因访问量激增导致虚拟机性能下降的情况。

本文基于相同的硬件配置和 I/O 读写场景，分别测试 VMware 超融合（vSphere 虚拟化 + vSAN 分布式存储）写入 300 GB 数据、SMTX OS（ELF + ZBS）写入 500 GB 数据时虚拟机的性能表现。结果显示，vSAN 7 难以充分利用缓存介质，发生缓存击穿，导致存储性能下降；而 SMTX OS 即便在写入更多数据的情况下也未发生缓存击穿，虚拟机性能保持稳定。

场景问题

混闪配置是超融合或分布式存储现阶段的主流落地模式。混闪配置是指机器中的磁盘使用 SSD + HDD 混合组成，其中 SSD 磁盘作为数据缓存层，而 HDD 磁盘作为数据容量层。以该模式构建的分布式存储池通过软件算法进行冷热数据自动判断，在提供高性能的同时，还可获得较大的存储容量，进而提升资源利用率，获得相对全闪存储更高的性价比。

在将 SSD 磁盘用作数据缓存层时，部分超融合产品会将缓存容量（Cache）划分为读和写各自独立的两部分。例如，vSAN 7 及更早版本会将每个磁盘组（Disk Group）中的缓存磁盘，按照容量占比划分为写缓冲区（30%）和读缓存区（70%），当读取数据未命中缓存或者写缓存已满，将会直接从容量层进行读写。

什么是分布式存储系统？

分布式存储系统

定义

分布式存储系统是大量普通PC服务器通过Internet互联，对外作为一个整体提供存储服务

特性

可扩展

低成本

高性能

易用

挑战

分布式存储系统的挑战主要在于数据、状态信息的持久化，要求在自动迁移、自动容错、并发读写的过程中保证数据的一致性。分布式存储涉及的技术主要来自两个领域：分布式系统以及数据库。

数据分布

一致性

容错

负载均衡

事务与并发控制

易用性

压缩/解压缩

分类

非结构化数据，一般的文档

结构化数据， 存储在关系数据库中

半结构化数据，HTML文档

不同的分布式存储系统适合处理不同类型的数据：

分布式文件系统

非结构化数据，这类数据以对象的形式组织，不同对象之间没有关联，这样的数据一般称为Blob（二进制大对象）数据

典型的有Facebook Haystack 以及 Taobao File System

另外，分布式文件系统也常作为分布式表格系统以及分布式数据库的底层存储，如谷歌的GFS可以作为分布式表格系统Google Bigtable 的底层存储，Amazon的EBS（弹性存储块）系统可以作为分布式数据库（Amazon RDS）的底层存储

总体上看，分布式文件系统存储三种类型的数据：Blob对象、定长块以及大文件

分布式键值系统

较简单的半结构化数据，只提供主键的CRUD（创建、读取、更新、删除）

典型的有Amazon Dynamo 以及 Taobao Tair

分布式表格系统

较复杂的半结构化数据，不仅支持CRUD，而且支持扫描某个主键范围

以表格为单位组织数据，每个表格包括很多行，通过主键标识一行，支持根据主键的CRUD功能以及范围查找功能

典型的有Google Bigtable 以及 Megastore，Microsoft Azure Table Storage，Amazon DynamoDB等

分布式数据库

存储结构化数据，一般是由单机关系数据库扩展而来

典型的包括MySQL数据库分片集群、Amazon RDS以及Microsoft SQL Azure