Maven常用插件使用说明之deploy

Maven的deploy插件用于把Maven自动构建生成的版本发布到中央代理仓库如Nexus服务器上,也能把第三方依赖库(如Jar包)或一个独立的Jar包直接发布到中央代理仓库供大家共享使用。下面介绍deploy插件的具体用法。假设Nexus服务器已成功安装,Nexus控制台URL为http://199.3.5.164:8081/nexus。

1、自动构建并发布到Nexus服务器(假设发布仓库为releases)

1)修改工程POM文件,增加以下内容:



releases
Internal Releases
http://199.3.5.164:8081/nexus/content/repositories/releases

其中url对应Nexus服务器的Releases仓库路径,repository的id必须与第3)点中的server的id一致。用于发布的仓库必须为Hosted类型。

2)修改Nexus服务器的Releases仓库属性。

进入Nexus控制台,用admin登录。点开“Views/Repositories”选“Repositories”,在Repositories列表中选择Releases,点configuration,Deployment Policy默认为“Disable Redeploy”,点击修改为“Allow Redeploy”并保存。

3)修改用户目录下的settings.xml文件。

settings.xml文件路径为${user.home}/.m2或%{m2_home}/conf/。Windows7系统目录为C:\Users\用户名\.m2。

找到,然后修改信息如下:


releases
deployment deployment

注意:server的id必须和第1)点中的repository的id一致。用户名最好用deployment。

4)重新设定用户deployment的密码。

进入Nexus控制台,点开Security选Users,在用户列表中右键点击deployment用户,选Set Password重新设定deployment的密码为“deployment”,当然也可设置为其他,只要与第3)点server配置一致即可。

5)在工程主目录下(POM文件所在目录)运行“mvn deploy:deploy”即能实现版本的构建和发布。

2、发布第三方依赖库或独立Jar包(假设发布仓库为releases,发布Jar包为test.jar)

1)按第1点中的第2)、3)、4)点进行配置。然后进入到test.jar所在目录。

2)执行“mvn deploy:deploy-file -DgroupId=com.test -DartifactId=test -Dversion=1.0 -Dpackaging=jar -Dfile=test.jar -Durl=http://199.3.5.164:8081/nexus/content/repositories/releases -DrepositoryId=releases”即可。

说明:deploy:deploy-file表示发布独立的文件。

groupId、artifactId和version可根据需要设定。

url为Nexus服务器releases仓库路径。

repositoryId与第1点第3)点中的server的id必须一致。

3)顺便说一下,发布独立的Jar包也可在Nexus控制台中实现。在Repositories列表中选择Releases,点Artifact Upload,指定GAV Definition为“GAV Parameters”,然后输入相应的groupId、artifactId和version、Packaging,再点击“Select Artifact(s) to Upload…”选择指定的Jar文件,最后点“Upload Artifact(s)”即可。

使用nexus搭建maven私服

使用maven的好处就是可以对项目的各种依赖进行统一管理,在pom文件中定以好依赖,就可以从maven中央库或者第三方库中下载到本地。但在企业内部使用也会遇到一些问题,每个使用者都需要去下载相应的依赖包或者插件,效率低下,所以搭建企业内部的私服就很有必要。

搭建私服后,所有的依赖就可以从私服下载,私服会自动判定,如果私服库里没有这个资源,则私服会自动去网上下载,如果私服已经包含所需资源,则可以通过内网提供给使用者,大大提高工作效率。

nexus是maven常用的私服,安装使用都还算方便,用于搭建企业内部的maven私服。

安装nexus

1、下载

下 载地址:http://nexus.sonatype.org/downloads/,这里列出了所有版本,挑一个最新版本来使用。Nexus提供了两种 安装方式,一种是内嵌Jetty的bundle,只要你有JRE就能直接运行。第二种方式是WAR,你只须简单的将其发布到web容器中即可使用。

为了方便就直接选用bundle版本。本文下载的是nexus-oss-webapp-1.9.2.3-bundle.tar.gz 。

2、安装

在指定的目录解压下载的文件

tar xvf nexus-oss-webapp-1.9.2.3-bundle.tar.gz

解 压后会看到两个文件夹,分别是nexus-oss-webapp-1.9.2.3和sonatype-work,前者包含了nexus的运行环境和应用程 序,后者包含了你自己的配置和存储构件的地方。nexus-oss-webapp-1.9.2.3/conf/plexus.properties中可以 修改端口信息已经工作区的路径。

3、启动nexus

进 入nexus-oss-webapp-1.9.2.3/bin/jsw/目录,然后根据OS的版本进入相应的目录,在linux下,运行./nexus start即启动了服务,直接运行./nexus会看到提示信息。neuxs默认监听端口是8081,此时在浏览器中运行访问http://nexus- server-ip:8081/nexus应该可以看到neuxs的界面。

4.配置nexus开启自动启动

以centos为例:

cp /opt/nexus/nexus-2.0.3/bin/nexus /etc/init.d/

打开/etc/init.d/nexus 修改

# Set this to the root of the Nexus installation
NEXUS_HOME=”/opt/nexus/nexus-2.0.3″

chkconfig nexus on   即可

如果是ubuntu

复制过去后运行:update-rc.d nexus defaults

注意配置防火墙规则:

-A INPUT -m state –state NEW -m tcp -p tcp –dport 8081 -j ACCEPT

配置nexus

开启远程索引

新搭建的neuxs环境只是一个空的仓库,需要手动和远程中心库进行同步,nexus默认是关闭远程索引下载,最重要的一件事情就是开启远程索引下载。登陆nexus系统,默认用户名密码为admin/admin123。

点击左边Administration菜单下面的Repositories,找到右边仓库列表中的三个仓库Apache Snapshots,Codehaus Snapshots和Maven Central,然后再没有仓库的configuration下把Download Remote Indexes修改为true。然后在这三个仓库上分别右键,选择Repari Index,这样Nexus就会去下载远程的索引文件。

建立内部仓库

新 建公司的内部仓库,步骤为Repositories –> Add –> Hosted Repository,在页面的下半部分输入框中填入Repository ID和Repository Name即可,比如分别填入myrepo和 my repository,另外把Deployment Policy设置为Allow Redeploy,点击save就创建完成了。

修改neuxs仓库组

Nexus 中仓库组的概念是Maven没有的,在Maven看来,不管你是hosted也好,proxy也好,或者group也好,对我都是一样的,我只管根据 groupId,artifactId,version等信息向你要构件。为了方便Maven的配置,Nexus能够将多个仓库,hosted或者 proxy合并成一个group,这样,Maven只需要依赖于一个group,便能使用所有该group包含的仓库的内容。

neuxs- 1.9.2.3中默认自带了一个名为“Public Repositories”组,点击该组可以对他保护的仓库进行调整,把刚才建立的公司内部仓库加入其中,这样就不需要再在maven中明确指定内部仓库 的地址了。同时创建一个Group ID为public-snapshots、Group Name为Public Snapshots Repositories的组,把Apache Snapshots、Codehaus Snapshots和Snapshots加入其中。

到这里neuxs的安装配置就完成了,下面介绍如何在maven中使用自己的私服。

项目使用maven私服

配置从nexus私服下载构件

maven 安装好默认是没有配置仓库信息,此时maven都默认去远程的中心仓库下载所依赖的构件。既然使用了私服,就需要明确告诉maven去哪里下载构件,可以 在三个地方进行配置,分别是是maven的安装目录下的conf下的settings.xml文件,这个全局配置,再一个是在 userprofile/.m2目录下的settings.xml,如果不存在该文件,可以复制conf下settings.xml,这个是针对当前用户 的,还有一个是在pom.xml中指定,其只对该项目有效,三个文件的优先级是pom.xml大于.m2,.m2大于conf下。

settings.xml的配置如下:

在profiles段增加一个profile

  1. <profile>
  2.   <id>nexus</id>
  3.   <repositories>
  4.     <repository>
  5.         <id>nexus</id>
  6.         <name>local private nexus</name>
  7.         <url>http://192.168.1.68:8081/nexus/content/groups/public</url>
  8.         <releases><enabled>true</enabled></releases>
  9.         <snapshots><enabled>false</enabled></snapshots>
  10.     </repository>
  11.     <repository>
  12.         <id>nexus-snapshots</id>
  13.         <name>local private nexus</name>
  14.         <url>http://192.168.1.68:8081/nexus/content/groups/public-snapshots</url>
  15.         <releases><enabled>false</enabled></releases>
  16.         <snapshots><enabled>true</enabled></snapshots>
  17.     </repository>
  18.   </repositories>
  19.   <pluginRepositories>
  20.     <pluginRepository>
  21.         <id>nexus</id>
  22.         <name>local private nexus</name>
  23.         <url>http://192.168.1.68:8081/nexus/content/groups/public</url>
  24.         <releases><enabled>true</enabled></releases>
  25.         <snapshots><enabled>false</enabled></snapshots>
  26.     </pluginRepository>
  27.     <pluginRepository>
  28.         <id>nexus-snapshots</id>
  29.         <name>local private nexus</name>
  30.         <url>http://192.168.1.68:8081/nexus/content/groups/public-snapshots</url>
  31.         <releases><enabled>false</enabled></releases>
  32.         <snapshots><enabled>true</enabled></snapshots>
  33.     </pluginRepository>
  34.    </pluginRepositories>
  35. </profile>

上 述的id,name可以根据自己的喜好来定义,保证多个repository的id不重复即可,主要是url的配置,可以在nexus的 repositories列表中找到对应的url,就是repositories的Repository Path,刚才我们已经在neuxs中定于了仓库组,这里就取对应组的Repository Path信息即可。

另 外,仓库是两种主要构件的家。第一种构件被用作其它构件的依赖。这是中央仓库中存储的大部分构件类型。另外一种构件类型是插件。如果不配置 pluginRepositories,那么执行maven动作时,还是会看到去远程中心库下载需要的插件构件,所以这里一定要加上这个。

在settings.xml中指使配置了profile还不行,需要激活它,在activeProfiles段,增加如下配置:

<activeProfile>nexus</activeProfile>

此处activeProfile中的内容就上面定义profile的id。

