使用排序集到通知系统(Use sorted set to notifications system)

使用排序集到通知系统(Use sorted set to notifications system)

我使用redis sorted sets来保存用户通知。 但由于我从未做过通知系统，我问的是我的逻辑。

我需要为每个通知保存4件事。

POST_ID post_type - A / B. 可见 - Y / N. 检查 - 是/否

---

我的问题是如何在排序集中存储这种类型的结构？

ZADD users_notifications:1 10 1_A_Y_Y ZADD users_notifications:1 20 2_A_Y_N ....

在redis中有更好的方法来做这种类型的东西吗？ 在上面的例子中，我在每个元素中保存了四个东西，我需要用服务器语言中的下划线进行拆分。

I am using redis sorted sets to save user notifications. But as i never did a notification system, I am asking about my logic.

I need to save 4 things for each notification.

post_id post_type - A/B visible - Y/N checked - Y/N

---

My question is how can I store this type of structure in sorted sets?

ZADD users_notifications:1 10 1_A_Y_Y ZADD users_notifications:1 20 2_A_Y_N ....

There is a better way to do this type of stuff in redis? In the case above i am saving the four thing in each element, and i need to split by the underscore in the server language.

最满意答案

这实际上取决于您需要如何查询数据。

解决此问题的最常见方法是使用排序的排序集和每个对象的哈希值。

所以：

ZADD notifications:<user-id> <timestamp> <post-id> HMSET notifications:<user-id>:<post-id> type <type> visible <visible> checked <checked>

您可以使用ZRANGE按顺序获取最新通知，然后使用流水线调用HMGET来获取每个对象的属性。

正如我所提到的，这取决于您需要如何访问数据。 例如，如果您始终向用户显示可见和未经检查的通知，那么您可能希望将这些ID存储在不同的有序集中，这样您就不必查询状态。

假设您有这样一个排序集，当用户解除您要执行的通知时：

HSET notifications:<user-id>:<post-id> visible 0 ZREM notifications:<user-id>:visible <post-id>

It really depends on how you need to query the data.

The most common way to approach this problem is to use a sorted set for the order and a hash for each object.

So:

ZADD notifications:<user-id> <timestamp> <post-id> HMSET notifications:<user-id>:<post-id> type <type> visible <visible> checked <checked>

You'd use ZRANGE to get the latest notifications in order and then a pipelined call to HMGET to get the attributes for each object.

As I mentioned, it depends on how you need to access the data. If, for example, you always show visible and unchecked notifications to a user, then you probably want to store those IDs in a different sorted set, so that you don't have to query for the status.

Assuming you have such a sorted set, when a user dismisses a notification you'd do:

HSET notifications:<user-id>:<post-id> visible 0 ZREM notifications:<user-id>:visible <post-id>