SNS广播的问题
广播的问题
* 快速有效跟踪友邻动态
* 最近的动态，而非所有动态
* 合并重复信息
* 减少刷屏的影响
通常lifestream解决方案
twitter的方式
Twitter is, fundamentally, a messaging system.
整个系统的后台是一个巨大的异步消息队列，每条广播被放大N倍发送出去，N为你的follower.
谁在这么做？
twitter/xiaonei(?)/联络家/
twitter方案
优点：
1. 查看一个人关注的所有广播时，只有单个数据源
2. 可以删掉自己不想看的广播（校内）
3. 逻辑简单，只会看到关注后对方的广播（twitter）
4. 可以发送私信（只发给一个人）
缺点：
1. 延迟，联络家那边说会有分钟级别的延迟
2. 发送出去的消息没办法清除掉
3. 如果sns不够活跃，会有大量的无用功
通常lifestream解决方案
minifeed的方式
每个用户维护自己的feed列表，当需要显示自己关注的所有的feed时，从多个feed处拿到数据并merge.
谁在这么做？
douban/51/friendfeed/facebook(?)
minifeed的方式
优点：
1. 相应快，发出广播后友邻实时看到
2. 自己可以删除自己的单条广播
3. 对于cache的利用率高，每条广播在系统中都只有一条
4. 添加了一个友邻后马上能够看到他以前的广播
缺点：
1. 查看关注的广播时，需要通过cache/db取得多份数据，可能导致大量的cache/db访问。
2. 不便于发给单个人的广播 （暂时我们没有需求）
广播的类型
1. 收藏
2. 评论
3. 日记
4. 相册
5. 推荐
6. 我说
7. 小组
8. 讨论
9. 友邻
10. .....................
广播隐私
* 收藏/小组/友邻/活动隐私：
要不全部能看，要不全部都不能看到，采用bits控制
过滤时根据bits的值决定时候否显示这一大类的广播
* 日记/相册/推荐隐私
允许单条设置隐私，采用bits+type控制。“广播隐私设置”设置是否放入广播，再根据日记/相册/推荐的隐私设置决定type.
过滤时需要逐条检查type.
豆瓣的广播实现
* 所有的数据在miniblog表，id号递增，时间排序容易
* 对于每个人，在memcache中维护他最近1个礼拜的广播（id，type) 列表（合并/过滤都在这个列表上进行）
* 当需要查看1个礼拜前的广播时，直接查db
* 单条广播在memcache中单独为一个key
* 查看友邻广播时，首先拿到所有友邻的广播(id,type)列表，按id排序合并，去掉不能看到的type,然后过滤，合并。
广播合并
以天 为单位合并广播
* 同种action的合并（同看了一本书，同加入了一个小组）
* 同一个人的同种行为合并（消除刷屏的危险）
o 合并一个人当天所有的同类型行为（收藏，照片）
o 合并一个人连续的同类型行为（推荐）
不同的页面 首页／友邻广播／个人广播， 采用不同的合并策略