其实也可以不进行上述配置,只在项目的pom.xml里配置即可。配置如下
pom.xml配置如下:

  1. <repositories>
  2.       <repository>
  3.           <id>nexus</id>
  4.           <name>local private nexus</name>
  5.           <url>http://192.168.1.68:8081/nexus/content/groups/public</url>
  6.           <releases>
  7.               <enabled>true</enabled>
  8.           </releases>
  9.           <snapshots>
  10.               <enabled>false</enabled>
  11.           </snapshots>
  12.       </repository>
  13.   </repositories>
  14.   <pluginRepositories>
  15.       <pluginRepository>
  16.           <id>nexus</id>
  17.           <name>local private nexus</name>
  18.           <url>http://192.168.1.68:8081/nexus/content/groups/public</url>
  19.           <releases>
  20.               <enabled>true</enabled>
  21.           </releases>
  22.           <snapshots>
  23.               <enabled>false</enabled>
  24.           </snapshots>
  25.       </pluginRepository>
  26.   </pluginRepositories>

其中id,name都无所谓,关键不能把url弄错。

有了上述配置,当在项目执行maven操作时,如果本地库中没有依赖的构件,maven会去私服下载,如果私服也没有,私服会去远程中心库下载,同时会在私服的本地缓存,这样如果第二个人再要用到这个构件,私服就直接提供下载。

deploy项目到私服

对于企业自身的项目,也可以提交到搭建的nexus私服中,首先需要在项目的pom.xml中配置deploy到哪,配置如下:

  1. <distributionManagement>
  2. <repository>
  3. <id>releases</id>
  4. <name>Nexus Release Repository</name>
  5. <url>http://10.1.81.199:8081/nexus/content/repositories/releases/</url>
  6. </repository>
  7. <snapshotRepository>
  8. <id>snapshots</id>
  9. <name>Nexus Snapshot Repository</name>
  10. <url>http://10.1.81.199:8081/nexus/content/repositories/snapshots/</url>
  11. </snapshotRepository>
  12. </distributionManagement>

这是提交还是会报错,因为没有提交到nexus的权限

在maven的conf目录下,配置setting.xml

  1. <server>
  2.   <id>releases</id>
  3.   <username>admin</username>
  4.   <password>admin123</password>
  5. </server>
  6. lt;server>
  7. <id>snapshots</id>
  8. <username>admin</username>
  9. <password>admin123</password>
  10. </server>

注意这里的id应该和pom中配置的远程发布管理库的ID所对应才行。用户名和密码都是nexus的。再次deploy即可。

发布的项目带源码发布到nexus

需要配置插件来实现,在pom.xml中增加如下插件
  1. <plugin>
  2.             <groupId>org.apache.maven.plugins</groupId>
  3.             <artifactId>maven-source-plugin</artifactId>
  4.             <executions>
  5.                 <execution>
  6.                     <id>attach-sources</id>
  7.                     <goals>
  8.                         <goal>jar</goal>
  9.                     </goals>
  10.                 </execution>
  11.             </executions>
  12.         </plugin>

deploy时候不进行test

由于我deploy时候,自动进行test,而我的test需要的环境可能已经没有了导致无法deploy
于是可增加参数
deploy -Dmaven.test.skip=true
就可以跳过test环节。我是在eclipse中用的, run—build… 里输入这些就可以了

常见问题:

更新遇到错误:

was cached in the local repository, resolution will not be reattempted until the update interval of nexus has elapsed or updates are forced
去自己的.m2 文件夹下把 xxx.lastUpdated文件全部删掉,重新运行maven,ok!

或者在用maven时加 -U参数,就可以忽略xxx.lastUpdated..

Redis与Memcache的区别及应用场景

1.  MySQL+Memcached架构的问题

Memcached采用客户端服务器的架构,客户端和服务器端的通讯使用自定义的协议标准,只要满足协议格式要求,客户端Library可以用任何语言实现。

Memcached服务器使用基于Slab的内存管理方式,有利于减少内存碎片和频繁分配销毁内存所带来的开销。各个Slab按需动态分配一个page的内存(和4Kpage的概念不同,这里默认page1M),page内部按照不同slab class的尺寸再划分为内存chunk供服务器存储KV键值对使用(slab机制相当于内存池机制, 实现从操作系统分配一大块内存, 然后 memcached 自己管理这块内存, 负责分配与回收。)

关于memcached的内存分配机制:Memcached 内存分配机制介绍

实际mysql是适合进行海量数据存储的,通过Memcached将热点数据加载到cache,加速访问,很多公司都曾经使用过这样的架构,但随着业务数据量的不断增加,和访问量的持续增长,我们遇到了很多问题:

1.MySQL需要不断进行拆库拆表,Memcached也需不断跟着扩容,扩容和维护工作占据大量开发时间。

2.Memcached与MySQL数据库数据一致性问题。

3.Memcached数据命中率低或down机,大量访问直接穿透到DB,MySQL无法支撑。

4.跨机房cache同步问题。

关于memcached问题:Memcache存储大数据的问题

众多NoSQL百花齐放,如何选择

最近几年,业界不断涌现出很多各种各样的NoSQL产品,那么如何才能正确地使用好这些产品,最大化地发挥其长处,是我们需要深入研究和思考的问题,实际归根结底最重要的是了解这些产品的定位,并且了解到每款产品的tradeoffs,在实际应用中做到扬长避短,总体上这些NoSQL主要用于解决以下几种问题

1.少量数据存储,高速读写访问。此类产品通过数据全部in-momery 的方式来保证高速访问,同时提供数据落地的功能,实际这正是Redis最主要的适用场景。

2.海量数据存储,分布式系统支持,数据一致性保证,方便的集群节点添加/删除。

3.这方面最具代表性的是dynamo和bigtable 2篇论文所阐述的思路。前者是一个完全无中心的设计,节点之间通过gossip方式传递集群信息,数据保证最终一致性,后者是一个中心化的方案设计,通过类似一个分布式锁服务来保证强一致性,数据写入先写内存和redo log,然后定期compat归并到磁盘上,将随机写优化为顺序写,提高写入性能。

4.Schema free,auto-sharding等。比如目前常见的一些文档数据库都是支持schema-free的,直接存储json格式数据,并且支持auto-sharding等功能,比如MongoDB

面对这些不同类型的NoSQL产品,我们需要根据我们的业务场景选择最合适的产品。

redis最适合所有数据in-momory的场景,虽然Redis也提供持久化功能,但实际更多的是一个disk-backed的功能,跟传统意义上的持久化有比较大的差别,那么可能大家就会有疑问,似乎Redis更像一个加强版的Memcached,那么何时使用Memcached,何时使用Redis呢?

memcache和redis的比较:

  • 性能方面:没有必要过多的关心性能,因为二者的性能都已经足够高了。由于Redis只使用单核,而Memcached可以使用多核,所以在比较上,平均每一个核上Redis在存储小数据时比Memcached性能更高。而在100k以上的数据中,Memcached性能要高于Redis,虽然Redis最近也在存储大数据的性能上进行优化,但是比起Memcached,还是稍有逊色。说了这么多,结论是,无论你使用哪一个,每秒处理请求的次数都不会成为瓶颈。(比如瓶颈可能会在网卡)
  • 内存使用效率:使用简单的key-value存储的话,Memcached的内存利用率更高,而如果Redis采用hash结构来做key-value存储,由于其组合式的压缩,其内存利用率会高于Memcached。当然,这和你的应用场景和数据特性有关。
  • 数据持久化:如果你对数据持久化和数据同步有所要求,那么推荐你选择Redis,因为这两个特性Memcached都不具备。即使你只是希望在升级或者重启系统后缓存数据不会丢失,选择Redis也是明智的。
  • 数据结构:当然,最后还得说到你的具体应用需求。Redis相比Memcached来说,拥有更多的数据结构和并支持更丰富的数据操作,通常在Memcached里,你需要将数据拿到客户端来进行类似的修改再set回去。这大大增加了网络IO的次数和数据体积。在Redis中,这些复杂的操作通常和一般的GET/SET一样高效。所以,如果你需要缓存能够支持更复杂的结构和操作,那么Redis会是不错的选择。
  • 网络IO模型方面:Memcached是多线程,分为监听线程、worker线程,引入锁,带来了性能损耗。Redis使用单线程的IO复用模型,将速度优势发挥到最大,也提供了较简单的计算功能
  • 内存管理方面:Memcached使用预分配的内存池的方式,带来一定程度的空间浪费 并且在内存仍然有很大空间时,新的数据也可能会被剔除,而Redis使用现场申请内存的方式来存储数据,不会剔除任何非临时数据 Redis更适合作为存储而不是cache
  • 数据的一致性方面:Memcached提供了cas命令来保证.而Redis提供了事务的功能,可以保证一串 命令的原子性,中间不会被任何操作打断

如果简单地比较Redis与Memcached的区别,大多数都会得到以下观点:

1 、Redis不仅仅支持简单的k/v类型的数据,同时还提供list,set,zset,hash等数据结构的存储。

2 、Redis支持数据的备份,即master-slave模式的数据备份。

3 、Redis支持数据的持久化,可以将内存中的数据保持在磁盘中,重启的时候可以再次加载进行使用。

4、Redis可以实现主从复制,实现故障恢复。

5、Redis的Sharding技术: 很容易将数据分布到多个Redis实例中

2.  Redis常用数据类型

Redis最为常用的数据类型主要有以下:

  • String
  • Hash
  • List
  • Set
  • Sorted set
  • pub/sub
  • Transactions

在具体描述这几种数据类型之前,我们先通过一张图了解下Redis内部内存管理中是如何描述这些不同数据类型的:

         首先Redis内部使用一个redisObject对象来表示所有的key和value,redisObject最主要的信息如上图所示:

type代表一个value对象具体是何种数据类型,

encoding是不同数据类型在redis内部的存储方式,

比如:type=string代表value存储的是一个普通字符串,那么对应的encoding可以是raw或者是int,如果是int则代表实际redis内部是按数值型类存储和表示这个字符串的,当然前提是这个字符串本身可以用数值表示,比如:”123″ “456”这样的字符串。

这里需要特殊说明一下vm字段,只有打开了Redis的虚拟内存功能,此字段才会真正的分配内存,该功能默认是关闭状态的,该功能会在后面具体描述。通过上图我们可以发现Redis使用redisObject来表示所有的key/value数据是比较浪费内存的,当然这些内存管理成本的付出主要也是为了给Redis不同数据类型提供一个统一的管理接口,实际作者也提供了多种方法帮助我们尽量节省内存使用,我们随后会具体讨论。

3.  各种数据类型应用和实现方式

下面我们先来逐一的分析下这7种数据类型的使用和内部实现方式:

  • String:
Strings 数据结构是简单的key-value类型,value其实不仅是String,也可以是数字.

常用命令:  set,get,decr,incr,mget 等。

