对于社交类APP开发后台架构怎样搭建？
社交App最常见的场景是类似于微博的场景，用户与用户之间有关注和粉丝这两种关系，一个用户发表了内容，关注了该用户的用户在个人主页上都能收到最新的动态。社交的核心功能是Feed。Feed是指用户通过关注功能，聚合了被关注用户的最新的内容（同时也包括了自己的内容）以供自己浏览的信息服务。按发表的时间顺序把关注的用户的内容展现出来。深圳APP开发公司资深程序员根据多年的开发经验整理总结下面4个方面描述Feed的架构。
·基本表结构
·推拉模式
·数据库架构
·缓存架构
社交APP开发经验之基本表结构
常用的Feed架构是把数据存储在MySQL，热点数据（一般来说是最近3天的数据）存储在缓存(常见的缓存系统有Redis和Memcached，微博是使用Memcached)，务必让绝大多数请求通过缓存直接返回(例如微博要求核心缓存命中率要达到99%)，只有少量的请求穿透缓存落到数据库。
在最简单的Feed架构中，MySQL有下面的4张基本表
．send coutent:发送内容表，存储用户发表的内容，表结构如表9-1所示
．revelve content:接收内容表，用于推模式（推模式的描述请看下节）时存储用户接收的内容，表结构如表9-2所示。
社交APP开发后台管理结构表示意表9-2reveive_content接收内容表
另外，在社交App还需要下面两张表存储用户和用户之间的关系。
·followings:关注表，存储用户关注的人，表结构如表9-3所示：
社交APP开发关注表9-3 followings关注表
·followers:粉丝表，存储用户的粉丝，表结构如表9-4所示：
社交APP开发方法示意图表9-4followerS粉丝表
社交APP开发模式之推拉模式
用户发表内容后，后台通过定的方式把获取数据展示到该用户的粉丝主页，常用的两种方式是推模式和拉模式：
1．推模式
平常邮箱中收件箱和发件箱的作用如下
·发件箱：存储用户发送的邮件。
·收件箱：存储用户收到的邮件。
推模式的数据库设计也有收件箱和发件箱类似的概念，发件箱对应表9-1“send content发送内容表”，收件箱对应表9-2“revelve content接收内容表”。
推模式下用户发表条内容的流程如下：
(1) id为l用户发表条内容为“蓝蓝的天空”信息
(2)这条内容写入发送内容表“send content”后内容如下
(3)在粉丝表“followers”查找id为1用户的粉丝，粉丝表“followers”的内容如下。
从粉丝表可知，id为l用户的粉丝是id为2的用户。
(4)因为id为2的用户的feed中需要显示这条内容，因此把内容写入接收内容表“revelve content”，写入后接收内容表“revelve content”内容如下。
(5)bid为2的用户显示Feed时，通过SQL语句“select*from reveive-content where revcive-id=2”就能查询该用户显示的数据。从推模式的流程可看出，推模式使用了空间换时间的策略，查找Feed中需要显示的内容很简单，只需要条SQL语句就行同样推模式的缺点也很明显，如下所示：
·同时推给多人（例如上十万人）不但延时严重，而且浪费存储空间。
·变更操作的成本而，如果某个用户删了一条内容，要同时把“send_content”表和“revelve content”表中的数据删除。
2．拉模式
拉模式下用户发表条内容的流程如下。
(1) id为1用户发表了条内容，内容为“蓝蓝的天空”。
(2)这条内容写入发送内容表“send content”，写入后发送内容表“send content”内容如下。
(3)当id为2的用户显示Feed时，在关注表“followings”查找id为2所关注的用户，关注表的内容如下。
从关注表“followiug_id“可知．id为2的用户关注了id为l的用户，因此需要获取id为l的用户发表的内容。
（4）id为2的用户通过SQL语句“select*from send-content where author-id in （1）”查询所需要显示的内容。
由上述流程可知，拉模式采用了时间换空间的策略，用户推送内容时效率很高，但当用户显示Feed时，需要花大量的时间在聚合运算上。
APP开发公司关于推拉模式的总结
推模式和拉模式的特点总结如下。
好了，APP开发公司本文关于社交APP制作接本结构表与模式的方法就分享到这里，希望本站此类型的文章对您的工作有所帮助，谢谢关注，博纳网络编辑整理。
