前言

本文参照互联网上一篇文章进行实际操作， 但是在搭建elk平台过程中， 采用docker方式进行， 因此节省了部属的繁琐过程，因此把基于docker的操作过程， 穿插到原文中。

为了， 获取一个docker环境，  取决于您的操作系统， 对于linux本身大部分新版本的都支持docker了， 对于windows和mac os系统， 您需要安装一定的虚拟机， 或者docker tools（其实也是虚拟机，只是操作方便）。

这里是在windows上安装了vmware， 然后在vm中安装了centos系统， 然后在centos7中安装了docker系统

ELK（ElasticSearch, Logstash, Kibana）平台恰好可以同时实现日志收集、日志搜索和日志分析的功能

[root@localhost elk]# cat docker-compose.yml
elk:
  image: qnib/elk
  ports:
   - "9200:9200"
   - "5514:5514"
   - "55514:55514/udp"
   - "5601:5601"
   - "8080:80"
   - "8500:8500"
  environment:
  - DC_NAME=dc1
  - RUN_SERVER=true
  - BOOTSTRAP_CONSUL=true
  - COLLECT_METRICS=false
  - FORWARD_TO_LOGSTASH=false
  dns: 127.0.0.1
  hostname: elk
  volumes: 
   - /var/lib/elasticsearch
  privileged: true
  extra_hosts:
   - "myelk:192.168.128.189"
   - "otherhost:50.31.209.229"

tar -zxvf elasticsearch-2.1.0.tar.gz
cd elasticsearch-2.1.0

./bin/plugin install mobz/elasticsearch-head

vi config/elasticsearch.yml

cluster.name=es_cluster
node.name=node0
path.data=/tmp/elasticsearch/data
path.logs=/tmp/elasticsearch/logs
#当前hostname或IP，我这里是centos2
network.host=centos2
network.port=9200

./bin/elasticsearch

./bin/elasticsearch &

tar -zxvf logstash-2.1.1.tar.gz
cd logstash-2.1.1

mkdir config
vi config/log4j_to_es.conf

# For detail structure of this file
# Set: https://www.elastic.co/guide/en/logstash/current/configuration-file-structure.html
input {
  # For detail config for log4j as input, 
  # See: https://www.elastic.co/guide/en/logstash/current/plugins-inputs-log4j.html
  log4j {
    mode => "server"
    host => "centos2"
    port => 4567
  }
}
filter {
  #Only matched data are send to output.
}
output {
  # For detail config for elasticsearch as output, 
  # See: https://www.elastic.co/guide/en/logstash/current/plugins-outputs-elasticsearch.html
  elasticsearch {
    action => "index"          #The operation on ES
    hosts  => "centos2:9200"   #ElasticSearch host, can be array.
    index  => "applog"         #The index to write data to.
  }
}

./bin/logstash agent -f config/log4j_to_es.conf

<dependency>
    <groupId>log4j</groupId>
    <artifactId>log4j</artifactId>
    <version>1.2.17</version>
</dependency>

log4j.rootLogger=INFO,console

# for package com.demo.elk, log would be sent to socket appender.
log4j.logger.com.demo.elk=DEBUG, socket

# appender socket
log4j.appender.socket=org.apache.log4j.net.SocketAppender
log4j.appender.socket.Port=4567
log4j.appender.socket.RemoteHost=centos2
log4j.appender.socket.layout=org.apache.log4j.PatternLayout
log4j.appender.socket.layout.ConversionPattern=%d [%-5p] [%l] %m%n
log4j.appender.socket.ReconnectionDelay=10000

# appender console
log4j.appender.console=org.apache.log4j.ConsoleAppender
log4j.appender.console.target=System.out
log4j.appender.console.layout=org.apache.log4j.PatternLayout
log4j.appender.console.layout.ConversionPattern=%d [%-5p] [%l] %m%n

package com.demo.elk;

import org.apache.log4j.Logger;

public class Application {
    private static final Logger LOGGER = Logger.getLogger(Application.class);
    public static void main(String[] args) throws Exception {
        for (int i = 0; i < 10; i++) {
            LOGGER.error("Info log [" + i + "].");
            Thread.sleep(500);
        }
    }
}

tar -zxvf kibana-4.3.0-linux-x86.tar.gz
cd kibana-4.3.0-linux-x86
vi config/kibana.yml

server.port: 5601
server.host: “centos2”
elasticsearch.url: http://centos2:9200
kibana.index: “.kibana”

./bin/kibana

CORS是一个W3C标准，全称是"跨域资源共享"（Cross-origin resource sharing）。

它允许浏览器向跨源服务器，发出XMLHttpRequest请求，从而克服了AJAX只能同源使用的限制。

本文详细介绍CORS的内部机制

一、简介

CORS需要浏览器和服务器同时支持。目前，所有浏览器都支持该功能，IE浏览器不能低于IE10。

整个CORS通信过程，都是浏览器自动完成，不需要用户参与。对于开发者来说，CORS通信与同源的AJAX通信没有差别，代码完全一样。浏览器一旦发现AJAX请求跨源，就会自动添加一些附加的头信息，有时还会多出一次附加的请求，但用户不会有感觉。

因此，实现CORS通信的关键是服务器。只要服务器实现了CORS接口，就可以跨源通信。

二、两种请求

浏览器将CORS请求分成两类：简单请求（simple request）和非简单请求（not-so-simple request）。

只要同时满足以下两大条件，就属于简单请求。

（1) 请求方法是以下三种方法之一：

• HEAD
• GET
• POST

（2）HTTP的头信息不超出以下几种字段：

• Accept
• Accept-Language
• Content-Language
• Last-Event-ID
• Content-Type：只限于三个值application/x-www-form-urlencoded、multipart/form-data、text/plain

凡是不同时满足上面两个条件，就属于非简单请求。

浏览器对这两种请求的处理，是不一样的。

三、简单请求

3.1 基本流程

对于简单请求，浏览器直接发出CORS请求。具体来说，就是在头信息之中，增加一个Origin字段。

下面是一个例子，浏览器发现这次跨源AJAX请求是简单请求，就自动在头信息之中，添加一个Origin字段。

GET /cors HTTP/1.1
Origin: http://api.bob.com
Host: api.alice.com
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...

上面的头信息中，Origin字段用来说明，本次请求来自哪个源（协议 + 域名 + 端口）。服务器根据这个值，决定是否同意这次请求。

如果Origin指定的源，不在许可范围内，服务器会返回一个正常的HTTP回应。浏览器发现，这个回应的头信息没有包含Access-Control-Allow-Origin字段（详见下文），就知道出错了，从而抛出一个错误，被XMLHttpRequest的onerror回调函数捕获。注意，这种错误无法通过状态码识别，因为HTTP回应的状态码有可能是200。

如果Origin指定的域名在许可范围内，服务器返回的响应，会多出几个头信息字段。

Access-Control-Allow-Origin: http://api.bob.com
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: FooBar
Content-Type: text/html; charset=utf-8

上面的头信息之中，有三个与CORS请求相关的字段，都以Access-Control-开头。

（1）Access-Control-Allow-Origin

该字段是必须的。它的值要么是请求时Origin字段的值，要么是一个*，表示接受任意域名的请求。

（2）Access-Control-Allow-Credentials

该字段可选。它的值是一个布尔值，表示是否允许发送Cookie。默认情况下，Cookie不包括在CORS请求之中。设为true，即表示服务器明确许可，Cookie可以包含在请求中，一起发给服务器。这个值也只能设为true，如果服务器不要浏览器发送Cookie，删除该字段即可。

