1 / 32

高并发服务端分布式系统设计介绍

高并发服务端分布式系统设计介绍. 高性能高并发 分布式计算、存储 大数据处理 NoSQL. Jone 2013.10. 应用场景. 日均千万级以上 PV(Page View) 高并发和大量峰值请求据处理 PB 级别的海量数据处理. 好用但是也好麻烦. 数据同步 数据备份 数据恢复、迁移 扩展. 目前较成熟的一些产品. Google FS + Map-Reduce + Big-table Hadoop + HBase Casssandra (Facebook & Apache) Dymano (Amazon)

crete
Download Presentation

高并发服务端分布式系统设计介绍

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 高并发服务端分布式系统设计介绍 • 高性能高并发 • 分布式计算、存储 • 大数据处理 • NoSQL Jone 2013.10

  2. 应用场景 • 日均千万级以上PV(Page View) • 高并发和大量峰值请求据处理 • PB级别的海量数据处理

  3. 好用但是也好麻烦 • 数据同步 • 数据备份 • 数据恢复、迁移 • 扩展

  4. 目前较成熟的一些产品 • Google FS + Map-Reduce + Big-table • Hadoop + HBase • Casssandra (Facebook & Apache) • Dymano (Amazon) • OceanBase TFS Tair (Taobao)

  5. 为什么需要这样的系统—— 网站架构演变 最初：一台webserver，网页直接访问， 所有业务、逻辑、数据都在这台机器上。 100PV Web Web Server

  6. 为什么需要这样的系统—— 网站架构演变 稍后：一台webserver，一台数据库。 逻辑和数据开始分离，如经典的LAMP结构。 Web 1000~10000PV MySQL Server Web Server

  7. 为什么需要这样的系统—— 网站架构演变 再稍后：静态页面缓存、简单的数据缓存， 视图，逻辑，数据分离，如典型的MVC结构。 Static Page Cache, pictures, css…. Web PV Web Server MySQL Server

  8. 为什么需要这样的系统—— 网站架构演变 再再稍后：更多Web服务器，数据库分库或 读写分离，缓存服务器。 Static Page Cache, pictures, css…. Web CacheServer PV Web Server MySQL Server

  9. 为什么需要这样的系统—— 网站架构演变 日均百万PV已经面临较大性能挑战， 需要良好的架构和负载均衡。 Static Page Servers Web ReverseServer e.g: Nigix PV MySQL Server Cache Servers Real Web Server 2007~2008

  10. 为什么需要这样的系统—— 网站架构演变 千万级PV: 大型分布式系统登场 PV

  11. 一些必要的分布式概念 CAP理论： Consistency：一致性 ——所有节点在同一时间具有相同的数据 Availability：可用性 ——每个请求不管成功或者失败都有响应 （能在确定时间内返回） Partition tolerance：分隔容忍性 ——网络出现分隔（分区）时仍能满足一致性 和可用性 CAP三者不能同时满足

  12. 一些必要的分布式概念 实际工程中的CAP概念的应用： 有强一致性和弱一致性（含最终一致性） ——强一致性，可以保证C和P 各个节点数据一致，为保证P，出现故障时无法保证 A（可用性） ——弱一致性（含最终一致性） 各个节点数据可能出现短时间的不一致，但最终能 够同步。保证了A和P。

  13. 一些必要的分布式概念 强一致性系统的应用： 不能丢失数据的实时系统： 如淘宝购物车等涉及Money、订单、Business的系统 特点： 并不存在读 >> 写，可以认为读写需求是同等的。 任何读必须等待最新的写完成并同步至所有节点。 保证强一致性的系统，认为其是“完全同步”的。

  14. 一些必要的分布式概念 弱一致性（最终一致性）系统的应用： 短时间内节点数据不同步可以容忍，但最终能同步 一致。同时读需求远大于写，写节点挂掉需要一定 时间来恢复。 如各种微博，SNS，消息，邮件等 特点： 读 >> 写，不同节点可能读到老数据，但最终能够同 步。 通常采用“半同步”的做法。

  15. 一些必要的分布式概念 NWR： N指数据需要存储（备份）N份 W指一个写请求最少需要在W个节点上完成才算成功 R指一个读请求最少需要在R个节点上完成才算成功 显然N, W, R至少为1才有意义 W + R > N：强一致性 W + R < N：弱一致性（最终一致性）

  16. 一些必要的分布式概念 分布式选举和Paxos算法：序号最大者胜 简单理解： 基本条件：一堆分布式节点，有一个主节点，剩下的 为从节点。主节点数据最新（认为其序号最大）， 从节点向主节点来同步数据，同步中数据不断更新 （序号也增大） 进行选举：主节点挂了。需要选举产生一个主节点。 显然谁序号最大（数据最新）将是最接近挂掉的主节 点的，它将当选为新的主节点。

  17. 一些必要的分布式概念 一致性Hash算法（环形）

  18. 一些必要的分布式概念 一致性Hash算法（环形）

  19. 一些必要的分布式概念 一致性Hash算法（环形）

  20. 分布式计算和存储的主要思想—— 拆分 如何分？ ——垂直拆分： 不同的数据，放到不同的节点上处理，把业务拆分。 垂直扩展：新业务增加新节点，不影响其它。 ——水平拆分： 相同的数据，放到不同的节点上处理，把压力拆分。 水平扩展：新压力增加新节点，与之前的节点协同 工作。

  21. 开始设计—— 高并发服务端分布式系统 概要设计： http://cnblogs.com/ccdev 有类似设计的开源实现： 淘宝的Oceanbase https://github.com/alibaba/oceanbase/

  22. 开始设计 以组（Group）来完成一个业务，处理该业务的逻辑 和数据。

  23. 开始设计 • 以弱一致性（最终一致性）系统为例 • 一个组有一个主节点，N个从节点 • 只有主节点能写，但所有节点都能读 • 主节点写的时候，采用“半同步”，除主节点外， • 至少有一个从节点和主节点同步成功，主才能返回写 • 成功。即任何时刻至少有一个从节点和主节点同步 • 主节点挂掉，由分布式选举可以找到至少一个和 • 主节点同步的从节点，由它成为新的主节点 • 所有从节点都会不断向主节点同步更新数据，若经 • 过一段时间没有写请求，所有节点都会同步一致

  24. 开始设计 • 组内有备份节点，一旦有任何节点挂掉，备份节 • 点开始工作并不断从主节点“偷”数据来同步自己，避 • 免“雪崩”。 • 组内可采用“一致性Hash算法”来分担压力，所以 • 可以方便地扩展新节点 • 主节点数据更新，通知所有从节点来更新数据 • “心跳”服务

  25. 开始设计 • 一个系统由多个组构成，由全局节点（Global）来 • 管理各个组

  26. 开始设计 • Global Master节点： • （1）管理系统全局配置，发送全局控制信息； • （2）监控各个group的工作状态，提供心跳服务，若 • 发现宕机，通知该group发起分布式选举产生新的 • 组内主节点； • （3）处理Client端首次到达的请求，找出负责处理该 • 请求的组并将此组的信息（location）返回， • 则来自同一个前端请求源的该类业务请求自第二次 • 起不需要再向Global Master查询组信息（缓存机制）； • （4）保持和Global Slave的强一致性同步，保持自身健 • 康状态并向全局的“心跳”服务验证自身的状态。

  27. 开始设计 • Global Slave节点： • 采用完全同步和Global Master节点保持“强一致性” • 如果Global master挂掉，可随时切换成为新的Global • Master节点 • 全局“心跳”服务 • 监控Global节点的状态 保证系统健康工作 • Global节点并不承担实际的压力，实际的压力在各 • 个组内

  28. 开始设计

  29. GFS的架构

  30. 分布式系统设计 大概的做法很好想，完全没有问题的做法很难想。

  31. 参考资料： • 我的文章：http://cnblogs.com/ccdev • 淘宝Oceanbase: • https://github.com/alibaba/oceanbase/tree/oceanbase_0.4/src • The Google file system. • [1] http://nosql-database.org/ • [2] http://highscalability.com/ • [3] Hadoop: Open source implementation of MapReduce. • http://lucene.apache.org/hadoop/ • [4] http://en.wikipedia.org/wiki/Two-phase_commit_protocol • [5] http://codahale.com/you-cant-sacrifice-partition-tolerance/ • [6] http://blog.nosqlfan.com/

  32. Thank you!

More Related