z**********g
发帖数: 209 | 1 见过好几次了，也算高频题，但是没有一点clue。
有大侠讨论讨论一下吗？ |
w****x
发帖数: 2483 | |
z**********g
发帖数: 209 | |
q****s
发帖数: 1658 | 4 这也算open question吧 应该是没有唯一答案的 |
l*****a
发帖数: 14598 | 5 详细说下需求，好不？
【在 z**********g 的大作中提到】
: 见过好几次了，也算高频题，但是没有一点clue。
: 有大侠讨论讨论一下吗？
|
g*********e
发帖数: 14401 | 6 每个用户有一个Like list，存储ID
每个like有global count， 以及ID
每当有人Like/dislike一次，+/-count 这需要分布式处理
当当前页面有like buttom时，根据ID寻找朋友的Likelist中是否存在这个ID |
z**********g
发帖数: 209 | 7 每当有人Like/dislike一次，+/-count 这需要分布式处理
没想明白为什么要分布式处理？ |
z**********g
发帖数: 209 | 8 我说一下自己的想法：
每个like有一个list, 然后如果有人点击like，就会把自己加入list。
每个Person有一个list,点击时会把like加入list。
只想到这么多了。我没看到有dislike的button。 |
z**********g
发帖数: 209 | |
n****e
发帖数: 678 | 10 当然有unlike的button
感觉 还是每个人一个list的比较efficient
一个like有一个list， 可能不太efficient， 有些东西like的人很多 （> 100M）
比较支持glowinglake的做法
【在 z**********g 的大作中提到】
: 我说一下自己的想法：
: 每个like有一个list, 然后如果有人点击like，就会把自己加入list。
: 每个Person有一个list,点击时会把like加入list。
: 只想到这么多了。我没看到有dislike的button。
|
z**********g
发帖数: 209 | 11
根据glowinglake，
每当有人Like/dislike一次，+/-count 这需要分布式处理
我没想明白为什么要分布式处理？
【在 n****e 的大作中提到】
: 当然有unlike的button
: 感觉 还是每个人一个list的比较efficient
: 一个like有一个list， 可能不太efficient， 有些东西like的人很多 （> 100M）
: 比较支持glowinglake的做法
|
n****e
发帖数: 678 | 12 可能是map reduce之类的吧
【在 z**********g 的大作中提到】
:
: 根据glowinglake，
: 每当有人Like/dislike一次，+/-count 这需要分布式处理
: 我没想明白为什么要分布式处理？
|
n****e
发帖数: 678 | 13 多个人对一个item 进行 like/dislike 有点像map reduce的感觉
【在 n****e 的大作中提到】
: 可能是map reduce之类的吧
|
