app上的消息的已读和未读状态！

[_楠竹]

假如推送五条通知，用户总量为10万。10万个用户对消息的已读和未读状态是不一样的，有可能读了三条，有可能读了一条，甚至一条没读。如果做一张中间表保存用户是否对这五条通知已读未读的话，就会变成只要推送一条通知中间表立马产生10万条记录。推送的消息越多中间表记录成倍数增长。有没有更优的做法，中间表方式数据太多了。

[tianfang]

没有特别好的办法 可以用当前表+历史表的方式处理，历史表一定要用nosql方式存储，性能要求不高，就全部用nosql存储

[feng00~]

个人认为可以这么设计： 设计一个已读记录表，字段 ：用户ID、通知编号(可以存多个) 如： 用户ID 已读通知 10001 1,2,3 1.推送5条通知 2.用户10001 打开了1号通知，发送服务器，已读记录表插入一条记录，10001 1 3.用户10002 打开了2号通知，请求服务器，更新记录 10001 1,2 4.判断是否已读，交给app来处理，服务器只需提供已读列表接口 5.APP判断通知列表中的ID是否存在于 已读列表中，如果存在则标记为已读。

[_楠竹]

楼上的做法也想到过，读一条才插入一条进入数据库，查询的时候left/right join起来，有就有没就没。感觉长此以往，这中间表的数据也不会小到哪里去。

[李德胜1995]

尝试一下redis的储存，使用set结构，key为消息id,value为已读此信息的用户的id... 如果一条信息10万用户已读，这个set集合就有10万个元素。。。 判断用户的id是否在此集合中来判断用户是否对此条信息已读。。。

[feng00~]

引用 3 楼 admin_admin_111 的回复:

楼上的做法也想到过，读一条才插入一条进入数据库，查询的时候left/right join起来，有就有没就没。感觉长此以往，这中间表的数据也不会小到哪里去。

不明白为什么需要left，right？只需提供一个查询已读记录的接口，让app自己拿已读ID和消息ID比较， 判断已读未读。 数据增长是必然的，除非没有用户。

[ah_ty]

不明白为啥已读未读状态不存在客户端

[你女友很喜欢我]

引用 7 楼 ah_ty 的回复:

不明白为啥已读未读状态不存在客户端

那要是网页呢，多端登录呢，每个端都要重新提醒一遍吗?

[你女友很喜欢我]

引用 11 楼 ah_ty 的回复:

[quote=引用 8 楼 你女友很喜欢我 的回复:][quote=引用 7 楼 ah_ty 的回复:]不明白为啥已读未读状态不存在客户端

那要是网页呢，多端登录呢，每个端都要重新提醒一遍吗?[/quote] 你觉得多端的场景需要每个端都做消息推送吗？想要同步可以学习一波微信，思维不要那么死，要求app必须登录不就可以了吗？app登录后将最新已读消息id上传服务器，这样就可以同步了，是不是省了很多事呢？[/quote] 不是所有人需求都和微信一样，你可以借鉴但不是唯一。微信登录都是依赖一个已登录设备去进行登录，但是除了微信外，其他有几个这种实现方式？干嘛思维那么死呢

[你女友很喜欢我]

引用 11 楼 ah_ty 的回复:

[quote=引用 8 楼 你女友很喜欢我 的回复:][quote=引用 7 楼 ah_ty 的回复:]不明白为啥已读未读状态不存在客户端

那要是网页呢，多端登录呢，每个端都要重新提醒一遍吗?[/quote] 你觉得多端的场景需要每个端都做消息推送吗？想要同步可以学习一波微信，思维不要那么死，要求app必须登录不就可以了吗？app登录后将最新已读消息id上传服务器，这样就可以同步了，是不是省了很多事呢？[/quote] 况且，这个是微信之前用的方式，现在早就以服务器为主了

[你女友很喜欢我]

引用 11 楼 ah_ty 的回复:

