随笔-294  评论-207  文章-0  trackbacks-0
  2017年5月18日

可参照:http://www.voidcn.com/blog/Vindra/article/p-4917667.html

一、get请求 

curl "http://www.baidu.com"  如果这里的URL指向的是一个文件或者一幅图都可以直接下载到本地

curl -i "http://www.baidu.com"  显示全部信息

curl -l "http://www.baidu.com" 只显示头部信息

curl -v "http://www.baidu.com" 显示get请求全过程解析

 

wget "http://www.baidu.com"也可以

 

二、post请求

curl -d "param1=value1&param2=value2" "http://www.baidu.com"

 

三、json格式的post请求

curl -l -H "Content-type: application/json" -X POST -d '{"phone":"13521389587","password":"test"}' http://domain/apis/users.json

例如:

curl -l -H "Content-type: application/json" -X POST -d '{"ver": "1.0","soa":{"req":"123"},"iface":"me.ele.lpdinfra.prediction.service.PredictionService","method":"restaurant_make_order_time","args":{"arg2":"\"stable\"","arg1":"{\"code\":[\"WIND\"],\"temperature\":11.11}","arg0":"{\"tracking_id\":\"100000000331770936\",\"eleme_order_id\":\"100000000331770936\",\"platform_id\":\"4\",\"restaurant_id\":\"482571\",\"dish_num\":1,\"dish_info\":[{\"entity_id\":142547763,\"quantity\":1,\"category_id\":1,\"dish_name\":\"[0xe7][0x89][0xb9][0xe4][0xbb][0xb7][0xe8][0x85][0x8a][0xe5][0x91][0xb3][0xe5][0x8f][0x89][0xe7][0x83][0xa7][0xe5][0x8f][0x8c][0xe6][0x8b][0xbc][0xe7][0x85][0xb2][0xe4][0xbb][0x94][0xe9][0xa5][0xad]\",\"price\":31.0}],\"merchant_location\":{\"longitude\":\"121.47831425\",\"latitude\":\"31.27576153\"},\"customer_location\":{\"longitude\":\"121.47831425\",\"latitude\":\"31.27576153\"},\"created_at\":1477896550,\"confirmed_at\":1477896550,\"dishes_total_price\":0.0,\"food_boxes_total_price\":2.0,\"delivery_total_price\":2.0,\"pay_amount\":35.0,\"city_id\":\"1\"}"}}' http://vpcb-lpdinfra-stream-1.vm.elenet.me:8989/rpc

ps:json串内层参数需要格式化

posted @ 2017-05-18 11:28 xzc 阅读(39) | 评论 (1)编辑 收藏
  2017年5月17日
服务器上的一些统计数据:

1)统计80端口连接数
netstat -nat|grep -i "80"|wc -l

2)统计httpd协议连接数
ps -ef|grep httpd|wc -l

3)、统计已连接上的,状态为“established
netstat -na|grep ESTABLISHED|wc -l

4)、查出哪个IP地址连接最多,将其封了.
netstat -na|grep ESTABLISHED|awk {print $5}|awk -F: {print $1}|sort|uniq -c|sort -r +0n

netstat -na|grep SYN|awk {print $5}|awk -F: {print $1}|sort|uniq -c|sort -r +0n

---------------------------------------------------------------------------------------------

1、查看apache当前并发访问数:
netstat -an | grep ESTABLISHED | wc -l

对比httpd.conf中MaxClients的数字差距多少。

2、查看有多少个进程数:
ps aux|grep httpd|wc -l

3、可以使用如下参数查看数据
server-status?auto

#ps -ef|grep httpd|wc -l
1388
统计httpd进程数,连个请求会启动一个进程,使用于Apache服务器。
表示Apache能够处理1388个并发请求,这个值Apache可根据负载情况自动调整。

#netstat -nat|grep -i "80"|wc -l
4341
netstat -an会打印系统当前网络链接状态,而grep -i "80"是用来提取与80端口有关的连接的,wc -l进行连接数统计。
最终返回的数字就是当前所有80端口的请求总数。

#netstat -na|grep ESTABLISHED|wc -l
376
netstat -an会打印系统当前网络链接状态,而grep ESTABLISHED 提取出已建立连接的信息。 然后wc -l统计。
最终返回的数字就是当前所有80端口的已建立连接的总数。

netstat -nat||grep ESTABLISHED|wc - 可查看所有建立连接的详细记录

查看Apache的并发请求数及其TCP连接状态:
Linux命令:
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

返回结果示例:
LAST_ACK 5
SYN_RECV 30
ESTABLISHED 1597
FIN_WAIT1 51
FIN_WAIT2 504
TIME_WAIT 1057
其中的
SYN_RECV表示正在等待处理的请求数;
ESTABLISHED表示正常数据传输状态;
TIME_WAIT表示处理完毕,等待超时结束的请求数。

---------------------------------------------------------------------------------------------

查看httpd进程数(即prefork模式下Apache能够处理的并发请求数):
Linux命令:
     ps -ef | grep httpd | wc -l

查看Apache的并发请求数及其TCP连接状态:

Linux命令:
     netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
返回结果示例:
LAST_ACK 5
SYN_RECV 30
ESTABLISHED 1597
FIN_WAIT1 51
FIN_WAIT2 504
TIME_WAIT 1057

说明:
   SYN_RECV表示正在等待处理的请求数;
   ESTABLISHED表示正常数据传输状态;
   TIME_WAIT表示处理完毕,等待超时结束的请求数。
posted @ 2017-05-17 23:12 xzc 阅读(46) | 评论 (2)编辑 收藏
  2017年5月12日

一、回收站简介:

    在HDFS里,删除文件时,不会真正的删除,其实是放入回收站/trash,回收站里的文件可以快速恢复。

    可以设置一个时间阀值,当回收站里文件的存放时间超过这个阀值或是回收站被清空时,文件才会被彻底删除,并且释放占用的数据块。

二、实例:

    Hadoop的回收站trash功能默认是关闭的,所以需要在core-site.xml中手动开启。

1、修改core-site.xml,增加:

复制代码
<property>  <name>fs.trash.interval</name>  <value>1440</value>  <description>Number of minutes between trash checkpoints.  If zero, the trash feature is disabled.  </description>  </property>
复制代码

默认是0,单位是分钟,这里设置为1天。
删除数据rm后,会将数据move到当前文件夹下的.Trash目录。

2、测试

1)、新建目录input

hadoop/bin/hadoop fs -mkdir input

2)、上传文件

root@master:/data/soft# hadoop/bin/hadoop fs -copyFromLocal /data/soft/file0* input

3)、删除目录input

[root@master data]# hadoop fs -rmr input  Moved to trash: hdfs://master:9000/user/root/input

4)、查看当前目录

[root@master data]# hadoop fs -ls  Found 2 items  drwxr-xr-x - root supergroup 0 2011-02-12 22:17 /user/root/.Trash

发现input删除了,多了一个目录.Trash
5)、恢复刚刚删除的目录

[root@master data]# hadoop fs -mv /user/root/.Trash/Current/user/root/input /user/root/input

6)、查看恢复的数据

[root@master data]# hadoop fs -ls input  Found 2 items  -rw-r--r-- 3 root supergroup 22 2011-02-12 17:40 /user/root/input/file01  -rw-r--r-- 3 root supergroup 28 2011-02-12 17:40 /user/root/input/file02

7)、删除.Trash目录(清理垃圾)

[root@master data]# hadoop fs -rmr .Trash  Deleted hdfs://master:9000/user/root/.Trash
posted @ 2017-05-12 11:20 xzc 阅读(39) | 评论 (0)编辑 收藏
  2017年5月10日
     摘要:  以前用redis用的很多,各种数据类型用的飞起,算是用得很溜了。不过那都是封装好的方法,自己直接调用。以前的公司比较规范,开发只是开发,很少去做跟运维相关的事情。             换了一份工作,不过这边项目刚开始起步,各种东西还不是很全,需要从头做起。运维什么的都是自己来。这下要考虑的东西就多了。比如说re...  阅读全文
posted @ 2017-05-10 10:49 xzc 阅读(65) | 评论 (0)编辑 收藏
  2017年4月28日
转自:http://www.cnblogs.com/cyfonly/p/5954614.html

一、为什么需要消息系统

复制代码
1.解耦:   允许你独立的扩展或修改两边的处理过程,只要确保它们遵守同样的接口约束。 2.冗余:   消息队列把数据进行持久化直到它们已经被完全处理,通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中,在把一个消息从队列中删除之前,需要你的处理系统明确的指出该消息已经被处理完毕,从而确保你的数据被安全的保存直到你使用完毕。 3.扩展性:   因为消息队列解耦了你的处理过程,所以增大消息入队和处理的频率是很容易的,只要另外增加处理过程即可。 4.灵活性 & 峰值处理能力:   在访问量剧增的情况下,应用仍然需要继续发挥作用,但是这样的突发流量并不常见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力,而不会因为突发的超负荷的请求而完全崩溃。 5.可恢复性:   系统的一部分组件失效时,不会影响到整个系统。消息队列降低了进程间的耦合度,所以即使一个处理消息的进程挂掉,加入队列中的消息仍然可以在系统恢复后被处理。 6.顺序保证:   在大多使用场景下,数据处理的顺序都很重要。大部分消息队列本来就是排序的,并且能保证数据会按照特定的顺序来处理。(Kafka 保证一个 Partition 内的消息的有序性) 7.缓冲:   有助于控制和优化数据流经过系统的速度,解决生产消息和消费消息的处理速度不一致的情况。 8.异步通信:   很多时候,用户不想也不需要立即处理消息。消息队列提供了异步处理机制,允许用户把一个消息放入队列,但并不立即处理它。想向队列中放入多少消息就放多少,然后在需要的时候再去处理它们。
复制代码

 

