接上一篇，我们有了好友关系之后，就又涉及到了怎么样处理“只能看到好友的动态，和好友在好友动态下的评论）
其实关于获取好友状态，已经不成问题，从数据库中读取出来就行了，最后统一出一个好友列表，然后进行查询就行了。关键的地方在于这个好友动态的排序以及评论呈现。
1、关于评论和动态的获取
我们采取的方式是：后端返回全部动态，前端进行排序。这样的好处是大幅减小了后端的压力，因为如果不这样，后端得依次进行如下操作：
获取当前用户 -> 获取用户的好友列表 -> 对每个用户的好友选择出所有动态 -> 对所有好友选择出来的动态进行排序 -> 对最后结果只返回前n个（后续的再次发送请求获取）
这样的方式对于小型服务器来说是致命的，举个例子，1个人有50个好友，每个好友20个动态，每个动态5条好友评论，光是获取所有好友动态就必须查询50205=5000条记录，然后还要对这5000条记录进行排序，最后选择出指定100条。这中间还没有包括根据好友进行评论过滤，匿名信息的转换之类的过程，可想而知，一旦大量用户登录查看动态，服务器将压力非常大。
因此，我们将排序做到了前端，后台在进行查询的时候，查询的时候只查询到动态层面，评论在用户点击指定动态之后才会获取，将一步的动作分成两步，用户在下拉浏览的同时发送新的获取评论请求，服务器再返回指定动态的评论，这样就将5000化为5020+n5,n为每页显示的动态数，大大减缓了服务器的压力。同时，通过缓存技术比如Memcached，保存用户的好友动态，防止用户首页快速刷新造成大量的请求。
2、关于评论的呈现
仔细一想，评论其实满足了一种树形结构，因为我不但可以评论这条动态，也可以评论之前的评论，所以，在存储评论的时候，我们可以加入一个parentID，再配合messageID（根节点，动态的ID），就可以进行前端的评论的树形结构生成，大概的数据表就是这样：
这样，基本的功能就完成了，其实现在想想都是很简单的设计，只不过以前并没有做过和思考，导致当时开发遇到了一点点小问题－ －～
就到这里吧，最后再次广告：github：https://github.com/lizhuoli1126/FriendCircle