应用场景:String是最常用的一种数据类型,普通的key/ value 存储都可以归为此类.即可以完全实现目前 Memcached 的功能,并且效率更高。还可以享受Redis的定时持久化,操作日志及 Replication等功能。除了提供与 Memcached 一样的get、set、incr、decr 等操作外,Redis还提供了下面一些操作:

      • 获取字符串长度
      • 往字符串append内容
      • 设置和获取字符串的某一段内容
      • 设置及获取字符串的某一位(bit)
      • 批量设置一系列字符串的内容

实现方式:String在redis内部存储默认就是一个字符串,被redisObject所引用,当遇到incr,decr等操作时会转成数值型进行计算,此时redisObject的encoding字段为int。

  • Hash

常用命令:hget,hset,hgetall 等。

应用场景:在Memcached中,我们经常将一些结构化的信息打包成HashMap,在客户端序列化后存储为一个字符串的值,比如用户的昵称、年龄、性别、积分等,这时候在需要修改其中某一项时,通常需要将所有值取出反序列化后,修改某一项的值,再序列化存储回去。这样不仅增大了开销,也不适用于一些可能并发操作的场合(比如两个并发的操作都需要修改积分)。而Redis的Hash结构可以使你像在数据库中Update一个属性一样只修改某一项属性值。

我们简单举个实例来描述下Hash的应用场景,比如我们要存储一个用户信息对象数据,包含以下信息:

用户ID为查找的key,存储的value用户对象包含姓名,年龄,生日等信息,如果用普通的key/value结构来存储,主要有以下2种存储方式:

第一种方式将用户ID作为查找key,把其他信息封装成一个对象以序列化的方式存储,这种方式的缺点是,增加了序列化/反序列化的开销,并且在需要修改其中一项信息时,需要把整个对象取回,并且修改操作需要对并发进行保护,引入CAS等复杂问题。

第二种方法是这个用户信息对象有多少成员就存成多少个key-value对儿,用用户ID+对应属性的名称作为唯一标识来取得对应属性的值,虽然省去了序列化开销和并发问题,但是用户ID为重复存储,如果存在大量这样的数据,内存浪费还是非常可观的。

那么Redis提供的Hash很好的解决了这个问题,Redis的Hash实际是内部存储的Value为一个HashMap,并提供了直接存取这个Map成员的接口,如下图:

也就是说,Key仍然是用户ID, value是一个Map,这个Map的key是成员的属性名,value是属性值,这样对数据的修改和存取都可以直接通过其内部Map的Key(Redis里称内部Map的key为field), 也就是通过 key(用户ID) + field(属性标签) 就可以操作对应属性数据了,既不需要重复存储数据,也不会带来序列化和并发修改控制的问题。很好的解决了问题。

这里同时需要注意,Redis提供了接口(hgetall)可以直接取到全部的属性数据,但是如果内部Map的成员很多,那么涉及到遍历整个内部Map的操作,由于Redis单线程模型的缘故,这个遍历操作可能会比较耗时,而另其它客户端的请求完全不响应,这点需要格外注意。

实现方式:

上面已经说到Redis Hash对应Value内部实际就是一个HashMap,实际这里会有2种不同实现,这个Hash的成员比较少时Redis为了节省内存会采用类似一维数组的方式来紧凑存储,而不会采用真正的HashMap结构,对应的value redisObject的encoding为zipmap,当成员数量增大时会自动转成真正的HashMap,此时encoding为ht。

  • List

常用命令:lpush,rpush,lpop,rpop,lrange等。

应用场景:

Redis list的应用场景非常多,也是Redis最重要的数据结构之一,比如twitter的关注列表,粉丝列表等都可以用Redis的list结构来实现。

Lists 就是链表,相信略有数据结构知识的人都应该能理解其结构。使用Lists结构,我们可以轻松地实现最新消息排行等功能。Lists的另一个应用就是消息队列,
可以利用Lists的PUSH操作,将任务存在Lists中,然后工作线程再用POP操作将任务取出进行执行。Redis还提供了操作Lists中某一段的api,你可以直接查询,删除Lists中某一段的元素。

实现方式:

Redis list的实现为一个双向链表,即可以支持反向查找和遍历,更方便操作,不过带来了部分额外的内存开销,Redis内部的很多实现,包括发送缓冲队列等也都是用的这个数据结构。

  • Set

常用命令:

sadd,spop,smembers,sunion 等。

应用场景:

Redis set对外提供的功能与list类似是一个列表的功能,特殊之处在于set是可以自动排重的,当你需要存储一个列表数据,又不希望出现重复数据时,set是一个很好的选择,并且set提供了判断某个成员是否在一个set集合内的重要接口,这个也是list所不能提供的。

Sets 集合的概念就是一堆不重复值的组合。利用Redis提供的Sets数据结构,可以存储一些集合性的数据,比如在微博应用中,可以将一个用户所有的关注人存在一个集合中,将其所有粉丝存在一个集合。Redis还为集合提供了求交集、并集、差集等操作,可以非常方便的实现如共同关注、共同喜好、二度好友等功能,对上面的所有集合操作,你还可以使用不同的命令选择将结果返回给客户端还是存集到一个新的集合中。

实现方式:

set 的内部实现是一个 value永远为null的HashMap,实际就是通过计算hash的方式来快速排重的,这也是set能提供判断一个成员是否在集合内的原因。

  • Sorted Set

常用命令:

zadd,zrange,zrem,zcard等

使用场景:

Redis sorted set的使用场景与set类似,区别是set不是自动有序的,而sorted set可以通过用户额外提供一个优先级(score)的参数来为成员排序,并且是插入有序的,即自动排序。当你需要一个有序的并且不重复的集合列表,那么可以选择sorted set数据结构,比如twitter 的public timeline可以以发表时间作为score来存储,这样获取时就是自动按时间排好序的。

另外还可以用Sorted Sets来做带权重的队列,比如普通消息的score为1,重要消息的score为2,然后工作线程可以选择按score的倒序来获取工作任务。让重要的任务优先执行。

实现方式:

Redis sorted set的内部使用HashMap和跳跃表(SkipList)来保证数据的存储和有序,HashMap里放的是成员到score的映射,而跳跃表里存放的是所有的成员,排序依据是HashMap里存的score,使用跳跃表的结构可以获得比较高的查找效率,并且在实现上比较简单。

  • Pub/Sub

Pub/Sub 从字面上理解就是发布(Publish)与订阅(Subscribe),在Redis中,你可以设定对某一个key值进行消息发布及消息订阅,当一个key值上进行了消息发布后,所有订阅它的客户端都会收到相应的消息。这一功能最明显的用法就是用作实时消息系统,比如普通的即时聊天,群聊等功能。

  • Transactions

谁说NoSQL都不支持事务,虽然Redis的Transactions提供的并不是严格的ACID的事务(比如一串用EXEC提交执行的命令,在执行中服务器宕机,那么会有一部分命令执行了,剩下的没执行),但是这个Transactions还是提供了基本的命令打包执行的功能(在服务器不出问题的情况下,可以保证一连串的命令是顺序在一起执行的,中间有会有其它客户端命令插进来执行)。Redis还提供了一个Watch功能,你可以对一个key进行Watch,然后再执行Transactions,在这过程中,如果这个Watched的值进行了修改,那么这个Transactions会发现并拒绝执行。

4.  Redis实际应用场景

Redis在很多方面与其他数据库解决方案不同:它使用内存提供主存储支持,而仅使用硬盘做持久性的存储;它的数据模型非常独特,用的是单线程。另一个大区别在于,你可以在开发环境中使用Redis的功能,但却不需要转到Redis。

转向Redis当然也是可取的,许多开发者从一开始就把Redis作为首选数据库;但设想如果你的开发环境已经搭建好,应用已经在上面运行了,那么更换数据库框架显然不那么容易。另外在一些需要大容量数据集的应用,Redis也并不适合,因为它的数据集不会超过系统可用的内存。所以如果你有大数据应用,而且主要是读取访问模式,那么Redis并不是正确的选择。

        然而我喜欢Redis的一点就是你可以把它融入到你的系统中来,这就能够解决很多问题,比如那些你现有的数据库处理起来感到缓慢的任务。这些你就可以通过Redis来进行优化,或者为应用创建些新的功能。在本文中,我就想探讨一些怎样将Redis加入到现有的环境中,并利用它的原语命令等功能来解决 传统环境中碰到的一些常见问题。在这些例子中,Redis都不是作为首选数据库。

1、显示最新的项目列表

下面这个语句常用来显示最新项目,随着数据多了,查询毫无疑问会越来越慢。

  1. SELECT * FROM foo WHERE … ORDER BY time DESC LIMIT 10

        在Web应用中,“列出最新的回复”之类的查询非常普遍,这通常会带来可扩展性问题。这令人沮丧,因为项目本来就是按这个顺序被创建的,但要输出这个顺序却不得不进行排序操作。

        类似的问题就可以用Redis来解决。比如说,我们的一个Web应用想要列出用户贴出的最新20条评论。在最新的评论边上我们有一个“显示全部”的链接,点击后就可以获得更多的评论。

        我们假设数据库中的每条评论都有一个唯一的递增的ID字段。

        我们可以使用分页来制作主页和评论页,使用Redis的模板,每次新评论发表时,我们会将它的ID添加到一个Redis列表:

  1. LPUSH latest.comments <ID>

       我们将列表裁剪为指定长度,因此Redis只需要保存最新的5000条评论:

       LTRIM latest.comments 0 5000

      每次我们需要获取最新评论的项目范围时,我们调用一个函数来完成(使用伪代码):

  1. FUNCTION get_latest_comments(start, num_items):
  2.     id_list = redis.lrange(“latest.comments”,start,start+num_items – 1)
  3.     IF id_list.length < num_items
  4.         id_list = SQL_DB(“SELECT … ORDER BY time LIMIT …”)
  5.     END
  6.     RETURN id_list
  7. END

 

      这里我们做的很简单。在Redis中我们的最新ID使用了常驻缓存,这是一直更新的。但是我们做了限制不能超过5000个ID,因此我们的获取ID函数会一直询问Redis。只有在start/count参数超出了这个范围的时候,才需要去访问数据库。

        我们的系统不会像传统方式那样“刷新”缓存,Redis实例中的信息永远是一致的。SQL数据库(或是硬盘上的其他类型数据库)只是在用户需要获取“很远”的数据时才会被触发,而主页或第一个评论页是不会麻烦到硬盘上的数据库了。

