export命令

功能说明：设置或显示环境变量。

语　　法：export [-fnp][变量名称]=[变量设置值]

补充说明：在shell中执行程序时，shell会提供一组环境变量。 export可新增，修改或删除环境变量，供后续执行的程序使用。

export的效力仅及于该此登陆操作。

参　　数：

    -f 　代表[变量名称]中为函数名称。

　 -n 　删除指定的变量。变量实际上并未删除，只是不会输出到后续指令的执行环境中。

　 -p 　列出所有的shell赋予程序的环境变量。

      一个变量创建时，它不会自动地为在它之后创建的shell进程所知。而命令export可以向后面的shell传递变量的值。当一个shell脚本调用并执行时，它不会自动得到原来脚本（调用者）里定义的变量的访问权，除非这些变量已经被显式地设置为可用。

      export命令可以用于传递一个或多个变量的值到任何后继脚本。

在 linux 里设置环境变量的三种实现方法（export PATH）：

1.直接使用 export 命令 （我们以 mysql 服务举例说明）

[root@liyao ~]# export PATH=$PATH:/usr/local/mysql/bin

查看是否已经设置好，可以使用命令 export 命令来查看，也可以直接$#变量名#来查看

zhongweichaomatoMacBook-Pro:~ zhongweichao$ $PATH

-bash: :/Users/zhongweichao/.local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/Users/zhongweichao/Develop/jboss-5.1.0.GA/bin

需要注意： 直接使用 export 设置的变量都是临时变量，也就是说退出当前的 shell ，为该变量定义的值便不会生效了。如何能让我们定义的变量永久生效呢？那就看我们的第二种定义的方式。

2. 修改 /etc/profile

[root@liyao ~]# vi /etc/profile

export PATH=$PATH:/usr/local/mysql/bin  # 在配置文件中加入此行配置

需要注意的是：修改完这个文件必须要使用 以下命令在不用重启系统的情况下使修改的内容生效。

[root@liyao ~]# source /etc/profile

或者是用 ‘.’：

[root@liyao ~]# . /etc/profile

查看：

[root@liyao ~]# echo $PATH

/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin:/usr/local/mysql/bin

# 配置已经生效

3. 修改 .bashrc 文件是在当前用户 shell 下生效

# vi /root/.bashrc?在里面加入：

export PATH=$PATH:/usr/local/mysql/bin

修改这个文件之后同样也需要使用 source 或者是 . 使配置文件生效。

再来使用 echo $PATH看下变量是否生效

[root@liyao ~]# echo $PATH

/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin:/usr/local/mysql/bin

shell与export命令

      用户登录到Linux系统后，系统将启动一个用户shell。在这个shell中，可以使用shell命令或声明变量，也可以创建并运行 shell脚本程序。运行shell脚本程序时，系统将创建一个子shell。此时，系统中将有两个shell，一个是登录时系统启动的shell，另一 个是系统为运行脚本程序创建的shell。当一个脚本程序运行完毕，它的脚本shell将终止，可以返回到执行该脚本之前的shell。从这种意义上来 说，用户可以有许多 shell，每个shell都是由某个shell（称为父shell）派生的。 

      在子 shell中定义的变量只在该子shell内有效。如果在一个shell脚本程序中定义了一个变量，当该脚本程序运行时，这个定义的变量只是该脚本程序内 的一个局部变量，其他的shell不能引用它，要使某个变量的值可以在其他shell中被改变，可以使用export命令对已定义的变量进行输出。 export命令将使系统在创建每一个新的shell时定义这个变量的一个拷贝。这个过程称之为变量输出。

一个简单的方法可以知道你的网站是因为什么原因慢：
 1). 如果是因为服务器上网站放的太多的原因，Discuz!程序左下脚的执行时间会比较大，一般会大到几秒，如果那个时间是0.0几秒的话，服务器负载是很清的。
 2).如果是网络原因，这时候你ping 你的域名一般都不理想，或者延迟大，或者丢包多。当然如果是网络慢那还要区分是服务器端网络的问题还是你个人那边网络的问题。
 3).如果排除以上原因，那就要仔细分析了，最常见的原因是挂了统计或广告代码。
 服务器：排除（同ip其它网站访问打开速度正常）
本地网络：排除（打开一些网站速度很快）
插件：排除（只有QQ互联） 页面数据太大 排除（以前打开很快。再说图片都是后加载）
数据库远程连接加载慢

（一） 基本语法 iptables-t filter -A INPUT -p icmp -j DROP 高级语法 iptables-t filter -A INPUT -m mac –mac-source 00:1C:23:3B:2E:B1 -j DROP 区别高级语法与基本语法的不同：首先filter的机制是由iptables_filter.ko模块所提供的功能，而这个模块本身就已提供了一些简单的匹配的过滤方式,而所谓的基本语法是指只使用iptable_filter.ko模块自身所提供的功能。高级语法必须调用其它模块的功能。以高级语法的范例为例，“-mmac”就是告知iptables工具，我们要动用xt_mac.ko模块的功能，由于是调用其它的模块，因此，语法的部分将会随着不同的模块而有所改变，而且每一个模块的语法也不一样，这就是所谓的“高级语法”。 举例1：将222.24.21.195送到本机的ICMP封包丢弃 语法：iptables-A INPUT -p icmp -s 222.24.21.195 -j DROP 语法解释： -AINPUT

-picmp

-s222.24.21.195

-j

较常见的处理方式:

举例2：不允许222.24.21.195主机通过本机DNS服务来执行名称解析 语法：iptables-A INPUT -p udp -s 222.24.21.195 --dport 53 -j REJECT 语法解释： --dport53

