1、LRUCache的实现分析

在分析LRUCache前先对LinkedHashMap做些介绍。LinkedHashMap继承于HashMap，它使用了一个双向链表来存储Map中的Entry顺序关系，这种顺序有两种，一种是LRU顺序，一种是插入顺序，这可以由其构造函数public LinkedHashMap(int initialCapacity,float loadFactor, boolean accessOrder)指定。所以，对于get、put、remove等操作，LinkedHashMap除了要做HashMap做的事情，还做些调整Entry顺序链表的工作。
以get操作为例，如果是LRU顺序（accessOrder为true），Entry的recordAccess方法就调整get到的Entry到链表的头部去：

   public V get(Object key) {
        Entry<K,V> e = (Entry<K,V>)getEntry(key);
        if (e == null)
            return null;
        e.recordAccess(this);
        return e.value;
    }

对于put来说，LinkedHashMap重写了addEntry方法：

   void addEntry(int hash, K key, V value, int bucketIndex) {
        createEntry(hash, key, value, bucketIndex);
        // Remove eldest entry if instructed, else grow capacity if appropriate
        Entry<K,V> eldest = header.after;
        if (removeEldestEntry(eldest)) {
            removeEntryForKey(eldest.key);
        } else {
            if (size >= threshold)
                resize(2 * table.length);
        }
    }

addEntry中调用了boolean removeEldestEntry(Map.Entry eldest)方法，默认实现一直返回false，也就是默认的Map是没有容量限制的。LinkedHashMap的子类可以复写该方法，当当前的size大于阈值时返回true，这样LinkedHashMap就可以从Entry顺序链表中删除最旧的Entry。这使得LinkedHashMap具有了Cache的功能，可以存储限量的元素，并具有两种可选的元素淘汰策略（LRU和FIFO），其中的LRU是最常用的。
Solr的LRUCache是基于LinkedHashMap实现的，所以LRUCache的实现真的很简单，这里列出其中核心的代码片断：

    public Object init(final Map args, Object persistence, final CacheRegenerator regenerator) {
	//一堆解析参数参数初始化的代码
	//map map    
    map = new LinkedHashMap(initialSize, 0.75f, true) {
      @Override
      protected boolean removeEldestEntry(final Map.Entry eldest) {
        if (size() > limit) {
          // increment evictions regardless of state.
          // this doesn't need to be synchronized because it will
          // only be called in the context of a higher level synchronized block.
          evictions++;
          stats.evictions.incrementAndGet();
          return true;
        }
        return false;
      }
    };
    if (persistence==null) {
      // must be the first time a cache of this type is being created
      persistence = new CumulativeStats();
    }
    stats = (CumulativeStats)persistence;
    return persistence;
  }
 
    public Object put(final Object key, final Object value) {
    synchronized (map) {
      if (state == State.LIVE) {
        stats.inserts.incrementAndGet();
      }
      // increment local inserts regardless of state???
      // it does make it more consistent with the current size...
      inserts++;
      return map.put(key,value);
    }
  }
 
  public Object get(final Object key) {
    synchronized (map) {
      final Object val = map.get(key);
      if (state == State.LIVE) {
        // only increment lookups and hits if we are live.
        lookups++;
        stats.lookups.incrementAndGet();
        if (val!=null) {
          hits++;
          stats.hits.incrementAndGet();
        }
      }
      return val;
    }
  }

可以看到，LRUCache对读写操作直接加的互斥锁，多线程并发读写时会有锁的竞争问题。通常来说，Cache系统的读要远多于写，不能并发读是有些不够友好。不过，相比于Solr中其它耗时的操作来说，LRUCache的串行化读往往不会成为系统的瓶颈。LRUCache的优点是，直接套用LinkedHashMap，实现简单，缺点是，因为LinkedHashMap的get操作需要操作Entry顺序链表，所以必须对整个操作加锁。

2、FastLRUCache的实现分析

Solr1.4引入FastLRUCache作为另一种可选的实现。FastLRUCache放弃了LinkedHashMap，而是使用现在很多Java Cache实现中使用的ConcurrentHashMap。但ConcurrentHashMap只提供了高性能的并发存取支持，并没有提供对淘汰数据的支持，所以FastLRUCache主要需要做的就是这件事情。FastLRUCache的存取操作都在ConcurrentLRUCache中实现，所以我们直接过渡到ConcurrentLRUCache的实现。
ConcurrentLRUCache的存取操作代码如下：

  public V get(final K key) {
    final CacheEntry<K,V> e = map.get(key);
    if (e == null) {
      if (islive) {
        stats.missCounter.incrementAndGet();
      }
      return null;
    }
    if (islive) {
      e.lastAccessed = stats.accessCounter.incrementAndGet();
    }
    return e.value;
  }
 
  public V remove(final K key) {
    final CacheEntry<K,V> cacheEntry = map.remove(key);
    if (cacheEntry != null) {
      stats.size.decrementAndGet();
      return cacheEntry.value;
    }
    return null;
  }
 
  public Object put(final K key, final V val) {
    if (val == null) {
      return null;
    }
    final CacheEntry e = new CacheEntry(key, val, stats.accessCounter.incrementAndGet());
    final CacheEntry oldCacheEntry = map.put(key, e);
    int currentSize;
    if (oldCacheEntry == null) {
      currentSize = stats.size.incrementAndGet();
    } else {
      currentSize = stats.size.get();
    }
    if (islive) {
      stats.putCounter.incrementAndGet();
    } else {
      stats.nonLivePutCounter.incrementAndGet();
    }
 
    // Check if we need to clear out old entries from the cache.
    // isCleaning variable is checked instead of markAndSweepLock.isLocked()
    // for performance because every put invokation will check until
    // the size is back to an acceptable level.
    // There is a race between the check and the call to markAndSweep, but
    // it's unimportant because markAndSweep actually aquires the lock or returns if it can't.
    // Thread safety note: isCleaning read is piggybacked (comes after) other volatile reads
    // in this method.
    if (currentSize > upperWaterMark && !isCleaning) {
      if (newThreadForCleanup) {
        new Thread() {
          @Override
          public void run() {
            markAndSweep();
          }
        }.start();
      } else if (cleanupThread != null){
        cleanupThread.wakeThread();
      } else {
        markAndSweep();
      }
    }
    return oldCacheEntry == null ? null : oldCacheEntry.value;
  }

