以hive为例说明程序的三种使用方式

一、hive交互shell，$HIVE_HOME/bin/hive

类似于linux的shell，比如mysql也有交互shell

二、shell命令，比如 $HIVE_HOME/bin/hive -e 'sql'

                                  $HIVE_HOME/bin/hive -f filename

三、hive thrift服务

1、启动为前台$HIVE_HOME/bin/hiveserver2

2、启动为后台：nohup $HIVE_HOME/bin/hiveserver2 1>/var/log/hiveserver.log 2>/var/log/hiveserver.err &

启动成功后，可以在别的节点上用beeline去连接

方式（1）

hive/bin/beeline 回车，进入beeline的命令界面

输入命令连接hiveserver2

beeline> !connect jdbc:hive2://hostname:10000

（hostname是hiveserver2所启动的那台主机名，端口默认是10000）

提示用户名 root 密码为空

用beeline连接的好处是输出结果会对齐

方式（2）

或者启动就连接：

bin/beeline -ujdbc:hive2://mini1:10000 -n hadoop

什么是thrift？这要从RPC框架说起

RPC框架包含四个部分：

1.通信模型（网络通信框架）：假设通信的为A机器与B机器，A与B之间有通信模型，在Java中一般基于BIO或NIO；。

2.过程（服务）定位：使用给定的通信方式，与确定IP与端口及方法名称确定具体的过程或方法；

3.远程代理对象：本地调用的方法(服务)其实是远程方法的本地代理，因此可能需要一个远程代理对象，对于Java而言，远程代理对象可以使用Java的动态代理对象实现，封装了调用远程方法调用；

4.序列化协议，将对象名称、方法名称、参数等对象信息进行网络传输需要转换成二进制传输，这里可能需要不同的序列化技术方案。如:protobuf，Arvo等。

其中2.3两项可以概括为“调用控制协议”

完成RPC 需要两个协议，“序列化协议”和“调用控制协议”，还需要一个网络通信框架，而Netty就是一个网络通信框架。

常见例子举例：

1.zeroC ICE，拥有自己的网络通信框架 + ICE 调用控制协议和对象序列化协议,同时也涵盖了服务组件的抽象部署等功能。

2.thrift，有自己的网络通信框架+thrift 对象序列化协议+thrift 调用控制协议

3.probuff，只是 对象序列化协议

4.XMLRPC ，jsonRPC，常见的语境是利用HTTP协议作为调用控制协议,XML 和 JSON 作为对象序列化之后的格式。

5. Netty只是网络通信框架,目的是让你用最少的代码构建出足够支撑网络通信的功能，它是基于JAVA的NIO进行封装后的产品。

5、dubbo，基于netty的rpc框架。

6、hadoop中也有自己的rpc框架，比如spark中的rpc就是基于netty的。

Thrift是Facebook于2007年开发的跨语言的rpc服框架，提供多语言的编译功能，并提供多种服务器工作模式；用户通过Thrift的IDL（接口定义语言）来描述接口函数及数据类型，然后通过Thrift的编译环境生成各种语言类型的接口文件，用户可以根据自己的需要采用不同的语言开发客户端代码和服务器端代码。

nohup和&：

nohup是永久执行
&是指在后台运行
运行 nohup --help
Run COMMAND, ignoring hangup signals. 可以看到是“运行命令，忽略挂起信号”
就是指，用nohup运行命令可以使命令永久的执行下去，和用户终端没有关系，例如我们断开SSH连接都不会影响他的运行，注意了nohup没有后台运行的意思；&才是后台运行
&是指在后台运行，但当用户退出(挂起)的时候，命令自动也跟着退出
那么，我们可以巧妙的吧他们结合起来用就是
nohup COMMAND &
这样就能使命令永久的在后台执行
举个例子nohup tail -f nohup.out
然后退出登录，再连接，用ps -ef 你会还能看到在运行
ps -ef
root      3457     1  0 18:20 ?        00:00:00 tail -f nohup.out
另外，nohup执行后，会产生日志文件nohup.out，把命令的执行中的消息保存到这个文件中，一般在当前目录下，如果当前目录不可写，那么自动保存到执行这个命令的用户的home目录下，例如root的话就保存在/root/下

