这是一个创建于 3384 天前的主题，其中的信息可能已经有所发展或是发生改变。
类似 微信朋友圈，微博。
你发送一条消息，那么意味这 这条消息要出现在你所有的好友的时间轴里面， 简单复制过去是可以的，但是意味着消息被复制了几百次， 资源消耗很大。 复制一个id过去，又会有热点问题。
简单的来说 就是push 和 pull. 我觉得主动推，复制全文方案更好。 但是不知道 这里有大牛有更巧妙的方案吗？
你发送一条消息，那么意味这 这条消息要出现在你所有的好友的时间轴里面， 简单复制过去是可以的，但是意味着消息被复制了几百次， 资源消耗很大。 复制一个id过去，又会有热点问题。
简单的来说 就是push 和 pull. 我觉得主动推，复制全文方案更好。 但是不知道 这里有大牛有更巧妙的方案吗？
 |
1
celon 2015-08-04 18:41:57 +08:00 via iPhone
我的想法是
复制id，缓存最近一段时间的内容 |
 |
2
Yinz 2015-08-04 18:55:21 +08:00
复制id的热点问题是什么问题，了解一下
|
 |
3
lean 2015-08-04 19:03:16 +08:00 via Android
我感觉和共同协作文档类似
|
 |
4
taowen 2015-08-04 19:24:27 +08:00 via Android
|
 |
5
wkdhf233 2015-08-04 19:29:06 +08:00
= =打开朋友圈的时候获取所有好友最近发的按时间戳排个序？
|
 |
6
codeyung 2015-08-04 20:18:31 +08:00
貌似时间戳之前 不显示 只显示时间戳之后滴
|
 |
7
a591826944 2015-08-04 20:22:12 +08:00
mark 关注下。。
|
 |
8
alex321 2015-08-04 20:36:27 +08:00  3
简单地说，有个在内存中的时间轴(key)队列维护着所有的动态索引(value)，然后，所有的动态内容同样维护在一个内存中的异常庞大的队列对象里，这个对象你可以隔几个星期或者隔几天或者隔几个小时写到后端缓存或者更加后端的数据库里头。队列中尽可能保持一周内的动态，缓存中维持大概一两三个月就差不多了。
然后，针对某个用户，按照索引去队列中拿他的好友的动态。一周内的动态都在内存中，很顺畅，然后，当拿到快接近一周的尾巴的时候，后端程序预估可能要先去后端缓存取额外的动态数据了。这个过程几乎是在用户查看的时候，后端程序就能够做完的。然后，就没有然后了。 要注意的是，上面的时间周期视应用情景决定，架构层级什么的也视应用承载的动态数量可能要做调整。 |
 |
9
outfocontrol 2015-08-04 20:41:22 +08:00
今年ArchSummit深圳场讲过微信朋友圈的做法，ppt： http://pan.baidu.com/s/1sjA4Xq9
|
|
10
outfocontrol 2015-08-04 20:43:27 +08:00 2
|
 |
11
benjiam OP @outfocontrol 这个早看过了。只看流程 那么push 就可以了。 但是考虑到几百个好友的情况，其实效率很低。 最后 他的同步算法，我觉得是有问题的，最极端的情况， 3个集群都可能产生冲突。
|
 |
12
imn1 2015-08-04 20:52:43 +08:00
服务器不保存信息的话，确实是 LZ 所说那样
服务器保存信息的话，就如 LS 各位所说 那问题来了，到底是希望还是不希望服务器保存呢？ 简单地说，保存就必然不是私密了 |
 |
13
akira 2015-08-04 21:01:44 +08:00
参考推特的时间轴实现方案
|
|
14
outfocontrol 2015-08-04 21:08:44 +08:00
＠benjiam 还是得看应用场景，朋友圈请求量最多的应该是拉个人的时间轴数据，事先建好时间轴索引取数据就快很多了，而且更新时间轴是朋友有动态才去更新的。同步问题肯定是有的，这种做法很大程度看KV的实现如何，KV高效的话效率应该不会低，微信这么大的访问量都这么做了。
|
|
15
benjiam OP @outfocontrol 你并不知道 具体的实现过程，从外面看流程是很简单的。微信的系统是多IDC的，每个IDC的数据是独立，但是可以相互merge。 每个用户最多5000个好友。只是实现不难， 高效的话，就不好说了。
|
 |
17
pixstone 2015-08-05 03:11:38 +08:00
@benjiam 微信好像 有朋友数量上限，然后Push几百人的话，应该是 MQ 之类的推送 ID。然后把 ID 加入个人时间轴，至于数据热点的话，这个 ID 对象本身内容，可以通过基础的跨机房通信渠道同步推送 什么的。
至于微博那样的几万粉丝用户的话，就是采用 pull 了。本身在关注操作的时候就有区分数据获取方式了。 朋友数量大于一定的用户（这部分用户总数并不会很大，参考 28 原则 ）的更新就只提交到公告板类似的区域。其他用户获取新时间轴的时候去这个公告板获取数据来填充自己的时间轴。 |
 |
18
tshwangq 2015-08-05 18:00:44 +08:00
时间轴 push和pull两种模型。 像sina是结合使用的。
另外还有看过一个借助图形数据库的实现： http://www.rene-pickhardt.de/time-lines-and-news-streams-neo4j-is-377-times-faster-than-mysql/ etsy团队也有一个实现。在slideshare上有分享他们的实现。值得借鉴。 |
Select Language