大家都知道，Redis之所以性能好，读写快，是因为Redis是一个内存数据库，它的操作都几乎基于内存。但是内存型数据库有一个很大的弊端，就是当数据库进程崩溃或系统重启的时候，如果内存数据不保存的话，里面的数据就会丢失不见了。这样的数据库并不是一个可靠的数据库。

所以数据的持久化是内存型数据库的重中之重。它不仅提供数据保存硬盘的功能，还可以借此用硬盘容量扩展数据存储空间，使得Redis的可以存储超过机器本身内存大小的数据。

Redis对于数据持久化提供了两种持久化的方案，RDB与AOF。它们的原理和使用场景都大不相同，下面我们来详细地了解下。

Redis作为一款高效的内存数据库，可作用于方方面面，相信如今项目的开发都离不开它。大家可能都知道Redis是高可用的，但很少知道具体高可用是利用什么去实现的。

抛两个问题：

1. 只部署一个Redis实例，如果这个实例挂了就无法读写数据了，那怎么做实例备份？
2. 部署了两个Redis，一主一从做复制，从只读，如果主挂了，那这个服务还怎么正常对外服务？

显然，要做到高可用，首先要有足够多的Redis实例（最好三台以上），一主多从。然后再主挂了的时候，要有机制让其他实例替代主的位置。

哨兵服务Sentinel，就是这套题的答案，它是一个检查redis服务下线并补偿的服务。下面我们来完整了解下Sentinel的作用和工作原理，最后实验下它的效果。

互联网发展到现在，由于数据量大、操作并发高等问题，大部分网站项目都采用分布式的架构。而分布式系统最大的特点数据分散，在不同网络节点在某些时刻（数据未同步完，数据丢失），数据会不一致。

在2000年，Eric Brewer教授在PODC的研讨会上提出了一个猜想：一致性、可用性和分区容错性三者无法在分布式系统中被同时满足，并且最多只能满足其中两个！

在2002年，Lynch证明其猜想，上升为定理。被这就是大家所认知的CAP定理。

CAP是所有分布式数据库的设计标准。例如Zookeeper、Redis、HBase等的设计都是基于CAP理论的。

CAP定义

所谓的CAP就是分布式系统的三个特性：

Java的异步编程是一项非常常用的多线程技术。

之前通过源码详细分析了ThreadPoolExecutor《你真的懂ThreadPoolExecutor线程池技术吗？看了源码你会有全新的认识》。通过创建一个ThreadPoolExecutor，往里面丢任务就可以实现多线程异步执行了。

但之前的任务主要倾向于线程池，并没有讲到异步编程方面的内容。本文将通过介绍Executor+Future框架（FutureTask是实现的核心），来深入了解下Java的异步编程。

万事从示例开始，我们先通过示例Demo有一个直观的印象，再深入去了解概念与原理。

使用示例

Demo：

《对象搜索算法与回收算法》介绍了垃圾回收的基础算法，相当于垃圾回收的方法论。接下来就详细看看垃圾回收的具体实现。

上文提到过现代的商用虚拟机的都是采用分代收集的，不同的区域用不同的收集器。常用的7种收集器，其适用的范围如图所示