所有的操作都是直接调用map（ConcurrentHashMap）的。看下put中的代码，当map容量达到上限并且没有其他线程在清理数据（currentSize > upperWaterMark && !isCleaning），就调用markAndSweep方法清理数据，可以有3种方式做清理工作：1）在该线程同步执行，2）即时启动新线程异步执行，3）提供单独的清理线程，即时唤醒它异步执行。

markAndSweep方法那是相当的冗长，这里就不罗列出来。下面叙述下它的思路。

对于ConcurrentLRUCache中的每一个元素CacheEntry，它有个属性lastAccessed，表示最后访问的数值大小。ConcurrentLRUCache中的stats.accessCounter是全局的自增整数，当put或get Entry时，Entry的lastAccessed会被更新成新自增得到的accessCounter。 ConcurrentLRUCache淘汰数据就是淘汰那些lastAccessed较小的Entry。因为ConcurrentLRUCache没有维护以lastAccessed排序的Entry链表（否则就是LRUCache了），所以淘汰数据时就需要遍历整个Map中的元素来淘汰合适的Entry。这是不是要扯上排序呢？其实不用那么大动干戈。

这里定义几个变量，wantToKeep表示Map中需要保留的Entry个数，wantToRemove表示需要删除的个数（wantToRemove=map.size-wantToKeep),newestEntry是最大的lastAccessed值（初始是stats.accessCounter），这三个变量初始都是已知的，oldestEntry表示最小的lastAccessed，这个是未知的，可以在遍历Entry时通过比较递进到最小。Map中的Entry有3种:(a)是可以立刻判断出可以被淘汰的，也就是lastAccessed<(oldestEntry+wantToRemove)的，（b）是可以立刻判断出可以被保留的，也就是lastAccessed>(newestEntry-1000)的，（c）除上述两者之外的就是不能准确判断是否需要被淘汰的。对于遍历一趟Map中的Entry来说，极好的情况是如果淘汰掉满足（a）的Entry后Map大小降到了wantToKeep，这种情况的典型代表是对Cache只有get和put操作，使得lastAccessed在Map中能保持连续；极坏的情况是，可能满足（a）的Entry不够多甚至没有。但遍历一趟Map至少有一个效果是，会把需要处理的Entry范围缩小到满足（c）的。如此反复迭代，一定使得Map容量调到wantToKeep。而对这个淘汰，也要考虑一个现实情况是，wantToKeep往往是接近于map.size（比如等于0.9*map.size）的，如果remove操作不是很多，那么并不需要很多次遍历就可以完成清理工作。

ConcurrentLRUCache淘汰数据的基本思想如上所述。它的执行过程可以分为3个阶段。第一个阶段就是遍历Map中的每个Entry，如果满足（a）就remove，满足（b）则跳过，满足（c）则放到新map中。一遍下来后，如果map.size还大于wantToKeep，第二个阶段就再重复上述过程（实现上，Solr用了个变量numPasses，似乎想做个开关控制遍历几次，当前就固定成一次）。完了如果map.size还大于wantToKeep，第三阶段再遍历一遍Map，但这次使用PriorityQueue来提取出还需要再淘汰的N个最old的Entry，这样一次下来就收工了。需要补充一点，上面提到的wantToKeep在代码中是acceptableWaterMark和lowerWaterMark，也就是如果遍历后达到acceptableWaterMark就算完成，但操作是按lowerWaterMark的要求来。

这个算法的时间复杂度是2n+kln(k)（k值在实际大多数情况下会很小），相比于直接的堆排，通常会更快些。

3、总结

LRUCache和FastLRUCache两种Cache实现是两种很不同的思路。两者的相同点是，都使用了现成的Map来维护数据。不同点是如何来淘汰数据。LRUCache（也就是LinkedHashMap）格外维护了一个结构，在做存取操作时同时更新该结构，优点在于淘汰操作是O(1)的，缺点是需要对存取操作加互斥锁。FastLRUCache正相反，它没有额外维护新的结构，可以由ConcurrentHashMap支持并发读，但put操作中如果需要淘汰数据，淘汰过程是O(n)的，因为整个过程不加锁，这也只会影响该次put的性能，而FastLRUCache也可选成起独立线程异步执行来降低影响。而另一个Cache实现Ehcache，它在淘汰数据就是同步的，不过它限定了每次淘汰数据的大小（通常都少于5个），所以同步情况下性能不会太受影响。

