素描速写画人体结构图口诀技巧讲解

  categories:资料  author:

速写是属于素描的一种绘画形式,速写与素描各有特点。它们锻炼人的不同方面的能力。速写:时间较短、表现方式灵活,重在表现人物的动态、精彩的表情、感人的情景或是一瞬即逝的风景。它训练人的观察力、表现力、记忆力、概括力。是一种很好的练习方式。素描:广义的素描包括速写。狭义的素描,指时间较长、表现光影效果、透视和虚实现象、表现物体的结构这样的单色绘画。它训练人的观察力、表现力、对细节的叙述,对画面层次、前后、空间、透视、结构、块面、虚实等都有很精确的要求。速写与素描没有谁高于谁这一说。就像国画与油画一样,是两种不同的表达形式

人物速写,我们最容易出现的问题,就是比例结构找不对,要么头大了,要么手短了,那么今天我们把复杂的人体,简单化来理解,把人体分成具体的几何形,理解掌握好各个几何形之间的间隔比例关系,就能有效的解决人物速写比例结构的问题。

“新七法”中以“比例得当”明确地强调了基础绘画的品评标准。谈到比例,这里应再强调人体的基本结构和动态。如人体的基本比例:即以头为基本单位,按从发际线——下颌——胸线——肚脐之间的距离定为3个头长,还有脐孔到耻骨联合为一个头长。脚底——髌骨——耻骨联合线为4个头长,骨盆线到肚脐还有半个头长。坐五(我们知道,在产生坐姿比例时,上半身基本保持不变,而产生比例变化的地方就在骨盆和髌骨之间)、盘三半(根据人物的动态变化观察比例)。这是画好速写的第二步,这一步强调在平时训练学习过程中,我们必须熟练掌握并了解人体的基本比例。

动态自然 强调动态线

把握控制人体运动规律的两条线:肩线,骨盆线。肩线就是指两个肩点的连线,在人体产生动态变化时,肩线和骨盆线这两条线将会成“倒八字”。我们在充分认识这一规律后,就可以熟练地把握人物运动的基本特点。

比例和动态在速写学习过程中属于重中之重,我们必须熟练地掌握人体结构的基本知识、比例和技能,理解人物骨骼和肌肉的生长规律以及对形体运动所产生美的能量进行明确判断。善于抓住物象的基本特征、注意每个转折部位的扭动关系。

古人习中国画,很注重笔墨。而今,我们研究速写,也如“六法论”里强调“骨法用笔”与“新七法”中强调“轻重适宜”一样,“用线”在表达速写语言里尤为重要,学者应在学习的过程中研究线条的趣味,发现线条的魅力、情趣。“骨法用笔”强调了我们在用线时应该根据物象的形体变化为支撑,善于把握物象的实质,即骨架。速写在用线时也应注意线条的穿插、取舍和提炼,注意线条的对比、变化和节奏(如轻重、虚实、方圆、曲直、疏密、粗细、长短)。流畅的线条可增强画面表现力和生动性,线条的特质与形体结构的巧妙结合,是速写达到“气韵生动”的重要条件。当然,线、面结合的速写更利于增强绘画层次感。

下面和大家将的人体比例结构,是按照七头身的比例进行讲解的。

人体这么多结构,其实数起来一共就17个段,每段之间相互联合结构在一起,就组成了人体

人之所有有各种动态,最主要的是三大固定段与两大活动段的之间相互组合形成的,四肢是丰富动态而存在的。那么三大固定段分别是头,胸腔和髋骨。两大活动段是颈和腰。简称三固定和两活动。

将人体比例结构,肯定要有个标准单位来进行定位,通常我们是以头的长度为单位1对全身各部分进行比较。这里,我们要记住人体简化后的基本型,头为椭圆,胸腔为倒梯形,髋骨为正梯形。这五段的比例如下:

1.头长:1

2.颈(下颚至肩):1/3头

3.胸腔:上下长:一又三分之一头;肩宽两头;腰宽一头

4.腰:上下长1/3头,左右宽1头

5.髋骨:上下长:一头;髋骨上缘:一又三分之一头;下缘一头半

在起大型的过程中,我们其实不妨轻轻的画出这几段,检查上下长度和左右宽度是否正确,目测会有一定难度,建议是拿笔去测量,以保证往下走不会出错。

讲完三固定和两活动,接下来分析手部的结构和比例:

手生根的地方为肩膀,手又分为上臂,前臂和手掌,这三段的比例是:

