基于Repository设计缓存方案

Thu, 14 Nov 2019 09:14:25 +0800

场景#

Tester—A：这个 getInfo 接口咋这么慢呢？查一下要5+s？QPS竟然只有10！！！！
RD-B    ：这是因为getInfo要查库。。。N多库
Tester-B：那优化一下呗？
RD-B    ：好的，容我操作一波（给接口加上一个响应缓存），好了你再测试一下
Tester-B：（测试中。。。），速度果然快了不少。诶不对，这个接口里拿到的用户信息不对，我明明已经balaba了，这里没有更新！！！
RD-B    ：哦哦哦，我晓得咯，再容我操作一波（缓存加有效时间，个人信息更新的时候再强删缓存），O了

至此开始了针对于QPS+缓存更新的一些列测试。。。剧终。

QPS和响应时间是后（jie）端（kou)工程师非常熟悉的指标，这两个值能比较直观的反映该接口的性能，间接直接影响了前端页面的流畅度。。。

问题来了#

接口查询性能如何提高#

除去机器和编程语言的因素之后，肯定要从业务场景出发，分析接口响应缓慢的原因。譬如，最常见的:

查N多表，表还没有索引orz
无用数据，增加传输的Size
反复查询某些热点数据，但每次都直接打到数据库
上游服务响应缓慢
其他

好了，这里只讨论热点数据的缓存方案，毕竟要具体场景具体分析，而缓存方案是比较通用的。

缓存方案如何选择#

序号	缓存方案	优势	劣势
1	Response缓存	简单暴力	缓存更新时机不好把控，如果面面俱到可能心态崩坏；缓存粒度太大，无法局部更新；针对查询接口有帮助，其他业务下查询数据则毫无帮助
2	Repository缓存	粒度由Repo自行掌握，可控性强；Repo复用场景下会提高应用整体的速度	需要针对各个Repo做缓存的处理；改动较多；其他orz

总的来说，Repository的缓存方案，在上述背景上较简单暴力的中间件缓存法要更加优雅可控～。

缓存算法#

提到缓存就一定会提到缓存替换策略，有最常见的：LRU LFU FIFO MRU(最近频繁使用算法) LRU的多个变种算法 LIRS等。这里选用了LRU-K（K=2）并基于golang来实现 cached-repository，更多算法的详细信息参见参考文档中的LRU和LRU-K:

这里分成了两个interface:

CacheAlgor重点在于与Repo交互，所以只提供了简单的增删改查，底层还是基于Cache来实现的。本意是想实现多种缓存替换算法来丰富cached-repository，orz

// cache.go
// CacheAlgor is an interface implements different alg.
type CacheAlgor interface {
	Put(key, value interface{})
	Get(key interface{}) (value interface{}, ok bool)
	Update(key, value interface{})
	Delete(key interface{})
}

lru.Cache 在于提供基于LRU-like算法缓存和替换能力，所以接口会更丰富一些，

// lru/types.go
// Cache is the interface for simple LRU cache.
type Cache interface {
	// Puts a value to the cache, returns true if an eviction occurred and
	// updates the "recently used"-ness of the key.
	Put(key, value interface{}) bool

	// Returns key's value from the cache and
	// updates the "recently used"-ness of the key. #value, isFound
	Get(key interface{}) (value interface{}, ok bool)

	// Removes a key from the cache.
	Remove(key interface{}) bool

	// Peeks a key
	// Returns key's value without updating the "recently used"-ness of the key.
	Peek(key interface{}) (value interface{}, ok bool)

	// Returns the oldest entry from the cache. #key, value, isFound
	Oldest() (interface{}, interface{}, bool)

	// Returns a slice of the keys in the cache, from oldest to newest.
	Keys() []interface{}

	// Returns the number of items in the cache.
	Len() int

	// iter all key and items in cache
	Iter(f IterFunc)

	// Clears all cache entries.
	Purge()
}

关于如何实现LRU或者LRU-K，网上已经有很多文章了，原理也不复杂，这里就不过多赘述了，直接上测试结果

LRU和LRU-K

Mon, 12 Aug 2019 20:10:32 +0800

缓存淘汰机制#

缓存淘汰机制在缓存需要被清理的时候使用。主要有以下几种算法：

FIFO：先入先出，优先清理最先被缓存的数据对象。实现简单，直接使用队列就可以实现。
LRU：最近最久未被使用，优先清理最近没有被使用的对象。使用一个最近使用时间降序的有序队列，优先清理队列对后的数据。与LFU的区别在于：LRU是按照最近使用使用的时间排序，LFU需要维护一个使用频次并用于排序。
LFU：最近最少使用，优先清理最近最少使用的数据对象。使用一个使用次数降序的有序队列，优先清理队列最后的数据。

// 其中LRU和LFU可以通过维护一个Hashmap来提高访问效率。

LRU / LRU-1#

LRU（Least recently used，最近最少使用）算法根据数据的历史访问记录来进行淘汰数据，其核心思想是“如果数据最近被访问过，那么将来被访问的几率也更高”。实现思路也很简单，就不过多赘述了：

// data to cache
type data struct {
    key   int
    value int
}

// LRUCache structture to support LRU alg.
type LRUCache struct {
    recoder map[int]*list.Element // key hit for get op O(1)
    linked  *list.List            // linked-list
    rest    int                   // rest capacity
}

// Constructor ... to generate a LRUCache
func Constructor(capacity int) LRUCache {
    c := LRUCache{
        rest:    capacity,
        linked:  list.New(),
        recoder: make(map[int]*list.Element),
    }

    return c
}

// Get ... O(1) wanted
func (c *LRUCache) Get(key int) int {
    v, ok := c.recoder[key]
    if !ok {
        return -1
    }
    // hit the key
    _ = c.linked.Remove(v)
    c.recoder[key] = c.linked.PushFront(v.Value)
    fmt.Println("get", key, c.linked.Len(), c.recoder)

    return v.Value.(*data).value
}

// Put ... O(1) wanted
func (c *LRUCache) Put(key int, value int) {
    if v, ok := c.recoder[key]; ok {
        c.linked.Remove(v)
        goto h
    }

    if c.rest == 0 {
        tail := c.linked.Back()
        c.linked.Remove(tail)
        delete(c.recoder, tail.Value.(*data).key)
    } else {
        c.rest--
    }
h:
    head := c.linked.PushFront(&data{key, value})
    c.recoder[key] = head
}

LRU-K#

LRU-K的主要目的是为了解决LRU算法“缓存污染”的问题，其核心思想是将“最近使用过1次”的判断标准扩展为“最近使用过K次”。也就是说没有到达K次访问的数据并不会被缓存，这也意味着需要对于缓存数据的访问次数进行计数，并且访问记录不能无限记录，也需要使用替换算法进行替换。当需要淘汰数据时，LRU-K会淘汰第K次访问时间距当前时间最大的数据。

缓存 on Yeqown