朋友圈设计

时间 2019-12-07

标签朋友设计繁體版

原文原文链接

在社交软件中，朋友圈（社交圈）的功能逐渐出如今各个项目经理的案板上，本文将从技术的角度介绍，如何实现一个相似微信的朋友圈功能。数据库

朋友圈的功能点

首先看看，朋友圈要实现的基本功能点，有请截图：缓存

能够发现主要包含：服务器

主题内容，具备各类类型的内容，如文本，图片，小视频，软文...微信
点赞信息，按照时间排序的用户信息网络
评论信息，按照时间排序的文本评论，或许之后会衍生出图片评论。分布式
离线同步，不知道你们有没有发现，不管是发布主题，发布点赞，发布评论，都支持离线同步的功能。在断网的状况下，依旧能够进行发布说说。这个功能极大的优化了用户体验。优化
离线缓存，在断网的状况下，依旧能查看过去的说说内容。.net
增量更新，在使用朋友圈的过程当中，对比同类型的APP，微信朋友圈的流量消耗是很是小的。线程
及时通知，包括了好友发表的说说显示小红点，他人回复的评论和点赞消息，都能及时的通知用户。设计

能够发现，这些4-7这些都是在以前QQ空间中没有发现的优势，增强了用户体验，以及适应移动环境下，低流量，网络不稳定的特色。

能够发现，微信朋友圈在不断的升级过程当中，不断引入了新的主题类型，而这主要是依赖良好的兼容性设计。具体能够参考App兼容性设计这篇文章。我的猜想就是使用TYPE字段进行向下兼容。

离线同步的功能可谓是为移动环境量身定作的功能，极大的增强了用户体验。可是想要比较完美的实现这个功能，也是很是考验软件开发人员的。离线同步，基本实现的原理图：

其基本方法就是日志先行原则：把全部的操做，先写入本地数据库中，而后后台不断的进行同步到服务器。日志先行原则在分布式系统设计中，会常常被用到，它是分布式事务补偿（RETRY）的一种通用方法。

经过离线缓存，能够作到在断网的状况下，依旧能够查看朋友圈，而且，能够采用增量更新的方式，在刷朋友圈的时候进行低流量的同步服务器的说说到本地。

增量更新通俗的讲就是把旧的数据和新的变化数据合并，造成最新的数据。

增量更新实现的两种方式：

采用日志版本号：则每次提交都会生成一个版本号，更新的时候，客户端拿着Old Version去服务器对比，服务器将Newest Version返回给客户端。而后进行for 循环升级便可。这种方式，比较适合须要追踪每次变化的业务场景，如SVN，GIT。
采用最后修改时间：对增量更新的目标，添加最后修改时间的属性（MT），客户端在更新的时候，拿着本地的MT和服务器的MT对比，而后判断目标是否须要更新便可。这种方式，就比较适合不须要追踪变化过程的场景，如朋友圈。可是须要注意，这个颗粒度须要选择合适。

增量更新的颗粒度：

颗粒度值得是增量更新的目标单位，好比说，一个文件，一个数据库，一条说说。选择合适的颗粒度是很是重要的。颗粒度太大会致使增量更新没有意义，过小会致使增量更新须要考虑的因素过多。 而在朋友圈中，选择颗粒度就是一条说说了。

结合离线同步，离线缓存，以及增量更新中的各个要点，咱们设计出以下的基本流程结构：

在发布阶段，须要先把发布的内容（说说，点赞，评论）写入操做日志中，而后Notify SYNC 线程进行同步。

发布遇到的问题和解决方法：

发布-Request异常：只须要等待网络恢复正常，再次发布便可。
发布-Resonse异常：此时服务器已经写入了发布的具体内容，而APP端不知道，根据BASE思想，采用最终一致的方法，咱们采用UUID做为内容的ID，只须要网络恢复正常的时候RETRY，服务器发现该ID的内容已经存在，则直接返回OK便可。

而读取数据阶段，咱们须要考虑合并日志和班级圈缓存，造成最终的数据。由于咱们设计中，缓存数据就是合并了日志操做的缓存，因此只用直接读取就能够了。

刷朋友圈

在刷朋友圈的时候有两种状况：

此时，咱们能够利用好离线缓存数据，提取离线缓存的ID+CT（建立时间）+MT（最后修改时间）进行查询，服务器进行查询后，若是发现服务器的MT时间大于APP的缓存，则返回增量更新的内容，且大体有三种状态：

同步的时候，建议采用指示缓存数据信息数量=须要展现的数据数量+5 ，避免由于DELETE，从而致使服务器返回的数据（CREATE）中包含了APP端已经缓存的数据。

反穿

从服务器过来的数据，须要反穿过操做日志，才能造成正确的显示数据。反穿图解:

反穿的基本要求就是须要保证同步过来的数据和操做日志保持合并后，能保持最终一致。

对于一些他人评论的消息，或者点赞信息，须要及时的推送给用户，因此咱们还须要设计推送协议，将一些及时消息推送给用户。

在移动环境中，网络异常和省流量是很是重要的，一个好的社交圈设计，须要考虑到这两点。而微信朋友圈无异于创造了先河。