|
精华帖 (0) :: 良好帖 (3) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-03-10
抛出异常的爱 写道 myreligion 写道 抛出异常的爱 写道 ray_linn 写道 说句不客气的，微博就是垃圾堆，而数据库不是存垃圾的地方，所以是垃圾的东西就不需要用数据库，只需要回到本来面目---文本格式就可以。
用户----我关注的用户，是个一对多的关系。这种connection不是垃圾，可以放数据库里。 每个用户有自己独立的folder(以ID code为名），自己发表的垃圾，就堆在这个folder里，当场就生成静态html。 然后一个用户登录了，就到自己关注的用户的folder里东读一点西读一点，其实都是静态HTML，你要觉得硬盘IO太多，也不妨放个memcache，不放，也不见得会怎么样。 至于这些文本怎么删除，其实只要跟踪一下用户登录就可以，还登录的用户是hot user，他们的内容可以keep住，不是hot user的，folder就可以由后台清空了 如果有新的微博是否需要f5来刷新? 如果非f5刷新那怎么通知到? 靠对所有跟随者广播么? 如果广播那怎么知道我的跟随者是否在线?(非在线不通知) 如果收到了广播通知如何通知浏览器F5刷新页面? 如果刷新页面时是把所有新消息都刷出来还是只刷出来刚刚广播的消息? 以上求解惑 @ray_linn说的很有道理，垃圾信息回归垃圾模式处理就行了，呵呵。 对于刷新，我觉得应该是ajax模式。对于主贴上第三版设计，页面打开时会同时在js中记录下偏移量，然后定期的或者像gmail那样保持长连接的去查询。当服务器发现偏移量变化时，根据偏移量得到新的索引数据，把新的消息发送给客户端，然后更新客户端中偏移量的值到最新值。 对于分布式文件系统模式，吞吐量肯定是非常庞大的，不会有网络400M之类的流量限制，很多设计可以简单很多。 上面提到的客户端可以是浏览器，也可以是手机客户端之类的。应该都可以。 我猜是这样～～ ajax memcache等高深词汇对于 几百人同时在线可以完成的不错..... 400M流量....有时还要再想想..... 你说过的长连接很有意思 能细说说怎么用么 长连接好像有个名词是comet |
| 返回顶楼 | |
|
发表时间：2011-03-10
最后修改：2011-03-10
myreligion 写道 长连接好像有个名词是comet comet不是万能狗皮膏药。众所周知，http之所以设计成短连接，就是为了能够服务尽量多的客户。（下一个网页你都要看半天）。 轮询的方式也未必就差到哪里去，polling 还是 comet 还是piggypolling，这只是个小策略问题。 单从 io的效率来看，文本文件效率永远高于NOSQL和SQL |
| 返回顶楼 | |
|
发表时间：2011-03-10
最后修改：2011-03-10
ray_linn 写道 myreligion 写道 长连接好像有个名词是comet comet不是万能狗皮膏药。众所周知，http之所以设计成短连接，就是为了能够服务尽量多的客户。（下一个网页你都要看半天）。 轮询的方式也未必就差到哪里去，polling 还是 comet 还是piggypolling，这只是个小策略问题。 单从 io的效率来看，文本文件效率永远高于NOSQL和SQL 我一直以为是由于以前的io没有nio那么多连接可用..... 减少请求再减少请求 可能是这种密集web2.0的技术难点 分析统计等功能会渐渐分散到个人并由人肉智能代替. |
| 返回顶楼 | |
|
发表时间：2011-03-10
抛出异常的爱 写道 ray_linn 写道 myreligion 写道 长连接好像有个名词是comet comet不是万能狗皮膏药。众所周知，http之所以设计成短连接，就是为了能够服务尽量多的客户。（下一个网页你都要看半天）。 轮询的方式也未必就差到哪里去，polling 还是 comet 还是piggypolling，这只是个小策略问题。 单从 io的效率来看，文本文件效率永远高于NOSQL和SQL 我一直以为是由于以前的io没有nio那么多连接可用..... 减少请求再减少请求 可能是这种密集web2.0的技术难点 分析统计等功能会渐渐分散到个人并由人肉智能代替. 分析统计等功能会渐渐分散到个人并由人肉智能代替。深有体会。 |
| 返回顶楼 | |
|
发表时间：2011-03-10
额，俺做一个问答网站的时候新鲜事推送方式类似于楼主的方案一。
|
| 返回顶楼 | |
|
发表时间：2011-03-10
每个消息的制造者创建一个消息实体到数据库，后台有线程程序分析消息制造者的这个动作并将消息实体的主键分发给各个消费者，我们定义给每个消费者展示多少条feed，在这个线程分发的同时我们会同时更新每个用户的两个缓存消息列表，我们给每个用户创建两个缓存消息列表，一个是需要展示的全部消息列表，一个是实时的消息列表【该列表读取后被清空，用户自己刷新时也会清空】
我们以前是这么干的，感觉跟楼主说的方案一类似^_^ |
| 返回顶楼 | |
|
发表时间：2011-03-10
完了 这个贴我没话语权 么搞过。。。
|
| 返回顶楼 | |
|
发表时间：2011-03-11
觉得他们处理方式会比较特殊，以他们的设计风格来看，比较倾向于系统，不会是一般常规的处理方法。
就像Memcachedb也是他们自己搞的，还有LVS当时也是新浪的章博士搞出来的 也许又发明了什么系统呢 |
| 返回顶楼 | |
|
发表时间：2011-03-11
最后修改：2011-03-11
vtrtbb 写道 觉得他们处理方式会比较特殊，以他们的设计风格来看，比较倾向于系统，不会是一般常规的处理方法。
就像Memcachedb也是他们自己搞的，还有LVS当时也是新浪的章博士搞出来的 也许又发明了什么系统呢 你觉得互联网的微薄和当初的火鸟BBS有什么区别，无非就是垃圾信息更多了些。如果按我的方案，memcached基本都是靠边站的，要增强的反而是http server自身的cache. 真的要设计，我会把每条信息存成XML格式，其文件名对Browser缓存友好，不使用任何Memcached来缓存静态页面，所有页面由XSLT和javascript在客户端生成。 所以在Web server的cache上动点功夫，减少磁盘io |
| 返回顶楼 | |
|
发表时间：2011-03-18
myreligion 写道 NanguoCoffee 写道 http://www.slideshare.net/iso1600/cache-4842490
刚看了一遍，这些东西有什么看的，是个人都知道，从JLive的论坛年代就开始了id cache。关键是怎么落地。我觉得这个ppt并不比我提出的这个分布式文件系统的方案更有参考价值和讨论价值。 这位老兄的口气挺大的，我看新浪这套方案就挺好的。 比如说您也拿出你的建构方案，跟他比比，让我们无地自容一下，期待。 |
| 返回顶楼 | |
