（1）使用 docker 命令拉取镜像
1 | docker pull flink |
（2）编写 docker-compose.yml，内容如下：
1 | version: '2.1' |
（3）执行 docker-compose，命令如下：
1 | docker-compose up -d |
（4）打开浏览器，访问 http://127.0.0.1:8081
1 | # jobManager 的IP地址 |
1 | # 可以选择 'NONE' 或者 'zookeeper'. |
1 | # 用于存储和检查点状态 |
1 | # 基于 Web 的运行时监视器侦听的地址. |
1 | # io.tmp.dirs: /tmp |
1 | 指示是否从 Kerberos ticket 缓存中读取 |
1 | # 覆盖以下配置以提供自定义 ZK 服务名称 |
为了避免存储在 Zookeeper 上的数据被其他程序或者人为误修改，Zookeeper 提供了 ACL(Access Control Lists) 进行权限控制。
ACL 权限可以针对节点设置相关读写等权限，保障数据安全性。
ZooKeeper ACL 提供了以下几种命令行：
Zookeeper 的 acl 通过 [scheme:id:permissions] 来构成权限列表。
world:anyone:[permissons]；auth:user:password:[permissons]，使用这种模式时，你需要先进行登录，之后采用 auth 模式设置权限时，user 和 password 都将使用登录的用户名和密码；auth:user:BASE64(SHA1(password)):[permissons]，这种形式下的密码必须通过 SHA1 和 BASE64 进行双重加密；ip:182.168.0.168:[permissions]；想要给某个节点设置权限 (ACL)，有以下两个可选的命令：
1 | # 1.给已有节点赋予权限 |
查看指定节点的权限命令如下：
1 | getAcl path |
可以使用如下所示的命令为当前 Session 添加用户认证信息，等价于登录操作。
1 | # 格式 |
world 是一种默认的模式，即创建时如果不指定权限，则默认的权限就是 world。
1 | [zk: localhost:2181(CONNECTED) 32] create /mytest abc |
1 | [zk: localhost:2181(CONNECTED) 36] addauth digest test:root # 登录 |
1 | [zk:44] create /spark "spark" digest:heibai:sCxtVJ1gPG8UW/jzFHR0A1ZKY5s=:cdrwa #指定用户名和加密后的密码 |
到这里你可以发现使用 auth 模式设置的权限和使用 digest 模式设置的权限，在最终结果上，得到的权限模式都是 digest。某种程度上，你可以把 auth 模式理解成是 digest 模式的一种简便实现。因为在 digest 模式下，每次设置都需要书写用户名和加密后的密码，这是比较繁琐的，采用 auth 模式就可以避免这种麻烦。
限定只有特定的 ip 才能访问。
1 | [zk: localhost:2181(CONNECTED) 46] create /hive "hive" ip:192.168.0.108:cdrwa |
这里可以看到当前主机已经不能访问，想要能够再次访问，可以使用对应 IP 的客户端，或使用下面介绍的 super 模式。
需要修改启动脚本 zkServer.sh，并在指定位置添加超级管理员账户和密码信息：
1 | "-Dzookeeper.DigestAuthenticationProvider.superDigest=heibai:sCxtVJ1gPG8UW/jzFHR0A1ZKY5s=" |
修改完成后需要使用 zkServer.sh restart 重启服务，此时再次访问限制 IP 的节点：
1 | [zk: localhost:2181(CONNECTED) 0] get /hive #访问受限 |
ZooKeeper 命令用于在 ZooKeeper 服务上执行操作。
1 | # 启动服务 |
ls 命令ls 命令用于查看某个路径下目录列表。
【语法】
1 | ls path |
说明：
- path：代表路径。
【示例】
1 | [zk: localhost:2181(CONNECTED) 0] ls / |
ls2 命令ls2 命令用于查看某个路径下目录列表，它比 ls 命令列出更多的详细信息。
【语法】
1 | ls2 path |
说明：
- path：代表路径。
【示例】
1 | [zk: localhost:2181(CONNECTED) 1] ls2 / |
get 命令get 命令用于获取节点数据和状态信息。
【语法】
1 | get path [watch] |
说明：
- path：代表路径。
- **[watch]**：对节点进行事件监听。
【示例】
1 | [zk: localhost:2181(CONNECTED) 31] get /hadoop |
说明：
节点各个属性如下表。其中一个重要的概念是 Zxid(ZooKeeper Transaction Id)，ZooKeeper 节点的每一次更改都具有唯一的 Zxid，如果 Zxid1 小于 Zxid2，则 Zxid1 的更改发生在 Zxid2 更改之前。
状态属性 说明 cZxid 数据节点创建时的事务 ID ctime 数据节点创建时的时间 mZxid 数据节点最后一次更新时的事务 ID mtime 数据节点最后一次更新时的时间 pZxid 数据节点的子节点最后一次被修改时的事务 ID cversion 子节点的更改次数 dataVersion 节点数据的更改次数 aclVersion 节点的 ACL 的更改次数 ephemeralOwner 如果节点是临时节点，则表示创建该节点的会话的 SessionID；如果节点是持久节点，则该属性值为 0 dataLength 数据内容的长度 numChildren 数据节点当前的子节点个数
stat 命令stat 命令用于查看节点状态信息。它的返回值和 get 命令类似，但不会返回节点数据。
【语法】
1 | stat path [watch] |
【示例】
1 | [zk: localhost:2181(CONNECTED) 32] stat /hadoop |
create 命令create 命令用于创建节点并赋值。
【语法】
1 | create [-s] [-e] path data acl |
说明：
- **[-s][-e]**：-s 和 -e 都是可选的，-s 代表顺序节点，-e 代表临时节点，注意其中 -s 和 -e 可以同时使用的，并且临时节点不能再创建子节点。
- 默认情况下，所有 znode 都是持久的。
- 顺序节点保证 znode 路径将是唯一的。
- 临时节点会在会话过期或客户端断开连接时被自动删除。
- path：指定要创建节点的路径，比如 /hadoop。
- data：要在此节点存储的数据。
- acl：访问权限相关，默认是 world，相当于全世界都能访问。
【示例】创建持久节点
1 | [zk: localhost:2181(CONNECTED) 4] create /hadoop 123456 |
【示例】创建有序节点，此时创建的节点名为指定节点名 + 自增序号：
1 | [zk: localhost:2181(CONNECTED) 23] create -s /a "aaa" |
【示例】创建临时节点：
1 | [zk: localhost:2181(CONNECTED) 26] create -e /tmp "tmp" |
set 命令set 命令用于修改节点存储的数据。
【语法】
1 | set path data [version] |
说明：
- path：节点路径。
- data：需要存储的数据。
- **[version]**：可选项，版本号(可用作乐观锁)。
【示例】
1 | [zk: localhost:2181(CONNECTED) 33] set /hadoop 345 |
也可以基于版本号进行更改，此时类似于乐观锁机制，当你传入的数据版本号 (dataVersion) 和当前节点的数据版本号不符合时，zookeeper 会拒绝本次修改：
1 | [zk: localhost:2181(CONNECTED) 34] set /hadoop 678 0 |
delete 命令delete 命令用于删除某节点。
【语法】
1 | delete path [version] |
说明：
- path：节点路径。
- **[version]**：可选项，版本号（同 set 命令）。和更新节点数据一样，也可以传入版本号，当你传入的数据版本号 (dataVersion) 和当前节点的数据版本号不符合时，zookeeper 不会执行删除操作。
【示例】
1 | [zk: localhost:2181(CONNECTED) 36] delete /hadoop 0 |
delete 命令不能删除带有子节点的节点。如果想要删除节点及其子节点，可以使用 deleteall path
针对每个节点的操作，都会有一个监听者（watcher）。
使用 get path -w 注册的监听器能够在节点内容发生改变的时候，向客户端发出通知。需要注意的是 zookeeper 的触发器是一次性的 (One-time trigger)，即触发一次后就会立即失效。
1 | [zk: localhost:2181(CONNECTED) 4] get /hadoop -w |
get path [watch] 在当前版本已废弃
使用 stat path -w 注册的监听器能够在节点状态发生改变的时候，向客户端发出通知。
1 | [zk: localhost:2181(CONNECTED) 7] stat path -w |
stat path [watch] 在当前版本已废弃
使用 ls path -w 或 ls2 path -w 注册的监听器能够监听该节点下所有子节点的增加和删除操作。
1 | [zk: localhost:2181(CONNECTED) 9] ls /hadoop -w |
ls path [watch] 和 ls2 path [watch] 在当前版本已废弃
使用 help 可以查看所有命令帮助信息。
使用 history 可以查看最近 10 条历史记录。
| 命令 | 功能描述 |
|---|---|
| conf | 打印服务配置的详细信息。 |
| cons | 列出连接到此服务器的所有客户端的完整连接/会话详细信息。包括接收/发送的数据包数量，会话 ID，操作延迟，上次执行的操作等信息。 |
| dump | 列出未完成的会话和临时节点。这只适用于 Leader 节点。 |
| envi | 打印服务环境的详细信息。 |
| ruok | 测试服务是否处于正确状态。如果正确则返回“imok”，否则不做任何相应。 |
| stat | 列出服务器和连接客户端的简要详细信息。 |
| wchs | 列出所有 watch 的简单信息。 |
| wchc | 按会话列出服务器 watch 的详细信息。 |
| wchp | 按路径列出服务器 watch 的详细信息。 |
更多四字命令可以参阅官方文档：https://zookeeper.apache.org/doc/current/zookeeperAdmin.html
使用前需要使用 yum install nc 安装 nc 命令，使用示例如下：
1 | [root@hadoop001 bin]# echo stat | nc localhost 2181 |
ZooKeeper 是 Apache 的顶级项目。ZooKeeper 为分布式应用提供了高效且可靠的分布式协调服务，提供了诸如统一命名服务、配置管理和分布式锁等分布式的基础服务。在解决分布式数据一致性方面，ZooKeeper 并没有直接采用 Paxos 算法，而是采用了名为 ZAB 的一致性协议。
ZooKeeper 主要用来解决分布式集群中应用系统的一致性问题，它能提供基于类似于文件系统的目录节点树方式的数据存储。但是 ZooKeeper 并不是用来专门存储数据的，它的作用主要是用来维护和监控存储数据的状态变化。通过监控这些数据状态的变化，从而可以达到基于数据的集群管理。
很多大名鼎鼎的框架都基于 ZooKeeper 来实现分布式高可用，如：Dubbo、Kafka 等。
ZooKeeper 官方支持 Java 和 C 的 Client API。ZooKeeper 社区为大多数语言（.NET，python 等）提供非官方 API。
客户端和服务端交互遵循以下基本步骤：
ZooKeeper 官方客户端的核心是 ZooKeeper 类。它在其构造函数中提供了连接 ZooKeeper 服务的配置选项，并提供了访问 ZooKeeper 数据的方法。
其主要操作如下：
connect- 连接 ZooKeeper 服务create- 创建 znodeexists- 检查 znode 是否存在及其信息getACL/setACL- 获取/设置一个 znode 的 ACLgetData/setData- 获取/设置一个 znode 的数据getChildren- 获取特定 znode 中的所有子节点delete- 删除特定的 znode 及其所有子项close- 关闭连接
ZooKeeper 官方客户端的使用方法是在 maven 项目的 pom.xml 中添加：
1 | <dependency> |
ZooKeeper 类通过其构造函数提供连接 ZooKeeper 服务的功能。其构造函数的定义如下：
1 | ZooKeeper(String connectionString, int sessionTimeout, Watcher watcher) |
参数说明：
connectionString- ZooKeeper 集群的主机列表。sessionTimeout- 会话超时时间（以毫秒为单位）。- watcher - 实现监视机制的回调。当被监控的 znode 状态发生变化时，ZooKeeper 服务端的
WatcherManager会主动调用传入的 Watcher ，推送状态变化给客户端。
【示例】连接 ZooKeeper
1 | import org.apache.zookeeper.Watcher; |
说明：
添加一个
connect方法，用于创建一个ZooKeeper对象，用于连接到 ZooKeeper 服务。这里
CountDownLatch用于停止（等待）主进程，直到客户端与 ZooKeeper 集合连接。
ZooKeeper对象通过监听器回调来监听连接状态。一旦客户端与 ZooKeeper 建立连接，监听器回调就会被调用；并且监听器回调函数调用CountDownLatch的countDown方法来释放锁，在主进程中await。
ZooKeeper 类提供了 exists 方法来检查 znode 的存在。如果指定的 znode 存在，则返回一个 znode 的元数据。
exists 方法的签名如下：
1 | exists(String path, boolean watcher) |
【示例】
1 | Stat stat = zk.exists("/", true); |
ZooKeeper 类的 create 方法用于在 ZooKeeper 中创建一个新节点（znode）。
create 方法的签名如下：
1 | create(String path, byte[] data, List<ACL> acl, CreateMode createMode) |
【示例】
1 | private static final String path = "/mytest"; |
ZooKeeper 类提供了 delete 方法来删除指定的 znode。
delete 方法的签名如下：
1 | delete(String path, int version) |
让我们创建一个新的 Java 应用程序来了解 ZooKeeper API 的 delete 功能。创建文件 ZKDelete.java 。在 main 方法中，使用 ZooKeeperConnection 对象创建一个 ZooKeeper 对象 zk 。然后，使用指定的路径和版本号调用 zk 对象的 delete 方法。
删除 znode 的完整程序代码如下：
【示例】
1 | zk.delete(path, zk.exists(path, true).getVersion()); |
ZooKeeper 类提供 getData 方法来获取附加在指定 znode 中的数据及其状态。 getData 方法的签名如下：
1 | getData(String path, Watcher watcher, Stat stat) |
【示例】
1 | byte[] data = zk.getData(path, false, null); |
ZooKeeper 类提供 setData 方法来修改指定 znode 中附加的数据。 setData 方法的签名如下：
1 | setData(String path, byte[] data, int version) |
【示例】
1 | String text = "含子节点的节点"; |
ZooKeeper 类提供 getChildren 方法来获取特定 znode 的所有子节点。 getChildren 方法的签名如下：
1 | getChildren(String path, Watcher watcher) |
【示例】
1 |
|
Curator 客户端的使用方法是在 maven 项目的 pom.xml 中添加：
1 | <dependency> |
1 | import org.apache.curator.RetryPolicy; |
1 | Stat stat = client.checkExists().forPath(path); |
1 | CuratorFrameworkState state = client.getState(); |
1 | // 创建节点 |
1 | client.delete() |
1 | byte[] data = client.getData().forPath(path); |
1 | String text2 = "try again"; |
1 | List<String> children = client.getChildren().forPath(path); |
和 Zookeeper 原生监听一样，使用 usingWatcher 注册的监听是一次性的，即监听只会触发一次，触发后就销毁。
【示例】
1 | // 设置监听器 |
输出
1 | 节点 /mytest 发生了事件：NodeDataChanged |
说明
修改两次数据，但是监听器只会监听第一次修改。
Curator 还提供了创建永久监听的 API，其使用方式如下：
1 | // 设置监听器 |
这里以监听 /hadoop 下所有子节点为例，实现方式如下：
1 | // 创建节点 |
1 | public class AclOperation { |
Memcached 是一个自由开源的，高性能，分布式内存对象缓存系统。
Memcached 是一种基于内存的 key-value 存储，用来存储小块的任意数据（字符串、对象）。这些数据可以是数据库调用、API 调用或者是页面渲染的结果。
Memcached 简洁而强大。它的简洁设计便于快速开发，减轻开发难度，解决了大数据量缓存的很多问题。它的 API 兼容大部分流行的开发语言。本质上，它是一个简洁的 key-value 存储系统。
memcached 作为高速运行的分布式缓存服务器，具有以下的特点。
可以通过 telnet 命令并指定主机 ip 和端口来连接 Memcached 服务。
1 | telnet 127.0.0.1 11211 |
使用 Java 程序连接 Memcached，需要在你的 classpath 中添加 Memcached jar 包。
本站 jar 包下载地址：spymemcached-2.10.3.jar。
Google Code jar 包下载地址：spymemcached-2.10.3.jar（需要科学上网）。
以下程序假定 Memcached 服务的主机为 127.0.0.1，端口为 11211。
1 | import net.spy.memcached.MemcachedClient; |
jetty 是什么？
jetty 是轻量级的 web 服务器和 servlet 引擎。
它的最大特点是：可以很方便的作为嵌入式服务器。
它是 eclipse 的一个开源项目。不用怀疑，就是你常用的那个 eclipse。
它是使用 Java 开发的，所以天然对 Java 支持良好。
什么是嵌入式服务器？
以 jetty 来说明，就是只要引入 jetty 的 jar 包，可以通过直接调用其 API 的方式来启动 web 服务。
用过 Tomcat、Resin 等服务器的朋友想必不会陌生那一套安装、配置、部署的流程吧，还是挺繁琐的。使用 jetty，就不需要这些过程了。
jetty 非常适用于项目的开发、测试，因为非常快捷。如果想用于生产环境，则需要谨慎考虑，它不一定能像成熟的 Tomcat、Resin 等服务器一样支持企业级 Java EE 的需要。
我觉得嵌入式启动方式的一个好处在于：可以直接运行项目，无需每次部署都得再配置服务器。
jetty 的嵌入式启动使用有两种方式：
API 方式
maven 插件方式
添加 maven 依赖
1 | <dependency> |
官方的启动代码
1 | public class SplitFileServer |
直接运行 Main 方法，就可以启动 web 服务。
注：以上代码在 eclipse 中运行没有问题，如果想在 Intellij 中运行还需要为它指定配置文件。
如果想了解在 Eclipse 和 Intellij 都能运行的通用方法可以参考我的 github 代码示例。
我的实现也是参考 springside 的方式。
代码行数有点多，不在这里贴代码了。
如果你熟悉 maven，那么实在太简单了
注： Maven 版本必须在 3.3 及以上版本。
(1) 添加 maven 插件
1 | <plugin> |
(2) 执行 maven 命令：
1 | mvn jetty:run |
讲真，就是这么简单。jetty 默认会为你创建一个 web 服务，地址为 127.0.0.1:8080。
当然，你也可以在插件中配置你的 webapp 环境
1 | <plugin> |
官方给的 jetty-env.xml 范例
1 |
|
Jetty Server 就是由多个 Connector（连接器）、多个 Handler（处理器），以及一个线程池组成。
跟 Tomcat 一样，Jetty 也有 HTTP 服务器和 Servlet 容器的功能，因此 Jetty 中的 Connector 组件和 Handler 组件分别来实现这两个功能，而这两个组件工作时所需要的线程资源都直接从一个全局线程池 ThreadPool 中获取。
Jetty Server 可以有多个 Connector 在不同的端口上监听客户请求，而对于请求处理的 Handler 组件，也可以根据具体场景使用不同的 Handler。这样的设计提高了 Jetty 的灵活性，需要支持 Servlet，则可以使用 ServletHandler；需要支持 Session，则再增加一个 SessionHandler。也就是说我们可以不使用 Servlet 或者 Session，只要不配置这个 Handler 就行了。
为了启动和协调上面的核心组件工作，Jetty 提供了一个 Server 类来做这个事情，它负责创建并初始化 Connector、Handler、ThreadPool 组件，然后调用 start 方法启动它们。
对比一下 Tomcat 的整体架构图，你会发现 Tomcat 在整体上跟 Jetty 很相似，它们的第一个区别是 Jetty 中没有 Service 的概念，Tomcat 中的 Service 包装了多个连接器和一个容器组件，一个 Tomcat 实例可以配置多个 Service，不同的 Service 通过不同的连接器监听不同的端口；而 Jetty 中 Connector 是被所有 Handler 共享的。
第二个区别是，在 Tomcat 中每个连接器都有自己的线程池，而在 Jetty 中所有的 Connector 共享一个全局的线程池。
跟 Tomcat 一样，Connector 的主要功能是对 I/O 模型和应用层协议的封装。I/O 模型方面，最新的 Jetty 9 版本只支持 NIO，因此 Jetty 的 Connector 设计有明显的 Java NIO 通信模型的痕迹。至于应用层协议方面，跟 Tomcat 的 Processor 一样，Jetty 抽象出了 Connection 组件来封装应用层协议的差异。
服务端在 NIO 通信上主要完成了三件事情：监听连接、I/O 事件查询以及数据读写。因此 Jetty 设计了Acceptor、SelectorManager 和 Connection 来分别做这三件事情
Acceptor 用于接受请求。跟 Tomcat 一样，Jetty 也有独立的 Acceptor 线程组用于处理连接请求。在 Connector 的实现类 ServerConnector 中，有一个 _acceptors 的数组，在 Connector 启动的时候, 会根据 _acceptors 数组的长度创建对应数量的 Acceptor，而 Acceptor 的个数可以配置。
1 | for (int i = 0; i < _acceptors.length; i++) |
Acceptor 是 ServerConnector 中的一个内部类，同时也是一个 Runnable，Acceptor 线程是通过 getExecutor() 得到的线程池来执行的，前面提到这是一个全局的线程池。
Acceptor 通过阻塞的方式来接受连接，这一点跟 Tomcat 也是一样的。
1 | public void accept(int acceptorID) throws IOException |
接受连接成功后会调用 accepted() 函数，accepted() 函数中会将 SocketChannel 设置为非阻塞模式，然后交给 Selector 去处理，因此这也就到了 Selector 的地界了。
1 | private void accepted(SocketChannel channel) throws IOException |
SelectorManager
Jetty 的 Selector 由 SelectorManager 类管理，而被管理的 Selector 叫作 ManagedSelector。SelectorManager 内部有一个 ManagedSelector 数组，真正干活的是 ManagedSelector。咱们接着上面分析，看看在 SelectorManager 在 accept 方法里做了什么。
1 | public void accept(SelectableChannel channel, Object attachment) |
SelectorManager 从本身的 Selector 数组中选择一个 Selector 来处理这个 Channel，并创建一个任务 Accept 交给 ManagedSelector，ManagedSelector 在处理这个任务主要做了两步：
第一步，调用 Selector 的 register 方法把 Channel 注册到 Selector 上，拿到一个 SelectionKey。
1 | _key = _channel.register(selector, SelectionKey.OP_ACCEPT, this); |
第二步，创建一个 EndPoint 和 Connection，并跟这个 SelectionKey（Channel）绑在一起：
1 | private void createEndPoint(SelectableChannel channel, SelectionKey selectionKey) throws IOException |
这里需要你特别注意的是，ManagedSelector 并没有直接调用 EndPoint 的方法去处理数据，而是通过调用 EndPoint 的方法返回一个 Runnable，然后把这个 Runnable 扔给线程池执行，所以你能猜到，这个 Runnable 才会去真正读数据和处理请求。
Connection
这个 Runnable 是 EndPoint 的一个内部类，它会调用 Connection 的回调方法来处理请求。Jetty 的 Connection 组件类比就是 Tomcat 的 Processor，负责具体协议的解析，得到 Request 对象，并调用 Handler 容器进行处理。下面我简单介绍一下它的具体实现类 HttpConnection 对请求和响应的处理过程。
请求处理：HttpConnection 并不会主动向 EndPoint 读取数据，而是向在 EndPoint 中注册一堆回调方法：
1 | getEndPoint().fillInterested(_readCallback); |
这段代码就是告诉 EndPoint，数据到了你就调我这些回调方法 _readCallback 吧，有点异步 I/O 的感觉，也就是说 Jetty 在应用层面模拟了异步 I/O 模型。
而在回调方法 _readCallback 里，会调用 EndPoint 的接口去读数据，读完后让 HTTP 解析器去解析字节流，HTTP 解析器会将解析后的数据，包括请求行、请求头相关信息存到 Request 对象里。
响应处理：Connection 调用 Handler 进行业务处理，Handler 会通过 Response 对象来操作响应流，向流里面写入数据，HttpConnection 再通过 EndPoint 把数据写到 Channel，这样一次响应就完成了。
到此你应该了解了 Connector 的工作原理，下面我画张图再来回顾一下 Connector 的工作流程。
Acceptor 监听连接请求，当有连接请求到达时就接受连接，一个连接对应一个 Channel，Acceptor 将 Channel 交给 ManagedSelector 来处理。
ManagedSelector 把 Channel 注册到 Selector 上，并创建一个 EndPoint 和 Connection 跟这个 Channel 绑定，接着就不断地检测 I/O 事件。
I/O 事件到了就调用 EndPoint 的方法拿到一个 Runnable，并扔给线程池执行。
线程池中调度某个线程执行 Runnable。
Runnable 执行时，调用回调函数，这个回调函数是 Connection 注册到 EndPoint 中的。
回调函数内部实现，其实就是调用 EndPoint 的接口方法来读数据。
Connection 解析读到的数据，生成请求对象并交给 Handler 组件去处理。
Jetty 的 Handler 设计是它的一大特色，Jetty 本质就是一个 Handler 管理器，Jetty 本身就提供了一些默认 Handler 来实现 Servlet 容器的功能，你也可以定义自己的 Handler 来添加到 Jetty 中，这体现了“微内核 + 插件”的设计思想。
Handler 就是一个接口，它有一堆实现类，Jetty 的 Connector 组件调用这些接口来处理 Servlet 请求。
1 | public interface Handler extends LifeCycle, Destroyable |
方法说明：
Handler 的 handle 方法跟 Tomcat 容器组件的 service 方法一样，它有 ServletRequest 和 ServeletResponse 两个参数。Handler 都需要关联一个 Server 组件，Handler 需要被 Server 组件来管理。Handler 通过 setServer 和 getServer 方法绑定 Server。Handler 会加载一些资源到内存，因此通过设置 destroy 方法来销毁。Handler 只是一个接口，完成具体功能的还是它的子类。那么 Handler 有哪些子类呢？它们的继承关系又是怎样的？这些子类是如何实现 Servlet 容器功能的呢？
在 AbstractHandler 之下有 AbstractHandlerContainer，为什么需要这个类呢？这其实是个过渡，为了实现链式调用，一个 Handler 内部必然要有其他 Handler 的引用，所以这个类的名字里才有 Container，意思就是这样的 Handler 里包含了其他 Handler 的引用。
HandlerWrapper 和 HandlerCollection 都是 Handler，但是这些 Handler 里还包括其他 Handler 的引用。不同的是，HandlerWrapper 只包含一个其他 Handler 的引用，而 HandlerCollection 中有一个 Handler 数组的引用。
HandlerWrapper 有两个子类：Server 和 ScopedHandler。
HandlerCollection 其实维护了一个 Handler 数组。这是为了同时支持多个 Web 应用，如果每个 Web 应用有一个 Handler 入口，那么多个 Web 应用的 Handler 就成了一个数组，比如 Server 中就有一个 HandlerCollection，Server 会根据用户请求的 URL 从数组中选取相应的 Handler 来处理，就是选择特定的 Web 应用来处理请求。
Handler 可以分成三种类型：
ServletHandler、ContextHandler 以及 WebAppContext 等，它们实现了 Servlet 规范。
Servlet 规范中有 Context、Servlet、Filter、Listener 和 Session 等，Jetty 要支持 Servlet 规范，就需要有相应的 Handler 来分别实现这些功能。因此，Jetty 设计了 3 个组件：ContextHandler、ServletHandler 和 SessionHandler 来实现 Servle 规范中规定的功能，而WebAppContext 本身就是一个 ContextHandler，另外它还负责管理 ServletHandler 和 SessionHandler。
ContextHandler 会创建并初始化 Servlet 规范里的 ServletContext 对象，同时 ContextHandler 还包含了一组能够让你的 Web 应用运行起来的 Handler，可以这样理解，Context 本身也是一种 Handler，它里面包含了其他的 Handler，这些 Handler 能处理某个特定 URL 下的请求。比如，ContextHandler 包含了一个或者多个 ServletHandler。
ServletHandler 实现了 Servlet 规范中的 Servlet、Filter 和 Listener 的功能。ServletHandler 依赖 FilterHolder、ServletHolder、ServletMapping、FilterMapping 这四大组件。FilterHolder 和 ServletHolder 分别是 Filter 和 Servlet 的包装类，每一个 Servlet 与路径的映射会被封装成 ServletMapping，而 Filter 与拦截 URL 的映射会被封装成 FilterMapping。
SessionHandler 用来管理 Session。除此之外 WebAppContext 还有一些通用功能的 Handler，比如 SecurityHandler 和 GzipHandler，同样从名字可以知道这些 Handler 的功能分别是安全控制和压缩 / 解压缩。
WebAppContext 会将这些 Handler 构建成一个执行链，通过这个链会最终调用到我们的业务 Servlet。
常规的 NIO 编程思路是，将 I/O 事件的侦测和请求的处理分别用不同的线程处理。具体过程是：
启动一个线程，在一个死循环里不断地调用 select 方法，检测 Channel 的 I/O 状态，一旦 I/O 事件达到，比如数据就绪，就把该 I/O 事件以及一些数据包装成一个 Runnable，将 Runnable 放到新线程中去处理。
在这个过程中按照职责划分，有两个线程在干活，一个是 I/O 事件检测线程，另一个是 I/O 事件处理线程。这样的好处是它们互不干扰和阻塞对方。
将 I/O 事件检测和业务处理这两种工作分开的思路也有缺点：当 Selector 检测读就绪事件时，数据已经被拷贝到内核中的缓存了，同时 CPU 的缓存中也有这些数据了，我们知道 CPU 本身的缓存比内存快多了，这时当应用程序去读取这些数据时，如果用另一个线程去读，很有可能这个读线程使用另一个 CPU 核，而不是之前那个检测数据就绪的 CPU 核，这样 CPU 缓存中的数据就用不上了，并且线程切换也需要开销。
因此 Jetty 的 Connector 做了一个大胆尝试，那就是把 I/O 事件的生产和消费放到同一个线程来处理，如果这两个任务由同一个线程来执行，如果执行过程中线程不阻塞，操作系统会用同一个 CPU 核来执行这两个任务，这样就能利用 CPU 缓存了。
ManagedSelector 的本质就是一个 Selector，负责 I/O 事件的检测和分发。为了方便使用，Jetty 在 Java 原生的 Selector 上做了一些扩展，就变成了 ManagedSelector，我们先来看看它有哪些成员变量：
1 | public class ManagedSelector extends ContainerLifeCycle implements Dumpable |
这些成员变量中其他的都好理解，就是“Selector 更新任务”队列_updates和执行策略_strategy可能不是很直观。
为什么需要一个“Selector 更新任务”队列呢，对于 Selector 的用户来说，我们对 Selector 的操作无非是将 Channel 注册到 Selector 或者告诉 Selector 我对什么 I/O 事件感兴趣，那么这些操作其实就是对 Selector 状态的更新，Jetty 把这些操作抽象成 SelectorUpdate 接口。
1 | /** |
这意味着如果你不能直接操作 ManageSelector 中的 Selector，而是需要向 ManagedSelector 提交一个任务类，这个类需要实现 SelectorUpdate 接口 update 方法，在 update 方法里定义你想要对 ManagedSelector 做的操作。
比如 Connector 中 Endpoint 组件对读就绪事件感兴趣，它就向 ManagedSelector 提交了一个内部任务类 ManagedSelector.SelectorUpdate：
1 | _selector.submit(_updateKeyAction); |
这个_updateKeyAction就是一个 SelectorUpdate 实例，它的 update 方法实现如下：
1 | private final ManagedSelector.SelectorUpdate _updateKeyAction = new ManagedSelector.SelectorUpdate() |
我们看到在 update 方法里，调用了 SelectionKey 类的 interestOps 方法，传入的参数是OP_READ，意思是现在我对这个 Channel 上的读就绪事件感兴趣了。
那谁来负责执行这些 update 方法呢，答案是 ManagedSelector 自己，它在一个死循环里拉取这些 SelectorUpdate 任务类逐个执行。
那 I/O 事件到达时，ManagedSelector 怎么知道应该调哪个函数来处理呢？其实也是通过一个任务类接口，这个接口就是 Selectable，它返回一个 Runnable，这个 Runnable 其实就是 I/O 事件就绪时相应的处理逻辑。
1 | public interface Selectable |
ManagedSelector 在检测到某个 Channel 上的 I/O 事件就绪时，也就是说这个 Channel 被选中了，ManagedSelector 调用这个 Channel 所绑定的附件类的 onSelected 方法来拿到一个 Runnable。
这句话有点绕，其实就是 ManagedSelector 的使用者，比如 Endpoint 组件在向 ManagedSelector 注册读就绪事件时，同时也要告诉 ManagedSelector 在事件就绪时执行什么任务，具体来说就是传入一个附件类，这个附件类需要实现 Selectable 接口。ManagedSelector 通过调用这个 onSelected 拿到一个 Runnable，然后把 Runnable 扔给线程池去执行。
那 Endpoint 的 onSelected 是如何实现的呢？
1 |
|
上面的代码逻辑很简单，就是读事件到了就读，写事件到了就写。
铺垫了这么多，终于要上主菜了。前面我主要介绍了 ManagedSelector 的使用者如何跟 ManagedSelector 交互，也就是如何注册 Channel 以及 I/O 事件，提供什么样的处理类来处理 I/O 事件，接下来我们来看看 ManagedSelector 是如何统一管理和维护用户注册的 Channel 集合。再回到今天开始的讨论，ManagedSelector 将 I/O 事件的生产和消费看作是生产者消费者模式，为了充分利用 CPU 缓存，生产和消费尽量放到同一个线程处理，那这是如何实现的呢？Jetty 定义了 ExecutionStrategy 接口：
1 | public interface ExecutionStrategy |
我们看到 ExecutionStrategy 接口比较简单，它将具体任务的生产委托内部接口 Producer，而在自己的 produce 方法里来实现具体执行逻辑，也就是生产出来的任务要么由当前线程执行，要么放到新线程中执行。Jetty 提供了一些具体策略实现类：ProduceConsume、ProduceExecuteConsume、ExecuteProduceConsume 和 EatWhatYouKill。它们的区别是：
分析了这几种线程策略，我们再来看看 Jetty 是如何实现 ExecutionStrategy 接口的。答案其实就是实现 produce 接口生产任务，一旦任务生产出来，ExecutionStrategy 会负责执行这个任务。
1 | private class SelectorProducer implements ExecutionStrategy.Producer |
SelectorProducer 是 ManagedSelector 的内部类，SelectorProducer 实现了 ExecutionStrategy 中的 Producer 接口中的 produce 方法，需要向 ExecutionStrategy 返回一个 Runnable。在这个方法里 SelectorProducer 主要干了三件事情
JSON（JavaScript Object Notation）是一种基于文本的数据交换格式。几乎所有的编程语言都有很好的库或第三方工具来提供基于 JSON 的 API 支持，因此你可以非常方便地使用任何自己喜欢的编程语言来处理 JSON 数据。
本文主要从 Java 语言的角度来讲解 JSON 的应用。
JSON 起源于 1999 年的 JS 语言规范 ECMA262 的一个子集（即 15.12 章节描述了格式与解析），后来 2003 年作为一个数据格式ECMA404（很囧的序号有不有？）发布。
2006 年，作为 rfc4627 发布，这时规范增加到 18 页，去掉没用的部分，十页不到。
JSON 的应用很广泛，这里有超过 100 种语言下的 JSON 库：json.org。
更多的可以参考这里，关于 json 的一切。
这估计是最简单标准规范之一：
{} 表示、内部是 "key":"value"，数组用 [] 表示，不同值用逗号分开false / null / true / object / array / number / string1 | { |
扩展阅读：
http://www.json.org/json-zh.html - 图文并茂介绍 json 数据形式
优点：
缺点：
使用 JSON 实现 RPC（类似 XML-RPC）：JSON-RPC
使用 JSON 实现 path 查询操作（类似 XML-PATH）：JsonPATH
在线查询工具：JsonPATH
格式化工具：jsbeautifier
chrome 插件：5 个 Json View 插件
在线 Mock: 在线 mock
Java 中比较流行的 JSON 库有：
从性能上来看，一般情况下：Fastjson > Jackson > Gson
遵循好的设计与编码风格，能提前解决 80%的问题，个人推荐 Google JSON 风格指南。
简单摘录如下：
JSON API与 Google JSON 风格指南有很多可以相互参照之处。
JSON API是数据交互规范，用以定义客户端如何获取与修改资源，以及服务器如何响应对应请求。
JSON API 设计用来最小化请求的数量，以及客户端与服务器间传输的数据量。在高效实现的同时，无需牺牲可读性、灵活性和可发现性。
1 | <dependency> |
Group.java
1 | public class Group { |
User.java
1 | public class User { |
初始化 Bean
1 | Group group = new Group(); |
1 | String jsonString = JSON.toJSONString(group); |
1 | Group bean = JSON.parseObject(jsonString, Group.class); |
@JSONField扩展阅读：更多 API 使用细节可以参考：JSONField 用法，这里介绍基本用法。
可以配置在属性（setter、getter）和字段（必须是 public field）上。
1 |
|
@JSONTypeJSONType.alphabetic 属性: fastjson 缺省时会使用字母序序列化，如果你是希望按照 java fields/getters 的自然顺序序列化，可以配置 JSONType.alphabetic，使用方法如下：
1 |
|
扩展阅读：更多 API 使用细节可以参考 jackson-databind 官方说明
1 | <dependency> |
1 | ObjectMapper mapper = new ObjectMapper(); |
1 | ObjectMapper mapper = new ObjectMapper(); |
1 | Person p = new Person("Tom", 20); |
扩展阅读：更多注解使用细节可以参考 jackson-annotations 官方说明
@JsonProperty1 | public class MyBean { |
@JsonIgnoreProperties 和 @JsonIgnore1 | // means that if we see "foo" or "bar" in JSON, they will be quietly skipped |
@JsonCreator1 | public class CtorBean { |
@JsonPropertyOrderalphabetic 设为 true 表示，json 字段按自然顺序排列，默认为 false。
1 |
|
详细内容可以参考官方文档：Gson 用户指南
1 | <dependency> |
1 | Gson gson = new Gson(); |
1 | int i1 = gson.fromJson("1", int.class); |
Gson 实例可以通过 GsonBuilder 来定制实例化，以控制其序列化、反序列化行为。
1 | Gson gson = new GsonBuilder() |
@Since@Since 用于控制对象的序列化版本。示例：
1 | public class VersionedClass { |
@SerializedName@SerializedName 用于将类成员按照指定名称序列化、反序列化。示例：
1 | private class SomeObject { |
示例源码：javalib-io-json
原因很简单，就是 Java 默认的序列化机制（ObjectInputStream 和 ObjectOutputStream）具有很多缺点。
不了解 Java 默认的序列化机制，可以参考：Java 序列化
Java 自身的序列化方式具有以下缺点：
Serializable 接口。serialVersionUID。引入二进制序列化库就是为了解决这些问题，这在 RPC 应用中尤为常见。
Protobuf 是 Google 公司内部的混合语言数据标准，是一种轻便、高效的结构化数据存储
格式，可以用于结构化数据序列化，支持 Java、Python、C++、Go 等语言。Protobuf
使用的时候需要定义 IDL（Interface description language），然后使用不同语言的 IDL
编译器，生成序列化工具类。
优点：
缺点：
Thrift 是 apache 开源项目，是一个点对点的 RPC 实现。
它具有以下特性：
Hessian 是动态类型、二进制、紧凑的，并且可跨语言移植的一种序列化框架。Hessian 协
议要比 JDK、JSON 更加紧凑，性能上要比 JDK、JSON 序列化高效很多，而且生成的字节
数也更小。
RPC 框架 Dubbo 就支持 Thrift 和 Hession。
它具有以下特性：
Hessian 本身也有问题，官方版本对 Java 里面一些常见对象的类型不支持：
Kryo 是用于 Java 的快速高效的二进制对象图序列化框架。Kryo 还可以执行自动的深拷贝和浅拷贝。 这是从对象到对象的直接复制，而不是从对象到字节的复制。
它具有以下特性：
FST 是一个 Java 实现二进制序列化库。
它具有以下特性：
了解了以上这些常见的二进制序列化库的特性。在技术选型时，我们就可以做到有的放矢。
（1）选型参考依据
对于二进制序列化库，我们的选型考量一般有以下几点：
（2）选型建议
如果需要跨语言通信，那么可以考虑：Protobuf、Thrift、Hession。
1 | <dependency> |
示例：
1 | import org.nustaq.serialization.FSTConfiguration; |
测试：
1 | long begin = System.currentTimeMillis(); |
1 | <dependency> |
示例：
1 | import com.esotericsoftware.kryo.Kryo; |
测试：
1 | long begin = System.currentTimeMillis(); |
Hessian 应用
1 | Student student = new Student(); |
Lombok 是一种 Java 实用工具，可用来帮助开发人员消除 Java 的冗长，尤其是对于简单的 Java 对象（POJO）。它通过注释实现这一目的。通过在开发环境中实现 Lombok，开发人员可以节省构建诸如 hashCode() 和 equals() 、getter / setter 这样的方法以及以往用来分类各种 accessor 和 mutator 的大量时间。
由于 Lombok 仅在编译阶段生成代码，所以使用 Lombok 注解的源代码，在 IDE 中会被高亮显示错误，针对这个问题可以通过安装 IDE 对应的插件来解决。具体的安装方式可以参考：Setting up Lombok with Eclipse and Intellij
使 IntelliJ IDEA 支持 Lombok 方式如下：
1 | <dependency> |
Lombok 提供注解 API 来修饰指定的类：
@Getter and @Setter Lombok 代码：
1 | private boolean employed = true; |
等价于 Java 源码：
1 | private boolean employed = true; |
@NonNull Lombok 代码：
1 |
|
等价于 Java 源码：
1 |
|
@ToString Lombok 代码：
1 |
|
等价于 Java 源码：
1 | public class Foo extends Bar { |
@EqualsAndHashCode Lombok 代码：
1 |
|
等价于 Java 源码：
1 | public class Person extends SentientBeing { |
@Data Lombok 代码：
1 |
|
等价于 Java 源码：
1 | public class Company { |
@Cleanup Lombok 代码：
1 | public void testCleanUp() { |
等价于 Java 源码：
1 | public void testCleanUp() { |
@Synchronized Lombok 代码：
1 | private DateFormat format = new SimpleDateFormat("MM-dd-YYYY"); |
等价于 Java 源码：
1 | private final java.lang.Object $lock = new java.lang.Object[0]; |
@SneakyThrows Lombok 代码：
1 |
|
等价于 Java 源码：
1 | public void testSneakyThrows() { |
示例源码：javalib-bean
@Builder在类上标注了 @Data 和 @Builder 注解的时候，编译时，lombok 优化后的 Class 中会没有默认的构造方法。在反序列化的时候，没有默认构造方法就可能会报错。
【示例】使用 @Builder 不当导致 json 反序列化失败
1 |
|
运行时会抛出异常：
1 | Exception in thread "main" com.fasterxml.jackson.databind.exc.MismatchedInputException: Cannot construct instance of `io.github.dunwu.javatech.bean.lombok.BuilderDemo01` (although at least one Creator exists): cannot deserialize from Object value (no delegate- or property-based Creator) |
【示例】使用 @Builder 正确方法
1 |
|
@Data 注解和继承使用 @Data 注解时，则有了 @EqualsAndHashCode 注解，那么就会在此类中存在 equals(Object other) 和 hashCode() 方法，且不会使用父类的属性，这就导致了可能的问题。比如，有多个类有相同的部分属性，把它们定义到父类中，恰好 id（数据库主键）也在父类中，那么就会存在部分对象在比较时，它们并不相等，这是因为：lombok 自动生成的 equals(Object other) 和 hashCode() 方法判定为相等，从而导致和预期不符。
修复此问题的方法很简单：
@Data 时，加上 @EqualsAndHashCode(callSuper=true) 注解。@Getter @Setter @ToString 代替 @Data 并且自定义 equals(Object other) 和 hashCode() 方法。【示例】测试 @Data 和 @EqualsAndHashCode
1 |
|
上面的单元测试可以通过，但如果将 @EqualsAndHashCode(callSuper = true, exclude = { "address", "city", "state", "zip" }) 注掉就会报错。
FreeMarker 是一款模板引擎： 即一种基于模板和要改变的数据， 并用来生成输出文本(HTML 网页，电子邮件，配置文件，源代码等)的通用工具。 它不是面向最终用户的，而是一个 Java 类库，是一款程序员可以嵌入他们所开发产品的组件。
Freemark 模板编写为 FreeMarker Template Language (FTL)。它是简单的，专用的语言， 不是 像 PHP 那样成熟的编程语言。在模板中，你可以专注于如何展现数据， 而在模板之外可以专注于要展示什么数据。
这种方式通常被称为 MVC (模型 视图 控制器) 模式，对于动态网页来说，是一种特别流行的模式。 它帮助从开发人员(Java 程序员)中分离出网页设计师(HTML 设计师)。设计师无需面对模板中的复杂逻辑， 在没有程序员来修改或重新编译代码时，也可以修改页面的样式。
Freemark 模板一句话概括就是：**_模板 + 数据模型 = 输出_**
${ and } 所分隔(或者 #{ and }，这种风格已经不建议再使用了；点击查看更多)。<#-- 和 -->来分隔的。注释会被 FreeMarker 直接忽略， 更不会在输出内容中显示。
🔔 注意：
- FTL 是区分大小写的。
插值仅仅可以在文本中使用。FTL 标签不可以在其他FTL 标签和插值中使用。注释可以放在FTL 标签和插值中。
FTL 指令有两种类型： 预定义指令 和 用户自定义指令。 对于用户自定义的指令使用 @ 来代替 #。
🔔 注意：
- FreeMarker 仅仅关心 FTL 标签的嵌套而不关心 HTML 标签的嵌套。 它只会把 HTML 看做是文本，不会来解释 HTML。
- 如果你尝试使用一个不存在的指令(比如，输错了指令的名称)， FreeMarker 就会拒绝执行模板，同时抛出错误信息。
- FreeMarker 会忽略 FTL 标签中多余的 空白标记。
以下为快速浏览清单，如果需要了解更多细节，请参考这里。
passwords + { "joe": "secret42" }(x * 1.5 + 10) / 2 - y % 100x == y， x != y， x < y， x > y， x >= y， x <= y， x lt y， x lte y， x gt y， x gte y， 等等。。。。。。!registered && (firstVisit || fromEurope)name?upper_case, path?ensure_starts_with('/')repeat("What", 3)=, +=, -=, *=, /=, %=, ++, --注意：变量 仅仅 在 文本区 (比如 <h1>Hello ${name}!</h1>) 和 字符串 中起作用。
正确示例：
1 | < |
错误示例：
1 | <#if ${big}>...</#if> |
Freemark 支持的类型有：
字符串
1 | ${"Hello ${user}"} |
输出：
1 | Hello deister |
数字
布尔值
日期/时间 (日期，时间或日期时间)
FTL 支持的所有转义字符：
| 转义序列 | 含义 |
|---|---|
\" |
引号 (u0022) |
\' |
单引号(又称为撇号) (u0027) |
\{ |
起始花括号：{ |
\\ |
反斜杠 (u005C) |
\n |
换行符 (u000A) |
\r |
回车 (u000D) |
\t |
水平制表符(又称为 tab) (u0009) |
\b |
退格 (u0008) |
\f |
换页 (u000C) |
\l |
小于号：< |
\g |
大于号：> |
\a |
&符：& |
\xCode |
字符的 16 进制 Unicode 码 (UCS 码) |