二、kafka 架构

2.1 拓扑结构

如下图:

图.1

2.2 相关概念

如图.1中,kafka 相关名词解释如下:

复制代码
1.producer:   消息生产者,发布消息到 kafka 集群的终端或服务。 2.broker:   kafka 集群中包含的服务器。 3.topic:   每条发布到 kafka 集群的消息属于的类别,即 kafka 是面向 topic 的。 4.partition:   partition 是物理上的概念,每个 topic 包含一个或多个 partition。kafka 分配的单位是 partition。 5.consumer:   从 kafka 集群中消费消息的终端或服务。 6.Consumer group:   high-level consumer API 中,每个 consumer 都属于一个 consumer group,每条消息只能被 consumer group 中的一个 Consumer 消费,但可以被多个 consumer group 消费。 7.replica:   partition 的副本,保障 partition 的高可用。 8.leader:   replica 中的一个角色, producer 和 consumer 只跟 leader 交互。 9.follower:   replica 中的一个角色,从 leader 中复制数据。 10.controller:   kafka 集群中的其中一个服务器,用来进行 leader election 以及 各种 failover。 12.zookeeper:   kafka 通过 zookeeper 来存储集群的 meta 信息。
复制代码

2.3 zookeeper 节点

kafka 在 zookeeper 中的存储结构如下图所示:

 

图.2

 

三、producer 发布消息

3.1 写入方式

producer 采用 push 模式将消息发布到 broker,每条消息都被 append 到 patition 中,属于顺序写磁盘(顺序写磁盘效率比随机写内存要高,保障 kafka 吞吐率)。

3.2 消息路由

producer 发送消息到 broker 时,会根据分区算法选择将其存储到哪一个 partition。其路由机制为:

1. 指定了 patition,则直接使用; 2. 未指定 patition 但指定 key,通过对 key 的 value 进行hash 选出一个 patition 3. patition 和 key 都未指定,使用轮询选出一个 patition。

 附上 java 客户端分区源码,一目了然:

复制代码
//创建消息实例 public ProducerRecord(String topic, Integer partition, Long timestamp, K key, V value) {      if (topic == null)           throw new IllegalArgumentException("Topic cannot be null");      if (timestamp != null && timestamp < 0)           throw new IllegalArgumentException("Invalid timestamp " + timestamp);      this.topic = topic;      this.partition = partition;      this.key = key;      this.value = value;      this.timestamp = timestamp; }  //计算 patition,如果指定了 patition 则直接使用,否则使用 key 计算 private int partition(ProducerRecord<K, V> record, byte[] serializedKey , byte[] serializedValue, Cluster cluster) {      Integer partition = record.partition();      if (partition != null) {           List<PartitionInfo> partitions = cluster.partitionsForTopic(record.topic());           int lastPartition = partitions.size() - 1;           if (partition < 0 || partition > lastPartition) {                throw new IllegalArgumentException(String.format("Invalid partition given with record: %d is not in the range [0...%d].", partition, lastPartition));           }           return partition;      }      return this.partitioner.partition(record.topic(), record.key(), serializedKey, record.value(), serializedValue, cluster); }  // 使用 key 选取 patition public int partition(String topic, Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster) {      List<PartitionInfo> partitions = cluster.partitionsForTopic(topic);      int numPartitions = partitions.size();      if (keyBytes == null) {           int nextValue = counter.getAndIncrement();           List<PartitionInfo> availablePartitions = cluster.availablePartitionsForTopic(topic);           if (availablePartitions.size() > 0) {                int part = DefaultPartitioner.toPositive(nextValue) % availablePartitions.size();                return availablePartitions.get(part).partition();           } else {                return DefaultPartitioner.toPositive(nextValue) % numPartitions;           }      } else {           //对 keyBytes 进行 hash 选出一个 patition           return DefaultPartitioner.toPositive(Utils.murmur2(keyBytes)) % numPartitions;      } }
复制代码

3.3 写入流程

 producer 写入消息序列图如下所示:

图.3

流程说明:

复制代码
1. producer 先从 zookeeper 的 "/brokers/.../state" 节点找到该 partition 的 leader 2. producer 将消息发送给该 leader 3. leader 将消息写入本地 log 4. followers 从 leader pull 消息,写入本地 log 后 leader 发送 ACK 5. leader 收到所有 ISR 中的 replica 的 ACK 后,增加 HW(high watermark,最后 commit 的 offset) 并向 producer 发送 ACK
复制代码

3.4 producer delivery guarantee

 一般情况下存在三种情况:

1. At most once 消息可能会丢,但绝不会重复传输 2. At least one 消息绝不会丢,但可能会重复传输 3. Exactly once 每条消息肯定会被传输一次且仅传输一次

当 producer 向 broker 发送消息时,一旦这条消息被 commit,由于 replication 的存在,它就不会丢。但是如果 producer 发送数据给 broker 后,遇到网络问题而造成通信中断,那 Producer 就无法判断该条消息是否已经 commit。虽然 Kafka 无法确定网络故障期间发生了什么,但是 producer 可以生成一种类似于主键的东西,发生故障时幂等性的重试多次,这样就做到了 Exactly once,但目前还并未实现。所以目前默认情况下一条消息从 producer 到 broker 是确保了 At least once,可通过设置 producer 异步发送实现At most once。

 

四、broker 保存消息

4.1 存储方式

物理上把 topic 分成一个或多个 patition(对应 server.properties 中的 num.partitions=3 配置),每个 patition 物理上对应一个文件夹(该文件夹存储该 patition 的所有消息和索引文件),如下:

 

图.4

4.2 存储策略

无论消息是否被消费,kafka 都会保留所有消息。有两种策略可以删除旧数据:

1. 基于时间:log.retention.hours=168 2. 基于大小:log.retention.bytes=1073741824

需要注意的是,因为Kafka读取特定消息的时间复杂度为O(1),即与文件大小无关,所以这里删除过期文件与提高 Kafka 性能无关。

4.3 topic 创建与删除

4.3.1 创建 topic

创建 topic 的序列图如下所示:

图.5

流程说明:

复制代码
1. controller 在 ZooKeeper 的 /brokers/topics 节点上注册 watcher,当 topic 被创建,则 controller 会通过 watch 得到该 topic 的 partition/replica 分配。 2. controller从 /brokers/ids 读取当前所有可用的 broker 列表,对于 set_p 中的每一个 partition: 	2.1 从分配给该 partition 的所有 replica(称为AR)中任选一个可用的 broker 作为新的 leader,并将AR设置为新的 ISR 	2.2 将新的 leader 和 ISR 写入 /brokers/topics/[topic]/partitions/[partition]/state 3. controller 通过 RPC 向相关的 broker 发送 LeaderAndISRRequest。
复制代码

4.3.2 删除 topic

删除 topic 的序列图如下所示:

图.6

流程说明:

1. controller 在 zooKeeper 的 /brokers/topics 节点上注册 watcher,当 topic 被删除,则 controller 会通过 watch 得到该 topic 的 partition/replica 分配。 2. 若 delete.topic.enable=false,结束;否则 controller 注册在 /admin/delete_topics 上的 watch 被 fire,controller 通过回调向对应的 broker 发送 StopReplicaRequest。

 

五、kafka HA

5.1 replication

如图.1所示,同一个 partition 可能会有多个 replica(对应 server.properties 配置中的 default.replication.factor=N)。没有 replica 的情况下,一旦 broker 宕机,其上所有 patition 的数据都不可被消费,同时 producer 也不能再将数据存于其上的 patition。引入replication 之后,同一个 partition 可能会有多个 replica,而这时需要在这些 replica 之间选出一个 leader,producer 和 consumer 只与这个 leader 交互,其它 replica 作为 follower 从 leader 中复制数据。

Kafka 分配 Replica 的算法如下:

1. 将所有 broker(假设共 n 个 broker)和待分配的 partition 排序 2. 将第 i 个 partition 分配到第(i mod n)个 broker 上 3. 将第 i 个 partition 的第 j 个 replica 分配到第((i + j) mode n)个 broker上

5.2 leader failover

当 partition 对应的 leader 宕机时,需要从 follower 中选举出新 leader。在选举新leader时,一个基本的原则是,新的 leader 必须拥有旧 leader commit 过的所有消息。

kafka 在 zookeeper 中(/brokers/.../state)动态维护了一个 ISR(in-sync replicas),由3.3节的写入流程可知 ISR 里面的所有 replica 都跟上了 leader,只有 ISR 里面的成员才能选为 leader。对于 f+1 个 replica,一个 partition 可以在容忍 f 个 replica 失效的情况下保证消息不丢失。

当所有 replica 都不工作时,有两种可行的方案:

1. 等待 ISR 中的任一个 replica 活过来,并选它作为 leader。可保障数据不丢失,但时间可能相对较长。 2. 选择第一个活过来的 replica(不一定是 ISR 成员)作为 leader。无法保障数据不丢失,但相对不可用时间较短。

kafka 0.8.* 使用第二种方式。

kafka 通过 Controller 来选举 leader,流程请参考5.3节。

5.3 broker failover

kafka broker failover 序列图如下所示:

图.7

流程说明: 

