1. Redis安装、命令行及开发
  2. Thrift开发
  3. 初识Hadoop2


1. Redis安装、命令行及开发



1.1. Redis安装部署



1.1.1. Redis简介

Redis是一款开源的、高性能的键-值存储(key-value store)。它常被称作是一款数据结构服务器(data structure server)。Redis的键值可以包括字符串(strings)类型,同时它还包括哈希(hashes)、列表(lists)、集合(sets)和 有序集合(sorted sets)等数据类型。 对于这些数据类型,可以执行原子操作。

为了获得优异的性能,Redis采用了内存中(in-memory)数据集(dataset)的方式。同时,Redis支持数据的持久化,你可以每隔一段时间将数据集转存到磁盘上(snapshot),或者在日志尾部追加每一条操作命令(append only file,aof)。

Redis同样支持主从复制(master-slave replication),并且具有非常快速的非阻塞首次同步( non-blocking first synchronization)、网络断开自动重连等功能。同时Redis还具有其它一些特性,其中包括简单的事物支持、发布订阅 ( pub/sub)、管道(pipeline)和虚拟内存(vm)等 ,Redis具有丰富的客户端,支持现阶段流行的大多数编程语言。Java常用的是Jedis。



1.1.2. Redis安装部署

安装的具体步骤如下所示:

解压缩redis-2.8.3.tar.gz,并且重命名为redis

 

  1. #tar -zxvf redis-2.8.3.tar.gz
  2. #mv redis-2.8.3 redis

进入redis目录,进行编译和安装

 

  1. #make
  2. #make install

启动redis服务

 

  1. #redis-server redis.conf &

Redis默认支持主从复制的模式,具体配置如下:

修改从服务器的redis.conf,添加:

 

  1. slaveof 192.168.137.18 6379

运行过程中,通过redis-cli中命令可以动态不停机切换主从

主:

 

  1. slaveof no one

从:

 

  1. slaveof 192.168.137.19 6379

Redis默认支持snapshot和AOF两种持久化机制,前者会定期的进行数据的内存映射磁盘持久化,后者则是通过日志的方式对数据进行持久化,前者恢复数据速度快,但是当集中进行持久化的时间到来时将是高并发访问的噩梦,而AOF的问题正好相反,AOF重启回复的速度不够好,但是数据持久化几乎不影响redis对外的基本服务。

配置从的持久化aof方式:

关闭自动snapshot:

 

  1. #save 900 1
  2. #save 300 10
  3. #save 60 10000

开启AOF:

 

  1. appendonly yes

此处可以动态在redis-cli中不停机运行命令:

 

  1. CONFIG SET APPENDONLY YES

除此之外Redis还有很多优化配置项:

  1. 指定Redis监听端口,默认端口为6379

作者在自己的一篇博文中解释了为什么选用6379作为默认端口,因为6379在手机按键上MERZ对应的号码,而MERZ取自意大利歌女Alessia Merz的名字

 

  1. port 6379
  2. 绑定的主机地址

 

  1. bind 127.0.0.1
  2. 当 客户端闲置多长时间后关闭连接,如果指定为0,表示关闭该功能

 

  1. timeout 300
  2. 指定日志记录级别,Redis总共支持四个级别:debug、verbose、notice、warning,默认为verbose

 

  1. loglevel verbose
  2. 设置数据库的数量,默认数据库为0,可以使用SELECT <dbid>命令在连接上指定数据库id

 

  1. databases 16
  2. 指定存储至本地数据库时是否压缩数据,默认为yes,Redis采用LZF压缩,如果为了节省CPU时间,可以关闭该选项,但会导致数据库文件变的巨大

 

  1. rdbcompression yes
  2. 指定本地数据库文件名,默认值为dump.rdb

 

  1. dbfilename dump.rdb
  2. 指定本地数据库存放目录

 

  1. dir ./
  2. 当master服务设置了密码保护时,slav服务连接master的密码

 

  1. masterauth <master-password]]>
  2. 设置Redis连接密码,如果配置了连接密码,客户端在连接Redis时需要通过AUTH <password>命令提供密码,默认关闭

 

  1. requirepass foobared
  2. 设置同一时间最大客户端连接数,默认无限制,Redis可以同时打开的客户端连接数为Redis进程可以打开的最大文件描述符数,如果设置 maxclients 0,表示不作限制。当客户端连接数到达限制时,Redis会关闭新的连接并向客户端返回max number of clients reached错误信息

 

  1. maxclients 128
  2. 指定Redis最大内存限制,Redis在启动时会把数据加载到内存中,达到最大内存后,Redis会先尝试清除已到期或即将到期的Key,当此方法处理 后,仍然到达最大内存设置,将无法再进行写入操作,但仍然可以进行读取操作。Redis新的vm机制,会把Key存放内存,Value会存放在swap区

 

  1. maxmemory <bytes]]>
  2. 指定更新日志文件名,默认为appendonly.aof

 

  1. appendfilename appendonly.aof
  2. 指定更新日志条件,共有3个可选值:

no:表示等操作系统进行数据缓存同步到磁盘(快) always:表示每次更新操作后手动调用fsync()将数据写到磁盘(慢,安全) everysec:表示每秒同步一次(折衷,默认值)

 

  1. appendfsync everysec
  2. 指定是否启用虚拟内存机制,默认值为no,简单的介绍一下,VM机制将数据分页存放,由Redis将访问量较少的页即冷数据swap到磁盘上,访问多的页面由磁盘自动换出到内存中

 

  1. vm-enabled no
  2. 虚拟内存文件路径,默认值为/tmp/redis.swap,不可多个Redis实例共享

 

  1. vm-swap-file /tmp/redis.swap
  2. 将所有大于vm-max-memory的数据存入虚拟内存,无论vm-max-memory设置多小,所有索引数据都是内存存储的(Redis的索引数据 就是keys),也就是说,当vm-max-memory设置为0的时候,其实是所有value都存在于磁盘。默认值为0

 

  1. vm-max-memory 0
  2. Redis swap文件分成了很多的page,一个对象可以保存在多个page上面,但一个page上不能被多个对象共享,vm-page-size是要根据存储的 数据大小来设定的,作者建议如果存储很多小对象,page大小最好设置为32或者64bytes;如果存储很大大对象,则可以使用更大的page,如果不 确定,就使用默认值

 

  1. vm-page-size 32
  2. 设置swap文件中的page数量,由于页表(一种表示页面空闲或使用的bitmap)是在放在内存中的,在磁盘上每8个pages将消耗1byte的内存。

 

  1. vm-pages 134217728
  2. 设置访问swap文件的线程数,最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的,可能会造成比较长时间的延迟。默认值为4

 

  1.  vm-max-threads 4
  2. 设置在向客户端应答时,是否把较小的包合并为一个包发送,默认为开启

 

  1. glueoutputbuf yes
  2. 指定在超过一定的数量或者最大的元素超过某一临界值时,采用一种特殊的哈希算法

 

  1.  hash-max-zipmap-entries 64
  2.  hash-max-zipmap-value 512
  3. 指定是否激活重置哈希,默认为开启

 

  1. activerehashing yes
  2. 指定包含其它的配置文件,可以在同一主机上多个Redis实例之间使用同一份配置文件,而同时各个实例又拥有自己的特定配置文件

 

  1. include /path/to/local.conf


1.2. Redis操作



1.2.1. Redis各种数据类型及操作

在K,V型NOSQL数据库中redis是数据类型相当丰富的,redis的Key是一个非二进制安全的字符类型( not binary-safe strings ),其Value支持一下数据结构:

  1. String
  2. List
  3. Set
  4. Sorted set
  5. Hash

redis本质上一个key-value 数据库,首先key也是字符串类型,由于key不是binary safe的字符串,所以像“my key”和“mykey\n”这样包含空格和换行的key是不允许的。在使用的时候可以自己定义一个Key的格式。