1、master的工作

对于ReplicationHandler的复制功能来说，核心的问题确定是在一个时间点要复制哪些文件，这就用上了lucene的IndexDeletionPolicy的特性。lucene在初始化时，会调用IndexDeletionPolicy.onInit(List<? extends IndexCommit> commits)方法；lucene在commit（触发的时机也可以是optimize、close，solr在commit时实际上就是close了indexwriter）时，会调用IndexDeletionPolicy.onCommit(List<? extends IndexCommit> commits)。IndexCommit对象中保存了该次提交关联的文件列表等信息，这使得solr中的复制过程中，slave可以从master得到文件列表后跟本地文件做比较，跳过不变的文件，下载新文件，并删除无用的文件。IndexDeletionPolicy的两个针对commits的函数，会对当前存在的commits列表做些处理，比如lucene默认的KeepOnlyLastCommitDeletionPolicy会只保留最新的IndexCommit，对那些过时的IndexCommit执行delete操作以将无用的文件删掉。solr中，SolrDeletionPolicy默认也是保留最新一个IndexCommit，但可以设置maxCommitAge、maxCommitsToKeep、maxOptimizedCommitsToKeep来保留更多的IndexCommit。但solr真正使用的IndexDeletionPolicy实现是IndexDeletionPolicyWrapper，它是SolrDeletionPolicy的wrap。在slave从master复制文件的过程中，要保证当前正在复制的IndexCommit点不能被删除，这就用到了IndexDeletionPolicyWrapper中的void setReserveDuration(Long indexVersion, long reserveTime)方法，该方法会在master向slave响应indexversion、filelist命令前、以及每向slave传送5M的索引文件内容时调用，而默认的reserveTime时间是10s，如果慢速网络传输5M数据需要10秒以上，就需要调整该值了。

ReplicationHandler复制文件没有采用rsync，而是使用http，它在读一个文件内容传输到slave时，默认是按照1M大小分段输出内容到slave（http chunked？），并且默认是对每段内容做了checksum，保证传输的内容的正确性。上面提到的setReserveDuration点，主要就是它在packetsWritten % 5 == 0次数后触发一次修改。

ReplicationHandler还可以备份索引文件。由于lucene的索引文件只是追加新文件而不会修改已有文件，所以只要针对一个IndexCommit点做备份，其过程还是很简单的。

2、slave的工作

slave启动时会创建SnapPuller对象，SnapPuller会启动一个线程定时的（pollInterval间隔）从master复制数据（fetchLatestIndex方法）。对于一次复制过程，slave和master交互处理细节如下：
1、slave首先向master询问最新的索引版本号（indexversion命令），slave检查得到的latestVersion、latestGeneration有效后，和本地的IndexCommit的getVersion()、getGeneration()比较，如果不相等，则需要往下进行，否则等待下一次调度。

2、slave向master请求之前得到的indexversion下的文件列表（filelist命令，包括索引文件和可选的配置文件）。如果文件列表为空，则返回等待下一次调度。否则，就需要检查哪些文件需要被下载过来。这里做的判断有：1）如果本地的commit.getGeneration() >= latestGeneration，说明本地索引文件被破坏（比如对slave不小心提交了修改索引的命令），需要完全将master的文件复制过来。2）逐个检查文件列表中的文件是否在本地存在，不存在就下载下来。

3、对于下载文件内容，对应命令是filecontent。下载的文件显然需要放到临时目录中，这个临时目录和已有的索引目录（默认名字index）在同一数据目录下，只是命名为index.<时间戳>。下载完毕后，copy数据有两种情况：1）如果是完全下载，则不需要将临时目录中的文件copy到已有目录中，而是修改数据目录中的index.properties，标识索引目录为新生成的临时目录，而旧索引目录并不会被删除，可以手工删掉，当然，通常是不应该出现slave的Generation大于master的异常情况。2）通常就是把临时索引目录的文件copy到旧索引目录，copy时要把segments_N放到最后copy，避免copy中途出现异常造成数据被毁。

4、当新索引和可选的配置文件copy完毕之后，slave会对solrcore的UpdateHandler做commit操作，这会close掉indexwriter并强制重启新的indexsearcher提供服务。同时，如果solrcore的UpdateHandler是DirectUpdateHandler2（不应该不是），会强制调用handler.forceOpenWriter()来删除旧的无用的索引文件，并调用replicationHandler.refreshCommitpoint()来更新slave的indexCommitPoint。

5、如果索引复制失败，slave会向数据目录下的replication.properties输出复制失败的信息。

还是说下DocIDMapperImpl的作用吧。在zoie中，uid和lucene的docid有一一对应关系。从docid到uid的映射很简单，就是分配个maxdoc大小的数组，索引位置是docid，值是uid。这样做也是因为docid是从小到大自增的，大小总有限。但uid是long型的，使用数组反映射是不行了，一个直接的选择是使用hashmap。不过zoie为了节约空间，使用了更有效的算法，也就是下面的类，这个算法有些像是bloom filter算法的变种应用。

 
package proj.zoie.api.impl;
 
import java.util.Arrays;
import java.util.HashMap;
 