上臂:一又三分之一头

前臂:一头

手掌:三分之二头

所以手从肩膀至指尖的距离为三头,而三段的比例是4:3:2

这里我要稍微讲一点骨骼,以方便大家理解几本几何形(如下图)

上臂的骨头叫做肱骨,只有一根。前臂的骨头有两根,分别是尺骨和桡骨。手掌的骨头叫手骨。

而手的几本几何形如下,上臂为矩形,因为有肱二头和肱三头肌,所以前后比较宽。前臂类似矩形,但是靠近肘部的地方略宽,之所以上图讲骨骼,前臂有两根骨头,所以导致前臂左右略宽于上臂(如下图)同时还可以注意的是,上臂的长度几本等同于胸腔的长度!

那么想画好手,我们 需要简单了解一下手的肌肉有哪些,

肩头的是三角肌,

三角肌下面,附着于肱骨之上的是肱二头肌(前)和肱三头肌(后),

前臂上的是肱桡肌(大弧线)、尺侧伸腕肌(小弧线)、掌长肌(小弧线)、尺骨(直线)。这里跟大家讲的弧线,看下图就会很明白我在讲什么了:

牢记基本型,记住这几根弧线,就能逐渐画好手!

下半身的大体块有大腿、膝盖、小腿以及骨盆,骨盆往外,大腿往内,膝盖往外,小腿往内,足往外,都是成梯形来回转折的,整个腿的长度从骨盆上缘至足底是四个头,第一个头到腹股沟,第二个投至膝盖中,第三个头至小腿中,第四个头至足底。具体如下图:

以上是正面试图,那么侧面来看,骨盆是向前倾斜的,大腿垂直往下,膝盖也是向前倾斜的,小腿垂直往下,足平置(一头宽),所以如些图,会呈现大腿靠前,小腿靠后的样子

大腿的骨头叫股骨,只有一根,小腿骨头有两根,分别是胫骨和腓骨,这个简单和大家带一下

我们了解了腿部的基本几何形,再来简单了解如何把腿圆起来,请结合文字看图,理解会方便很多,大腿的主要肌肉有三条(股直肌、股内肌、股外肌)所以大腿外侧是一个大弧线,内侧一个中等弧线;膝盖内圆外方;小腿的胫骨是露在外头的,骨头后面是腓肠肌和比目鱼肌,所以小腿外侧也是一个大弧线,内侧是一个小弧线;足和小腿链接的地方有两个关节骨点,注意这个骨点的位置,是内高外低

这里目前不要过多纠结于肌肉和骨骼,只要记住基本几何形和几条弧线,就能够很好地表现结构,多加练习,会越来越熟练,之后再了解一次肌肉和骨骼,就能更深刻的理解,也能更准确地将其形体表达出来。

接下来要讲的,是头、手、足三个部分的比例结构,

首先是头:… 阅读全文

Spring Boot OAuth 2.0 客户端

  categories:资料  author:

在上一篇《OAuth 2.0 授权码请求》中我们已经可以获取到access_token了,本节将使用客户端来访问远程资源

配置资源服务器

授权服务器负责生成并发放访问令牌(access_token),客户端在访问受保护的资源时会带上访问令牌,资源服务器需要解析并验证客户端带的这个访问令牌。

如果你的资源服务器同时也是一个授权服务器(资源服务器和授权服务器在一起),那么资源服务器就不需要考虑令牌解析的事情了,否则这一步是不可或缺的。

To use the access token you need a Resource Server (which can be the same as the Authorization Server). Creating a Resource Server is easy, just add @EnableResourceServer and provide some configuration to allow

阅读全文

OAuth 2.0 授权码请求

  categories:资料  author:

纸上得来终觉浅,绝知此事要躬行。理论知识了解以后,最终还是要动手实践,不亲自做一遍永远不知道里面有多少坑。本节的重点是用Spring Security实现授权码模式。

1. maven依赖

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.cjs.example</groupId>
    <artifactId>cjs-oauth2-code-server</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <packaging>jar</packaging>

    <name>cjs-oauth2-code-server</name>
    <description></description>

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.0.2.RELEASE</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
        <java.version>1.8</java.version>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-security</artifactId>
        
阅读全文

Spring Security OAuth2.0

  categories:资料  author:

OAuth 2.0 Provider 实现

