消息提醒设计

[hhh798]

场景是这样的：每当有人给我的文章点赞、评论、关注我的时候，我就会收到消息提醒，

我是这样做的：我建了一个消息表，存储所有的消息记录，每个点赞、评论、关注都生成一条记录。

但是如果用户点赞或了我，数据库生成了记录，过会又取消了，此时记录已经生成了，等用户登录 APP 时，所以仍然会收到提醒。。

这种取消就不收到提醒，应该怎么做呢？

[ysoserious]

取消就删掉相应的未读提醒？

[hhh798]

@ysoserious 无法知道是哪一条

[ysoserious]

@nioncodotcom 重新设计消息表或者提醒机制，找不到目标，无法撤回也不能拦截

[hhh798]

@ysoserious 不知道行业内常用做法是咋样的

[bukip]

再发一条”某用户又取消了对你的点赞！“『皮』

[rogwan]

取消可以不通知，不用管这个状态。如果前面用户看到关注的消息，点击进去发现粉丝已经取消了，这个也不是什么大问题，至少表示曾经粉过 up 主。

[rogwan]

掉粉、粉转路人，很多系统都是不通知主人的

[lzxgh621]

不太理解，不知道谁点赞哪一条那提醒有什么用，用户会看到什么呢？

[lzxgh621]

微信朋友圈删除评论提醒数字还在点进去什么都没有我是一直不能理解啊。

[hakono]

就和上面说的一样，就不取消通知呗，又没问题。，
点赞后取消掉，用户收到通知发现没有被点赞，肯定会知道是别人取消了，这个其实也是符合用户操作逻辑的

如果想真的在用户接收到推送前删除这条消息，那你就只能重新设计表结构了，这没办法的
如果实在没办对原本的表做更改，那你就只能在其他地方记录生成的数据记录的 id 了（如果你的表里连自增的 id 键都没的话，那真的还是建议重新设计表结构了），然后加上点赞用户，被点赞用户，时间之类的信息，取消点赞的时候从这个表反查到 id，然后你搞完就会发现，还不如重新设计表最简单

[Immortal]

不知道消息表怎么设计的
我想了下 如下字段不能完成这个需求么：
id from to type article_id deleted_at
- 关注的消息 article_id 是为空的
- 每种类型的消息都有自己的 type
- 取消的时候就给 deleted_at 增加一个取消时间戳，默认为空,或者直接物理删除
这样在取消关注、点赞、删除评论的时候根据 to+article_id 应该能锁定到消息了

[ericgui]

搞对列比较合适


至于你说用户取消了，没办法取消的，已经发送的，是取消不了的

[EscYezi]

在消息表里加一个逻辑删除字段，取消时置 1，下次用户登录时查消息表数据决定是否提醒。
不过现在 app 好像都要进行推送的吧？

[EscYezi]

那样的话只能在推送发出之前拦截了，没拦住的话用户打开 app 看到点赞消息出现又消失？😂

[nvkou]

延时队列？反正这种通知不是时间敏感。晚个 1 分钟也没问题。话说为什么要记录用户操作呢。只记录文章有多少点赞不行吗？用户还需要知道自己点赞过什么？

[xuanbg]

5 楼正解，取消了再发一条取消的消息才是正常操作。

[hhh798]

@xuanbg 取消有消息，感觉有点傻
@nvkou 被点赞、被评论、被关注的人需要知道呀
@EscYezi 准备加一个逻辑删除字段了
@Immortal 就准备这么干了
@hakono 表重新设计了

[Vtwoguest]

很多 App 的逻辑都是关注有提醒，关注之后取消不提醒，点进去就会显示无
另外想问一下表存在记录后接下来的逻辑是如何设计的呢

[liuzhaowei55]

如果按现在的消息表这样设计，在消息表里应该关联该消息的事件主体会好一点，不然以后这条消息就是孤岛了。
之前我也是这样设计的，不过后来就取消了消息表的设计，直接在事件主体上标注受影响人对于这条消息的已读未读删除，结构更简单了，毕竟也只是一个事件的通知，一般也就未读已读删除三个操作。

[lufeng08]

接着讨论，我们也有消息系统，晚上来看结论，优化我们的消息系统。