复制代码
1. controller 在 zookeeper 的 /brokers/ids/[brokerId] 节点注册 Watcher,当 broker 宕机时 zookeeper 会 fire watch 2. controller 从 /brokers/ids 节点读取可用broker 3. controller决定set_p,该集合包含宕机 broker 上的所有 partition 4. 对 set_p 中的每一个 partition     4.1 从/brokers/topics/[topic]/partitions/[partition]/state 节点读取 ISR     4.2 决定新 leader(如4.3节所描述)     4.3 将新 leader、ISR、controller_epoch 和 leader_epoch 等信息写入 state 节点 5. 通过 RPC 向相关 broker 发送 leaderAndISRRequest 命令
复制代码

5.4 controller failover

 当 controller 宕机时会触发 controller failover。每个 broker 都会在 zookeeper 的 "/controller" 节点注册 watcher,当 controller 宕机时 zookeeper 中的临时节点消失,所有存活的 broker 收到 fire 的通知,每个 broker 都尝试创建新的 controller path,只有一个竞选成功并当选为 controller。

当新的 controller 当选时,会触发 KafkaController.onControllerFailover 方法,在该方法中完成如下操作:

复制代码
1. 读取并增加 Controller Epoch。 2. 在 reassignedPartitions Patch(/admin/reassign_partitions) 上注册 watcher。 3. 在 preferredReplicaElection Path(/admin/preferred_replica_election) 上注册 watcher。 4. 通过 partitionStateMachine 在 broker Topics Patch(/brokers/topics) 上注册 watcher。 5. 若 delete.topic.enable=true(默认值是 false),则 partitionStateMachine 在 Delete Topic Patch(/admin/delete_topics) 上注册 watcher。 6. 通过 replicaStateMachine在 Broker Ids Patch(/brokers/ids)上注册Watch。 7. 初始化 ControllerContext 对象,设置当前所有 topic,“活”着的 broker 列表,所有 partition 的 leader 及 ISR等。 8. 启动 replicaStateMachine 和 partitionStateMachine。 9. 将 brokerState 状态设置为 RunningAsController。 10. 将每个 partition 的 Leadership 信息发送给所有“活”着的 broker。 11. 若 auto.leader.rebalance.enable=true(默认值是true),则启动 partition-rebalance 线程。 12. 若 delete.topic.enable=true 且Delete Topic Patch(/admin/delete_topics)中有值,则删除相应的Topic。
复制代码

 

6. consumer 消费消息

6.1 consumer API

kafka 提供了两套 consumer API:

1. The high-level Consumer API 2. The SimpleConsumer API

 其中 high-level consumer API 提供了一个从 kafka 消费数据的高层抽象,而 SimpleConsumer API 则需要开发人员更多地关注细节。

6.1.1 The high-level consumer API

high-level consumer API 提供了 consumer group 的语义,一个消息只能被 group 内的一个 consumer 所消费,且 consumer 消费消息时不关注 offset,最后一个 offset 由 zookeeper 保存。

使用 high-level consumer API 可以是多线程的应用,应当注意:

1. 如果消费线程大于 patition 数量,则有些线程将收不到消息 2. 如果 patition 数量大于线程数,则有些线程多收到多个 patition 的消息 3. 如果一个线程消费多个 patition,则无法保证你收到的消息的顺序,而一个 patition 内的消息是有序的

6.1.2 The SimpleConsumer API

如果你想要对 patition 有更多的控制权,那就应该使用 SimpleConsumer API,比如:

1. 多次读取一个消息 2. 只消费一个 patition 中的部分消息 3. 使用事务来保证一个消息仅被消费一次

 但是使用此 API 时,partition、offset、broker、leader 等对你不再透明,需要自己去管理。你需要做大量的额外工作:

1. 必须在应用程序中跟踪 offset,从而确定下一条应该消费哪条消息 2. 应用程序需要通过程序获知每个 Partition 的 leader 是谁 3. 需要处理 leader 的变更

 使用 SimpleConsumer API 的一般流程如下:

复制代码
1. 查找到一个“活着”的 broker,并且找出每个 partition 的 leader 2. 找出每个 partition 的 follower 3. 定义好请求,该请求应该能描述应用程序需要哪些数据 4. fetch 数据 5. 识别 leader 的变化,并对之作出必要的响应
复制代码

以下针对 high-level Consumer API 进行说明。

6.2 consumer group

如 2.2 节所说, kafka 的分配单位是 patition。每个 consumer 都属于一个 group,一个 partition 只能被同一个 group 内的一个 consumer 所消费(也就保障了一个消息只能被 group 内的一个 consuemr 所消费),但是多个 group 可以同时消费这个 partition。

kafka 的设计目标之一就是同时实现离线处理和实时处理,根据这一特性,可以使用 spark/Storm 这些实时处理系统对消息在线处理,同时使用 Hadoop 批处理系统进行离线处理,还可以将数据备份到另一个数据中心,只需要保证这三者属于不同的 consumer group。如下图所示:

 

图.8

6.3 消费方式

consumer 采用 pull 模式从 broker 中读取数据。

push 模式很难适应消费速率不同的消费者,因为消息发送速率是由 broker 决定的。它的目标是尽可能以最快速度传递消息,但是这样很容易造成 consumer 来不及处理消息,典型的表现就是拒绝服务以及网络拥塞。而 pull 模式则可以根据 consumer 的消费能力以适当的速率消费消息。

对于 Kafka 而言,pull 模式更合适,它可简化 broker 的设计,consumer 可自主控制消费消息的速率,同时 consumer 可以自己控制消费方式——即可批量消费也可逐条消费,同时还能选择不同的提交方式从而实现不同的传输语义。

6.4 consumer delivery guarantee

如果将 consumer 设置为 autocommit,consumer 一旦读到数据立即自动 commit。如果只讨论这一读取消息的过程,那 Kafka 确保了 Exactly once。

但实际使用中应用程序并非在 consumer 读取完数据就结束了,而是要进行进一步处理,而数据处理与 commit 的顺序在很大程度上决定了consumer delivery guarantee:

复制代码
1.读完消息先 commit 再处理消息。     这种模式下,如果 consumer 在 commit 后还没来得及处理消息就 crash 了,下次重新开始工作后就无法读到刚刚已提交而未处理的消息,这就对应于 At most once 2.读完消息先处理再 commit。     这种模式下,如果在处理完消息之后 commit 之前 consumer crash 了,下次重新开始工作时还会处理刚刚未 commit 的消息,实际上该消息已经被处理过了。这就对应于 At least once。 3.如果一定要做到 Exactly once,就需要协调 offset 和实际操作的输出。     精典的做法是引入两阶段提交。如果能让 offset 和操作输入存在同一个地方,会更简洁和通用。这种方式可能更好,因为许多输出系统可能不支持两阶段提交。比如,consumer 拿到数据后可能把数据放到 HDFS,如果把最新的 offset 和数据本身一起写到 HDFS,那就可以保证数据的输出和 offset 的更新要么都完成,要么都不完成,间接实现 Exactly once。(目前就 high-level API而言,offset 是存于Zookeeper 中的,无法存于HDFS,而SimpleConsuemr API的 offset 是由自己去维护的,可以将之存于 HDFS 中)
复制代码

总之,Kafka 默认保证 At least once,并且允许通过设置 producer 异步提交来实现 At most once(见文章《kafka consumer防止数据丢失》)。而 Exactly once 要求与外部存储系统协作,幸运的是 kafka 提供的 offset 可以非常直接非常容易得使用这种方式。

更多关于 kafka 传输语义的信息请参考《Message Delivery Semantics》。

6.5 consumer rebalance

当有 consumer 加入或退出、以及 partition 的改变(如 broker 加入或退出)时会触发 rebalance。consumer rebalance算法如下:

复制代码
1. 将目标 topic 下的所有 partirtion 排序,存于PT 2. 对某 consumer group 下所有 consumer 排序,存于 CG,第 i 个consumer 记为 Ci 3. N=size(PT)/size(CG),向上取整 4. 解除 Ci 对原来分配的 partition 的消费权(i从0开始) 5. 将第i*N到(i+1)*N-1个 partition 分配给 Ci
复制代码

在 0.8.*版本,每个 consumer 都只负责调整自己所消费的 partition,为了保证整个consumer group 的一致性,当一个 consumer 触发了 rebalance 时,该 consumer group 内的其它所有其它 consumer 也应该同时触发 rebalance。这会导致以下几个问题:

复制代码
1.Herd effect   任何 broker 或者 consumer 的增减都会触发所有的 consumer 的 rebalance 2.Split Brain   每个 consumer 分别单独通过 zookeeper 判断哪些 broker 和 consumer 宕机了,那么不同 consumer 在同一时刻从 zookeeper 看到的 view 就可能不一样,这是由 zookeeper 的特性决定的,这就会造成不正确的 reblance 尝试。 3. 调整结果不可控   所有的 consumer 都并不知道其它 consumer 的 rebalance 是否成功,这可能会导致 kafka 工作在一个不正确的状态。
复制代码

基于以上问题,kafka 设计者考虑在0.9.*版本开始使用中心 coordinator 来控制 consumer rebalance,然后又从简便性和验证要求两方面考虑,计划在 consumer 客户端实现分配方案。(见文章《Kafka Detailed Consumer Coordinator Design》和《Kafka Client-side Assignment Proposal》),此处不再赘述。

 

七、注意事项

7.1 producer 无法发送消息的问题

最开始在本机搭建了kafka伪集群,本地 producer 客户端成功发布消息至 broker。随后在服务器上搭建了 kafka 集群,在本机连接该集群,producer 却无法发布消息到 broker(奇怪也没有抛错)。最开始怀疑是 iptables 没开放,于是开放端口,结果还不行(又开始是代码问题、版本问题等等,倒腾了很久)。最后没办法,一项一项查看 server.properties 配置,发现以下两个配置:

