OAuth 2.0 协议是一种三方授权协议，目前大部分的第三方授权场景（例如接入微信第三方登录）均为基于该协议的标准或改进实现。OAuth 1.0 版本于 2007 年发布，2.0 版本则在 2011 年发布，其中 2.0 版本取消了所有 token 的加密过程，并简化了授权流程，但因强制使用 HTTPS 协议，被认为安全性高于之前的版本。

• 项目地址：https://github.com/plotor/oauth4j

SPI (Service Provider Interfaces) 是 JDK 1.5 引入的一种服务扩展内置机制。在面向接口编程的范畴下，SPI 能够基于配置的方式声明应用的具体扩展接口实现。之前在写接口限流器时曾遇到过这样一个场景，针对服务端的限流策略一般需要从多个维度进行控制，比如具体接口、IP、用户、设备，以及调用方等等，假设限流器接口 org.zhenchao.spi.ApiRateLimiter 定义为：

1
2
3

public interface RateLimiter {
    boolean reject();
}

Node.js 这几年火的不要不要的，借助 js 天生的事件驱动机制和 V8 高性能引擎，让编写高并发的 web 应用门槛降低了许多，当然这背后还要得益于 Douglas C. Schmidt 在 1995 年提出的基于事件驱动的 Reactor 模式，让本身只支持单线程执行的 js 能够胜任如今高并发环境下的服务端应用。

不过作为一名服务端开发人员，我对 js 的使用程度并不高，所以也一直没有机会去切身体会 Node.js 的魅力，好在 Reactor 只是一个设计模式，与具体语言和平台无关的。前段时间将负责的项目中的一个比较新的服务引入了 Vert.x 组件进行改造，也算是与 Reactor 模式有了一次亲密接触。Vert.x 是一个被称为运行在 JVM 上的 Node.js，用于在任何层次上编写非阻塞、响应式的模块或服务，关于 Vert.x 的发展历程还多少有些坎坷，具体可以移步官网。

我们通常说缓存、降级，以及限流技术是高并发服务的三大利器，本文我们就来聊聊限流技术中常用的算法。为保证服务的可用性，限流往往是服务端接口的必备特性之一，用于对抗大规模恶意或无效请求，保护有限的计算和存储资源。关于接口限流有很多成熟的算法可供使用，包括：计数器、漏桶，以及令牌桶等，这些算法都为实际项目中的限流器设计提供了理论支撑。

通过前面两篇文章，我们完成了对 MyBatis 所有配置文件（包括配置文件和映射文件）解析过程的分析。回忆一下我们最开始给出的小示例（如下），经过前面的跋山涉水，我们终于完成了第一行代码的 99% （手动滑稽），这最后的 1% 就是创建 SqlSessionFactory 对象。所有的配置解析最后都会封装到 Configuration 对象中，接下去就是调用 SqlSessionFactoryBuilder#build 方法创建 SqlSessionFactory 对象，实际使用的是 DefaultSqlSessionFactory 实现类进行实例化。

上一篇我们分析了配置文件的加载与解析过程，本文将继续对映射文件的加载与解析实现进行分析。MyBatis 的映射文件用于配置 SQL 语句、二级缓存，以及结果集映射等，是区别于其它 ORM 框架的主要特色之一。

在上一篇分析配置文件 <mappers/> 标签的解析实现时，了解到 MyBatis 最终通过调用 XMLMapperBuilder#parse 方法实现对映射文件的解析操作，本文我们将以此方法作为入口，探究 MyBatis 加载和解析映射文件的实现机制。

上一篇我们曾约定 mybatis-config.xml 文件为配置文件，SQL 语句配置文件为映射文件，本文我们将沿用上一篇中的示例程序，一起探究一下 MyBatis 加载和解析配置文件（即 mybatis-config.xml）的过程。

配置文件的加载过程

在示例程序中，执行配置文件（包括后面要介绍的映射文件）加载与解析的过程位于第一行代码中（如下）。其中，Resources 是一个简单的基于类路径或其它位置获取数据流的工具类，借助该工具类可以获取配置文件的 InputStream 流对象，然后将其传递给 SqlSessionFactoryBuilder#build 方法以构造 SqlSessionFactory 对象。

MyBatis 是一个易用、轻量，且强大的半自动化 ORM 框架，在设计思想和代码实现上都有许多值得我们借鉴的地方，例如动态代理机制的应用，资源文件的加载与解析，缓存模块的设计、反射机制的应用，插件模块的设计，架构分层，以及对设计模式的应用等，是一个非常适合初入源码阅读领域的练手项目。本系列文章将从配置文件解析、映射文件解析，以及 SQL 语句执行机制这三个大方向对整个框架的实现展开分析。本文是本系列的第一篇文章，主要从整体的角度对 MyBatis 的架构设计做一个综述性的介绍。

什么？Paxos 号称是最难理解的算法？虽然有些夸张，那也得看一下！

直接入正题，在分布式系统中存在多个主机节点，这些主机之间的通信机制一般分为 共享内存 和 消息传递 两种。这两种方式各有优劣，而 paxos 算法主要用来解决基于消息机制的分布式一致性问题。

在分布式系统中，网络一般被认为是不可靠的，所以传递的消息可能会存在延迟、丢失、重复等问题，发送消息的进程也可能出现运行缓慢、重启，甚至被杀死等情况。Paxos 算法解决的问题是在一个可能发生这些异常（不包括消息可能被篡改的情况）的分布式系统中如何就某个值达成一致，保证不论发生以上任何异常，都不会破坏决策一致性的问题。

Java 多线程类库对于共享数据的读写访问主要采用同步机制来保证线程安全，而本文所要探究的 ThreadLocal 则采用了一种完全不同的策略，它不是用来解决共享数据的并发访问问题的，ThreadLocal 让每个线程都将目标数据复制一份作为线程私有，后续对于该数据的操作都是在各自私有的副本上进行，线程之间彼此相互隔离，也就不存在竞争问题。

下面的例子演示了 ThreadLocal 的典型应用场景。在 jdk 1.8 之前，如果我们希望对日期和时间进行格式化操作，则需要使用 SimpleDateFormat 类，而我们知道它是是线程不安全的，在多线程并发执行时会出现一些奇怪的问题。