例如 object-type:id:field

Key不要太长。占内存,查询慢,Key不要太短。

u:1000:pwd不如 user:1000:password 可读性好

Redis操作命令也是极其丰富的,具体命令如下:

Key相关命令

  1. exits key 测试指定key是否存在,返回1表示存在,0不存在
  2. del key1 key2 ....keyN  删除给定key,返回删除key的数目,0表示给定key都不存在
  3. type key返回给定key的value类型。返回 none 表示不存在,key有string字符类型,list 链表类型 set 无序集合类型等...
  4. keys pattern 返回匹配指定模式的所有key(支持*,?,[abc ]的方式)
  5. random key 返回从当前数据库中随机选择的一个key,如果当前数据库是空的,返回空串
  6. rename oldkey newkey 原子的重命名一个key,如果newkey存在,将会被覆盖,返回1表示成功,0失败。失败可能是oldkey不存在或者和newkey相同
  7. renamenx oldkey newkey 同上,但是如果newkey存在返回失败
  8. dbsize 返回当前数据库的key数量
  9. expire key seconds 为key指定过期时间,单位是秒。返回1成功,0表示key已经设置过过期时间或者不存在
  10. ttl key 返回设置了过期时间的key的剩余过期秒数, -1表示key不存在或者没有设置过过期时间
  11. select db-index 通过索引选择数据库,默认连接的数据库所有是0,默认数据库数是16个。返回1表示成功,0失败
  12. move key db-index  将key从当前数据库移动到指定数据库。返回1成功。0 如果key不存在,或者已经在指定数据库中
  13. flushdb 删除当前数据库中所有key,此方法不会失败。慎用
  14. flushall 删除所有数据库中的所有key,此方法不会失败。更加慎用

String相关命令

string是redis最基本的类型,而且string类型是二进制安全的。redis的string可以包含任何数据。包括jpg图片或者序列化的对象。最大上限是1G字节。 如果只用string类型,redis就可以被看作加上持久化特性的memcached。

  1. set key value设置key对应的值为string类型的value,返回1表示成功,0失败
  2. setnx key value同上,如果key已经存在,返回0 。nx 是not exist的意思
  3. get key获取key对应的string值,如果key不存在返回nil
  4. getset key value设置key的值,并返回key的旧值。如果key不存在返回nil
  5. mget key1 key2 ... keyN 一次获取多个key的值,如果对应key不存在,则对应返回nil。
  6. mset key1 value1 ... keyN valueN一次设置多个key的值,成功返回1表示所有的值都设置了,失败返回0表示没有任何值被设置
  7. msetnx key1 value1 ... keyN valueN同上,但是不会覆盖已经存在的key
  8. incr key对key的值做加加操作,并返回新的值。注意incr一个不是int的value会返回错误,incr一个不存在的key,则设置key为1
  9. decr key同上,但是做的是减减操作,decr一个不存在key,则设置key为-1
  10. incrby key integer同incr,加指定值 ,key不存在时候会设置key,并认为原来的value是 0
  11. decrby key integer 同decr,减指定值。decrby完全是为了可读性,我们完全可以通过incrby一个负值来实现同样效果,反之一样。
  12. append key value给指定key的字符串值追加value,返回新字符串值的长度。
  13. substr key start end返回截取过的key的字符串值,注意并不修改key的值。下标是从0开始的。

List相关命令

redis的list类型其实就是一个每个子元素都是string类型的双向链表。我们可以通过push,pop操作从链表的头部或者尾部添加删除元素。这使得list既可以用作栈,也可以用作队列。

list的pop操作还有阻塞版本的。当我们[lr]pop一个list对象是,如果list是空,或者不存在,会立即返回nil。但是阻塞版本的b[lr]pop可以则可以阻塞,当然可以加超时时间,超时后也会返回nil。为什么要阻塞版本的pop呢,主要是为了避免轮询。举个简单的例子如果用list来实现一个工作队列。执行任务的thread可以调用阻塞版本的pop去获取任务这样就可以避免轮询去检查是否有任务存在。当任务来时候工作线程可以立即返回,也可以避免轮询带来的延迟。

  1. lpush key string在key对应list的头部添加字符串元素,返回1表示成功,0表示key存在且不是list类型
  2. rpush key string同上,在尾部添加
  3. llen key返回key对应list的长度,key不存在返回0,如果key对应类型不是list返回错误
  4. lrange key start end返回指定区间内的元素,下标从0开始,负值表示从后面计算,-1表示倒数第一个元素 ,key不存在返回空列表
  5. ltrim key start end截取list,保留指定区间内元素,成功返回1,key不存在返回错误
  6. lset key index value设置list中指定下标的元素值,成功返回1,key或者下标不存在返回错误
  7. lrem key count value从key对应list中删除count个和value相同的元素。count为0时候删除全部
  8. lpop key从list的头部删除元素,并返回删除元素。如果key对应list不存在或者是空返回nil,如果key对应值不是list返回错误
  9. rpop同上,但是从尾部删除
  10. blpop key1...keyN timeout从左到右扫描返回对第一个非空list进行lpop操作并返回,比如blpop list1 list2 list3 0 ,如果list不存在,list2,list3都是非空则对list2做lpop并返回从list2中删除的元素。如果所有的list都是空或不存在,则会阻塞timeout秒,timeout为0表示一直阻塞。当阻塞时,如果有client对key1...keyN中的任意key进行push操作,则第一在这个key上被阻塞的client会立即返回。如果超时发生,则返回nil。
  11. brpop 同blpop,一个是从头部删除一个是从尾部删除
  12. rpoplpush srckey destkey从srckey对应list的尾部移除元素并添加到destkey对应list的头部,最后返回被移除的元素值,整个操作是原子的.如果srckey是空或者不存在返回nil

Set相关命令

redis的set是string类型的无序集合。set元素最大可以包含(2的32次方-1)个元素。set的是通过hash table实现的,hash table会随着添加或者删除自动的调整大小,关于set集合类型除了基本的添加删除操作,其他有用的操作还包含集合的取并集(union),交集(intersection),差集(difference)。通过这些操作可以很容易的实现sns中的好友推荐和blog的tag功能。

  1. sadd key member 添加一个string元素到,key对应的set集合中,成功返回1,如果元素以及在集合中返回0,key对应的set不存在返回错误
  2. srem key member 从key对应set中移除给定元素,成功返回1,如果member在集合中不存在或者key不存在返回0,如果key对应的不是set类型的值返回错误
  3. spop key 删除并返回key对应set中随机的一个元素,如果set是空或者key不存在返回nil
  4. srandmember key 同spop,随机取set中的一个元素,但是不删除元素
  5. smove srckey dstkey member 从srckey对应set中移除member并添加到dstkey对应set中,整个操作是原子的。成功返回1,如果member在srckey中不存在返回0,如果key不是set类型返回错误
  6. scard key 返回set的元素个数,如果set是空或者key不存在返回0
  7. sismember key member 判断member是否在set中,存在返回1,0表示不存在或者key不存在
  8. sinter key1 key2...keyN 返回所有给定key的交集
  9. sinterstore dstkey key1...keyN 同sinter,但是会同时将交集存到dstkey下
  10. sunion key1 key2...keyN 返回所有给定key的并集
  11. sunionstore dstkey key1...keyN 同sunion,并同时保存并集到dstkey下
  12. sdiff key1 key2...keyN 返回所有给定key的差集
  13. sdiffstore dstkey key1...keyN 同sdiff,并同时保存差集到dstkey下
  14. smembers key 返回key对应set的所有元素,结果是无序的

SortSet相关命令