举例3：允许192.168.1.0/24网段的主机对192.168.0.1提出任何的服务请求 语法：iptables-A INPUT -p all -s 192.168.1.0/24 -d 192.168.0.1 -j ACCEPT 语法解释： -pall

-s192.168.1.0/24

-jACCEPT

举例4：只允许用户端主机从eth1访问的本机SSH服务 语法： iptables-A INPUT -p tcp -i eth1 --dport 22 -j ACCEPT 语法解释： -ieth1

举例5:不允许本机的应用程序从eth0接口送出封包去访问www.baidu.com网站 语法：iptables-A OUTPUT -o eth0 -p tcp -d www.baidu.com --dport 80 -j REJECT 语法解释： -AOUTPUT

（二） 有上面几个例子了解了iptables的基本语法,下面对参数进行整理总结。 （1）接口的匹配参数

（2）上层协议（UpperLayer Protocal）的匹配参数

（3）匹配来源/目的的IP地址

（4）匹配来源/目的的Port位置

（5）处理方式

在项目中，我们会需要获取接口的操作日志。比如获取接口的接口名、操作人，接口运行时间、所属的服务、接口的类型（增删改查）等等。初级的做法是在接口方法执行完后将这些操作记录存入库中，这段代码写在接口中，但是这样违反了设计原则中的单一职责原则。常用的做法是使用AOP来做，在运行时动态的插入日志记录的代码。这里我是用注解来做。

创建日志记录表

首先我们来创建日志记录表：

operation表

当然后编写实体类：

编写日志记录注解

我们先定义一个注解OperationLog

这个注解里面定义了几个参数：

“

opType：业务类型

opBusinessName：业务名称，例如会员服务、订单服务等等

opBusinessId：业务来源ID，一般为主键ID

”

定义业务类型类OperationType

这个业务类型类定义了接口的类型：增删改查。

接下来我们编写切面类OperationLogAspect

获取方法上面的注解：

Method method = ((MethodSignature) pjp.getSignature()).getMethod();//获取目标方法上面的注解OperationLog opLog = method.getAnnotation(OperationLog.class);

执行目标方法：

try {    // 执行目标方法    result = pjp.proceed();} catch (Throwable throwable) {    throw new Exception(throwable);}

在执行目标方法前后记录执行时间：

TimeInterval timer = DateUtil.timer();... // 执行目标方法...long executeTime = timer.intervalRestart(); 

解析注解上的表达式，就是获取业务id：

// 解析表达式，获取结果String itemId = String.valueOf(expression.getValue(context));

将数据封装到对象中：

Operation operation = Operation.builder()                    //.id(snowflake.nextId())                    .opType(opLog.opType().name())                    .opBusinessName(opLog.opBusinessName())                    .opBusinessId(itemId)                    .opTime(String.valueOf(executeTime))                    //这里可以添加操作人                    .build();

记录日志并入库：

private void handle(Operation operation) {    // 通过日志打印输出    log.info("opType = " + operation.getOpType() + ",opItem = " + operation.getOpBusinessName() + ",opItemId = " + operation.getOpBusinessId() + ",opTime = " + operation.getOpTime());    // 持久化入库    operationService.save(operation);}

整体代码如下：

测试注解

测试注解代码如下：

@RequestMapping("/getById")@ResponseBody@OperationLog(opType = OperationType.QUERY,opBusinessName = "会员服务",opBusinessId = "#id")public Member getById(@RequestParam String id) {    return memberService.getById(id);}

我们在这个接口getById上添加了注解@OperationLog，表明我们想记录这个接口的操作记录。opType为查询类型，所属的业务为会员服务，业务id为接口的参数id。

启动代码运行接口：

控制台打印了日志：

并且数据库也有了记录：

代码到这里就结束了，当然我们还可以在日志记录表中添加接口名的路径、以及接口的调用链等信息。

限流算法目前程序开636f70793231313335323631343130323136353331333433663032发过程常用的限流算法有两个：漏桶算法和令牌桶算法。

漏桶算法

漏桶算法的原理比较简单，请求进入到漏桶中，漏桶以一定的速率漏水。当请求过多时，水直接溢出。可以看出，漏桶算法可以强制限制数据的传输速度。如图所示，把请求比作是水滴，水先滴到桶里，通过漏洞并以限定的速度出水，当水来得过猛而出水不够快时就会导致水直接溢出，即拒绝服务。

图片来自网络

漏桶的出水速度是恒定的，那么意味着如果瞬时大流量的话，将有大部分请求被丢弃掉(也就是所谓的溢出)。

令牌桶算法

令牌桶算法的原理是系统以一定速率向桶中放入令牌，如果有请求时，请求会从桶中取出令牌，如果能取到令牌，则可以继续完成请求，否则等待或者拒绝服务。这种算法可以应对突发程度的请求，因此比漏桶算法好。

图片来自网络

漏桶算法和令牌桶算法的选择

两者的主要区别漏桶算法能够强行限制处理数据的速率，不论系统是否空闲。而令牌桶算法能够在限制数据的平均处理速率的同时还允许某种程度的突发流量。如何理解上面的含义呢？漏桶算法，比如系统吞吐量是 120/s，业务请求 130/s，使用漏斗限流 100/s，起到限流的作用，多余的请求将产生等待或者丢弃。对于令牌桶算法，每秒产生 100 个令牌，系统容量 200 个令牌。正常情况下，业务请求 100/s 时，请求能被正常被处理。当有突发流量过来比如 200 个请求时，因为系统容量有 200 个令牌可以同一时刻处理掉这 200 个请求。如果是漏桶算法，则只能处理 100 个请求，其他的请求等待或者被丢弃。