2、删除与过滤

      我们可以使用LREM来删除评论。如果删除操作非常少,另一个选择是直接跳过评论条目的入口,报告说该评论已经不存在。

       有些时候你想要给不同的列表附加上不同的过滤器。如果过滤器的数量受到限制,你可以简单的为每个不同的过滤器使用不同的Redis列表。毕竟每个列表只有5000条项目,但Redis却能够使用非常少的内存来处理几百万条项目。

3、排行榜相关

      另一个很普遍的需求是各种数据库的数据并非存储在内存中,因此在按得分排序以及实时更新这些几乎每秒钟都需要更新的功能上数据库的性能不够理想。

      典型的比如那些在线游戏的排行榜,比如一个Facebook的游戏,根据得分你通常想要:

         – 列出前100名高分选手

         – 列出某用户当前的全球排名

      这些操作对于Redis来说小菜一碟,即使你有几百万个用户,每分钟都会有几百万个新的得分。

      模式是这样的,每次获得新得分时,我们用这样的代码:

      ZADD leaderboard  <score>  <username>

     你可能用userID来取代username,这取决于你是怎么设计的。

      得到前100名高分用户很简单:ZREVRANGE leaderboard 0 99。

      用户的全球排名也相似,只需要:ZRANK leaderboard <username>。

4、按照用户投票和时间排序

      排行榜的一种常见变体模式就像Reddit或Hacker News用的那样,新闻按照类似下面的公式根据得分来排序:

       score = points / time^alpha

      因此用户的投票会相应的把新闻挖出来,但时间会按照一定的指数将新闻埋下去。下面是我们的模式,当然算法由你决定。

      模式是这样的,开始时先观察那些可能是最新的项目,例如首页上的1000条新闻都是候选者,因此我们先忽视掉其他的,这实现起来很简单。

      每次新的新闻贴上来后,我们将ID添加到列表中,使用LPUSH + LTRIM,确保只取出最新的1000条项目。

      有一项后台任务获取这个列表,并且持续的计算这1000条新闻中每条新闻的最终得分。计算结果由ZADD命令按照新的顺序填充生成列表,老新闻则被清除。这里的关键思路是排序工作是由后台任务来完成的。

5、处理过期项目

      另一种常用的项目排序是按照时间排序。我们使用unix时间作为得分即可。

      模式如下:

       – 每次有新项目添加到我们的非Redis数据库时,我们把它加入到排序集合中。这时我们用的是时间属性,current_time和time_to_live。

       – 另一项后台任务使用ZRANGE…SCORES查询排序集合,取出最新的10个项目。如果发现unix时间已经过期,则在数据库中删除条目。

6、计数

       Redis是一个很好的计数器,这要感谢INCRBY和其他相似命令。

       我相信你曾许多次想要给数据库加上新的计数器,用来获取统计或显示新信息,但是最后却由于写入敏感而不得不放弃它们。

       好了,现在使用Redis就不需要再担心了。有了原子递增(atomic increment),你可以放心的加上各种计数,用GETSET重置,或者是让它们过期。

       例如这样操作:

         INCR user:<id> EXPIRE

         user:<id> 60

       你可以计算出最近用户在页面间停顿不超过60秒的页面浏览量,当计数达到比如20时,就可以显示出某些条幅提示,或是其它你想显示的东西。

7、特定时间内的特定项目

        另一项对于其他数据库很难,但Redis做起来却轻而易举的事就是统计在某段特点时间里有多少特定用户访问了某个特定资源。比如我想要知道某些特定的注册用户或IP地址,他们到底有多少访问了某篇文章。

      每次我获得一次新的页面浏览时我只需要这样做:

       SADD page:day1:<page_id> <user_id>

      当然你可能想用unix时间替换day1,比如time()-(time()%3600*24)等等。

      想知道特定用户的数量吗?只需要使用SCARD page:day1:<page_id>。

       需要测试某个特定用户是否访问了这个页面?SISMEMBER page:day1:<page_id>。

8、实时分析正在发生的情况,用于数据统计与防止垃圾邮件等

        我们只做了几个例子,但如果你研究Redis的命令集,并且组合一下,就能获得大量的实时分析方法,有效而且非常省力。使用Redis原语命令,更容易实施垃圾邮件过滤系统或其他实时跟踪系统。

9、Pub/Sub

       Redis的Pub/Sub非常非常简单,运行稳定并且快速。支持模式匹配,能够实时订阅与取消频道。

10、队列

        你应该已经注意到像list push和list pop这样的Redis命令能够很方便的执行队列操作了,但能做的可不止这些:比如Redis还有list pop的变体命令,能够在列表为空时阻塞队列。

       现代的互联网应用大量地使用了消息队列(Messaging)。消息队列不仅被用于系统内部组件之间的通信,同时也被用于系统跟其它服务之间的交互。消息队列的使用可以增加系统的可扩展性、灵活性和用户体验。非基于消息队列的系统,其运行速度取决于系统中最慢的组件的速度(注:短板效应)。而基于消息队列可以将系统中各组件解除耦合,这样系统就不再受最慢组件的束缚,各组件可以异步运行从而得以更快的速度完成各自的工作。

    此外,当服务器处在高并发操作的时候,比如频繁地写入日志文件。可以利用消息队列实现异步处理。从而实现高性能的并发操作。

11、缓存

        Redis的缓存部分值得写一篇新文章,我这里只是简单的说一下。Redis能够替代memcached,让你的缓存从只能存储数据变得能够更新数据,因此你不再需要每次都重新生成数据了。

此部分内容的原文地址:http://antirez.com/post/take-advantage-of-redis-adding-it-to-your-stack.html

5.  国内外三个不同领域巨头分享的Redis实战经验及使用场景

随着应用对高性能需求的增加,NoSQL逐渐在各大名企的系统架构中生根发芽。这里我们将为大家分享社交巨头新浪微博、传媒巨头Viacom及图片分享领域佼佼者Pinterest带来的Redis实践,首先我们看新浪微博 @启盼cobain的Redis实战经验分享:

一、新浪微博:史上最大的Redis集群

Tape is Dead,Disk is Tape,Flash is Disk,RAM Locality is King. — Jim Gray

Redis不是比较成熟的memcache或者Mysql的替代品,是对于大型互联网类应用在架构上很好的补充。现在有越来越多的应用也在纷纷基于Redis做架构的改造。首先简单公布一下Redis平台实际情况:

  • 2200+亿 commands/day 5000亿Read/day 500亿Write/day
  • 18TB+ Memory
  • 500+ Servers in 6 IDC 2000+instances

应该是国内外比较大的Redis使用平台,今天主要从应用角度谈谈Redis服务平台。

Redis使用场景

1.Counting(计数)

计数的应用在另外一篇文章里较详细的描述,计数场景的优化 http://www.xdata.me/?p=262这里就不多加描述了。

可以预见的是,有很多同学认为把计数全部存在内存中成本非常高,我在这里用个图表来表达下我的观点:

很多情况大家都会设想纯使用内存的方案会很有很高成本,但实际情况往往会有一些不一样:

  • COST,对于有一定吞吐需求的应用来说,肯定会单独申请DB、Cache资源,很多担心DB写入性能的同学还会主动将DB更新记入异步队列,而这三块的资源的利用率一般都不会太高。资源算下来,你惊异的发现:反而纯内存的方案会更精简!
  • KISS原则,这对于开发是非常友好的,我只需要建立一套连接池,不用担心数据一致性的维护,不用维护异步队列。
  • Cache穿透风险,如果后端使用DB,肯定不会提供很高的吞吐能力,cache宕机如果没有妥善处理,那就悲剧了。
  • 大多数的起始存储需求,容量较小。

2.Reverse cache(反向cache)

面对微博常常出现的热点,如最近出现了较为火爆的短链,短时间有数以万计的人点击、跳转,而这里会常常涌现一些需求,比如我们向快速在跳转时判定用户等级,是否有一些账号绑定,性别爱好什么的,已给其展示不同的内容或者信息。

普通采用memcache+Mysql的解决方案,当调用id合法的情况下,可支撑较大的吞吐。但当调用id不可控,有较多垃圾用户调用时,由于memcache未有命中,会大量的穿透至Mysql服务器,瞬间造成连接数疯长,整体吞吐量降低,响应时间变慢。

这里我们可以用redis记录全量的用户判定信息,如string key:uid int:type,做一次反向的cache,当用户在redis快速获取自己等级等信息后,再去Mc+Mysql层去获取全量信息。如图:

当然这也不是最优化的场景,如用Redis做bloomfilter,可能更加省用内存。

3.Top 10 list

产品运营总会让你展示最近、最热、点击率最高、活跃度最高等等条件的top list。很多更新较频繁的列表如果使用MC+MySQL维护的话缓存失效的可能性会比较大,鉴于占用内存较小的情况,使用Redis做存储也是相当不错的。

4.Last Index

用户最近访问记录也是redis list的很好应用场景,lpush lpop自动过期老的登陆记录,对于开发来说还是非常友好的。

5.Relation List/Message Queue

这里把两个功能放在最后,因为这两个功能在现实问题当中遇到了一些困难,但在一定阶段也确实解决了我们很多的问题,故在这里只做说明。

Message Queue就是通过list的lpop及lpush接口进行队列的写入和消费,由于本身性能较好也能解决大部分问题。

6.Fast transaction with Lua

Redis 的Lua的功能扩展实际给Redis带来了更多的应用场景,你可以编写若干command组合作为一个小型的非阻塞事务或者更新逻辑,如:在收到message推送时,同时1.给自己的增加一个未读的对话 2.给自己的私信增加一个未读消息 3.最后给发送人回执一个完成推送消息,这一层逻辑完全可以在Redis Server端实现。

但是,需要注意的是Redis会将lua script的全部内容记录在aof和传送给slave,这也将是对磁盘,网卡一个不小的开销。

7.Instead of Memcache

  1. 很多测试和应用均已证明,
  2. 在性能方面Redis并没有落后memcache多少,而单线程的模型给Redis反而带来了很强的扩展性。
  3. 在很多场景下,Redis对同一份数据的内存开销是小于memcache的slab分配的。
  4. Redis提供的数据同步功能,其实是对cache的一个强有力功能扩展。

Redis使用的重要点

1.rdb/aof Backup!

我们线上的Redis 95%以上是承担后端存储功能的,我们不仅用作cache,而更为一种k-v存储,他完全替代了后端的存储服务(MySQL),故其数据是非常重要的,如果出现数据污染和丢失,误操作等情况,将是难以恢复的。所以备份是非常必要的!为此,我们有共享的hdfs资源作为我们的备份池,希望能随时可以还原业务所需数据。