和set一样sorted set也是string类型元素的集合,不同的是每个元素都会关联一个double类型的score。sorted set的实现是skip list和hash table的混合体。当元素被添加到集合中时,一个元素到score的映射被添加到hash table中,另一个score到元素的映射被添加到skip list,并按照score排序,所以就可以有序的获取集合中的元素。

  1. zadd key score member 添加元素到集合,元素在集合中存在则更新对应score
  2. zrem key member 删除指定元素,1表示成功,如果元素不存在返回0
  3. zincrby key incr member 增加对应member的score值,然后移动元素并保持skip list有序。返回更新后的score值
  4. zrank key member 返回指定元素在集合中的排名(下标,非score),集合中元素是按score从小到大排序的
  5. zrevrank key member 同上,但是集合中元素是按score从大到小排序
  6. zrange key start end 类似lrange操作从集合中取指定区间的元素。返回的是有序结果
  7. zrevrange key start end 同上,返回结果是按score逆序的
  8. zrangebyscore key min max 返回集合中score在给定区间的元素
  9. zcount key min max 返回集合中score在给定区间的数量
  10. zcard key 返回集合中元素个数
  11. zscore key element  返回给定元素对应的score
  12. zremrangebyrank key min max 删除集合中排名在给定区间的元素
  13. zremrangebyscore key min max 删除集合中score在给定区间的元素

Hash相关命令

redis hash是一个string类型的field和value的映射表。

hash特别适合用于存储对象。相较于将对象的每个字段存成单个string类型。将一个对象存储在hash类型中会占用更少的内存,并且可以更方便的存取整个对象。

  1. hset key field value设置hash field为指定值,如果key不存在,则先创建
  2. hget key field 获取指定的hash field
  3. hmget key filed1....fieldN 获取全部指定的hash filed
  4. hmset key filed1 value1 ... filedN valueN 同时设置hash的多个field
  5. hincrby key field integer 将指定的hash filed 加上给定值
  6. hexists key field 测试指定field是否存在
  7. hdel key field 删除指定的hash field
  8. hlen key 返回指定hash的field数量
  9. hkeys key 返回hash的所有field
  10. hvals key 返回hash的所有value
  11. hgetall 返回hash的所有filed和value


1.2.2. Redis事务

redis对事务的支持目前还比较简单。redis只能保证一个client发起的事务中的命令可以连续的执行,而中间不会插入其他client的命令。

  1. Multi事物开始
  2. Exec 执行事务
  3. Discard 放弃事物
  4. Watch 监听key
  5. Unwatch 放弃所有key的监听

watch 命令会监视给定的key,当exec时候如果监视的key从调用watch后发生过变化,则整个事务会失败。注意watch的key是对整个连接有效的,和事务一样,如果连接断开,监视和事务都会被自动清除。

Multi 、 Exec 用来开启和执行事务,如下图所示:

图 1 Multi、Exec

Discard命令用于取消事务,具体如下图:

图 2 Discard

Watch、Unwatch用于监视和取消监视相关的key:

图 3 watch

图 4 unwatch



1.2.3. 发布订阅

发布订阅(pub/sub)是一种消息通信模式。订阅者可以通过subscribe和psubscribe命令向redis server订阅自己感兴趣的消息类型,redis将消息类型称为通道(channel)。当发布者通过publish命令向redis server发送特定类型的消息时。订阅该消息类型的全部client都会收到此消息。这里消息的传递是多对多的。一个client可以订阅多个 channel,也可以向多个channel发送消息。

  1. subscribe
  2. unsubscribe
  3. psubscribe
  4. punsubscribe
  5. publish
  6. pubsub

Publish用于发布消息到主题,如下图所示:

图 5 publish

除了发布数据到简单的队列,还可以将队列进行编组,通过‘.’来进行队列组划分,下图是将数据发布到某个组的队列中:

图 6 publish到某个组的某个队列

subscribe用于订阅普通的队列:

图 7 subscribe

unsubscribe用于取消队列,运行以下命令即可:

 

  1. #unsubscribe a b
  2. 或者#unsubscribe

psubscribe用于订阅组队列的信息:

图 8 psubscribe

punsubscribe用于取消队列组的订阅。

pubsub用于监控队列的状态:

  1. pubsub channels列出所有的队列
  2. pubsub channels a.* 列出所有a组队列的订阅
  3. pubsub numsub a.* a组队列订阅个数
  4. pubsub numpat 订阅模式个数(多个用户订阅相同的模式比如 psubscribe a.b,这个命令统计出来的是多个而不是就一种模式,此处应用要注意)

 

  1. }


1.3. Jedis



1.3.1. 初始化连接

直接连接Redis:

 

  1. Jedis jedis = new Jedis(SERVER_ADDRESS, SERVER_PORT);

这样有一个问题,当并发量很大连接的建立将会很花费时间,因此Redis提供了连接池:

初始化连接池

 

  1. JedisPoolConfig jpc = new JedisPoolConfig();
  2. jpc.setMaxActive(100);
  3. // …………
  4. jp = new JedisPool(jpc, SERVER_ADDRESS, SERVER_PORT, 2000);

销毁连接池

 

  1. jp.destroy();

使用和退回连接

 

  1. Jedis jedis = jp.getResource();
  2. try {
  3.     …………
  4. } catch (JedisConnectionException e) {
  5.     if (null != jedis) {
  6.         jp.returnBrokenResource(jedis);
  7.         jedis = null;
  8.     }
  9. } finally {
  10.     if (null != jedis)
  11.         jp.returnResource(jedis);
  12. }

以下是连接池的优化配置项:

  1. maxActive

控制池中对象的最大数量。默认值是8,如果是负值表示没限制。

  1. maxIdle

控制池中空闲的对象的最大数量。默认值是8,如果是负值表示没限制。

  1. minIdle

控制池中空闲的对象的最小数量。默认值是0。

  1. whenExhaustedAction

指定池中对象被消耗完以后的行为,有下面这些选择:

>> WHEN_EXHAUSTED_FAIL 0

>> WHEN_EXHAUSTED_GROW 2

>> WHEN_EXHAUSTED_BLOCK 1

如果是WHEN_EXHAUSTED_FAIL,当池中对象达到上限以后,继续borrowObject会抛出NoSuchElementException异常。

如果是WHEN_EXHAUSTED_GROW,当池中对象达到上限以后,会创建一个新对象,并返回它。

如果是WHEN_EXHAUSTED_BLOCK,当池中对象达到上限以后,会一直等待,直到有一个对象可用。这个行为还与maxWait有关,如果maxWait是正数,那么会等待maxWait的毫秒的时间,超时会抛出NoSuchElementException异常;如果maxWait为负值,会永久等待。

whenExhaustedAction 的默认值是WHEN_EXHAUSTED_BLOCK,maxWait的默认值是-1。

  1. maxWait

whenExhaustedAction 如果是WHEN_EXHAUSTED_BLOCK,指定等待的毫秒数。如果maxWait是正数,那么会等待maxWait的毫秒的时间,超时会抛出NoSuchElementException异常;如果maxWait为负值,会永久等待。maxWait的默认值是-1。

  1. testOnBorrow

如果testOnBorrow被设置,pool会在borrowObject返回对象之前使用PoolableObjectFactory的validateObject来验证这个对象是否有效,要是对象没通过验证,这个对象会被丢弃,然后重新选择一个新的对象。testOnBorrow的默认值是false。

  1. testOnReturn

如果testOnReturn被设置,pool会在returnObject的时候通过PoolableObjectFactory的validateObject方法验证对象,如果对象没通过验证,对象会被丢弃,不会被放到池中。testOnReturn的默认值是false。

  1. testWhileIdle

指定idle对象是否应该使用PoolableObjectFactory的validateObject校验,如果校验失败,这个对象会从对象池中被清除。这个设置仅在timeBetweenEvictionRunsMillis被设置成正值(>0)的时候才会生效。testWhileIdle的默认值是false。

  1. timeBetweenEvictionRunsMillis

指定驱逐线程的休眠时间。如果这个值不是正数(>0),不会有驱逐线程运行。timeBetweenEvictionRunsMillis的默认值是-1。

