2011-04 新浪杨卫华：构建高性能的微博系统（QCon北京2011）

2020-03-01 195浏览

1.Build High Performance Weibo System @TimYang
2.• 微博是什么？ • 140字 • 根据注系实时投递 • 支持评论、转发及图片、视频等媒体
3.相演讲 • 《构建可扩展的微博系统》QCon 2010 • 《微博架构与平台安全》WDC 2010
4.Agenda 3 2 4 1
5.Part 1 海量存储
6.每天近亿条新记录，大部分记录变更需要即时反映到业务系统(一致性)，如何解决？
7.MySQL • 适合海量存储，可不断拆分扩展 • 久经考验
8.拆分策略 • 按 hash 拆分 • 多维度，如系 • 多级索引，如 user_timeline index
9.问题 • 单机性能限制、需要持续拆分 • 访问速度需求 • 用户 • 系，每秒 5 万次 • 延迟
10.MySQL + cache 问题 • 雪崩 • 一致性 • cache数据类型不，需要序列化 • 额外销 • 添加及修改问题
11.NoSQL “Databases are specializing – the “one size fits all” approach no longer applies.” MongoDB设计哲学
12.NoSQL? • 单机思路 • Redis • MongoDB • 分布式思路 • Cassandra
13.用好一款源产品的前提条件是深入了解它的定位。
14.特性比较 • MongoDB • Redis • HBase • Cassandra
15.Redis - 持久方式 • 持久化存储模式理解 • snapshot - 主流 • vm - 作者放弃 • diskstore - 作者新方向 • aof - 重建慢
16.Redis - 数据类型 •string:key value redisObject 16 bytes/item •list:双向链表 40 bytes / item •hash:zipmap(<64) • set/sorted set
17.Redis - Replication • 重读rdb文件问题 • 代码实现简单
18.Redis - 容量规
19.Redis - 定位 • 需要高速读写访问 • 能容忍短期不可用，无成熟failover方案 • 有list/set数据结构需求(optional)
20.海量存储 • MySQL，久经考验的海量存储 • NoSQL，填补MySQL与cache之间空但是需要有合适的驾驭能力，
21.Part 2 实时计算
22.微博架构 (第三版)
23.服务→接口→应用
24.问题一大部分Web系统瓶颈在于cache数据访问，仅用压缩是否足？可用的cache资源放不下所有热点数据，导致数据加载日趋缓慢 • 扩容？
25.“Web 系统用 json 来存储及 cache 非常浪费。一条微博用 json 数据结构来存所有字段(包括作者信息)，需要2~5K字节左右, 用 xml 需要10k左右, 用 protobuf 序列化后，大约只有500字节。”
26.历程 RDBMS→ Key value (JSON)→ Protocol buffers(binary)
27.JSON 烦恼 • DB • Cache • Message Queue • API
28.PB 优势 •Numeric:varint, from 1 byte • 仅传输编号，不传输字段名称 • 支持多语言：Java, C++, Python...
29.• 编解码高效 • 从 cache 最终结果到中间结果，进一步节约空间 • “192.168.0.1” → “0xc0a80000” → varint
30.Benchmark Text Text (数据来源：http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking)
31.“We would like to provide public APIs that accept protocol buffers as well as XML, both because it is more efficient and because we're just going to convert that XML to protocol buffers on our end anyway.” - Google
32.数据结构，小即是美
33.步处理需求 • 微博的发表是步处理 • 随着平台应用增多，与应用相作也逐渐转向 • 其他需要步方式步的操作？数据操
34.问题二随着系统增大，“一上线就出问题”情况增多，追究原因很大一部分是由于人员对步处理缺乏深度理解。发
35.• 传统 LAMP 应用中，单个操作步骤增多及处理时间增大对整体性能影响不大。 • 步队列处理程序中 1ms 的处理时间延长可能会引起连锁反应及业务故障。 • 实时监控队列处理性能指标数据。
36.步监控 • MQ stat • MQ Processor stat
37.问题三明星用户上百万粉丝，数据如何实时投递到所有用户? 为什么显示有“1条新评论”，点有数据？却没
38.实时性与一致性 • Timeline消息流，计数，系变更等业务需要及时投递给所有用户 • 为了解除耦合，功能由不同服务完成 • 步处理 • 将写 cache 与数据库分
39.老的发表流程 1. 提交发表 2. 入队列 3. 队列处理程序读出 4. 写cache及数据库master 5. 数据库replication到所有节点
40.问题
41.问题 • 第5步，破坏了实时性及一致性
42.问题 • 第5步，破坏了实时性及一致性 • 改进方法
43.问题 • 第5步，破坏了实时性及一致性 • 改进方法 • 进一步步处理
44.问题 • 第5步，破坏了实时性及一致性 • 改进方法 • 进一步步处理 • 队列分级
45.下一步 • RAM is the new disk • 所有热点数据加载到内存
46.方法一 “Percona Server now both SQL and NOSQL HandlerSocket, 据称它的测试服务器可以到 100万rps，配置是12cores/24threads and 380GB of RAM, mysql如果这样用不就是个 Redis，所有数据都加到内存，使用NoSQL方式来访问”
47.@jackbillow “ 1. 提升PK的lookup 2.替代cache 层（管理方面）” @kobe “ 还是运维成本低，挂innodb的话原有的工具全能用上” @TimYang “如果一张表可以全部放入内存， InnoDB会自动创建一个Adaptive Hash Indexes（基于 hash的内存索引）以达到内存数据库的性能”
48.方法二 • 将NoSQL当作数据的读库 • 通过中间程序读取binlog放入Redis • jbinloghttps://github.com/tangfl/jbinlog
49.Part 3 平台接口
50.游戏规则已经发生了变化，产品的竞争转变为平台和app生态圈之间的竞争
51.接口设计要素 • 安全 • 隐私保护 • spam • 易用 • 稳定
52.全国分布的接口响应时间及可用性监控 Text
53.其他优化 • 批量访问接口 • GZIP压缩 • 推送接口
54.Part 4 服务治理
55.微博中最常出现影响性能原因是什么？
56.“@郑环Zheng:“熵增定律：随着系统的持续运行，熵值将趋于无限增长。我们的运维职责就是持续对抗熵增，并尽可能降低熵值。” //@白鸦: 架构师的功底就是控制熵。 @bian：上学习了"熵"http://t.cn/h0k4r原文转发(49) 原文评论(15)” 2月14日 10:36 转发(22) 评论(10)
57.治理一：重构 • 做法，而不是做加法。 • 新业务也遵循这个原则。
58.治理二：容量 • 容量规及监控 • 容量未规 • 系统突然变慢，不能快速定位 • 业务迅速增长给容量规好，未有效监控现有系统带来挑战
59.治理三：诊断 • 通过日志和图形工具发现各 • 接口响应速度 • 消息处理速度 • cache命中率 • 迅速定位问题能力常
60.治理四：降级 • 单个业务问题引发了连锁反映，造成整体处理性能下降。 • 降级，每个业务增加独立功能
61.Timeline Memcached Redis MySQL
62.下一步 • 做法，可以走更远 • 更好的将数据RAM化 • 更好的分布式方式
63.Q&A @TimYang 欢迎加入新浪微博技术团队长期招聘