2.Small item & Small instance!

由于Redis单线程(严格意义上不是单线程,但认为对request的处理是单线程的)的模型,大的数据结构list,sorted set,hash set的批量处理就意味着其他请求的等待,故使用Redis的复杂数据结构一定要控制其单key-struct的大小。

另外,Redis单实例的内存容量也应该有严格的限制。单实例内存容量较大后,直接带来的问题就是故障恢复或者Rebuild从库的时候时间较长,而更糟糕的是,Redis rewrite aof和save rdb时,将会带来非常大且长的系统压力,并占用额外内存,很可能导致系统内存不足等严重影响性能的线上故障。我们线上96G/128G内存服务器不建议单实例容量大于20/30G。

3.Been Available!

业界资料和使用比较多的是Redis sentinel(哨兵)

http://www.huangz.me/en/latest/storage/redis_code_analysis/sentinel.html

http://qiita.com/wellflat/items/8935016fdee25d4866d9

2000行C实现了服务器状态检测,自动故障转移等功能。

但由于自身实际架构往往会复杂,或者考虑的角度比较多,为此 @许琦eryk和我一同做了hypnos项目。

hypnos是神话中的睡神,字面意思也是希望我们工程师无需在休息时间处理任何故障。:-)

其工作原理示意如下:

Talk is cheap, show me your code! 稍后将单独写篇博客细致讲下Hypnos的实现。

4.In Memory or not?

发现一种情况,开发在沟通后端资源设计的时候,常常因为习惯使用和错误了解产品定位等原因,而忽视了对真实使用用户的评估。也许这是一份历史数据,只有最近一天的数据才有人进行访问,而把历史数据的容量和最近一天请求量都抛给内存类的存储现实是非常不合理的。

所以当你在究竟使用什么样的数据结构存储的时候,请务必先进行成本衡量,有多少数据是需要存储在内存中的?有多少数据是对用户真正有意义的。因为这其实对后端资源的设计是至关重要的,1G的数据容量和1T的数据容量对于设计思路是完全不一样的

Plans in future?

1.slave sync改造

全部改造线上master-slave数据同步机制,这一点我们借鉴了MySQL Replication的思路,使用rdb+aof+pos作为数据同步的依据,这里简要说明为什么官方提供的psync没有很好的满足我们的需求:

假设A有两个从库B及C,及 A `— B&C,这时我们发现master A服务器有宕机隐患需要重启或者A节点直接宕机,需要切换B为新的主库,如果A、B、C不共享rdb及aof信息,C在作为B的从库时,仍会清除自身数据,因为C节点只记录了和A节点的同步状况。

故我们需要有一种将A`–B&C 结构切换切换为A`–B`–C结构的同步机制,psync虽然支持断点续传,但仍无法支持master故障的平滑切换。

实际上我们已经在我们定制的Redis计数服务上使用了如上功能的同步,效果非常好,解决了运维负担,但仍需向所有Redis服务推广,如果可能我们也会向官方Redis提出相关sync slave的改进。

2.更适合redis的name-system Or proxy

细心的同学发现我们除了使用DNS作为命名系统,也在zookeeper中有一份记录,为什么不让用户直接访问一个系统,zk或者DNS选择其一呢?

其实还是很简单,命名系统是个非常重要的组件,而dns是一套比较完善的命名系统,我们为此做了很多改进和试错,zk的实现还是相对复杂,我们还没有较强的把控粒度。我们也在思考用什么做命名系统更符合我们需求。

3.后端数据存储

