|
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-01-17
bluemeteor 写道 以前朋友做社区的时候我们讨论过一个方案，分享一下
先说一下背景，由于当时的情况是数据库必须采用sqlserver2k（政治原因），而团队中对sqlserver2k优化都没有什么信心，但是WEB层的架构都是团队定的，所以尽量把业务实现和性能解决方案的重心偏移DB，避免SQL，这是出发点 所有的好友状态和最新行为都是通过物理文件来保存的，实时的操作是memcache来保存。 通过apache或者Light HTTPd 建立 resource服务器，每次用户执行操作后会重写/userid/his/xxx.js，这样用户的好友登陆后首先加载好友列表，然后在页面中分别加载好友相应的js来实现最近操作记录。同时还有类似javaeye的"我在看帖子"这种实时状态，是通过memcache来实现的。 这个方案提供了很好的扩展性，可以通过优化linux来实现非常好的性能，但是，安全性是个问题，最辛酸的是，辛辛苦苦做完，项目被毙了…… 那就是说这个方案还没有得到实践的检验 |
| 返回顶楼 | |
|
发表时间：2009-01-17
瀚 愚 写道 bluemeteor 写道 以前朋友做社区的时候我们讨论过一个方案，分享一下
先说一下背景，由于当时的情况是数据库必须采用sqlserver2k（政治原因），而团队中对sqlserver2k优化都没有什么信心，但是WEB层的架构都是团队定的，所以尽量把业务实现和性能解决方案的重心偏移DB，避免SQL，这是出发点 所有的好友状态和最新行为都是通过物理文件来保存的，实时的操作是memcache来保存。 通过apache或者Light HTTPd 建立 resource服务器，每次用户执行操作后会重写/userid/his/xxx.js，这样用户的好友登陆后首先加载好友列表，然后在页面中分别加载好友相应的js来实现最近操作记录。同时还有类似javaeye的"我在看帖子"这种实时状态，是通过memcache来实现的。 这个方案提供了很好的扩展性，可以通过优化linux来实现非常好的性能，但是，安全性是个问题，最辛酸的是，辛辛苦苦做完，项目被毙了…… 那就是说这个方案还没有得到实践的检验 用json当初做这个功能的时候提出的一种解决方案，当然是可以实现的，而且从回复中也看到有几位朋友已经用json实现了，用json就是在页面解释重写DOM。 |
| 返回顶楼 | |
|
发表时间：2009-02-01
似乎大家都忽略一个问题，就是用户的体验。我们只站在一个技术人员的角度去考虑系统设计，这个是很致命的。每个SNS网站的用户对好友动态的关注可能都有不同的需求，这个是不能忽视的。如果单单考虑最基本的数据存储格式，建议参考UCH。其他就是具体问题具体分析了。关于动态合并，建议是在显示的时候进行合并。
|
| 返回顶楼 | |
|
发表时间：2009-02-19
bluemeteor 写道 以前朋友做社区的时候我们讨论过一个方案，分享一下
先说一下背景，由于当时的情况是数据库必须采用sqlserver2k（政治原因），而团队中对sqlserver2k优化都没有什么信心，但是WEB层的架构都是团队定的，所以尽量把业务实现和性能解决方案的重心偏移DB，避免SQL，这是出发点 所有的好友状态和最新行为都是通过物理文件来保存的，实时的操作是memcache来保存。 通过apache或者Light HTTPd 建立 resource服务器，每次用户执行操作后会重写/userid/his/xxx.js，这样用户的好友登陆后首先加载好友列表，然后在页面中分别加载好友相应的js来实现最近操作记录。同时还有类似javaeye的"我在看帖子"这种实时状态，是通过memcache来实现的。 这个方案提供了很好的扩展性，可以通过优化linux来实现非常好的性能，但是，安全性是个问题，最辛酸的是，辛辛苦苦做完，项目被毙了…… 动态信息这个问题关键的是要解决写的问题. 你作成静态文件只能解决读取的速度. 我的想法是 每个在线用户维持一个好友动态队列Q(长度20).每个数据项包括:发送者ID,发送时间,类型,T表主键. 用户生成一个动态信息则记录到数据库动态信息表T中. 并且更新在线好友的好友动态队列Q. 用户上线则从数据库动态信息表T中初始化好友动态队列Q. 同时每过段时间持久化在线用户的好友动态队列.用来防止系统崩溃. |
| 返回顶楼 | |
|
发表时间：2009-02-19
我觉得怎么样设计动态显示并不是关键点与难点，可取的无非两种：一种是表关联、一种是直接动作分配到好友，当好友登录时直接SELECT查询。
关键是如何来设计规则：也是分两种，一种是信息发送者制定的规则、一种是信息收取者制定的规则。 |
| 返回顶楼 | |
|
发表时间：2009-02-26
单纯从技术来讲，日志我看是最简单方便的实现方式
|
| 返回顶楼 | |
|
发表时间：2009-03-08
1.每一条动态信息存为一条记录。 2.每条信息对相关好友都新增一条记录信息，仅记录id，时间等关键信息，具体内容到动态表中查询。 3.只保留最近一段时间的动态，定期删除。 用户量大的情况下，则需要考虑用户信息分库存储，则推送规则需要进行一些调整。 |
| 返回顶楼 | |