在OAuth 2.0中,provider角色事实上是把授权服务和资源服务分开,有时候它们也可能在同一个应用中,用Spring Security OAuth你可以选择把它们分成两个应用,当然多个资源服务可以共享同一个授权服务。

获取token的请求由Spring MVC的控制端点处理,访问受保护的资源由标准的Spring Security请求过滤器处理。

(The requests for the tokens are handled by Spring MVC controller endpoints, and access to protected resources is handled by standard Spring Security request filters. )

为了实现OAuth 2.0授权服务器,在Spring Security的过滤器链中需要有以下端点:… 阅读全文

The OAuth 2.0 Authorization Framework

  categories:资料  author:

OAuth 2.0授权框架支持第三方支持访问有限的HTTP服务,通过在资源所有者和HTTP服务之间进行一个批准交互来代表资源者去访问这些资源,或者通过允许第三方应用程序以自己的名义获取访问权限。

为了方便理解,可以想象OAuth2.0就是在用户资源和第三方应用之间的一个中间层,它把资源和第三方应用隔开,使得第三方应用无法直接访问资源,从而起到保护资源的作用。

为了访问这种受保护的资源,第三方应用(客户端)在访问的时候需要提供凭证。即,需要告诉OAuth2.0你是谁你要做什么。

你可以将用户名和密码告诉第三方应用,让第三方应用直接以你的名义去访问,也可以授权第三方应用去访问。

可以联想一下微信公众平台开发,在微信公众平台开发过程中当我们访问某个页面,页面可能弹出一个提示框应用需要获取我们的个人信息问是否允许,点确认其实就是授权第三方应用获取我们在微信公众平台的个人信息。这里微信网页授权就是使用的OAuth2.0。

1.  Introduction

在传统的client-server认证模型中,客户端通过提供资源所有者的凭证来请求服务器访问一个受限制的资源(受保护的资源)。为了让第三方应用可以访问这些受限制的资源,资源所有者共享他的凭证给第三方应用。

1.1.   Roles

OAuth定义了四种角色:

  • resource owner(资源所有者)
  • resource server(资源服务器)
  • client(客户端):代表资源所有者并且经过所有者授权去访问受保护的资源的应用程序
  • authorization server(授权服务器):在成功验证资源所有者并获得授权后向客户端发出访问令牌

1.2.  Protocol Flow

抽象的OAuth2.0流程如图所示:

  1. (A)  客户端向资源所有者请求其授权
  2. (B)  客户端收到资源所有者的授权许可,这个授权许可是一个代表资源所有者授权的凭据
  3. (C)  客户端向授权服务器请求访问令牌,并出示授权许可
  4. (D)  授权服务器对客户端身份进行认证,并校验授权许可,如果都是有效的,则发放访问令牌
  5. (E)  客户端向资源服务器请求受保护的资源,并出示访问令牌
  6. (F)  资源服务器校验访问令牌,如果令牌有效,则提供服务

1.3.  Authorization Grant

一个授权许可是一个凭据,它代表资源所有者对访问受保护资源的一个授权,是客户端用来获取访问令牌的。

授权类型有四种:authorization … 阅读全文

Spring Security OAuth2开发指南

  categories:资料  author:

Spring OAuth2.0提供者实际上分为:

  • 授权服务 Authorization Service.
  • 资源服务 Resource Service.
虽然这两个提供者有时候可能存在同一个应用程序中,但在Spring Security OAuth中你可以把
他它们各自放在不同的应用上,而且你可以有多个资源服务,它们共享同一个中央授权服
务。
所有获取令牌的请求都将会在Spring MVC controller endpoints中进行处理,并且访问受保护
的资源服务的处理流程将会放在标准的Spring Security请求过滤器中(filters)。
下面是配置一个授权服务必须要实现的endpoints:
  • AuthorizationEndpoint:用来作为请求者获得授权的服务,默认的URL是/oauth/authorize.
  • TokenEndpoint:用来作为请求者获得令牌(Token)的服务,默认的URL是/oauth/token.
下面是配置一个资源服务必须要实现的过滤器:
  • OAuth2AuthenticationProcessingFilter:用来作为认证令牌(Token)的一个处理流程过滤器。只有当过滤器通过之后,请求者才能获得受保护的资源。
配置提供者(授权、资源)都可以通过简单的Java注解@Configuration来进行适配,你也可以使用基于XML的声明式语法来进行配置,如果你打算这样做的话,那么请使用http://www.springframework.org/schema/security/spring-security-oauth2.xsd来作为XML的schema(即XML概要定义)以及使用http://www.springframework.org/schema/security/oauth2来作为命名空间。
一、授权服务配置:

配置一个授权服务,你需要考虑几种授权类型(Grant Type),不同的授权类型为客户端(Client)提供了不同的获取令牌(Token)方式,为了实现并确定这几种授权,需要配置使用 ClientDetailsService 和 TokenService 来开启或者禁用这几种授权机制。到这里就请注意了,不管你使用什么样的授权类型(Grant Type),每一个客户端(Client)都能够通过明确的配置以及权限来实现不同的授权访问机制。这也就是说,假如你提供了一个支持”client_credentials”的授权方式,并不意味着客户端就需要使用这种方式来获得授权。下面是几种授权类型的列表,具体授权机制的含义可以参见RFC6749(中文版本):
  • authorization_code:授权码类型。
  • implicit:隐式授权类型。
  • password:资源所有者(即用户)密码类型。
  • client_credentials:客户端凭据(客户端ID以及Key)类型。
  • refresh_token:通过以上授权获得的刷新令牌来获取新的令牌。
可以用 @EnableAuthorizationServer … 阅读全文

Kubernetes主机和容器的监控方案

  categories:资料  author:

本文是有容云后端开发工程师 李强 7月27日在微信群分享内容整理

摘要:随着Docker容器云的广泛应用,大量的业务软件运行在容器中,这使得对docker容器的监控越来越重要。传统的监控系统大多数是针对物理机或者虚拟机设计的,而容器的特点不同与传统的物理机或者虚拟机,如果还是采用传统的监控系统,则会增加监控复杂程度,那么如何对容器进行监控呢?

大家晚上好,今天很高兴能在这里和大家一起交流和分享在工作中的一些经验和总结。都知道监控在运维体系乃至产品的整个生命中期都是重要的一个环节,针对不同的应用场景,监控方案也会有很大的不同。本次就和大家分享一下我在开发我们公司新产品ufleet的监控模块时的一些技术总结,如果有错误的地方,欢迎大家指出。主要内容有:

1.数据的采集方式

2.监控原理

3.容器的监控方案

4.kubernetes上的主机和容器的监控

5.监控工具的对比

一个完整的监控体系包括:采集数据、分析存储数据、展示数据、告警以及自动化处理、监控工具自身的安全机制,接下来会对数据的采集和监控原理深入讲解,其他部分会在一些架构中穿插讲解。

一 、数据的采集方式

1.命令行方式。比如在linux系统上使用top,vmstat,netstat写一些shell脚本进行数据的采集,再把数据存储在文本文件中进行处理。

2.嵌入式。通过在进程中运行agent的方式获取应用的状态。如目前的APM产品都是通过将监控工具嵌入到应用内部进行数据采集。

3.主动输出。提前在应用中埋点,应用主动上报。比如一些应用系统的业务状态,可以通过在日志中主动输出状态用于采集。

4.旁路式。通过外部获取的方式采集数据。比如对网站url的探测,模拟业务的报文 ,对服务器的ping,流量的监控。可以通过在交换机上将流量进行端口复制,将源始流量复制到另一个端口后再进行处理,这样这业务系统是完全没有侵入。

5.远程接入。通过对应用进程接口调用获取应用的状态。比如使用JMX的方式连接到java进程中,对进程的状态进行采集。

6.入侵式。不同于嵌入式,入侵式的agent是独立运行的进程,而不是运行在进程中。这个目前监控工具比较常用的方式,比如zabbix,在主机上运行一个进程进行相关数据的采集。

二、监控原理

具体监控指标总结如下:

  • 首先是容器本身资源使用情况:cpu,内存,网络,磁盘
  • 物理机的资源使用情况:cpu,内存,网络,磁盘
  • 物理机上容器镜像情况,名字,大小,版本。

1.主机的监控

(1)Cpu数据

使用top命令可以查看当前cpu使用情况,源文件来自/proc/stat

采样两个足够短的时间间隔的Cpu快照,分别记作t1,t2,其中t1、t2的结构均为:

(user、nice、system、idle、iowait、irq、softirq、stealstolen、guest)的9元组;

a) 计算总的Cpu时间片totalCpuTime

  • 把第一次的所有cpu使用情况求和,得到s1;
  • 把第二次的所有cpu使用情况求和,得到s2;
  • s2 – s1得到这个时间间隔内的所有时间片,即totalCpuTime = j2
