Sudo本地提权漏洞安全预警

运维技术OS小编 发表了文章 • 0 个评论 • 152 次浏览 • 2017-05-31 15:53 • 来自相关话题

linux 系统sudo存在本地提权高危漏洞,本地攻击者可以利用此漏洞提权至root。请检查您所使用的sudo是否在影响范围之内,并及时进行升级。
影响范围

       Centos 5、6、7

       Redhat Enterprise Linux 5、6、7

       Ubuntu 14.04、15.04、16.04、16.10、17.04、17.10

       Debian wheezy、jessie、jessie、sid

       SUSE Linux Enterprise Software Development Kit 12 SP1、SP2

       SUSE Linux Enterprise Server for SAP 12

       SUSE Linux Enterprise Server 12 SP1 、SP2

       SUSE Linux Enterprise Server 12-LTSS

       SUSE Linux Enterprise Desktop 12 SP1 、SP2

       SUSE Linux Enterprise Server for Raspberry Pi 12 SP2

       OpenSuse
 
修复方案

       【CentOS/RHEL】

       yum update

       或 yum install sudo

       【Ubuntu/Debian】

       sudo apt update $ sudo apt upgrade

       或sudo apt-get install sudo

       备注:部分官方版本还未发布可用修复包,请时刻关注,官网发布后UCloud软件源也会在第一时间更新。

       【修复版本】

       1、Centos /Redhat

       Centos /RHEL 7 :1.8.6p7-22.el7_3

       Centos /RHEL 6 :1.8.6p3-28.el6_9

       Centos /RHEL 5 :1.7.2p1-30.el5_11

       2、Ubuntu

       Ubuntu 14.04:1.8.9p5-1ubuntu1.4

       Ubuntu 16.04:1.8.16-0ubuntu1.4

       Ubuntu 16.10:1.8.16-0ubuntu3.2

       Ubuntu 17.04:1.8.19p1-1ubuntu1.1

       3、Debian

       Debian wheezy:1.8.5p2-1+nmu3+deb7u3

       Debian jessie:1.8.10p3-1+deb8u4

       4、SUSE /OpenSuse

       1.8.10p3-2.11.1

       1.8.10p3-10.5.1
 
漏洞详情

       CVE-2017-1000367:当确定tty时,Sudo没有正确解析/ proc / [pid] / stat的内容,本地攻击者可能会使用此方法来覆盖文件系统上的任何文件,从而绕过预期权限或获取root shell。

       sudo版本查看方法:

       Centos /RHEL /SUSE /OpenSuse:rpm -qa|grep sudo

       Ubuntu /Debian:dpkg -l sudo 查看全部
linux 系统sudo存在本地提权高危漏洞,本地攻击者可以利用此漏洞提权至root。请检查您所使用的sudo是否在影响范围之内,并及时进行升级。
影响范围

       Centos 5、6、7

       Redhat Enterprise Linux 5、6、7

       Ubuntu 14.04、15.04、16.04、16.10、17.04、17.10

       Debian wheezy、jessie、jessie、sid

       SUSE Linux Enterprise Software Development Kit 12 SP1、SP2

       SUSE Linux Enterprise Server for SAP 12

       SUSE Linux Enterprise Server 12 SP1 、SP2

       SUSE Linux Enterprise Server 12-LTSS

       SUSE Linux Enterprise Desktop 12 SP1 、SP2

       SUSE Linux Enterprise Server for Raspberry Pi 12 SP2

       OpenSuse
 
修复方案

       【CentOS/RHEL】

       yum update

       或 yum install sudo

       【Ubuntu/Debian】

       sudo apt update $ sudo apt upgrade

       或sudo apt-get install sudo

       备注:部分官方版本还未发布可用修复包,请时刻关注,官网发布后UCloud软件源也会在第一时间更新。

       【修复版本】

       1、Centos /Redhat

       Centos /RHEL 7 :1.8.6p7-22.el7_3

       Centos /RHEL 6 :1.8.6p3-28.el6_9

       Centos /RHEL 5 :1.7.2p1-30.el5_11

       2、Ubuntu

       Ubuntu 14.04:1.8.9p5-1ubuntu1.4

       Ubuntu 16.04:1.8.16-0ubuntu1.4

       Ubuntu 16.10:1.8.16-0ubuntu3.2

       Ubuntu 17.04:1.8.19p1-1ubuntu1.1

       3、Debian

       Debian wheezy:1.8.5p2-1+nmu3+deb7u3

       Debian jessie:1.8.10p3-1+deb8u4

       4、SUSE /OpenSuse

       1.8.10p3-2.11.1

       1.8.10p3-10.5.1
 
漏洞详情

       CVE-2017-1000367:当确定tty时,Sudo没有正确解析/ proc / [pid] / stat的内容,本地攻击者可能会使用此方法来覆盖文件系统上的任何文件,从而绕过预期权限或获取root shell。

       sudo版本查看方法:

       Centos /RHEL /SUSE /OpenSuse:rpm -qa|grep sudo

       Ubuntu /Debian:dpkg -l sudo

Prometheus时间序列监控方案

开源项目push 发表了文章 • 0 个评论 • 145 次浏览 • 2017-05-26 00:00 • 来自相关话题

最近一直在折腾时序类型的数据库,经过一段时间项目应用,觉得十分不错。而Prometheus又是刚刚推出不久的开源方案,中文资料较少,所以打算写一系列应用的实践过程分享一下。
 

Prometheus 是什么?

Prometheus是一套开源的监控&报警&时间序列数据库的组合,起始是由SoundCloud公司开发的。随着发展,越来越多公司和组织接受采用Prometheus,社会也十分活跃,他们便将它独立成开源项目,并且有公司来运作。google SRE的书内也曾提到跟他们BorgMon监控系统相似的实现是Prometheus。现在最常见的Kubernetes容器管理系统中,通常会搭配Prometheus进行监控。

Prometheus 的优点

非常少的外部依赖,安装使用超简单已经有非常多的系统集成 例如:docker HAProxy Nginx JMX等等服务自动化发现直接集成到代码设计思想是按照分布式、微服务架构来实现的
 

Prometheus 的特性

自定义多维度的数据模型非常高效的存储 平均一个采样数据占 ~3.5 bytes左右,320万的时间序列,每30秒采样,保持60天,消耗磁盘大概228G。强大的查询语句轻松实现数据可视化
 
等等, 相对于Graphite这种产品,还是有不少优点的。最让我觉得不错的是非常优秀的写性能和读取性能,它数据结构实现和OpenTSDB是有相似之处,有兴趣可以看看这个文档:解密OpenTSDB的表存储优 。

Prometheus 的系统架构





它的服务过程是这样的 Prometheus daemon 负责定时去目标上抓取 metrics(指标) 数据,每个抓取目标需要暴露一个http服务的接口给它定时抓取。

Prometheus支持通过配置文件、文本文件、zookeeper、Consul、DNS SRV lookup等方式指定抓取目标。
Alertmanager 是独立于Prometheus的一个组件,可以支持Prometheus的查询语句,提供十分灵活的报警方式。
Prometheus支持很多方式的图表可视化,例如十分精美的Grafana,自带的Promdash,以及自身提供的模版引擎等等,还提供HTTP API的查询方式,自定义所需要的输出。

PushGateway这个组件是支持Client主动推送 metrics 到PushGateway,而Prometheus只是定时去Gateway上抓取数据。

如果有使用过statsd的用户,则会觉得这十分相似,只是statsd是直接发送给服务器端,而Prometheus主要还是靠进程主动去抓取。

Prometheus 的数据模型

Prometheus 从根本上所有的存储都是按时间序列去实现的,相同的 metrics(指标名称) 和 label(一个或多个标签) 组成一条时间序列,不同的label表示不同的时间序列。为了支持一些查询,有时还会临时产生一些时间序列存储。
 
metrics name & label 指标名称和标签
每条时间序列是由唯一的 指标名称 和 一组 标签 (key=value)的形式组成。
指标名称 一般是给监测对像起一名字,例如 http_requests_total 这样,它有一些命名规则,可以包字母数字_之类的的。

通常是以应用名称开头_监测对像_数值类型_单位这样, 例如:
push_totaluserlogin_mysql_duration_secondsapp_memory_usage_bytes
 
标签 就是对一条时间序列不同维度的识别了,例如 一个http请求用的是POST还是GET,它的endpoint是什么,这时候就要用标签去标记了, 最终形成的标识便是这样了:http_requests_total{method="POST",endpoint="/api/tracks"}记住,针对http_requests_total这个metrics name 无论是增加标签还是删除标签都会形成一条新的时间序列。
查询语句就可以跟据上面标签的组合来查询聚合结果了。

如果以传统数据库的理解来看这条语句,则可以考虑 http_requests_total是表名,标签是字段,而timestamp是主键,还有一个float64字段是值了。(Prometheus里面所有值都是按float64存储)。

Prometheus 的四种数据类型

Counter:
Counter 用于累计值,例如 记录 请求次数、任务完成数、错误发生次数。一直增加,不会减少。重启进程后,会被重置。
例如:http_response_total{method="GET",endpoint="/api/tracks"} 100
10秒后抓取 http_response_total{method="GET",endpoint="/api/tracks"} 100
Gauge:
Gauge 常规数值,例如 温度变化、内存使用变化。可变大,可变小。重启进程后,会被重置
例如: memory_usage_bytes{host="master-01"} 100 < 抓取值
memory_usage_bytes{host="master-01"} 30
memory_usage_bytes{host="master-01"} 50
memory_usage_bytes{host="master-01"} 80 < 抓取值
Histogram:
Histogram 可以理解为柱状图的意思,常用于跟踪事件发生的规模,例如:请求耗时、响应大小。它特别之处是可以对记录的内容进行分组,提供 count 和 sum 全部值的功能。
例如:{小于10=5次,小于20=1次,小于30=2次},count=7次,sum=7次的求和值



 
Summary:
Summary和Histogram十分相似,常用于跟踪事件发生的规模,例如:请求耗时、响应大小。同样提供 count 和 sum 全部值的功能。例如:count=7次,sum=7次的值求值它提供一个quantiles的功能,可以按%比划分跟踪的结果。例如:quantile取值0.95,表示取采样值里面的95%数据。
 