import proj.zoie.api.DocIDMapper;
import proj.zoie.api.ZoieIndexReader;
 
/**
 * @author ymatsuda
 * 
 */
 
public class DocIDMapperImpl implements DocIDMapper {
 
	private final int[] _docArray;
	private final long[] _uidArray;
	private final int[] _start;
	private final long[] _filter;
	private final int _mask;
	private final int MIXER = 2147482951; // a prime number
 
	/**
	 * 
	 * @param uidArray uidArray的大小是索引的maxdoc，所以数组的每个索引位置
	 * 表示docid，值表示uid，如果docid被删除，
	 * 其索引位置的值为ZoieIndexReader.DELETED_UID
	 */
	public DocIDMapperImpl(long[] uidArray) {
		int len = uidArray.length;
		int mask = len / 4;
		mask |= (mask >> 1);
		mask |= (mask >> 2);
		mask |= (mask >> 4);
		mask |= (mask >> 8);
		mask |= (mask >> 16);
		_mask = mask;
	//上面的操作，首先是取mask为len的1/4,之后做了联合的右移及或操作，
	//使得mask最高有效位右边的位值都变为1,也就是说，假如mask开始等于0x10110000，
	//操作后变成0x11111111，这才能mask可以和下面的h做与操作定位到_filter数组中
	//的某个索引位置。也可以看到，mask的大小介于len的1/4到1/2。
		_filter = new long[mask + 1];
 
		for (long uid : uidArray) {
			if (uid != ZoieIndexReader.DELETED_UID) {
				int h = (int) ((uid >>> 32) ^ uid) * MIXER;
	//这个hash值算法目的是将uid能散到int的整个数值范围内，并降低h之间的冲突，
	//所以计算后得到的h会比较大。
				long bits = _filter[h & _mask];
				bits |= ((1L << (h >>> 26)));
				bits |= ((1L << ((h >> 20) & 0x3F)));
				_filter[h & _mask] = bits;
	//(h >>> 26)得到的是h高位的前5位，再经过1L << 后，其取值范围就是0-31;
	//(1L << ((h >> 20) & 0x3F))取值范围是0-63。
	//这两个或操作正好取了bits的位数范围中的两位。
	//bits的两个或操作，相当于bloom filter中两次hash取位。
	//对于bloom filter算法，判定key是否存在是有误判的可能性，这里也不意外。
	//因为bits有64位，而每个uid取两位，mask最坏是len的1/2，在hash散均的情况下，
	//这个_filter每个桶(索引位置）冲突率不会很大。
			}
		}
 
		_start = new int[_mask + 1 + 1];
		len = 0;
		for (long uid : uidArray) {
			if (uid != ZoieIndexReader.DELETED_UID) {
				_start[((int) ((uid >>> 32) ^ uid) * MIXER) & _mask]++;
				len++;
			}
		}
		int val = 0;
		for (int i = 0; i < _start.length; i++) {
			val += _start[i];
			_start[i] = val;
		}
		_start[_mask] = len;
//_start经过了两个循环处理，第一个循环计算出_start每个桶中保存了多少个uid，
//并计算出有效的uid个数len。第二个循环是为下面的操作做准备，它使得_start中每个桶
//保存的是从第0个桶到当前桶有多少有效的uid。
 
		long[] partitionedUidArray = new long[len];
		int[] docArray = new int[len];
 
		for (long uid : uidArray) {
			if (uid != ZoieIndexReader.DELETED_UID) {
				int i = --(_start[((int) ((uid >>> 32) ^ uid) * MIXER) & _mask]);
				partitionedUidArray[i] = uid;
			}
		}
		int s = _start[0];
		for (int i = 1; i < _start.length; i++) {
			int e = _start[i];
			if (s < e) {
				Arrays.sort(partitionedUidArray, s, e);
			}
			s = e;
		}
	//这两个循环来填充partitionedUidArray数组，并调整_start保存的计数，
	//这个计数就是partitionedUidArray数组的索引位置的偏小临近值。
	//注意对_start的--操作和s < e的判断，这是处理一个桶里存在多个uid的情况，
	//以保证partitionedUidArray中uid的顺序，也使得_start相邻两个桶的计数会有差值。
	//所以当可以利用二分查找来搜索_uidArray和_docArray。
		for (int docid = 0; docid < uidArray.length; docid++) {
			long uid = uidArray[docid];
			if (uid != ZoieIndexReader.DELETED_UID) {
				final int p = ((int) ((uid >>> 32) ^ uid) * MIXER) & _mask;
				int idx = findIndex(partitionedUidArray, uid, _start[p],
						_start[p + 1]);
				if (idx >= 0) {
					docArray[idx] = docid;
				}
			}
		}
		//填充docArray
		_uidArray = partitionedUidArray;
		_docArray = docArray;
	}
 
	/**
	 * @see 分析出构造函数后，这个函数就比较好理解了。这里就不细说了。
	 */
	public int getDocID(final long uid) {
		final int h = (int) ((uid >>> 32) ^ uid) * MIXER;
		final int p = h & _mask;
 
		// check the filter
		final long bits = _filter[p];
		if ((bits & (1L << (h >>> 26))) == 0
				|| (bits & (1L << ((h >> 20) & 0x3F))) == 0)
			return -1;
 
		// do binary search in the partition
		int begin = _start[p];
		int end = _start[p + 1] - 1;
		// we have some uids in this partition, so we assume (begin <= end)
		while (true) {
			int mid = (begin + end) >>> 1;
			long midval = _uidArray[mid];
 
			if (midval == uid)
				return _docArray[mid];
			if (mid == end)
				return -1;
 
			if (midval < uid)
				begin = mid + 1;
			else
				end = mid;
		}
	}
 
