1.CAP概述

CAP理论是由EricBrewer教授提出的，在设计和部署分布式应用的时候，存在三个核心的系统需求，这个三个需求之间存在一定的特殊关系。三个需求如下：

C: Consistency 一致性

A: Availability 可用性

P:Partition Tolerance分区容错性

CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，最多只能同时较好的满足两个。

2.CAP定义

(1)C: Consistency 一致性

一致性又称为原子性或者事务性。表示一个事务的操作是不可分割的，要不然这个事务完成，要不然这个事务不完成，不会出现这个事务完成了一半这样的情况。这种事务的原子性使得数据具有一致性。

我们通常情况下在数据库中存在的脏数据就属于数据没有具有一致性的表现。而在分布式系统中，经常出现的一个数据不具有一致性的情况是读写数据时缺乏一致性。比如两个节点数据冗余，第一个节点有一个写操作，数据更新以后没有有效的使得第二个节点更新数据，在读取第二个节点的时候就会出现不一致的问题出现。

传统的ACID数据库是很少存在一致性问题的，因为数据的单点原因，数据的存取又具有良好的事务性，不会出现读写的不一致。

任何一个读操作总是能读取到之前完成的写操作结果，也就是在分布式环境中，多点的数据是一致的;

(2)A: Availability 可用性

         好的可用性主要是指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。可用性通常情况下可用性和分布式数据冗余，负载均衡等有着很大的关联。

每一个操作总是能够在确定的时间内返回，也就是系统随时都是可用的。

(3)P:Partition Tolerance分区容错性

         分区容错性和扩展性紧密相关。在分布式应用中，可能因为一些分布式的原因导致系统无法正常运转。好的分区容错性要求能够使应用虽然是一个分布式系统，而看上去却好像是在一个可以运转正常的整体。比如现在的分布式系统中有某一个或者几个机器宕掉了，其他剩下的机器还能够正常运转满足系统需求，这样就具有好的分区容错性。

英文原文：preshing，感谢@浅水清流 的热心翻译。如果其他朋友也有不错的原创或译文，可以尝试推荐给伯乐在线。以下是译文。

——————————————————

无锁哈希表（Lock-Free Hash Table ）可以提高多线程下的性能表现，但是因为实现一个无锁哈希表本身的复杂度不小。（ps：真正的复杂在于出错之后的调试，因为多线程下的调试本身就很复杂，引入无锁数据结构之后，传统的看堆栈信息和打印log都基本上没有意义了。堆栈中的数据可能被并发访问破坏，而打印log本身可能会改变程序执行时对数据访问的时序。一个比较可行的做法是实现一个无锁版本和一个传统数据结构+锁的版本，出错后通过替换来定位是无锁数据结构本身的bug还是其他逻辑的bug）。所以对一个项目而言，无锁数据结构基本上是一把双刃剑。

据我所知，第一个用于实际开发的无锁哈希表是
Dr. Cliff Click 为Java而写。在2007年他发布了这个无锁哈希表的源码并且在google做了关于它的报告（视频）。我承认，在我第一次看这个报告的时候，我对它的大部分内容都不理解。Dr. Cliff Click是这个领域的先驱。(Maged
M. Michael 在IBM做了大量关于无锁数据结构的研究。这个是2002年的一篇论文，关于哈希表，http://www.research.ibm.com/people/m/michael/spaa-2002.pdf)

很幸运，6年时间足够我理解Dr. Cliff Click所做的研究。事实上，你不必做一些前沿的探索，去实现一个完美的无锁哈希表。在这里我将分享我实现的这个版本。我相信有使用C++进行多线程开发经验的程序员，可以通过这篇博客梳理以前的经验，并且完全理解它。

什么是python

Python是一种简单易学，功能强大的编程语言，它有高效率的高层数据结构，能简单而有效地实现面向对象编程。Python简洁的语法和对动态输入的支持，再加上解释性语言的本质，使得它在大多数平台上的很多领域都是一个理想的脚本语言，特别适用于快速的应用程序开发。

Python支持命令式编程、面向对象程序设计、函数式编程、泛型编程多种编程范式。Python具备垃圾自动回收功能，能够自动管理内存使用。Python经常被当作脚本语言用于处理系统管理任务和Web编程

前言

RocksDB是在LevelDB原来的代码上进行改进完善的，所以在用法上与LevelDB非常的相似，其特点在http://blog.csdn.net/tzdjzs/article/details/20838945已在详细说明

从https://github.com/facebook/rocksdb/wiki/Performance-Benchmarks 来看，RocksDB对比LevelDB的性能有大的提高，由于英文水平不行，这里就不翻译英文说明了。

编译

由于家里的笔记本配置低，一旦运行虚拟机就会卡机，因此才会选择cygwin编译

1. 编译环境

从INSTALL.md文件内容来看，编译RocksDB需要使用到C++11的特点，需要gcc4.7以上版本，RocksDB需要压缩表内容，需要第三方库zlib,bzip2,snappy，并且需要一个编译参数处理库：gflags。第三方库的编译过程可以查看文件说明，而cygwin要支持新的gcc,可以使用cygwin的setup.exe来进行安装，这里推荐163的镜像：mirrors.163.com,从那里可以查看怎么添加cygwin源的。本人使用的是gcc4.8

2. 修改源码

由于本身不支持 Windows 平台, 在 Cygwin 里编译的话, 也会报”Unknow platform”错误，但对比leveldb来说，修改源码的地方会相对较多

2.1 修改build_detect_platform文件

把

PLATFORM_CXXFLAGS="-std=c++11" 

改为

PLATFORM_CXXFLAGS="-std=gnu++11" 

好像cygwin不能很好支持c++11参数，后来上网找了一下，可以改为gnu++11

关于LevelDB的资料网上还是比较丰富的，如果你尚未听说过LevelDB，那请稍微预习一下，因为RocksDB实际上是在LevelDB之上做的改进。本文主要侧重在架构上对RocksDB对LevelDB改进的地方做个简单介绍并添加一些个人的看法，更详细的信息读者可参考其官网：http://rocksdb.org/

RocksDB是在LevelDB原来的代码上进行改进完善的，所以在用法上与LevelDB非常的相似。如下，就是简单的把原来Leveldb信息替换为Rocksdb，从继承的角度看，Rocksdb就像是Leveldb的后辈。

RocksDB:

#include "rocksdb/db.h"  

rocksdb::DB* db;  
rocksdb::Options options;  
options.create_if_missing = true;  

rocksdb::Status status = rocksdb::DB::Open(options, "/tmp/testdb", &db);  

assert(status.ok());  

status = db->Get(rocksdb::ReadOptions(), key1, &value);  
status = db->Put(rocksdb::WriteOptions(), key2, value);  
status = db->Delete(rocksdb::WriteOptions(), key1);  

delete db;