分享阅读原文:http://www.cnblogs.com/vovlie/p/Prometheus_CONCEPTS.html  查看全部
最近一直在折腾时序类型的数据库,经过一段时间项目应用,觉得十分不错。而Prometheus又是刚刚推出不久的开源方案,中文资料较少,所以打算写一系列应用的实践过程分享一下。
 


Prometheus 是什么?


Prometheus是一套开源的监控&报警&时间序列数据库的组合,起始是由SoundCloud公司开发的。随着发展,越来越多公司和组织接受采用Prometheus,社会也十分活跃,他们便将它独立成开源项目,并且有公司来运作。google SRE的书内也曾提到跟他们BorgMon监控系统相似的实现是Prometheus。现在最常见的Kubernetes容器管理系统中,通常会搭配Prometheus进行监控。


Prometheus 的优点


  • 非常少的外部依赖,安装使用超简单
  • 已经有非常多的系统集成 例如:docker HAProxy Nginx JMX等等
  • 服务自动化发现
  • 直接集成到代码
  • 设计思想是按照分布式、微服务架构来实现的

 


Prometheus 的特性


  • 自定义多维度的数据模型
  • 非常高效的存储 平均一个采样数据占 ~3.5 bytes左右,320万的时间序列,每30秒采样,保持60天,消耗磁盘大概228G。
  • 强大的查询语句
  • 轻松实现数据可视化

 
等等, 相对于Graphite这种产品,还是有不少优点的。最让我觉得不错的是非常优秀的写性能和读取性能,它数据结构实现和OpenTSDB是有相似之处,有兴趣可以看看这个文档:解密OpenTSDB的表存储优 。


Prometheus 的系统架构


prometheus.png

它的服务过程是这样的 Prometheus daemon 负责定时去目标上抓取 metrics(指标) 数据,每个抓取目标需要暴露一个http服务的接口给它定时抓取。

Prometheus支持通过配置文件、文本文件、zookeeper、Consul、DNS SRV lookup等方式指定抓取目标。
Alertmanager 是独立于Prometheus的一个组件,可以支持Prometheus的查询语句,提供十分灵活的报警方式。
Prometheus支持很多方式的图表可视化,例如十分精美的Grafana,自带的Promdash,以及自身提供的模版引擎等等,还提供HTTP API的查询方式,自定义所需要的输出。

PushGateway这个组件是支持Client主动推送 metrics 到PushGateway,而Prometheus只是定时去Gateway上抓取数据。

如果有使用过statsd的用户,则会觉得这十分相似,只是statsd是直接发送给服务器端,而Prometheus主要还是靠进程主动去抓取。


Prometheus 的数据模型


Prometheus 从根本上所有的存储都是按时间序列去实现的,相同的 metrics(指标名称) 和 label(一个或多个标签) 组成一条时间序列,不同的label表示不同的时间序列。为了支持一些查询,有时还会临时产生一些时间序列存储。
 
metrics name & label 指标名称和标签
每条时间序列是由唯一的 指标名称 和 一组 标签 (key=value)的形式组成。
指标名称 一般是给监测对像起一名字,例如 http_requests_total 这样,它有一些命名规则,可以包字母数字_之类的的。

通常是以应用名称开头_监测对像_数值类型_单位这样, 例如:
  1. push_total
  2. userlogin_mysql_duration_seconds
  3. app_memory_usage_bytes

 
标签 就是对一条时间序列不同维度的识别了,例如 一个http请求用的是POST还是GET,它的endpoint是什么,这时候就要用标签去标记了, 最终形成的标识便是这样了:
http_requests_total{method="POST",endpoint="/api/tracks"}
记住,针对http_requests_total这个metrics name 无论是增加标签还是删除标签都会形成一条新的时间序列。
查询语句就可以跟据上面标签的组合来查询聚合结果了。

如果以传统数据库的理解来看这条语句,则可以考虑 http_requests_total是表名,标签是字段,而timestamp是主键,还有一个float64字段是值了。(Prometheus里面所有值都是按float64存储)。


Prometheus 的四种数据类型


Counter:
  • Counter 用于累计值,例如 记录 请求次数、任务完成数、错误发生次数。
  • 一直增加,不会减少。
  • 重启进程后,会被重置。

例如:http_response_total{method="GET",endpoint="/api/tracks"} 100
10秒后抓取 http_response_total{method="GET",endpoint="/api/tracks"} 100

Gauge:
  • Gauge 常规数值,例如 温度变化、内存使用变化。
  • 可变大,可变小。
  • 重启进程后,会被重置

例如: memory_usage_bytes{host="master-01"} 100 < 抓取值
memory_usage_bytes{host="master-01"} 30
memory_usage_bytes{host="master-01"} 50
memory_usage_bytes{host="master-01"} 80 < 抓取值

Histogram:
  • Histogram 可以理解为柱状图的意思,常用于跟踪事件发生的规模,例如:请求耗时、响应大小。它特别之处是可以对记录的内容进行分组,提供 count 和 sum 全部值的功能。

例如:{小于10=5次,小于20=1次,小于30=2次},count=7次,sum=7次的求和值
sum.png

 
Summary:
  • Summary和Histogram十分相似,常用于跟踪事件发生的规模,例如:请求耗时、响应大小。同样提供 count 和 sum 全部值的功能。
  • 例如:count=7次,sum=7次的值求值
  • 它提供一个quantiles的功能,可以按%比划分跟踪的结果。例如:quantile取值0.95,表示取采样值里面的95%数据。

 
分享阅读原文:http://www.cnblogs.com/vovlie/p/Prometheus_CONCEPTS.html 

Hive安装配置

大数据/云计算koyo 发表了文章 • 0 个评论 • 109 次浏览 • 2017-05-25 21:52 • 来自相关话题

相比较于 Apache Hive 而言,Cloudera CDH 将 Hive 拆分为一个个独立的服务,如 hive,metastore,hivesever2等。如果在安装配置之前不能弄清楚各个部分的关系,那么安装过程中出现的各种问题也就不能针对性地解决。因此首先分享一下我个人对于hive,metastore 以及 hiveserve2 之间关系的理解。
 
使用 yum 安装 Cloudera CDH Hive 需要分别安装hive,hive-metastore 和 hive-sever2。其中hive是必须安装的,hive-metastore 和 hive-sever2 则根据要求选择安装。
 
启动 hive 之后出现的 CLI 是查询任务的入口,CLI 提交任务给 DriverDriver 接收到任务后调用 Compiler,Executor,Optimizer 将 SQL 语句转化为可以在 Hadoop 集群上执行的 MapReduce 任务Compiler,Executor 从 metastore 获取所需要的元数据信息hivesever2 作为 hivesever 的改进版本,最主要的变化在于提供了全新的命令行窗口 BeeLine。
 
1、使用 yum 安装 Hive 组件
Hive安装:
 
yum install hive
yum install hive-metastore
yum install hive-server2

2、配置 Hive
创建Hive相关文件的存储路径并更改目录权限
hdfs dfs -mkdir -p /usr/hive/warehouse
hdfs dfs -mkdir -p /usr/hive/tmp
hdfs dfs -mkdir -p /usr/hive/log
hdfs dfs -chmod g+w /usr/hive/warehouse
hdfs dfs -chmod g+w /usr/hive/tmp
hdfs dfs -chmod g+w /usr/hive/log配置环境变量
vim /usr/lib/hive/conf/hive-env.shexport HADOOP_HOME=/usr/lib/hadoop
export HIVE_CONF_DIR=/usr/lib/hive/conf
3、配置 MySQL
Metastore默认使用内嵌的Derby数据库存储元数据信息,同时支持多种数据库可做拓展。官网推荐使用MySQL和PostgreSQL,这里只列出MySQL的具体配置过程,有关PostgreSQL的配置过程可查阅官网。

CentOS 7 默认yum源并未包含mysql,需要首先配置repo源:
wget http://repo.mysql.com/mysql-community-release-el7-5.noarch.rpm安装mysql-community-release-el7-5.noarch.rpm包
rpm -ivh mysql-community-release-el7-5.noarch.rpm安装mysql并启动mysql
yum install mysql-server为当前用户分配mysql权限并重启mysql服务
sudo chown -R root:root /var/lib/mysql
service mysqld restart设置root密码
mysql -u rootmysql > use mysql;
mysql > update user set password=password('123456') where user='root';
mysql > exit;创建用于存储元数据的数据库和操作的用户
mysql -uroot -p123456mysql> CREATE DATABASE metastore;
mysql> USE metastore;
mysql> SOURCE /usr/lib/hive/scripts/metastore/upgrade/mysql/hive-schema-0.12.0.mysql.sql;
mysql> CREATE USER 'hive'@'metastore' IDENTIFIED BY '123';
mysql> REVOKE ALL PRIVILEGES, GRANT OPTION FROM 'hive'@'metastorehost';
mysql> GRANT ALL ON metastore.* TO 'hive'@'metastorehost' IDENTIFIED BY 'hive';
mysql> GRANT ALL ON metastore.* TO 'hive'@'%' IDENTIFIED BY 'hive';
mysql> FLUSH PRIVILEGES;
mysql> ALTER DATABASE metastore CHARACTER SET latin1;
mysql> quit;
4、配置 Hive Metastore
内嵌模式是metastore 的默认模式,使用 Derby 存储元数据信息,但不支持多用户并发对metastore 操作,不建议在实际环境中使用。这里不再赘述。

下面的本地模式和远程模式均需要使用JDBC才能完成metastore和mysql的通信,需要先添加JDBC驱动包。
$ yum install mysql-connector-java
$ ln -s /usr/share/java/mysql-connector-java.jar /usr/lib/hive/lib/mysql-connector-java.jar

