曹刚：门户网站系统运维架构规划设计实战.pptVIP

* * * * * * Presented by, MySQL AB? O’Reilly Media, Inc. 曹刚 2008-10-12 imysql@ 浅析系统架构 主要内容 Myspace发展历程之架构 Sohu社区架构演变以及基本实现 一些典型应用的架构 总结 Myspace 50万用户结构图 Myspace 100-200万用户结构图 Myspace 300万用户结构图 Myspace 1700万用户结构图 Myspace 2600万用户结构图 Sohu社区服务器结构图 临时的解决方案 Cache实现思想 较理想的方案 不同的业务采取不同的架构 Carp算法简介 CARP是一种基于DHT(分布式hash表)思想的hash算法，最初由微软提出，用于实现Web Proxy产品的缓存阵列，目前微软已将此技术作为草案提交给IETF组织等待成为标准。有关CARP技术的全文，可参考： /carp.txt /WhitePapers/Mscarp.pdf 特点： 一：CARP算法相当简单，容易实现； 二：CARP算法在“找路”时只需要一跳，其“找路”算法空间复杂度 是常数级，速度快 三：CARP算法不支持资源的冗余，也就是说其在执行“找路”时，指定要查找的资源只会存储在系统中唯一的一个节点上 四：数据迁移量少，只会涉及从旧服务器至新服务器的迁移，不会有旧服务器到旧服务器的数据迁移。 Amazon s3 环形算法简介 Amazon是DHT算法的一种，由此来实现用户到服务器的定位，具体资料见 /gp/browse.html?node特点： 一：容易进行单点扩容 二：不支持资源的冗余，指定要查找的资源只会存储在系统中唯一的一个节点上 缺点： 一：进行大规模扩容工作量稍大 二：算法复杂，计算效率比carp算法低，实现难度大 总结 对业务需求了解透彻是技术架构的基础 根据业务形态、网络情况选择适合的技术架构方案 根据需求分析合理划分子系统 为系统中不同应用选择适合的硬件 根据情况选择开发环境、开发语言等 总结 根据需求分析定义数据结构、系统接口 进行编码、单元测试 测试（功能测试、压力测试等） 部署方案以及维护方案（数据备份、灾难恢复等） 谢谢大家！ * 大家好，我是来自mysql专家组的曹刚，今天由我和大家分享系统架的一些经验。我们还有来自meg的另外两位成员吴丙烯和大家分享负载均衡 叶金荣分享mysql优化。构我们组织的宗旨：促进MySQL技术的交流和分享，提供企业MySQL培训；推广MySQL数据库的广泛使用，致力于为不同环境下的应用提供贴身全面的解决方案。我们的成员均由各大知名公司知名dba组成 希望今天分享的内容能够为大家以后的工作有所帮助 * * * 早期的myspace仅仅由3台机器组成，2台apache,1台db 当访问量上升的时候，通过添加web服务器来减少服务器压力 一段时间后，数据库服务器也出现负载问题，采取master-slave方式进行访问分担 但是随着数据量增长，在大量的数据中进行查找，删除，添加操作，会消耗更多的磁盘I/O * 为了解决单台服务器数据过多，磁盘I/O问题，myspace进行了垂直分割，将各种功能分拆，不同的功能由不同的组服务器提供服务 MySpace还从存储设备与数据库服务器直接交互的方式切换到SAN（Storage Area Network，存储区域网络）——用高带宽、专门设计的网络将大量磁盘存储设备连接在一起，而数据库连接到SAN * 垂直分割的瓶颈：尽管各个应用高度独立，但随着用户量的增加，应用间的冗余数据越来越大，性能随之急剧下降 Myspace首先采取扩展硬件的方法，对于数据库采用32颗cpu的机器，但是成本随之飙升，对于网站运营带来非常大的难题。 随后，myspace按照100万用户一组进行划分，为用户提供服务。相应的服务器为固定的用户提供服务，每台机器都有blog, 个人资料等数据存储。但是像登陆信息，还是独立的，统一的数据管理。 * 当用户增长到900万-1700万的时候，出现了严重的I/O问题。采取两方面的改造 第一：采用新的SAN设备 第二：增加cache层，减少数据库的sql查询 * 当用户增长到2600万的时候，缓存对于内存的需求量持续上升 因此系统从32位升至64位，能够管理更多的内存 * * 访问方式:采取静态数据生成,每5分钟一次 问题瓶颈：apache磁盘I/O非常高，增加apache会增加数据库负载 软件设计：数据库表设计不合理，一个表对应一个论坛数据，读取数据需要进行大量的排序 初期设计时，删除采用物理删除，造成大量的磁盘碎片 * * 这是