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 合并一个人连续的同类型行为（推荐）

 不同的页面 首页／友邻广播／个人广播， 采用不同的合并策略