所谓的本地模式和远程模式,指的是metastore和hiveserver的位置关系,而和数据库的位置无关,这一点尤为重要。

 
本地模式:
metastore service 和 HiveServer 运行在同一进程,但是数据库运行在独立的进程,也可以将数据库安装在独立的主机上。内嵌的 metastore 服务和数据库通过 JDBC 通信。

配置方式如下:
vim /usr/lib/hive/conf/hive-site.xml添加如下内容
<property>
<name>javax.jdo.option.ConnectionURL</name>
<value>jdbc:mysql://mysqlhost/hive?createDatabaseIfNotExist=true</value>
<description>JDBC connect string for a JDBC metastore</description>
</property>
<property>
<name>javax.jdo.option.ConnectionDriverName</name>
<value>com.mysql.jdbc.Driver</value>
<description>Driver class name for a JDBC metastore</description>
</property>
<property>
<name>javax.jdo.option.ConnectionUserName</name>
<value>hive</value>
<description>username to use against metastore database</description>
</property>
<property>
<name>javax.jdo.option.ConnectionPassword</name>
<value>123</value>
<description>password to use against metastore database</description>
</property>
<property>
<name>hive.metastore.warehouse.dir</name>
<!-- base hdfs path -->
<value>/user/hive/warehouse</value>
<description>location of default database for the warehouse</description>
</property>格式化数据库
cd /usr/lib/hive/bin$ ./schematool --dbType mysql --initSchema
远程模式:
metastore service运行在独立的JVM进程中,通过配置hive.metastore.uris,进而实现HiveServer,Impala 等进程与 metastore 通信。通过配置javax.jdo.option.ConnectionURL,实现 metastore service 和数据库的通信,这点和本地模式是一样的。上述两个配置选项位于$HIVE_HOME/conf/hive-site.xml。

