1. Dreaming Infrastructure
我的架构学习笔记
邝宇恒
http://randomtaste.appspot.com

2. About me
Mail&GTalk: kuangyuheng@gmail.com
Twitter: kyhpudding
中山大学, 03CS本
06年实习进入百度, 搜藏, 空间, 基础平台部
刚刚加入腾讯广州研发中心
本交流纯属个人心得, 不代表任何公司组织之意见

3. Infrastructure

4. Infrastructure
可以用开源软件马上搭一个

5. Infrastructure
可以全部``云''掉

6. 那我还讲啥?

7. Infrastructure's fun!
选择一个基础架构
组合, 利用, 优化: 这不仅是一堆开源软件
或者一坨云
有时候, 你得自己动手......

8. Just for fun :-)

9. Infrastructure components
For distributed web services
机群部署运维
自动部署与各种各样的监控
服务定位和均衡
硬件虚拟化
Messaging
Protocol
Messaging infrastructure: reliable message queue etc.
应用容器, 框架 etc.
存储
适应业务需要的存储系统.
往往是最困难的.
还有更多
接入(均衡, CDN, 防攻击 etc.)
检索, 日志收集与分析, 机器学习......

10. Outline
讨论范围
互联网应用, 更精确地: web 应用
基于普通 PC Server 环境, 分布式系统
以存储系统为讨论中心
关于权衡
基础架构设计理念
Google, LiveJournal, Yahoo!
存储系统细节
GFS&BigTable, Dynamo, Sherpa/PNUTS
假定听众有基本了解, 直接讨论有趣的细节
Lessons learned
折腾和被折腾的心得

11. It's all about trade-offs

12. 容量可扩展 可用性
可靠性
高吞吐
It's all about trade-offs
一致性
易开发
多快好省! 低延迟

13. CAP
Consistency, Availability, Partition

14. 搞清你在做什么
我的行业
稳定至上的银行业? 精益求精的搜索行业? 多快好省抢占
地盘的SNS?
我的业务模式, 信息模型
实时在线服务 vs. 线下分析, 读写比例?
关系-存储-浏览, twitter/lifestreaming, 检索-
ranking, 挖掘-推荐, 他们的结合?
扁平的树状结构? 还是复杂的网状结构?
产品上的权衡
我的开发者的水平, 习惯
基础架构的用户就是应用开发者
我有多少钱, 多少时间

15. 搞清我的位置

16. 设计理念: Google 篇

17. 设计理念: Google 篇

18. 设计理念: Google 篇

19. 设计理念: Google 篇

20. 设计理念: Google 篇
BigTable
Replication across IDC,
eventually consistency
服务端编程能力

21. 设计理念: LiveJournal 篇
LiveJournal: Behind The Scenes, Scaling Storytime
Brad Fitzpatrick, April 2007

22. 设计理念: LiveJournal 篇
LAMM(emcache)P(erl)!
高速成长, 从单机到数百台, scaling!

23. 设计理念: LiveJournal 篇
LAMM(emcache)P(erl)!
高速成长, 从单机到数百台, scaling!
数据库
Scaling read: replication, master/slave
Scaling write: sharding
JOIN? Big sorted table? sharding 不是包医百病

24. 设计理念: LiveJournal 篇
LAMM(emcache)P(erl)!
高速成长, 从单机到数百台, scaling!
数据库
Scaling read: replication, master/slave
Scaling write: sharding
JOIN? Big sorted table? sharding 不是包医百病
Cache, Cache, Cache!
Cache就是清凉油, 哪里不舒服了抹一下 --- 朱聪
Everything run from memory in Web 2.0 --- twitter
memcached!

25. 设计理念: LiveJournal 篇
LAMM(emcache)P(erl)!
高速成长, 从单机到数百台, scaling!
数据库
Scaling read: replication, master/slave
Scaling write: sharding
JOIN? Big sorted table? sharding 不是包医百病
Cache, Cache, Cache!
Cache就是清凉油, 哪里不舒服了抹一下 --- 朱聪
Everything run from memory in Web 2.0 --- twitter
memcached!
分布式 Key-Value 存储: MogileFS

