初入 Redis 向各位大神讨一个解决方案

可以用一个 hset,key 是 catid,value 是 json 序列化的 string

@Mirana 那如果修改某个值不是还要序列化和反序列化吗。有点麻烦。

第一种： hset ， catid 为 key ，结构为：{‘ 1_like ’: 100, ‘ 1_hate ’: 90, ‘ 2_like ’: 20, ‘ 2_hate ’: 10, ....}，不建议 key 中包含长字符串，所以可以用 0 代表 like ， 1 代表 hate ，于是成为：{‘ 1_0 ’: 100, ‘ 1_1 ’: 90, ‘ 1_0 ’: 20, ‘ 1_1 ’: 10, ....}
第二种：直接用 catid_id_like 的形式，如： 1_1_like: 100 ， 1_1_hate: 90 ，同样 0 代表 like ， 1 代表 hate ，成为： 1_1_0: 100 ， 1_1_1: 90

上面适合不同的 catid 下有相同的 item_id ，如果不同的 catid 下面的 item_id 不存在重复的，那么就简单了，第二种，并且 key 中去掉 catid ，表示为： id_like ，如： 1_like: 100 ， 1_hate: 90 ，同样 0 代表 like ， 1 代表 hate ，成为： 1_0: 100 ， 1_1: 90

只是一种思路，具体细节根据 lz 情况自行调整。

@jsonfork 做好封装你就不会有这种感觉了。。。。。。

@tonghuashuai 不同的 catid 下会有相同的 item_id 。还有一种方案：使用 hmset ， catid 同样为 key ，结构为：{`1`:`100_102`,`2`:`10_22`,...} ，`1` 为 item_id ，`100_102` ， 100 为 like ， 102 为 hate ，这种结构怎么样，有没有什么问题。

@jsonfork
key value 的思想是唯一的 key 对应唯一的 value ，你这种方式叶能实现功能，但是 like 和 hate 操作都会更新同一个 key 的 value ，个人认为不太好，只是个人认为。

@tonghuashuai 嗯，用了第一种方式。 这样操作会方便些。 这个数据量如果大的话会有影响的吗。 就是意味着我们 10W 条数据，要产生 20W 的记录值。这样查询性能有影响吗。

@jsonfork
hash 数据结构的时间复杂度是 O(1)，所以 hget hset 的时间复杂度都是 O(1)，所以数据量不会影响性能。

@tonghuashuai OK, 谢谢老司机指路！！

我建议是使用 zset, member 是 id, score 是 like << 32 + hate
如果要 like zadd(id, 1<<32 + 1)
如果是 hate zadd(id, 1)

如果要批量获取 id 的 score 可以使用一个临时的 zset, 把 ids 放在这个 zset 总和原始数据进行 ZINTERSTORE:


使用 hget 的问题不是 hget 本身效率的问题. 是太多 round trip.

@caixu
纠正下:

如果要 like ZINCRBY(id, 1<<32 + 1)
如果是 hate ZINCRBY(id, 1)

@caixu 不太了解你说命令。看不怎么懂。 但是我发现你没有用到 catid ，因为我是用 catid 来做分类的， 每个 catid 下面会有相同的 item_id 。