	/**
	 * @see 在arr的一个区间内二分查找uid所在的索引位置。
	 * @param arr
	 * @param uid
	 * @param begin
	 * @param end
	 * @return
	 */
	private static final int findIndex(final long[] arr, final long uid,
			int begin, int end) {
		if (begin >= end)
			return -1;
		end--;
 
		while (true) {
			int mid = (begin + end) >>> 1;
			long midval = arr[mid];
			if (midval == uid)
				return mid;
			if (mid == end)
				return -1;
 
			if (midval < uid)
				begin = mid + 1;
			else
				end = mid;
		}
	}
}

就时间复杂度来说，DocIDMapperImpl和hashmap相当（在hash均匀情况下，那个二分查找次数通常不会很多）。就空间复杂度来说，DocIDMapperImpl中的_uidArray和_docArray相当于hashmap中项的kye和value集合。DocIDMapperImpl中还有的是_start和_filter，而hashmap中每个项还有hash值和项冲突时的next引用以及需要大于负载因子的额外空间。在mask等于1/2 len的最坏情况下，DocIDMapperImpl也是要优于hashmap的。

/**
* 这个wrapper类提供auto_ptr以引用语义，在下面的操作中有介绍。
*/

template<typename _Tp1>
struct auto_ptr_ref {
	_Tp1* _M_ptr;
	explicit auto_ptr_ref(_Tp1* __p) :
		_M_ptr(__p) {
	}
};

template<typename _Tp>
class auto_ptr {
private:
	_Tp* _M_ptr;//
 
public:
	/// The pointed-to type.
	typedef _Tp element_type;

/**
* 构造函数，将auto_ptr绑定到指针__p。
* __p是一个指向new出来的对象的指针，默认为0（NULL）是说auto_ptr的构造函数可以不传参构造，
* 这时成员_M_ptr=0，如果接着解引用auto_ptr对象，将Segmentation fault。当然，通常应用auto_ptr的构造
* 函数会传参的。auto_ptr提供了get函数来判断_M_ptr是否为空、reset函数重置_M_ptr指针。
* 在继承情况下，_M_ptr可以是__p的基类型。
* 构造函数声明为explicit表示禁止参数的自动类型转换（因为它们总是邪恶的）。
*
*/

	explicit auto_ptr(element_type* __p = 0) throw () :
		_M_ptr(__p) {
	}

/**
* 辅助函数
*/

	element_type*	release() throw () {
		element_type* __tmp = _M_ptr;
		_M_ptr = 0;
		return __tmp;
	}

/**
* auto_ptr的复制构造函数是很邪恶的，它的逻辑是将参数__a中的指针挪给新对象的，
* 原来的__a的内置指针被置空，接下来就不能继续操作__a引用的对象，否则就掉进出错的陷阱。
* 另外，复制构造函数的参数不是个const，因为它需要修改参数内容的。
*/

			auto_ptr(auto_ptr& __a) throw () :
		_M_ptr(__a.release()) {
	}

/**
* 成员函数模板。好吧，我承认，我对模板也是半知半解（注意，不是一知半解）。这个函数
* 用于将继承体系中的子类型上溯成基类型。举个例子：
* 假如User是基类，Admin是派生类，那么下面的操作是ok的。
* auto_ptr<Admin> ptr2(new Admin());
* auto_ptr<User> ptr3(ptr2);
* 编译器的原理类型识别和转换的大致过程是：当模板参数类型不匹配时（_Tp1转成_Tp），
* 编译首先检查是否存在合适的类型转换操作符（auto_ptr是没有的），如果没有则检查是否
* 存在合适的成员函数模板完成类型转换。在_Tp1是_Tp的派生类的情况下，这种转换就会成功。
* 这也是说，编译器检查的是模板参数类型而不是对象的实际类型，所以，下面的例子编译就会失败：
* auto_ptr<User> ptr2(new Admin());
* auto_ptr<Admin> ptr3(ptr2);
*/

	template<typename _Tp1>	auto_ptr(auto_ptr<_Tp1>& __a) throw () :
		_M_ptr(__a.release()) {
	}

/**
* @brief 重置管理的对象指针，如果_M_ptr不为空，会delete掉。如果重置的指针就是本身
* 的_M_ptr，就是个空操作。
* @param __p 对象指针.
*/

	void reset(element_type* __p = 0) throw () {
		if (__p != _M_ptr) {
			delete _M_ptr;
			_M_ptr = __p;
		}
	}

/**
* 赋值操作符，和复制构造函数一样是邪恶的，赋值操作会delete掉右值管理的对象指针。
* 如果auto_ptr对象作为函数参数传递，并且是传值，那么这个调用过程会涉及到赋值操作符
* 的调用，产生并不期待的delete外部对象的结果。
*/

		auto_ptr& operator=(auto_ptr& __a) throw () {
		reset(__a.release());
		return *this;
	}

/**
* 成员函数模板赋值操作符
*/

