1.对帖子点赞功能:
我的理解:
有3张表:_User表,Post表,Like表
Like表储存用户-帖子,表达用户对帖子的点赞.
点赞时需要查Like表判断是否已经点赞过,才能在Praise表内添加点赞数据对其点赞,并在Post表中点赞计数+1;
但是这个过程是异步的,同时操作多次的时候会导致重复+1.
点赞的实现是否有什么比较好的方式?
2.帖子列表中获取是否点赞
获取帖子列表的时候需要同时获取本人是否对其点赞过,貌似没有比较好的实现方式,只能遍历帖子,每个帖子再做一次查询?这样获取一次帖子列表岂不是得做N+1次网络请求?

ps:看到https://github.com/lzwjava/WeShare 是采用Array来保存点赞者id,如果这样做的话,点赞者数量很大的时候会不会有问题?我的理解Array应该是用来存放比较有限数量的数据比较合适吧?点赞者的数量是有可能达到较大的量级的..

Array +1

量级大的话可以考虑 redis

帖子列表中要判断用户是否点赞,用array能实现吗?
是不是获取完帖子列表后,要遍历帖子一个个去获取...

直接存成 Post 的一个字段。

判断是否点赞可以在客户端做,如果 Array 太大的话,也可以使用 LeanEngine34 在服务端判断好再返回 Post。

那请问下LeanEngine调用是直接操作数据库,还是一样通过调用网络请求,?

不是这个意思,LeanEngine 的作用是在服务端处理数据。

举个例子,我直接用一个 Array 保存点赞的 id,那么获取到的一个 Post 是这样的

{
  "id": "34523462346",
  "content": "x",
  "likes": ["zhang3", "li4", "li5", ... "li10086"]
}

这个直接传给客户端就太大了,可以在云引擎里定义一个函数,请求这个函数的时候会先拿到这个 Post,然后看当前用户是否 like 了该 Post,最后返回的 Post 是这样的

{
  "id": "34523462346",
  "content": "x",
  "liked": true
}

感谢耐心的回复.
LeanEngine是云端的引擎这点我是知道的,其实我是想知道代码在云端执行的时候,操作数据调用的是javaScript SDK的API,这时他的底层是不是跟前端一样通过网络请求来访问数据?
代码在云端执行,数据库也在云端,那么他们为什么还要通过网络请求来操作呢?

是一样的 因为 rest api 是我们后端唯一的接口,任何的操作包括 sdk 最终都是通过 rest api 完成的。

点赞功能我也有点困扰。如果用云引擎返回数据,缓存就不好做了吧

如果要显示点赞用户列表 array 没法分页 和根据点赞时间排序吧

如果有分页与排序需求,建议单独存成 Like 表。

恩 单独一个表就是有一个问题 列表中判断当前用户是否点赞...并且不是每个post请求一个API去判断

1 人赞了这个帖子.

可以找我们给 Like 表添加联合唯一索引,然后在 Like 的 afterSave hook 里给 Post +1

把 Like 信息冗余到 Post 里,Post 保存一份「likedUsers」数组,新增 Like 记录的时候同时往 Post 更新这个数组。

cc @z11

哦 知道了,谢谢 ghost

谢谢,这个方法前期是可以的
不过还有个疑问,一个 明星的动态列表 往往每个动态都是几百个点赞 甚至几千个点赞
这种情况 请问是怎么实现的?

Like 表用于在 Post 详情页(分页、排序地)显示点赞列表。

Post 的 likedUsers 与 likedUsersNumber 数据是冗余的,用于在 Post 列表页显示数据,这部分数据不需要完整,比如 likedUsers 只需要保存最近的 20 个就够了。

此外,还可以使用我们的 LeanCache redis 服务,来保存 Post 完整的 likedUsers 数据。

按照目前的方案数据存储两个地方
like表数据用来显示
array数据用来判断 一个列表 当前用户是否点赞 便利循环array里面是否存在当前用户id
这样的便利数据在 明星列表中的动态就不行了吧,因为每个动态的array 数据是巨大的

显示没有问题,现在的疑问就一个...

就在 array数据巨大的时候 ,一个列表中如何判断 哪些动态点赞哪些没点赞

判断 一个列表 当前用户是否点赞

这个需求可以构建一个 Like 查询,user == currentUser && post in postList。

如果索引合适,这个查询成本不高。

这样还是一个列表每一条数据都请求API了哦