szyhf/go-diredisorm

An Redis ORM for golang. 一个go语言的Redis查询器。

简述

对Redis的数据操作的二次封装，以应付一些常见的情况，主要核心问题在于与DB层同步。 目前依赖于：go-redis 暂时不考虑解耦，这块成本太高了。

特性

1. 支持同名键的方式创建数据库保护，缓解缓存穿透的问题。
2. 提供一定程度的缓存重建锁，缓解缓存并发的问题。

启动及注册

option := &redis.Options{
	Addr: "127.0.0.1:6379",
}
RedisClient = redis.NewClient(option)
// 默认情况下请用default注册
rorm.RegistryRedisClient("default", RedisClient)

思路

根据现在遇到的情况一点点处理吧。

接口：QuerySet

最基础的QuerySet接口，提供一些基础方法。

获取QuerySet的方式由于各个扩展不尽相同，这里先不罗列了。

// 缓存穿透保护（连贯操作）
// 表示对本次查询的key做180s的缓存穿透保护
qs = qs.Protect(180*time.Second)

更多文档参考wiki目录

1. Main.md
2. ZSet.md

关于日志：

暂时没空处理日志的问题，先用着beego的loger，构建如果有问题，注释掉就好，不影响工作。

go-diredisorm's Issues

ZSetQuery中Rebuilding和ZAdd的问题记录

使用ZSet的时候，有ZAdd的调用时机有两个场景，一个是在Rebuilding的时候，一个是在同步新增元素的时候，此时要区分处理：

Rebuilding的时候

此时，key应该是不存在的，因此调用时ZAdd除了添加元素外，还承担了创建key的工作。

同步新增元素的时候

此时，key应该先存在，因为此时如果key不存在，ZAdd仅会添加当前增加的元素，则其他依赖于该ZSet的方法都会错误的认为该ZSet仅有刚同步的元素，数据库用已有的元素可能会遗失。所以如果此时key不存在，应先调用Rebuilding，再执行ZAdd。

当前解决方案

RedisQuerier中区分使用ZAddExpire和ZAddExpireIfExist方法，前者用于Rebuilding，后者用于同步新增元素。为了确保安全，Rebuilding的时候额外调用一次Del(key)，将当前key清除。