大内存的使用肯定是一个重要的成本优化方向,flash盘及分布式的存储也在我们未来计划之中。(原文链接: Largest Redis Clusters Ever

二、Pinterest:Reids维护上百亿的相关性

Pinterest已经成为硅谷最疯故事之一,在2012年,他们基于PC的业务增加1047%,移动端采用增加1698%, 该年3月其独立访问数量更飙升至533亿。在Pinterest,人们关注的事物以百亿记——每个用户界面都会查询某个board或者是用户是否关注的行为促成了异常复杂的工程问题。这也让Redis获得了用武之地。经过数年的发展,Pinterest已经成为媒体、社交等多个领域的佼佼者,其辉煌战绩如下:

  • 获得的推荐流量高于Google+、YouTube及LinkedIn三者的总和
  • 与Facebook及Twitter一起成为最流行的三大社交网络
  • 参考Pinterest进行购买的用户比其它网站更高( 更多详情

如您所想,基于其独立访问数,Pinterest的高规模促成了一个非常高的IT基础设施需求。

 

通过缓存来优化用户体验

近日,Pinterest工程经理Abhi Khune对其公司的用户体验需求及Redis的使用经验 进行了分享。即使是滋生的应用程序打造者,在分析网站的细节之前也不会理解这些特性,因此先大致的理解一下使用场景:首先,为每个粉丝进行提及到的预检查;其次,UI将准确的显示用户的粉丝及关注列表分页。高效的执行这些操作,每次点击都需要非常高的性能架构。

不能免俗,Pinterest的软件工程师及架构师已经使用了MySQL及memcache,但是缓存解决方案仍然达到了他们的瓶颈;因此为了拥有更好的用户体验,缓存必须被扩充。而在实际操作过程中,工程团队已然发现缓存只有当用户sub-graph已经在缓存中时才会起到作用。因此。任何使用这个系统的人都需要被缓存,这就导致了整个图的缓存。同时,最常见的查询“用户A是否关注了用户B”的答案经常是否定的,然而这却被作为了缓存丢失,从而促成一个数据库查询,因此他们需要一个新的方法来扩展缓存。最终,他们团队决定使用Redis来存储整个图,用以服务众多的列表。

使用Redis存储大量的Pinterest列表

Pinterest使用了Redis作为解决方案,并将性能推至了内存数据库等级,为用户保存多种类型列表:

  • 关注者列表
  • 你所关注的board列表
  • 粉丝列表
  • 关注你board的用户列表
  • 某个用户中board中你没有关注的列表
  • 每个board的关注者及非关注者

Redis为其7000万用户存储了以上的所有列表,本质上讲可以说是储存了所有粉丝图,通过用户ID分片。鉴于你可以通过类型来查看以上列表的数据,分析概要信息被用看起来更像事务的系统储存及访问。Pinterest当下的用户like被限制为10万,初略进行统计:如果每个用户关注25个board,将会在用户及board间产生17.5亿的关系。同时更加重要的是,这些关系随着系统的使用每天都会增加。

Pinterest的Reids架构及运营

通过Pinterest的一个创始人了解到,Pinterest开始使用Python及订制的Django编写应用程序,并一直持续到其拥有1800万用户级日410TB用户数据的时候。虽然使用了多个存储对数据进行储存,工程师根据用户id使用了8192个虚拟分片,每个分片都运行在一个Redis DB之上,同时1个Redis实例将运行多个Redis DB。为了对CPU核心的充分使用,同一台主机上同时使用多线程和单线程Redis实例。

鉴于整个数据集运行在内存当中,Redis在Amazon EBS上对每秒传输进来的写入都会进行持久化。扩展主要通过两个方面进行:第一,保持50%的利用率,通过主从转换,机器上运行的Redis实例一半会转译到一个新机器上;第二,扩展节点和分片。整个Redis集群都会使用一个主从配置,从部分将被当做一个热备份。一旦主节点失败,从部分会立刻完成主的转换,同时一个新的从部分将会被添加,ZooKeeper将完成整个过程。同时他们每个小时都会在Amazon S3上运行BGsave做更持久的储存——这项Reids操作会在后端进行,之后Pinterest会使用这些数据做MapReduce和分析作业。(更多内容见原文)

三、Viacom:Redis在系统中的用例盘点

Viacom是全球最大的传媒集体之一,同时也遭遇了当下最大的数据难题之一:如何处理日益剧增的动态视频内容。

着眼这一挑战的上升趋势,我们会发现:2010年世界上所有数据体积达到ZB级,而单单2012这一年,互联网产生的数据就增加了2.8个ZB,其中大部分的数据都是非结构化的,包括了视频和图片。

覆盖MVN(以前称为MTV Networks、Paramount及BET),Viacom是个名副其实的传媒巨头,支持众多人气站点,其中包括The Daily Show、osh.0、South Park Studios、GameTrailers.com等。作为媒体公司,这些网站上的文档、图片、视频短片都在无时无刻的更新。长话短说,下面就进入Viacom高级架构师Michael Venezia 分享的Redis实践:

Viacom的网站架构背景

对于Viacom,横跨多个站点传播内容让必须专注于规模的需求,同时为了将内容竟可能快的传播到相应用户,他们还必须聚焦内容之间的关系。然而即使The Daily Show、Nickelodeon、Spike或者是VH1 这些单独的网站上,日平均PV都可以达到千万,峰值时流量更会达到平均值的20-30倍。同时基于对实时的需求,动态的规模及速度已成为架构的基础之一。

除去动态规模之外,服务还必须基于用户正在浏览的视频或者是地理位置来推测用户的喜好。比如说,某个页面可能会将一个独立的视频片段与本地的促销,视频系列的额外部分,甚至是相关视频联系起来。为了能让用户能在网站上停留更长的时间,他们建立了一个能基于详细元数据自动建立页面的软件引擎,这个引擎可以根据用户当下兴趣推荐额外的内容。鉴于用于兴趣的随时改变,数据的类型非常广泛——类似graph-like,实际上做的是大量的join。

这样做有利于减少类似视频的大体积文件副本数,比如数据存储中一个独立的记录是Southpark片段“Cartman gets an Anal Probe”,这个片段可能也会出现在德语的网站上。虽然视频是一样的,但是英语用户搜索的可能就是另一个不同的词语。元数据的副本转换成搜索结果,并指向相同的视频。因此在美国用户搜索真实标题的情况下,德国浏览者可能会使用转译的标题——德国网站上的“Cartman und die Analsonde”。

这些元数据覆盖了其它记录或者是对象,同时还可以根据使用环境来改变内容,通过不同的规则集来限制不同地理位置或者是设备请求的内容。

Viacom的实现方法

尽管许多机构通过使用ORM及传统关系型数据库来解决这个问题,Viacom却使用了一个迥然不同的方法。

本质上,他们完全承担不了对数据库的直接访问。首先,他们处理的大部分都是流数据,他们偏向于使用Akamai从地理上来分配内容。其次,基于页面的复杂性可能会取上万个对象。取如此多的数据显然会影响到性能,因此JSON在1个数据服务中投入了使用。当然,这些JSON对象的缓存将直接影响到网站性能。同时,当内容或者是内容之间的关系发生改变时,缓存还需要动态的进行更新。

Viacom依靠对象基元和超类解决这个问题,继续以South Park为例:一个私有的“episode”类包含了所有该片段相关信息,一个“super object”将有助于发现实际的视频对象。超类这个思想确实非常有益于建设低延迟页面的自动建设,这些超类可以帮助到基元对象到缓存的映射及保存。

Viacom为什么要使用Redis

每当Viacom上传一个视频片段,系统将建立一个私有的对象,并于1个超类关联。每一次修改,他们都需要重估私有对象的每个改变,并更新所有复合对象。同时,系统还需要无效Akamail中的URL请求。系统现有架构的组合及更敏捷的管理方法需求将Viacom推向了Redis。

基于Viacom主要基于PHP,所以这个解决方案必须支持php。他们首先选择了memcached做对象存储,但是它并不能很好的支持hashmap;同时他们还需要一个更有效的进行无效步骤的重估,即更好的理解内容的依赖性。本质上说,他们需要时刻跟进无效步骤中的依赖性改变。因此他们选择了Redis及Predis的组合来解决这个问题。

他们团队使用Redis给southparkstudios.com和thedailyshow.com两个网站建设依赖性图,在取得了很大的成功后他们开始着眼Redis其它适合场景。

Redis的其它使用场景

显而易见,如果有人使用Redis来建设依赖性图,那么使用它来做对象处理也是说得通的。同样,这也成了架构团队为Redis选择的第二使用场景。Redis的复制及持久化特性同时也征服了Viacom的运营团队,因此在几个开发周期后,Redis成为他们网站的主要数据及依赖性储存。

后两个用例则是行为追踪及浏览计数的缓冲,改变后的架构是Redis每几分钟向MySQL中储存一次,而浏览计数则通过Redis进行存储及计数。同时Redis还被用来做人气的计算,一个基于访问数及访问时间的得分系统——如果某个视频最近被访问的次数越多,它的人气就越高。在如此多内容上每隔10-15分钟做一次计算绝对不是类似MySQL这样传统关系型数据库的强项,Viacom使用Redis的理由也非常简单——在1个存储浏览信息的Redis实例上运行Lua批处理作业,计算出所有的得分表。信息被拷贝到另一个Redis实例上,用以支持相关的产品查询。同时还在MySQL上做了另一个备份,用以以后的分析,这种组合会将这个过程耗费的时间降低60倍。

Viacom还使用Redis存储一步作业信息,这些信息被插入一个列表中,工作人员则使用BLPOP命令行在队列中抓取顶端的任务。同时zsets被用于从众多社交网络(比如Twitter及Tumblr)上综合内容,Viacom通过Brightcove视频播放器来同步多个内容管理系统。

横跨这些用例,几乎所有的Redis命令都被使用——sets、lists、zlists、hashmaps、scripts、counters等。同时,Redis也成为Viacom可扩展架构中不可或缺的一环。

Hadoop2.5.2 HA高可靠性集群搭建(Hadoop+Zookeeper)

 

一.概述

1.1 hadoop1.0的单点问题

Hadoop中的NameNode好比是人的心脏,非常重要,绝对不可以停止工作。在hadoop1时代,只有一个NameNode。如果该NameNode数据丢失或者不能工作,那么整个集群就不能恢复了。这是hadoop1中的单点问题,也是hadoop1不可靠的表现。如下图所示,便是hadoop1.0的架构图;
Hadoop2.5.2 HA高可靠性集群搭建(Hadoop+Zookeeper)

1.2 hadoop2.0对hadoop1.0单点问题的解决

为了解决hadoop1中的单点问题,在hadoop2中新的NameNode不再是只有一个,可以有多个(目前只支持2个)。每一个都有相同的职能。一个是active状态的,一个是standby状态的。当集群运行时,只有active状态的NameNode是正常工作的,standby状态的NameNode是处于待命状态的,时刻同步active状态NameNode的数据。一旦active状态的NameNode不能工作,通过手工或者自动切换,standby状态的NameNode就可以转变为active状态的,就可以继续工作了。这就是高可靠。

1.3 使用JournalNode实现NameNode(Active和Standby)数据的共享

Hadoop2.0中,2个NameNode的数据其实是实时共享的。新HDFS采用了一种共享机制,Quorum Journal Node(JournalNode)集群或者Nnetwork File System(NFS)进行共享。NFS是操作系统层面的,JournalNode是hadoop层面的,我们这里使用JournalNode集群进行数据共享(这也是主流的做法)。如下图所示,便是JournalNode的架构图。
Hadoop2.5.2 HA高可靠性集群搭建(Hadoop+Zookeeper)
两个NameNode为了数据同步,会通过一组称作JournalNodes的独立进程进行相互通信。当active状态的NameNode的命名空间有任何修改时,会告知大部分的JournalNodes进程。standby状态的NameNode有能力读取JNs中的变更信息,并且一直监控edit log的变化,把变化应用于自己的命名空间。standby可以确保在集群出错时,命名空间状态已经完全同步了

1.4 NameNode之间的故障切换

对于HA集群而言,确保同一时刻只有一个NameNode处于active状态是至关重要的。否则,两个NameNode的数据状态就会产生分歧,可能丢失数据,或者产生错误的结果。为了保证这点,这就需要利用使用ZooKeeper了。首先HDFS集群中的两个NameNode都在ZooKeeper中注册,当active状态的NameNode出故障时,ZooKeeper能检测到这种情况,它就会自动把standby状态的NameNode切换为active状态。

二.Hadoop(HA)集群的搭建

2.1 配置详细
主机名 IP NameNode DataNode Year Zookeeper JournalNode
mast1 192.168.177.131
mast2 192.168.177.132
mast3 192.168.177.133
2.2 安装jdk

(省略)安装jdk和配置环境变量

2.2 SSH免登录

(省略),参考:http://eksliang.iteye.com/blog/2187265

2.4 Zookeeper集群搭建

(省略),参考,http://eksliang.iteye.com/blog/2107002,这是我的solr集群部署,也是使用zookeeper进行管理,zookeeper这里步骤跟操作一模一样,最后我的zoo.cfg文件如下所示

[hadoop@Mast1 conf]$ cat zoo.cfg 
# The number of milliseconds of each tick
tickTime=2000
# The number of ticks that the initial 
# synchronization phase can take
initLimit=10
# The number of ticks that can pass between 
# sending a request and getting an acknowledgement
syncLimit=5
# the directory where the snapshot is stored.
dataDir=/home/hadoop/zookeeper/data
dataLogDir=/home/hadoop/zookeeper/datalog
# the port at which the clients will connect
clientPort=2181
server.1=mast1:2888:3888  
server.2=mast2:2888:3888  
server.3=mast3:2888:3888
2.5配置Hadoop配置文件

先配置mast1这台机器,配置后了后,将配置环境,复制到mast2、mast3上面即可!

hadoop2.0的配置存放在~/etc/hadoop目录下面,

  • core.xml
<configuration>
 <!-- 指定hdfs的nameservice为ns -->
 <property>    
      <name>fs.defaultFS</name>    
      <value>hdfs://ns</value>    
 </property>
 <!--指定hadoop数据临时存放目录-->
 <property>
      <name>hadoop.tmp.dir</name>
      <value>/home/hadoop/workspace/hdfs/temp</value>
 </property>   
                          
 <property>    
      <name>io.file.buffer.size</name>    
      <value>4096</value>    
 </property>
 <!--指定zookeeper地址-->
 <property>
      <name>ha.zookeeper.quorum</name>
      <value>mast1:2181,mast2:2181,mast3:2181</value>
 </property>
 </configuration>
  • hdfs-site.xml
<configuration>
    <!--指定hdfs的nameservice为ns,需要和core-site.xml中的保持一致 -->    
    <property>    
        <name>dfs.nameservices</name>    
        <value>ns</value>    
    </property>  
    <!-- ns下面有两个NameNode,分别是nn1,nn2 -->
    <property>
       <name>dfs.ha.namenodes.ns</name>
       <value>nn1,nn2</value>
    </property>
    <!-- nn1的RPC通信地址 -->
    <property>
       <name>dfs.namenode.rpc-address.ns.nn1</name>
       <value>mast1:9000</value>
    </property>
    <!-- nn1的http通信地址 -->
    <property>
        <name>dfs.namenode.http-address.ns.nn1</name>
        <value>mast1:50070</value>
    </property>
    <!-- nn2的RPC通信地址 -->
    <property>
        <name>dfs.namenode.rpc-address.ns.nn2</name>
        <value>mast2:9000</value>
    </property>
    <!-- nn2的http通信地址 -->
    <property>
        <name>dfs.namenode.http-address.ns.nn2</name>
        <value>mast2:50070</value>
    </property>
    <!-- 指定NameNode的元数据在JournalNode上的存放位置 -->
    <property>
         <name>dfs.namenode.shared.edits.dir</name>
         <value>qjournal://mast1:8485;mast2:8485;mast3:8485/ns</value>
    </property>
    <!-- 指定JournalNode在本地磁盘存放数据的位置 -->
    <property>
          <name>dfs.journalnode.edits.dir</name>
          <value>/home/hadoop/workspace/journal</value>
    </property>
    <!-- 开启NameNode故障时自动切换 -->
    <property>
          <name>dfs.ha.automatic-failover.enabled</name>
          <value>true</value>
    </property>
    <!-- 配置失败自动切换实现方式 -->
    <property>
            <name>dfs.client.failover.proxy.provider.ns</name>
            <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
    </property>
    <!-- 配置隔离机制 -->
    <property>
             <name>dfs.ha.fencing.methods</name>
             <value>sshfence</value>
    </property>
    <!-- 使用隔离机制时需要ssh免登陆 -->
    <property>
            <name>dfs.ha.fencing.ssh.private-key-files</name>
            <value>/home/hadoop/.ssh/id_rsa</value>
    </property>
                              
    <property>    
        <name>dfs.namenode.name.dir</name>    
        <value>file:///home/hadoop/workspace/hdfs/name</value>    
    </property>    
    
    <property>    
        <name>dfs.datanode.data.dir</name>    
        <value>file:///home/hadoop/workspace/hdfs/data</value>    
    </property>    
    
    <property>    
       <name>dfs.replication</name>    
       <value>2</value>    
    </property>   
    <!-- 在NN和DN上开启WebHDFS (REST API)功能,不是必须 -->                                                                    
    <property>    
       <name>dfs.webhdfs.enabled</name>    
       <value>true</value>    
    </property>    
</configuration>
  • mapred-site.xml
<configuration>
 <property>    
        <name>mapreduce.framework.name</name>    
        <value>yarn</value>    
 </property>    
</configuration>
  • yarn-site.xml
<configuration>
    <!-- 指定nodemanager启动时加载server的方式为shuffle server -->
    <property>    
            <name>yarn.nodemanager.aux-services</name>    
            <value>mapreduce_shuffle</value>    
     </property>  
     <!-- 指定resourcemanager地址 -->
     <property>
            <name>yarn.resourcemanager.hostname</name>
            <value>mast3</value>
      </property> 
</configuration>
  • slaves
[hadoop@Mast1 hadoop]$ cat slaves
mast1
mast2
mast3
  • 修改JAVA_HOME

分别在文件hadoop-env.sh和yarn-env.sh中添加JAVA_HOME配置

#export JAVA_HOME=${JAVA_HOME} --原来   
export JAVA_HOME=/usr/local/java/jdk1.7.0_67

虽然默认配置了${JAVA_HOME}的环境变量,但是hadoop启动时,会提示找不到,没有办法,指定绝对路径,这个是必须的。

  • 配置hadoop的环境变量,参考我的配置
[hadoop@Mast1 hadoop]$ vim ~/.bash_profile  
export HADOOP_HOME="/home/hadoop/hadoop-2.5.2"  
export PATH=$HADOOP_HOME/bin:$HADOOP_HOME/sbin:$PATH  
export HADOOP_COMMON_LIB_NATIVE_DIR=$HADOOP_HOME/lib/native  
export HADOOP_OPTS="-Djava.library.path=$HADOOP_HOME/lib"
  • 将配置复制到mast2、mast3
scp -r ~/.bash_profile hadoop@mast2:/home/hadoop/  
scp -r ~/.bash_profile hadoop@mast3:/home/hadoop/  
scp -r $HADOOP_HOME/etc/hadoop hadoop@mast2:/home/hadoop/hadoop-2.5.2/etc/  
scp -r $HADOOP_HOME/etc/hadoop hadoop@mast3:/home/hadoop/hadoop-2.5.2/etc/

至此Hadoop的配置完毕,接下来就是启动集群了

三.集群的启动

3.1 启动zookeeper集群

分别在mast1、mast2、mast3上执行如下命令启动zookeeper集群;

[hadoop@Mast1 bin]$ sh zkServer.sh start

验证集群zookeeper集群是否启动,分别在mast1、mast2、mast3上执行如下命令验证zookeeper集群是否启动,集群启动成功,有两个follower节点跟一个leader节点;

[hadoop@Mast1 bin]$ sh zkServer.sh status
JMX enabled by default
Using config: /home/hadoop/zookeeper/zookeeper-3.3.6/bin/../conf/zoo.cfg
Mode: follower
3.2 启动journalnode集群

在mast1上执行如下命令完成JournalNode集群的启动

[hadoop@Mast1 hadoop-2.5.2]$ sbin/hadoop-daemons.sh start journalnode

执行jps命令,可以查看到JournalNode的java进程pid

3.3 格式化zkfc,让在zookeeper中生成ha节点

在mast1上执行如下命令,完成格式化

hdfs zkfc –formatZK

(注意,这条命令最好手动输入,直接copy执行有可能会有问题,当时部署时我是蛋疼了许久)

格式成功后,查看zookeeper中可以看到

[zk: localhost:2181(CONNECTED) 1] ls /hadoop-ha
[ns]
3.4 格式化hdfs
hadoop namenode –format

(注意,这条命令最好手动输入,直接copy执行有可能会有问题)

3.5 启动NameNode

首先在mast1上启动active节点,在mast1上执行如下命令

[hadoop@Mast1 hadoop-2.5.2]$ sbin/hadoop-daemon.sh start namenode

在mast2上同步namenode的数据,同时启动standby的namenod,命令如下

#把NameNode的数据同步到mast2上
[hadoop@Mast2 hadoop-2.5.2]$ hdfs namenode –bootstrapStandby
#启动mast2上的namenode作为standby
[hadoop@Mast2 hadoop-2.5.2]$ sbin/hadoop-daemon.sh start namenode
3.6 启动启动datanode

在mast1上执行如下命令

[hadoop@Mast1 hadoop-2.5.2]$ sbin/hadoop-daemons.sh start datanode
3.7 启动year

在作为资源管理器上的机器上启动,我这里是mast3,执行如下命令完成year的启动

[hadoop@Mast3 hadoop-2.5.2]$ sbin/start-yarn.sh
3.8 启动ZKFC

在mast1上执行如下命令,完成ZKFC的启动

[hadoop@Mast1 hadoop-2.5.2]$ sbin/hadoop-daemons.sh start zkfc

全部启动完后分别在mast1,mast2,mast3上执行jps是可以看到下面这些进程的

#mast1上的java PID进程
[hadoop@Mast1 hadoop-2.5.2]$ jps
2837 NodeManager
3054 DFSZKFailoverController
4309 Jps
2692 DataNode
2173 QuorumPeerMain
2551 NameNode
2288 JournalNode
#mast2上的java PID进程
[hadoop@Mast2 ~]$ jps
2869 DFSZKFailoverController
2353 DataNode
2235 JournalNode
4522 Jps
2713 NodeManager
2591 NameNode
2168 QuorumPeerMain
#mast3上的java PID进程
[hadoop@Mast3 ~]$ jps
2167 QuorumPeerMain
2337 JournalNode
3506 Jps
2457 DataNode
2694 NodeManager
2590 ResourceManager

四.测试HA的高可用性

启动后mast1的namenode和mast2的namenode如下所示:
Hadoop2.5.2 HA高可靠性集群搭建(Hadoop+Zookeeper)
Hadoop2.5.2 HA高可靠性集群搭建(Hadoop+Zookeeper)

此时在mast1上执行如下命令关闭mast1上的namenode

[hadoop@Mast1 hadoop-2.5.2]$ sbin/hadoop-daemon.sh stop namenode

再次查看mast1上的namenode,发现自动切换为active了!证据如下:
Hadoop2.5.2 HA高可靠性集群搭建(Hadoop+Zookeeper)

来自:http://www.iteye.com/news/30739

使用FastDFS搭建图片服务器单实例篇——OSS分布式文件存储

一、背景描述

之前公司的图片服务器已经不能胜任了(直接使用tomcat),需要重新搭建图片服务器,这两天研究了下FastDFS,感觉挺好用记录下来以供日后参考。

二、FastDFS官方介绍

FastDFS是一款类Google FS的开源分布式文件系统,它用纯C语言实现,支持Linux、FreeBSD、AIX等UNIX系统。它只能通过 专有API对文件进行存取访问,不支持POSIX接口方式,不能mount使用。准确地讲,Google FS以及FastDFS、mogileFS、 HDFS、TFS等类Google FS都不是系统级的分布式文件系统,而是应用级的分布式文件存储服务。

    1、FastDFS架构图

wKioL1cZmp3xhDAdAAMMQuy6qEc170.jpg

图1:FastDFS架构图

1)Tracker cluster中各个tracker server相互独立,不进行相互通信。

2)Storage cluster中各个storage组(Volume1,Volume2…)相互独立,不进行相互通信,也就是说各个组之间保存的数据是不相同的。但是各个组中的storage server之间是属于互相备份的关系,也就是说storage server之间保存相同的数据。