另外nohup $HIVE_HOME/bin/hiveserver2 1>/var/log/hiveserver.log 2>/var/log/hiveserver.err &，此条命令中的1指的是标准输出，2指的是标准错误。如下为输出重定向详解。

./command.sh > output

这其中的>就是标准输出符号，其实是 1>output 的缩写

./command.sh 2> output

这里的2>就是将标准错误输出到output文件里。

而0< 则是标准输入了。

nohup ./command.sh > output 2>&1 &

中间的 2>&1的意思是把标准错误2重定向到标准输出中1，而标准输出又导入文件output里面，所以结果是标准错误和标准输出都导入文件output里面了。

至于为什么需要将标准错误重定向到标准输出的原因，那就归结为标准错误没有缓冲区，而stdout有。这就会导致 >output 2>output 文件output被两次打开，而stdout和stderr将会竞争覆盖，这肯定不是我门想要的.这就是为什么有人会写成：nohup ./command.sh >output 2>output出错的原因了。

最后谈一下/dev/null文件的作用

这是一个无底洞，任何东西都可以定向到这里，但是却无法打开。

所以一般很大的stdou和stderr当你不关心的时候可以利用stdout和stderr定向到这里>./command.sh >/dev/null 2>&1

为什么命令结尾加&会使程序在后台运行？这牵涉到shell脚本的实现原理。

Linux系统提供给用户的最重要的系统程序是Shell命令语言解释程序。它不属于内核部分，而是在核心之外，以用户态方式运行。其基本功能是解释并执行用户打入的各种命令，实现用户与Linux核心的接口。系统初启后，核心为每个终端用户建立一个进程去执行Shell解释程序。它的执行过程基本上按如下步骤： (1)读取用户由键盘输入的命令行。 (2)分析命令，以命令名作为文件名，并将其它参数改造为系统调用execve( )内部处理所要求的形式。 (3)终端进程调用fork( )建立一个子进程。 (4)终端进程本身用系统调用wait4( )来等待子进程完成（如果是后台命令，则不等待）。当子进程运行时调用execve( )，子进程根据文件名（即命令名）到目录中查找有关文件（这是命令解释程序构成的文件），将它调入内存，执行这个程序（解释这条命令）。 (5)如果命令末尾有&号（后台命令符号），则终端进程不用系统调用wait4( )等待，立即发提示符，让用户输入下一个命令，转⑴。如果命令末尾没有&号，则终端进程要一直等待，当子进程（即运行命令的进程）完成处理后终止，向父进程（终端进程）报告，此时终端进程醒来，在做必要的判别等工作后，终端进程发提示符，让用户输入新的命令，重复上述处理过程。

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

Linux系统的shell作为操作系统的外壳，为用户提供使用操作系统的接口。它是命令语言、命令解释程序及程序设计语言的统称。 shell是用户和Linux内核之间的接口程序，如果把Linux内核想象成一个球体的中心，shell就是围绕内核的外层。当从shell或其他程序向Linux传递命令时，内核会做出相应的反应。 shell是一个命令语言解释器，它拥有自己内建的shell命令集，shell也能被系统中其他应用程序所调用。用户在提示符下输入的命令都由shell先解释然后传给Linux核心。 有一些命令，比如改变工作目录命令cd，是包含在shell内部的。还有一些命令，例如拷贝命令cp和移动命令rm，是存在于文件系统中某个目录下的单独的程序。对用户而言，不必关心一个命令是建立在shell内部还是一个单独的程序。 shell首先检查命令是否是内部命令，若不是再检查是否是一个应用程序（这里的应用程序可以是Linux本身的实用程序，如ls和rm，也可以是购买的商业程序，如xv，或者是自由软件，如emacs）。然后shell在搜索路径里寻找这些应用程序（搜索路径就是一个能找到可执行程序的目录列表，也就是环境变量$path）。如果键入的命令不是一个内部命令并且在路径里没有找到这个可执行文件，将会显示一条错误信息。如果能够成功找到命令，该内部命令或应用程序将被分解为系统调用并传给Linux内核。