26. 设计理念: 延伸, 经典模式
RDBMS处理逻辑数据
分离大段文本内容, 珍惜宝贵
的DB资源
Scaling: replication,
sharding
Key-Value存储存大数据
简单, 易扩展, 性能好
Cache everywhere
多层次, 全方位
Infrastructure
MySQL&Memcache&KV
cluster
PHP host environment
Sina App Engine!

27. 设计理念: Yahoo! 篇
众多的业务, 众多的需求
门户, 搜索, 广告, 邮箱, 社区.....
小数据, 大数据, 在线服务, 离线分析......
众多的基础构建
MySQL&Oracle
UDB, YMDB, PNUTS, Hadoop....
拥抱开源
大量PHP使用, 定制开源软件, yapache etc.
Hadoop!
走向云端
That's what we are talking about!

28. 设计理念: Yahoo! 篇
Source: Key challenges in cloud computing
...and the Yahoo! approach
Raghu Ramakrishnan

29. 设计理念: Yahoo! 篇
在线服务
依然有很多 MySQL, Oracle, 不可替代, 或没必要迁移
UDB: Dynamo like, YMDB: Media files
Sherpa/PNUTS: 托管的可扩展, 关系式存储.

30. 设计理念: Yahoo! 篇
在线服务
依然有很多 MySQL, Oracle, 不可替代, 或没必要迁移
UDB: Dynamo like, YMDB: Media files
Sherpa/PNUTS: 托管的可扩展, 关系式存储.
离线分析
Hadoop
HDFS: GFS
Pig: 跟Sawzall可不同
HBase?
Everest Data warehousing
完全SQL支持

31. 小结: 设计里
Google
一层层构建的统一基础架构.
真正的统一平台: 强大的平台极大降低创新门槛.
LiveJournal
快速扩展, 随需应变的典范.
运用开源和自制软件的结合.
Yahoo!
当你有很多完全不同的应用和老系统......
不追求完全统一, 具体问题具体分析.

32. 细节: GFS
Key-Value存储
Index, Log
线下应用: 大块低并发写
高吞吐远比低延迟重要
简单设计: Single Master
Master容量决定文件数目: 瓶
颈? it depends
单点故障 --- chubby
强一致性
确保写三个replica再返回
部分replica失败下的不一致
--- 非幂等操作是恶魔.
chunkserver挂掉超长延时
CAP: C+, P-

33. 细节: BigTable
That effort took many years...
一张排序的大表
线上应用, 类DB功能
线下分析, 结构化数据
With GFS
GFS保证数据一致可靠
Log-structured merge tree, 切
合GFS模型
可用性......
一份数据只在一台机器服务,
挂了麻烦等10+秒......
GFS的超长写延时: 开两个
log...
CAP: C&P==GFS, A--

34. 幕后英雄: Chubby
高可用: 如何保证主备一致和正确
自动切换?
主备严格同步确认&心跳
当备连不上主时, 变成主
当他们之间只是网络断掉
当某些client只能连上其中一台
不一致的双 master
当主备连不上的时候
唯一安全的方法就是不再接受提
交, 手工操作检查重起.
可用性比一台机还差!
使用专门心跳电缆和传输线
假定线路完全靠谱.
跨机房就别指望了.

35. 幕后英雄: Chubby
增加到3台
提交至少得到其他1台确认
使任何操作都得到多数派确认
slave连不上master, 发起选举
投票结果取决于另一台slave与master
的连通
失败: 发起的slave自认倒霉
成功: 原master的提交不再可能得到多
数票. master移交
2N+1台机器, 最多可容忍N台不一致
(挂掉)而保持全局一致.
更多节点具体如何投票确认? Paxos!
Paxos made simple & Wikipedia

36. 幕后英雄: Chubby
每个服务都得来这么一回?
简单点: 锁文件
Master对共享文件加锁, 保证只有一个
master写
如何切换: 租约: Lease
30secs etc, master到期续约
续约不上(网络断, 被抢)让出master, 停
止服务
发现锁因未续约而失效, 分配另外的机器
作为master锁住
Chubby: 可靠的锁服务&小文件存储
Using Paxos...
不是细粒度的事务锁!
Developers rarely consider availability