阅读全文

Kunbernetes-基于Nexus构建私有镜像仓库

  categories:资料  author:

1、 安装Nexus

Nexus是Sonatype提供的仓库管理平台,Nuexus Repository OSS3能够支持Maven、npm、Docker、YUM、Helm等格式数据的存储和发布;并且能够与Jekins、SonaQube和Eclipse等工具进行集成。Nexus支持作为宿主和代理存储库的Docker存储库,可以直接将这些存储库暴露给客户端工具;也可以以存储库组的方式暴露给客户端工具,存储库组是合并了多个存储库的内容的存储库,能够通过一个URL将多个存储库暴露给客户端工具,从而便于用户的使用。通过nexus自建能够有效减少访问获取镜像的时间和对带宽使用,并能够通过自有的镜像仓库共享企业自己的镜像。在本文中,采用Docker模式安装部署Nexus。

首先,通过mkdir创建一个目录,用于为Nexus提供存储的空间。

$ mkdir {path}/nexus-data && chown -R 200 {path}/nexus-data

接着,就可以通过sonatype/nexus3镜像启动nexus3的容器化应用了。通过如下命令启动的nexus将对外暴露8081端口,并容器的持久化数据通过会存储在上述创建的空间中。在容器运行后,用户将可以通过http://{host_ip}:8081访问nexus应用,其中{host_ip}为容器所部署的宿主机的IP地址。

$ docker run -d -p 8081:8081 --name nexus -
阅读全文

Kubernetes-核心资源之Pod

  categories:资料  author:

1Pod概述

在Kubernetes集群中,Pod是所有业务类型的基础,它是一个或多个容器的组合。这些容器共享存储、网络和命名空间,以及如何运行的规范。在Pod中,所有容器都被同一安排和调度,并运行在共享的上下文中。对于具体应用而言,Pod是它们的逻辑主机,Pod包含业务相关的多个应用容器。Kubernetes不只是支持Docker容器,它也支持其他容器。Pod 的上下文可以理解成多个linux命名空间的联合:

  • PID 命名空间(同一个Pod中应用可以看到其它进程)
  • 网络 命名空间(同一个Pod的中的应用对相同的IP地址和端口有权限)
  • IPC 命名空间(同一个Pod中的应用可以通过VPC或者POSIX进行通信)
  • UTS 命名空间(同一个Pod中的应用共享一个主机名称)

一个Pod的共享上下文是Linux命名空间、cgroups和其它潜在隔离内容的集合。 在Pod中,容器共享一个IP地址和端口空间,它们可以通过localhost发现彼此。在同一个Pod中的容器,可以使用System V 或POSIX信号进行标准的进程间通信和共享内存。在不同Pod中的容器,拥有不同的IP地址,因此不能够直接在进程间进行通信。容器间通常使用Pod IP地址进行通信。在一个Pod中的应用于口访问共享的存储卷,它被定为为Pod的一部分,可以被挂接至每一个应用文件系统。与独立的应用容器一样,Pod是一个临时的实体,它有着自己的生命周期。在Pod被创建时,会被指派一个唯一的ID,并被调度到Node中,直到Pod被终止或删除。如果Pod所在的Node宕机,给定的Pod(即通过UID定义)不会被重新调度。相反,它将被完全相同的Pod所替代。这所说的具有和Pod相关生命周期的情况,例如存储卷,是说和Pod存在的时间一样长。如果Pod被删除,即使完全相同的副本被创建,则相关存储卷等也会被删除,并会Pod创建一个新的存储卷等。Pod本身就没有打算作为持久化的实体,在调度失败、Node失败和获取其它退出(缺少资源或者Node在维护)情况下,Pod都会被删除。一般来说,用户不应该直接创建Pod,即是创建单个的Pod也应该通过控制器创建。在集群范围内,控制器为Pod提供自愈能力,以及副本和部署管理。

一个多容器的Pod会包含一个文件拉取器和一个web服务器,此web服务器使用一个持久化存储卷来在容器中共享存储。

网络:每一个Pod都会被指派一个唯一的Ip地址,在Pod中的每一个容器共享网络命名空间,包括Ip地址和网络端口。在同一个Pod中的容器可以同locahost进行互相通信。当Pod中的容器需要与Pod外的实体进行通信时,则需要通过端口等共享的网络资源。

