既然标准库中没有我们满足上述需求的本地缓存组件，那我们就想只有两种解决方案了
那首先面临的第一个问题就是方案的调研和选型，没有合适的方案时自己再来动手构建。下面我们就来给大家介绍下golang中哪些可以直接来使用的本地缓存组件吧。
2.golang本地缓存组件概览
golang中本地缓存方案可选的有如下一些：
下面通过笔者一段时间的调研和研究，将golang可选的开源本地缓存组件汇总为下表，方便大家在方案选型时作参考。
在上述方案中，freecache、bigcache、fastcache、ristretto、groupcache这几个大家根据实际的业务场景首选，offheap有定制需求时可考虑。
通过上表的总结，个人想再此再谈几点关于本地缓存组件的理解：
1.上述本地缓存组件中，实现零GC的方案主要就两种：
a.无GC：分配堆外内存(Mmap)
b.避免GC：map非指针优化(map[uint64]uint32)或者采用slice实现一套无指针的map
c.避免GC：数据存入[]byte slice(可考虑底层采用环形队列封装循环使用空间)
2.实现高性能的关键在于：
a.数据分片(降低锁的粒度)
上述几种缓存组件每种组件的实现都是1和2的几个分支的组合。下面我们大概给大家介绍每种组件的核心原理。
3. 主流缓存组件实现原理剖析
在本节中我们会重点分析下freecache、bigcache、fastcache、offheap这几个组件内部的实现原理。
3.1 freecache实现原理
首先分析下freecache的内部实现原理。在freecache中它通过segment来进行对数据分片，freecache内部包含256个segment，每个segment维护一把互斥锁，每一条kv数据进来后首先会根据k进行计算其hash值，然后根据hash值决定当前的这条数据落入到哪个segment中。
对于每个segment而言，它由索引、数据两部分构成。
索引：其中索引最简单的方式采用map来维护，例如map[uint64]uint32这种。而freecache并没有采用这种做法，而是通过采用slice来底层实现一套无指针的map，以此避免GC扫描。
数据：数据采用环形缓冲区来循环使用，底层采用[]byte进行封装实现。数据写入环形缓冲区后，记录写入的位置index作为索引，读取时首先读取数据header信息，然后再读取kv数据。
在freecache中数据的传递过程是：freecache->segment->(slot,ringbuffer)
下图是freecache的内部实现框架图。
总结：freecache通过利用数据分片减小锁的粒度，然后再存储时索引并没有采用内置的map来维护而是采用自建map减少指针来避免GC，同时数据存储时采用预先分配内存然后后边循环使用。通过上述两种方法保证了在堆上分配内存同时减少GC对系统性能的影响。
3.2 bigcache实现原理
bigcache和freecache类似，也是一个零GC、高性能的cache组件，但是它的实现和freecache还是有些差异，这儿有篇英文博客介绍bigcache设计原理的，内容稍长感兴趣的可以阅读下，下面我们介绍一下bigcache的实现原理。
bigcache同样是采用分片的方式构成，一个bigcache对象包含2^n 个cacheShard对象，默认是1024个。每个cacheShard对象维护着一把sync.RWLock锁(读写锁)。所有的数据会分散到不同的cacheShard中。
每个cacheShard同样由索引和数据构成。索引采用map[uint64]uint32来存储，数据采用entry([]byte)环形队列存储。索引中存储的是该条数据在entryBuffer写入的位置pos。每条kv数据按照TLV的格式写入队列。
不过值得注意的是，和bigcache和freecache不同的一点在于它的环形队列可以自动扩容。同时bigcache中数据的过期是通过全局的时间窗口维护的，每个单独的kv无法设置不同的过期时间。
下面是bigcache的内容实现原理框架图。
总结：bigcache思路和freecache大体相同，只不过在索引存储时更为巧妙，直接采用内置的map结构加上基础数据类型来实现。同时底层存储数据的队列也可以根据空间大小来决定是否扩容。唯一的缺陷是无法针对每个key进行设置不同的过期时间。这个个人认为如果想用bigcache同时想要这个特性，可以进行二次开发一下。
通过性能测试数据来看，bigcache性能要比freecache稍微好一点。大家可以思考下他们性能的差异可能会在哪里呢？
3.3 fastcache实现原理
本节介绍下fastcache的实现原理，根据fastcache官方文档介绍，它的灵感来自于bigcache。所以整体的思路和bigcache很类似，数据通过bucket进行分片。fastcache由512个bucket构成。每个bucket维护一把读写锁。在bucket内部数据同理是索引、数据两部分构成。索引用map[uint64]uint64存储。数据采用chunks二维的切片(二维数组)存储。不过值得注意的是fastcache有一个很大的特性是，它的内存分配是在堆外分配的，而不是在堆上分配的。堆外分配的内存。这样做也就避免了golang GC的影响。下图是fastcache内部实现框架图。
总结：fastcache一方面充分利用了分片来降低锁的粒度，另一方面在索引存储时采用了对map的优化，同时在分配内存时，直接从堆外申请内存，自己实现了分配和释放内存的逻辑。通过上述手段使得GC的影响降到了最低。fastcache唯一的缺陷是官方提供的版本没有提供针对kv数据的过期时间这个特性。所以如果需要这个特性的话，需要自己动手二次开发。整体从性能上来看是比bigcache和freecache都更优。
3.4 offheap实现原理
本节介绍下offheap的相关内容，offheap其实功能就比较简单了，就是一个基于堆外内存构建的哈希表。它通过直接调用系统调用函数来分配内存。然后在内部通过数组来实现哈希表。实现过程中当发生哈希冲突时，它是采用探测法来解决。由于是在堆外分配的内存上构建的哈希表。导致它的GC开销非常的小。下图是offheap的内部实现框架图。
总结：offheap内部由于是采用探测法解决哈希冲突的，所以当哈希冲突严重时数据删除、查询都会带来非常复杂的处理流程。而且性能也会有一些损耗。可以作为学习和研究的项目还是非常不错的。
4.总结