我的应用程序中有社交网络的各个方面,并且我已经实现了一个像这样的答案的事件流:
How to implement the activity stream in a social network
就像那里说的那样,系统中的每个通知,我都会为收到通知的每个用户(键)推送一个来自事件关系表的 ID 列表(值):
key value
user:1:notifications [25, 24, 23]
user:2:notifications [24, 22, 17, 13, 5, 4]
...
因此,我的表中只有导致此问题的事件和用户。发生的事情是我只有在 redis 中收到通知的用户,而在 mysql 中没有收到通知...
我的问题是,如果在 redis 中持久保存此 ids 是正确的,还是仅针对更新的 memcached 和定期修剪此列表是否正确?
最佳答案
与其说是编程问题,不如说这是一个应用程序架构/设计问题,因此理论上没有唯一的正确答案。
但是,在实践中 - Redis/Memcache 和许多其他此类实现并不意味着持久化非常大(或快速增长)的数据集。
作为一个nosql数据存储,Redis使用内存,再加上硬盘上的一个镜像。因此,虽然您可以存储的数据大小没有限制,但理想情况下,它应该始终小于您计划分配给 Redis 的空闲内存。
涵盖所有基础的最简单解决方案是在生成用户事件数据时将其存储在 Redis 中。使用 Redis 显示通知等。保持 cron 运行,截断所有早于预定义天数(或每个用户的预定义事件数)的事件日志,并将它们保存到常规数据库中。
当用户希望检索所有通知时,一些速度损失是可以接受的(因为它不是频繁的、必需的或提倡的操作)并且您可以绕过 Redis 从数据库中提取它们。
替代方案: 同样,最好根据您的应用程序的实际数量来选择要使用的解决方案。但你可以这样做:
- 将所有事件存储在数据库中
- 对于任何登录用户,获取所有事件并将其存储在 Redis 中
- 注销时从 Redis 中删除该用户的事件/通知
- 添加事件时,需要一些额外的逻辑来检查受影响的用户是否在线。在这两种情况下,您都需要将事件添加到数据库中,但如果受影响的用户在线,则也将其推送到他在 Redis 中的哈希。
关于mysql - 使用 redis 将所有用户通知保存在列表中?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/9603653/