c# - Redis Lua 脚本返回表并解析对象

Question

我有一个问题，

local searchkey=@searchkey
local blockKeys = redis.call('keys', searchkey)
local table = {}
for i = 0, #blockKeys, 1 do
    local seats = redis.call('HVALS', blockKeys[i])
    table[i] = seats
end
return table

我想为 .net obj 解析此表数据我使用了 StackExchange.Redis 库和 lua 返回 RedisResult 但 lua 表数据未解析 RedisValue[]

有人有想法吗？

Answer 1

RedisResult 是未知形状数据的通用包装器。有些运算符允许您以多种方式解释数据，例如:

RedisResult val = ...

// simple
int asInt = (int)val; // a single integer
string asString = (string)val; // a single string

string[] asStrings = (string[])val; // a table of strings
double[] asDoubles = (double[])val; // a table of doubles

// more structured

var asKeys = (RedisKey[])val; // a table of keys
var asValues = (RedisValue[])val; // a table of values
var asMulti = (RedisResult[])val; // a table of general purpose values

因此您可以可能将其转换为您需要的内容。但是:在脚本中使用 KEYS 是个大问题，您真的应该改变它。

---

解决评论中的问题:

Why I dont use keys , can you explain it to me ? Because I check performance, and keys is better than scan, and for table, hvals return binary object so => key, { {key, obj}, {key, obj}}

引用自redis documentation :

Warning: consider KEYS as a command that should only be used in production environments with extreme care. It may ruin performance when it is executed against large databases. This command is intended for debugging and special operations, such as changing your keyspace layout. Don't use KEYS in your regular application code.

每个 Redis 实例都有一个单线程核心来处理请求。 KEYS 在小型数据库上看起来不错，但是有或没有过滤器性能是 O(N)，其中 N 是总 数据库中的键数，对于大型系统:它可能灾难性地坏 - 意思是:需要 10 秒才能返回。通常，预计 Redis 操作将花费最坏的几毫秒，而当您的KEYS 操作运行时:没有其他可以。它完全在那段时间阻塞了服务器。

您注意到 KEYS 比 SCAN 更有效，在某些方面确实如此。 SCAN 的全部意义在于它允许您将操作作为一系列(可能很长)小批量 - “扫描前 100 个；现在扫描下一个从那里开始 100；然后是下一个 100”。这有更多的开销和延迟，并且涉及到服务器的更多往返，但优点是它不会在很长一段时间内阻塞服务器核心。

但是!通常，更好的方法是使用一组您希望与您的数据相匹配的东西。假设您有一个大数据库并且您对所有 /foo/{whatever} 数据感兴趣。现在;不是使用 KEYS 或 SCAN 来查找这些值，如果您需要迭代该系列中的所有键，简单地删除是可行的所有的键到一个集合中。因此，当您创建 /foo/abc 时，您还将 /foo/abc 放入 set /foo/_keys (或其他；这里没有约定)通过 sadd。现在:要迭代该系列中的所有键，您只需迭代 set /foo/_keys - 这是一个 非常 更合适的 API。