远程模式的主要优点在于管理员不必向每个hive 用户提供数据库的JDBC的登录信息,保证安全性。用户只需要在hive.metastore.uris中添加metastore的Thirft network API(如thrift://192.168.1.1:9083)即可完成所在客户端与服务端的通信,进而获取元数据信息。

所谓客户端,即可以提交查询任务的hive节点;所谓服务端,即为客户端提供metastore service的客户端。这里的客户端分为两类:
1.通过内嵌的metastore服务直接获取元数据
2.通过配置的hive.metastore.uris访问指定的安装hive-metastore的客户端,进而获取元数据,这时被访问的客户端相对于访问的客户端就称为服务端。

 
服务端配置如下,可以注意到这里的配置和本地模式一致。
 
<property>
<name>javax.jdo.option.ConnectionURL</name>
<value>jdbc:mysql://mysqlhost/hive?createDatabaseIfNotExist=true</value>
<description>JDBC connect string for a JDBC metastore</description>
</property>
<property>
<name>javax.jdo.option.ConnectionDriverName</name>
<value>com.mysql.jdbc.Driver</value>
<description>Driver class name for a JDBC metastore</description>
</property>
<property>
<name>javax.jdo.option.ConnectionUserName</name>
<value>hive</value>
<description>username to use against metastore database</description>
</property>
<property>
<name>javax.jdo.option.ConnectionPassword</name>
<value>123</value>
<description>password to use against metastore database</description>
</property>
<property>
<name>hive.metastore.warehouse.dir</name>
<!-- base hdfs path -->
<value>/user/hive/warehouse</value>
<description>location of default database for the warehouse</description>
</property>格式化数据库cd /usr/lib/hive/bin$ ./schematool --dbType mysql --initSchema客户端配置如下:

<!-- thrift://<host_name>:<port> 默认端口是9083 -->
<property>
<name>hive.metastore.uris</name
<value>thrift://metastorehost:9083</value>
<description>Thrift uri for the remote metastore. Used by metastore client to connect to remote metastore.</description>
</property> <!-- hive表的默认存储路径 -->
<property>
<name>hive.metastore.warehouse.dir</name>
<value>/user/hive/warehouse</value>
<description>location of default database for the warehouse</description>
</property> 查看全部
相比较于 Apache Hive 而言,Cloudera CDH 将 Hive 拆分为一个个独立的服务,如 hive,metastore,hivesever2等。如果在安装配置之前不能弄清楚各个部分的关系,那么安装过程中出现的各种问题也就不能针对性地解决。因此首先分享一下我个人对于hive,metastore 以及 hiveserve2 之间关系的理解。
 
使用 yum 安装 Cloudera CDH Hive 需要分别安装hive,hive-metastore 和 hive-sever2。其中hive是必须安装的,hive-metastore 和 hive-sever2 则根据要求选择安装。
 
  • 启动 hive 之后出现的 CLI 是查询任务的入口,CLI 提交任务给 Driver
  • Driver 接收到任务后调用 Compiler,Executor,Optimizer 将 SQL 语句转化为可以在 Hadoop 集群上执行的 MapReduce 任务
  • Compiler,Executor 从 metastore 获取所需要的元数据信息
  • hivesever2 作为 hivesever 的改进版本,最主要的变化在于提供了全新的命令行窗口 BeeLine。

 
1、使用 yum 安装 Hive 组件
Hive安装:
 
yum install hive
yum install hive-metastore
yum install hive-server2

2、配置 Hive
创建Hive相关文件的存储路径并更改目录权限
hdfs dfs -mkdir -p /usr/hive/warehouse
hdfs dfs -mkdir -p /usr/hive/tmp
hdfs dfs -mkdir -p /usr/hive/log
hdfs dfs -chmod g+w /usr/hive/warehouse
hdfs dfs -chmod g+w /usr/hive/tmp
hdfs dfs -chmod g+w /usr/hive/log
配置环境变量
vim /usr/lib/hive/conf/hive-env.sh
export HADOOP_HOME=/usr/lib/hadoop
export HIVE_CONF_DIR=/usr/lib/hive/conf

3、配置 MySQL
Metastore默认使用内嵌的Derby数据库存储元数据信息,同时支持多种数据库可做拓展。官网推荐使用MySQL和PostgreSQL,这里只列出MySQL的具体配置过程,有关PostgreSQL的配置过程可查阅官网。

CentOS 7 默认yum源并未包含mysql,需要首先配置repo源:
wget http://repo.mysql.com/mysql-community-release-el7-5.noarch.rpm
安装mysql-community-release-el7-5.noarch.rpm包
rpm -ivh mysql-community-release-el7-5.noarch.rpm
安装mysql并启动mysql
yum install mysql-server
为当前用户分配mysql权限并重启mysql服务
sudo chown -R root:root /var/lib/mysql
service mysqld restart
设置root密码
mysql -u root
mysql > use mysql; 
mysql > update user set password=password('123456') where user='root';
mysql > exit;
创建用于存储元数据的数据库和操作的用户
mysql -uroot -p123456
mysql> CREATE DATABASE metastore;
mysql> USE metastore;
mysql> SOURCE /usr/lib/hive/scripts/metastore/upgrade/mysql/hive-schema-0.12.0.mysql.sql;
mysql> CREATE USER 'hive'@'metastore' IDENTIFIED BY '123';
mysql> REVOKE ALL PRIVILEGES, GRANT OPTION FROM 'hive'@'metastorehost';
mysql> GRANT ALL ON metastore.* TO 'hive'@'metastorehost' IDENTIFIED BY 'hive';
mysql> GRANT ALL ON metastore.* TO 'hive'@'%' IDENTIFIED BY 'hive';
mysql> FLUSH PRIVILEGES;
mysql> ALTER DATABASE metastore CHARACTER SET latin1;
mysql> quit;

4、配置 Hive Metastore
内嵌模式是metastore 的默认模式,使用 Derby 存储元数据信息,但不支持多用户并发对metastore 操作,不建议在实际环境中使用。这里不再赘述。

下面的本地模式和远程模式均需要使用JDBC才能完成metastore和mysql的通信,需要先添加JDBC驱动包。
$ yum install mysql-connector-java
$ ln -s /usr/share/java/mysql-connector-java.jar /usr/lib/hive/lib/mysql-connector-java.jar


所谓的本地模式和远程模式,指的是metastore和hiveserver的位置关系,而和数据库的位置无关,这一点尤为重要。


 
本地模式:
metastore service 和 HiveServer 运行在同一进程,但是数据库运行在独立的进程,也可以将数据库安装在独立的主机上。内嵌的 metastore 服务和数据库通过 JDBC 通信。

配置方式如下:
vim /usr/lib/hive/conf/hive-site.xml
添加如下内容
<property>
<name>javax.jdo.option.ConnectionURL</name>
<value>jdbc:mysql://mysqlhost/hive?createDatabaseIfNotExist=true</value>
<description>JDBC connect string for a JDBC metastore</description>
</property>
<property>
<name>javax.jdo.option.ConnectionDriverName</name>
<value>com.mysql.jdbc.Driver</value>
<description>Driver class name for a JDBC metastore</description>
</property>
<property>
<name>javax.jdo.option.ConnectionUserName</name>
<value>hive</value>
<description>username to use against metastore database</description>
</property>
<property>
<name>javax.jdo.option.ConnectionPassword</name>
<value>123</value>
<description>password to use against metastore database</description>
</property>
<property>
<name>hive.metastore.warehouse.dir</name>
<!-- base hdfs path -->
<value>/user/hive/warehouse</value>
<description>location of default database for the warehouse</description>
</property>
格式化数据库
cd /usr/lib/hive/bin$ ./schematool --dbType mysql --initSchema

远程模式:
metastore service运行在独立的JVM进程中,通过配置hive.metastore.uris,进而实现HiveServer,Impala 等进程与 metastore 通信。通过配置javax.jdo.option.ConnectionURL,实现 metastore service 和数据库的通信,这点和本地模式是一样的。上述两个配置选项位于$HIVE_HOME/conf/hive-site.xml。

远程模式的主要优点在于管理员不必向每个hive 用户提供数据库的JDBC的登录信息,保证安全性。用户只需要在hive.metastore.uris中添加metastore的Thirft network API(如thrift://192.168.1.1:9083)即可完成所在客户端与服务端的通信,进而获取元数据信息。


所谓客户端,即可以提交查询任务的hive节点;所谓服务端,即为客户端提供metastore service的客户端。这里的客户端分为两类:
1.通过内嵌的metastore服务直接获取元数据
2.通过配置的hive.metastore.uris访问指定的安装hive-metastore的客户端,进而获取元数据,这时被访问的客户端相对于访问的客户端就称为服务端。


 
服务端配置如下,可以注意到这里的配置和本地模式一致。
 
<property>
<name>javax.jdo.option.ConnectionURL</name>
<value>jdbc:mysql://mysqlhost/hive?createDatabaseIfNotExist=true</value>
<description>JDBC connect string for a JDBC metastore</description>
</property>
<property>
<name>javax.jdo.option.ConnectionDriverName</name>
<value>com.mysql.jdbc.Driver</value>
<description>Driver class name for a JDBC metastore</description>
</property>
<property>
<name>javax.jdo.option.ConnectionUserName</name>
<value>hive</value>
<description>username to use against metastore database</description>
</property>
<property>
<name>javax.jdo.option.ConnectionPassword</name>
<value>123</value>
<description>password to use against metastore database</description>
</property>
<property>
<name>hive.metastore.warehouse.dir</name>
<!-- base hdfs path -->
<value>/user/hive/warehouse</value>
<description>location of default database for the warehouse</description>
</property>
格式化数据库
cd /usr/lib/hive/bin$ ./schematool --dbType mysql --initSchema
客户端配置如下:

<!-- thrift://<host_name>:<port> 默认端口是9083 --> 
<property>
<name>hive.metastore.uris</name
<value>thrift://metastorehost:9083</value>
<description>Thrift uri for the remote metastore. Used by metastore client to connect to remote metastore.</description>
</property> <!-- hive表的默认存储路径 -->
<property>
<name>hive.metastore.warehouse.dir</name>
<value>/user/hive/warehouse</value>
<description>location of default database for the warehouse</description>
</property>

Zookeepr参数详解

大数据/云计算Rock 发表了文章 • 0 个评论 • 131 次浏览 • 2017-05-24 21:47 • 来自相关话题

zookeeper的默认配置文件为zookeeper/conf/zoo_sample.cfg,需要将其修改为zoo.cfg。其中各配置项的含义,解释如下:
 
1.tickTime:Client-Server通信心跳时间
tickTime=2000
Zookeeper 服务器之间或客户端与服务器之间维持心跳的时间间隔,也就是每个 tickTime 时间就会发送一个心跳。tickTime以毫秒为单位。2.initLimit:Leader-Follower初始通信时限
initLimit=5
集群中的follower服务器(F)与leader服务器(L)之间初始连接时能容忍的最多心跳数(tickTime的数量)。3.syncLimit:Leader-Follower同步通信时限
syncLimit=2
集群中的follower服务器与leader服务器之间请求和应答之间能容忍的最多心跳数(tickTime的数量)。4.dataDir:数据文件目录
dataDir=/data/zookeeper/data
Zookeeper保存数据的目录,默认情况下,Zookeeper将写数据的日志文件也保存在这个目录里。5.clientPort:客户端连接端口
clientPort=2181
客户端连接 Zookeeper 服务器的端口,Zookeeper 会监听这个端口,接受客户端的访问请求。6.服务器名称与地址:集群信息(服务器编号,服务器地址,LF通信端口,选举端口)
这个配置项的书写格式比较特殊,规则如下:
server.N=YYY:A:B
server.1=zk1:2888:3888
server.2=zk2:2888:3888
server.3=zk3:2888:38887.ZK为什么设置为奇数个?
zookeeper有这样一个特性:集群中只要有过半的机器是正常工作的,那么整个集群对外就是可用的。也就是说如果有2个zookeeper,那么只要有1个死了zookeeper就不能用了,因为1没有过半,所以2个zookeeper的死亡容忍度为0;同理,要是有3个zookeeper,一个死了,还剩下2个正常的,过半了,所以3个zookeeper的容忍度为1;同理你多列举几个:2 -> 0; 3 -> 1; 4 - >1; 5 -> 2; 6 -> 2会发现一个规律,2n和2n-1的容忍度是一样的,都是n-1,所以为了更加高效,何必增加那一个不必要的zookeeper呢。增加处理能力,哈哈。。。 查看全部
zookeeper的默认配置文件为zookeeper/conf/zoo_sample.cfg,需要将其修改为zoo.cfg。其中各配置项的含义,解释如下:
 
1.tickTime:Client-Server通信心跳时间
tickTime=2000
Zookeeper 服务器之间或客户端与服务器之间维持心跳的时间间隔,也就是每个 tickTime 时间就会发送一个心跳。tickTime以毫秒为单位。
2.initLimit:Leader-Follower初始通信时限
initLimit=5
集群中的follower服务器(F)与leader服务器(L)之间初始连接时能容忍的最多心跳数(tickTime的数量)。
3.syncLimit:Leader-Follower同步通信时限
syncLimit=2 
集群中的follower服务器与leader服务器之间请求和应答之间能容忍的最多心跳数(tickTime的数量)。
4.dataDir:数据文件目录
dataDir=/data/zookeeper/data
Zookeeper保存数据的目录,默认情况下,Zookeeper将写数据的日志文件也保存在这个目录里。
5.clientPort:客户端连接端口
clientPort=2181
客户端连接 Zookeeper 服务器的端口,Zookeeper 会监听这个端口,接受客户端的访问请求。
6.服务器名称与地址:集群信息(服务器编号,服务器地址,LF通信端口,选举端口)
这个配置项的书写格式比较特殊,规则如下:
server.N=YYY:A:B
server.1=zk1:2888:3888
server.2=zk2:2888:3888
server.3=zk3:2888:3888
7.ZK为什么设置为奇数个?
zookeeper有这样一个特性:集群中只要有过半的机器是正常工作的,那么整个集群对外就是可用的。也就是说如果有2个zookeeper,那么只要有1个死了zookeeper就不能用了,因为1没有过半,所以2个zookeeper的死亡容忍度为0;同理,要是有3个zookeeper,一个死了,还剩下2个正常的,过半了,所以3个zookeeper的容忍度为1;同理你多列举几个:2 -> 0; 3 -> 1; 4 - >1; 5 -> 2; 6 -> 2会发现一个规律,2n和2n-1的容忍度是一样的,都是n-1,所以为了更加高效,何必增加那一个不必要的zookeeper呢。增加处理能力,哈哈。。。

MYSQL的不同SQL模式解析

数据库chris 发表了文章 • 0 个评论 • 149 次浏览 • 2017-05-15 23:05 • 来自相关话题

一、Mysql SQL Mode简介

通常来说MySQL服务器能够工作在不同的SQL模式下,并能针对不同的客户端以不同的方式应用这些模式。这样,应用程序就能对服务器操作进行量身定制以满足自己的需求。
 
这类模式定义了MySQL应支持的SQL语法,以及应该在数据上执行何种确认检查。这样,就能在众多不同的环境下、与其他数据库服务器一起更容易地使用MySQL。
 
可以使用" --sql-mode="modes" "选项,通过启动mysqld来设置默认的SQL模式。而从MySQL 4.1开始,也能在启动之后,使用SET [SESSION|GLOBAL] sql_mode='modes'语句,通过设置sql_mode变量更改其模式。
 
通常在linux下安装完mysql后,其默认的sql-mode值是空,在这种情形下mysql执行的是一种不严格的检查,例如日期字段可以插入'0000-00-00 00:00:00'这样的值,还有如果要插入的字段长度超过列定义的长度,那么mysql不会终止操作,而是会自动截断后面的字符继续插入操作,如下例:
mysql> create table t1 (c1 char(3));
mysql> insert into t1 values('abcd');
mysql> select * from t1;
+------+
| c1 |
+------+
| abc |
+------+
1 row in set (0.00 sec)我们发现插入的字符被自动截断了,但是如果我们本意希望如果长度超过限制就报错,那么我们可以设置sql_mode为STRICT_TRANS_TABLES,如下:
mysql> set session sql_mode='STRICT_TRANS_TABLES'这样我们再执行同样的操作,mysql就会告诉我们插入的值太长,操作被终止,如下:
mysql> insert into t1 values('abcd');
ERROR 1406 (22001): Data too long for column 'c1' at row 1
经常使用的sql_mode值:




说明:如果把sql_mode的值设置成后面的两个值(也就是我们说的严格模式),那么当在列中插入或更新不正确的值时,mysql将会给出错误,并且放弃insert/update操作。
 
在我们的一般应用中建议使用这两种模式,而不是使用默认的空或ANSI模式。但是需要注意的问题是,如果数据库运行在严格模式下,并且你的存储引擎不支持事务,那么有数据不一致的风险存在,比如一组sql中有两个dml语句,如果后面的一个出现了问题,但是前面的已经操作成功,那么mysql并不能回滚前面的操作。因此说设置sql_mode需要应用人员权衡各种得失,从而得到一个合适的选择。
 
Sql_mode的值还有很多,这里不再累述,可以参考相关的手册。
 
 

二、SQL Mode与可移植性

如果mysql与其它异构数据库之间有数据移植的需求的话,那么下面的sql_mode的组合设置可以达到相应的效果:




 

三、SQL Mode与数据效验

SQL Mode 还可以实现对数据效验和转移等功能如: 
效验日期数据合法性. 在INSERT或UPDATE过程中,如果被零除(或MOD(X,0)),则产生错误 将‘"'视为识别符引号(‘`'引号字符) 禁用反斜线字符(‘\')做为字符串内的退出字符。启用NO_BACKSLASH_ESCAPES模式,反斜线则成为普通字符。 将||视为字符串连接操作符(+)(同CONCAT()),而不视为OR。 查看全部


一、Mysql SQL Mode简介


通常来说MySQL服务器能够工作在不同的SQL模式下,并能针对不同的客户端以不同的方式应用这些模式。这样,应用程序就能对服务器操作进行量身定制以满足自己的需求。
 
这类模式定义了MySQL应支持的SQL语法,以及应该在数据上执行何种确认检查。这样,就能在众多不同的环境下、与其他数据库服务器一起更容易地使用MySQL。
 
可以使用" --sql-mode="modes" "选项,通过启动mysqld来设置默认的SQL模式。而从MySQL 4.1开始,也能在启动之后,使用SET [SESSION|GLOBAL] sql_mode='modes'语句,通过设置sql_mode变量更改其模式。
 
通常在linux下安装完mysql后,其默认的sql-mode值是空,在这种情形下mysql执行的是一种不严格的检查,例如日期字段可以插入'0000-00-00 00:00:00'这样的值,还有如果要插入的字段长度超过列定义的长度,那么mysql不会终止操作,而是会自动截断后面的字符继续插入操作,如下例:
mysql> create table t1 (c1 char(3));
mysql> insert into t1 values('abcd');
mysql> select * from t1;
+------+
| c1 |
+------+
| abc |
+------+
1 row in set (0.00 sec)
我们发现插入的字符被自动截断了,但是如果我们本意希望如果长度超过限制就报错,那么我们可以设置sql_mode为STRICT_TRANS_TABLES,如下:
mysql> set session sql_mode='STRICT_TRANS_TABLES'
这样我们再执行同样的操作,mysql就会告诉我们插入的值太长,操作被终止,如下:
mysql> insert into t1 values('abcd');
ERROR 1406 (22001): Data too long for column 'c1' at row 1

经常使用的sql_mode值:
sqlmode.png

说明:如果把sql_mode的值设置成后面的两个值(也就是我们说的严格模式),那么当在列中插入或更新不正确的值时,mysql将会给出错误,并且放弃insert/update操作。
 
在我们的一般应用中建议使用这两种模式,而不是使用默认的空或ANSI模式。但是需要注意的问题是,如果数据库运行在严格模式下,并且你的存储引擎不支持事务,那么有数据不一致的风险存在,比如一组sql中有两个dml语句,如果后面的一个出现了问题,但是前面的已经操作成功,那么mysql并不能回滚前面的操作。因此说设置sql_mode需要应用人员权衡各种得失,从而得到一个合适的选择。
 
Sql_mode的值还有很多,这里不再累述,可以参考相关的手册。
 
 


二、SQL Mode与可移植性


如果mysql与其它异构数据库之间有数据移植的需求的话,那么下面的sql_mode的组合设置可以达到相应的效果:
databaseclass.png

 


三、SQL Mode与数据效验


SQL Mode 还可以实现对数据效验和转移等功能如: 
  1. 效验日期数据合法性. 
  2. 在INSERT或UPDATE过程中,如果被零除(或MOD(X,0)),则产生错误 
  3. 将‘"'视为识别符引号(‘`'引号字符) 
  4. 禁用反斜线字符(‘\')做为字符串内的退出字符。启用NO_BACKSLASH_ESCAPES模式,反斜线则成为普通字符。 
  5. 将||视为字符串连接操作符(+)(同CONCAT()),而不视为OR。

​选择云服务器的小窍门有哪些?

大数据/云计算OT学习平台 发表了文章 • 0 个评论 • 113 次浏览 • 2017-05-15 14:59 • 来自相关话题

OTPUB直播活动又双叒叕来喽!
直播主题
老板等等,微软专家找你聊转型!
直播时间
2017年5月16日 14:00-15:00

点击报名>>>
云计算,将云服务器待到了聚光灯下。但选择云服务器是件很困难的事,因为云平台的功能都相差无几。我们货比三家时,建议从细节入手,综合考量,只选对的,不选贵的,选择适配业务需求的云服务器。那么选择云服务器的小窍门有哪些呢?
一、谨记自身需求
云服务器归根到底是为你的业务服务的,因此首先需要明确你对云服务器的需求,比较并评估各种功能,例如虚拟化功能、网络隔离和root权限隔离等。要留意管理和监控处理器、内存、磁盘I/O性能、存储限制等资源管理的功能。确定某个平台能够满足你企业的具体标准之后,再评估成本。
二、网络线路,建议选双线或多线
根据数据中心接入的网络线路,国内云服务器提供电信、联通等单线/双线带宽。建议选择双线。即使你的业务主要面向本地客户群也是如此。因为本地客户的宽带使用状况也不统一,即使中国北方地区也有大量的电信用户。为满足不同网络运营商客户的访问需求,建议选择双线双IP。
三、推荐香港节点
根据部署区域的差异,很多服务商提供国内、香港、韩国、美国等多样化的节点供你选择。国内节点必须备案,美国云服务器连接中国速度慢,因此如果你的业务面向亚太区客户群,个人推荐香港节点。香港节点,一般采用BGP国际多线,支持中国大陆和亚太区极速访问,且大陆南北地区均享高速。更重要的是,香港云服务器免备案,即开即用,你的业务可以最快速度上线,抢占市场先机。如果你的客户群主要分布在北美和欧洲,建议使用美国云服务器。
云服务器
四、云服务器性能测试
选购云服务器前,建议通过性能测试感知云服务器的性能表现(一般很多云服务商都提供测试机型、免费试用、3天无条件退款等,这些都可用于性能测试)。通过对测试IP进行ping、Tracert路由追踪、网站测速工具等可初步把握云服务器的网络连接速度和质量。通过HD Tune等工具测试磁盘性能等。总之,我们需要对云服务器的稳定性、网络稳定性以及软件兼容性等主要方面进行测试,包括云服务器是否宕机、损坏数据恢复能力、是否具备入侵攻击防护、网络延迟和丢包率、软件安装和运行是否正常、软件数据是否兼容等。
以上就是选择云服务器时的小窍门,希望对你有所帮助。最后,我们还要提醒云服务器用户,虽然云服务器拥有多重数据副本、快照备份等机制,但传统的定期本地备份习惯我们也不能丢弃。因为再稳定的云平台也无法保证100%无故障,一旦云平台基础架构出现故障,后果可能是毁灭性的,做好自身网站数据备份并下载到本地保存,是保护我们努力成果的应尽之责,也是防止关键业务数据丢失的最后一道防线。 查看全部
OTPUB直播活动又双叒叕来喽!
直播主题
老板等等,微软专家找你聊转型!
直播时间
2017年5月16日 14:00-15:00

点击报名>>>
云计算,将云服务器待到了聚光灯下。但选择云服务器是件很困难的事,因为云平台的功能都相差无几。我们货比三家时,建议从细节入手,综合考量,只选对的,不选贵的,选择适配业务需求的云服务器。那么选择云服务器的小窍门有哪些呢?
一、谨记自身需求
云服务器归根到底是为你的业务服务的,因此首先需要明确你对云服务器的需求,比较并评估各种功能,例如虚拟化功能、网络隔离和root权限隔离等。要留意管理和监控处理器、内存、磁盘I/O性能、存储限制等资源管理的功能。确定某个平台能够满足你企业的具体标准之后,再评估成本。
二、网络线路,建议选双线或多线
根据数据中心接入的网络线路,国内云服务器提供电信、联通等单线/双线带宽。建议选择双线。即使你的业务主要面向本地客户群也是如此。因为本地客户的宽带使用状况也不统一,即使中国北方地区也有大量的电信用户。为满足不同网络运营商客户的访问需求,建议选择双线双IP。
三、推荐香港节点
根据部署区域的差异,很多服务商提供国内、香港、韩国、美国等多样化的节点供你选择。国内节点必须备案,美国云服务器连接中国速度慢,因此如果你的业务面向亚太区客户群,个人推荐香港节点。香港节点,一般采用BGP国际多线,支持中国大陆和亚太区极速访问,且大陆南北地区均享高速。更重要的是,香港云服务器免备案,即开即用,你的业务可以最快速度上线,抢占市场先机。如果你的客户群主要分布在北美和欧洲,建议使用美国云服务器。
云服务器
四、云服务器性能测试
选购云服务器前,建议通过性能测试感知云服务器的性能表现(一般很多云服务商都提供测试机型、免费试用、3天无条件退款等,这些都可用于性能测试)。通过对测试IP进行ping、Tracert路由追踪、网站测速工具等可初步把握云服务器的网络连接速度和质量。通过HD Tune等工具测试磁盘性能等。总之,我们需要对云服务器的稳定性、网络稳定性以及软件兼容性等主要方面进行测试,包括云服务器是否宕机、损坏数据恢复能力、是否具备入侵攻击防护、网络延迟和丢包率、软件安装和运行是否正常、软件数据是否兼容等。
以上就是选择云服务器时的小窍门,希望对你有所帮助。最后,我们还要提醒云服务器用户,虽然云服务器拥有多重数据副本、快照备份等机制,但传统的定期本地备份习惯我们也不能丢弃。因为再稳定的云平台也无法保证100%无故障,一旦云平台基础架构出现故障,后果可能是毁灭性的,做好自身网站数据备份并下载到本地保存,是保护我们努力成果的应尽之责,也是防止关键业务数据丢失的最后一道防线。

腾讯云正式加入CNCF和Linux基金会

大数据/云计算图灵之歌 发表了文章 • 0 个评论 • 417 次浏览 • 2017-05-09 12:16 • 来自相关话题

美国东部时间5月8日,全球知名非营利性组织CNCF (Cloud Native Computing Foundation)在全球开源盛会“2017 OpenStack峰会”上宣布,腾讯云作为金牌会员正式加入CNCF基金会。 

按照规则,基于企业会员对代码的贡献、贡献的标准和规范、为开源组织提供的支持等综合标准,CNCF基金会授予腾讯云金牌会员身份,同时基于腾讯云在Linux领域的积极贡献,腾讯云获CNCF基金会邀请加入Linux基金会。



腾讯云是国内最大的基于Kubernetes提供容器服务的公有云服务商,也是拥有国内最大规模KVM集群的企业。腾讯云加入CNCF和Linux基金会,标志腾讯云深度参与全球开源技术生态圈,在容器服务、KVM虚拟化等重大开源项目的实力已经得到全球核心开源组织和业界的认可,将为腾讯云进一步参与全球开源社区技术交流、参与开源项目开发等领域开拓全新局面。

CNCF及Linux基金会
据悉,CNCF基金会是由Linux 基金会发起的,致力于管理和运转原生云项目,吸纳开源社区和合作伙伴,共同推动Kubernetes以及容器计算发展的非营利组织,其成员包括Docker、Google、Intel、Red Hat、IBM等国际知名科技公司。
 
Linux基金会是全球知名的非营利性的联盟,致力于促进Linux的发展,推动行业产生原创性技术研究和内容,以促进Linux的发展。

腾讯云加入基金会的用户价值
CNCF基金会的执行董事Dan Kohn对腾讯云的加入表示欢迎,他表示,“建立在开源技术上的容器服务正在以难以置信的速度,让公司实现向云计算的迁移,这印证了目前大环境对开源技术的热情和信任。同时,对容器服务的积极采用将助燃一个新兴市场的产生,并让我们的用户立于不败之地。CNCF热烈欢迎新成员加入,我们希望大家可以从基金会和社区中获得帮助和指导,这将进一步夯实CNCF作为提供行业最优实践和云原生生态系统的第三方的重要价值。”

腾讯云专家工程师刘颖表示,容器技术的发展在为中国的云计算提供新思路,对云计算领域产生积极深远的影响,腾讯云在国内提供的容器技术已经帮助大量互联网和传统企业快速构建云原生应用,使企业系统组件化、微服务化,实现持续集成和交付,加快应用迭代,降低开发成本,同时也是实现DevOps的重要支撑。  

腾讯云在CNCF与Linux领域的贡献
在实际的产品设计中,腾讯云的容器技术不仅拥抱开源、支持用户直接调用Kubernetes API,还基于Kubernetes打造了CBS、CLB等产品插件,并在容器网络上以腾讯云私有网络为基础,实现高可靠、高性能的网络方案。三一重工、华尔街见闻APP在面对原系统拆分后微服务架构部署、开发测试应用部署等需求时,均选择使用腾讯云容器服务。

在加入CNCF基金会后,腾讯云将从产品出发,基于大量用户在产品使用中的感受和腾讯云的服务实践,将有价值的特性推送和反馈给社区,与社区一起完善相关特性,同时又从社区中获得广泛的用户反馈,再次回到产品,提升腾讯云的产品体验。比如腾讯云将在未来推送自身的Kubernetes相关特性进入CNCF开源社区,并继续通过Kubernetes的Bugfix,Code Optimization及Design Proposals等方式更多地参与到社区特性开发的工作当中。在这个过程中,腾讯云紧密服务社区,并进一步拓宽技术视野,更深地加入到全球技术交流中 。
  
与此同时,腾讯云多年来一直与Linux开源社区互动,与专注系统底层、高性能加速、解决方案的各类社区保持稳定良性的交流,不断反馈技术成果。腾讯云在云计算基础IaaS关键技术——虚拟机热迁移和稳定方面已经取得了重大成果,设计热迁移过程中内存的快速写保护算法,解决了虚拟机热迁移过程中如虚拟机磁盘IO性能下降、迁移后QCOW2镜像零页写操作等难题,还重构了KVM的RTC计时框架,让windows虚拟机的时钟系统在时钟频率频繁调整的情况下保持精准。 
 
腾讯云在CNCF与Linux社区的计划 
过去,这些成果都由腾讯云以核心patch的方式回馈给CNCF和Linux社区,而加入CNCF和Linux基金会后,基于腾讯云在容器服务的实践,将给予CNCF原生云建设回馈;同时腾讯云基于庞大的用户规模,在虚拟机方面有丰富的研究与实践,将给予Linux社区以巨大的回馈。 
  
刘颖表示,希望能成为全球开源社区的新力量,推动CNCF和Linux的发展,分享腾讯云的经验,为CNCF和Linux的项目做出贡献,腾讯云将与社区紧密联系在一起,为全球用户提供高品质、全能力的技术服务。
 
在数字经济时代,云计算正在改变整体商业的运作模式,而开源技术也在加速企业向云计算迁移的步伐,以及改变云计算领域部署和管理应用的方式。自建立以来,CNCF和Linux基金会始终在推动合作伙伴在社区共同贡献更多的开源技术,腾讯云的加入将有望加速全球技术的发展进程。 
  查看全部
美国东部时间5月8日,全球知名非营利性组织CNCF (Cloud Native Computing Foundation)在全球开源盛会“2017 OpenStack峰会”上宣布,腾讯云作为金牌会员正式加入CNCF基金会。 

按照规则,基于企业会员对代码的贡献、贡献的标准和规范、为开源组织提供的支持等综合标准,CNCF基金会授予腾讯云金牌会员身份,同时基于腾讯云在Linux领域的积极贡献,腾讯云获CNCF基金会邀请加入Linux基金会。



腾讯云是国内最大的基于Kubernetes提供容器服务的公有云服务商,也是拥有国内最大规模KVM集群的企业。腾讯云加入CNCF和Linux基金会,标志腾讯云深度参与全球开源技术生态圈,在容器服务、KVM虚拟化等重大开源项目的实力已经得到全球核心开源组织和业界的认可,将为腾讯云进一步参与全球开源社区技术交流、参与开源项目开发等领域开拓全新局面。

CNCF及Linux基金会
据悉,CNCF基金会是由Linux 基金会发起的,致力于管理和运转原生云项目,吸纳开源社区和合作伙伴,共同推动Kubernetes以及容器计算发展的非营利组织,其成员包括Docker、Google、Intel、Red Hat、IBM等国际知名科技公司。
 
Linux基金会是全球知名的非营利性的联盟,致力于促进Linux的发展,推动行业产生原创性技术研究和内容,以促进Linux的发展。

腾讯云加入基金会的用户价值
CNCF基金会的执行董事Dan Kohn对腾讯云的加入表示欢迎,他表示,“建立在开源技术上的容器服务正在以难以置信的速度,让公司实现向云计算的迁移,这印证了目前大环境对开源技术的热情和信任。同时,对容器服务的积极采用将助燃一个新兴市场的产生,并让我们的用户立于不败之地。CNCF热烈欢迎新成员加入,我们希望大家可以从基金会和社区中获得帮助和指导,这将进一步夯实CNCF作为提供行业最优实践和云原生生态系统的第三方的重要价值。”

腾讯云专家工程师刘颖表示,容器技术的发展在为中国的云计算提供新思路,对云计算领域产生积极深远的影响,腾讯云在国内提供的容器技术已经帮助大量互联网和传统企业快速构建云原生应用,使企业系统组件化、微服务化,实现持续集成和交付,加快应用迭代,降低开发成本,同时也是实现DevOps的重要支撑。  

腾讯云在CNCF与Linux领域的贡献
在实际的产品设计中,腾讯云的容器技术不仅拥抱开源、支持用户直接调用Kubernetes API,还基于Kubernetes打造了CBS、CLB等产品插件,并在容器网络上以腾讯云私有网络为基础,实现高可靠、高性能的网络方案。三一重工、华尔街见闻APP在面对原系统拆分后微服务架构部署、开发测试应用部署等需求时,均选择使用腾讯云容器服务。

在加入CNCF基金会后,腾讯云将从产品出发,基于大量用户在产品使用中的感受和腾讯云的服务实践,将有价值的特性推送和反馈给社区,与社区一起完善相关特性,同时又从社区中获得广泛的用户反馈,再次回到产品,提升腾讯云的产品体验。比如腾讯云将在未来推送自身的Kubernetes相关特性进入CNCF开源社区,并继续通过Kubernetes的Bugfix,Code Optimization及Design Proposals等方式更多地参与到社区特性开发的工作当中。在这个过程中,腾讯云紧密服务社区,并进一步拓宽技术视野,更深地加入到全球技术交流中 。
  
与此同时,腾讯云多年来一直与Linux开源社区互动,与专注系统底层、高性能加速、解决方案的各类社区保持稳定良性的交流,不断反馈技术成果。腾讯云在云计算基础IaaS关键技术——虚拟机热迁移和稳定方面已经取得了重大成果,设计热迁移过程中内存的快速写保护算法,解决了虚拟机热迁移过程中如虚拟机磁盘IO性能下降、迁移后QCOW2镜像零页写操作等难题,还重构了KVM的RTC计时框架,让windows虚拟机的时钟系统在时钟频率频繁调整的情况下保持精准。 
 
腾讯云在CNCF与Linux社区的计划 
过去,这些成果都由腾讯云以核心patch的方式回馈给CNCF和Linux社区,而加入CNCF和Linux基金会后,基于腾讯云在容器服务的实践,将给予CNCF原生云建设回馈;同时腾讯云基于庞大的用户规模,在虚拟机方面有丰富的研究与实践,将给予Linux社区以巨大的回馈。 
  
刘颖表示,希望能成为全球开源社区的新力量,推动CNCF和Linux的发展,分享腾讯云的经验,为CNCF和Linux的项目做出贡献,腾讯云将与社区紧密联系在一起,为全球用户提供高品质、全能力的技术服务。
 
在数字经济时代,云计算正在改变整体商业的运作模式,而开源技术也在加速企业向云计算迁移的步伐,以及改变云计算领域部署和管理应用的方式。自建立以来,CNCF和Linux基金会始终在推动合作伙伴在社区共同贡献更多的开源技术,腾讯云的加入将有望加速全球技术的发展进程。 

 

MYSQL大小写敏感介绍

数据库chris 发表了文章 • 0 个评论 • 138 次浏览 • 2017-05-08 22:55 • 来自相关话题

简介

在MySQL中,数据库对应数据目录中的目录。数据库中的每个表至少对应数据库目录中的一个文件(也可能是多个,取决于存储引擎)。因此,所使用操作系统的大小写敏感性决定了数据库名和表名的大小写敏感性。
 
在大多数Unix中数据库名和表名对大小写敏感,而在Windows中对大小写不敏感。一个显著的例外情况是Mac OS X,它基于Unix但使用默认文件系统类型(HFS+),对大小写不敏感。然而,Mac OS X也支持UFS卷,该卷对大小写敏感,就像Unix一样。
 
变量lower_case_file_system说明是否数据目录所在的文件系统对文件名的大小写敏感。ON说明对文件名的大小写不敏感,OFF表示敏感。
 
例如在Linux下查看:
mysql> show variables like 'lower%';
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
| lower_case_file_system | OFF |
| lower_case_table_names | 0 |
+------------------------+-------+
2 rows in set (0.00 sec)说明Linux系统对大小写敏感,MySQL也默认设置为对大小写敏感, 而Windows则相反。
 

大小写区分规则

Linux下:
数据库名与表名是严格区分大小写的;表的别名是严格区分大小写的;列名与列的别名在所有的情况下均是忽略大小写的;变量名也是严格区分大小写的;
 
windows下:
都不区分大小写
 
Mac OS下(非UFS卷):
都不区分大小写
 

参数说明

unix下lower_case_table_names默认值为 0 ;  Windows下默认值是 1 ;Mac OS X下默认值是 2 .





由大小写敏感转换为不敏感方法

如果原来所建立库及表都是对大小写敏感的,想要转换为对大小写不敏感,主要需要进行如下3步:
将数据库数据通过mysqldump导出。在my.cnf中更改lower_case_tables_name = 1,并重启mysql数据库。将导出的数据导入mysql数据库。
 

注意事项

为了避免大小写引发的问题,一种推荐的命名规则是:在定义数据库、表、列的时候全部采用小写字母加下划线的方式,不使用任何大写字母
 
在任何系统中可以使用lower_case_tables_name=1。使用该选项的不利之处是当使用SHOW TABLES或SHOW DATABASES时,看不出名字原来是用大写还是小写。
 
请注意在Unix中如果以前lower_case_tables_name = 0将lower_case_tables_name设置为1之前,重启mysqld之前,必须先将旧的数据库名和表名转换为小写。 查看全部


简介


在MySQL中,数据库对应数据目录中的目录。数据库中的每个表至少对应数据库目录中的一个文件(也可能是多个,取决于存储引擎)。因此,所使用操作系统的大小写敏感性决定了数据库名和表名的大小写敏感性。
 
在大多数Unix中数据库名和表名对大小写敏感,而在Windows中对大小写不敏感。一个显著的例外情况是Mac OS X,它基于Unix但使用默认文件系统类型(HFS+),对大小写不敏感。然而,Mac OS X也支持UFS卷,该卷对大小写敏感,就像Unix一样。
 
变量lower_case_file_system说明是否数据目录所在的文件系统对文件名的大小写敏感。ON说明对文件名的大小写不敏感,OFF表示敏感。
 
例如在Linux下查看:
mysql> show variables like 'lower%';
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
| lower_case_file_system | OFF |
| lower_case_table_names | 0 |
+------------------------+-------+
2 rows in set (0.00 sec)
说明Linux系统对大小写敏感,MySQL也默认设置为对大小写敏感, 而Windows则相反。
 


大小写区分规则


Linux下
  • 数据库名与表名是严格区分大小写的;
  • 表的别名是严格区分大小写的;
  • 列名与列的别名在所有的情况下均是忽略大小写的;
  • 变量名也是严格区分大小写的;

 
windows下
  • 都不区分大小写

 
Mac OS下(非UFS卷):
  • 都不区分大小写

 


参数说明


unix下lower_case_table_names默认值为 0 ;  Windows下默认值是 1 ;Mac OS X下默认值是 2 .
args.png


由大小写敏感转换为不敏感方法


如果原来所建立库及表都是对大小写敏感的,想要转换为对大小写不敏感,主要需要进行如下3步:
  1. 将数据库数据通过mysqldump导出。
  2. 在my.cnf中更改lower_case_tables_name = 1,并重启mysql数据库。
  3. 将导出的数据导入mysql数据库。

 


注意事项


为了避免大小写引发的问题,一种推荐的命名规则是:在定义数据库、表、列的时候全部采用小写字母加下划线的方式,不使用任何大写字母
 
在任何系统中可以使用lower_case_tables_name=1。使用该选项的不利之处是当使用SHOW TABLES或SHOW DATABASES时,看不出名字原来是用大写还是小写。
 
请注意在Unix中如果以前lower_case_tables_name = 0将lower_case_tables_name设置为1之前,重启mysqld之前,必须先将旧的数据库名和表名转换为小写。

集成Power Query插件 微软Excel新功能

学习资源OT学习平台 发表了文章 • 0 个评论 • 96 次浏览 • 2017-05-08 16:29 • 来自相关话题

微软Power Query是一款Excel专用插件,用以提升Excel的商业智能自助服务体验,Power Query包含公共搜索功能,但目前仅适用于美国。Power Query插件将与Office 365 Power BI插件整合,用户可在组织内部进行数据的共享、管理和搜索。
集成Power Query插件 微软Excel新功能 
EXECL集成Power Query
Power Query简化了数据查找和访问的过程,允许用户轻松发现、整合和完善数据,以便更好地在Excel中进行结果分析。
在即将到来的Excel新版本里,这款插件将被集成到Excel,成为一项产品特性,因此用户不需要再专门安装插件,就能使用该特性。
企业内部用户可以找到并利用这些共享查询(如果数据允许共享),使用共享查询中的基础数据进行企业数据分析和报告。
 
OTPUB直播活动又双叒叕来喽!
直播主题
Salesforce爱因斯坦Einstein人工智能解决方案
直播时间
2017年5月11日 14:00-15:00

点击报名>>>
  查看全部
微软Power Query是一款Excel专用插件,用以提升Excel的商业智能自助服务体验,Power Query包含公共搜索功能,但目前仅适用于美国。Power Query插件将与Office 365 Power BI插件整合,用户可在组织内部进行数据的共享、管理和搜索。
集成Power Query插件 微软Excel新功能 
EXECL集成Power Query
Power Query简化了数据查找和访问的过程,允许用户轻松发现、整合和完善数据,以便更好地在Excel中进行结果分析。
在即将到来的Excel新版本里,这款插件将被集成到Excel,成为一项产品特性,因此用户不需要再专门安装插件,就能使用该特性。
企业内部用户可以找到并利用这些共享查询(如果数据允许共享),使用共享查询中的基础数据进行企业数据分析和报告。
 
OTPUB直播活动又双叒叕来喽!
直播主题
Salesforce爱因斯坦Einstein人工智能解决方案
直播时间
2017年5月11日 14:00-15:00

点击报名>>>
 

HTTP长连接和短连接介绍

运维技术being 发表了文章 • 0 个评论 • 152 次浏览 • 2017-05-06 13:29 • 来自相关话题

1、HTTP协议与TCP/IP协议的关系​
HTTP的长连接和短连接本质上是TCP长连接和短连接。HTTP属于应用层协议,在传输层使用TCP协议,在网络层使用IP协议。IP协议主要解决网络路由和寻址问题,TCP协议主要解决如何在IP层之上可靠的传递数据包,使在网络上的另一端收到发端发出的所有包,并且顺序与发出顺序一致。TCP有可靠,面向连接的特点。
 
2、如何理解HTTP协议是无状态的
HTTP协议是无状态的,指的是协议对于事务处理没有记忆能力,服务器不知道客户端是什么状态。也就是说,打开一个服务器上的网页和你之前打开这个服务器上的网页之间没有任何联系。HTTP是一个无状态的面向连接的协议,无状态不代表HTTP不能保持TCP连接,更不能代表HTTP使用的是UDP协议(无连接)。
 
3、什么是长连接、短连接?
在HTTP/1.0中,默认使用的是短连接。也就是说,浏览器和服务器每进行一次HTTP操作,就建立一次连接,但任务结束就中断连接。如果客户端浏览器访问的某个HTML或其他类型的 Web页中包含有其他的Web资源,如JavaScript文件、图像文件、CSS文件等;当浏览器每遇到这样一个Web资源,就会建立一个HTTP会话。
 
但从 HTTP/1.1起,默认使用长连接,用以保持连接特性。使用长连接的HTTP协议,会在响应头有加入这行代码:Connection:keep-alive在使用长连接的情况下,当一个网页打开完成后,客户端和服务器之间用于传输HTTP数据的 TCP连接不会关闭,如果客户端再次访问这个服务器上的网页,会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接,它有一个保持时间,可以在不同的服务器软件(如Apache)中设定这个时间。实现长连接要客户端和服务端都支持长连接。
 
HTTP协议的长连接和短连接,实质上是TCP协议的长连接和短连接。
 
3.1 TCP连接
当网络通信时采用TCP协议时,在真正的读写操作之前,server与client之间必须建立一个连接,当读写操作完成后,双方不再需要这个连接 时它们可以释放这个连接,连接的建立是需要三次握手的,而释放则需要4次握手,所以说每个连接的建立都是需要资源消耗和时间消耗的

经典的三次握手示意图:








经典的四次挥手关闭图:
 








 
3.2 TCP短连接
我们模拟一下TCP短连接的情况,client向server发起连接请求,server接到请求,然后双方建立连接。client向server 发送消息,server回应client,然后一次读写就完成了,这时候双方任何一个都可以发起close操作,不过一般都是client先发起 close操作。为什么呢,一般的server不会回复完client后立即关闭连接的,当然不排除有特殊的情况。从上面的描述看,短连接一般只会在 client/server间传递一次读写操作

短连接的优点是:管理起来比较简单,存在的连接都是有用的连接,不需要额外的控制手段
 
3.3 TCP长连接
接下来我们再模拟一下长连接的情况,client向server发起连接,server接受client连接,双方建立连接。Client与server完成一次读写之后,它们之间的连接并不会主动关闭,后续的读写操作会继续使用这个连接。

首先说一下TCP/IP详解上讲到的TCP保活功能,保活功能主要为服务器应用提供,服务器应用希望知道客户主机是否崩溃,从而可以代表客户使用资源。如果客户已经消失,使得服务器上保留一个半开放的连接,而服务器又在等待来自客户端的数据,则服务器将应远等待客户端的数据,保活功能就是试图在服务 器端检测到这种半开放的连接。

如果一个给定的连接在两小时内没有任何的动作,则服务器就向客户发一个探测报文段,客户主机必须处于以下4个状态之一:
客户主机依然正常运行,并从服务器可达。客户的TCP响应正常,而服务器也知道对方是正常的,服务器在两小时后将保活定时器复位。客户主机已经崩溃,并且关闭或者正在重新启动。在任何一种情况下,客户的TCP都没有响应。服务端将不能收到对探测的响应,并在75秒后超时。服务器总共发送10个这样的探测 ,每个间隔75秒。如果服务器没有收到一个响应,它就认为客户主机已经关闭并终止连接。客户主机崩溃并已经重新启动。服务器将收到一个对其保活探测的响应,这个响应是一个复位,使得服务器终止这个连接。客户机正常运行,但是服务器不可达,这种情况与2类似,TCP能发现的就是没有收到探查的响应。
 
长连接短连接操作过程:
短连接的操作步骤是:建立连接——数据传输——关闭连接...建立连接——数据传输——关闭连接

长连接的操作步骤是:建立连接——数据传输...(保持连接)...数据传输——关闭连接
 
4、 长连接和短连接的优点和缺点
由上可以看出,长连接可以省去较多的TCP建立和关闭的操作,减少浪费,节约时间。对于频繁请求资源的客户来说,较适用长连接。不过这里存在一个问题,存活功能的探测周期太长,还有就是它只是探测TCP连接的存活,属于比较斯文的做法,遇到恶意的连接时,保活功能就不够使了。在长连接的应用场景下,client端一般不会主动关闭它们之间的连接,Client与server之间的连接如果一直不关闭的话,会存在一个问题,随着客户端连接越来越多,server早晚有扛不住的时候,这时候server端需要采取一些策略,如关闭一些长时间没有读写事件发生的连接,这样可 以避免一些恶意连接导致server端服务受损;如果条件再允许就可以以客户端机器为颗粒度,限制每个客户端的最大长连接数,这样可以完全避免某个蛋疼的客户端连累后端服务。

短连接对于服务器来说管理较为简单,存在的连接都是有用的连接,不需要额外的控制手段。但如果客户请求频繁,将在TCP的建立和关闭操作上浪费时间和带宽。

长连接和短连接的产生在于client和server采取的关闭策略,具体的应用场景采用具体的策略,没有十全十美的选择,只有合适的选择。
 
5、什么时候用长连接,短连接? 
长连接多用于操作频繁,点对点的通讯,而且连接数不能太多情况,。每个TCP连接都需要三步握手,这需要时间,如果每个操作都是先连接,再操作的话那么处理速度会降低很多,所以每个操作完后都不断开,次处理时直接发送数据包就OK了,不用建立TCP连接。例如:数据库的连接用长连接, 如果用短连接频繁的通信会造成socket错误,而且频繁的socket 创建也是对资源的浪费。 
  
而像WEB网站的http服务一般都用短链接,因为长连接对于服务端来说会耗费一定的资源,而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源,如果用长连接,而且同时有成千上万的用户,如果每个用户都占用一个连接的话,那可想而知吧。所以并发量大,但每个用户无需频繁操作情况下需用短连好。 查看全部
1、HTTP协议与TCP/IP协议的关系​
HTTP的长连接和短连接本质上是TCP长连接和短连接。HTTP属于应用层协议,在传输层使用TCP协议,在网络层使用IP协议。IP协议主要解决网络路由和寻址问题,TCP协议主要解决如何在IP层之上可靠的传递数据包,使在网络上的另一端收到发端发出的所有包,并且顺序与发出顺序一致。TCP有可靠,面向连接的特点。
 
2、如何理解HTTP协议是无状态的
HTTP协议是无状态的,指的是协议对于事务处理没有记忆能力,服务器不知道客户端是什么状态。也就是说,打开一个服务器上的网页和你之前打开这个服务器上的网页之间没有任何联系。HTTP是一个无状态的面向连接的协议,无状态不代表HTTP不能保持TCP连接,更不能代表HTTP使用的是UDP协议(无连接)。
 
3、什么是长连接、短连接?
HTTP/1.0中,默认使用的是短连接。也就是说,浏览器和服务器每进行一次HTTP操作,就建立一次连接,但任务结束就中断连接。如果客户端浏览器访问的某个HTML或其他类型的 Web页中包含有其他的Web资源,如JavaScript文件、图像文件、CSS文件等;当浏览器每遇到这样一个Web资源,就会建立一个HTTP会话。
 
但从 HTTP/1.1起,默认使用长连接,用以保持连接特性。使用长连接的HTTP协议,会在响应头有加入这行代码:
Connection:keep-alive
在使用长连接的情况下,当一个网页打开完成后,客户端和服务器之间用于传输HTTP数据的 TCP连接不会关闭,如果客户端再次访问这个服务器上的网页,会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接,它有一个保持时间,可以在不同的服务器软件(如Apache)中设定这个时间。实现长连接要客户端和服务端都支持长连接。
 
HTTP协议的长连接和短连接,实质上是TCP协议的长连接和短连接。
 
3.1 TCP连接
当网络通信时采用TCP协议时,在真正的读写操作之前,server与client之间必须建立一个连接,当读写操作完成后,双方不再需要这个连接 时它们可以释放这个连接,连接的建立是需要三次握手的,而释放则需要4次握手,所以说每个连接的建立都是需要资源消耗和时间消耗的

经典的三次握手示意图:
tcp.png

san.png

经典的四次挥手关闭图:
 
huishou.png

si.png

 
3.2 TCP短连接
我们模拟一下TCP短连接的情况,client向server发起连接请求,server接到请求,然后双方建立连接。client向server 发送消息,server回应client,然后一次读写就完成了,这时候双方任何一个都可以发起close操作,不过一般都是client先发起 close操作。为什么呢,一般的server不会回复完client后立即关闭连接的,当然不排除有特殊的情况。从上面的描述看,短连接一般只会在 client/server间传递一次读写操作

短连接的优点是:管理起来比较简单,存在的连接都是有用的连接,不需要额外的控制手段
 
3.3 TCP长连接
接下来我们再模拟一下长连接的情况,client向server发起连接,server接受client连接,双方建立连接。Client与server完成一次读写之后,它们之间的连接并不会主动关闭,后续的读写操作会继续使用这个连接。

首先说一下TCP/IP详解上讲到的TCP保活功能,保活功能主要为服务器应用提供,服务器应用希望知道客户主机是否崩溃,从而可以代表客户使用资源。如果客户已经消失,使得服务器上保留一个半开放的连接,而服务器又在等待来自客户端的数据,则服务器将应远等待客户端的数据,保活功能就是试图在服务 器端检测到这种半开放的连接。

如果一个给定的连接在两小时内没有任何的动作,则服务器就向客户发一个探测报文段,客户主机必须处于以下4个状态之一:
  1. 客户主机依然正常运行,并从服务器可达。客户的TCP响应正常,而服务器也知道对方是正常的,服务器在两小时后将保活定时器复位。
  2. 客户主机已经崩溃,并且关闭或者正在重新启动。在任何一种情况下,客户的TCP都没有响应。服务端将不能收到对探测的响应,并在75秒后超时。服务器总共发送10个这样的探测 ,每个间隔75秒。如果服务器没有收到一个响应,它就认为客户主机已经关闭并终止连接。
  3. 客户主机崩溃并已经重新启动。服务器将收到一个对其保活探测的响应,这个响应是一个复位,使得服务器终止这个连接。
  4. 客户机正常运行,但是服务器不可达,这种情况与2类似,TCP能发现的就是没有收到探查的响应。

 
长连接短连接操作过程:
短连接的操作步骤是:建立连接——数据传输——关闭连接...建立连接——数据传输——关闭连接

长连接的操作步骤是:建立连接——数据传输...(保持连接)...数据传输——关闭连接
 
4、 长连接和短连接的优点和缺点
由上可以看出,长连接可以省去较多的TCP建立和关闭的操作,减少浪费,节约时间。对于频繁请求资源的客户来说,较适用长连接。不过这里存在一个问题,存活功能的探测周期太长,还有就是它只是探测TCP连接的存活,属于比较斯文的做法,遇到恶意的连接时,保活功能就不够使了。在长连接的应用场景下,client端一般不会主动关闭它们之间的连接,Client与server之间的连接如果一直不关闭的话,会存在一个问题,随着客户端连接越来越多,server早晚有扛不住的时候,这时候server端需要采取一些策略,如关闭一些长时间没有读写事件发生的连接,这样可 以避免一些恶意连接导致server端服务受损;如果条件再允许就可以以客户端机器为颗粒度,限制每个客户端的最大长连接数,这样可以完全避免某个蛋疼的客户端连累后端服务。

短连接对于服务器来说管理较为简单,存在的连接都是有用的连接,不需要额外的控制手段。但如果客户请求频繁,将在TCP的建立和关闭操作上浪费时间和带宽。

长连接和短连接的产生在于client和server采取的关闭策略,具体的应用场景采用具体的策略,没有十全十美的选择,只有合适的选择。
 
5、什么时候用长连接,短连接? 
长连接多用于操作频繁,点对点的通讯,而且连接数不能太多情况,。每个TCP连接都需要三步握手,这需要时间,如果每个操作都是先连接,再操作的话那么处理速度会降低很多,所以每个操作完后都不断开,次处理时直接发送数据包就OK了,不用建立TCP连接。例如:数据库的连接用长连接, 如果用短连接频繁的通信会造成socket错误,而且频繁的socket 创建也是对资源的浪费。 
  
而像WEB网站的http服务一般都用短链接,因为长连接对于服务端来说会耗费一定的资源,而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源,如果用长连接,而且同时有成千上万的用户,如果每个用户都占用一个连接的话,那可想而知吧。所以并发量大,但每个用户无需频繁操作情况下需用短连好。