Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Dreaming Infrastructure

16.604 visualizaciones

Publicado el

Publicado en: Tecnología, Educación

Dreaming Infrastructure

  1. 1. Dreaming Infrastructure 我的架构学习笔记 邝宇恒 http://randomtaste.appspot.com
  2. 2. About me Mail&GTalk: kuangyuheng@gmail.com Twitter: kyhpudding 中山大学, 03CS本 06年实习进入百度, 搜藏, 空间, 基础平台部 刚刚加入腾讯广州研发中心 本交流纯属个人心得, 不代表任何公司组织之意见
  3. 3. Infrastructure
  4. 4. Infrastructure 可以用开源软件马上搭一个
  5. 5. Infrastructure 可以全部``云''掉
  6. 6. 那我还讲啥?
  7. 7. Infrastructure's fun! 选择一个基础架构 组合, 利用, 优化: 这不仅是一堆开源软件 或者一坨云 有时候, 你得自己动手......
  8. 8. Just for fun :-)
  9. 9. Infrastructure components For distributed web services 机群部署运维 自动部署与各种各样的监控 服务定位和均衡 硬件虚拟化 Messaging Protocol Messaging infrastructure: reliable message queue etc. 应用容器, 框架 etc. 存储 适应业务需要的存储系统. 往往是最困难的. 还有更多 接入(均衡, CDN, 防攻击 etc.) 检索, 日志收集与分析, 机器学习......
  10. 10. Outline 讨论范围 互联网应用, 更精确地: web 应用 基于普通 PC Server 环境, 分布式系统 以存储系统为讨论中心 关于权衡 基础架构设计理念 Google, LiveJournal, Yahoo! 存储系统细节 GFS&BigTable, Dynamo, Sherpa/PNUTS 假定听众有基本了解, 直接讨论有趣的细节 Lessons learned 折腾和被折腾的心得
  11. 11. It's all about trade-offs
  12. 12. 容量可扩展 可用性 可靠性 高吞吐 It's all about trade-offs 一致性 易开发 多快好省! 低延迟
  13. 13. CAP Consistency, Availability, Partition
  14. 14. 搞清你在做什么 我的行业 稳定至上的银行业? 精益求精的搜索行业? 多快好省抢占 地盘的SNS? 我的业务模式, 信息模型 实时在线服务 vs. 线下分析, 读写比例? 关系-存储-浏览, twitter/lifestreaming, 检索- ranking, 挖掘-推荐, 他们的结合? 扁平的树状结构? 还是复杂的网状结构? 产品上的权衡 我的开发者的水平, 习惯 基础架构的用户就是应用开发者 我有多少钱, 多少时间
  15. 15. 搞清我的位置
  16. 16. 设计理念: Google 篇
  17. 17. 设计理念: Google 篇
  18. 18. 设计理念: Google 篇
  19. 19. 设计理念: Google 篇
  20. 20. 设计理念: Google 篇 BigTable Replication across IDC, eventually consistency 服务端编程能力
  21. 21. 设计理念: LiveJournal 篇 LiveJournal: Behind The Scenes, Scaling Storytime Brad Fitzpatrick, April 2007
  22. 22. 设计理念: LiveJournal 篇 LAMM(emcache)P(erl)! 高速成长, 从单机到数百台, scaling!
  23. 23. 设计理念: LiveJournal 篇 LAMM(emcache)P(erl)! 高速成长, 从单机到数百台, scaling! 数据库 Scaling read: replication, master/slave Scaling write: sharding JOIN? Big sorted table? sharding 不是包医百病 
  24. 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. 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. 26. 设计理念: 延伸, 经典模式 RDBMS处理逻辑数据 分离大段文本内容, 珍惜宝贵 的DB资源 Scaling: replication, sharding Key-Value存储存大数据 简单, 易扩展, 性能好 Cache everywhere 多层次, 全方位 Infrastructure MySQL&Memcache&KV cluster PHP host environment Sina App Engine!
  27. 27. 设计理念: Yahoo! 篇 众多的业务, 众多的需求 门户, 搜索, 广告, 邮箱, 社区..... 小数据, 大数据, 在线服务, 离线分析...... 众多的基础构建 MySQL&Oracle UDB, YMDB, PNUTS, Hadoop.... 拥抱开源 大量PHP使用, 定制开源软件, yapache etc. Hadoop! 走向云端 That's what we are talking about!
  28. 28. 设计理念: Yahoo! 篇 Source: Key challenges in cloud computing ...and the Yahoo! approach Raghu Ramakrishnan
  29. 29. 设计理念: Yahoo! 篇 在线服务 依然有很多 MySQL, Oracle, 不可替代, 或没必要迁移 UDB: Dynamo like, YMDB: Media files Sherpa/PNUTS: 托管的可扩展, 关系式存储.
  30. 30. 设计理念: Yahoo! 篇 在线服务 依然有很多 MySQL, Oracle, 不可替代, 或没必要迁移 UDB: Dynamo like, YMDB: Media files Sherpa/PNUTS: 托管的可扩展, 关系式存储. 离线分析 Hadoop HDFS: GFS Pig: 跟Sawzall可不同 HBase? Everest Data warehousing 完全SQL支持 
  31. 31. 小结: 设计里 Google 一层层构建的统一基础架构. 真正的统一平台: 强大的平台极大降低创新门槛. LiveJournal 快速扩展, 随需应变的典范. 运用开源和自制软件的结合. Yahoo! 当你有很多完全不同的应用和老系统...... 不追求完全统一, 具体问题具体分析.
  32. 32. 细节: GFS Key-Value存储 Index, Log 线下应用: 大块低并发写 高吞吐远比低延迟重要 简单设计: Single Master Master容量决定文件数目: 瓶 颈? it depends 单点故障 --- chubby 强一致性 确保写三个replica再返回 部分replica失败下的不一致 --- 非幂等操作是恶魔. chunkserver挂掉超长延时 CAP: C+, P-
  33. 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. 34. 幕后英雄: Chubby 高可用: 如何保证主备一致和正确 自动切换? 主备严格同步确认&心跳 当备连不上主时, 变成主 当他们之间只是网络断掉 当某些client只能连上其中一台 不一致的双 master 当主备连不上的时候 唯一安全的方法就是不再接受提 交, 手工操作检查重起. 可用性比一台机还差! 使用专门心跳电缆和传输线 假定线路完全靠谱. 跨机房就别指望了.
  35. 35. 幕后英雄: Chubby 增加到3台 提交至少得到其他1台确认 使任何操作都得到多数派确认 slave连不上master, 发起选举 投票结果取决于另一台slave与master 的连通 失败: 发起的slave自认倒霉 成功: 原master的提交不再可能得到多 数票. master移交 2N+1台机器, 最多可容忍N台不一致 (挂掉)而保持全局一致. 更多节点具体如何投票确认? Paxos! Paxos made simple & Wikipedia
  36. 36. 幕后英雄: Chubby 每个服务都得来这么一回? 简单点: 锁文件 Master对共享文件加锁, 保证只有一个 master写 如何切换: 租约: Lease 30secs etc, master到期续约 续约不上(网络断, 被抢)让出master, 停 止服务 发现锁因未续约而失效, 分配另外的机器 作为master锁住 Chubby: 可靠的锁服务&小文件存储 Using Paxos... 不是细粒度的事务锁! Developers rarely consider availability
  37. 37. 细节: 论文之后...... GFS的问题 master 单点故障: 从手工恢复到使用 chubby master 文件数量上限 不同的应用模式: 小文件, 大文件量, 从打包到BigTable 分区: 使用多套 GFS 共同使用, 共享同一堆chunk server 延迟: 基本没救了 BigTable Replication, eventually consistency, 在线服务应用 coprocessors: 应用处理直接运行在服务端最接近数据源处 --- bandwidth AppEngine, DataStore on BigTable Datastore index: 使用户查询在顺序表模型上仅需一次range查 询 常见超慢读写, 就是因为这些设计? Spanner?
  38. 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. 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. 40. 细节: Sherpa/PNUTS Yahoo!’s Hosted Data Serving Platform
  41. 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. 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. 43. Lessons Learned
  44. 44. DO NOT Design for scalability
  45. 45. DO NOT Design for scalability at first
  46. 46. DO NOT Design for scalability at first ``可扩展'' 是有代价的 受限的查询能力 CAP: 宽松的一致性模型让开发者迷惑 不要在还没成长的时候担负成长的烦恼. 为赋新辞强说愁 在力所能及的情况下, 为可扩展做准备 以尽量不影响开发为前提 遵循常用扩展方法和可扩展设计原则
  47. 47. DO NOT Design for scalability at first ``可扩展'' 是有代价的 受限的查询能力 CAP: 宽松的一致性模型让开发者迷惑 不要在还没成长的时候担负成长的烦恼. 为赋新辞强说愁 在力所能及的情况下, 为可扩展做准备 以尽量不影响开发为前提 遵循常用扩展方法和可扩展设计原则 Google App Engine vs. Sina App Engine 对长尾头部应用, 谁都不靠谱: 需要特殊定制和优化 对小网站, 初创企业, 谁更靠谱?
  48. 48. DO NOT Design for scalability at first
  49. 49. 纵向性能提升 提升单机性能 横向扩展? 机器成本...... 我们的特殊国情, 人力成本--, 机器+机位+带宽成本++ 对长尾头部应用下大力气做特殊优化绝对划得来 如果对占最多机器的核心应用单机性能提升30% 就能省20-30%的机器...... 和机位! 那是好多钱......
  50. 50. 纵向性能提升 提升单机性能 硬件 摩尔定律+机器运维成本: 换新的好机器是值的 插满内存槽通常没错 数据库, 看书... OS&基础软件 文件系统选择, 硬件驱动, 配置... readahead, sendfile, epoll... 编译器, 编译选项, tcmalloc... IO 传统硬盘: 避免随机读写 / SSD: 避免随机写. 压缩: CPU 换 IO&带宽. 部署 你的每台机器的 CPU, 内存, IO 都跑满了吗? 混搭部署, PHP纯CPU, Cache纯内存
  51. 51. Design for fault, always 这年头什么都不可靠 硬件不可靠 单机再可靠, 当机器足够多, 你会老是见到机器挂的 所以... 机器少的时候还好, 小心你的硬盘...... 网络不可靠, 仔细设计超时和重试策略 人最不可靠 Bug... Getting real: 你得习惯烂软件质量 靠机制, 不要靠人
  52. 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. 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. 54. 容量可扩展 可用性 可靠性 Design for your developers 高吞吐d 多: 能做的功能/应用/改进更多 快: 应用开发快 好: 一致性 能靠谱地跑起来, 实现产品核心价值 省: 省钱! 易开发 多快好省! 低延迟
  55. 55. 硬件影响设计 Source: Jeff Dean, Designs, Lessons and Advice from Building Large Distributed Systems
  56. 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. 57. 信息组织影响设计 信息爆炸 Thousands: 文件夹, 分类 Millions: Tags, 简单检索 Billions, web scale: 检索! 信息结构 结构化和严格关系模型 纯文本/媒体与无关系 Web: 半结构化, 复杂与不确定关系
  58. 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. 59. 全新挑战 Aggregate, Filter, Rank EVERYTHING in REAL-TIME 推推拉拉的 News feed 只是挑战的开始 跳出纯关系数据模型 灵活可定制的实时检索是基础架构而非添头 计算分析平台成为必须, Map-Reduce 就够了? 经典模式和组件也许不再有效 但基础方法和技术依然
  60. 60. Thank you! Q&A

×