存储:Pod能够被指定共享存储卷的集合,在Pod中所有的容器能够访问共享存储卷,允许这些容器共享数据。存储卷也允许在一个Pod持久化数据,以防止其中的容器需要被重启。

2Pod的工作方式

在Kubernetes中一般不会直接创建一个独立的Pod,这是因为Pod是临时存在的一个实体。当直接创建一个独立的Pod时,如果缺少资源或者所被调度到的Node失败,则Pod会直接被删除。这里需要注意的是,重起Pod和重起Pod中的容器不是一个概念,Pod自身不会运行,它只是容器所运行的一个环境。Pod本身没有自愈能力,如果Pod所在的Node失败,或者如果调度操作本身失败,则Pod将会被删除;同样的,如果缺少资源,Pod也会失败。Kubernetes使用高层次的抽象,即控制器来管理临时的Pod。通过控制器能够创建和管理多个Pod,并在集群范围内处理副本、部署和提供自愈能力。例如,如果一个Node失败,控制器可以自动的在另外一个节点上部署一个完全一样的副本。控制器是Pod模板来创建Pod,Pod的控制器包括:

  • Deployment
  • StatefulSet
  • DaemonSet

Pod模板是一个被包含在其它对象(例如:Deployment、StatefuleSet、DaemonSet等)中的Pod规格。控制使用Pod模板创建实际的Pod,下面是Pod模板的一个示例:

2.1

阅读全文

Kakfa utils源代码分析

  categories:资料  author:

Kafka.utils,顾名思义,就是一个工具套件包,里面的类封装了很多常见的功能实现——说到这里,笔者有一个感触:当初为了阅读Kafka源代码而学习了Scala语言,本以为Kafka的实现会用到很多函数编程(Functional Programming, FP),结果目前来看,大部分还是很朴素地以面向对象的方式来实现的,只有很少一部分集合的处理使用诸如map,reduce这样的FP方式。不能不说有点小小的遗憾。——当然也许后面Kafka的核心代码中会看到更多FP的身影。

下图就是kafka.utils包的所有代码:

因为很难像其他包代码之间有逻辑关系,我们就一个一个说吧:
一、Annotations.scala
这个源代码文件中定义了3个注释类:threadsafe、nonthreadsafe和immutable。它们都继承了StaticAnnotation——Scala提供的StaticAnnotation类似于Java中的@Target(ElementType.TYPE),因此主要的作用域是类和接口。具体到这三个元注解(meta-annotation),很容易知道它们的含义:分别标记线程安全、非线程安全和不可变性。Kafka开发中常用到的SimpleConsumer类就是被标记为@threadsafe的。
二. CommandLineUtils.scala
这个文件使用JOpt Simple库负责解析命令行参数,具体使用用法参见官网:http://pholser.github.io/jopt-simple/
Kafka在这个文件中提供了一个object:CommandLineUtils。具体包含的方法有:
1. printUsageAndDie: 打印命令使用方法并终止程序
2. checkRequiredArgs:使用Jopts Simple的API(以下皆同)检查是否缺少必要参数
3. checkInvalidArgs:检查指定的参数是否存在不兼容情况,即哪些参数不能同时使用
4. parseKeyValueArgs:解析key=value格式的参数对,并返回一个Properties对象
三、Crc32.scala
这个类就是CRC32校验码的实现类,来自于Hadoop提供的PureJavaCrc32类——CRC32校验码的纯Java实现版本。这个类很长,里面有很多位操作,由于CRC32计算不在本次研究范围,所以就了解到这吧。
四、DelayedItem.scala
这个类是个泛型类,实现了java.util.Delayed接口。用于标记那些在给定延迟时间之后执行的对象。该类接收一个泛型T,一个延迟时间以及延迟时间的单位。另外,实现这个接口的话必须要实现一个compareTo和getDelay方法。
1. getDelay: 计算距离触发时间还剩下多长时间
2. compareTo: 比较2个Delayed对象的延迟触发时间
五、FileLock.scala
顾名思义,FileLock就是一个文件锁,它的构造函数接收一个文件对象,并总是先尝试创建这个文件(如果不存在的话),然后创建一个FileChannel对象对该文件进行随机读写操作。同时创建一个java.nio.channel.FlieLock文件锁对象用于实现下面的方法:
1. lock: 对文件加锁,如果该文件上已有锁抛出异常
2. tryLock: 尝试对文件加锁,如果成功返回true,否则返回false… 阅读全文



快乐成长 每天进步一点点      京ICP备18032580号-1