	template<typename _Tp1>	auto_ptr& operator=(auto_ptr<_Tp1>& __a) throw () {
		reset(__a.release());
		return *this;
	}

/**
* 析构函数，操作很明显，因为是delete，所以auto_ptr是不支持数组指针的，否则会有
* 内存泄露。
*/

	~auto_ptr() {
		delete _M_ptr;
	}

/**
* 解引用操作符
*/

		element_type& operator*() const throw () {
		_GLIBCXX_DEBUG_ASSERT(_M_ptr != 0);
		return *_M_ptr;
	}

/**
* ->操作符，是auto_ptr被用得最多的调用吧。
*/

				element_type* operator->() const throw () {
		_GLIBCXX_DEBUG_ASSERT(_M_ptr != 0);
		return _M_ptr;
	}

/**
* 返回auto_ptr管理的指针，这通常用于判断指针是否为空的情况，所以，如果要判断
* auto_ptr管理的指针是否为空，不要使用if(auto_ptr_obj){}而是使用get函数(实际上，
* 因为auto_ptr并没用定义指向element_type的dumb指针的隐式类型转换操作符，所以根本
* 编译不过if(auto_ptr_obj))。
* 但是，auto_ptr并没有禁止你进一步操作你得到的指针，甚至delete它使
* auto_ptr对象内置的指针悬空。
*/

	element_type* get() const throw () {
		return _M_ptr;
	}

/**
* 下面的三个函数连带auto_ptr_ref是auto_ptr中的神奇之笔，因为我拍了好多次脑袋才想明白
* 是怎么的应用原理。考虑两种使用情况：
* 1）void foo(auto_ptr< User> ptr);
* 2）auto_ptr< User> func_returning_auto_ptr(…..);
* auto_ptr ptr< User> = func_returning_auto_ptr(…..);
* 对于第一种情况，当调用方式是：foo(auto_ptr< User>(new User));时，因为是传值调用，
* 而实参是个临时对象，所以需要做赋值构造对象，但auto_ptr的赋值构造函数参数并不是const的
* 所以不匹配其复制构造函数。auto_ptr采用了曲线策略，编译器接着检查类型转换操作符，
* 发现operator auto_ptr_ref<_Tp1>()是匹配的，所以将临时对象转成auto_ptr_ref，再调用
* auto_ptr(auto_ptr_ref __ref)把auto_ptr_ref转成auto_ptr。
*/

	auto_ptr(auto_ptr_ref<element_type> __ref) throw () :
		_M_ptr(__ref._M_ptr) {
	}
 
	template<typename _Tp1>	operator auto_ptr_ref<_Tp1>() throw () {
		return auto_ptr_ref<_Tp1> (this->release());
	}

/**
* 和auto_ptr(auto_ptr_ref __ref)相似
*/

		auto_ptr& operator=(auto_ptr_ref<element_type> __ref) throw () {
		if (__ref._M_ptr != this->get()) {
			delete _M_ptr;
			_M_ptr = __ref._M_ptr;
		}
		return *this;
	}

/**
* 怎么说这个函数呢？我还不晓得这个转换操作符在什么时候调用呢？
*/

			template<typename _Tp1>	operator auto_ptr<_Tp1>() throw () {
		return auto_ptr<_Tp1> (this->release());
	}
};

//auto_ptr是不支持void类型的模板特化。

template<> class auto_ptr<void> {
public:
	typedef void element_type;
};

Beansdb是豆瓣荣誉出品的分布式key-value存储系统，该系统是对经典的Dynamo的简化。项目地址：http://code.google.com/p/beansdb/，其上的Inside BeansDB.pdf文档是对beansdb的很好的介绍。

Beansdb的CAP特点表现为：

1）分布式的，伸缩性比较好（P）

2）最终一致的(C)，可能出现短时间内的数据不一致。

3）高可用的(A)，部分节点出现故障不影响服务。

Beansdb在豆瓣内部有着广泛的使用，比如图片文件、小媒体文件、profile、properties等等。Beansdb不像GFS等分布式存储系统，一般不用于存储百兆以上单位的大数据。

2、Beansdb功能组成

Beansdb代码由两部分组成：1）c代码实现的服务器端程序，2）一些python脚本实现的程序。

我当前分析的版本是0.3，下面分别介绍其功能。

2.1服务器端程序

服务器端程序实现的功能如下：

1、基于tokyo cabinet实现key-value存储功能。为了提高性能，在存储数据时，Beansdb先将数据快速的存储到tcmdb（内存db）中，由独立线程异步的将tcmdb中的数据更新到tchdb中。可见，在非正常情况下，Beansdb是有可能丢失数据的，这种情况就需要对等节点同步数据来修复。

2、为了解决对等系统中的提交的一致性问题，Beansdb采用版本号+修改的时间戳来标识数据。提交的策略是：高版本号覆盖低版本号，新数据覆盖旧数据。

3、Beansdb使用hashtree来diff两个数据节点的数据一致性。Hashtree中保存的hash数据会固化到磁盘上，同时为了提高性能，在内存中会完整的构造hashtree结构，hashtree的更新也是由独立线程异步更新（在新的查询或者提交前会再次尝试更新hashtree，保证hashtree的实时性，如果hashtree已是valid，这个操作相当于空操作）。

