David John Wheeler有一句名言“计算机科学中的任何问题都可以通过加上一层间接层来解决”，一层不够就再加一层。后半句是我加的 (*￣︶￣) ，虽然有点玩笑的意思，但是也的确能说明一些问题。计算机科学的确是靠着一层又一层的抽象与封装解决了巨量的问题。
我们来简单回顾一下：
开始的时候是程序员直接输入二进制指令来操纵硬件的，不仅性能低下还很耗费用户时间；
于是后来出现了操作系统，用文件、进程与线程、地址空间抽象了磁盘、CPU与内存，统一和简化了硬件访问方式；
机器语言对用户不友好，于是便出现了汇编语言、中级语言（如C）、高级语言（如Java）的包装，其最终执行还是要转化为机器语言；
裸高级语言大家还用得不爽，觉得开发效率低，于是又出现了各种框架（如Spring、Hibernate）
......
这样一层一层抽象包装下来，我们要想实现一个功能比如定时写文件等已经变成了很简单的事，只需要几行代码就搞定了。
但是抽象层数过多就会导致我们顶层的用户有时候会出现一些莫名其妙的问题，我们用一个实际的案例伪共享来说明一下
我们知道java在运行的时候有两个地方可能用到重排序，一个是编译器编译的的时候，一个是处理器运行的时候。
那么我们就应该问问为啥要用指令重排序呢？
我们从生活中举个例子，假设你有一箱红纸，现在要你剪成小红花贴在窗上。你有两种极端的选择：拿出来一个，把这个剪好，再贴上去......一个一个依次进行；另一种方式是先全部拿出来，然后全部剪好，最后全部贴上去。
那种效率更高？很明显是后者，因为前者你就需要不停地在箱子，剪刀和胶水之间切换，这个切换过程不仅浪费时间，还耗费精力。但是后者一直做一个工作也很无聊，还会导致半天了窗上一朵花都没有，会给你带来失落感，所以比较合适的做法就是拿出来一叠，把这一叠剪好，贴上去。这样既不无聊，也减少了切换次数，提高了工作效率。
再想想，如果有三个人，一个负责拿，一个负责剪，一个负责贴，就更快了。
我之前在一片文章 用Nginx+Redis实现session共享的均衡负载 中做了一个负载均衡的实验，其主要架构如下：
把debian1作为调度服务器承担请求分发的任务，即用户访问的是debian1，然后debain1把请求按照一定的策略发送给应用服务器：debian2或者debain3，甚至更多的debain4、5、6......
状态和数据可以放在外部的分布式缓存服务和分布式数据库服务中，这样应用服务本身就是无状态的，所以机器增减都是很容易的，应用的高可用是有保证的（对于有状态的高可用不仅要注意机器增减与切换、还要注意备份冗余、数据一致性等问题）。但是当时忽略了一个地方，那就是调度服务器debian1本身的高可用性没有考虑到，存在单点问题。
高可用的首要想法就是双机热备，故障时自动切换，所以我们要给debian1加一个备机debain1'。我现在按照自己的知识粗浅的把解决方案分为两类：客户端有感知的高可用、对客户端透明的高可用，并分别挑选一个示例做一下实验。
注：下面实现高可用都用的是双机热备，为了方便，把调度服务器debian1简称为主机，把调度服务器debian1的备机debian1'简称为备机。
基于一致性哈希的分布式内存键值存储——CHKV。
目前的定位就是作为 Cache，DataBase 的功能先不考虑。
set,get,delete,keys,expire几个操作；NameNode 失效则整个系统不可用。
若当成内存数据库使用，则要注意持久化，而且只要有一个 DataNode 失效（未经请求与数据转移就下线了）整个系统就不可对外服务；
若当成内存缓存使用，则 DataNode 失效只是失去了一部分缓存，系统仍然可用。
DataNode 失效（未经请求与数据转移就断开了和 NameNode 的连接）则 NameNode 需要及时通知 Client。
客户 要使用 CHKV 就必须使用 Client 库或者自己依据协议（兼容redis）实现，可以是多种语言的API。
当然也可以把 Client 当做 Proxy，使得 CHKV 内部结构对 客户 透明，亦即有如下两种方式：
后端好书阅读与推荐系列文章：
后端好书阅读与推荐
后端好书阅读与推荐（续）
后端好书阅读与推荐（续二）
后端好书阅读与推荐（续三）
后端好书阅读与推荐（续四）
后端好书阅读与推荐（续五）
Redis设计与实现 (豆瓣): https://book.douban.com/subject/25900156/
通过前面这本书我们已经知道redis怎么用比较好了，现在我们来看看 Redis 的实现原理。这本书是作者自己看着源码写出来的，不得不佩服作者的智慧与毅力。这本书基于redis3.0，此刻redis最新版是4.0.9，我们看书的时候可以自己去看看源码，看看redis有啥变化没，源码在此。