复制代码
# The address the socket server listens on. It will get the value returned from  # java.net.InetAddress.getCanonicalHostName() if not configured. #   FORMAT: #     listeners = security_protocol://host_name:port #   EXAMPLE: #     listeners = PLAINTEXT://your.host.name:9092 listeners=PLAINTEXT://:9092

 # Hostname and port the broker will advertise to producers and consumers. If not set, 
 # it uses the value for "listeners" if configured. Otherwise, it will use the value
 # returned from java.net.InetAddress.getCanonicalHostName().
 #advertised.listeners=PLAINTEXT://your.host.name:9092

复制代码

以上说的就是 advertised.listeners 是 broker 给 producer 和 consumer 连接使用的,如果没有设置,就使用 listeners,而如果 host_name 没有设置的话,就使用 java.net.InetAddress.getCanonicalHostName() 方法返回的主机名。

修改方法:

1. listeners=PLAINTEXT://121.10.26.XXX:9092 2. advertised.listeners=PLAINTEXT://121.10.26.XXX:9092

修改后重启服务,正常工作。关于更多 kafka 配置说明,见文章《Kafka学习整理三(borker(0.9.0及0.10.0)配置)》。

 

八、参考文章

1. 《Kafka剖析(一):Kafka背景及架构介绍

2. 《Kafka设计解析(二):Kafka High Availability (上)

3. 《Kafka设计解析(二):Kafka High Availability (下)

4. 《Kafka设计解析(四):Kafka Consumer解析

5. 《Kafka设计解析(五):Kafka Benchmark

6. 《Kafka学习整理三(borker(0.9.0及0.10.0)配置)

7. 《Using the High Level Consumer

8. 《Using SimpleConsumer

9. 《Consumer Client Re-Design

10. 《Message Delivery Semantics

11. 《Kafka Detailed Consumer Coordinator Design

12. 《Kafka Client-side Assignment Proposal

13. 《Kafka和DistributedLog技术对比

14. 《kafka安装和启动

15. 《kafka consumer防止数据丢失

  

 

作者:cyfonly
本文版权归作者和博客园共有,欢迎转载,未经同意须保留此段声明,且在文章页面明显位置给出原文连接。欢迎指正与交流。
posted @ 2017-04-28 10:37 xzc 阅读(42) | 评论 (0)编辑 收藏
  2017年4月25日

1.  Kerberos简介

1.1. 功能

  1. 一个安全认证协议

  2. 用tickets验证

  3. 避免本地保存密码和在互联网上传输密码

  4. 包含一个可信任的第三方

  5. 使用对称加密

  6. 客户端与服务器(非KDC)之间能够相互验证

Kerberos只提供一种功能——在网络上安全的完成用户的身份验证。它并不提供授权功能或者审计功能。

1.2. 概念

首次请求,三次通信方

  • the Authentication Server
  • the Ticket Granting Server
  • the Service or host machine that you’re wanting access to.

 

图 1‑1 角色

其他知识点

  • 每次通信,消息包含两部分,一部分可解码,一部分不可解码
  • 服务端不会直接有KDC通信
  • KDC保存所有机器的账户名和密码
  • KDC本身具有一个密码

2.  3次通信

 

  我们这里已获取服务器中的一张表(数据)的服务以为,为一个http服务。

2.1. 你和验证服务

  如果想要获取http服务,你首先要向KDC表名你自己的身份。这个过程可以在你的程序启动时进行。Kerberos可以通过kinit获取。介绍自己通过未加密的信息发送至KDC获取Ticket Granting Ticket (TGT)。

(1)信息包含

  • 你的用户名/ID
  • 你的IP地址
  • TGT的有效时间

  Authentication Server收到你的请求后,会去数据库中验证,你是否存在。注意,仅仅是验证是否存在,不会验证对错。

  如果存在,Authentication Server会产生一个随机的Session key(可以是一个64位的字符串)。这个key用于你和Ticket Granting Server (TGS)之间通信。

(2)回送信息

  Authentication Server同样会发送两部分信息给你,一部分信息为TGT,通过KDC自己的密码进行加密,包含:

  • 你的name/ID
  • TGS的name/ID
  • 时间戳
  • 你的IP地址
  • TGT的生命周期
  • TGS session key

另外一部分通过你的密码进行加密,包含的信息有

  • TGS的name/ID
  • 时间戳
  • 生命周期
  • TGS session key

 

图 2‑1 第一次通信

  如果你的密码是正确的,你就能解密第二部分信息,获取到TGS session key。如果,密码不正确,无法解密,则认证失败。第一部分信息TGT,你是无法解密的,但需要展示缓存起来。

2.2. 你和TGS

如果第一部分你已经成功,你已经拥有无法解密的TGT和一个TGS Session Key。

(1)    请求信息

 a)  通过TGS Session Key加密的认证器部分:

  • 你的name/ID
  • 时间戳

b)       明文传输部分:

  • 请求的Http服务名(就是请求信息)
  • HTTP Service的Ticket生命周期

c)        TGT部分

  Ticket Granting Server收到信息后,首先检查数据库中是否包含有你请求的Http服务名。如果无,直接返回错误信息。

  如果存在,则通过KDC的密码解密TGT,这个时候。我们就能获取到TGS Session key。然后,通过TGS Session key去解密你传输的第一部分认证器,获取到你的用户名和时间戳。

TGS再进行验证:

  1. 对比TGT中的用户名与认证器中的用户名
  2. 比较时间戳(网上有说认证器中的时间错和TGT中的时间错,个人觉得应该是认证器中的时间戳和系统的时间戳),不能超过一定范围
  3. 检查是否过期
  4. 检查IP地址是否一致
  5. 检查认证器是否已在TGS缓存中(避免应答攻击)
  6. 可以在这部分添加权限认证服务

  TGS随机产生一个Http Service Session Key, 同时准备Http Service Ticket(ST)。

(2)    回答信息

  a)        通过Http服务的密码进行加密的信息(ST):

  • 你的name/ID
  • Http服务name/ID
  • 你的IP地址
  • 时间戳
  • ST的生命周期
  • Http Service Session Key

  b)       通过TGS Session Key加密的信息

  • Http服务name/ID
  • 时间戳
  • ST的生命周期
  • Http Service Session Key

  你收到信息后,通过TGS Session Key解密,获取到了Http Service Session Key,但是你无法解密ST。

 

图 2‑2 第二次通信

2.3. 你和Http服务

  在前面两步成功后,以后每次获取Http服务,在Ticket没有过期,或者无更新的情况下,都可直接进行这一步。省略前面两个步骤。

(1)    请求信息

  a)        通过Http Service Session Key加密部分

  • 你的name/ID
  • 时间戳

  b)       ST

   Http服务端通过自己的密码解压ST(KDC是用Http服务的密码加密的),这样就能够获取到Http Service Session Key,解密第一部分。

服务端解密好ST后,进行检查

  1. 对比ST中的用户名(KDC给的)与认证器中的用户名
  2. 比较时间戳(网上有说认证器中的时间错和TGT中的时间错,个人觉得应该是认证器中的时间戳和系统的时间戳),不能超过一定范围
  3. 检查是否过期
  4. 检查IP地址是否一致
  5. 检查认证器是否已在HTTP服务端的缓存中(避免应答攻击)

(2)    应答信息

a)        通过Http Service Session Key加密的信息

  • Http服务name/ID
  • 时间戳

 

图 2‑3 第三次通信

  你在通过缓存的Http Service Session Key解密这部分信息,然后验证是否是你想要的服务器发送给你的信息。完成你的服务器的验证。

至此,整个过程全部完成。

posted @ 2017-04-25 15:56 xzc 阅读(34) | 评论 (2)编辑 收藏
  2017年4月14日
