Dreaming Infrastructure

Dreaming Infrastructure我的架构学习笔记

邝宇恒http://randomtaste.appspot.com

About me

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

Infrastructure

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

Infrastructure可以全部``云''掉

那我还讲啥?

Infrastructure's fun!

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

Just for fun :-)

Infrastructure components

机群部署运维自动部署与各种各样的监控服务定位和均衡硬件虚拟化

MessagingProtocolMessaging infrastructure: reliable message queue etc.

应用容器, 框架 etc.存储

适应业务需要的存储系统.往往是最困难的.

还有更多接入(均衡, CDN, 防攻击 etc.)检索, 日志收集与分析, 机器学习......

For distributed web services

Outline

讨论范围互联网应用, 更精确地: web 应用基于普通 PC Server 环境, 分布式系统以存储系统为讨论中心

关于权衡基础架构设计理念

Google, LiveJournal, Yahoo!存储系统细节

GFS&BigTable, Dynamo, Sherpa/PNUTS假定听众有基本了解, 直接讨论有趣的细节

Lessons learned折腾和被折腾的心得

It's all about trade-offs

It's all about trade-offs

容量可扩展

易开发

可靠性

一致性

可用性

多快好省!

高吞吐

低延迟

CAPConsistency, Availability, Partition

搞清你在做什么

我的行业稳定至上的银行业? 精益求精的搜索行业? 多快好省抢占地盘的SNS?

我的业务模式, 信息模型实时在线服务 vs. 线下分析, 读写比例?关系-存储-浏览, twitter/lifestreaming, 检索-ranking, 挖掘-推荐, 他们的结合? 扁平的树状结构? 还是复杂的网状结构?

产品上的权衡我的开发者的水平, 习惯

基础架构的用户就是应用开发者我有多少钱, 多少时间

搞清我的位置

设计理念: Google 篇

设计理念: Google 篇

BigTableReplication across IDC, eventually consistency服务端编程能力

设计理念: LiveJournal 篇LiveJournal: Behind The Scenes, Scaling Storytime

Brad Fitzpatrick, April 2007

设计理念: LiveJournal 篇

LAMM(emcache)P(erl)!高速成长, 从单机到数百台, scaling!


LAMM(emcache)P(erl)!高速成长, 从单机到数百台, scaling!数据库

Scaling read: replication, master/slaveScaling write: sharding

JOIN? Big sorted table? sharding 不是包医百病




JOIN? Big sorted table? sharding 不是包医百病Cache, Cache, Cache!

Cache就是清凉油, 哪里不舒服了抹一下 --- 朱聪Everything run from memory in Web 2.0 --- twittermemcached!




JOIN? Big sorted table? sharding 不是包医百病Cache, Cache, Cache!

Cache就是清凉油, 哪里不舒服了抹一下 --- 朱聪Everything run from memory in Web 2.0 --- twittermemcached!

分布式 Key-Value 存储: MogileFS

设计理念: 延伸, 经典模式

RDBMS处理逻辑数据分离大段文本内容, 珍惜宝贵的DB资源Scaling: replication, sharding

Key-Value存储存大数据简单, 易扩展, 性能好

Cache everywhere多层次, 全方位

InfrastructureMySQL&Memcache&KV clusterPHP host environmentSina App Engine!

设计理念: Yahoo! 篇

众多的业务, 众多的需求门户, 搜索, 广告, 邮箱, 社区.....小数据, 大数据, 在线服务, 离线分析......

众多的基础构建MySQL&OracleUDB, YMDB, PNUTS, Hadoop....

拥抱开源大量PHP使用, 定制开源软件, yapache etc.Hadoop!

走向云端That's what we are talking about!

设计理念: Yahoo! 篇Source: Key challenges in cloud computing

...and the Yahoo! approachRaghu Ramakrishnan


在线服务依然有很多 MySQL, Oracle, 不可替代, 或没必要迁移UDB: Dynamo like, YMDB: Media filesSherpa/PNUTS: 托管的可扩展, 关系式存储.


在线服务依然有很多 MySQL, Oracle, 不可替代, 或没必要迁移UDB: Dynamo like, YMDB: Media filesSherpa/PNUTS: 托管的可扩展, 关系式存储.

离线分析Hadoop

HDFS: GFSPig: 跟Sawzall可不同HBase?

Everest Data warehousing完全SQL支持

小结: 设计里

