简述
以微信朋友圈为例,但又与微信不同是微信是以强社交为主,只有好友之间才可以查阅对方的朋友圈内容,而我们当前的设计类似的微博以弱社交的表现形式,其显著特点就是即便互相没有关注也可以访问对方的朋友圈数据。所以设计之初首先要确认应用场景是强社交
,还是弱社交
关系。
场景
基于timeline的用户留言与点赞
信息流
注意事项,AREA1
,AREA2
分别是两块SCHEMA分别存储在mongodb中,本文的重点也是根据实际示例探讨这两块SCHEMA的存储结构。
1
. 系统所有的时间均是timestamp long类型,时间间隔24小时之内均显示(xx小时之前),如1小时27分钟前则显示(1小时前);间隔1小时内则显示(xx分钟前);不足1分钟则显示(刚刚)。该时间算法由客户端自己完成,服务器端只提供创建时间,默认时区为UTC+8.2
. 用户显示上报设备型号,则显示该记录。有可能用户上包的设备型号是(oneplus a6000)则显示为(一加 6,或者 oneplus 6)所以设备型号要后台维护。3
.点赞,延迟3秒与服务器同步,可取消点赞。点赞成功图标高亮显示,不影响数据同步。无人点赞数字区域显示赞
4
.留言总数,无人留言显示回复
5
.默认值显示3-5条最新的留言记录。支持emoji字符存储。点击4
,5
则进入留言详细列表
留言列表
注意事项,分页显示数据,处理好同步机制。A
.同1
B
.同3
C
.这条记录用于张三回复了李四D
.王五的这条留言被2人点赞其中含当前用户,则高亮显示点赞图标。但无人回复E
.钱七回复了麻六,则麻六的回复标签上有回复记录的总数。F
.回复主贴
键盘由点击具体事件后弹出,如先点击1
,A
,输入框提示回复主体。
评论
1
.直接评论主贴
回复
A
.回复他人留言
存储方案
写入效率低,数据允余占用存储空间,读取效率高。
基于redis
1 | new post: |
基于mongodb
示例详解
服务器返回数据
API的设计原则是尽可能的将能一次返回所需要的所有数据,从而减少与服务器间的交互。而我们在存储的时候也不太可能将动态数据直接存储持久化。一旦数据结构改变变动会比较大,从而适当的设计关联关系有助于简化业务逻辑充分的利用mongodb高性能特性。
1 | { |
AREA1 模块
1 | "category":"PICTURE", |
AREA2 comments 模块
1 | "comments":[ |
AREA2 comments 模块存储优化
1 | "comments_postid":[ |
AREA2 likes 模块
1 | "likes":[ |
AREA2 likes 模块存储优化
1 | "likes_postid":[ |
最终的储存结构
1 | { |
update
2018.11.29
补充一下。likeCount
commentCount
是实时计算的出来的,而不是持久化在mongodb中。