App后台学习

第九章-中

社交App的架构

推拉模式’

当用户发表内容，作为关注着 需要收到消息，常用的两种方式是推拉模式

推的流程为

id为1 的我发送消息 保存到数据库

查找我的粉丝的id 然后对对各个粉丝的查看他们关注的信息的数据插入我发表了内容，采用的是一种空间换时间的方式，查找很容易，缺点在于同时推给多人，不但延时严重而且浪费储存空间。变更操作也很麻烦，如果某个用户删除一条信息，要把和这条信息想关联的也要处理

拉模式

我发表信息 存入数据库

你获取数据 通过查询我的关注的人 的id 然后查他发的内容 ，拉的方式采用时间换空间的策略

数据库框架的演变

数据库自增id

数据库自增加id 采用分表分库的问题，可能导致 多张表数据有重复的id。为了保障id的唯一性，需要一个统一发id的服务，例如每秒写入100万数据，为了区分没秒的数据，常见的是time+sequeue设计方式，设计中id长度为64位，前32位客表示数值（0-4294967295）精确到秒（用时间错描述），中间20位（可表示数据0-1048575就可以表示0-100万之间的任意整数），最后12位重复其他业务信息。

分表分库策略

常见的分表策略有两种

1。按hash拆分

2，按时间拆分

按hash拆分

将一张表的数据分不到多张表。例如内容表根分为4个表，根据分表内容的用户做id做hash运算，吧算法id%4计算改数据落在那个表上按hash拆分使用前中期使用，特在在于数据规模可控，增长速度可控，缺点在与 如果特殊用户的查询性能低，如果某些用户比较多，按照id策略找成数据集中在摸个数据表上，造成写入操作集中在某个表上。

冷热数据无法分离存取。如热点数据可以放在性能强的硬盘上 冷们数据放在读写弱的硬盘上，但是hash表无法瞒住这个需求

按时间查分

某个时间点的数据放在一个表上，不同时间端查不同时间表

综合策略

两者结合 用户发表内容 按照id取hash值到具体库中，在按时间取具体的表

在以时间查分的情况下有一个问题

如果发表的内容是以时间分表，如果我要查用户id为1000的人最近发的5条记录，视乎需要遍历所有表 导致效率过低 解决这个问题需要引入二级索引表 将用户id和用户在那个表上发的总内容数量的表

缓存的架构引进

后台使用分布式缓存后，每条缓存服务器缓存总数据的一部分，需要解决两个问题

这么确定那个数据存在那个服务器上

这么才能让数据均衡分布到缓存服务器上，避免赵成 某个数据多某个数据少

解决方案：用服务器的数量数量除以缓存数据的key的hash值，余数对应缓存服务器的下标，缺点在于当增加或减少服务器，会导致数据从储存在其他服务器上变为储存在另一个服务器上。

，在App后台开发中，大部分业务请求所需的数据都是通过缓存获取，只有少部分请求穿透到服务器上，因此数据库的负载能力按照缓存承担了大部分请求的设计情况。当缓存无法命中大量业务请求穿透到数据库，会是的业务瘫痪吗，当服务器增加的时候，整体的命中会下降，所以采用另一种方案

一致性的hash算法

通过圆环的形式组成的 例如三个服务器缓存 讲个各自的hash取出 构成一个环形 当请求过来 判断 是否在当前服务器 上如果不是顺着顺时针寻找最近的key的hash执所在的服务器上还有个问题 当增加一条服务器可能导致 原来落在服务器0上的请求有缓存服务器4和缓存服务器0共同承担，但是其他两个服务压力不变，没法充分利用每条服务器。 可以加入一个虚拟节点来处理。

如果其中一条服务器宕机了 也会造成命中率答复下降。方案 获取数据时候 先访问住缓存 当主缓冲获取失败，在访问从缓存，

当数据更新住缓存获取数据更对主缓存进行更新。更新后在更新从缓存，如果住缓存一致性更新失败 则把主缓存和从缓存删除。读取数据库后在加载到缓存中

为了保存缓存失效的问题

定期吧主缓存的数据同步到从缓存 应用层控制请求有一定概率落到从缓存上，让从缓存承担部分请求