numTestsPerEvictionRun

设置驱逐线程每次检测对象的数量。这个设置仅在timeBetweenEvictionRunsMillis被设置成正值(>0)的时候才会生效。numTestsPerEvictionRun的默认值是3。

  1. minEvictableIdleTimeMillis

指定最小的空闲驱逐的时间间隔(空闲超过指定的时间的对象,会被清除掉)。这个设置仅在timeBetweenEvictionRunsMillis被设置成正值(>0)的时候才会生效。minEvictableIdleTimeMillis默认值是30分钟。

  1. softMinEvictableIdleTimeMillis

与minEvictableIdleTimeMillis类似,也是指定最小的空闲驱逐的时间间隔(空闲超过指定的时间的对象,会被清除掉),不过会参考minIdle的值,只有idle对象的数量超过minIdle的值,对象才会被清除。这个设置仅在timeBetweenEvictionRunsMillis被设置成正值(>0)的时候才会生效,并且这个配置能被minEvictableIdleTimeMillis配置取代(minEvictableIdleTimeMillis配置项的优先级更高)。softMinEvictableIdleTimeMillis的默认值是-1。

  1. lifo

pool可以被配置成LIFO队列(last-in-first-out)或FIFO队列(first-in-first-out),来指定空闲对象被使用的次序。lifo的默认值是true。

一致性Hash分片

数据放在一台服务节点上,服务节点需要处理所有的数据,对于节点本身压力很大,数据需要分片到多台服务器上,实现数据服务的负载均衡,通常使用的方法是根据key的hashcode与服务器个数进行mod,然后得到1就分到第一台上,2就分到第二台上

但是这种分配在添加新的服务器的时候将会成为一种空前的灾难

于是我们使用一致性hash算法进行分片如下图:

图 9 一致性HASH

需要插入的数据首先与2的32次方进行取模运算,数据将会落在一个收尾闭合的环上,然后每个物理节点也将通过同样的算法计算出在环上的直至,然后数据向顺时针方向移动到最近的一台服务节点上。

当添加一台新节点的时候,如下图所示:

图 10 一致性HASH添加节点

很容易看到只有少数的数据会被重新分配,其余数据不受影响。

但是又带来了新的问题,新加入的节点无法分担其他多点服务器的压力,因此算法继续改良后的到我们现在用到的版本,每个节点将虚拟一圈的虚拟节点,数据同样顺时针移动到虚拟节点中,然后虚拟节点的数据又重新映射到物理节点中,这样数据将非常平均。

Jedis提供了一致性hash的分片方法,首先添加分片服务器

 

  1. List<JedisShardInfo]]> shards = new ArrayList<JedisShardInfo>();
  2. JedisShardInfo si =null;
  3. si= new JedisShardInfo("192.168.137.18", 6379,"N1");
  4. shards.add(si);
  5. si = new JedisShardInfo("192.168.137.19", 6379,"N2");
  6. shards.add(si);

然后建立没台服务节点的连接池:

 

  1. ShardedJedisPool pool = new ShardedJedisPool(new Config(), shards);
  2. ShardedJedis jedis = pool.getResource();
  3. JedisShardInfo jsi = jedis.getShardInfo("b1");//a1会hash到N2上
  4. System.out.println(jsi.getHost()+"\t"+jsi.getPort()+"\t"+jsi.getName());
  5. pool.returnResource(jedis);
  6. pool.destroy();


1.3.2. 基本操作

Jedis对各种数据类型操作与命令名称完全一致

 

  1. jedis.函数名();//函数名就是命令名

例如list的操作:

 

  1. // 将zhangsan加入到students的末尾
  2. jedis.lpush("students", "zhangsan");
  3. // 将zhaoliu 加入students数组的结尾
  4. jedis.rpush("students", "zhaoliu");
  5. // 移除students的第一个元素
  6. jedis.lpop("students");
  7. // 移除students的最后一个元素
  8. jedis.rpop("students");
  9. // 移除制定的元素,第二个参数表示要移除的个数,因为list中是允许出现重复元素的
  10. jedis.lrem("students", 1, "zhangsan");
  11. // 获取students数组的所有元素
  12. List<String]]> students = jedis.lrange("students", 0, -1);

Jedis的事务处理也是相当的简单,Redis对事物的操作封装了Transaction对象,该对象的操作方法与Jedis的各种数据类型的操作方法一致,通过jedis的multi方法返回一个事务对象,如以下代码:

 

  1. Jedis jedis = new Jedis(SERVER_ADDRESS, SERVER_PORT);
  2. jedis.watch("f2");
  3. jedis.set("f2", "aaa");
  4. jedis.unwatch();
  5. Transaction t = jedis.multi();
  6. t.set("f2", "bar");
  7. Response<String]]> result1 = t.get("f2");
  8. String foolbar=“”;
  9. // foolbar = result1.get();
  10. // System.out.println(foolbar);        
  11. t.exec();
  12. foolbar = result1.get();
  13. jedis.disconnect();

对于订阅发布Jedis提供的所有订阅发布的实现方法,发布数据相对简单,如下代码示例:

 

  1. jedis.publish("news.test2", "jhhjhh1");

订阅则更为简单,Jedis直接通过继承JedisPubSub类来实现所有的订阅操作方法,如下代码示例:

 

  1. public class TestSub extends JedisPubSub {
  2. //取得订阅的消息后的处理
  3. public void onMessage(String channel, String message) ;
  4. //取得按表达式的方式订阅的消息后的处理
  5. public void onPMessage(String pattern, String channel, String message) ;
  6. //初始化订阅时候的处理
  7. public void onSubscribe(String channel, int subscribedChannels) ;    
  8. //取消订阅时候的处理
  9. public void onUnsubscribe(String channel, int subscribedChannels)    ;
  10. //取消按表达式的方式订阅时候的处理
  11. public void onPUnsubscribe(String pattern, int subscribedChannels) ;//初始化按表达式的方式订阅时候的处理
  12. public void onPSubscribe(String pattern, int subscribedChannels) ;
  13. }
  14. jedis.subscribe(jedisPubSub, "news.test2");


1.3.3. 管道

redis是一个cs模式的tcp server,使用和http类似的请求响应协议。一个client可以通过一个socket连接发起多个请求命令。每个请求命令发出后client通常 会阻塞并等待redis服务处理,redis处理完后请求命令后会将结果通过响应报文返回给client。基本的通信过程如下

 

  1. Client: INCR X
  2. Server: 1
  3. Client: INCR X
  4. Server: 2
  5. Client: INCR X
  6. Server: 3
  7. Client: INCR X
  8. Server: 4

基本上四个命令需要8个tcp报文才能完成。由于通信会有网络延迟,假如从client和server之间的包传输时间需要0.125秒。那么上面的四个命令8个报文至少会需要1秒才能完成。利用pipeline的方式从client打包多条命令一起发出,不需要等待单条命令的响应返回,而redis服务端会处理完多条命令后会将多条命令的处理结果打包到一起返回给客户端。通信过程如下

 

  1. Client: INCR X
  2. Client: INCR X
  3. Client: INCR X
  4. Client: INCR X
  5. Server: 1
  6. Server: 2
  7. Server: 3
  8. Server: 4

具体方法是用如下示例:

 

  1. Jedis jedis = new Jedis(SERVER_ADDRESS, SERVER_PORT);
  2. Pipeline p = jedis.pipelined();
  3. p.set("r1", "bar");
  4. p.zadd("r2", 1, "barowitch");
  5. p.zadd("r2", 0, "barinsky");
  6. p.zadd("r2", 0, "barikoviev");
  7. Response<String]]> pipeString = p.get("r1");
  8. Response<Set<String>> sose = p.zrange("r2", 0, -1);
  9. p.sync();
  10. jedis.disconnect();


2. Thrift开发