37. 细节: 论文之后......
GFS的问题
master 单点故障: 从手工恢复到使用 chubby
master 文件数量上限
不同的应用模式: 小文件, 大文件量, 从打包到BigTable
分区: 使用多套 GFS 共同使用, 共享同一堆chunk server
延迟: 基本没救了
BigTable
Replication, eventually consistency, 在线服务应用
coprocessors: 应用处理直接运行在服务端最接近数据源处
--- bandwidth
AppEngine, DataStore on BigTable
Datastore index: 使用户查询在顺序表模型上仅需一次range查
询
常见超慢读写, 就是因为这些设计?
Spanner?

38. 细节: Dynamo
Amazon's ``always writable'' data storage
Key-Value存储
Always writable
事关核心价值: 一次失败的"加
入购物车", 直接损失一笔交易
Eventually consistency: C--,
A++
无中心, 持续扩展
Consistent Hash+Virtual node
各节点地位平等
More
(Dynamo+BigTable)@facebook
== Cassandra --- twitter wants it
too!

39. 细节: Dynamo
Amazon's ``always writable'' data storage
CAP: N vs. R+W
可配置的R,W&N, 满足不同需求.
Eventually consistency
想象如CVS等并发版本管理
commit指定修改所基于的版本
没有冲突的commit, 顺利replicate到
个节点
有冲突的commit, 各节点返回不同版
本, 由应用(提交者) merge.
Preference list
优先写头 N' 台机器. 失败的话会写
下面的 => N' < N
结果: 有可能但稀有的冲突.

40. 细节: Sherpa/PNUTS
Yahoo!’s Hosted Data Serving Platform

41. 细节: Sherpa/PNUTS
Hosted: the cloud
模型: 结构化数据表
在线服务, 小对象, 低延迟, 高并发
单条更新, 灵活查询. Sorted, hash皆支持
一致性模型, per-record timeline
以行为单位做 master/slave, 保证单条记录的一致更新时序
不会出现Dynamo的分支版本和合并, 极大简化开发
灵活的一致性需求: Read-any, read-critical, read-latest, test-
and-set-write
Notification/Trigger, 与外部cache等对接.
YMB: Yahoo! Message Broker
可靠异步消息队列, replication
提交到YMB即为提交成功.
YMB保障数据可靠性: 通过重放YMB消息恢复实际storage.

42. 小结: 细节
分布式系统
异步不可靠传输, 无一致时序是天然特性, 别想逃避.
Time, Clocks, and Ordering of Events in a Distributed System
Fallacies of Distributed Computing Explained
CAP
不同场景, 不同需求, 没有标准答案
Paxos&Chubby
真正实现一个 Quorum 算法
Chubby: 把复杂问题变成一个简单基础服务.
Commit log
经典设计模式
将可靠消息队列作为系统的骨架.
Log-structured merge tree
简单模型+简单实现

43. Lessons Learned

44. DO NOT Design for scalability

45. DO NOT Design for scalability at first

46. DO NOT Design for scalability at first
``可扩展'' 是有代价的
受限的查询能力
CAP: 宽松的一致性模型让开发者迷惑
不要在还没成长的时候担负成长的烦恼.
为赋新辞强说愁
在力所能及的情况下, 为可扩展做准备
以尽量不影响开发为前提
遵循常用扩展方法和可扩展设计原则

47. DO NOT Design for scalability at first
``可扩展'' 是有代价的
受限的查询能力
CAP: 宽松的一致性模型让开发者迷惑
不要在还没成长的时候担负成长的烦恼.
为赋新辞强说愁
在力所能及的情况下, 为可扩展做准备
以尽量不影响开发为前提
遵循常用扩展方法和可扩展设计原则
Google App Engine vs. Sina App Engine
对长尾头部应用, 谁都不靠谱: 需要特殊定制和优化
对小网站, 初创企业, 谁更靠谱?

48. DO NOT Design for scalability at first

49. 纵向性能提升
提升单机性能
横向扩展? 机器成本......
我们的特殊国情, 人力成本--, 机器+机位+带宽成本++
对长尾头部应用下大力气做特殊优化绝对划得来
如果对占最多机器的核心应用单机性能提升30%
就能省20-30%的机器...... 和机位!
那是好多钱......