（3）Access-Control-Expose-Headers

该字段可选。CORS请求时，XMLHttpRequest对象的getResponseHeader()方法只能拿到6个基本字段：Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma。如果想拿到其他字段，就必须在Access-Control-Expose-Headers里面指定。上面的例子指定，getResponseHeader('FooBar')可以返回FooBar字段的值。

3.2 withCredentials 属性

上面说到，CORS请求默认不发送Cookie和HTTP认证信息。如果要把Cookie发到服务器，一方面要服务器同意，指定Access-Control-Allow-Credentials字段。

Access-Control-Allow-Credentials: true

另一方面，开发者必须在AJAX请求中打开withCredentials属性。

var xhr = new XMLHttpRequest();
xhr.withCredentials = true;

否则，即使服务器同意发送Cookie，浏览器也不会发送。或者，服务器要求设置Cookie，浏览器也不会处理。

但是，如果省略withCredentials设置，有的浏览器还是会一起发送Cookie。这时，可以显式关闭withCredentials。

xhr.withCredentials = false;

需要注意的是，如果要发送Cookie，Access-Control-Allow-Origin就不能设为星号，必须指定明确的、与请求网页一致的域名。同时，Cookie依然遵循同源政策，只有用服务器域名设置的Cookie才会上传，其他域名的Cookie并不会上传，且（跨源）原网页代码中的document.cookie也无法读取服务器域名下的Cookie。

四、非简单请求

4.1 预检请求

非简单请求是那种对服务器有特殊要求的请求，比如请求方法是PUT或DELETE，或者Content-Type字段的类型是application/json。

非简单请求的CORS请求，会在正式通信之前，增加一次HTTP查询请求，称为"预检"请求（preflight）。

浏览器先询问服务器，当前网页所在的域名是否在服务器的许可名单之中，以及可以使用哪些HTTP动词和头信息字段。只有得到肯定答复，浏览器才会发出正式的XMLHttpRequest请求，否则就报错。

下面是一段浏览器的JavaScript脚本。

var url = 'http://api.alice.com/cors';
var xhr = new XMLHttpRequest();
xhr.open('PUT', url, true);
xhr.setRequestHeader('X-Custom-Header', 'value');
xhr.send();

上面代码中，HTTP请求的方法是PUT，并且发送一个自定义头信息X-Custom-Header。

浏览器发现，这是一个非简单请求，就自动发出一个"预检"请求，要求服务器确认可以这样请求。下面是这个"预检"请求的HTTP头信息。

OPTIONS /cors HTTP/1.1
Origin: http://api.bob.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Custom-Header
Host: api.alice.com
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...

"预检"请求用的请求方法是OPTIONS，表示这个请求是用来询问的。头信息里面，关键字段是Origin，表示请求来自哪个源。

除了Origin字段，"预检"请求的头信息包括两个特殊字段。

（1）Access-Control-Request-Method

该字段是必须的，用来列出浏览器的CORS请求会用到哪些HTTP方法，上例是PUT。

（2）Access-Control-Request-Headers

该字段是一个逗号分隔的字符串，指定浏览器CORS请求会额外发送的头信息字段，上例是X-Custom-Header。

4.2 预检请求的回应

服务器收到"预检"请求以后，检查了Origin、Access-Control-Request-Method和Access-Control-Request-Headers字段以后，确认允许跨源请求，就可以做出回应。

HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:39 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://api.bob.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: X-Custom-Header
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Content-Length: 0
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain

上面的HTTP回应中，关键的是Access-Control-Allow-Origin字段，表示http://api.bob.com可以请求数据。该字段也可以设为星号，表示同意任意跨源请求。

Access-Control-Allow-Origin: *

如果浏览器否定了"预检"请求，会返回一个正常的HTTP回应，但是没有任何CORS相关的头信息字段。这时，浏览器就会认定，服务器不同意预检请求，因此触发一个错误，被XMLHttpRequest对象的onerror回调函数捕获。控制台会打印出如下的报错信息。

XMLHttpRequest cannot load http://api.alice.com.
Origin http://api.bob.com is not allowed by Access-Control-Allow-Origin.

服务器回应的其他CORS相关字段如下。

Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: X-Custom-Header
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 1728000

（1）Access-Control-Allow-Methods

该字段必需，它的值是逗号分隔的一个字符串，表明服务器支持的所有跨域请求的方法。注意，返回的是所有支持的方法，而不单是浏览器请求的那个方法。这是为了避免多次"预检"请求。

（2）Access-Control-Allow-Headers

如果浏览器请求包括Access-Control-Request-Headers字段，则Access-Control-Allow-Headers字段是必需的。它也是一个逗号分隔的字符串，表明服务器支持的所有头信息字段，不限于浏览器在"预检"中请求的字段。

（3）Access-Control-Allow-Credentials

该字段与简单请求时的含义相同。

（4）Access-Control-Max-Age

该字段可选，用来指定本次预检请求的有效期，单位为秒。上面结果中，有效期是20天（1728000秒），即允许缓存该条回应1728000秒（即20天），在此期间，不用发出另一条预检请求。

4.3 浏览器的正常请求和回应

一旦服务器通过了"预检"请求，以后每次浏览器正常的CORS请求，就都跟简单请求一样，会有一个Origin头信息字段。服务器的回应，也都会有一个Access-Control-Allow-Origin头信息字段。

下面是"预检"请求之后，浏览器的正常CORS请求。

PUT /cors HTTP/1.1
Origin: http://api.bob.com
Host: api.alice.com
X-Custom-Header: value
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...

上面头信息的Origin字段是浏览器自动添加的。

下面是服务器正常的回应。

Access-Control-Allow-Origin: http://api.bob.com
Content-Type: text/html; charset=utf-8

上面头信息中，Access-Control-Allow-Origin字段是每次回应都必定包含的。

五、与JSONP的比较

CORS与JSONP的使用目的相同，但是比JSONP更强大。

JSONP只支持GET请求，CORS支持所有类型的HTTP请求。JSONP的优势在于支持老式浏览器，以及可以向不支持CORS的网站请求数据。

当 Web 资源请求由其它域名或端口提供的资源时，会发起跨域 HTTP 请求（cross-origin HTTP request）。比如，站点 http://domain-a.com 的某 HTML 页面通过 <img> 的 src 请求 http://domain-b.com/image.jpg。网络上，很多页面从其他站点加载各类资源（包括 CSS、图片、JavaScript 脚本）。

出于安全考虑，浏览器会限制脚本中发起的跨域请求。比如，使用 XMLHttpRequest 和 Fetch 发起的 HTTP 请求必须遵循同源策略。因此，Web 应用通过 XMLHttpRequest 对象或 Fetch 仅能向同域资源发起 HTTP 请求。 为提升 Web 应用的可用性，浏览器必须支持跨域请求。 （译者注：这段描述跨域不准确，跨域并非不一定是浏览器限制了发起跨站请求，而也可能是跨站请求可以正常发起，但是返回结果被浏览器拦截了。最好的例子是 CSRF 跨站攻击原理，请求是发送到了后端服务器无论是否跨域！注意：有些浏览器不允许从 HTTPS 的域跨域访问 HTTP，比如  Chrome 和 Firefox，这些浏览器在请求还未发出的时候就会拦截请求，这是一个特例。）