2.1. Thrift开发



2.1.1. Thrift概述

目前流行的开源多语言RPC框架如下所示:

  1. Facebook的Thrift:基于C++,开源,跨语言C++、C#、Erlang、Java、Perl、PHP、Python、Ruby、HTML、XSD、Smalltalk、Cocoa、OCaml、Haskell
  2. Google的Protocol Buffers:基于C++,开源,基于C++, Java, Python
  3. Baidu使用的ICE基于C++,开源
  4. Renren使用ACE基于C++(比ICE底层)

所谓RPC就是远程的过程方法调用,也就是说在本地执行一个远程的方法实现,Thrift就是这种类型的开源项目。Thrift基于IDL中间语法定义无语言相关的接口文件,然后通过thrift解释为各种语言可以识别的语法格式接口并关联实现,该框架非常类似于早期的corba。Thrift可以提供多语言的支持,换句话说发布一个java开发的服务RPC接口,可以用各种不同的语言进行调用使用,具体如下图所示:

图 11 Thrift多语言



2.1.2. Thrift安装

目前流行的开源多语言RPC框架如下所示:

使用yum安装准备环境:

 

  1. #yum -y install automake libtool flex bison pkgconfig gcc-c++ boost-devel libevent-devel zlib-devel python-devel ruby-devel openssl openssl-devel

安装ant和ivy环境:

解压缩apache-ant-1.8.2-bin.tar.gz并重命名为ant

 

  1. #tar -zxvf apache-ant-1.8.2-bin.tar.gz
  2. #mv apache-ant-1.8.2 ant

配置环境变量:

通过vi编辑器编辑:

 

  1. #vi /etc/profile

打开vi编辑器后,按下"i"键进入插入编辑模式,将以下内容编辑到文本末尾:

 

  1. ANT_HOME=/home/soft01/ant
  2. PATH=PATH:$ANT_HOME/bin

按“ESC”键进入命令行模式,然后输入如下内容保存退出,并使环境变量生效:

 

  1. /wq!
  2. #exit
  3. #source /etc/profile

解压缩apache-ivy-2.2.0-bin.tar.gz并重命名为ivy:

 

  1. #tar -zxvf apache-ivy-2.2.0-bin.tar.gz
  2. #mv apache-ivy-2.2.0 ivy

拷贝ivy下的核心jar到ant的lib目录中:

 

  1. #cp /home/soft01/ivy/ivy-2.2.0.jar /home/soft01/ant/lib/

安装thrift:

解压缩thrift-0.9.1.tar.gz并重命名为thrift:

 

  1. #tar -zxvf thrift-0.9.1.tar.gz
  2. #mv thrift-0.9.1 thrift

进入thrift目录,进行编译和安装:

 

  1. #./configure  --with-boost=/usr/local
  2. #make
  3. #make install


2.1.3. Thrift IDL

Thrift数据类型如下所示:

  1. bool true, false
  2. byte 8位的有符号整数
  3. i16 16位的有符号整数
  4. i32 32位的有符号整数
  5. i64 64位的有符号整数
  6. double 64位的浮点数
  7. string UTF-8编码的字符串
  8. binary 字符数组
  9. struct 结构体
  10. list<type> 有序的元素列表,类似于STL的vector
  11. set<type> 无序的不重复元素集,类似于STL的set
  12. map<type1,type2> key-value型的映射,类似于STL的map
  13. exception 是一个继承于本地语言的exception基类
  14. service服务 包含多个函数接口(纯虚函数)

Thrift定义接口文件分为复杂数据类型定义和服务接口定义,定义数据类型其实就可以理解为定义类,thrift使用struct来对应类,由于很多语言是没有类的概念的,但是基本都有结构体和共同体的概念,因此使用结构体高度抽象了类的概念,但是正因为如此,Thrift没法进行继承操作。

此外定义结构体里面的属性的时候需要在每个参数前编写行号,具体的定义如下所示:

 

  1. struct User {
  2. 1: i32 uid,
  3. 2: string name
  4. }

定义服务接口不需要写明接口修饰符如public等,因为thrift没有继承的概念,需要注意的是接口的参数列表需要著名参数编号,如下所示:

 

  1. service UserService {
  2. void store(1: User user),
  3. User retrieve(1: i32 uid)
  4. }

通过thrift命令可以将thrift的idl接口导出各语言源代码,具体导出命令如下:

 

  1. thrift –r –gen py service.thrift
  2. thrift –r –gen java servcie.thrift

可导出语言配置

cocoa(Cocoa)、cpp(C++)、csharp(C#)、erl(Erlang)、hs(Haskell)、html(HTML)、java(Java)、ocaml(OCaml)、perl(Perl)、php(PHP)、py(Python)、rb(Ruby)、st(Smalltalk)、xsd(XSD)



2.1.4. Thrift开发

首先需要实现上一章Thrift生成的接口,具体实例代码如下:

 

  1. public class XXXService implements IXXXService.Iface

需要注意的是,接口是Iface而并非IXXXService。

Thrift有很多种服务提供类,最常用的莫过于TThreadPoolServer和TNonblockingServer,这两个类一个定义的是同步多线程处理服务,一个是异步单线程处理服务,其他的thrift服务类几乎使用不到。

对于严格要求同步返回的调用,也就是一致性要求高的应用,必须使用TThreadPoolServer,比如调用后端接口返回数据的。

而对于返回信息可有可无的,并且调用成功失败也无伤大雅的但并发很高的服务可以考虑使用TNonblockingServer如TTS7.0知识库记录热点搜索词的功能。

为了提升效率,我们采用NIO的方式进行数据传输,对于Thrift封装的类是TFramedTransport,使用该类进行数据传输可以大大提升效率,并且同时使用上压缩效果更佳,压缩对应的类为TCompactProtocol。

以下分别展示同步服务和异步服务以及客户端的代码:

同步服务端:

 

  1. TServerSocket serverTransport = new TServerSocket(8080);
  2. IXXXService.Processor<Iface]]> processor =
  3. new IXXXService.Processor<Iface>(new XXXService());
  4. TThreadPoolServer.Args arg =
  5. new TThreadPoolServer.Args(serverTransport);
  6. arg.protocolFactory(new TCompactProtocol.Factory());
  7. arg.transportFactory(new TFramedTransport.Factory());
  8. arg.processorFactory(new TProcessorFactory(processor));
  9. arg.maxWorkerThreads(10000);
  10. arg.minWorkerThreads(50);
  11. TThreadPoolServer server = new TThreadPoolServer(arg);
  12. server.serve();

同步客户端:

 

  1. TTransport transport = new TFramedTransport(new TSocket(“127.0.0.1", 80));
  2. TProtocol protocol = new TCompactProtocol(transport);
  3. IXXXService.Client client = new IXXXService.Client(protocol);
  4. transport.open();
  5. client.xxx();

异步服务端:

 

  1. TNonblockingServerTransport serverTransport =
  2. new TNonblockingServerSocket(8080);
  3. IXXXService.Processor<Iface]]> processor =
  4. new IXXXService.Processor<Iface>(new XXXService());
  5. TNonblockingServer.Args arg =
  6. new TNonblockingServer.Args(serverTransport);
  7. arg.protocolFactory(new TCompactProtocol.Factory());
  8. arg.transportFactory(new TFramedTransport.Factory());
  9. arg.processorFactory(new TProcessorFactory(processor));
  10. TServer server = new TNonblockingServer(arg);
  11. server.serve();

异步客户端:

 

  1. TAsyncClientManager clientManager = new TAsyncClientManager();
  2. TNonblockingTransport transport = new TNonblockingSocket(
  3. "localhost", 8080);
  4. TProtocolFactory protocol = new TCompactProtocol.Factory();
  5. IXXXService.AsyncClient asyncClient =
  6. new IXXXService.AsyncClient(protocol, clientManager, transport);
  7. MethodCallback callBack = new MethodCallback();
  8. asyncClient.XXX(XXX, callBack);