50. 纵向性能提升
提升单机性能
硬件
摩尔定律+机器运维成本: 换新的好机器是值的
插满内存槽通常没错
数据库, 看书...
OS&基础软件
文件系统选择, 硬件驱动, 配置...
readahead, sendfile, epoll...
编译器, 编译选项, tcmalloc...
IO
传统硬盘: 避免随机读写 / SSD: 避免随机写.
压缩: CPU 换 IO&带宽.
部署
你的每台机器的 CPU, 内存, IO 都跑满了吗?
混搭部署, PHP纯CPU, Cache纯内存

51. Design for fault, always
这年头什么都不可靠
硬件不可靠
单机再可靠, 当机器足够多, 你会老是见到机器挂的
所以... 机器少的时候还好, 小心你的硬盘......
网络不可靠, 仔细设计超时和重试策略
人最不可靠
Bug... Getting real: 你得习惯烂软件质量
靠机制, 不要靠人

52. Design for fault, always
这年头什么都不可靠
Erlang 的启示
Making reliable distributed systems in the presence of
software errors
组件隔离: 存储与应用, 应用之间......
Why PHP works?
也从函数式编程中学到很多.
健壮的基础架构
1. 普通应用组件无须容忍基础架构和其他组件的错误.
2. 如果他们出错, 则直接跟着 crash --- 没有重试?
3. 在这样的情况下, 能提供符合用户健壮性要求的应用.
不要让应用开发者把时间耗在思考各种死法上.
桌面软件错误 vs. Web

53. Design for change
规模, 业务的迅速变化, 保持敏
捷
基础架构也是演化来的
没有完美的统一架构, 不要一次过满足三个愿望.
后天的问题, 至少留到明天解决, 不要阻碍今天的生活.
Right design at X may be very wrong at 10X or 100X
反之亦然!
Google: 7 significant revision in last 10 years.
简单设计
典范: GFS 的 single master 史.
缩短开发周期, 降低项目复杂度, 船小好调头.
准备抛弃

54. 容量可扩展 可用性
可靠性
Design for your developers
高吞吐d
多: 能做的功能/应用/改进更多
快: 应用开发快
好:
一致性 能靠谱地跑起来, 实现产品核心价值
省: 省钱!
易开发
多快好省! 低延迟

55. 硬件影响设计
Source: Jeff Dean, Designs, Lessons and Advice
from Building Large Distributed Systems

56. 硬件影响设计
06 vs. Now: 硬件导致设计思路改变.
关于CPU
核数飞速增加, 但单核性能并没有非常大的提高
糟糕的应用并行性, shared data struct and locks are
even more evil than ever!
关于SSD: 规则改变者
SSD价格会迅速降低, 性能可靠性会继续提高.
SSD与传统机械硬盘的不同特性
The 5 minutes rule 20 years later and how flash memory
changes the rules
Technologies for Data-Intensive Computing

57. 信息组织影响设计
信息爆炸
Thousands: 文件夹, 分类
Millions: Tags, 简单检索
Billions, web scale: 检索!
信息结构
结构化和严格关系模型
纯文本/媒体与无关系
Web: 半结构化, 复杂与不确定关系

58. 信息组织影响设计
信息爆炸
Thousands: 文件夹, 分类 --- 树状结构.
Millions: Tags, 简单检索 --- 简单网状结构和关系模型.
Billions, web scale: 检索! PageRank --- 这叫啥结构?
信息结构
结构化和严格关系模型 --- 数据库条目.
纯文本/媒体与无关系 --- Key/Value 存储, S3
Web: 半结构化, 复杂与不确定关系 --- Semantic Web,
Linked data, 人际关系, news feed...
Web 0.2, not Web 2.0! --- WWW 的能力远没有完全发挥
珠三角技术社区的新鲜事?
不是 ``好友/关键字的最新动态''
模糊与个性化需求: 珠三角? 技术? 我的技术喜好? 圈子?
开放平台与聚合: 只能在 twitter 站上推的不叫Web!
实时!

59. 全新挑战
Aggregate, Filter, Rank EVERYTHING in REAL-TIME
推推拉拉的 News feed 只是挑战的开始
跳出纯关系数据模型
灵活可定制的实时检索是基础架构而非添头
计算分析平台成为必须, Map-Reduce 就够了?
经典模式和组件也许不再有效
但基础方法和技术依然

60. Thank you!
Q&A