4、Beansdb对外提供兼容memcached协议的接口。Beansdb额外提供了两个命令：get @xxx用来返回hastree的状态，get ?xxxx用来返回对应key的meta信息，这两个命令辅助不同节点间hashtree的diff及数据同步。

小结：Beansdb的服务器端程序并没有像cassandra等提供一套集数据存储、数据复制、数据校验、对等节点管理等分布式功能，它只是实现一个单机key-value存储server和hashtree。从选择方面来说，如果使用如tokyo tyrant等现成的key-value存储server，beansdb也不必自己再使用memcached+tc造遍轮子。而服务器端的hashtree只提供了存储，对等节点的diff需要由外部脚本完成。

2.2 Python脚本程序

相比于c的服务器端程序，Beansdb的几个python脚本程序看起来有些不够工业化。下面简要的说明一下核心的python脚本提供的功能。

2.2.1 proxy.py

Proxy.py这个代理程序使得beansdb具有了分布式特点，不过这个脚本还是太朴素了些，它提供的功能如下：

1、客户端程序的请求都走到Proxy.py，由Proxy.py将请求分发到相应的存储服务器程序。不像Dynamo中的复杂的分布式一致性hash策略，proxy.py按照trunk手动分配数据的分布。比如，在桶数16时，DB = {“A:7900″:range(8), “B:7900”:range(8,16), “B:7900”:range(16)….}的配置使得，节点A的数据分布在桶0-7，节点B的数据分布在桶8-15，节点C的数据分布在桶0-15。和分布式一致性hash对比，这相当于虚拟节点个数是16，而每个虚拟节点对应的物理存储节点是已知不变的。Proxy.py将请求的key取hash后模桶数，以得到该桶中对应的节点列表。这样做的好处是：不像分布式一致性hash那样，数据的分布情况不是透明的，不能够手动迁移数据。缺点是：这种手动策略不适合大型的分布式集群，添加删除机器需要人工干预。

2、Proxy.py当前提供的NWR是N=3, R=1, W=1。读时只要从一个节点读到数据就返回，写时只要写到一个节点就表示写成功。这种策略虽然有些粗暴，不过也是最实时高效的，对于准确性要求不高的应用场景来说，也是可以接受的。

2.2.1 sync.py

sync.py脚本定时比较位于一个桶中的各存储节点的hashtree的hash是否相同。这个比较是从hashtree的根节点开始的，如果根节点相同就不需要继续比较，否则递归向下比较到hash值不同的叶子节点，diff出value不同时，由高版本节点数据覆盖低版本的节点数据。

3、服务器端程序分析

3.1 key-value存储分析

Beansdb基于tokyo cabinet的tcmdb和tchdb实现存储功能。实现代码位于hstore.h/hstroe.c文件。实现策略及特点如下：

1、存储的value数据除了提交的真实数据，还在数据后附加了Meta信息，Meta信息用于提交时的冲突解决。Meta信息结构如下：

typedef struct t_meta {
 
int32_t  version;//版本号
 
uint32_t hash;//value的hash值
 
uint32_t flag;//memcached协议中的flag字段
 
time_t   modified;//最后修改时间
 
} Meta;

2、存储的核心结构式hstore，定义如下：

struct t_hstore {
    int height;//
    int start;
    int end;
    bool stop_scan;
    bool *scanning;
    TCHDB **db;
    HTree **tree;
    pthread_mutex_t *mutex;
    TCMDB **cache;
};

涉及的操作函数如下：

HStore* hs_open(char *path, int height, int start, int end)

默认的情况下，参数height=1,start=0,end=-1，这使得创建的store->height=1, store->start =0, store->end =16；也就是说，默认会创建16个hdb文件及对应的db、htree和cache结构，这样做可以减少读写的锁冲突，也方便htree比较等。

char *hs_get(HStore *store, char *key, int *vlen, uint32_t *flag)

读数据。读请求有3种：

1）@请求读hashtree的状态信息。@请求有两种，一种是读16个桶文件各自总的状态信息，一种是读单个桶的所有的key的状态信息。图示如下：

这个图是命令“get @”，图中的0-f列表示16个db桶，每行的第二列表示总的hash，第三列表示item个数。第一行key @对应的是flag（0）和value的长度（132）。

再看下张图：

命令是“get @e”，表示查看桶e的信息，每行的列含义分别是key、hash、version。

2）?请求读key对应的value的Meta信息。

3）普通的读。普通的读的过程是：先计算出key对应到哪个桶中，然后读tcmdb，不存在时再读tchdb，得到的结果包含Meta信息。

bool hs_set(HStore *store, char *key, char* value, int vlen, int ver, uint32_t flag)

set数据的过程是：

1）计算出key在store中的桶index。

2）从index所在的hashtree中查找是否已有该key的item数据old_ver、old_hash。

3）计算value的hash，如果hash值等于old_hash，从tcmdb或者tchdb中查找该key对应的oldv，如果和value相同，表示数据没有变化。

4）如果数据有变化，存储数据到tcmdb中，格式是：value+ Meta。

5）调用ht_add来更新hashtree。

bool hs_delete(HStore *store, char *key)

删除数据的过程是：

1）计算出key在store中的桶index。

2）调用ht_remove删除hashtree中所在的data。

3）删除tcmdb和tchdb中的数据。

3.2 hashtree实现分析

