首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  程序员

消息提醒设计

  •  
  •   nioncodotcom · 23 天前 · 2257 次点击

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

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

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

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

    25 回复  |  直到 2019-10-22 13:27:19 +08:00
        1
    ysoserious   23 天前 via Android
    取消就删掉相应的未读提醒?
        2
    nioncodotcom   23 天前
    @ysoserious 无法知道是哪一条
        3
    ysoserious   23 天前 via Android
    @nioncodotcom 重新设计消息表或者提醒机制,找不到目标,无法撤回也不能拦截
        4
    nioncodotcom   23 天前
    @ysoserious 不知道行业内常用做法是咋样的
        5
    bukip   23 天前
    再发一条”某用户又取消了对你的点赞!“『皮』
        6
    rogwan   23 天前 via iPhone
    取消可以不通知,不用管这个状态。如果前面用户看到关注的消息,点击进去发现粉丝已经取消了,这个也不是什么大问题,至少表示曾经粉过 up 主。
        7
    rogwan   23 天前 via iPhone
    掉粉、粉转路人,很多系统都是不通知主人的
        8
    lzxgh621   23 天前
    不太理解,不知道谁点赞哪一条那提醒有什么用,用户会看到什么呢?
        9
    lzxgh621   23 天前
    微信朋友圈删除评论提醒数字还在点进去什么都没有我是一直不能理解啊。
        10
    hakono   23 天前
    就和上面说的一样,就不取消通知呗,又没问题。,
    点赞后取消掉,用户收到通知发现没有被点赞,肯定会知道是别人取消了,这个其实也是符合用户操作逻辑的

    如果想真的在用户接收到推送前删除这条消息,那你就只能重新设计表结构了,这没办法的
    如果实在没办对原本的表做更改,那你就只能在其他地方记录生成的数据记录的 id 了(如果你的表里连自增的 id 键都没的话,那真的还是建议重新设计表结构了),然后加上点赞用户,被点赞用户,时间之类的信息,取消点赞的时候从这个表反查到 id,然后你搞完就会发现,还不如重新设计表最简单
        11
    Immortal   23 天前
    不知道消息表怎么设计的
    我想了下 如下字段不能完成这个需求么:
    id from to type article_id deleted_at
    - 关注的消息 article_id 是为空的
    - 每种类型的消息都有自己的 type
    - 取消的时候就给 deleted_at 增加一个取消时间戳,默认为空,或者直接物理删除
    这样在取消关注、点赞、删除评论的时候根据 to+article_id 应该能锁定到消息了
        12
    ericgui   23 天前
    搞对列比较合适


    至于你说用户取消了,没办法取消的,已经发送的,是取消不了的
        13
    EscYezi   22 天前 via iPhone
    在消息表里加一个逻辑删除字段,取消时置 1,下次用户登录时查消息表数据决定是否提醒。
    不过现在 app 好像都要进行推送的吧?
        14
    EscYezi   22 天前 via iPhone
    那样的话只能在推送发出之前拦截了,没拦住的话用户打开 app 看到点赞消息出现又消失?😂
        15
    nvkou   22 天前 via Android
    延时队列?反正这种通知不是时间敏感。晚个 1 分钟也没问题。话说为什么要记录用户操作呢。只记录文章有多少点赞不行吗?用户还需要知道自己点赞过什么?
        16
    xuanbg   22 天前
    5 楼正解,取消了再发一条取消的消息才是正常操作。
        17
    nioncodotcom   22 天前
    @xuanbg 取消有消息,感觉有点傻
    @nvkou 被点赞、被评论、被关注的人需要知道呀
    @EscYezi 准备加一个逻辑删除字段了
    @Immortal 就准备这么干了
    @hakono 表重新设计了
        18
    Vtwoguest   22 天前
    很多 App 的逻辑都是关注有提醒,关注之后取消不提醒,点进去就会显示无
    另外想问一下表存在记录后接下来的逻辑是如何设计的呢
        19
    liuzhaowei55   22 天前
    如果按现在的消息表这样设计,在消息表里应该关联该消息的事件主体会好一点,不然以后这条消息就是孤岛了。
    之前我也是这样设计的,不过后来就取消了消息表的设计,直接在事件主体上标注受影响人对于这条消息的已读未读删除,结构更简单了,毕竟也只是一个事件的通知,一般也就未读已读删除三个操作。
        20
    lufeng08   22 天前
    接着讨论,我们也有消息系统,晚上来看结论,优化我们的消息系统。
        21
    nioncodotcom   22 天前
    @Vtwoguest 接下来就前台请求就查表把消息记录返回
    @liuzhaowei55 什么事件主体,消息记录里有发送人、接收人了啊,消息记录里也加了是否已读标志、是否删除标志
        22
    Vegetable   22 天前
    来换一个顺序,点赞-通知-收到通知-取消点赞。这种情况下,用户已经读到了通知了,系统如果把通知删了,用户会很迷惑,所以唯一能做的就是再发一次取消点赞的通知(没见过谁家做这个功能...)。

    这样很简单就可以意识到,通知是不可以删除的,不必特殊处理。
        23
    YUyu101   22 天前 via Android
    点赞应该是变动了 userpost 表,评论是变动了 comment 表,这些记录变动想放同一张表的话就要记录表名、主键、变动类型、变动字段,这样缺点是没有外键,每张表有各自的历史记录表的话可以用外键,但表会很多。这样之后再来一张或几张消息表对应这些历史记录、消息发送对象、已读未读,因为同一个变动可能要通知多个人,消息插入是被动的可以防止死用户占空间,在每次对象上线时开始根据上次上线时间后的变动遍历统计一遍,有取消的删除的可以这时候不加入消息表,历史记录表还是有的,统计完一起插入更新下用户登录时间。怕用户消息太多可以在统计时合并掉,反正消息只是一条消息,记录表里全都有。
        24
    hst001   22 天前
    这个时候对用户来说,报好不报坏未必不是好事
        25
    nioncodotcom   22 天前
    现在消息表结构是这样的
    id from_user to_user target_id type read status
    自增 id 发送人 接收人 评论 id 或文章 id 消息类型 是否已读 是否取消

    基本可以满足吧,点赞取消则根据 target_id 修改 status,关注取消则根据 from_user 修改 status
    @Vegetable @YUyu101 我现在没做实时推送消息,就登录后请求一下后台,看有没有未读消息
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   926 人在线   最高记录 5043   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 26ms · UTC 20:29 · PVG 04:29 · LAX 12:29 · JFK 15:29
    ♥ Do have faith in what you're doing.