跨域资源共享（ CORS ）机制允许 Web 应用服务器进行跨域访问控制，从而使跨域数据传输得以安全进行。浏览器支持在 API 容器中（例如 XMLHttpRequest 或 Fetch ）使用 CORS，以降低跨域 HTTP 请求所带来的风险。

这篇文章适用于网站管理员、后端和前端开发者。CORS 需要客户端和服务器同时支持。目前，所有浏览器都支持该机制。 对于服务端的支持，开发者可以阅读补充材料 cross-origin sharing from a server perspective (with PHP code snippets) 。

跨域资源共享标准（ cross-origin sharing standard ）允许在下列场景中使用跨域 HTTP 请求：

• 前文提到的由 XMLHttpRequest 或 Fetch 发起的跨域 HTTP 请求。
• Web 字体 (CSS 中通过 @font-face 使用跨域字体资源), 因此，网站就可以发布 TrueType 字体资源，并只允许已授权网站进行跨站调用。
• WebGL 贴图
• 使用 drawImage 将 Images/video 画面绘制到 canvas
• 样式表（使用 CSSOM）
• Scripts (未处理的异常)

本文概述了跨域资源共享机制及其所涉及的 HTTP 首部字段。

概述

跨域资源共享标准新增了一组 HTTP 首部字段，允许服务器声明哪些源站有权限访问哪些资源。另外，规范要求，对那些可能对服务器数据产生副作用的 HTTP 请求方法（特别是 GET 以外的 HTTP 请求，或者搭配某些 MIME 类型的 POST 请求），浏览器必须首先使用 OPTIONS 方法发起一个预检请求（preflight request），从而获知服务端是否允许该跨域请求。服务器确认允许之后，才发起实际的 HTTP 请求。在预检请求的返回中，服务器端也可以通知客户端，是否需要携带身份凭证（包括 Cookies 和 HTTP 认证相关数据）。

接下来的内容将讨论相关场景，并剖析该机制所涉及的 HTTP 首部字段。

若干访问控制场景

这里，我们使用三个场景来解释跨域资源共享机制的工作原理。这些例子都使用 XMLHttpRequest 对象。

本文中的 JavaScript 代码片段都可以从 http://arunranga.com/examples/access-control/ 获得。另外，使用支持跨域  XMLHttpRequest 的浏览器访问该地址，可以看到代码的实际运行结果。

关于服务端对跨域资源共享的支持的讨论，请参见这篇文章： Server-Side_Access_Control (CORS)。

简单请求

某些请求不会触发 CORS 预检请求。本文称这样的请求为“简单请求”，请注意，该术语并不属于 Fetch （其中定义了 CORS）规范。若请求满足所有下述条件，则该请求可视为“简单请求”：

• 使用下列方法之一：
  • GET
  • HEAD
  • POST
• Fetch 规范定义了对 CORS 安全的首部字段集合，不得人为设置该集合之外的其他首部字段。该集合为：
  • Accept
  • Accept-Language
  • Content-Language
  • Content-Type （需要注意额外的限制）
  • DPR
  • Downlink
  • Save-Data
  • Viewport-Width
  • Width
•  Content-Type 的值属于下列之一：
  • application/x-www-form-urlencoded
  • multipart/form-data
  • text/plain

比如说，假如站点 http://foo.example 的网页应用想要访问 http://bar.other 的资源。http://foo.example 的网页中可能包含类似于下面的 JavaScript 代码：

var invocation = new XMLHttpRequest();
var url = 'http://bar.other/resources/public-data/';
   
function callOtherDomain() {
  if(invocation) {    
    invocation.open('GET', url, true);
    invocation.onreadystatechange = handler;
    invocation.send(); 
  }
}

客户端和服务器之间使用 CORS 首部字段来处理跨域权限：

分别检视请求报文和响应报文：

GET /resources/public-data/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://foo.example/examples/access-control/simpleXSInvocation.html
Origin: http://foo.example


HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 00:23:53 GMT
Server: Apache/2.0.61 
Access-Control-Allow-Origin: *
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/xml

[XML Data]

第 1~10 行是请求首部。第10行 的请求首部字段 Origin 表明该请求来源于 http://foo.exmaple。

第 13~22 行是来自于 http://bar.other 的服务端响应。响应中携带了响应首部字段 Access-Control-Allow-Origin（第 16 行）。使用 Origin 和 Access-Control-Allow-Origin 就能完成最简单的访问控制。本例中，服务端返回的 Access-Control-Allow-Origin: * 表明，该资源可以被任意外域访问。如果服务端仅允许来自 http://foo.example 的访问，该首部字段的内容如下：

Access-Control-Allow-Origin: http://foo.example

现在，除了 http://foo.example，其它外域均不能访问该资源（该策略由请求首部中的 ORIGIN 字段定义，见第10行）。Access-Control-Allow-Origin 应当为 * 或者包含由 Origin 首部字段所指明的域名。

预检请求

与前述简单请求不同，“需预检的请求”要求必须首先使用 OPTIONS   方法发起一个预检请求到服务器，以获知服务器是否允许该实际请求。"预检请求“的使用，可以避免跨域请求对服务器的用户数据产生未预期的影响。

当请求满足下述任一条件时，即应首先发送预检请求：

• 使用了下面任一 HTTP 方法：
  • PUT
  • DELETE
  • CONNECT
  • OPTIONS
  • TRACE
  • PATCH
• 人为设置了对 CORS 安全的首部字段集合之外的其他首部字段。该集合为：
  • Accept
  • Accept-Language
  • Content-Language
  • Content-Type (but note the additional requirements below)
  • DPR
  • Downlink
  • Save-Data
  • Viewport-Width
  • Width
•  Content-Type 的值不属于下列之一:
  • application/x-www-form-urlencoded
  • multipart/form-data
  • text/plain

如下是一个需要执行预检请求的 HTTP 请求：

var invocation = new XMLHttpRequest();
var url = 'http://bar.other/resources/post-here/';
var body = '<?xml version="1.0"?><person><name>Arun</name></person>';
    
function callOtherDomain(){
  if(invocation)
    {
      invocation.open('POST', url, true);
      invocation.setRequestHeader('X-PINGOTHER', 'pingpong');
      invocation.setRequestHeader('Content-Type', 'application/xml');
      invocation.onreadystatechange = handler;
      invocation.send(body); 
    }
}

......

上面的代码使用 POST 请求发送一个 XML 文档，该请求包含了一个自定义的请求首部字段（X-PINGOTHER: pingpong）。另外，该请求的 Content-Type 为 application/xml。因此，该请求需要首先发起“预检请求”。

OPTIONS /resources/post-here/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Origin: http://foo.example
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type


HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:39 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 0
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain

预检请求完成之后，发送实际请求：

POST /resources/post-here/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
X-PINGOTHER: pingpong
Content-Type: text/xml; charset=UTF-8
Referer: http://foo.example/examples/preflightInvocation.html
Content-Length: 55
Origin: http://foo.example
Pragma: no-cache
Cache-Control: no-cache

<?xml version="1.0"?><person><name>Arun</name></person>


HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:40 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://foo.example
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 235
Keep-Alive: timeout=2, max=99
Connection: Keep-Alive
Content-Type: text/plain