今有一小型项目,完全自主弄,原来以为很简单的NTP服务,我给折腾了2个多小时才整撑头(以前都是运维搞,没太注意,所以这技术的东西,在简单都需要亲尝啊),这里记录为以后别再浪费时间。 目标环境,5台linux centos 6.3, 一台作为NTPD服务与外部公共NTP服务同步时间,同时作为内网的NTPD服务器,其他机器与这台服务做时间同步。 服务器IP 角色 说明 同步方式 192.168.1.135 NTPD服务 1、负责与外部公共NTPD服务同步标准时间 2、作为内外网络的NTPD服务 NTPD服务平滑同步 192.168.1.xxx 内外NTP客户端 内网设备与192.168.1.135同步时间 NTPD服务平滑同步 …… 内外NTP客户端 内网设备与192.168.1.135同步时间 NTPD服务平滑同步 1、NTP时间同步方式选择 NTP同步方式在linux下一般两种:使用ntpdate命令直接同步和使用NTPD服务平滑同步。有什么区别呢,简单说下,免得时间长了,概念又模糊。 现有一台设备,系统时间是 13:00 , 真实的当前时间(在空中,也许卫星上,这里假设是在准备同步的上级目标NTP服务器)是: 12:30 。如果我们使用ntpdate同步(ntpdate -u 目标NTP服务器IP),操作系统的时间立即更新为12:30,假如,我们的系统有一个定时应用,是在每天12:40运行,那么实际今天这个的任务已经运行过了(当前时间是13:00嘛),现在被ntpdate修改为12:30,那么意味作10分钟后,又会执行一次任务,这就糟糕了,这个任务只能执行一次的嘛!!我想你(其实是我)已经懂了ntpdate时间同步的隐患,当然这个例子有些极端,但的确是有风险的,生产环境我不打算这么干,还是稳妥点好。所以解决该问题的办法就是时间平滑更改,不会让一个时间点在一天内经历两次,这就是NTPD服务方式平滑同步时间,它每次同步时间的偏移量不会太陡,是慢慢来的(问:怎么来,没有细究,只晓得一次一点的同步,完全同步好需要较长时间,所以一般开启NTPD服务同步前先用ntpdate先手动同步一次)。 2、安装配置 CentOS 6.3系统已经自带了NTPD服务,一般默认是按照了的,如果没有安装,先检查下,然后配置好yum仓库,yum方式安装下就OK,具体如下: # rpm -q ntp ntp-4.2.4p8-2.el6.x86_64 // 这表示已安装了,如果没有安装,这是空白。 如果没有安装,我们按照下 # yum install ntp ...... 按上面的安装方式在内网每台服务器上都安装好NTP软件包。 完成后,都需要配置NTP服务为自启动 # chkconfig ntpd on # chkconfig --list ntpd ntpd 0:关闭 1:关闭 2:启用 3:启用 4:启用 5:启用 6:关闭 在配置前,先使用ntpdate手动同步下时间,免得本机与外部时间服务器时间差距太大,让ntpd不能正常同步。 # ntpdate -u 202.112.10.36 22 Dec 16:52:38 ntpdate[6400]: adjust time server 202.112.10.36 offset 0.012135 sec 配置内网NTP-Server(192.168.1.135) 下面主要是配置内网的NPTD服务器(192.168.1.135), NTPD服务配置核心就在/etc/ntp.conf文件,配置好了就OK。网上特别是老外的文章都很简单,我上当了,妈哟,基础环境不一样,我们得中国特色才行。先上配置文件再说,红色部分是我的修改,其他的是默认。 # For more information about this file, see the man pages # ntp.conf(5), ntp_acc(5), ntp_auth(5), ntp_clock(5), ntp_misc(5), ntp_mon(5). driftfile /var/lib/ntp/drift # Permit time synchronization with our time source, but do not # permit the source to query or modify the service on this system. restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery # Permit all access over the loopback interface. This could # be tightened as well, but to do so would effect some of # the administrative functions. restrict 127.0.0.1 restrict -6 ::1 # Hosts on local network are less restricted. # 允许内网其他机器同步时间 restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap # Use public servers from the pool.ntp.org project. # Please consider joining the pool (http://www.pool.ntp.org/join.html). # 中国这边最活跃的时间服务器 : http://www.pool.ntp.org/zone/cn server 210.72.145.44 perfer # 中国国家受时中心 server 202.112.10.36 # 1.cn.pool.ntp.org server 59.124.196.83 # 0.asia.pool.ntp.org #broadcast 192.168.1.255 autokey # broadcast server #broadcastclient # broadcast client #broadcast 224.0.1.1 autokey # multicast server #multicastclient 224.0.1.1 # multicast client #manycastserver 239.255.254.254 # manycast server #manycastclient 239.255.254.254 autokey # manycast client # allow update time by the upper server # 允许上层时间服务器主动修改本机时间 restrict 210.72.145.44 nomodify notrap noquery restrict 202.112.10.36 nomodify notrap noquery restrict 59.124.196.83 nomodify notrap noquery # Undisciplined Local Clock. This is a fake driver intended for backup # and when no outside source of synchronized time is available. # 外部时间服务器不可用时,以本地时间作为时间服务 server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 10 # Enable public key cryptography. #crypto includefile /etc/ntp/crypto/pw # Key file containing the keys and key identifiers used when operating # with symmetric key cryptography. keys /etc/ntp/keys # Specify the key identifiers which are trusted. #trustedkey 4 8 42 # Specify the key identifier to use with the ntpdc utility. #requestkey 8 # Specify the key identifier to use with the ntpq utility. #controlkey 8 # Enable writing of statistics records. #statistics clockstats cryptostats loopstats peerstats 配置参数和命令简单说明请参考:http://linux.vbird.org/linux_server/0440ntp.php#server_ntp.conf 配置文件修改完成,保存退出,启动服务。 # service ntpd start ...... 启动后,一般需要5-10分钟左右的时候才能与外部时间服务器开始同步时间。可以通过命令查询NTPD服务情况。 查看服务连接和监听 # netstat -tlunp | grep ntp udp 0 0 192.168.1.135:123 0.0.0.0:* 23103/ntpd udp 0 0 127.0.0.1:123 0.0.0.0:* 23103/ntpd udp 0 0 0.0.0.0:123 0.0.0.0:* 23103/ntpd udp 0 0 fe80::6cae:8bff:fe3d:f65:123 :::* 23103/ntpd udp 0 0 fe80::6eae:8bff:fe3d:f65:123 :::* 23103/ntpd udp 0 0 ::1:123 :::* 23103/ntpd udp 0 0 :::123 :::* 23103/ntpd 看红色加粗的地方,表示连接和监听已正确,采用UDP方式 ntpq -p 查看网络中的NTP服务器,同时显示客户端和每个服务器的关系 # ntpq -p # ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== *202.112.10.36 202.112.10.60 2 u 277 128 314 201.553 9.193 17.068 +59.124.196.83 129.6.15.28 2 u 88 128 377 71.153 -25.111 14.004 LOCAL(0) .LOCL. 10 l 15 64 377 0.000 0.000 0.000 位置 标志 含义 符号 * 响应的NTP服务器和最精确的服务器 + 响应这个查询请求的NTP服务器 blank(空格) 没有响应的NTP服务器 标题 remote 响应这个请求的NTP服务器的名称 refid NTP服务器使用的更高一级服务器的名称 st 正在响应请求的NTP服务器的级别 when 上一次成功请求之后到现在的秒数 poll 本地和远程服务器多少时间进行一次同步,单位秒,在一开始运行NTP的时候这个poll值会比较小,服务器同步的频率大,可以尽快调整到正确的时间范围,之后poll值会逐渐增大,同步的频率也就会相应减小 reach 用来测试能否和服务器连接,是一个八进制值,每成功连接一次它的值就会增加 delay 从本地机发送同步要求到ntp服务器的往返时间 offset 主机通过NTP时钟同步与所同步时间源的时间偏移量,单位为毫秒,offset越接近于0,主机和ntp服务器的时间越接近 jitter 统计了在特定个连续的连接数里offset的分布情况。简单地说这个数值的绝对值越小,主机的时间就越精确 ntpstat 命令查看时间同步状态,这个一般需要5-10分钟后才能成功连接和同步。所以,服务器启动后需要稍等下。 刚启动的时候,一般是: # ntpstat unsynchronised time server re-starting polling server every 64 s 连接并同步后: synchronised to NTP server (202.112.10.36) at stratum 3 time correct to within 275 ms polling server every 256 s OK,内网的NTPD服务已经配置完成,如果所有正常后,开始配置内网的其他设备与这台服务器作为时间同步服务。 配置内网NTP-Clients 内网其他设备作为NTP的客户端配置,相对就比较简单,而且所有设备的配置都相同。 首先需要安装NTPD服务,然后配置为自启动(与NTP-Server完全一样)。然后找其中一台配置/etc/ntp.conf文件,配置完成验证通过后,拷贝到其他客户端机器,直接使用即可。 # yum install ntp ... # chkconfig ntp on # vim /etc/ntp.conf driftfile /var/lib/ntp/drift restrict 127.0.0.1 restrict -6 ::1 # 配置时间服务器为本地的时间服务器 server 192.168.1.135 restrict 192.168.1.135 nomodify notrap noquery server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 10 includefile /etc/ntp/crypto/pw keys /etc/ntp/keys 为了简单,这里只列出了配置项,注释全部清理了。 OK,保存退出,请求服务器前,请先使用ntpdate手动同步下时间 # ntpdate -u 192.168.0.135 22 Dec 17:09:57 ntpdate[6439]: adjust time server 192.168.1.135 offset 0.004882 sec 这里有可能出现同步失败,一般情况下原因都是本地的NTPD服务器还没有正常启动起来,一般需要几分钟时间后才能开始同步。 错误判断请参考后面的错误处理。 # service ntpd start .... 启动后,查看同步情况 # ntpq -p # ntpstat ..... 因为是内网,一般ntpstat很快就可以同步上,几分钟需要等下. OK,本机客户端配置完成后,使用SCP拷贝/etc/ntp.conf到其他需要同步的客户端机器,启动NTPD服务即可。 其他客户端机器上操作配置如下: # ntpdate -u 192.168.0.135 22 Dec 17:09:57 ntpdate[6439]: adjust time server 192.168.1.135 offset 0.004882 sec # scp 192.168.1.xxx:/etc/ntp.conf /etc/ntp.conf # service ntpd start 3、错误问题处理 用于收集安装,配置和应用中出现的问题 错误1:ntpdate -u ip -> no server suitable for synchronization found 判断:在ntp客户端用ntpdate –d serverIP查看,发现有“Server dropped: strata too high”的错误,并且显示“stratum 16”。而正常情况下stratum这个值得范围是“0~15”。 原因:NTP server还没有和其自身或者它的server同步上。在ntp server上重新启动ntp服务后,ntp server自身或者与其server的同步的需要一个时间段,这个过程可能是5分钟,在这个时间之内在客户端运行ntpdate命令时会产生no server suitable for synchronization found的错误。 处理:等待几分钟后,重试一般解决。 也可以使用命令 ntpq -p查看情况 参考:http://blog.csdn.net/weidan1121/article/details/3953021
posted @ 2017-04-14 11:25 xzc 阅读(40) | 评论 (2)编辑 收藏
  2017年4月13日
问题导读
1.CM的安装目录在什么位置?


