@Component
public class MyBeanPostProcessor implements BeanPostProcessor{
//在每个bean初始化后，初始化方法执行后，都执行
的方法
@Override
public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
System.out.println("postProcessAfterInitialization=="+beanName);
return BeanPostProcessor.super.postProcessAfterInitialization(bean, beanName);
}
//在每个bean初始化后，在初始化方法执行前，都执行的方法
@Override
public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
System.out.println("postProcessBeforeInitialization=="+beanName);
return BeanPostProcessor.super.postProcessBeforeInitialization(bean, beanName);
}
}
三种初始化方式
public class Cat {
@PostConstruct//初始化
public void afterPropertiesSet() throws Exception {
System.out.println(" cat init");
}
@PreDestroy//销毁
public void destroy() throws Exception {
System.out.println("cat destroy");
}
}
public class User implements InitializingBean,DisposableBean{
public String toString() {
return "444";
}
@Override//初始化
public void afterPropertiesSet() throws Exception {
System.out.println(" user afterPropertiesSet");
}
@Override//销毁
public void destroy() throws Exception {
System.out.println("user destroy");
}
}
public class Room {
//初始化
public void afterPropertiesSet() throws Exception {
System.out.println(" room afterPropertiesSet");
}
//销毁
public void destroy() throws Exception {
System.out.println("room destroy");
}
}
@Configuration
public class Cfg1 {
@Bean
public Cat getCat() {
return new Cat();
}
@Bean
public User getUser() {
return new User();
}
@Bean(initMethod="afterPropertiesSet",destroyMethod="destroy")
public Room getRoom() {
return new Room();
}
}
@Configuration
public class RedisClusterConfig {
@Value("${spring.redis.cluster.nodes}")
private String clusterNodes;
@Bean
public JedisCluster getJedisCluster() {
// 截取集群节点
String[] cluster = clusterNodes.split(",");
// 创建set集合
Set<HostAndPort> nodes = new HashSet<HostAndPort>();
// 循环数组把集群节点添加到set集合中
for (String node : cluster) {
String[] host = node.split(":");
//添加集群节点
nodes.add(new HostAndPort(host[0], Integer.parseInt(host[1])));
}
JedisCluster jc = new JedisCluster(nodes);
return jc;
}
}
在application.properties文件中，配置spring.redis.cluster.nodes=
在使用的时候直接得到JedisCluster对象使用
一、Redis提供了哪些持久化机制：
1). RDB持久化：
该机制是指在指定的时间间隔内将内存中的数据集快照写入磁盘。
2). AOF持久化:
该机制将以日志的形式记录服务器所处理的每一个写操作，在Redis服务器启动之初会读取该文件来重新构建数据库，以保证启动后数据库中的数据是完整的。
3). 无持久化：
我们可以通过配置的方式禁用Redis服务器的持久化功能，这样我们就可以将Redis视为一个功能加强版的memcached了。
4). 同时应用AOF和RDB。
二、RDB机制的优势和劣势：
RDB存在哪些优势呢？
1). 一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。
2). 对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。
3). 性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。
4). 相比于AOF机制，如果数据集很大，RDB的启动效率会更高。
RDB又存在哪些劣势呢？
1). 如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。
2). 由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。
三、AOF机制的优势和劣势：
AOF的优势有哪些呢？
1). 该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。至于无同步，无需多言，我想大家都能正确的理解它。
2). 由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。
3). 如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。
4). AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。
AOF的劣势有哪些呢？
1). 对于相同数量的数据集而言，AOF文件通常要大于RDB文件。
2). 根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。
四、其它：
1. Snapshotting:
缺省情况下，Redis会将数据集的快照dump到dump.rdb文件中。此外，我们也可以通过配置文件来修改Redis服务器dump快照的频率，在打开6379.conf文件之后，我们搜索save，可以看到下面的配置信息：
save 900 1 #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。
save 300 10 #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。
save 60 10000 #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。
2. Dump快照的机制：
1). Redis先fork子进程。
2). 子进程将快照数据写入到临时RDB文件中。
3). 当子进程完成数据写入操作后，再用临时文件替换老的文件。
3. AOF文件：
上面已经多次讲过，RDB的快照定时dump机制无法保证很好的数据持久性。如果我们的应用确实非常关注此点，我们可以考虑使用Redis中的AOF机制。对于Redis服务器而言，其缺省的机制是RDB，如果需要使用AOF，则需要修改配置文件中的以下条目：
将appendonly no改为appendonly yes
从现在起，Redis在每一次接收到数据修改的命令之后，都会将其追加到AOF文件中。在Redis下一次重新启动时，需要加载AOF文件中的信息来构建最新的数据到内存中。
4. AOF的配置：
在Redis的配置文件中存在三种同步方式，它们分别是：
appendfsync always #每次有数据修改发生时都会写入AOF文件。
appendfsync everysec #每秒钟同步一次，该策略为AOF的缺省策略。
appendfsync no #从不同步。高效但是数据不会被持久化。
5. 如何修复坏损的AOF文件：
1). 将现有已经坏损的AOF文件额外拷贝出来一份。
2). 执行"redis-check-aof --fix <filename>"命令来修复坏损的AOF文件。
3). 用修复后的AOF文件重新启动Redis服务器。
6. Redis的数据备份：
在Redis中我们可以通过copy的方式在线备份正在运行的Redis数据文件。这是因为RDB文件一旦被生成之后就不会再被修改。Redis每次都是将最新的数据dump到一个临时文件中，之后在利用rename函数原子性的将临时文件改名为原有的数据文件名。因此我们可以说，在任意时刻copy数据文件都是安全的和一致的。鉴于此，我们就可以通过创建cron job的方式定时备份Redis的数据文件，并将备份文件copy到安全的磁盘介质中。
安装
1/到官网下载最新stable版
2/解压源码并进入目录
3/ make
4/ 可选 make test （可能出现need tcl>8.4,yum install tcl）
5/安装到指定目录,如 /usr/local/redis
make PREFIX=/usr/local/redis install
运行
./bin/redis-server redis-2.8.19/redis.conf
(默认前端运行模式。后台进程模式： 修改conf daemonize yes)
连接
[root@bogon redis]# ./bin/redis-cli
127.0.0.1:6379> set a bb
OK
127.0.0.1:6379> get a
"bb"
127.0.0.1:6379> get aa
(nil)
127.0.0.1:6379>
后来发现了logratate这个工具，Ubuntu
下的mysql，nginx好像也是用的这个工具还定期整理log的。配置文件为/etc/logrotate.conf，和很多其它ubuntu下的工
具一下，也可以把配置文件写在/etc/logrotate.d/下面。如对我们的tomcat的log文件进行整理，sudo vi
/etc/logrotate.d/tomcat，
/opt/tomcat/logs/catalina.out {
rotate 14
daily
copytruncate
compress
notifempty
missingok
}
其中：
rotate 7 表示保留7天的备份文件
daily 表示每天整理一次
copytruncate 表示先复制log文件的内容，然后再清空
compress 表示压缩备分文件
missingok 表示如果找不到log文件也没OK
notifempty 表示如果log文件是空的，就不进行rotate
可以通过/usr/sbin/logrotate -f /etc/logrotate.conf来执行。Ubuntu
有/etc/cron.daily/logrotate文件，内容为:
#!/bin/sh
test -x /usr/sbin/logrotate || exit 0
/usr/sbin/logrotate /etc/logrotate.conf
表示每天会定时执行一次这个命令
通过ntp同步服务器的时间
根据 Ubuntu 的文档 有两种方式可以用来使服务器的时间和ntp server同步。一种是通过ntpdate命令，如
ntpdate ntp.Ubuntu .com
然后在/etc/cron.daily/下新建一个文件来每天执行一次这个命令
另一种是通过ntpd来更新。sudo apt-get install
ntp。配置文件/etc/ntp.conf，可以通过修改配置文件为改变ntp server，
我们用的是210.72.145.44这个server
对于Linux 的系统安全来说，日志文件是极其重要的工具。系统管理员可以使用logrotate
程序用来管理系统中的最新的事件，对于Linux 的系统安全来说，日志文件是极其重要的工具。系统管理员可以使用logrotate
程序用来管理系统中的最新的事件。logrotate 还可以用来备份日志文件，本篇将通过以下几部分来介绍
日志文件的管理：
1、logrotate 配置
2、缺省配置 logrotate
3、使用include 选项读取其他配置文件
4、使用include 选项覆盖缺省配置
5、为指定的文件配置转储参数
一、logrotate 配置
logrotate
程序是一个日志文件管理工具。用来把旧的日志文件删除，并创建新的日志文件，我们把它叫做“转储”。我们可以根据日志文件的大小，也可以根据其天数来转储，这个过程一般通过
cron 程序来执行。
logrotate 程序还可以用于压缩日志文件，以及发送日志到指定的E-mail 。
logrotate 的配置文件是 /etc/logrotate.conf。主要参数如下表：
参数 功能
compress 通过gzip 压缩转储以后的日志
nocompress 不需要压缩时，用这个参数
copytruncate 用于还在打开中的日志文件，把当前日志备份并截断
nocopytruncate 备份日志文件但是不截断
create mode owner group 转储文件，使用指定的文件模式创建新的日志文件
nocreate 不建立新的日志文件
delaycompress 和 compress 一起使用时，转储的日志文件到下一次转储时才压缩
nodelaycompress 覆盖 delaycompress 选项，转储同时压缩。
errors address 专储时的错误信息发送到指定的Email 地址
ifempty 即使是空文件也转储，这个是 logrotate 的缺省选项。
notifempty 如果是空文件的话，不转储
mail address 把转储的日志文件发送到指定的E-mail 地址
nomail 转储时不发送日志文件
olddir directory 转储后的日志文件放入指定的目录，必须和当前日志文件在同一个文件系统
noolddir 转储后的日志文件和当前日志文件放在同一个目录下
prerotate/endscript 在转储以前需要执行的命令可以放入这个对，这两个关键字必须单独成行
postrotate/endscript 在转储以后需要执行的命令可以放入这个对，这两个关键字必须单独成行
daily 指定转储周期为每天
weekly 指定转储周期为每周
monthly 指定转储周期为每月
rotate count 指定日志文件删除之前转储的次数，0 指没有备份，5 指保留5 个备份
tabootext [+] list 让logrotate 不转储指定扩展名的文件，缺省的扩展名是：.rpm-orig,
.rpmsave, v, 和 ~
size size 当日志文件到达指定的大小时才转储，Size 可以指定 bytes (缺省)以及KB
(sizek)或者MB (sizem).cat /dev/null >catalina.out
后来发现了logratate这个工具，Ubuntu
下的mysql，nginx好像也是用的这个工具还定期整理log的。配置文件为/etc/logrotate.conf，和很多其它ubuntu下的工
具一下，也可以把配置文件写在/etc/logrotate.d/下面。如对我们的tomcat的log文件进行整理，sudo vi
/etc/logrotate.d/tomcat，
/opt/tomcat/logs/catalina.out {
rotate 14
daily
copytruncate
compress
notifempty
missingok
}
其中：
rotate 7 表示保留7天的备份文件
daily 表示每天整理一次
copytruncate 表示先复制log文件的内容，然后再清空
compress 表示压缩备分文件
missingok 表示如果找不到log文件也没OK
notifempty 表示如果log文件是空的，就不进行rotate
可以通过/usr/sbin/logrotate -f /etc/logrotate.conf来执行。Ubuntu
有/etc/cron.daily/logrotate文件，内容为:
#!/bin/sh
test -x /usr/sbin/logrotate || exit 0
/usr/sbin/logrotate /etc/logrotate.conf
表示每天会定时执行一次这个命令
通过ntp同步服务器的时间
根据 Ubuntu 的文档 有两种方式可以用来使服务器的时间和ntp server同步。一种是通过ntpdate命令，如
ntpdate ntp.Ubuntu .com
然后在/etc/cron.daily/下新建一个文件来每天执行一次这个命令
另一种是通过ntpd来更新。sudo apt-get install
ntp。配置文件/etc/ntp.conf，可以通过修改配置文件为改变ntp server，
我们用的是210.72.145.44这个server
对于Linux 的系统安全来说，日志文件是极其重要的工具。系统管理员可以使用logrotate
程序用来管理系统中的最新的事件，对于Linux 的系统安全来说，日志文件是极其重要的工具。系统管理员可以使用logrotate
程序用来管理系统中的最新的事件。logrotate 还可以用来备份日志文件，本篇将通过以下几部分来介绍
日志文件的管理：
1、logrotate 配置
2、缺省配置 logrotate
3、使用include 选项读取其他配置文件
4、使用include 选项覆盖缺省配置
5、为指定的文件配置转储参数
一、logrotate 配置
logrotate
程序是一个日志文件管理工具。用来把旧的日志文件删除，并创建新的日志文件，我们把它叫做“转储”。我们可以根据日志文件的大小，也可以根据其天数来转储，这个过程一般通过
cron 程序来执行。
logrotate 程序还可以用于压缩日志文件，以及发送日志到指定的E-mail 。
logrotate 的配置文件是 /etc/logrotate.conf。主要参数如下表：
参数 功能
compress 通过gzip 压缩转储以后的日志
nocompress 不需要压缩时，用这个参数
copytruncate 用于还在打开中的日志文件，把当前日志备份并截断
nocopytruncate 备份日志文件但是不截断
create mode owner group 转储文件，使用指定的文件模式创建新的日志文件
nocreate 不建立新的日志文件
delaycompress 和 compress 一起使用时，转储的日志文件到下一次转储时才压缩
nodelaycompress 覆盖 delaycompress 选项，转储同时压缩。
errors address 专储时的错误信息发送到指定的Email 地址
ifempty 即使是空文件也转储，这个是 logrotate 的缺省选项。
notifempty 如果是空文件的话，不转储
mail address 把转储的日志文件发送到指定的E-mail 地址
nomail 转储时不发送日志文件
olddir directory 转储后的日志文件放入指定的目录，必须和当前日志文件在同一个文件系统
noolddir 转储后的日志文件和当前日志文件放在同一个目录下
prerotate/endscript 在转储以前需要执行的命令可以放入这个对，这两个关键字必须单独成行
postrotate/endscript 在转储以后需要执行的命令可以放入这个对，这两个关键字必须单独成行
daily 指定转储周期为每天
weekly 指定转储周期为每周
monthly 指定转储周期为每月
rotate count 指定日志文件删除之前转储的次数，0 指没有备份，5 指保留5 个备份
tabootext [+] list 让logrotate 不转储指定扩展名的文件，缺省的扩展名是：.rpm-orig,
.rpmsave, v, 和 ~
size size 当日志文件到达指定的大小时才转储，Size 可以指定 bytes (缺省)以及KB
(sizek)或者MB (sizem).
原文来自http://note.youdao.com/share/web/file.html?id=236896997b6ffbaa8e0d92eacd13abbf&type=note
我怕链接会失效，故转载此篇文章
由于linux目前很热门，越来越多的人在学习linux，但是买一台服务放家里来学习，实在是很浪费。那么如何解决这个问题？虚拟机软件是很好的选择，常用的虚拟机软件有vmware workstations和virtual box等。在使用虚拟机软件的时候，很多初学者都会遇到很多问题，而vmware的网络连接问题是大家遇到最多问题之一。在学习交流群里面，几乎每天都会有同学问到这些问题，写这篇详解也是因为群里童鞋网络出故障，然后在帮他解决的过程中，对自己的理解也做一个总结。接下来，我们就一起来探讨一下关于vmware workstations网络连接的三种模式。
vmware为我们提供了三种网络工作模式，它们分别是：Bridged（桥接模式）、NAT（网络地址转换模式）、Host-Only（仅主机模式）。
打开vmware虚拟机，我们可以在选项栏的“编辑”下的“虚拟网络编辑器”中看到VMnet0（桥接模式）、VMnet1（仅主机模式）、VMnet8（NAT模式），那么这些都是有什么作用呢？其实，我们现在看到的VMnet0表示的是用于桥接模式下的虚拟交换机；VMnet1表示的是用于仅主机模式下的虚拟交换机；VMnet8表示的是用于NAT模式下的虚拟交换机。
同时，在主机上对应的有VMware Network Adapter VMnet1和VMware Network Adapter VMnet8两块虚拟网卡，它们分别作用于仅主机模式与NAT模式下。在“网络连接”中我们可以看到这两块虚拟网卡，如果将这两块卸载了，可以在vmware的“编辑”下的“虚拟网络编辑器”中点击“还原默认设置”，可重新将虚拟网卡还原。
小伙伴看到这里，肯定有疑问，为什么在真机上没有VMware Network Adapter VMnet0虚拟网卡呢？那么接下来，我们就一起来看一下这是为什么。
一、Bridged（桥接模式）
什么是桥接模式？桥接模式就是将主机网卡与虚拟机虚拟的网卡利用虚拟网桥进行通信。在桥接的作用下，类似于把物理主机虚拟为一个交换机，所有桥接设置的虚拟机连接到这个交换机的一个接口上，物理主机也同样插在这个交换机当中，所以所有桥接下的网卡与网卡都是交换模式的，相互可以访问而不干扰。在桥接模式下，虚拟机ip地址需要与主机在同一个网段，如果需要联网，则网关与DNS需要与主机网卡一致。其网络结构如下图所示：
接下来，我们就来实际操作，如何设置桥接模式。
首先，安装完系统之后，在开启系统之前，点击“编辑虚拟机设置”来设置网卡模式。
点击“网络适配器”，选择“桥接模式”，然后“确定”
在进入系统之前，我们先确认一下主机的ip地址、网关、DNS等信息。
然后，进入系统编辑网卡配置文件，命令为vi /etc/sysconfig/network-scripts/ifcfg-eth0
添加内容如下：
编辑完成，保存退出，然后重启虚拟机网卡，使用ping命令ping外网ip，测试能否联网。
能ping通外网ip，证明桥接模式设置成功。
那主机与虚拟机之间的通信是否正常呢？我们就用远程工具来测试一下。
主机与虚拟机通信正常。
这就是桥接模式的设置步骤，相信大家应该学会了如何去设置桥接模式了。桥接模式配置简单，但如果你的网络环境是ip资源很缺少或对ip管理比较严格的话，那桥接模式就不太适用了。如果真是这种情况的话，我们该如何解决呢？接下来，我们就来认识vmware的另一种网络模式：NAT模式。
二、NAT（地址转换模式）
刚刚我们说到，如果你的网络ip资源紧缺，但是你又希望你的虚拟机能够联网，这时候NAT模式是最好的选择。NAT模式借助虚拟NAT设备和虚拟DHCP服务器，使得虚拟机可以联网。其网络结构如下图所示：
在NAT模式中，主机网卡直接与虚拟NAT设备相连，然后虚拟NAT设备与虚拟DHCP服务器一起连接在虚拟交换机VMnet8上，这样就实现了虚拟机联网。那么我们会觉得很奇怪，为什么需要虚拟网卡VMware Network Adapter VMnet8呢？原来我们的VMware Network Adapter VMnet8虚拟网卡主要是为了实现主机与虚拟机之间的通信。在之后的设置步骤中，我们可以加以验证。
首先，设置虚拟机中NAT模式的选项，打开vmware，点击“编辑”下的“虚拟网络编辑器”，设置NAT参数及DHCP参数。
将虚拟机的网络连接模式修改成NAT模式，点击“编辑虚拟机设置”。
点击“网络适配器”，选择“NAT模式”
然后开机启动系统，编辑网卡配置文件，命令为vi /etc/sysconfig/network-scripts/ifcfg-eth0
具体配置如下：
编辑完成，保存退出，然后重启虚拟机网卡，动态获取ip地址，使用ping命令ping外网ip，测试能否联网。
之前，我们说过VMware Network Adapter VMnet8虚拟网卡的作用，那我们现在就来测试一下。
如此看来，虚拟机能联通外网，确实不是通过VMware Network Adapter VMnet8虚拟网卡，那么为什么要有这块虚拟网卡呢？
之前我们就说VMware Network Adapter VMnet8的作用是主机与虚拟机之间的通信，接下来，我们就用远程连接工具来测试一下。
然后，将VMware Network Adapter VMnet8启用之后，发现远程工具可以连接上虚拟机了。
那么，这就是NAT模式，利用虚拟的NAT设备以及虚拟DHCP服务器来使虚拟机连接外网，而VMware Network Adapter VMnet8虚拟网卡是用来与虚拟机通信的。
三、Host-Only（仅主机模式）
Host-Only模式其实就是NAT模式去除了虚拟NAT设备，然后使用VMware Network Adapter VMnet1虚拟网卡连接VMnet1虚拟交换机来与虚拟机通信的，Host-Only模式将虚拟机与外网隔开，使得虚拟机成为一个独立的系统，只与主机相互通讯。其网络结构如下图所示：
通过上图，我们可以发现，如果要使得虚拟机能联网，我们可以将主机网卡共享给VMware Network Adapter VMnet1网卡，从而达到虚拟机联网的目的。接下来，我们就来测试一下。
首先设置“虚拟网络编辑器”，可以设置DHCP的起始范围。
设置虚拟机为Host-Only模式。
开机启动系统，然后设置网卡文件。
保存退出，然后重启网卡，利用远程工具测试能否与主机通信。
主机与虚拟机之间可以通信，现在设置虚拟机联通外网。
我们可以看到上图有一个提示，强制将VMware Network Adapter VMnet1的ip设置成192.168.137.1，那么接下来，我们就要将虚拟机的DHCP的子网和起始地址进行修改，点击“虚拟网络编辑器”
重新配置网卡，将VMware Network Adapter VMnet1虚拟网卡作为虚拟机的路由。
重启网卡，然后通过 远程工具测试能否联通外网以及与主机通信。
测试结果证明可以使得虚拟机连接外网。
以上就是关于vmware三种网络模式的工作原理及配置详解。
Map<String,String> map=new HashMap<String,String>();
map.put("1", "222");
List<Map<String,String>> list = new ArrayList<Map<String,String>>();
list.add(map);
map=null;//没有效果，list中还是有数据
map.clear();//map没数据了
Map<String, String> map2 = list.get(0);
System.out.println(map2.size());
System.out.println(map2.get("1"));
背景
通过名字就知道，X-Forwarded-For 是一个 HTTP 扩展头部。HTTP/1.1（RFC 2616）协议并没有对它的定义，它最开始是由 Squid 这个缓存代理软件引入，用来表示 HTTP 请求端真实 IP。如今它已经成为事实上的标准，被各大 HTTP 代理、负载均衡等转发服务广泛使用，并被写入 RFC 7239（Forwarded HTTP Extension）标准之中。
X-Forwarded-For 请求头格式非常简单，就这样：
X-Forwarded-For: client, proxy1, proxy2
可以看到，XFF 的内容由「英文逗号 + 空格」隔开的多个部分组成，最开始的是离服务端最远的设备 IP，然后是每一级代理设备的 IP。
如果一个 HTTP 请求到达服务器之前，经过了三个代理 Proxy1、Proxy2、Proxy3，IP 分别为 IP1、IP2、IP3，用户真实 IP 为 IP0，那么按照 XFF 标准，服务端最终会收到以下信息：
X-Forwarded-For: IP0, IP1, IP2
Proxy3 直连服务器，它会给 XFF 追加 IP2，表示它是在帮 Proxy2 转发请求。列表中并没有 IP3，IP3 可以在服务端通过 Remote Address 字段获得。我们知道 HTTP 连接基于 TCP 连接，HTTP 协议中没有 IP 的概念，Remote Address 来自 TCP 连接，表示与服务端建立 TCP 连接的设备 IP，在这个例子里就是 IP3。
Remote Address 无法伪造，因为建立 TCP 连接需要三次握手，如果伪造了源 IP，无法建立 TCP 连接，更不会有后面的 HTTP 请求。不同语言获取 Remote Address 的方式不一样，例如 php 是 $_SERVER["REMOTE_ADDR"]，Node.js 是 req.connection.remoteAddress，但原理都一样。
问题
有了上面的背景知识，开始说问题。我用 Node.js 写了一个最简单的 Web Server 用于测试。HTTP 协议跟语言无关，这里用 Node.js 只是为了方便演示，换成任何其他语言都可以得到相同结论。另外本文用 Nginx 也是一样的道理，如果有兴趣，换成 Apache 或其他 Web Server 也一样。
下面这段代码会监听 9009 端口，并在收到 HTTP 请求后，输出一些信息：
JSvar http = require('http'); http.createServer(function (req, res) { res.writeHead(200, {'Content-Type': 'text/plain'}); res.write('remoteAddress: ' + req.connection.remoteAddress + '\n'); res.write('x-forwarded-for: ' + req.headers['x-forwarded-for'] + '\n'); res.write('x-real-ip: ' + req.headers['x-real-ip'] + '\n'); res.end(); }).listen(9009, '0.0.0.0');
这段代码除了前面介绍过的 Remote Address 和 X-Forwarded-For，还有一个 X-Real-IP，这又是一个自定义头部字段。X-Real-IP 通常被 HTTP 代理用来表示与它产生 TCP 连接的设备 IP，这个设备可能是其他代理，也可能是真正的请求端。需要注意的是，X-Real-IP 目前并不属于任何标准，代理和 Web 应用之间可以约定用任何自定义头来传递这个信息。
现在可以用域名 + 端口号直接访问这个 Node.js 服务，再配一个 Nginx 反向代理：
NGINXlocation / { proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_set_header X-NginX-Proxy true; proxy_pass http://127.0.0.1:9009/; proxy_redirect off; }
我的 Nginx 监听 80 端口，所以不带端口就可以访问 Nginx 转发过的服务。
测试直接访问 Node 服务：
BASHcurl http://t1.imququ.com:9009/ remoteAddress: 114.248.238.236 x-forwarded-for: undefined x-real-ip: undefined
由于我的电脑直接连接了 Node.js 服务，Remote Address 就是我的 IP。同时我并未指定额外的自定义头，所以后两个字段都是 undefined。
再来访问 Nginx 转发过的服务：
BASHcurl http://t1.imququ.com/ remoteAddress: 127.0.0.1 x-forwarded-for: 114.248.238.236 x-real-ip: 114.248.238.236
这一次，我的电脑是通过 Nginx 访问 Node.js 服务，得到的 Remote Address 实际上是 Nginx 的本地 IP。而前面 Nginx 配置中的这两行起作用了，为请求额外增加了两个自定义头：
proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
实际上，在生产环境中部署 Web 应用，一般都采用上面第二种方式，有很多好处。但这就引入一个隐患：很多 Web 应用为了获取用户真正的 IP，从 HTTP 请求头中获取 IP。
HTTP 请求头可以随意构造，我们通过 curl 的 -H 参数构造 X-Forwarded-For 和 X-Real-IP，再来测试一把。
直接访问 Node.js 服务：
BASHcurl http://t1.imququ.com:9009/ -H 'X-Forwarded-For: 1.1.1.1' -H 'X-Real-IP: 2.2.2.2' remoteAddress: 114.248.238.236 x-forwarded-for: 1.1.1.1 x-real-ip: 2.2.2.2
对于 Web 应用来说，X-Forwarded-For 和 X-Real-IP 就是两个普通的请求头，自然就不做任何处理原样输出了。这说明，对于直连部署方式，除了从 TCP 连接中得到的 Remote Address 之外，请求头中携带的 IP 信息都不能信。
访问 Nginx 转发过的服务：
BASHcurl http://t1.imququ.com/ -H 'X-Forwarded-For: 1.1.1.1' -H 'X-Real-IP: 2.2.2.2' remoteAddress: 127.0.0.1 x-forwarded-for: 1.1.1.1, 114.248.238.236 x-real-ip: 114.248.238.236
这一次，Nginx 会在 X-Forwarded-For 后追加我的 IP；并用我的 IP 覆盖 X-Real-IP 请求头。这说明，有了 Nginx 的加工，X-Forwarded-For 最后一节以及 X-Real-IP 整个内容无法构造，可以用于获取用户 IP。
用户 IP 往往会被使用与跟 Web 安全有关的场景上，例如检查用户登录地区，基于 IP 做访问频率控制等等。这种场景下，确保 IP 无法构造更重要。经过前面的测试和分析，对于直接面向用户部署的 Web 应用，必须使用从 TCP 连接中得到的 Remote Address；对于部署了 Nginx 这样反向代理的 Web 应用，在正确配置了 Set Header 行为后，可以使用 Nginx 传过来的 X-Real-IP 或 X-Forwarded-For 最后一节（实际上它们一定等价）。
那么，Web 应用自身如何判断请求是直接过来，还是由可控的代理转发来的呢？在代理转发时增加额外的请求头是一个办法，但是不怎么保险，因为请求头太容易构造了。如果一定要这么用，这个自定义头要够长够罕见，还要保管好不能泄露出去。
判断 Remote Address 是不是本地 IP 也是一种办法，不过也不完善，因为在 Nginx 所处服务器上访问，无论直连还是走 Nginx 代理，Remote Address 都是 127.0.0.1。这个问题还好通常可以忽略，更麻烦的是，反向代理服务器和实际的 Web 应用不一定部署在同一台服务器上。所以更合理的做法是收集所有代理服务器 IP 列表，Web 应用拿到 Remote Address 后逐一比对来判断是以何种方式访问。
通常，为了简化逻辑，生产环境会封掉通过带端口直接访问 Web 应用的形式，只允许通过 Nginx 来访问。那是不是这样就没问题了呢？也不见得。
首先，如果用户真的是通过代理访问 Nginx，X-Forwarded-For 最后一节以及 X-Real-IP 得到的是代理的 IP，安全相关的场景只能用这个，但有些场景如根据 IP 显示所在地天气，就需要尽可能获得用户真实 IP，这时候 X-Forwarded-For 中第一个 IP 就可以排上用场了。这时候需要注意一个问题，还是拿之前的例子做测试：
BASHcurl http://t1.imququ.com/ -H 'X-Forwarded-For: unknown, <>"1.1.1.1' remoteAddress: 127.0.0.1 x-forwarded-for: unknown, <>"1.1.1.1, 114.248.238.236 x-real-ip: 114.248.238.236
X-Forwarded-For 最后一节是 Nginx 追加上去的，但之前部分都来自于 Nginx 收到的请求头，这部分用户输入内容完全不可信。使用时需要格外小心，符合 IP 格式才能使用，不然容易引发 SQL 注入或 XSS 等安全漏洞。
结论
- 直接对外提供服务的 Web 应用，在进行与安全有关的操作时，只能通过 Remote Address 获取 IP，不能相信任何请求头；
- 使用 Nginx 等 Web Server 进行反向代理的 Web 应用，在配置正确的前提下，要用
X-Forwarded-For 最后一节 或 X-Real-IP 来获取 IP（因为 Remote Address 得到的是 Nginx 所在服务器的内网 IP）；同时还应该禁止 Web 应用直接对外提供服务； - 在与安全无关的场景，例如通过 IP 显示所在地天气，可以从
X-Forwarded-For 靠前的位置获取 IP，但是需要校验 IP 格式合法性；
PS：网上有些文章建议这样配置 Nginx，其实并不合理：
proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $remote_addr;
这样配置之后，安全性确实提高了，但是也导致请求到达 Nginx 之前的所有代理信息都被抹掉，无法为真正使用代理的用户提供更好的服务。还是应该弄明白这中间的原理，具体场景具体分析。
proxy_intercept_errors on; #如果被代理服务器返回的状态码为400或者大于400，设置的error_page配置起作用。默认为off。
error_page 404 https://www.baidu.com; #错误页
如果我们的代理只允许接受get，post请求方法的一种
proxy_method get; #支持客户端的请求方法。post/get；
如果你的nginx服务器给2台web服务器做代理，负载均衡算法采用轮询，那么当你的一台机器web程序iis关闭，也就是说web不能访问，那么nginx服务器分发请求还是会给这台不能访问的web服务器，如果这里的响应连接时间过长，就会导致客户端的页面一直在等待响应，对用户来说体验就打打折扣，这里我们怎么避免这样的情况发生呢。这里我配张图来说明下问题。
如果负载均衡中其中web2发生这样的情况，nginx首先会去web1请求，但是nginx在配置不当的情况下会继续分发请求道web2，然后等待web2响应，直到我们的响应时间超时，才会把请求重新分发给web1，这里的响应时间如果过长，用户等待的时间就会越长。
下面的配置是解决方案之一。
proxy_connect_timeout 1; #nginx服务器与被代理的服务器建立连接的超时时间，默认60秒
proxy_read_timeout 1; #nginx服务器想被代理服务器组发出read请求后，等待响应的超时间，默认为60秒。
proxy_send_timeout 1; #nginx服务器想被代理服务器组发出write请求后，等待响应的超时间，默认为60秒。
proxy_ignore_client_abort on; #客户端断网时，nginx服务器是否终端对被代理服务器的请求。默认为off。