Beansdb使用hashtree来校验不同数据，分析如下：

1、实现上，hashtree类似于heap结构，用到了两个大数组，一个存储hashtree的节点结构，一个存储hashtree中叶子节点的data数据。叶子节点的数据序列化后存储在tchdb中（文件名是.[number].index）。

2、Hashtree的每个非叶子节点有16个子节点，每个叶子节点最多存储128个data数据项。当叶子节点存储的data数据项超过128时，就会将叶子节点分化成非叶子节点并调整树结构。

3、下面给出核心的几个数据结构：

typedef struct t_item Item;
 
struct t_item {
 
uint32_t keyhash;
 
uint32_t hash;//value hash
 
short    ver;//版本号
 
unsigned char length;//item总长度
 
char     name[1];//key，name是变长的，= sizeof(Item) + n。
 
};
 
typedef struct t_data Data;
 
struct t_data {
 
int size;//整个结构的总大小
 
int count;//item个数
 
Item head[0];//item列表，由count及item结构中length可遍历得到列表数据
 
};
 
typedef struct t_node Node;
 
struct t_node {
 
uint16_t is_node:1;
 
uint16_t valid:1;
 
uint16_t modified:1;
 
uint16_t depth:4;//节点所在的深度，根是0，叶子是tree->height-1
 
uint16_t flag:9;
 
uint16_t hash;//所有子节点的hash总和
 
uint32_t count;//所有子节点的count和，如果是叶子节点，则为data->count
 
};
 
struct t_hash_tree {
 
int depth;//就是hstore的height，默认是1
 
int height;//高度，由节点数可得到，随着节点数的增加而增加
 
TCHDB *db;
 
Node *root;
 
Data **data;
 
int pool_size;
 
pthread_mutex_t lock;
 
char keybuf[30];
 
char buf[512];
 
};

4、对于hashtree在tchdb中存储的data，key是节点在Node大数组中的位置，value是序列化的Data结构数据。

5、hashtree中存在全局数组：static const int g_index[] = {0, 1, 17, 289, 4913, 83521, 1419857, 24137569, 410338673};。可以看到，g_index中的每个值表示hashtree中相应depth（起始是0，也就是数组的索引）下的最小节点位置。也可以看到，beansdb可以存储的项数是在整数范围内。在hashtree中，经常会用到下面3个定位函数：

inline uint32_t get_pos(HTree *tree, Node *node)

得到node相对于同一depth下的第一个节点的偏移位置。

inline Node *get_child(HTree *tree, Node *node, int b)

得到node节点的第i个子节点。

#define INDEX(it) (0x0f & ((it)->keyhash >> ((7 - node->depth - tree->depth) * 4)))

得到item的index位置（0-15），在node的不同层次，使用keyhash的不同的4位值做与结果。这个函数使得，当向hashtree添加新的data时，自根节点向下，通过node->depth的不同计算出其子节点index，并最终将数据保存在叶子节点上。

6、下面介绍几个核心函数的功能：

HTree*   ht_open(char *path, int depth);

打开htree索引文件，这在程序初始化阶段调用。在该函数中，通过调用get_max_pos函数遍历索引文件，得到max_pos，并以此确定内存需要存储的Node节点和Data的pool_size。因为Node节点和Data都要存储在内存中，所以当数据量很大时还是会消耗很多内存的。

static void *load_node(HTree *tree, Node *node)

加载node对应的data，如果node不是叶子节点返回NULL，如果tree->data不为空直接返回data，否则从db加载数据并校验有效性，有效时set数据到tree->data中相应的index，并返回数据。

static void update_node(HTree *tree, Node *node);

递归更新node的数据（hash、count），它是自底向上重新计算node的count和hash，叶子节点需要调用load_node加载数据。

static void save_node(HTree *tree, Node *node)

这同样是个递归操作，当node->modified为真，将数据更新到tchdb中，并调用update_node重新计算hash值，并释放掉data内存资源。

对于hashtree的add、delete、get操作，都会联合使用update_node和save_node保证内存数据及db数据的准确性。

3.3 服务端处理模型分析

服务端处理模型分为3部分，说明如下：

1、处理请求部分是由一个主线程+N个work线程构成。处理客户端请求代码是从memcached照搬过来的。主线程负责监听客户端请求，当accept后通过轮询方式将客户端fd扔到某个work线程的连接队列里，并通过pipe向work线程发送通知。Work线程处理的事件有两种：1是主线程发来的新的客户端连接请求，2是长连接情况下保持的客户端连接请求，其处理过程就是个状态机。这部分的代码不做分析，倘有时间，可以对memcached源码做更细致的分析。

2、flush线程，它定期遍历tcmdb，将tcmdb中的数据保存到tchdb中，并更新tcmdb和htree。

2、Check线程，它除了做flush线程的工作，还检查db数据和htree数据的一致性，当数据项个数差别很大时，将db数据信息更新到htree。窃猜测，这可能是htree损坏时会产生这种情况。

4、总结

写了这么多，其实并没有将源码整个托盘出来。像beansdb，代码算不上很多，如果是粗略的分析也用不上多少时间，不过要把整个代码的细节都照顾到还是需要一些耐心和时间的。纵览beansdb的代码，还是很清晰质量不错的。而就功能来说，它的proxy是可以用C实现得更完整些。