2.hadoop配置文件在什么位置?


3.Cloudera manager运行所需要的信息存在什么位置?

4.CM结构和功能是什么?




1. 相关目录
  • /var/log/cloudera-scm-installer : 安装日志目录。
  • /var/log/* : 相关日志文件(相关服务的及CM的)。
  • /usr/share/cmf/ : 程序安装目录。
  • /usr/lib64/cmf/ : Agent程序代码。
  • /var/lib/cloudera-scm-server-db/data : 内嵌数据库目录。
  • /usr/bin/postgres : 内嵌数据库程序。
  • /etc/cloudera-scm-agent/ : agent的配置目录。
  • /etc/cloudera-scm-server/ : server的配置目录。
  • /opt/cloudera/parcels/ : Hadoop相关服务安装目录。
  • /opt/cloudera/parcel-repo/ : 下载的服务软件包数据,数据格式为parcels。
  • /opt/cloudera/parcel-cache/ : 下载的服务软件包缓存数据。
  • /etc/hadoop/* : 客户端配置文件目录。

2. 配置
  • Hadoop配置文件
    配置文件放置于/var/run/cloudera-scm-agent/process/目录下。如:/var/run/cloudera-scm-agent/process/193-hdfs-NAMENODE/core-site.xml。这些配置文件是通过Cloudera Manager启动相应服务(如HDFS)时生成的,内容从数据库中获得(即通过界面配置的参数)。
    在CM界面上更改配置是不会立即反映到配置文件中,这些信息会存储于数据库中,等下次重启服务时才会生成配置文件。且每次启动时都会产生新的配置文件。
    CM Server主要数据库为scm基中放置配置的数据表为configs。里面包含了服务的配置信息,每一次配置的更改会把当前页面的所有配置内容添加到数据库中,以此保存配置修改历史。
    scm数据库被配置成只能从localhost访问,如果需要从外部连接此数据库,修改vim /var/lib/cloudera-scm-server-db/data/pg_hba.conf文件,之后重启数据库。运行数据库的用户为cloudera-scm。


  • 查看配置内容

    • 直接查询scm数据库的configs数据表的内容。
    • 访问REST API: http://hostname:7180/api/v4/cm/deployment,返回JSON格式部署配置信息。


  • 配置生成方式
    CM为每个服务进程生成独立的配置目录(文件)。所有配置统一在服务端查询数据库生成(因为scm数据库只能在localhost下访问)生成配置文件,再由agent通过网络下载包含配置文件的zip包到本地解压到指定的目录。


  • 配置修改
    CM对于需要修改的配置预先定义,对于没有预先定义的配置,则通过在高级配置项中使用xml配置片段的方式进行配置。而对于/etc/hadoop/下的配置文件是客户端的配置,可以在CM通过部署客户端生成客户端配置。

3. 数据库
Cloudera manager主要的数据库为scm,存储Cloudera manager运行所需要的信息:配置,主机,用户等。

4. CM结构
CM分为Server与Agent两部分及数据库(自带更改过的嵌入Postgresql)。它主要做三件事件:
  • 管理监控集群主机。
  • 统一管理配置。
  • 管理维护Hadoop平台系统。
实现采用C/S结构,Agent为客户端负责执行服务端发来的命令,执行方式一般为使用python调用相应的服务shell脚本。Server端为Java REST服务,提供REST API,Web管理端通过REST API调用Server端功能,Web界面使用富客户端技术(Knockout)。
  • Server端主体使用Java实现。
  • Agent端主体使用Python, 服务的启动通过调用相应的shell脚本进行启动,如果启动失败会重复4次调用启动脚本。
  • Agent与Server保持心跳,使用Thrift RPC框架。


5. 升级
在CM中可以通过界面向导升级相关服务。升级过程为三步:
  • 下载服务软件包。
  • 把所下载的服务软件包分发到集群中受管的机器上。
  • 安装服务软件包,使用软链接的方式把服务程序目录链接到新安装的软件包目录上。


6. 卸载
sudo /usr/share/cmf/uninstall-scm-express.sh, 然后删除/var/lib/cloudera-scm-server-db/目录,不然下次安装可能不成功。


7. 开启postgresql远程访问
CM内嵌数据库被配置成只能从localhost访问,如果需要从外部查看数据,数据修改vim /var/lib/cloudera-scm-server-db/data/pg_hba.conf文件,之后重启数据库。运行数据库的用户为cloudera-scm。
posted @ 2017-04-13 14:36 xzc 阅读(29) | 评论 (0)编辑 收藏
  2017年4月11日
  1. 新版本的 hbck 可以修复各种错误,修复选项是:     
  2. (1)-fix,向下兼容用,被-fixAssignments替代     
  3. (2)-fixAssignments,用于修复region assignments错误     
  4. (3)-fixMeta,用于修复meta表的问题,前提是HDFS上面的region info信息有并且正确。     
  5. (4)-fixHdfsHoles,修复region holes(空洞,某个区间没有region)问题     
  6. (5)-fixHdfsOrphans,修复Orphan region(hdfs上面没有.regioninfo的region)     
  7. (6)-fixHdfsOverlaps,修复region overlaps(区间重叠)问题     
  8. (7)-fixVersionFile,修复缺失hbase.version文件的问题     
  9. (8)-maxMerge <n> (n默认是5),当region有重叠是,需要合并region,一次合并的region数最大不超过这个值。     
  10. (9)-sidelineBigOverlaps ,当修复region overlaps问题时,允许跟其他region重叠次数最多的一些region不参与(修复后,可以把没有参与的数据通过bulk load加载到相应的region)     
  11. (10)-maxOverlapsToSideline <n> (n默认是2),当修复region overlaps问题时,一组里最多允许多少个region不参与     
  12. 由于选项较多,所以有两个简写的选项     
  13. (11) -repair,相当于-fixAssignments -fixMeta -fixHdfsHoles -fixHdfsOrphans -fixHdfsOverlaps -fixVersionFile -sidelineBigOverlaps     
  14. (12)-repairHoles,相当于-fixAssignments -fixMeta -fixHdfsHoles -fixHdfsOrphans     
  15.      
  16.      
  17.      
  18. 新版本的 hbck     
  19. (1)缺失hbase.version文件     
  20.  加上选项 -fixVersionFile 解决     
  21. (2)如果一个region即不在META表中,又不在hdfs上面,但是在regionserver的online region集合中     
  22.  加上选项 -fixAssignments 解决     
  23. (3)如果一个region在META表中,并且在regionserver的online region集合中,但是在hdfs上面没有     
  24.  加上选项 -fixAssignments -fixMeta 解决,( -fixAssignments告诉regionserver close region),( -fixMeta删除META表中region的记录)     
  25. (4)如果一个region在META表中没有记录,没有被regionserver服务,但是在hdfs上面有     
  26. 加上选项 -fixMeta -fixAssignments 解决,( -fixAssignments 用于assign region),( -fixMeta用于在META表中添加region的记录)     
  27. (5)如果一个region在META表中没有记录,在hdfs上面有,被regionserver服务了     
  28. 加上选项 -fixMeta 解决,在META表中添加这个region的记录,先undeploy region,后assign     
  29. (6)如果一个region在META表中有记录,但是在hdfs上面没有,并且没有被regionserver服务     
  30. 加上选项 -fixMeta 解决,删除META表中的记录     
  31. (7)如果一个region在META表中有记录,在hdfs上面也有,table不是disabled的,但是这个region没有被服务     
  32. 加上选项 -fixAssignments 解决,assign这个region     
  33. (8)如果一个region在META表中有记录,在hdfs上面也有,table是disabled的,但是这个region被某个regionserver服务了     
  34. 加上选项 -fixAssignments 解决,undeploy这个region     
  35. (9)如果一个region在META表中有记录,在hdfs上面也有,table不是disabled的,但是这个region被多个regionserver服务了     
  36. 加上选项 -fixAssignments 解决,通知所有regionserver close region,然后assign region     
  37. (10)如果一个region在META表中,在hdfs上面也有,也应该被服务,但是META表中记录的regionserver和实际所在的regionserver不相符     
  38. 加上选项 -fixAssignments 解决     
  39.      
  40. (11)region holes     
  41. 需要加上 -fixHdfsHoles ,创建一个新的空region,填补空洞,但是不assign 这个 region,也不在META表中添加这个region的相关信息     
  42. (12)region在hdfs上面没有.regioninfo文件     
  43. -fixHdfsOrphans 解决     
  44. (13)region overlaps     
  45. 需要加上 -fixHdfsOverlaps     
  46.      
  47.      
  48. 说明:     
  49. (1)修复region holes时,-fixHdfsHoles 选项只是创建了一个新的空region,填补上了这个区间,还需要加上-fixAssignments -fixMeta 来解决问题,( -fixAssignments 用于assign region),( -fixMeta用于在META表中添加region的记录),所以有了组合拳 -repairHoles 修复region holes,相当于-fixAssignments -fixMeta -fixHdfsHoles -fixHdfsOrphans     
  50. (2) -fixAssignments,用于修复region没有assign、不应该assign、assign了多次的问题     
  51. (3)-fixMeta,如果hdfs上面没有,那么从META表中删除相应的记录,如果hdfs上面有,在META表中添加上相应的记录信息     
  52. (4)-repair 打开所有的修复选项,相当于-fixAssignments -fixMeta -fixHdfsHoles -fixHdfsOrphans -fixHdfsOverlaps -fixVersionFile -sidelineBigOverlaps     
  53.      
  54. 新版本的hbck从(1)hdfs目录(2)META(3)RegionServer这三处获得region的Table和Region的相关信息,根据这些信息判断并repair    
新版本的 hbck 可以修复各种错误,修复选项是:    (1)-fix,向下兼容用,被-fixAssignments替代    (2)-fixAssignments,用于修复region assignments错误    (3)-fixMeta,用于修复meta表的问题,前提是HDFS上面的region info信息有并且正确。    (4)-fixHdfsHoles,修复region holes(空洞,某个区间没有region)问题    (5)-fixHdfsOrphans,修复Orphan region(hdfs上面没有.regioninfo的region)    (6)-fixHdfsOverlaps,修复region overlaps(区间重叠)问题    (7)-fixVersionFile,修复缺失hbase.version文件的问题    (8)-maxMerge <n> (n默认是5),当region有重叠是,需要合并region,一次合并的region数最大不超过这个值。    (9)-sidelineBigOverlaps ,当修复region overlaps问题时,允许跟其他region重叠次数最多的一些region不参与(修复后,可以把没有参与的数据通过bulk load加载到相应的region)    (10)-maxOverlapsToSideline <n> (n默认是2),当修复region overlaps问题时,一组里最多允许多少个region不参与    由于选项较多,所以有两个简写的选项    (11) -repair,相当于-fixAssignments -fixMeta -fixHdfsHoles -fixHdfsOrphans -fixHdfsOverlaps -fixVersionFile -sidelineBigOverlaps    (12)-repairHoles,相当于-fixAssignments -fixMeta -fixHdfsHoles -fixHdfsOrphans                新版本的 hbck    (1)缺失hbase.version文件     加上选项 -fixVersionFile 解决    (2)如果一个region即不在META表中,又不在hdfs上面,但是在regionserver的online region集合中     加上选项 -fixAssignments 解决    (3)如果一个region在META表中,并且在regionserver的online region集合中,但是在hdfs上面没有     加上选项 -fixAssignments -fixMeta 解决,( -fixAssignments告诉regionserver close region),( -fixMeta删除META表中region的记录)    (4)如果一个region在META表中没有记录,没有被regionserver服务,但是在hdfs上面有    加上选项 -fixMeta -fixAssignments 解决,( -fixAssignments 用于assign region),( -fixMeta用于在META表中添加region的记录)    (5)如果一个region在META表中没有记录,在hdfs上面有,被regionserver服务了    加上选项 -fixMeta 解决,在META表中添加这个region的记录,先undeploy region,后assign    (6)如果一个region在META表中有记录,但是在hdfs上面没有,并且没有被regionserver服务    加上选项 -fixMeta 解决,删除META表中的记录    (7)如果一个region在META表中有记录,在hdfs上面也有,table不是disabled的,但是这个region没有被服务    加上选项 -fixAssignments 解决,assign这个region    (8)如果一个region在META表中有记录,在hdfs上面也有,table是disabled的,但是这个region被某个regionserver服务了    加上选项 -fixAssignments 解决,undeploy这个region    (9)如果一个region在META表中有记录,在hdfs上面也有,table不是disabled的,但是这个region被多个regionserver服务了    加上选项 -fixAssignments 解决,通知所有regionserver close region,然后assign region    (10)如果一个region在META表中,在hdfs上面也有,也应该被服务,但是META表中记录的regionserver和实际所在的regionserver不相符    加上选项 -fixAssignments 解决        (11)region holes    需要加上 -fixHdfsHoles ,创建一个新的空region,填补空洞,但是不assign 这个 region,也不在META表中添加这个region的相关信息    (12)region在hdfs上面没有.regioninfo文件    -fixHdfsOrphans 解决    (13)region overlaps    需要加上 -fixHdfsOverlaps            说明:    (1)修复region holes时,-fixHdfsHoles 选项只是创建了一个新的空region,填补上了这个区间,还需要加上-fixAssignments -fixMeta 来解决问题,( -fixAssignments 用于assign region),( -fixMeta用于在META表中添加region的记录),所以有了组合拳 -repairHoles 修复region holes,相当于-fixAssignments -fixMeta -fixHdfsHoles -fixHdfsOrphans    (2) -fixAssignments,用于修复region没有assign、不应该assign、assign了多次的问题    (3)-fixMeta,如果hdfs上面没有,那么从META表中删除相应的记录,如果hdfs上面有,在META表中添加上相应的记录信息    (4)-repair 打开所有的修复选项,相当于-fixAssignments -fixMeta -fixHdfsHoles -fixHdfsOrphans -fixHdfsOverlaps -fixVersionFile -sidelineBigOverlaps        新版本的hbck从(1)hdfs目录(2)META(3)RegionServer这三处获得region的Table和Region的相关信息,根据这些信息判断并repair  

示例:

 

 

  1. 查看hbasemeta情况    
  2. hbase hbck    
  3. 1.重新修复hbase meta表(根据hdfs上的regioninfo文件,生成meta表)    
  4. hbase hbck -fixMeta    
  5. 2.重新将hbase meta表分给regionserver(根据meta表,将meta表上的region分给regionservere)    
  6. hbase hbck -fixAssignments    
查看hbasemeta情况   hbase hbck   1.重新修复hbase meta表(根据hdfs上的regioninfo文件,生成meta表)   hbase hbck -fixMeta   2.重新将hbase meta表分给regionserver(根据meta表,将meta表上的region分给regionservere)   hbase hbck -fixAssignments  

 


 

  1. 当出现漏洞    
  2. hbase hbck -fixHdfsHoles  (新建一个region文件夹)    
  3. hbase hbck -fixMeta        (根据regioninfo生成meta表)    
  4. hbase hbck -fixAssignments  (分配region到regionserver上)  
当出现漏洞   hbase hbck -fixHdfsHoles  (新建一个region文件夹)   hbase hbck -fixMeta        (根据regioninfo生成meta表)   hbase hbck -fixAssignments  (分配region到regionserver上)


 

  1. 一、故障原因    
  2. IP为10.191.135.3的服务器在2013年8月1日出现服务器重新启动的情况,导致此台服务器上的所有服务均停止。从而造成NTP服务停止。当NTP服务停止后,导致HBase集群中大部分机器时钟和主机时间不一致,造成regionserver服务中止。并在重新启动后,出现region的hole。需要对数据进行重新修复,以正常提供插入数据的服务。    
  3.     
  4. 二、恢复方式    
  5. 1、集群50个regionserver,宕掉服务41个,namenode所在机器10.191.135.3不明重启(原因查找中)导致本机上的namenode、zookeeper、时间同步服务器服务挂掉。    
  6. 2、重启hbase服务时,没能成功stop剩余的9个regionserver服务,进行了人为kill进程,    
  7. 3、在hdfs上移走了hlog(避免启动时split log花费过多时间影响服务),然后重启hbase。发现10.191.135.30机器上的时间与时间同步服务器10.191.135.3不同步。手工同步后重启成功。hbase可以正常提供查询服务。    
  8. 4、运行mapreduce put数据。抛出异常,数据无法正常插入;    
  9. 5、执行/opt/hbase/bin/hbase hbck -fixAssignments,尝试重新分配region。结果显示hbase有空洞,即region之间数据不连续了;    
  10. 6、通过上述操作可以定位是在regionserver服务宕掉的后重启的过程中丢了数据。需要进行空洞修复。然而hbase hbck命令总是只显示三条空洞。    
  11. 7、通过编写的regionTest.jar工具进行进一步检测出空洞所在的regionname然后停掉hbase,进而进行region合并修复空洞;    
  12. 8、合并的merge 操作需要先去.META.表里读取该region的信息,由于.META.表也在regionserver宕机过程中受到损坏,所以部分region的.META.信息没有,merge操作时就抛出空指针异常。因此只能将hdfs这些region进行移除,然后通过regionTest.jar 检测新的空洞所在的regionname,进行合并操作修复空洞;    
  13. 9、关于region重叠,即regionname存在.META.表内,但是在hdfs上被错误的移出,并进行了region合并。这种情况下需要通过regionTest.jar检测重叠的regionname然后手动去.META.表删除,.META.表修改之后需要flush;    
  14. 10、最后再次执行 hbase hbck 命令,hbase 所有表status ok。    
  15.     
  16. 三、相关命令及页面报错信息    
  17. 1.手工同步时间命令
service ntpd stop
ntpdate -d 192.168.1.20
service ntpd start    
  18.     
  19.     
  20. 2.org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed 2 actions: WrongRegionException: 2 times, servers with issues: datanode10:60020, 
at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.processBatchCallback(HConnectionManager.java:1641)
at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.processBatch(HConnectionManager.java:1409)
at org.apache.hadoop.hbase.client.HTable.flushCommits(HTable.java:949)
at org.apache.hadoop.hbase.client.HTable.doPut(HTable.java:826)
at org.apache.hadoop.hbase.client.HTable.put(HTable.java:801)
at org.apache.hadoop.hbase.mapreduce.TableOutputFormat$TableRecordWriter.write(TableOutputFormat.java:123)
at org.apache.hadoop.hbase.mapreduce.TableOutputFormat$TableRecordWriter.write(TableOutputFormat.java:84)
at org.apache.hadoop.mapred.MapTask$NewDirectOutputCollector.write(MapTask.java:533)
at org.apache.hadoop.mapreduce.task.TaskInputOutputContextImpl.write(TaskInputOutputContextImpl.java:88)
at o    
  21.     
  22. 3.13/08/01 18:30:02 DEBUG util.HBaseFsck: There are 22093 region info entries
ERROR: There is a hole in the region chain between +8615923208069cmnet201303072132166264580 and +861592321.  You need to create a new .regioninfo and region dir in hdfs to plug the hole.
ERROR: There is a hole in the region chain between +8618375993383cmwap20130512235639430 and +8618375998629cmnet201305040821436779670.  You need to create a new .regioninfo and region dir in hdfs to plug the hole.
ERROR: There is a hole in the region chain between +8618725888080cmnet201212271719506311400 and +8618725889786cmnet201302131646431671140.  You need to create a new .regioninfo and region dir in hdfs to plug the hole.
ERROR: Found inconsistency in table cqgprs
Summary:
  -ROOT- is okay.
    Number of regions: 1
    Deployed on:  datanode14,60020,1375330955915
  .META. is okay.
    Number of regions: 1
    Deployed on:  datanode21,60020,1375330955825
  cqgprs is okay.
    Number of regions: 22057
    Deployed on:  datanode1,60020,1375330955761 datanode10,60020,1375330955748 datanode11,60020,1375330955736 datanode12,60020,1375330955993 datanode13,60020,1375330955951 datanode14,60020,1375330955915 datanode15,60020,1375330955882 datanode16,60020,1375330955892 datanode17,60020,1375330955864 datanode18,60020,1375330955703 datanode19,60020,1375330955910 datanode2,60020,1375330955751 datanode20,60020,1375330955849 datanode21,60020,1375330955825 datanode22,60020,1375334479752 datanode23,60020,1375330955835 datanode24,60020,1375330955932 datanode25,60020,1375330955856 datanode26,60020,1375330955807 datanode27,60020,1375330955882 datanode28,60020,1375330955785 datanode29,60020,1375330955799 datanode3,60020,1375330955778 datanode30,60020,1375330955748 datanode31,60020,1375330955877 datanode32,60020,1375330955763 datanode33,60020,1375330955755 datanode34,60020,1375330955713 datanode35,60020,1375330955768 datanode36,60020,1375330955896 datanode37,60020,1375330955884 datanode38,60020,1375330955918 datanode39,60020,1375330955881 datanode4,60020,1375330955826 datanode40,60020,1375330955770 datanode41,60020,1375330955824 datanode42,60020,1375449245386 datanode43,60020,1375330955880 datanode44,60020,1375330955902 datanode45,60020,1375330955881 datanode46,60020,1375330955841 datanode47,60020,1375330955790 datanode48,60020,1375330955848 datanode49,60020,1375330955849 datanode5,60020,1375330955880 datanode50,60020,1375330955802 datanode6,60020,1375330955753 datanode7,60020,1375330955890 datanode8,60020,1375330955967 datanode9,60020,1375330955948
  test1 is okay.
    Number of regions: 1
    Deployed on:  datanode43,60020,1375330955880
  test2 is okay.
    Number of regions: 1
    Deployed on:  datanode21,60020,1375330955825
35 inconsistencies detected.
Status: INCONSISTENT    
  23.     
  24. 4.hadoop jar regionTest.jar com.region.RegionReaderMain /hbase/cqgprs 检测cqgprs表里的空洞所在的regionname。    
  25.     
  26. 5.==================================
first endKey = +8615808059207cmnet201307102326567966800
second startKey = +8615808058578cmnet201212251545557984830

first regionNmae = cqgprs,+8615808058578cmnet201212251545557984830,1375241186209.0f8266ad7ac45be1fa7233e8ea7aeef9.
second regionNmae = cqgprs,+8615808058578cmnet201212251545557984830,1362778571889.3552d3db8166f421047525d6be39c22e.
==================================
first endKey = +8615808060140cmnet201303051801355846850
second startKey = +8615808059207cmnet201307102326567966800

first regionNmae = cqgprs,+8615808058578cmnet201212251545557984830,1362778571889.3552d3db8166f421047525d6be39c22e.
second regionNmae = cqgprs,+8615808059207cmnet201307102326567966800,1375241186209.09d489d3df513bc79bab09cec36d2bb4.
==================================    
  27.     
  28. 6.Usage: bin/hbase org.apache.hadoop.hbase.util.Merge [-Dfs.default.name=hdfs://nn:port] <table-name> <region-1> <region-2>

./hbase org.apache.hadoop.hbase.util.Merge -Dfs.defaultFS=hdfs://bdpha cqgprs cqgprs,+8615213741567cmnet201305251243290802280,1369877465524.3c13b460fae388b1b1a70650b66c5039. cqgprs,+8615213745577cmnet201302141725552206710,1369534940433.5de80f59071555029ac42287033a4863. &    
  29.     
  30. 7.13/08/01 22:24:02 WARN util.HBaseFsck: Naming new problem group: +8618225125357cmnet201212290358070667800
ERROR: (regions cqgprs,+8618225123516cmnet201304131404096748520,1375363774655.b3cf5cc752f4427a4e699270dff9839e. and cqgprs,+8618225125357cmnet201212290358070667800,1364421610707.7f7038bfbe2c0df0998a529686a3e1aa.) There is an overlap in the region chain.
13/08/01 22:24:02 WARN util.HBaseFsck: reached end of problem group: +8618225127504cmnet201302182135452100210
13/08/01 22:24:02 WARN util.HBaseFsck: Naming new problem group: +8618285642723cmnet201302031921019768070
ERROR: (regions cqgprs,+8618285277826cmnet201306170027424674330,1375363962312.9d1e93b22cec90fd75361fa65b1d20d2. and cqgprs,+8618285642723cmnet201302031921019768070,1360873307626.f631cd8c6acc5e711e651d13536abe94.) There is an overlap in the region chain.
13/08/01 22:24:02 WARN util.HBaseFsck: reached end of problem group: +8618286275556cmnet201212270713444340110
13/08/01 22:24:02 WARN util.HBaseFsck: Naming new problem group: +8618323968833cmnet201306010239025175240
ERROR: (regions cqgprs,+8618323967956cmnet201306091923411365860,1375364143678.665dba6a14ebc9971422b39e079b00ae. and cqgprs,+8618323968833cmnet201306010239025175240,1372821719159.6d2fecc1b3f9049bbca83d84231eb365.) There is an overlap in the region chain.
13/08/01 22:24:02 WARN util.HBaseFsck: reached end of problem group: +8618323992353cmnet201306012336364819810
ERROR: There is a hole in the region chain between +8618375993383cmwap20130512235639430 and +8618375998629cmnet201305040821436779670.  You need to create a new .regioninfo and region dir in hdfs to plug the hole.
13/08/01 22:24:02 WARN util.HBaseFsck: Naming new problem group: +8618723686187cmnet201301191433522129820
ERROR: (regions cqgprs,+8618723683087cmnet201301300708363045080,1375364411992.4ee5787217c1da4895d95b3b92b8e3a2. and cqgprs,+8618723686187cmnet201301191433522129820,1362003066106.70b48899cc753a0036f11bb27d2194f9.) There is an overlap in the region chain.
13/08/01 22:24:02 WARN util.HBaseFsck: reached end of problem group: +8618723689138cmnet201301051742388948390
13/08/01 22:24:02 WARN util.HBaseFsck: Naming new problem group: +8618723711808cmnet201301031139206225900
ERROR: (regions cqgprs,+8618723710003cmnet201301250809235976320,1375364586329.40eed10648c9a43e3d5ce64e9d63fe00. and cqgprs,+8618723711808cmnet201301031139206225900,1361216401798.ebc442e02f5e784bce373538e06dd232.) There is an overlap in the region chain.
13/08/01 22:24:02 WARN util.HBaseFsck: reached end of problem group: +8618723714626cmnet201302122009459491970
ERROR: There is a hole in the region chain between +8618725888080cmnet201212271719506311400 and +8618725889786cmnet201302131646431671140.  You need to create a new .regioninfo and region dir in hdfs to plug the hole.    
  31.     
  32. 8.  delete '.META.','regionname','info:serverstartcode'    
  33. delete '.META.','regionname','info:regionserver'    
  34. delete '.META.','regionname','info:regioninfo'    
  35.      
  36. 9. flush '.META.'
major_compact '.META.'   
posted @ 2017-04-11 16:01 xzc 阅读(33) | 评论 (0)编辑 收藏

自从开源中国的maven仓库挂了之后就一直在用国外的仓库,慢得想要砸电脑的心都有了。如果你和我一样受够了国外maven仓库的龟速下载?快试试阿里云提供的maven仓库,从此不在浪费生命……

仓库地址:http://maven.aliyun.com/nexus/#view-repositories;public~browsestorage

 

仓库配置

在maven的settings.xml文件里的mirrors节点,添加如下子节点:

复制代码
<mirror>       <id>nexus-aliyun</id>       <mirrorOf>central</mirrorOf>         <name>Nexus aliyun</name>       <url>http://maven.aliyun.com/nexus/content/groups/public</url>   </mirror> 
复制代码

或者直接在profiles->profile->repositories节点,添加如下子节点:

复制代码
<repository>     <id>nexus-aliyun</id>     <name>Nexus aliyun</name>     <layout>default</layout>     <url>http://maven.aliyun.com/nexus/content/groups/public</url>     <snapshots>         <enabled>false</enabled>     </snapshots>     <releases>         <enabled>true</enabled>     </releases> </repository>
复制代码

 

settings文件的路径

settings.xml的默认路径就:个人目录/.m2/settings.xml

如:

windowns: C:\Users\你的用户名\.m2\settings.xml

linux: /home/你的用户名/.m2/settings.xml

Keep it simple!
作者:KEITSI
知识共享,欢迎转载。
posted @ 2017-04-11 10:08 xzc 阅读(55) | 评论 (0)编辑 收藏
仅列出标题  下一页