Google一层层构建的统一基础架构.真正的统一平台: 强大的平台极大降低创新门槛.

LiveJournal快速扩展, 随需应变的典范.运用开源和自制软件的结合.

Yahoo!当你有很多完全不同的应用和老系统......不追求完全统一, 具体问题具体分析.

细节: GFS

Key-Value存储Index, Log线下应用: 大块低并发写高吞吐远比低延迟重要

简单设计: Single MasterMaster容量决定文件数目: 瓶颈? it depends单点故障 --- chubby

强一致性确保写三个replica再返回部分replica失败下的不一致 --- 非幂等操作是恶魔.chunkserver挂掉超长延时

CAP: C+, P-

细节: BigTable

That effort took many years...一张排序的大表

线上应用, 类DB功能线下分析, 结构化数据

With GFSGFS保证数据一致可靠Log-structured merge tree, 切合GFS模型

可用性......一份数据只在一台机器服务, 挂了麻烦等10+秒......GFS的超长写延时: 开两个log...

CAP: C&P==GFS, A--

幕后英雄: Chubby

高可用: 如何保证主备一致和正确自动切换?

主备严格同步确认&心跳当备连不上主时, 变成主

当他们之间只是网络断掉当某些client只能连上其中一台不一致的双 master

当主备连不上的时候唯一安全的方法就是不再接受提交, 手工操作检查重起.可用性比一台机还差!

使用专门心跳电缆和传输线假定线路完全靠谱.跨机房就别指望了.


增加到3台提交至少得到其他1台确认使任何操作都得到多数派确认

slave连不上master, 发起选举投票结果取决于另一台slave与master的连通失败: 发起的slave自认倒霉成功: 原master的提交不再可能得到多数票. master移交

2N+1台机器, 最多可容忍N台不一致(挂掉)而保持全局一致.更多节点具体如何投票确认? Paxos!

Paxos made simple & Wikipedia


每个服务都得来这么一回?简单点: 锁文件

Master对共享文件加锁, 保证只有一个master写

如何切换: 租约: Lease30secs etc, master到期续约续约不上(网络断, 被抢)让出master, 停止服务发现锁因未续约而失效, 分配另外的机器作为master锁住

Chubby: 可靠的锁服务&小文件存储Using Paxos...不是细粒度的事务锁!Developers rarely consider availability

细节: 论文之后......

�GFS的问题master 单点故障: 从手工恢复到使用 chubbymaster 文件数量上限

不同的应用模式: 小文件, 大文件量, 从打包到BigTable分区: 使用多套 GFS 共同使用, 共享同一堆chunk server

延迟: 基本没救了BigTable

Replication, eventually consistency, 在线服务应用coprocessors: 应用处理直接运行在服务端最接近数据源处 --- bandwidth

AppEngine, DataStore on BigTableDatastore index: 使用户查询在顺序表模型上仅需一次range查询常见超慢读写, 就是因为这些设计?

Spanner?

细节: Dynamo

Key-Value存储Always writable

事关核心价值: 一次失败的"加入购物车", 直接损失一笔交易Eventually consistency: C--, A++

无中心, 持续扩展Consistent Hash+Virtual node各节点地位平等

More(Dynamo+BigTable)@facebook == Cassandra --- twitter wants it too!

Amazon's ``always writable'' data storage

细节: Dynamo

CAP: N vs. R+W可配置的R,W&N, 满足不同需求.

Eventually consistency想象如CVS等并发版本管理commit指定修改所基于的版本没有冲突的commit, 顺利replicate到个节点有冲突的commit, 各节点返回不同版本, 由应用(提交者) merge.

Preference list优先写头 N' 台机器. 失败的话会写下面的 => N' < N结果: 有可能但稀有的冲突.

Amazon's ``always writable'' data storage

细节: Sherpa/PNUTSYahoo!’s Hosted Data Serving Platform

细节: 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.

小结: 细节

分布式系统异步不可靠传输, 无一致时序是天然特性, 别想逃避.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

简单模型+简单实现

Lessons Learned

DO NOT Design for scalability

DO NOT Design for scalability at first


``可扩展'' 是有代价的受限的查询能力CAP: 宽松的一致性模型让开发者迷惑

不要在还没成长的时候担负成长的烦恼.为赋新辞强说愁

在力所能及的情况下, 为可扩展做准备以尽量不影响开发为前提遵循常用扩展方法和可扩展设计原则