[Some GZIP'd payload]

浏览器检测到，从 JavaScript 中发起的请求需要被预检。从上面的报文中，我们看到，第 1~12 行发送了一个使用 OPTIONS 方法的“预检请求”。 OPTIONS 是 HTTP/1.1 协议中定义的方法，用以从服务器获取更多信息。该方法不会对服务器资源产生影响。 预检请求中同时携带了下面两个首部字段：

Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER

首部字段 Access-Control-Request-Method 告知服务器，实际请求将使用 POST 方法。首部字段 Access-Control-Request-Headers 告知服务器，实际请求将携带两个自定义请求首部字段：X-PINGOTHER 与 Content-Type。服务器据此决定，该实际请求是否被允许。

第14~26 行为预检请求的响应，表明服务器将接受后续的实际请求。重点看第 17~20 行：

Access-Control-Allow-Origin: http://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400

首部字段 Access-Control-Allow-Methods 表明服务器允许客户端使用 POST, GET 和 OPTIONS 方法发起请求。该字段与 HTTP/1.1 Allow: response header 类似，但仅限于在需要访问控制的场景中使用。

首部字段 Access-Control-Allow-Headers 表明服务器允许请求中携带字段 X-PINGOTHER 与 Content-Type。与 Access-Control-Allow-Methods 一样，Access-Control-Allow-Headers 的值为逗号分割的列表。

最后，首部字段 Access-Control-Max-Age 表明该响应的有效时间为 86400 秒，也就是 24 小时。在有效时间内，浏览器无须为同一请求再次发起预检请求。请注意，浏览器自身维护了一个最大有效时间，如果该首部字段的值超过了最大有效时间，将不会生效。

预检请求与重定向

大多数浏览器不支持针对于预检请求的重定向。如果一个预检请求发生了重定向，浏览器将报告错误：

The request was redirected to 'https://example.com/foo', which is disallowed for cross-origin requests that require preflight

Request requires preflight, which is disallowed to follow cross-origin redirect

CORS 最初要求该行为，不过在后续的修订中废弃了这一要求。

在浏览器的实现跟上规范之前，有两种方式规避上述报错行为：

• 在服务端去掉对预检请求的重定向；
• 将实际请求变成一个简单请求。

如果上面两种方式难以做到，我们仍有其他办法：

• 使用简单请求模拟预检请求，用以探查预检请求是否重定向到其他 URL（使用  Response.url 或 XHR.responseURL）；
• 向上一步中获得的 URL 发起请求。

不过，如果请求由于缺失 Authorization 字段而引起一个预检请求，则这一方法将无法使用。这种情况只能由服务端进行更改。

附带身份凭证的请求

Fetch 与 CORS 的一个有趣的特性是，可以基于  HTTP cookies 和 HTTP 认证信息发送身份凭证。一般而言，对于跨域 XMLHttpRequest 或 Fetch 请求，浏览器不会发送身份凭证信息。如果要发送凭证信息，需要设置 XMLHttpRequest 的某个特殊标志位。

本例中，http://foo.example 的某脚本向 http://bar.other 发起一个GET 请求，并设置 Cookies：

var invocation = new XMLHttpRequest();
var url = 'http://bar.other/resources/credentialed-content/';
    
function callOtherDomain(){
  if(invocation) {
    invocation.open('GET', url, true);
    invocation.withCredentials = true;
    invocation.onreadystatechange = handler;
    invocation.send(); 
  }
}

第 7 行将 XMLHttpRequest 的 withCredentials 标志设置为 true，从而向服务器发送 Cookies。因为这是一个简单 GET 请求，所以浏览器不会对其发起“预检请求”。但是，如果服务器端的响应中未携带 Access-Control-Allow-Credentials: true ，浏览器将不会把响应内容返回给请求的发送者。

客户端与服务器端交互示例如下：

GET /resources/access-control-with-credentials/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://foo.example/examples/credential.html
Origin: http://foo.example
Cookie: pageAccess=2


HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:34:52 GMT
Server: Apache/2.0.61 (Unix) PHP/4.4.7 mod_ssl/2.0.61 OpenSSL/0.9.7e mod_fastcgi/2.4.2 DAV/2 SVN/1.4.2
X-Powered-By: PHP/5.2.6
Access-Control-Allow-Origin: http://foo.example
Access-Control-Allow-Credentials: true
Cache-Control: no-cache
Pragma: no-cache
Set-Cookie: pageAccess=3; expires=Wed, 31-Dec-2008 01:34:53 GMT
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 106
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain


[text/plain payload]

即使第 11 行指定了 Cookie 的相关信息，但是，如果 bar.other 的响应中缺失 Access-Control-Allow-Credentials: true（第 19 行），则响应内容不会返回给请求的发起者。

附带身份凭证的请求与通配符

对于附带身份凭证的请求，服务器不得设置 Access-Control-Allow-Origin 的值为“*”。

这是因为请求的首部中携带了 Cookie 信息，如果 Access-Control-Allow-Origin 的值为“*”，请求将会失败。而将 Access-Control-Allow-Origin 的值设置为 http://foo.example，则请求将成功执行。

另外，响应首部中也携带了 Set-Cookie 字段，尝试对 Cookie 进行修改。如果操作失败，将会抛出异常。

HTTP 响应首部字段

本节列出了规范所定义的响应首部字段。上一小节中，我们已经看到了这些首部字段在实际场景中是如何工作的。

Access-Control-Allow-Origin

响应首部中可以携带一个 Access-Control-Allow-Origin 字段，其语法如下:

Access-Control-Allow-Origin: <origin> | *

其中，origin 参数的值指定了允许访问该资源的外域 URI。对于不需要携带身份凭证的请求，服务器可以指定该字段的值为通配符，表示允许来自所有域的请求。

例如，下面的字段值将允许来自 http://mozilla.com 的请求：

Access-Control-Allow-Origin: http://mozilla.com

如果服务端指定了具体的域名而非“*”，那么响应首部中的 Vary 字段的值必须包含 Origin。这将告诉客户端：服务器对不同的源站返回不同的内容。

Access-Control-Expose-Headers

Access-Control-Expose-Headers 首部字段指定了服务端允许的首部字段集合。

Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header

服务器允许请求中携带 X-My-Custom-Header 和 X-Another-Custom-Header 这两个字段。

Access-Control-Max-Age

Access-Control-Max-Age 首部字段指明了预检请求的响应的有效时间。

Access-Control-Max-Age: <delta-seconds>

delta-seconds 表示该响应在多少秒内有效。

Access-Control-Allow-Credentials

Access-Control-Allow-Credentials 首部字段用于预检请求的响应，表明服务器是否允许 credentials 标志设置为 true 的请求。请注意：简单 GET 请求不会被预检；如果对此类请求的响应中不包含该字段，浏览器不会将响应返回给请求的调用者。

Access-Control-Allow-Credentials: true

上文已经讨论了附带身份凭证的请求。

Access-Control-Allow-Methods

Access-Control-Allow-Methods 首部字段用于预检请求的响应。其指明了实际请求所允许使用的 HTTP 方法。

Access-Control-Allow-Methods: <method>[, <method>]*

相关示例见这里。

Access-Control-Allow-Headers

Access-Control-Allow-Headers 首部字段用于预检请求的响应。其指明了实际请求中允许携带的首部字段。

Access-Control-Allow-Headers: <field-name>[, <field-name>]*

HTTP 请求首部字段

本节列出了可用于发起跨域请求的首部字段。请注意，这些首部字段无须手动设置。 当开发者使用 XMLHttpRequest 对象发起跨域请求时，它们已经被设置就绪。

Origin

Origin 首部字段表明预检请求或实际请求的源站。

Origin: <origin>

origin 参数的值为源站 URI。它不包含任何路径信息，只是服务器名称。

注意，不管是否为跨域请求，ORIGIN 字段总是被发送。

Access-Control-Request-Method

Access-Control-Request-Method 首部字段用于预检请求。其作用是，将实际请求所使用的 HTTP 方法告诉服务器。

Access-Control-Request-Method: <method>

相关示例见这里。

Access-Control-Request-Headers

Access-Control-Request-Headers 首部字段用于预检请求。其作用是，将实际请求所携带的首部字段告诉服务器。

Access-Control-Request-Headers: <field-name>[, <field-name>]*

相关示例见这里。

规范

浏览器兼容性

注：

• IE 10 提供了对规范的完整支持，但在较早版本（8 和 9）中，CORS 机制是借由 XDomainRequest 对象完成的。
• Firefox 3.5 引入了对 XMLHttpRequests 和 Web 字体的跨域支持（但最初的实现并不完整，这在后续版本中得到完善）；Firefox 7 引入了对 WebGL 贴图的跨域支持；Firefox 9 引入了对 drawImage 的跨域支持。

毛笔的分类主要有依尺寸，还有笔毛的种类，来源，形状等等来分。­

依尺寸可以简单的把毛笔分为：小楷，中楷，大楷。­

依笔毛的种类可分为：软毫，硬毫，兼毫等。­

依来源可分为：胎毛笔、狼毛笔、兔肩紫毫笔、鹿毛笔、鸡毛笔、鸭毛笔、羊毛笔、猪毛笔、鼠毛笔、虎毛笔、黄牛耳毫笔等。­

羊毫类：笔头是用山羊毛制成的。羊毫笔比较柔软，吸墨量大，适于写表现圆浑厚实的点画。比狼毫笔经久耐用。此类笔以湖笔为多，价格比较便宜。一般常见的有大楷笔、京提（或称提笔）、联锋、屏锋、顶锋、盖锋、条幅、玉笋、玉兰蕊、京楂等。 ­

狼毫笔：笔头是用黄鼠狼尾巴上的毛制成的。以东北产的鼠尾为最，称"北狼毫"、"关东辽尾"。狼毫比羊毫笔力劲挺，宜书宜画，但不如羊毫笔耐用，价格也比羊毫贵。常见的品种有兰竹、写意、山水、花卉、叶筋、衣纹、红豆、小精工、鹿狼毫书画（狼毫中加入鹿毫制成）、豹狼毫（狼毫中加入豹毛制成的）、特制长峰狼毫，超品长峰狼毫等。 ­

紫毫：笔头是以兔毛制成的，因色泽紫黑光亮而得名。此种笔挺拔尖锐而锋利，弹性比狼毫更强，以安徽出产的野兔毛为最好。 ­

兼毫：笔头是用两种刚柔不同的动物毛制成的。常见的种类有羊狼兼毫、羊紫兼毫，如五紫五羊，七紫三羊等等。此种笔的优点兼具了羊狼毫笔的长处，刚柔适中，价格也适中，为书画家常用。种类有调和式、心被式。 ­

依形状可分为：圆毫，尖豪等。­

此外，根据笔锋的长短，毛笔又有[B]长锋、中锋、短锋之别，性能各异。长锋容易画出婀娜多姿的线条，短锋容易使线条凝重厚实，中锋则兼而有之，画山水以用中锋为宜。根据笔锋的大小不同，毛笔又分为小、中、大等型号。画山水各种型号都要准备一点，一般“小山水”（小狼毫）、“大山水”（大狼毫）各备一枝，“小白云”、“大白云”羊毫笔各备一枝，再有一支更大的羊毫“斗笔”就可以了。新笔锋多尖锐，只适宜画细线，皴、擦、点擢用旧笔效果好。有的画家喜用秃笔，点线别有苍劲朴拙之趣。好的毛笔，都具有圆、齐、尖、健四个特点，使用起来运转自如。画笔用后要及时冲洗干净，避免墨汁干结损坏。 ­

制作毛笔笔管的原料一般有：金、银、象牙、玻璃、紫檀、斑竹。

画家论笔

* 文震亨：“尖”、“齐”、“圆”、“健”，笔之四德。­

* 张大千：张大千说英国出的一种水彩笔十分名贵，是用英国某地黄牛耳朵内的细毛制成，2500头黄牛才出一磅黄牛耳毫。牛耳毫制成的画笔，吸水饱满，有弹性。­

* 潘天寿：羊毫圆细柔训,含水量强,笔锋出水慢,运用枯墨湿墨,有其特长。­

我国的制笔，历史上有宣笔（安徽宣城）、湖笔（浙江湖州）两大中心。现在上海、苏州、北京、成都等地生产的画笔也享有盛誉。目前出产毛笔最有名的地方在浙江省吴兴县善琏镇湖州，称为湖笔。­

笔有“四德”，即“尖、齐、圆、健”，下面逐一介绍： ­

尖：指笔毫聚拢时，末端要尖瑞。笔尖则写字锋棱易出，较易传神。作家常以“秃笔”称自己的笔，但笔不尖则成秃笔，做书神采顿失。 ­

选购新笔时，毫毛有胶聚合，很容易分辨。在检查旧笔时，先将笔润湿，毫毛聚拢，便可分辨尖秃。 ­

齐：指笔尖润开压平后，毫尖平齐。毫若齐则压平时长短相等，中无空隙，运笔时“万毫齐力”。因为需把笔完全润开，选购时就较无法检查这一点。 ­

圆：指笔毫圆满如枣核之形，就是毫毛充足的意思。如毫毛充足则书写时笔力完足，反之则身瘦，缺乏笔力。笔锋圆满，运笔自能圆转如意。 ­

选购时，毫毛有胶聚拢，是不是圆满，仔细看看就知道了。 ­

健：即笔腰弹力；将笔毫重压后提起，随即恢复原状。笔有弹力，则能运用自如；一般而言，兔毫、狼毫弹力较羊毫强，书亦坚挺峻拔。 ­

利用 JTA 处理事务

什么是事务处理

事务是计算机应用中不可或缺的组件模型，它保证了用户操作的原子性 ( Atomicity )、一致性 ( Consistency )、隔离性 ( Isolation ) 和持久性 ( Durabilily )。关于事务最经典的示例莫过于信用卡转账：将用户 A 账户中的 500 元人民币转移到用户 B 的账户中，其操作流程如下
1. 将 A 账户中的金额减少 500
2. 将 B 账户中的金额增加 500
这两个操作必须保正 ACID 的事务属性：即要么全部成功，要么全部失败；假若没有事务保障，用户的账号金额将可能发生问题：
假如第一步操作成功而第二步失败，那么用户 A 账户中的金额将就减少 500 元而用户 B 的账号却没有任何增加（不翼而飞）；同样如果第一步出错 而第二步成功，那么用户 A 的账户金额不变而用户 B 的账号将增加 500 元（凭空而生）。上述任何一种错误都会产生严重的数据不一致问题，事务的缺失对于一个稳定的生产系统是不可接受的。

J2EE 事务处理方式

1. 本地事务：紧密依赖于底层资源管理器（例如数据库连接 )，事务处理局限在当前事务资源内。此种事务处理方式不存在对应用服务器的依赖，因而部署灵活却无法支持多数据源的分布式事务。在数据库连接中使用本地事务示例如下：

