搜索
飞信开放平台的资源分配与控制策略开放、动态网络分享、综合性网络服务October111飞信开放平台技术总监互联网产品首席架构师孙朝晖私人广告October112• 首先希望遭到关注并通过微博交流• 本人职责– “飞信开放平台”总体技术架构设计– 飞信互联网相关产品的技术规划– 飞信技术社区建设，特别欢迎与同仁广泛交流目录• 飞信开放平台的业务特点• 飞信开放平台对合作伙伴OPENAPI的资源控制• 飞信开放平台用户的服务资源分配• 飞信开放平台缓存资源分配策略October113飞信开放平台的业务特点October114• 飞信开放平台是⼀一个内容合作型的服务平台，将各种内容源聚合到飞信的Web，PC，手机，短信全客户端渠道• 合作服务类型 • 微博类 • SNS类 • 视频、文学、咨询等内容类 • 电子商务类 • ……飞信开放平台合作伙伴的数据通信方式October115• 飞信主动同步类型– 飞信利用第三方服务开放平台功能拉取TimeLine，并发布Feed（如新浪、腾讯微博）• 飞信被动同步类型– 第三方服务调用飞信开放平台API将动态主动推送到飞信开放平台上（多数互联网合作伙伴）• 双方相互同步类型– 双方相互向对方推送动态（如移动微博，开心网）• 客户端类型– 飞信以及第三方开发的PC，手机客户端，收发API据需要飞信开放平台对OPENAPI的资源分配策略October116飞信开放平台对OPENAPI的整体分配策略October117• 飞信开放平台通过基于RESTFUL的OPENAPI提供数据通信接口，根据不同的限制区域和服务级别，分成不同的服务器群集七层交换集群客户端服务群试验服务群普通服务群高级服服务群主动同步抓取服务群动态中心服务平台Push服务群飞信开放平台对API访问频次控制方法October118• 访问频次限流+按应用、IP、和用户ID的组合限流策略• 请求频次限流，限制同⼀一IP的并发连接数，防止过多的并发– 采用Nginxlimittrafficratemodule– limit_zoneone$binary_remote_addr10m;• 针对不同应用类型的制定组合资源限制策略飞信开放平台对API访问频次控制方法October119• 限流策略– 试验区应用全部采用每应用、每小时单⼀一频次限制策略– 客户端服务器集群全部采用每用户ID，每小时单⼀一频次限制策略– 对于中等规模应用（主要针对普通服务集群的Web应用），采用每IP（ServerIP）频次限制，同时每应用访问总频度设置上限– 对于大规模应用（主要针对VIP服务区的Web应用），采用用户频次限制，同时每ServerIP设置上限– 正在开发当中有每ServerIP+ClientIP频次限制，（主要应对匿名访问需求）飞信开放平台对OPENAPI频度控制的技术策略October1110• 总体策略：– 控制精确度让位于服务响应时间和服务器资源开销– 不同区域根据访问量和控制要求设计不同的控制方法• 试验区：控制精度优先– 同步控制：先检查修改计数，然后响应请求– 在Redis中采用INCRBY进行修改，定期刷新DB• 普通区– 异步控制：首先检查，返回响应，同时异步修改计数October1111• 对于VIP区域的完整异步频度控制体系飞信开放平台对OPENAPI频度控制的技术策略Web ServerAPI Server客户端1：请求API频度技术状态2：检查3：响应频次计数服务4：增加技术进程内计数缓冲5：更新频度状态持久化7：定期刷新DB 记录日志Redis缓存6：批量用户访问计数飞信开放平台对应用服务器资源分配策略October1112飞信开放平台对于Feed处理计算资源分配October1113用户通过Web或者OPEN API发布发布队列发布处理进程 （Feed内容写入）本站分发队列抓取进程外站发布队列外站发布处理进程动态分发进程Push 队列对外站Push进程外站分发队列动态分发进程动态分发进程飞信开放平台对于Feed处理计算资源分配October1114• Feed的发布与好友Timeline的分发，通过多队列计算进程进行处理，队列按处理优先级分布为– 本站发布队列（本站用户的发布内容记录以及写入Timeline）– 本站分发队列（向本站好友分发Feed）– 外站Push队列（将Feed发布到绑定的服务）– 外站Feed发布与分发队列（每服务⼀一个或者多个任务处理队列，用于来自合作伙伴的Feed转换分发）飞信开放平台对于Feed处理计算资源分配October1115• Feed发布与分发进程– 发布进程优先，优先完成内容写入– 分发只处理Timeline，Timeline索引存储按照时间分片– 优先本站内容分发• 与合作伙伴同步的进程进程的资源分配– Push进程与Fetch进程分离，Push进程无频度控制策略，优先发送– Fetch进程每服务对应1个或者多个，根据不同的用户抓取的优先级进行分级处理，Feed发布频度越高，分配进程数越多飞信开放平台内容抓取资源分配策略October1116• 按照合作伙伴业务类型分配– 微博类优先，对应在线用户队列执行频度比非微博高• 根据用户属性制定不同的抓取频度策略– 在线队列（微博类3分钟，非微博类10分钟）– 低活跃用户队列– 高活跃用户队列– 用户活跃度定期计算，非在线队列2小时进行重新划分与装载飞信开放平台用户存储资源分配October1117• 用户最新动态缓存容量分配– 除了固定的用户资料存储，为在线用户分配⼀一定数量的最新Feed存储Slot，减少DB读写– Slot数量分成3个等级，微博用户，多绑定多好友用户，低绑定用户• DB数据存储策略：– 微博类Feed与其他类分开– 微博类Feed按照时间老化– 非微博类Feed按照固定配额分配存储资源飞信开放平台缓存资源分配策略October1118飞信开放平台的缓存分配体系October1119资源缓存体系浏览器缓存CDN7层交换前部缓存图片服务器的Web应用缓存数据缓存体系浏览器本地缓存Web Server 数据缓存Redis缓存服务器中间件服务器本地缓存数据库服务器的BufferPool减少数据流量，提高Web加载速度，提升使用体验减少数据库直接读取，减少重复计算，降低计算负荷Web服务器输出缓存数据类缓存体系的总体技术架构October1120Web 服务器Redis全局缓存区浏览器本地数据缓存输出缓存ESI局部输出缓存APC ，Session 数据缓存无缓存的7层交换全局缓存 区域弱Session 区 强Session 区 中间件服务器缓存区 LRU Pool数据库的InnoDB Buffer PoolWeb服务器数据缓存October1121• APC– 存储基于Shmop– 代码缓存– 典型应用场景：全局统⼀一的不易变内容例如：全局配置（频度限制等）• Session– 本地Session仅用于保存短声明周期过程数据– 存储基于文件– 典型场景：OAuth认证过程中间TokenRedis缓存体系October1122• Redis缓存与数据区域对应，隔离影响范围，防止全面雪崩• Redis分成了三个区域• 全局区域– 特点：全局共用，对各Web，中间件Server等价，重建成本低– 典型应用：短连接的地址映射缓存– 构建方法：多Server多进程⼀一致性Hash，无Persist，无复制Redis缓存体系October1123• 弱Session区– 特点：与用户相关，要求⼀一致性低，重建成本低– 典型应用：每用户的Session典型对象：好友列表、隐私设置，50条最新动态（满足Ajax轮循加载）– 构建方法：采用多对⼀一复制方案，无永久存储Redis缓存体系October1124• 强Session区– 特点：与用户相关，要求⼀一定程度的⼀一致性，构建成本高，存储占用量不高– 典型应用：用户的在线队列，用户调整动态同步的抓取优先级– 构建方法：采用DiskStore方案，⼀一对⼀一复制，感谢！October1125