JFinal里使用Redis.use(...).lpush会多一个0xFC字节?

@JFinal

我在项目里使用Redis.use(...).lpush("key名称", “字符串值”)

推到redis里后,用redis的客户端管理工具,看到这个key的value值对应的字符串前面多了一个0xFC。

当然,如果我直接Redis.use(...).lpop弹出一个值,看到String变量值也是对的。但问题是出现在我在redis里加载了一个段lua脚本,在这段脚本里调用lpop弹出一个值,然后对这个字符串调用

local x = cjson.decode(hongBao);

解析成json对象的时候,就抛异常了,说解析成json的时候,在第一个字符位发现违法字符。

然后我换一个方法:

Jedis jedis = Redis.use(ConstantConfig.REDIS_BONUS).getJedis();

jedis.lpush("key值", object.toJSONString());  


通过这种方法放推进去的值,用redis的客户端管理软件看,就没那个0xFC了,然后lua脚本也可以正确解析json做计算操作了。

我想问一下,为什么会出现这样的情况呢。看文档说Redis.use(...).lpush就是对Jedis的lpush的一层封装而已。怎么会多出来一个字节呢。

我做了其他实验,调用Redis.use(...)里的set方法往redis里里放一个map类型的数据,结果用redis客户端看里面的数据,也是多了一个0xFC字节。但奇怪的是,调用get方法,反序列化这个map,又能成功拿到map对象。

评论区

JFinal

2020-09-24 15:06

确保序列化与反序列化算法一致

jfinal reids plugin 存数据前都会前数据进行序列化,默认使用 fst 序列化,那么你用别的工具拿数据时,也得用 fst 的算法反序列化

序列化以后的数据会多出一些表示数据本身特征的数据

通过 setSerializer(...) 可以配置自己的序列化算法

zzutligang

2020-09-24 17:29

刚才看了源码,确实是因为使用fst序列化,不同的序列化工具可能会增加一些额外的特征字节。我这个问题就是使用了JFinal封装的redis操作函数(这些函数都加了额外的序列化操作)。然后又用lua脚本去读数据,结果反序列化成string的时候,就出错了。现在只能是回避这个问题了,因为我控制不了lua脚本的序列化和反序列化,就只能使用jedis原生的取、放数据的函数来操作了。

JFinal

2020-09-24 17:56

@zzutligang 做一个 RedisKit 工具类,封装一下常用的一些 api,内部通过 jfinal 的 Redis 来获取需要的 jedis,实现所需功能:

public class RedisKit {
public void lpush(...) {
Jedis jedis = Redis.use().getJedis();
try {
jedis. lpush(...);
} finally {
jedis.close();
}
}
}

zzutligang

2020-09-24 18:11

好的,接下来我就这么做了!

热门反馈

扫码入社