清单 1. 本地事务处理实例

2. 分布式事务处理 : Java 事务编程接口（JTA：Java Transaction API）和 Java 事务服务 (JTS；Java Transaction Service) 为 J2EE 平台提供了分布式事务服务。分布式事务（Distributed Transaction）包括事务管理器（Transaction Manager）和一个或多个支持 XA 协议的资源管理器 ( Resource Manager )。我们可以将资源管理器看做任意类型的持久化数据存储；事务管理器承担着所有事务参与单元的协调与控制。JTA 事务有效的屏蔽了底层事务资源，使应用可以以透明的方式参入到事务处理中；但是与本地事务相比，XA 协议的系统开销大，在系统开发过程中应慎重考虑是否确实需要分布式事务。若确实需要分布式事务以协调多个事务资源，则应实现和配置所支持 XA 协议的事务资源，如 JMS、JDBC 数据库连接池等。使用 JTA 处理事务的示例如下（注意：connA 和 connB 是来自不同数据库的连接）

清单 2. JTA 事务处理

JTA 实现原理

很多开发人员都会对 JTA 的内部工作机制感兴趣：我编写的代码没有任何与事务资源（如数据库连接）互动的代码，但是我的操作（数据库更新）却实实在在的被包含在了事务中，那 JTA 究竟是通过何种方式来实现这种透明性的呢？ 要理解 JTA 的实现原理首先需要了解其架构：它包括事务管理器（Transaction Manager）和一个或多个支持 XA 协议的资源管理器 ( Resource Manager ) 两部分， 我们可以将资源管理器看做任意类型的持久化数据存储；事务管理器则承担着所有事务参与单元的协调与控制。 根据所面向对象的不同，我们可以将 JTA 的事务管理器和资源管理器理解为两个方面：面向开发人员的使用接口（事务管理器）和面向服务提供商的实现接口（资源管理器）。其中开发接口的主要部分即为上述示例中引用的 UserTransaction 对象，开发人员通过此接口在信息系统中实现分布式事务；而实现接口则用来规范提供商（如数据库连接提供商）所提供的事务服务，它约定了事务的资源管理功能，使得 JTA 可以在异构事务资源之间执行协同沟通。以数据库为例，IBM 公司提供了实现分布式事务的数据库驱动程序，Oracle 也提供了实现分布式事务的数据库驱动程序， 在同时使用 DB2 和 Oracle 两种数据库连接时， JTA 即可以根据约定的接口协调者两种事务资源从而实现分布式事务。正是基于统一规范的不同实现使得 JTA 可以协调与控制不同数据库或者 JMS 厂商的事务资源，其架构如下图所示：

