演讲者@TimYang.ppt

上传人:sccc 文档编号:5637894 上传时间:2023-08-04 格式:PPT 页数:65 大小:1.55MB
返回 下载 相关 举报
演讲者@TimYang.ppt_第1页
第1页 / 共65页
演讲者@TimYang.ppt_第2页
第2页 / 共65页
演讲者@TimYang.ppt_第3页
第3页 / 共65页
演讲者@TimYang.ppt_第4页
第4页 / 共65页
演讲者@TimYang.ppt_第5页
第5页 / 共65页
点击查看更多>>
资源描述

《演讲者@TimYang.ppt》由会员分享,可在线阅读,更多相关《演讲者@TimYang.ppt(65页珍藏版)》请在三一办公上搜索。

1、演讲者 TimYang,微博架构与平台安全,微博架构发展,新浪微博从 0 50,000,000 用户技术架构经历了 3 个阶段,第 1 版,技术特点,微博本质是解决发表/订阅问题第 1 版采用推消息模式,将发表/订阅简化成 insert/select 问题,技术细节,典型 LAMP 架构MySQL:单库单表,MyISAMMPSS(Multi-Port Single Server),快速成长,用户快速增长出现发表延迟现象,尤其是明星用户,架构演变,分发推送是造成发表延迟首因模式改进数据规模增大也带来一定延迟规模增大:数据拆分锁表问题:更改引擎发表过慢:异步方式,第 2 版,投递模式优化,推模式改

2、进,不需要推送到所有用户存储及发表峰值压力减轻投递延迟减小,数据拆分,优先按时间维度拆分内容和索引分开存放内容使用 key-value 方式存储(NoSQL)索引由于分页访问,拆分有挑战,异步处理,发表异步化发表速度及可靠性得到提高使用 MemcacheQ增加 stats queue,适合大规模运维,技术细节,InnoDB 引进,避免锁表烦恼PHP 中 libmemcached 代替 memcache在高并发下稳定性极大提高,高速发展,系统问题单点故障、“雪崩”访问速度,国内复杂网络环境数据压力及峰值MySQL 复制延迟、慢查询热门事件微博发表量,明星评论及粉丝,如何改进,系统方面允许任意模块

3、失败静态内容 CDN 加速数据压力及峰值将数据、功能、部署尽可能拆分提前容量规划,平台化需求,Web 系统有用户行为才有请求API 系统轮询请求峰值不明显用户行为很难预测,系统规模持续增大平台化需求新的架构如何设计?,“Break large complex systems down into many services.search touches 100s of services(ads,web search,books,news,spelling correction.)”-Jeff Dean,Google Fellow,服务化,服务接口应用,第 3 版,平台服务,平台服务和应用服务分开

4、,模块隔离新微博引擎,实现 feed cache 分层关系多维度索引结构,性能极大提高计数服务改成基于偏移,更高的一致性、低延迟,基础服务,DB 冷热分离等多维度拆分图片等存储去中心化动态内容支持多 IDC 同时更新,高性能架构,50,000,000 用户使用新浪微博最高发表 3,000 条微博/秒姚晨发表一条微博,会被 3,689,713 粉丝读到(11 月 10 日 数据),问题本质,解决高访问量、海量数据规模下易于扩展、低延迟高可用异地分布能力,每天数十亿次Web及接口请求请求内容随时变化,结果无法 cache如何扩展?,思路,去状态,可请求服务单元中任意节点去中心化,避免单点及瓶颈可线

5、性扩展,如100 万用户,10 台服务器1000 万用户,100 台服务器减少模块耦合,实时性,高性能系统具备低延迟、高实时性实时性核心是让数据离 CPU 最近,避免磁盘 IO,“CPU 访问 L1 就像从书桌拿一本书,L2 是从书架拿一本书,L3 是从客厅桌子上拿一本书,访问主存就像骑车去社区图书馆拿一本书。”-余锋 ecug 2010 淘宝网核心系统专家,Erlang技术专家,微博 cache 设计,高可用,好的架构具有高可用性业界Amazon S3:99.9%Amazon EC2:99.95%Facebook:n/a微博平台 99.95%(5 小时/年),如何达到,容量规划图表监控及 a

6、dmission control.接口及资源监控,7x24业务回环测试,监测业务逻辑有效性集成测试,图表,通过图表了解系统容量,接口监控,curl/各地请求情况及响应时间流量异常/access lognon-200 结果/失败率/exceptions将监控指标量化类似 mysql seconds behind master,“Many services are written to alert operations on failure and to depend upon human intervention for recovery,about 20%of the time they wi

7、ll make mistakes.Designing for automation.”-James Hamilton,VP of Amazon,自动化,大规模互联网系统运作需要尽可能自动化发布及安装服务启用、停止故障处理前提,去状态化,允许单点故障及重启,“System administration at Google usually have 1 week of on call duty,and the other 5 weeks are spent making improvements to make the on call portion more optimized,automate

8、d,and trouble-free”-Tom Limoncelli Everything SysadminLumeta Corporation总监,贝尔实验室专家,微博系统运转依赖大量自动化工具工具在持续改进并增加中,高可用性还有异地分布的需求在国内网络环境下,IDC 灾难、机房检修维护会导致服务中断用户就近访问可提高速度,静态内容分布采用 CDN 技术,成熟动态内容分布是业界难点核心是数据的分布式存储,理想的分布式存储产品支持海量规模、可扩展、高性能、低延迟、高可用性多机房分布,异地容灾调用简单,具备丰富数据库特性,分布式存储需要解决多对多的数据复制同步及数据一致性,复制策略,Master

9、/Slave实现简单,master 有单点风险Multi-Master合并多处写,异步,最终一致性需要应用避免冲突Paxos:强一致性,延迟大,Multi-MasterWeb 应用多地区同步的最佳策略没有现成成熟的产品,微博方案,通过消息广播方式将数据多地分布类似 Yahoo!Message Broker,“We use YMB for replication for 2 reasons.1.YMB ensure msgs are not lost before they are applied to the db.2.YMB is designed for wide-area replica

10、tion.This isolates individual PNUTS clusters from dealing with update between regions”PNUTS:Yahoo!s Hosted Data Serving Platform,新推送架构,现状,API 大部分请求都是为了获取最新数据重新思考 Rest API大部分调用都是空返回大部分时间在处理不必要的询问无法实时投递存在请求数限制(rate limit),如何解决,新一代推送接口(Stream API)采用推送的方式有新数据服务器立即推送给调用方无数据则不消耗流量客户端实现更简单,技术特点,低延迟,从发表到客户端

11、接收1秒内完成高并发长连接服务,推送架构,为什么先持久化KISS,Keep It Simple and Stupid测试表明持久几乎不增加延迟开销batch insertcursor read,内部细节,Stream Buffer保存用户最近数据保存客户端断线重连之间下行数据,平台安全,由于接口开放,需要防范各种恶意行为垃圾内容垃圾粉丝恶意行为,内容安全,微博平台需要为用户提供安全及良好体验的应用为开发者营造公平的环境接口需要清晰的权限控制及安全规则,接口安全,Auth层访问需要 AppKey需要 OAuth 授权权限层流量控制、权限,架构就是将复杂问题抽象简单并解决,下一代微博架构,期待您的参与Join us!TimYang,

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 建筑/施工/环境 > 农业报告


备案号:宁ICP备20000045号-2

经营许可证:宁B2-20210002

宁公网安备 64010402000987号