客户端回调:

 

  1. public class MethodCallback implements AsyncMethodCallback {
  2.     Object res = null;
  3.     public Object getResult() {
  4.         // 返回结果值
  5.         return this.res;
  6.     }
  7.     // 处理服务返回的结果值
  8.     public void onComplete(Object response) {
  9.         this.res = response;
  10.     }
  11.     // 处理调用服务过程中出现的异常
  12.     public void onError(Exception ex) {
  13.         ex.printStackTrace();
  14.     }
  15. }


3. 初识Hadoop2



3.1. Hadoop2概述



3.1.1. Hadoop1的局限

HDFS的局限性主要体现在以下几点:

  1. 资源隔离
  2. 元数据扩展性
  3. 访问效率
  4. 数据丢失

回顾HDFS的架构图:

图 12 HDFS

MapReduce的局限性主要体现在以下几点:

  1. 扩展性

集群最大节点数–4000,最大并发任务数–40000

当 map-reduce job非常多的时候,会造成很大的内存开销,潜在来说,也增加了 JobTracker fail 的风险,这也是业界普遍总结出老 Hadoop 的 Map-Reduce 只能支持 4000 节点主机的上限。

  1. 可用性

JobTracker负载较重

存在单点故障, 一旦故障,

所有执行的任务的全部失败

  1. 批处理模式,时效性低

仅仅使用MapReduce一种计算方式

  1. 低效的资源管理

把资源强制划分为 map task slot 和 reduce task slot, 当系统中只有 map task 或者只有 reduce task 的时候,会造成资源的浪费

回顾MR的架构图:

图 13 MR



3.1.2. Hadoop2的改进

针对以上问题,Hadoop2做了很大的改进,可以说Hadoop2和hadoop1是完全不同的架构。Hadoop 2新特性如下所示:

  1. 由HDFS、MapReduce和YARN三个分支构成
  2. HDFS:支持NN Federation、HA
  3. MapReduce:运行在YARN上的MR,编程模型不变
  4. YARN:资源管理系统等

改变后的特点如下:

  1. 直接源于MRv1在几个方面的无能

扩展性差,JobTracker成为瓶颈

可靠性差,NameNode单点故障

扩展性差,难以支持MR之外的计算

资源利用率低

  1. 多计算框架各自为战,数据共享困难

MR:离线计算框架

Storm:实时计算框架

Spark:内存计算框架

具体架构如下图所示:

图 14 Hadoop2

Hadoop 2提供了YARN架构及组件,废弃了hadoop1的jobtracker和tasktracker,取而代之的是以下几个功能模块:

  1. ResourceManager

处理客户端请求

启动/监控ApplicationMaster

监控NodeManager

资源分配与调度

  1. NodeManager

单个节点上的资源管理

处理来自ResourceManager的命令

处理来自ApplicationMaster的命令

  1. ApplicationMaster

数据切分

为应用程序申请资源,并分配给内部任务

任务监控与容错

组件交互如下图所示:

图 15 Yarn-1

图 16 Yarn-2

具体作业执行流程如下图:

图 17 作业执行流程

  1. 用户向YARN 中提交应用程序, 其中包括ApplicationMaster 程序、启动ApplicationMaster 的命令、用户程序等。
  2. ResourceManager 为该应用程序分配第一个Container, 并与对应的NodeManager 通信,要求它在这个Container 中启动应用程序的ApplicationMaster。
  3. ApplicationMaster 首先向ResourceManager 注册, 这样用户可以直接通过ResourceManage 查看应用程序的运行状态,然后它将为各个任务申请资源,并监控它的运行状态,直到运行结束,即重复步骤4~7。
  4. ApplicationMaster 采用轮询的方式通过RPC 协议向ResourceManager 申请和领取资源。
  5. 一旦ApplicationMaster 申请到资源后,便与对应的NodeManager 通信,要求它启动任务。
  6. NodeManager 为任务设置好运行环境(包括环境变量、JAR 包、二进制程序等)后,将任务启动命令写到一个脚本中,并通过运行该脚本启动任务。
  7. 各个任务通过某个RPC 协议向ApplicationMaster 汇报自己的状态和进度,以让ApplicationMaster 随时掌握各个任务的运行状态,从而可以在任务失败时重新启动任务。在应用程序运行过程中,用户可随时通过RPC 向ApplicationMaster 查询应用程序的当前运行状态。
  8. 应用程序运行完成后,ApplicationMaster 向ResourceManager 注销并关闭自己。

对于hadoop1的资源调度核心概念:Slot,只能实现资源的静态管理和分配。

Hadoop 1采用了静态资源设置策略,即每个节点实现配置好可用的slot总数,这些slot数目一旦启动后无法再动态修改。

Hadoop 1将slot分为Map slot和Reduce slot两种,不允许共享,同时其它应用也无法共享资源。

没引入有效的资源隔离机制,采用了基于jvm的资源隔离机制,过于粗糙,很多资源,比如CPU,无法进行隔离。

而Hadoop2核心概念:Container,实现资源动态管理和分配,如下图:

图 18 调度

Yarn支持CPU和内存两种资源调度方式,允许配置每个节点、每个任务可用的CPU和内存资源总量,可以根据实际需要和CPU性能将每个物理CPU划分成若干个,可以参看下图:

图 19 调度2

YARN上运行的软件如下图所示:

图 20 Yarn运行的软件

运行在YARN上带来的好处 如下:

  1. 一个集群部署多个版本
  2. 计算资源按需伸缩
  3. 不同负载应用混搭,集群利用率高
  4. 共享底层存储,避免数据跨集群迁移


3.1.3. NameNode HA

Hadoop1的HDFS缺陷需要通过很复杂的手段规避:

Secondary NameNode:阶段性合并edits和fsimage以缩短集群启动时间,不是HA ,无法立刻接管失效的NN及保证数据完整性

Backup NameNode (HADOOP-4539):它在内存中复制了NN的当前状态,算是Warm Standby,但无法保证数据完整性

手动把name.dir指向NFS:这是安全的Cold Standby,可以保证元数据不丢失,但集群的恢复则完全靠手动

Facebook AvatarNode:Hot Standby,无法自动切换,需要管理员手动把对外提供服务的虚拟IP映射到Standby NN

其它依赖外部的HA机制,譬如DRBD+PaceMaker+Crosync+Cman

而Hadoop2架构与生具来的支持单点故障的缺陷,如下图:

图 21 HA

其利用共享存储在两个NN间同步edits信息,如NFS等中高端存储设备内部的各种RAID以及冗余硬件,DataNode同时向两个NN汇报块信息,让Standby NN保持集群最新状态。

用FailoverController watchdog进程监视和控制NN进程,防止因 NN FullGC挂起无法发送heart beat

防止脑裂(brain-split):主备切换时由于切换不彻底等原因导致Slave误以为出现两个active master,通常采用Fencing机制:

  1. 共享存储fencing,确保只有一个NN可以写入edits
  2. 客户端fencing,确保只有一个NN可以响应客户端的请求
  3. DN fencing,确保只有一个NN可以向DN下发删除等命令


3.1.4. NameNode Federation

Hadoop 1.0版本容量及性能缺陷:

  1. 单NameNode容量限制:按常规的估算公式1百万个块需要1G内存,1亿个文件NameNode进程可能需要上百G内存保存元数据信息,受制于Java内存管理能力限制,上百G内存保基本上达到上限
  2. 单NameNode性能限制:所有的元数据信息的读取和操作都需要与NameNode进行通信,如客户端的addBlock、getBlockLocations,DataNode的blockRecieved、blockReport等操作,在集群规模变大后, NameNode 会成为性能瓶颈

2.0 Federation实现方式:

Federation由多个NameService组成,每个NameService又由一个或两个(HA)NN组成,每个NameNode会定义一个存储池,单独对外提供服务,多个NameNode共用集群里DataNode上的存储资源。使用客户端挂载表把不同的目录映射到不同的NameNode上,通过目录自动对应NameNode,使Federation的配置改动对应用透明。

图 22 Federation



3.2. Hadoop2完整安装



3.2.1. Hadoop2安装

环境准备,参看hadoop安装

服务器规划如下:

master1-hadoop2: 192.168.137.23 主机名:master1

(active namenode,RM)
master1-ha-hadoop2: 192.168.137.24 主机名:masterha1
(standby namenode,jn)
master2-hadoop2: 192.168.137.31 主机名:master2
(active namenode,jn)
master2-ha-hadoop2: 192.168.137.40 主机名:masterha2
(standby namenode,jn)
slave1-hadoop2: 192.168.137.25 主机名:slave1
(datanode,nodemanager)
slave2-hadoop2: 192.168.137.26 主机名:slave2
(datanode,nodemanager)
slave3-hadoop2: 192.168.137.27 主机名:slave3
(datanode,nodemanager)
三台机器安装zookeeper,本例中三台服务器为masterha1、masterha2和master2(具体参看zookeeper安装)
接下来开始进行安装:
1. 解压缩hadoop-2.2.0.tar.gz 并改名为hadoop2 添加环境变量HADOOP_HOME、PATH(注意除了bin目录外还有sbin目录)
2. 建立数据目录
权限设置为755(mkdir -m 755 xxx)
 
1. #mkdir -m 755 namedir
2. #mkdir -m 755 datadir
3. #mkdir -m 755 jndir
4. #mkdir -m 755 temp
5. #mkdir -m 755 hadoopmrsys
6. #mkdir -m 755 hadoopmrlocal
7. #mkdir -m 755 nodemanagerlocal
8. #mkdir -m 755 nodemanagerlogs
9. #mkdir -m 755 nodemanagerremote
10. 进入目录HADOOP_HOME/etc/hadoop
11. 修改core-site.xml
 
1. <configuration]]>
2. <property]]>
3. <name]]>fs.defaultFS</name]]>
4. <value]]>viewfs:///</value>
5. </property]]>
6. <property]]>
7. <name]]>fs.viewfs.mounttable.default.link./tmp</name]]>
8. <value]]>hdfs://hadoop-cluster1/tmp</value>
9. </property]]>
10. <property]]>
11. <name]]>fs.viewfs.mounttable.default.link./tmp1</name]]>
12. <value]]>hdfs://hadoop-cluster2/tmp2</value>
13. </property]]>
14. </configuration]]>
15. 修改hdfs-site.xml
 
1. <configuration]]>
2. <!--cluster1-->
3. <property]]>
4. <name]]>dfs.nameservices</name]]>
5. <value]]>hadoop-cluster1,hadoop-cluster2</value]]>
6. </property]]>
7. <property]]>
8. <name]]>dfs.ha.namenodes.hadoop-cluster1</name]]>
9. <value]]>nn1,nn2</value]]>
10. </property]]>
11. <property]]>
12. <name]]>dfs.namenode.rpc-address.hadoop-cluster1.nn1</name]]>
13. <value]]>master1:9000</value]]>
14. </property]]>
15. <property]]>
16. <name]]>dfs.namenode.rpc-address.hadoop-cluster1.nn2</name]]>
17. <value]]>masterha1:9000</value]]>
18. </property]]>
19. <property]]>
20. <name]]>dfs.namenode.http-address.hadoop-cluster1.nn1</name]]>
21. <value]]>master1:50070</value]]>
22. </property]]>
23. <property]]>
24. <name]]>dfs.namenode.http-address.hadoop-cluster1.nn2</name]]>
25. <value]]>masterha1:50070</value]]>
26. </property]]>
27. <property]]>
28. <name]]>dfs.namenode.secondary.http-address.hadoop-cluster1.nn1</name]]>
29. <value]]>master1:9001</value]]>
30. </property]]>
31. <property]]>
32. <name]]>dfs.namenode.secondary.http-address.hadoop-cluster1.nn2</name]]>
33. <value]]>masterha1:9001</value]]>
34. </property]]>
35. <property]]>
36. <name]]>dfs.client.failover.proxy.provider.hadoop-cluster1</name]]>
37. <value]]>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value]]>
38. </property]]>
39. <!--cluster1-->
40. <!--cluster2-->
41. <property]]>
42. <name]]>dfs.ha.namenodes.hadoop-cluster2</name]]>
43. <value]]>nn3,nn4</value]]>
44. </property]]>
45. <property]]>
46. <name]]>dfs.namenode.rpc-address.hadoop-cluster2.nn3</name]]>
47. <value]]>master2:9000</value]]>
48. </property]]>
49. <property]]>
50. <name]]>dfs.namenode.rpc-address.hadoop-cluster2.nn4</name]]>
51. <value]]>masterha2:9000</value]]>
52. </property]]>
53. <property]]>
54. <name]]>dfs.namenode.http-address.hadoop-cluster2.nn3</name]]>
55. <value]]>master2:50070</value]]>
56. </property]]>
57. <property]]>
58. <name]]>dfs.namenode.http-address.hadoop-cluster2.nn4</name]]>
59. <value]]>masterha2:50070</value]]>
60. </property]]>
61. <property]]>
62. <name]]>dfs.namenode.secondary.http-address.hadoop-cluster2.nn3</name]]>
63. <value]]>master2:9001</value]]>
64. </property]]>
65. <property]]>
66. <name]]>dfs.namenode.secondary.http-address.hadoop-cluster2.nn4</name]]>
67. <value]]>masterha2:9001</value]]>
68. </property]]>
69. <property]]>
70. <name]]>dfs.client.failover.proxy.provider.hadoop-cluster2</name]]>
71. <value]]>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value]]>
72. </property]]>
73. <!--cluster2-->
74. <property]]>
75. <name]]>dfs.namenode.name.dir</name]]>
76. <value]]>/home/hadoop/namedir</value]]>
77. </property]]>
78. <property]]>
79. <name]]>dfs.namenode.shared.edits.dir.hadoop-cluster1.nn1</name]]>
80. <value]]>qjournal://masterha1:8485;master2:8485;masterha2:8485/cluster1</value>
81. </property]]>
82. <property]]>
83. <name]]>dfs.namenode.shared.edits.dir.hadoop-cluster1.nn2</name]]>
84. <value]]>qjournal://masterha1:8485;master2:8485;masterha2:8485/cluster1</value>
85. </property]]>
86. <property]]>
87. <name]]>dfs.namenode.shared.edits.dir.hadoop-cluster2.nn3</name]]>
88. <value]]>qjournal://masterha1:8485;master2:8485;masterha2:8485/cluster2</value>
89. </property]]>
90. <property]]>
91. <name]]>dfs.namenode.shared.edits.dir.hadoop-cluster2.nn4</name]]>
92. <value]]>qjournal://masterha1:8485;master2:8485;masterha2:8485/cluster2</value>
93. </property]]>
94. <property]]>
95. <name]]>dfs.datanode.data.dir</name]]>
96. <value]]>/home/hadoop/datadir</value]]>
97. </property]]>
98. <property]]>
99. <name]]>ha.zookeeper.quorum</name]]>
100. <value]]>masterha1:2181,master2:2181,masterha2:2181,</value]]>
101. </property]]>
102. <property]]>
103. <name]]>dfs.ha.fencing.methods</name]]>
104. <value]]>sshfence</value]]>
105. </property]]>
106. <property]]>
107. <name]]>ha.zookeeper.session-timeout.ms</name]]>
108. <value]]>5000</value]]>
109. </property]]>
110. <property]]>
111. <name]]>dfs.ha.automatic-failover.enabled</name]]>
112. <value]]>false</value]]>
113. </property]]>
114. <property]]>
115. <name]]>dfs.journalnode.edits.dir</name]]>
116. <value]]>/home/hadoop/jndir</value]]>
117. </property]]>
118. <property]]>
119. <name]]>dfs.replication</name]]>
120. <value]]>2</value]]>
121. </property]]>
122. <property]]>
123. <name]]>dfs.permission</name]]>
124. <value]]>false</value]]>
125. </property]]>
126. <property]]>
127. <name]]>dfs.webhdfs.enabled</name]]>
128. <value]]>true</value]]>
129. </property]]>
130. <property]]>
131. <name]]>dfs.support.append</name]]>
132. <value]]>true</value]]>
133. </property]]>
134. <property]]>
135. <name]]>hadoop.tmp.dir</name]]>
136. <value]]>/home/hadoop/temp</value]]>
137. </property]]>
138. <property]]>
139. <name]]>hadoop.proxyuser.hduser.hosts</name]]>
140. <value>*</value]]>
141. </property]]>
142. <property]]>
143. <name]]>hadoop.proxyuser.hduser.groups</name]]>
144. <value>*</value]]>
145. </property]]>
146. <property]]>
147. <name]]>dfs.ha.fencing.methods</name]]>
148. <value]]>sshfence</value]]>
149. </property]]>
150. <property]]>
151. <name]]>dfs.ha.fencing.ssh.private-key-files</name]]>
152. <value]]>/home/hadoop/.ssh/id_rsa</value]]>
153. </property]]>
154. </configuration]]>
155. 开启mr配置:
 