[quote=引用 8 楼 你女友很喜欢我 的回复:][quote=引用 7 楼 ah_ty 的回复:]不明白为啥已读未读状态不存在客户端

那要是网页呢，多端登录呢，每个端都要重新提醒一遍吗?[/quote] 你觉得多端的场景需要每个端都做消息推送吗？想要同步可以学习一波微信，思维不要那么死，要求app必须登录不就可以了吗？app登录后将最新已读消息id上传服务器，这样就可以同步了，是不是省了很多事呢？[/quote] 你又怎么断定提出需求的人一定是有app，如果他只在网页上有这个需求呢,我一定是开发一个客户端用来存储吗

[ah_ty]

这种方式我也是想到但是目前还没有运用在生产中，其实可以尝试，有机会我会尝试一波，理论上是可行的，而且可以极大的降低服务器的压力以及数据存储

[ah_ty]

引用 8 楼 你女友很喜欢我 的回复:

[quote=引用 7 楼 ah_ty 的回复:]不明白为啥已读未读状态不存在客户端

那要是网页呢，多端登录呢，每个端都要重新提醒一遍吗?[/quote] 你觉得多端的场景需要每个端都做消息推送吗？想要同步可以学习一波微信，思维不要那么死，要求app必须登录不就可以了吗？app登录后将最新已读消息id上传服务器，这样就可以同步了，是不是省了很多事呢？

[ah_ty]

引用 8 楼 你女友很喜欢我 的回复:

[quote=引用 7 楼 ah_ty 的回复:]不明白为啥已读未读状态不存在客户端

那要是网页呢，多端登录呢，每个端都要重新提醒一遍吗?[/quote] 当然这种方式你觉得要求app必须登录不合适，还可以存一个用户最新已读消息id，这样一个用户只需要存一个id，每次用户读了消息可以去刷新这个id

引用 14 楼 你女友很喜欢我 的回复:

[quote=引用 11 楼 ah_ty 的回复:][quote=引用 8 楼 你女友很喜欢我 的回复:][quote=引用 7 楼 ah_ty 的回复:]不明白为啥已读未读状态不存在客户端

那要是网页呢，多端登录呢，每个端都要重新提醒一遍吗?[/quote] 你觉得多端的场景需要每个端都做消息推送吗？想要同步可以学习一波微信，思维不要那么死，要求app必须登录不就可以了吗？app登录后将最新已读消息id上传服务器，这样就可以同步了，是不是省了很多事呢？[/quote] 你又怎么断定提出需求的人一定是有app，如果他只在网页上有这个需求呢,我一定是开发一个客户端用来存储吗[/quote] 所以你要表达什么呢？你是为了和我扛？我不懂你要表达什么，我的建议是可以丢到客户端去，这样服务器的存储消息的复杂度是O1，操作每个用户的已读未读也是O1的时间复杂度和空间复杂度，你觉得你有更好的办法你可以说出来，当然你需要我可以有偿给你提供一套完整的O1复杂度的设计文档，你开心你可以有其他的意见和建议

[ah_ty]

引用 12 楼 你女友很喜欢我 的回复:

[quote=引用 11 楼 ah_ty 的回复:][quote=引用 8 楼 你女友很喜欢我 的回复:][quote=引用 7 楼 ah_ty 的回复:]不明白为啥已读未读状态不存在客户端

那要是网页呢，多端登录呢，每个端都要重新提醒一遍吗?[/quote] 你觉得多端的场景需要每个端都做消息推送吗？想要同步可以学习一波微信，思维不要那么死，要求app必须登录不就可以了吗？app登录后将最新已读消息id上传服务器，这样就可以同步了，是不是省了很多事呢？[/quote] 不是所有人需求都和微信一样，你可以借鉴但不是唯一。微信登录都是依赖一个已登录设备去进行登录，但是除了微信外，其他有几个这种实现方式？干嘛思维那么死呢[/quote] 说你思维死板，你还有脾气，你可以表达一下你的观点，让我们看看你的想法，而不是在这里做一个扛精