Traversable 和 Iterable 特质定义了 scala 集合的基本操作，后续文章中将要介绍的 Seq、Set，以及 Map 等集合都实现了这两个特质。本文主要对 Traversable 和 Iterable 中定义的方法进行归类和介绍，了解这些方法也就基本知道了 scala 集合的大部分操作。

Traversable 定义为 Trait 类型，包含 2 个直接派生的子特质 mutable.Traversable 和 immutable.Traversable，分别表示可变集合和不可变集合。其中不可变集合是指集合中的元素一旦初始化完成便不可再被修改，任何对该集合的修改操作都将生成一个新的集合。Traversable 特质的定义如下：

1
2
3
4

trait Traversable[+A] extends TraversableLike[A, Traversable[A]]
                         with GenTraversable[A]
                         with TraversableOnce[A]
                         with GenericTraversableTemplate[A, Traversable]

• 面试官 ：小桂子是吧，看你简历上写着精通 java 编程，想必对 java 已经掌握的很好了吧？
• 小桂子 ：系呀系呀，一直都用 java 写 bug 呢~
• 面试官 ：那你说说 jdk1.7 之前 HashMap 的底层实现原理呗，另外为什么在高并发场景下可能造成较高的 CPU 占用？
• 小桂子 ：这个。。。好像是红黑树？
• 面试官 ：哦？你说的是 jdk1.8 之后的设计，既然你提到了，那就聊聊红黑树这个数据结构吧，这里是白纸和笔，手写一棵吧！
• 小桂子 ：哎呀，哎呀哎呀，老师，突然肚子好疼，我要去一下厕所，一会儿就回来~~~

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 的架构设计做一个综述性的介绍。