图 1. JTA 体系架构

开发人员使用开发人员接口，实现应用程序对全局事务的支持；各提供商（数据库，JMS 等）依据提供商接口的规范提供事务资源管理功能；事务管理器（ TransactionManager ）将应用对分布式事务的使用映射到实际的事务资源并在事务资源间进行协调与控制。 下面，本文将对包括 UserTransaction、Transaction 和 TransactionManager 在内的三个主要接口以及其定义的方法进行介绍。

面向开发人员的接口为 UserTransaction （使用方法如上例所示），开发人员通常只使用此接口实现 JTA 事务管理，其定义了如下的方法：

• begin()- 开始一个分布式事务，（在后台 TransactionManager 会创建一个 Transaction 事务对象并把此对象通过 ThreadLocale 关联到当前线程上 )
• commit()- 提交事务（在后台 TransactionManager 会从当前线程下取出事务对象并把此对象所代表的事务提交）
• rollback()- 回滚事务（在后台 TransactionManager 会从当前线程下取出事务对象并把此对象所代表的事务回滚）
• getStatus()- 返回关联到当前线程的分布式事务的状态 (Status 对象里边定义了所有的事务状态，感兴趣的读者可以参考 API 文档 )
• setRollbackOnly()- 标识关联到当前线程的分布式事务将被回滚

面向提供商的实现接口主要涉及到 TransactionManager 和 Transaction 两个对象

Transaction 代表了一个物理意义上的事务，在开发人员调用 UserTransaction.begin() 方法时 TransactionManager 会创建一个 Transaction 事务对象（标志着事务的开始）并把此对象通过 ThreadLocale 关联到当前线程。UserTransaction 接口中的 commit()、rollback()，getStatus() 等方法都将最终委托给 Transaction 类的对应方法执行。Transaction 接口定义了如下的方法：

• commit()- 协调不同的事务资源共同完成事务的提交
• rollback()- 协调不同的事务资源共同完成事务的回滚
• setRollbackOnly()- 标识关联到当前线程的分布式事务将被回滚
• getStatus()- 返回关联到当前线程的分布式事务的状态
• enListResource(XAResource xaRes, int flag)- 将事务资源加入到当前的事务中（在上述示例中，在对数据库 A 操作时 其所代表的事务资源将被关联到当前事务中，同样，在对数据库 B 操作时其所代表的事务资源也将被关联到当前事务中）
• delistResourc(XAResource xaRes, int flag)- 将事务资源从当前事务中删除
• registerSynchronization(Synchronization sync)- 回调接口，Hibernate 等 ORM 工具都有自己的事务控制机制来保证事务， 但同时它们还需要一种回调机制以便在事务完成时得到通知从而触发一些处理工作，如清除缓存等。这就涉及到了 Transaction 的回调接口 registerSynchronization。工具可以通过此接口将回调程序注入到事务中，当事务成功提交后，回调程序将被激活。

TransactionManager 本身并不承担实际的事务处理功能，它更多的是充当用户接口和实现接口之间的桥梁。下面列出了 TransactionManager 中定义的方法，可以看到此接口中的大部分事务方法与 UserTransaction 和 Transaction 相同。 在开发人员调用 UserTransaction.begin() 方法时 TransactionManager 会创建一个 Transaction 事务对象（标志着事务的开始）并把此对象通过 ThreadLocale 关联到当前线程上；同样 UserTransaction.commit() 会调用 TransactionManager.commit()， 方法将从当前线程下取出事务对象 Transaction 并把此对象所代表的事务提交， 即调用 Transaction.commit()

• begin()- 开始事务
• commit()- 提交事务
• rollback()- 回滚事务
• getStatus()- 返回当前事务状态
• setRollbackOnly()
• getTransaction()- 返回关联到当前线程的事务
• setTransactionTimeout(int seconds)- 设置事务超时时间
• resume(Transaction tobj)- 继续当前线程关联的事务
• suspend()- 挂起当前线程关联的事务

在系统开发过程中会遇到需要将事务资源暂时排除的操作，此时就需要调用 suspend() 方法将当前的事务挂起：在此方法后面所做的任何操作将不会被包括在事务中，在非事务性操作完成后调用 resume()以继续事务（注： 要进行此操作需要获得 TransactionManager 对象， 其获得方式在不同的 J2EE 应用服务器上是不一样的）
下面将通过具体的代码向读者介绍 JTA 实现原理。下图列出了示例实现中涉及到的 Java 类，其中 UserTransactionImpl 实现了 UserTransaction 接口，TransactionManagerImpl 实现了 TransactionManager 接口，TransactionImpl 实现了 Transaction 接口

图 2. JTA 实现类图

清单 3. 开始事务 - UserTransactionImpl implenments UserTransaction

清单 4. 开始事务 - TransactionManagerImpl implements TransactionManager

现在我们就可以理解 Transaction 接口上没有定义 begin 方法的原因了：Transaction 对象本身就代表了一个事务，在它被创建的时候就表明事务已经开始，因此也就不需要额外定义 begin() 方法了。

清单 5. 提交事务 - UserTransactionImpl implenments UserTransaction

清单 6. 提交事务 - TransactionManagerImpl implenments TransactionManager