1. #cp mapred-site.xml.template mapred-site.xml
2. 修改mapred-site.xml
 
1. <configuration]]>
2. <property]]>
3. <name]]>mapreduce.framework.name</name]]>
4. <value]]>yarn</value]]>
5. </property]]>
6. <property]]>
7. <name]]>mapreduce.job.tracker</name]]>
8. <value]]>master1:54311</value]]>
9. </property]]>
10. <property]]>
11. <name]]>mapreduce.jobhistory.address</name]]>
12. <value]]>master1:10020</value]]>
13. </property]]>
14. <property]]>
15. <name]]>mapreduce.jobhistory.webapp.address</name]]>
16. <value]]>master1:19888</value]]>
17. </property]]>
18. <property]]>
19. <name]]>mapred.system.dir</name]]>
20. <value]]>/home/hadoop/hadoopmrsys</value]]>
21. <final]]>true</final]]>
22. </property]]>
23. <property]]>
24. <name]]>mapred.local.dir</name]]>
25. <value]]>/home/hadoop/hadoopmrlocal</value]]>
26. <final]]>true</final]]>
27. </property]]>
28. </configuration]]>
29. 修改yarn-site.xml
1. <configuration]]>
2. <property]]>
3. <name]]>yarn.nodemanager.aux-services</name]]>
4. <value]]>mapreduce_shuffle</value]]>
5. </property]]>
6. <property]]>
7. <name]]>yarn.nodemanager.aux-services.mapreduce.shuffle.class</name]]>
8. <value]]>org.apache.hadoop.mapred.ShuffleHandler</value]]>
9. </property]]>
10. <property]]>
11. <name]]>yarn.nodemanager.local-dirs</name]]>
12. <value]]>/home/hadoop/nodemanagerlocal</value]]>
13. </property]]>
14. <property]]>
15. <name]]>yarn.nodemanager.log-dirs</name]]>
16. <value]]>/home/hadoop/nodemanagerlogs</value]]>
17. </property]]>
18. <property]]>
19. <name]]>yarn.nodemanager.remote-app-log-dir</name]]>
20. <value]]>/home/hadoop/nodemanagerremote</value]]>     
21. </property]]>
22. <property]]>
23. <name]]>yarn.resourcemanager.address</name]]>
24. <value]]>master1:18032</value]]>
25. </property]]>
26. <property]]>
27. <name]]>yarn.resourcemanager.scheduler.address</name]]>
28. <value]]>master1:18030</value]]>
29. </property]]>
30. <property]]>
31. <name]]>yarn.resourcemanager.resource-tracker.address</name]]>
32. <value]]>master1:18031</value]]>
33. </property]]>
34. <property]]>
35. <name]]>yarn.resourcemanager.admin.address</name]]>
36. <value]]>master1:18033</value]]>
37. </property]]>
38. <property]]>
39. <name]]>yarn.resourcemanager.webapp.address</name]]>
40. <value]]>master1:18088</value]]>
41. </property]]>
42. </configuration]]>
43. 修改slaves
 
1. slave1
2. slave2
3. slave3
4. 修改hadoop-env.sh
 
1. export JAVA_HOME=xxx
2. 修改yarn-env.sh
 
1. export JAVA_HOME=xxx
2. 最后将配置好的hadoop分发到其余服务器上。


3.2.2. Hadoop2启动HDFS

    1. 启动masterha1、master2、masterha2节点上的zookeeper
    2. 在master1和master2节点上执行:
     
    1. #./bin/hdfs zkfc –formatZK
    2. 在masterha1、master2、masterha2节点上执行:
     
    1. #sbin/hadoop-daemons.sh start journalnode
    2. 在master1节点上执行:
     
    1. #bin/hdfs namenode -format –clusterId hadoop-cluster-new
    2. #scp -r namedir hadoop@masterha1:~
    3. #sbin/hadoop-daemon.sh start namenode
    4. 在masterha1节点上执行:
     
    1. #bin/hdfs namenode -bootstrapStandby
    2. #sbin/hadoop-daemon.sh start namenode
    3. 在master1,masterha1节点上执行:(将master1置成active状态)
     
    1. #./sbin/hadoop-daemon.sh start zkfc
    2. 在master2节点上执行:
     
    1. #bin/hdfs namenode -format –clusterId hadoop-cluster-new
    2. #scp -r namedir hadoop@masterha2:~
    3. #sbin/hadoop-daemon.sh start namenode
    4. 在masterha2节点上执行:
     
    1. #bin/hdfs namenode -bootstrapStandby
    2. #sbin/hadoop-daemon.sh start namenode
    3. 在master2,masterha2节点上执行:
     
    1. #./sbin/hadoop-daemon.sh start zkfc
    2. 在slave1、slave2、slave3节点上执行:(启动datanode)
     
    1. #sbin/hadoop-daemons.sh start datanode
    2. 验证hdfs:
    http://master1:50070
    hadoop shell命令验证
     
    1. #hadoop fs -mkdir hdfs://hadoop-cluster1/tmp
    2. #hadoop fs -mkdir hdfs://hadoop-cluster2/tmp2
    3. #hadoop fs -ls /
    hadoop shell命令验证
    注意操作的时候需要这样写了:
    hadoop fs -mkdir hdfs://hadoop-cluster1/aaa
    hadoop fs -ls hdfs://hadoop-cluster1



    3.2.3. Hadoop2启动MR和YARN

    1. 在master1节点上执行:
    1. #start-yarn.sh
    2. 验证yarn:
    http://master1:18088
    作业提交验证
     
    1. #hadoop jar hadoop-mapreduce-examples-2.2.0.jar randomwriter hdfs://hadoop-cluster1/output
    1. dir


    3.2.4. Hadoop2关闭服务

    1. 在master1节点上执行:
    1. #stop-yarn.sh
    2. 在slave1、slave2、slave3节点上执行:
     
    1. #sbin/hadoop-daemons.sh stop datanode
    2. 在master1,masterha1,master2,masterha2上执行:
     
    1. #sbin/hadoop-daemons.sh stop namenode
    2. 在masterha1,master2,masterha2上执行:
     
    1. #sbin/hadoop-daemons.sh stop journalnode
    2. 在master1,master2上执行:
     
    1. #sbin/hadoop-daemons.sh stop zkfc
    2. 在masterha1,master2,masterha2上执行:
     
    1. #zkServer.sh stop