go-zero缓存设计之业务层缓存

    • 缓存只删除不更新
    • 唯一索引仅缓存主键值，不直接缓存行记录（参考mysql索引思想）
    • 防缓存穿透设计，默认一分钟
    • 不缓存多行记录

    在大型业务系统中，通过对持久层添加缓存，对于大多数单行记录查询，相信缓存能够帮持久层减轻很大的访问压力，但在实际业务中，数据读取不仅仅只是单行记录， 面对大量多行记录的查询，这对持久层也会造成不小的访问压力，除此之外，像秒杀系统、选课系统这种高并发的场景，单纯靠持久层的缓存是不现实的，本节我们来 介绍go-zero实践中的缓存设计——biz缓存。

    适用场景举例

    • 选课系统
    • 秒杀 …

    像这些系统，我们可以在业务层再增加一层缓存来存储系统中的关键信息，如选课系统中学生选课信息，课程剩余名额；内容社交系统中某一段时间之间的内容信息等。

    接下来，我们一内容社交系统来进行举例说明。

    在内容社交系统中，我们一般是先查询一批内容列表，然后点击某条内容查看详情，

    从图以及上一篇文章go-zero缓存设计之持久层缓存中我们可以知道，内容列表的获取是没办法依赖缓存的， 如果我们在业务层添加一层缓存用来存储列表中的关键信息（甚至完整信息），那么多行记录的访问不在是一个问题，这就是biz redis要做的事情。 接下来我们来看一下设计方案，假设内容系统中单行记录包含以下字段

    我们的目标是获取一批内容列表，而尽量避免内容列表走db造成访问压力，首先我们采用redis的sort set数据结构来存储，根需要存储的字段信息量，有两种redis存储方案：

    • 缓存局部信息

    • 缓存完整信息

      biz-redis-01 对发布的所有内容按照一定规则压缩后均进行存储，同样score我们还是用createTime毫秒值，这种存储方案的好处是业务的增、删、查、改均走reids，而db层这时候 就可以不用考虑行记录缓存了，持久层仅提供数据备份和恢复使用，从另一方面来看，其缺点也很明显，需要的存储空间、配置要求更高，费用也会随之增大。

    示例代码：

    在以上例子中，redis是没有设置过期时间的，我们将增、删、改、查操作均同步到redis，我们认为内容社交系统的列表访问请求是比较高的情况下才做这样的方案设计， 除此之外，还有一些数据访问，没有想内容设计系统这么频繁的访问， 可能是某一时间段内访问量突如其来的增加，之后可能很长一段时间才会再访问一次，以此间隔， 或者说不会再访问了，面对这种场景，如果我又该如何考虑缓存的设计呢？在go-zero内容实践中，有两种方案可以解决这种问题：

    • 增加内存缓存：通过内存缓存来存储当前可能突发访问量比较大的数据，常用的存储方案采用map数据结构来存储，map数据存储实现比较简单，但缓存过期处理则需要增加 定时器来出来，另一宗方案是通过go-zero库中的 ，其是专门 用于内存管理.

    总结