同理， rollback、getStatus、setRollbackOnly 等方法也采用了与 commit() 相同的方式实现。 UserTransaction 对象不会对事务进行任何控制， 所有的事务方法都是通过 TransactionManager 传递到实际的事务资源即 Transaction 对象上。
上述示例演示了 JTA 事务的处理过程，下面将为您展示事务资源（数据库连接，JMS）是如何以透明的方式加入到 JTA 事务中的。首先需要明确的一点是，在 JTA 事务 代码中获得的数据库源 ( DataSource ) 必须是支持分布式事务的。在如下的代码示例中，尽管所有的数据库操作都被包含在了 JTA 事务中，但是因为 MySql 的数据库连接是通过本地方式获得的，对 MySql 的任何更新将不会被自动包含在全局事务中。

清单 7. JTA 事务处理

为什么必须从支持事务的数据源中获得的数据库连接才支持分布式事务呢？其实支持事务的数据源与普通的数据源是不同的，它实现了额外的 XADataSource 接口。我们可以简单的将 XADataSource 理解为普通的数据源（继承了 java.sql.PooledConnection），只是它为支持分布式事务而增加了 getXAResource 方法。另外，由 XADataSource 返回的数据库连接与普通连接也是不同的，此连接除了实现 java.sql.Connection 定义的所有功能之外还实现了 XAConnection 接口。我们可以把 XAConnection 理解为普通的数据库连接，它支持所有 JDBC 规范的数据库操作，不同之处在于 XAConnection 增加了对分布式事务的支持。通过下面的类图读者可以对这几个接口的关系有所了解：

图 3. 事务资源类图

应用程序从支持分布式事务的数据源获得的数据库连接是 XAConnection 接口的实现，而由此数据库连接创建的会话（Statement）也为了支持分布式事务而增加了功能，如下代码所示：

清单 8. JTA 事务资源处理

我们来看一下由 XAConnection 数据库连接创建的会话（Statement）部分的代码实现（不同的 JTA 提供商会有不同的实现方式，此处代码示例只是向您演示事务资源是如何被自动加入到事务中）。 我们以会话对象的 execute 方法为例，通过在方法开始部分增加对 associateWithTransactionIfNecessary 方法的调用，即可以保证在 JTA 事务期间，对任何数据库连接的操作都会被透明的加入到事务中。

清单 9. 将事务资源自动关联到事务对象 - XAStatement implements Statement

XAResource 与 Xid： XAResource 是 Distributed Transaction Processing: The XA Specification 标准的 Java 实现，它是对底层事务资源的抽象，定义了分布式事务处理过程中事务管理器和资源管理器之间的协议，各事务资源提供商（如 JDBC 驱动，JMS）将提供此接口的实现。使用此接口，开发人员可以通过自己的编程实现分布式事务处理，但这些通常都是由应用服务器实现的（服务器自带实现更加高效，稳定） 为了说明，我们将举例说明他的使用方式。
在使用分布式事务之前，为了区分事务使之不发生混淆，必须实现一个 Xid 类用来标识事务，可以把 Xid 想象成事务的一个标志符，每次在新事务创建是都会为事务分配一个 Xid，Xid 包含三个元素：formatID、gtrid（全局事务标识符）和 bqual（分支修饰词标识符）。 formatID 通常是零，这意味着你将使用 OSI CCR（Open Systems Interconnection Commitment, Concurrency 和 Recovery 标准）来命名；如果你要使用另外一种格式，那么 formatID 应该大于零，-1 值意味着 Xid 为无效。

gtrid 和 bqual 分别包含 64 个字节二进制码来分别标识全局事务和分支事务， 唯一的要求是 gtrid 和 bqual 必须是全局唯一的。
XAResource 接口中主要定义了如下方法：

• commit()- 提交事务
• isSameRM(XAResource xares)- 检查当前的 XAResource 与参数是否同一事务资源
• prepare()- 通知资源管理器准备事务的提交工作
• rollback()- 通知资源管理器回滚事务

在事务被提交时，Transaction 对象会收集所有被当前事务包含的 XAResource 资源，然后调用资源的提交方法，如下代码所示：

清单 10. 提交事务 - TransactionImpl implements Transaction

结束语

通过如上介绍相信读者对 JTA 的原理已经有所了解，本文中的示例代码都是理想情况下的假设实现。一款完善成熟的 JTA 事务实现需要考虑与处理的细节非常多，如性能（提交事务的时候使用多线程方式并发提交事务）、容错（网络，系统异常）等， 其成熟也需要经过较长时间的积累。感兴趣的读者可以阅读一些开源 JTA 实现以进一步深入学习。

来源：  https://www.ibm.com/developerworks/cn/java/j-lo-jta/index.html

收集到篇关于docker下安装mongodb的文章， 原文地址在后面给出， 记录在这里。

一. 准备工作

• 安装docker
• 安装docker-compose

注意

1. docker通过unix socket通信, 需要sudo权限, 每次操作docker都需要在命令行前添加sudo, 比较烦, 官方给出了方法.安装docker是会创建docker用户组, 也拥有unix socker读写权限, 将当前用户添加至docker用户组, 即可免除命令行前添加sudo. 参考
2. 容器间默认通过网桥连接内外部网络, 主机需要允许网卡转发
3. docker 网桥默认网段为172.17.42.1/16, 公司vpn默认对网段172.17.0.0/20路由, 会覆盖docker网段, 导致容器无法与外部网络通信, 修改/etc/default/docker, 添加DOCKER_OPTS="--bip=192.168.1.0/20", 这里网段是容器间的内部网络, 可以自行修改, 改到满意.
4. 国内使用官方镜像比较慢，建议使用国内第三方镜像加速。如：DaoCloud，阿里云

二. 实验

(一) 主从模式

