前面通过源码分析了服务端启动时做了以下这些事：
客户端启动时做了以下这些事：
但是并没有去研究 Netty 的核心 Reactor 线程模型是什么样的，以及服务端如何接收一个客户端新连接的，现在我们通过跟踪源码来了解一下。
Netty 客户端启动代码基本如下所示，客户端启动时 Netty 内部为我们做了什么？
带着以上几个问题，下面我们来一探究竟。
Netty 服务端启动代码基本如下所示，服务端启动时 Netty 内部为我们做了什么？
带着以上几个问题，下面我们来一探究竟。
众所周知，InnoDB 存储引擎有一个特点：支持事务。简单来说，事务就是一组要么都做，要么都不做的操作。那么在一个事务执行过程中，遇到异常或手动回滚时，怎么撤销刚刚执行的操作？这就要通过本篇文章要说的 undo log 来实现了。
MySQL 数据库对页中数据的修改都是在 Buffer Pool 中进行的，如果一个事务修改了 Buffer Pool 中的一个数据页，但是该数据页尚未刷新回磁盘，此时服务器挂了，Buffer Pool 中的数据修改就会丢失。
那么这个 持久性 怎么保证？MySQL 通过 redo log 来保证基于 Buffer Pool 的数据修改在服务器恢复后不会丢失，也就是会在事务执行期间将对数据库的修改通过 redo log 保存下来，待服务器恢复后通过重放该 redo log 达到数据不丢失的目的。
MySQL 作为最（bu）流（yao）行（qian）的开源数据库，性能高、成本低、可靠性好，其中一部分原因离不开其支持的 MyISAM、InnoDB、Memory 等多种存储引擎。不同的存储引擎管理的表的存储结构可能不同，采用的存取算法也可能不同，本文基于目前 MySQL 默认的存储引擎 InnoDB 对数据的存储及索引进行简单的介绍。
Java 中如果一个变量被声明是 volatile 的，则一个线程对该变量的修改对其它线程是立即可见的。但是并不能保证基于该变量的操作的原子性。
所以 volatile 变量可以看成功能被削的 synchronized，但是与 synchronized 相比，使用 volatile 编码较少，且运行时开销也较少，
因此在 volatile 能满足需求的时候不需要使用 synchronized。
Netty 是一个异步事件驱动的网络应用框架，用于快速开发可维护的高性能服务器和客户端。
使用 Netty 而不使用 Java 原生 NIO 的原因如下：
前面两篇文章介绍了 Zookeeper 的 Watcher 机制以及 Session 机制，下面分别从客户端和服务端两个方面来看下 Zookeeper 是怎么处理的。