3)每个storage server会启动一个单独的线程主动向Tracker cluster中每个tracker server报告其状态信息,包括磁盘使用情况,文件同步情况及文件上传下载次数统计等信息。

2、文件上传和下载的时序图

 

wKioL1cZm1KwweSxAACFK-IhvCs899.jpg

图2:文件上传时序图

1)Client通过Tracker server将文件上传到Storage server。

2)Tracker server向Client返回一台可用的Storage server的IP地址和端口号。

3)Client直接通过Tracker server返回的IP地址和端口与其中一台Storage server建立连接并进行文件上传。

4)上传完成,Storage server返回Client一个文件ID,文件上传结束。

 

wKiom1cZmo-RxJsXAACFly7rbaQ068.jpg

图3:文件下载时序图

1)Client通过Tracker server下载指定Storage组中某个Storage server上的某个文件(文件名包括Storage组名称)。

2)Tracker server向Client返回一台可用的Storage server的IP地址和端口号。

3)Client直接通过Tracker server返回的IP地址和端口与其中一台Storage server建立连接并进行文件下载。

三、安装并配置FastDFS

    1、运行环境及相关软件

    CentOS 6.5

FastDFS_v5.08.tar.gz

nginx-1.8.1.tar.gz

fastdfs-nginx-module_v1.16.tar.gz

libfastcommon

2、服务器规划

服务器名称
IP地址和端口
备注
fastdfs-tracker 172.18.10.232:22122 跟踪服务器/调度服务器
fastdfs-storage 172.18.10.233:23000 存储服务器

3、安装FastDFS

1)首先创建工具目录(非必须)

1
2
[root@fastdfs-storage ~]# mkdir -p /home/oldcat/tools
[root@fastdfs-storage ~]# cd /home/oldcat/tools/

    2) 下载并安装FastDFS依赖包libfastcommon

1
2
3
4
5
6
7
[root@fastdfs-storage tools]# wget https://codeload.github.com/happyfish100/libfastcommon/zip/master
[root@fastdfs-storage tools]# unzip master
[root@fastdfs-storage tools]# cd libfastcommon-master/
[root@fastdfs-storage libfastcommon-master]# ls
HISTORY  INSTALL  libfastcommon.spec  make.sh  php-fastcommon  README  src
[root@fastdfs-storage libfastcommon-master]# ./make.sh
[root@fastdfs-storage libfastcommon-master]# ./make.sh install

    3)下载并安装FastDFS  

1
2
3
4
[root@fastdfs-tracker tools]# wget http://jaist.dl.sourceforge.net/project/fastdfs/FastDFS%20Server%20Source%20Code/FastDFS%20Server%20with%20PHP%20Extension%20Source%20Code%20V5.08/FastDFS_v5.08.tar.gz
[root@fastdfs-tracker tools]# tar xf FastDFS_v5.08.tar.gz
[root@fastdfs-tracker tools]# cd FastDFS
[root@fastdfs-tracker FastDFS]# ./make.sh && ./make.sh install

    采用默认方式安装后的文件及目录:

1)服务脚本:

1
2
3
[root@fastdfs-tracker ~]# ll /etc/init.d/ |grep fdfs
-rwxr-xr-x. 1 root root   918 4月  22 22:08 fdfs_storaged
-rwxr-xr-x. 1 root root   920 4月  22 22:08 fdfs_trackerd

2)样例配置文件

1
2
3
4
5
[root@fastdfs-tracker ~]# ll /etc/fdfs/
总用量 20
-rw-r--r--. 1 root root 1461 4月  22 22:08 client.conf.sample
-rw-r--r--. 1 root root 7927 4月  22 22:08 storage.conf.sample
-rw-r--r--. 1 root root 7200 4月  22 22:08 tracker.conf.sample

    3)命令行工具

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
[root@fastdfs-tracker ~]# ll /usr/bin|grep fdfs
-rwxr-xr-x.   1 root root     252272 4月  22 22:08 fdfs_appender_test
-rwxr-xr-x.   1 root root     252225 4月  22 22:08 fdfs_appender_test1
-rwxr-xr-x.   1 root root     242449 4月  22 22:08 fdfs_append_file
-rwxr-xr-x.   1 root root     242013 4月  22 22:08 fdfs_crc32
-rwxr-xr-x.   1 root root     242508 4月  22 22:08 fdfs_delete_file
-rwxr-xr-x.   1 root root     243627 4月  22 22:08 fdfs_download_file
-rwxr-xr-x.   1 root root     243369 4月  22 22:08 fdfs_file_info
-rwxr-xr-x.   1 root root     255657 4月  22 22:08 fdfs_monitor
-rwxr-xr-x.   1 root root     863913 4月  22 22:08 fdfs_storaged
-rwxr-xr-x.   1 root root     258712 4月  22 22:08 fdfs_test
-rwxr-xr-x.   1 root root     257881 4月  22 22:08 fdfs_test1
-rwxr-xr-x.   1 root root     365232 4月  22 22:08 fdfs_trackerd
-rwxr-xr-x.   1 root root     243547 4月  22 22:08 fdfs_upload_appender
-rwxr-xr-x.   1 root root     244453 4月  22 22:08 fdfs_upload_file

    注意:虽然FastDFS区分tracker和storage服务器,但是安装的软件及步骤均相同,只是不同的配置文件而已,因此以上安装适用tracker server和storage server

4、配置跟踪服务器(tracker server)

    1)拷贝tracker server和client端样例配置文件并重命名

1
2
[root@fastdfs-tracker ~]# cp /etc/fdfs/tracker.conf.sample /etc/fdfs/tracker.conf
[root@fastdfs-storage ~]# cp /etc/fdfs/client.conf.sample /etc/fdfs/client.conf

2)编辑tracker server配置文件tracker.conf,需要修改内容如下:

1
2
3
    disabled=false(默认为false,表示是否无效)
    port=22122(默认为22122)
    base_path=/data/fastdfs/tracker

3)编辑client端的配置文件client.conf,需要修改内容如下

1
2
    base_path=/data/fastdfs/tracker
    tracker_server=172.18.10.232:22122

4)创建tracker server数据目录

1
[root@fastdfs-tracker ~]# mkdir -p /data/fastdfs/tracker

5)测试启动tracker server,启动成功会自动在/data/fastdfs/tracker目录新建data和logs目录

1
2
3
4
5
6
7
8
[root@fastdfs-tracker ~]# cd /data/fastdfs/tracker/
[root@fastdfs-tracker tracker]# ls
[root@fastdfs-tracker tracker]# /etc/init.d/fdfs_trackerd start
Starting FastDFS tracker server:
[root@fastdfs-tracker tracker]# ss -lntup|grep 22122
tcp    LISTEN     0      128                    *:22122                 *:*      users:(("fdfs_trackerd",3785,5)) 
[root@fastdfs-tracker tracker]# ls
data  logs

    6)关闭tracker server

1
2
3
[root@fastdfs-tracker tracker]# /etc/init.d/fdfs_trackerd stop
waiting for pid [3785] exit ...
pid [3785] exit.

    5、配置存储服务器(storage server)

    1)拷贝storage server样例配置文件并重命名

1
[root@fastdfs-storage ~]# cp /etc/fdfs/storage.conf.sample /etc/fdfs/storage.conf

2)编辑storage server配置文件storage.conf,需要修改内容如下:

1
2
3
4
5
6
    disabled=false(默认为false,表示是否无效)
    port=23000(默认为23000)
    base_path=/data/fastdfs/storage
    tracker_server=172.18.10.232:22122
    store_path0=/data/fastdfs/storage
    http.server_port=8888(默认为8888,nginx中配置的监听端口那之一致)

3)创建storage server数据目录

1
[root@fastdfs-storage ~]# mkdir -p /data/fastdfs/storage

    4)测试启动storage server,启动成功会自动在/data/fastdfs/tracker目录新建data和logs目录(启动storage server的前提是tracker server必须事先已启动)

1
2
3
4
5
6
7
8
[root@fastdfs-storage ~]# cd /data/fastdfs/storage/
[root@fastdfs-storage storage]# ls
[root@fastdfs-storage storage]# /etc/init.d/fdfs_storaged start
Starting FastDFS storage server:
[root@fastdfs-storage storage]# ss -lntup|grep 23000
tcp    LISTEN     0      128                    *:23000                 *:*      users:(("fdfs_storaged",3786,5))
[root@fastdfs-storage storage]# ls
data  logs

    6、文件上传测试

执行如下上传命令:

1
2
3
[root@fastdfs-tracker ~]# /usr/bin/fdfs_upload_file /etc/fdfs/client.conf /home/oldcat/imgs/test.jpg
group1/M00/00/00/rBIK6VcaP0aARXXvAAHrUgHEviQ394.jpg
返回文件ID即说明文件已经上传成功

四、存储服务器(storage server)安装并配置nginx

1)下载并安装fastdfs-nginx-module模块

注:FastDFS通过Tracker服务器,将文件放在Storage服务器存储,但是同组存储服务器之间需要进入文件复制,有同步延迟的问题。假设Tracker服务器将文件上传到了192.168.4.125,上传成功后文件ID已经返回给客户端。此时FastDFS存储集群机制会将这个文件同步到同组存储192.168.4.126,在文件还没有复制完成的情况下,客户端如果用这个文件ID在192.168.4.126上取文件,就会出现文件无法访问的错误。而fastdfs-nginx-module可以重定向文件连接到源服务器取文件,避免客户端由于复制延迟导致的文件无法访问错误。

1
2
3
4
5
6
[root@fastdfs-storage  tools]# wget http://nchc.dl.sourceforge.net/project/fastdfs/FastDFS%20Nginx%20Module%20Source%20Code/fastdfs-nginx-module_v1.16.tar.gz
[root@fastdfs-storage tools]# tar xf fastdfs-nginx-module_v1.16.tar.gz 
[root@fastdfs-storage tools]# cd fastdfs-nginx-module/src/
[root@fastdfs-storage src]# vim config
编辑config文件,执行如下命令进行批量替换并保存退出
:%s+/usr/local/+/usr/+g

2)拷贝fastdfs-nginx-module模块中配置文件到/etc/fdfs目录中并编辑

1
2
3
4
5
6
7
8
9
10
[root@fastdfs-storage ~]# cp /home/oldcat/tools/fastdfs-nginx-module/src/mod_fastdfs.conf /etc/fdfs/
[root@fastdfs-storage ~]# vim /etc/fdfs/mod_fastdfs.conf
修改内容如下:
connect_timeout=10
base_path=/tmp(默认为/tmp
tracker_server=172.18.10.232:22122
storage_server_port=23000(默认配置为23000)
url_have_group_name = true
store_path0=/data/fastdfs/storage
group_name=group1(默认配置为group1)

3)安装nginx依赖库

1
[root@fastdfs-storage nginx-1.8.1]# yum install -y pcre-devel zlib-devel

4)下载并安装nginx

1
2
3
4
5
[root@fastdfs-storage  tools]# wget http://nginx.org/download/nginx-1.8.1.tar.gz
[root@fastdfs-storage tools]# tar xf nginx-1.8.1.tar.gz 
[root@fastdfs-storage tools]# cd nginx-1.8.1
[root@fastdfs-storage nginx-1.8.1]# ./configure --prefix=/application/nginx/ --add-module=../fastdfs-nginx-module/src/
[root@fastdfs-storage nginx-1.8.1]# make && make install

5)拷贝FastDFS中的部分配置文件到/etc/fdfs目录中

1
2
[root@fastdfs-storage ~]# cp /home/oldcat/tools/FastDFS/conf/http.conf /etc/fdfs/
[root@fastdfs-storage ~]# cp /home/oldcat/tools/FastDFS/conf/mime.types /etc/fdfs/

6)配置nginx,如下所示:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
[root@fastdfs-storage ~]# vim /application/nginx/conf/nginx.conf
    user  root;    
    worker_processes  1;
    events {
       worker_connections  1024;
    }
    http {
        include       mime.types;
        default_type  application/octet-stream;
        sendfile        on;
        keepalive_timeout  65;
        server {
            listen       8888;
            server_name  localhost;
            location ~/group[0-9]/ {
                ngx_fastdfs_module;
            }
            error_page   500 502 503 504  /50x.html;
            location = /50x.html {
            root   html;
            }
        }
    }

说明:

a、”user root”是解决下载操作时报404的问题

b、8888端口号与/etc/fdfs/storage.conf中的http.server_port=8888相对应

c、storage对应有多个group的情况下,访问路径带group名称,例如:/group1/M00/00/00/**,对应nginx配置:

location ~/group[0-9]/ {
ngx_fastdfs_module;
}

7)拷贝nginx服务到/etc/init.d/目录下并启动

1
2
3
4
[root@fastdfs-storage ~]# cp /application/nginx/sbin/nginx /etc/init.d/
[root@fastdfs-storage ~]# /etc/init.d/nginx
[root@fastdfs-storage ~]# ss -lntup|grep 8888
tcp    LISTEN     0      128                    *:8888                  *:*      users:(("nginx",7308,6),("nginx",7309,6))

8)通过浏览器访问之前已经上传的文件

wKioL1cZ8tLQKD7IAAWwU5Vw2Qs236.png浏览器可以成功访问到上传的图片,说明使用FastDFS搭建的图片服务器成功完成!