• 准备工作
  1. 创建db目录 mkdir -p /data/mongodbtest/master /data/mongodbtest/slaver
  2. `docker-compose.yml内容如下:

     version: '2'
     services:
       master:
         image: mongo:latest
         volumes:
           - /data/mongodbtest/master:/data/db
         command: mongod --dbpath /data/db  --master
       slaver:
         image: mongo:latest
         volumes:
           - /data/mongodbtest/slaver:/data/db
         command: mongod --dbpath /data/db --slave --source master:27017
         links:
          - master

• 启动容器docker-compose up -d
  

  注: docker-compose会默认将文件夹名字作为容器名的前缀, 我的文件夹为masterslave, 容器明分别为masterslave_master_1和masterslave_slave_1

• 验证
  在master中插入一条记录:

  docker-compose exec master mongo
  use test
  db.test.insert({msg: "from master", ts: new Date()})

  查看slave中的数据, 执行

  docker-compose exec slaver mongo
  rs.slaveOk()
  use test
  db.test.find()
  db.test.insert({msg: 'from slaver', ts: new Date()})  //报错, slaver只有读权限

  查看slave服务信息

  db.printReplicationInfo()

  测试故障转移:首先, 关闭master, docker-compose stop master; 其次, 重新连接slave,查看服务信息, 插入数据.如下:

  docker-compose exec slaver mongo
  db.printReplicationInfo() //依然是slave, 没有自动切换为master
  use test
  db.testData.insert({msg: "from slave", ts: new Date()}) //插入失败

• 总结
  简单的master-slave模型仅仅做了一个数据复制, 而且并不可靠, master挂了整体将无法进行写操作

(二) 副本集(Relica set)

• 介绍

三实例

1主 + 2次要

• 准备工作
  1. 创建db文件夹

     mkdir -p /data/mongodbtest/replset/rs1 /data/mongodbtest/replset/rs2 /data/mongodbtest/replset/rs2

  2. docker-compose.yml

     version: '3'
     services:
       rs1:
         image: mongo:latest
         volumes:
           - /data/mongodbtest/replset/rs1:/data/db
         command: mongod --dbpath /data/db --replSet myset
       rs2:
         image: mongo:latest
         volumes:
           - /data/mongodbtest/replset/rs2:/data/db
         command: mongod --dbpath /data/db --replSet myset
       rs3:
         image: mongo:2.7.8
         volumes:
           - /data/mongodbtest/replset/rs3:/data/db
         command: mongod --dbpath /data/db --replSet myset

• 初始化副本级

  docker-compose exec rs1 mongo
  rs.initiate()
  rs.add('rs2:27017')
  rs.add('rs3:27017')
  rs.conf() //查看配置
  rs.status() //查看副本级状态

• 验证
  • 数据复制功能

    docker-compose exec rs1 mongo
    use test
    db.test.insert({msg: 'from primary', ts: new Date()})
    quit()
    docker-compose exec rs2 mongo
    rs.slaveOk() //副本集默认仅primary可读写
    use test
    db.test.find()
    quit()
    docker-compose exec rs3 mongo
    rs.slaveOk() //副本集默认仅primary可读写
    use test
    db.test.find()
    quit()

  • 故障转移功能
    副本集在 primary 挂掉以后, 可以在 secondary 中选取出新的 primary

    docker-compose stop rs1

    登录 rs2/rs3 中查看可以看到，选出了新的 primary ，这时候我们重新启动 rs1，它成为了 secondary

    docker-compose start rs1
    docker-compose exec rs1 mongo

• 总结
  通过客户端的设置, 可以进行主副节点读写分离:

  a). primary:默认参数, 只从主节点上进行读取操作;
  b). primaryPreferred:大部分从主节点上读取数据, 只有主节点不可用时从secondary节点读取数据;
  c). secondary:只从secondary节点上进行读取操作, 存在的问题是secondary节点的数据会比primary节点数据"旧";
  d). secondaryPreferred:优先从secondary节点进行读取操作, secondary节点不可用时从主节点读取数据;
  e). nearest:不管是主节点,secondary节点, 从网络延迟最低的节点上读取数据.

  副节点不是越多越好, 因为引主节点做写操作, 其他副节点从主节点复制数据, 副节点越多, 主节点压力越大.

1主 + 1副 + 1仲裁

• 准备工作
  1. 删除/data/mongodbtest/replset/rs[1-3]/ 下的内容
  2. docker-compose.yml

     version: '3'
     services:
       rs1:
         image: mongo:latest
         volumes:
           - /data/mongodbtest/replset/rs1:/data/db
         command: mongod --dbpath /data/db --replSet myset --oplogSize 128
       secondary:
         image: mongo:latest
         volumes:
           - /data/mongodbtest/replset/rs2:/data/db
         command: mongod --dbpath /data/db --replSet myset --oplogSize 128
       arbiter:
         image: mongo:latest
         command: mongod --dbpath /data/db --replSet myset --smallfiles --oplogSize 128

• 启动

  docker-compose up -d

• 初始化副本级

  mongo rs1:27017  
  rs.initiate()
  rs.add('rs2:27017')
  rs.add('rs3:27017', true) // arbiter only
  rs.conf() //查看配置
  rs.status() //查看副本级状态

• 验证(同上)
• 总结
  每个副本集对主节点都是全量拷贝, 数量压力增大的时候, 节点压力随之变大. 无法自动扩张.

限制

在官方文档中提到了副本集的一些限制:

• 一个副本集成员不能超过12个
• 副本集最多有50个成员
• 可以投票的成员最多7个
• 如果启动 mongod 的时候没有通过 --oplogSize 制定 oplog 的大小，默认 oplog 最大为 50G

分片

MongoDB 提供了水平扩展的功能，其 Sharding 机制使其具备了支撑大数据量和大吞吐量的能力。
在一个 Sharding 集群中，有下面三种角色：

• shard: 每个 shard 存储整个 sharding 集群数据的一个子集，每一个 shard 都是一个 replset
• mongos: 查询路由，客户端通过其从 shard 中查询数据，也可以理解为 proxy
• config servers: 配置服务器，存储整个 sharding 集群的元数据和配置。
  

  MongoDB 3.4 起，要求 config servers 也是 replset。
  MongoDB 提供两种分片策略：hash sharding 和 range sharding，需要根据自己的业务特征和数据特征进行选择。

测试版

• 环境
  1 config servers(csrs) + 1 mongos + 1shard(1primary + 1secondary + 1arbiter)
• 准备工作
  1. 创建文件夹

     mkdir -p /data/mongodbtest/cs/rs1 /data/mongodbtest/cs/rs2 /data/mongodbtest/cs/rs3 # for config server replset
     mkdir -p /data/mongodbtest/sh/rs1 /data/mongodbtest/sh/rs2 /data/mongodbtest/sh/rs3 # for sharding 1
     mkdir -p /data/mongodbtest/mongos

  2. keyfile
     MongoDB 规定 sharding 集群内部必须有授权机制，比如 mongos 去访问 config server的时候，我们这里通过key
  3. docker-compose.yml

     version: '3'
     services:
       csrs1:
         image: mongo:latest
         volumes:
           - /data/mongodbtest/cs/rs1:/data/db
         command: mongod --noauth --configsvr --replSet csrs --dbpath /data/db
       csrs2:
         image: mongo:latest
         volumes:
           - /data/mongodbtest/cs/rs2:/data/db
         command: mongod --noauth --configsvr --replSet csrs --dbpath /data/db
       csrs3:
         image: mongo:latest
         volumes:
           - /data/mongodbtest/cs/rs3:/data/db
         command: mongod --noauth --configsvr --replSet csrs --dbpath /data/db
       mongos:
         image: mongo:latest
         command: mongos --noauth --configdb csrs/csrs1:27019,csrs2:27019,csrs3:27019
       shrs1:
         image: mongo:latest
         volumes:
           - /data/mongodbtest/sh/rs1:/data/db
         command: mongod --noauth --dbpath /data/db --shardsvr --replSet shrs
       shrs2:
         image: mongo:latest
         volumes:
           - /data/mongodbtest/sh/rs2:/data/db
         command: mongod --noauth --dbpath /data/db --shardsvr --replSet shrs
       shrs3:
         image: mongo:latest
         volumes:
           - /data/mongodbtest/sh/rs3:/data/db
         command: mongod --noauth --dbpath /data/db --shardsvr --replSet shrs

• 启动 docker-compose up -d
• 配置副本集
  1. 配置 config server

     docker-compose exec csrs1 mongo --port 27019
     rs.initiate()
     
     rs.add('csrs2:27019')
     rs.add('csrs3:27019')
     rs.status() //查看状态
     quit()

     config server 默认端口为 27019

  2. 配置 shard server

     docker-compose exec shrs1 mongo --port 27018
     rs.initiate()
     var cfg = rs.conf()
     cfg.members[0].host = 'shrs1:27018'
     rs.reconfig(cfg)
     rs.add('shrs2:27018')
     rs.add('shrs3:27018')
     quit()

     'shard server' 默认端口号为 27018

• 配置 mongos

  docker-compose exec mongos mongo
  sh.addShard('shrs/shrs1:27018')
  sh.status() //查看状态