专业app开发公司：讲解社交app后台架构
社交app最常见的场景是类似于微博的场景，用户与用户之间有关注和粉丝这两种关系，一个用户发表了内容，关注了该用户的用户在个人主页上都能收到最新的动态。
社交的核心功能是Feed。Feed是指用户通过关注功能，聚集了被关注用户的最新的内容（同时包括了自己的内容）以供自己浏览的信息服务。
Feed的界面按发表的时间循序把关注的用户的内容展现出来。
下面专业网站建设公司深圳市博纳网络信息技术有限公司讲解从4个方面描述feed的架构。
1.基本表结构
2.推拉模式
3.数据库架构
4.缓存架构
常见的FeedJI架构是把数据存储在mysql，储存在缓存（常见的缓存系统有redis和memcached，微博是使用memcached），务必让绝大多数请求通过缓存直接返回，只有少量的请求穿透缓存落到数据库。
在最简单的feed架构中，mysql有下面4张基本表。
.send-content：发送内容表，存储用户发表的内容。
.reveive-content：接收内容表，用于推模式时存储用户接收的内容。
另外，在社交app还需要下面两张表存储用户和用户之间的关系。
followings：关注表，存储用户关注的人。
followers：粉丝表，存储用户的粉丝。
推拉模式
用户发表内容后，后台通过一定的方式把获取数据展示到该用户的粉丝主页，常用的两种方式是推模式和拉模式。
推模式
平常邮箱中发件箱和发件箱的作用。
推模式的数据库设计也有收件箱和发件箱类似的概念，
同样推模式的缺点也很明显：
同时推给多人不但延时严重，而且浪费存储空间。
变更操作的成本高，如果某个用户删了一条内容，就用时把“send-content”表和“reveive-content”表中的数据删除。
拉模式
拉模式最低的问题是大量的聚合运算，请求的响应时间可能较长，可以通过缓存策略让大部分的请求的响应时间能达到2到3毫秒。
以上是专业app网站建设公司讲解的社交app后台架构，更多网站建设app开发知识关注深圳市博纳网络官网www.198bona.com
www.sabong.net
联 系 人：陈先生
联系地址：深圳
