我们先来看这么一个问题：如果现在有一个小规模的倒排索引，它能完全加载在内存中。当有新文章进入内存的时候，倒排索引该如何更新呢？这个问题看似简单，但是实现起来却非常复杂。
我们能想到最直接的解决思路是，只要解析新文章有哪些关键词，然后将文章 ID 加入倒排表中关键词对应的文档列表即可。没错，在没有其他用户使用的情况下，这样的方法是可行的。但如果你有过一定的工程经验，你就会知道，在实际应用中，必然会有多个用户同时访问这个索引。
这个时候，如果我们直接更新倒排索引，就可能造成用户访问错误，甚至会引发程序崩溃。因此，一般来说，我们会对倒排表加上「读写锁」，然后再更新。但是，加上「锁」之后会带来频繁的读写锁切换，整个系统的检索效率会比无锁状态有所下降。
因此，为了使得系统有更好的性能，在工业界的实现中，我们会使用一种叫做 Double Buffer（双缓冲）机制 的解决方案，使得我们可以在无锁状态下对索引完成更新。
所谓 Double Buffer ，就是在内存中同时保存两份一样的索引，一个是索引 A，一个是索引 B。我们会使用一个指针 p 指向索引 A，表示索引 A 是当前可访问的索引。那么用户在访问时就会通过指针 p 去访问索引 A。这个时候，如果我们要更新，只更新索引 B。这样，索引 A 和索引 B 之间就不存在读写竞争的问题了。因此，在这个过程中，索引 A 和索引 B 都可以保持无锁的状态。
那更新完索引 B 之后，我们该如何告知用户应该来访问索引 B 呢？这时候，我们可以将指针 p 通过 原子操作（即无法被打断的最细粒度操作，在 Java 和 C++11 等语言中都有相应实现）从 A 直接切换到 B 上。接着，我们就把索引 B 当作只读索引，然后更新索引 A。
通过这样的机制，我们就能同时维护两个倒排索引，保持一个读、一个写，并且来回切换，最终完成高性能的索引更新。不过，为了避免切换太频繁，我们并不是每来一条新数据就更新，而是积累一批新数据以后再批量更新。这就是工业界常用的 Double Buffer 机制。
笔者没有明白的是：B 有了新增的文档 30 ，切换到 B 了，那么 A 里面并没有文档 30 ，如何同步数据呢?
用 Double Buffer 机制更新索引是一个高效的方案，追求检索性能的应用场景常常会使用这种方案。但是对于索引到了一定量级的应用而言，使用 Double Buffer 会带来翻倍的内存资源开销。比如说，像搜索引擎这样万亿级网页的索引规模，数据大部分存储在磁盘上，更是无法直接使用 Double Buffer 机制进行更新的。因此，我们还是需要寻找其他的解决方案。