``可扩展'' 是有代价的受限的查询能力CAP: 宽松的一致性模型让开发者迷惑

不要在还没成长的时候担负成长的烦恼.为赋新辞强说愁

在力所能及的情况下, 为可扩展做准备以尽量不影响开发为前提遵循常用扩展方法和可扩展设计原则

Google App Engine vs. Sina App Engine对长尾头部应用, 谁都不靠谱: 需要特殊定制和优化对小网站, 初创企业, 谁更靠谱?

纵向性能提升

横向扩展? 机器成本......我们的特殊国情, 人力成本--, 机器+机位+带宽成本++对长尾头部应用下大力气做特殊优化绝对划得来

如果对占最多机器的核心应用单机性能提升30%就能省20-30%的机器...... 和机位!那是好多钱......

提升单机性能

纵向性能提升

硬件摩尔定律+机器运维成本: 换新的好机器是值的插满内存槽通常没错

数据库, 看书...OS&基础软件

文件系统选择, 硬件驱动, 配置...readahead, sendfile, epoll...编译器, 编译选项, tcmalloc...

IO传统硬盘: 避免随机读写 / SSD: 避免随机写.压缩: CPU 换 IO&带宽.

部署你的每台机器的 CPU, 内存, IO 都跑满了吗?混搭部署, PHP纯CPU, Cache纯内存

提升单机性能

Design for fault, always

硬件不可靠单机再可靠, 当机器足够多, 你会老是见到机器挂的所以... 机器少的时候还好, 小心你的硬盘......

网络不可靠, 仔细设计超时和重试策略人最不可靠

Bug... Getting real: 你得习惯烂软件质量靠机制, 不要靠人

这年头什么都不可靠

Design for fault, always

Erlang 的启示Making reliable distributed systems in the presence of software errors组件隔离: 存储与应用, 应用之间......Why PHP works?

也从函数式编程中学到很多.健壮的基础架构1. 普通应用组件无须容忍基础架构和其他组件的错误.2. 如果他们出错, 则直接跟着 crash --- 没有重试?3. 在这样的情况下, 能提供符合用户健壮性要求的应用.

不要让应用开发者把时间耗在思考各种死法上.桌面软件错误 vs. Web

这年头什么都不可靠

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 史.缩短开发周期, 降低项目复杂度, 船小好调头.

准备抛弃

规模, 业务的迅速变化, 保持敏捷

容量可扩展

易开发

可靠性

一致性

可用性

多快好省!

高吞吐d

低延迟

Design for your developers多: 能做的功能/应用/改进更多快: 应用开发快好: 能靠谱地跑起来, 实现产品核心价值省: 省钱!

硬件影响设计

Source: Jeff Dean, Designs, Lessons and Advice from Building Large Distributed Systems

硬件影响设计

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 rulesTechnologies for Data-Intensive Computing

信息组织影响设计

信息爆炸Thousands: 文件夹, 分类Millions: Tags, 简单检索Billions, web scale: 检索!

信息结构结构化和严格关系模型纯文本/媒体与无关系Web: 半结构化, 复杂与不确定关系

信息组织影响设计

信息爆炸Thousands: 文件夹, 分类 --- 树状结构.Millions: Tags, 简单检索 --- 简单网状结构和关系模型.Billions, web scale: 检索! PageRank --- 这叫啥结构?

信息结构结构化和严格关系模型 --- 数据库条目.纯文本/媒体与无关系 --- Key/Value 存储, S3Web: 半结构化, 复杂与不确定关系 --- Semantic Web, Linked data, 人际关系, news feed...Web 0.2, not Web 2.0! --- WWW 的能力远没有完全发挥

珠三角技术社区的新鲜事?不是 ``好友/关键字的最新动态''模糊与个性化需求: 珠三角? 技术? 我的技术喜好? 圈子?开放平台与聚合: 只能在 twitter 站上推的不叫Web!实时!

全新挑战

Aggregate, Filter, Rank EVERYTHING in REAL-TIME推推拉拉的 News feed 只是挑战的开始

跳出纯关系数据模型

灵活可定制的实时检索是基础架构而非添头

计算分析平台成为必须, Map-Reduce 就够了?

经典模式和组件也许不再有效

但基础方法和技术依然

Thank you!

Q&A

Dreaming Infrastructure

Technology

Transcript of Dreaming Infrastructure