大型互联网架构设计

1、1“大型”网站技术架构探讨2目录大型网站架构的目标与挑战网站架构演变及其技术脉络架构设计理论与原则讨论及总结3大型网站架构的目标与挑战何谓“大型”网站？网站日均流量IP/PVIP 5,972,587 PV 9,376,IP229,680,000 PV2,955,981,IP25,680,000 PV222,132,IP5,532,000 PV25,723,IP300,000 PV747,000没有统一的判断标准，流量大小是一个重要指标日均流量至少IP1,000,000才算大型网站4大型网站架构的目标与挑战何谓“大型”网站？网站内容是否“动态”才是关键5大型网站架构的目标与挑战 移动APP的几个

2、重要指标网站内容是否“动态”才是关键6大型网站架构的目标与挑战网站架构目标与挑战 每个目标背后面临着技术、设计、维护等诸多方面的挑战。 而目标本身的期望值也会根据实际情况进行调整，这也意味着网站架构建设是个不断调整的过程。负载均衡数据备份异地容灾。高速缓存并行计算异地镜像。开发框架多层设计业务分割。7大型网站架构的目标与挑战网站架构演变及其技术脉络架构设计理论与原则讨论及总结8网站架构演变及其技术脉络Step1Web动静态资源分离及其与DB物理分离n优点：“简单”、安全性提高n缺点：存在单点，谈不上高可用性（high availability架构目标）n技术点：应用设计要保证可扩展（frame

3、work很重要Spring/Beetle）、Web Server动/静态资源分离Web Server（ApacheNginxIISJBoss）、Database Server（MysqlOracleRedis）9Step1技术点Web动静态资源分离img,doc,js,css等静态资源使用单独的Web HTTP Server处理请求动态页面静态化处理网站架构演变及其技术脉络10Step2采取缓存处理n优点：简单有效、维护方便n缺点：依然存在单点n技术点：客户端（浏览器）缓存、前端页面缓存、页面片段缓存、本地数据缓存/数据库缓存网站架构演变及其技术脉络减少对网站的访问减少对Web应用服务器的请求

4、减少对数据库的查询减少文件系统I/O操作11Step2技术点客户端（浏览器）缓存技术点说明根据HTTP协议特性，修改Header参数（Cache-Control、Expires、Pragma、Last-Modified、Etag），让浏览器来缓存页面（一些优秀开发框架会对此做透明的封装，例如：Beetle）/Protocols/rfc2616/rfc2616-sec14.html使用HTTP1.1协议，由于http pipelining技术特性，能够使用get请求的决不采取post请求为了节约带宽，压缩页面（Content-Encoding: gzip）；页面各

5、个元素能“小”即“小”，例如：js包压缩，js合并，图片压缩等会话状态信息采取Cookie代替传统使用服务器Sessions对象存储习惯做法；使用Ajax实现页面局部刷新如果可能，可采取浏览器插件技术突破浏览器功能限制，将原本在服务器端运算，尽量迁到浏览器端。ActiveX/Applet/Flash/.HTML5 最值得期待，她的出现必定改变整个Web世界能够让浏览器缓存的数据一定要缓存；浏览器能够处理的运算，决不放在服务器端来处理。网站架构演变及其技术脉络12Step2技术点前端页面缓存采用具备缓存功能的http反向代理服务器作前端页面缓存器，VarnishSquidNcacheAiCach

6、e(商业)【硬件F5】网站架构演变及其技术脉络13Step2技术点页面片段缓存ESI(Edge Side Includes)ESI需要服务器端支持，常见apache(mod_esi)、WebLogic、JSP标签库(JESI)等。网站架构演变及其技术脉络14Step2技术点本地数据缓存需要从数据库系统和Web应用服务器两个层面考虑缓存优化网站架构演变及其技术脉络技术点说明关系数据库系统（如：OracleMySql）Query Cache策略：一般以sql为key来缓存查询结果，尽量不要拼sql，使用PreparedStatement的“？”模式sql；Query Cache大小要根据数据库系统

7、具体情况合理设置，过大只会浪费内存，参考值：128M关系数据库系统Data Buffer策略：就是数据库数据内存缓存器，其访问命中率决定数据库性能，可根据实际物理内存大小适量增大，如：MySql建议buffer值为物理内存60-80%应用服务器Cache包括：对象缓存（例如：对象线程安全，做成单例），更新频率不大数据考虑缓存（如：基表数据、配置文件信息），考虑使用线程池，对象池，连接池等常见java解决方案：mapOSCacheEHCache等15Step3增加机器做HA、数据库读写分离网站架构演变及其技术脉络n优点：增加服务器和HA机制，系统性能及可用性得到保证n缺点：读写分离，增加程序难度

8、，架构变复杂，维护难度增加n技术点：负载均衡、DAL、数据库读写分离16Step3技术点负载均衡网站架构演变及其技术脉络类型说明DNS负载均衡实现简单、有Cache缺乏灵活性，但对分区域（如构建CDN方案）访问简单有效反向代理软件HAProxy、Nginx、Apache、Lighttpd等硬件产品F5、NetScaler等LVS(Linux Virtual Server)/SMART Client自己写代码某些情况下简单有效17Step3技术点数据库读写分离及DAL网站架构演变及其技术脉络读写分离逻辑分批负载均衡失效转移（fail

9、over）数据库分区透明支持两大实现模式：独立Proxy服务器；单独API库文件各个数据库厂商都有自己复制方案常见通用方案：ETL、GoldenGateTJS18Step4CDN、分布式缓存、分库网站架构演变及其技术脉络n优点：异地缓存有效解决不同地方用户访问过慢的问题；分库策略带来网站性能整体提升n缺点：成本大幅增加，架构进一步复杂化，也维护难度进一步增大，架构开始臃肿了n技术点：CDN、分布式缓存、Shard分库19Step4技术点CDN网站架构演变及其技术脉络nCDN(Content Delivery Network)内容分发网络n将网站的内容分发到最接近用户的网络“边缘”，使用户可以就

10、近获取，从而解决互联网网络拥挤的状况，提高用户访问的响应速度。n适合静态内容很多（如：静态页面、图片、视频等）及页面内容实时性要求不高的网站，如：新闻类门户网站nCDN构建可以做的很简单，也可以很复杂，主要根据自己网站实际情况而定20Step4技术点分布式缓存网站架构演变及其技术脉络n本地缓存性能优秀，但容量有限，无伸缩性n采用分布式缓存方案突破容量限制，具备良好伸缩性；但分布式涉及远程网络通信消耗其性能本地缓存来得优秀，并可涉及节点状态维护及数据复制问题，其稳定性和可靠性是个挑战。n目前流行分布式缓存方案：memcached、membase、redis等，基本上当前的NoSQL方案都可以用来

11、做分布式缓存方案21Step4技术点分库网站架构演变及其技术脉络n读写分离（简单有效，前面已介绍）n垂直分区良好的松耦合的模块化设计是垂直分库的前提22Step4技术点分库网站架构演变及其技术脉络n水平分区（Shard）分片Key识别（划分检索依据）是关键是否还有其它招？用NoSql数据库部分替换关系数据库23Step5多个数据中心，向分布式存储和计算的架构体系迈进网站架构演变及其技术脉络n优点：多数据中心，带来更高质量区域服务体验；分布式存储及计算架构有效解决pb级数据量存储、检索及计算性能问题n缺点：架构复杂、数据同步、一致性及系统维护、技能要求等成本十分高n技术点：分布式文件系统、Map

12、/Reduce、Key-Value存储24Step5技术点向分布式存储计算解决方案DFS、Map/Reduce、Key-Value DB网站架构演变及其技术脉络nDFS分布式文件系统，如：LustreHDFSGFSTFSFreeNas等nMap/Reduce算法（计算框架），基本上现有NoSQL数据库中都支持此算法。nKey-Value DB，也作为NoSQL解决方案，如：BigTableTairHbase HyperTable等n提供完整解决方案： Google(GFS|Map/Reduce|BigTable) Apache Hadoop(HDFS|Map/Reduce|HBase) 25凡

13、客关键系统架构凡客关键系统架构26 订单面临的矛盾 数据量倍增响应效率还要更高电子商务订单处理优化分析订单查询服务内存硬盘空间索引应用服务器传统解决方案不能根本上解决问题27热数据DB(SQL Server，NoSQL)冷数据DB(SQL Server，NoSQL)路由服务6个月以上到终结点的冷数据新增热数据2013年订单工作规划第一个重点项目解决方案：订单数据冷热分离查询订单入口读新建修改订单入口写Hadoop(Hadoop(提供数据分析用提供数据分析用) )28基于消息队列的订单处理机制订单处理流程的现有机制订单处理流程的改进方案探讨29订单处理流程的现有机制前台主库后台主库后台只读按频率

14、读串行写读数据写数据串行写按频率读大量数据写入串行写分发复制创建订单服务及应用1N订单同步服务*4订单支付服务*4订单取消服务*2订单转有效服务*3订单拦截服务*2下游系统抓取服务按频率读现有处理现有处理流程存在流程存在问题问题30订单处理流程的现有机制WHY？WHAT？WHERE？The Problems流程流程存在存在问题剖析问题剖析HOW can we solve these problems?31基于消息队列的订单处理机制订单处理流程的现有机制订单处理流程的改进方案探讨32订单处理流程的改进方案使用WCF服务，数据改抓为推；构建基础模块，解耦调用方式。保留windows服务，降低查询频

15、率，查缺补漏，处理失败、异常等情况。使用消息队列，解耦服务依赖，试点验证，选择合适的消息队列。缓存中间数据，减少数据更新，分析业务要求，差别对待一致性。业务业务驱动驱动纠错纠错机制机制通信通信机制机制缓存缓存数据数据Required!Better?解决解决方案方案订单业务的处理是以使用订单业务的处理是以使用windows服务服务从数据库从数据库抓取数据抓取数据的方式的方式驱动驱动根本根本原因原因33订单处理流程的改进方案1.1 使用WCF服务，数据由抓改推Step Step 1 1业务流的服务接口业务流的服务接口实现实现主要任务主要任务风险风险订单同步服务订单转有效服务订单拦截服务下游业务方服

16、务订单新建服务支付同步服务支付请求服务完成原windows服务中业务逻辑的wcf封装各服务按照业务流程组装起来服务调用失败，造成的控制流中断34订单处理流程的改进方案基础模块基础模块解决方案解决方案主要任务主要任务风险风险完成基础模块开发，达到解耦服务调用方式的目的异步调用服务异常时，线程资源的紧缺造成消费方服务阻塞大量发生异常时的控制，放弃调用，保证消费方的线程资源；使用消息队列Factoryvoid Notify(Action del)（统一的事件触发）（统一的事件触发） Handler1（如异步（如异步直接调用）直接调用） Handler2（如写入（如写入消息队列）消息队列）1.2 构建

17、基础模块，解耦调用方式Step Step 1 135订单处理流程的改进方案2 保留windows服务，查缺补漏Step Step 2 2业务流某节点故障？业务流某节点故障？原有原有WindowsWindows服务服务订单同步服务订单转有效服务订单拦截服务下游业务方服务订单新建服务支付同步服务支付请求服务保留windows服务，以较低频率运行，查询长时间未处理的数据处理完成后，同样采用调用服务推送的方式，接续处理流程设置阈值，结合VIMOP监控各处理流程节点长时间未处理数据数据库36订单处理流程的改进方案3.1 使用使用消息队列消息队列，解耦服务依赖，解耦服务依赖Step 3Step 3服务消费

18、方消息队列服务提供方天生的异步处理机制存储转发，消息先写入本地机器，稳定性高消息写与消息同步的资源隔离优点 消息一定能通知到一条消息只通知一次低延迟目标目标问题问题 Queue的选择？MSMQ是否能胜任？消息的丢失，延迟的容忍度？使用开源Queue，可控性更强37订单处理流程的改进方案3.2 使用使用MSMQ，试点验证可行性，试点验证可行性Step 3Step 3几种几种Q的处理能力的处理能力使用MSMQ应用于错误容忍度相对较高的场景做试点（例如：订单拦截服务） 验证MSMQ的处理能力 （weblog的经验，达到 1000W/天的 消息处理量 ）验证MSMQ的消息丢失率验证MSMQ的延迟使用使

19、用MSMQ验证验证38消息队列选择3.3 MSMQ不可行，尝试使用不可行，尝试使用MetaQStep Step 3 3开源开源MetaQ高吞吐量、高可用性、适合大规模分布式系统应用设计初衷：为大规模互联网应用设计的消息中间件公开的性能测试结果https:/ 缓存缓存中间数据，减少数据库更新中间数据，减少数据库更新订单同步服务订单拦截服务订单转有效服务Memcache服务器后台主库技术难点技术难点： 不同业务要求下，数据一致性的控制Step 4Step 440订单处理流程的改进方案解决方案整体拓扑图后台主库Memcache服务器订单同步服务消息队列集群订单转有效服务消息队列集群订单拦截服务前台主

20、库后台主库后台只读按频率读串行写串行写按频率读大量数据写入串行写分发复制创建订单服务及应用1N订单同步服务*4订单支付服务*4订单取消服务*2订单转有效服务*3订单拦截服务*2下游系统抓取服务按频率读改进前改进前改进后改进后现有处理流程现有处理流程New41订单处理流程的改进方案缓存与数据库完全一致性转有效服务拦截服务支付服务取消服务占可定缓存与数据库最终一致性4.2 分析业务要求，差别对待一致性Step 4Step 4MemcacheSQL ServerService1.Gets(key)2.Update3.Sets(key)MemcacheSQL ServerService11.Gets(

21、key)5.Update2.Sets(key)Service23.Notify6.Sets(key)4.Gets(key)42基于消息队列的订单处理机制Hadoop集群架构数据导入方案统计分析方案43Hadoop集群架构NameNode.DataNodeDataNodeDataNodeDataNodeDataNodeDataNodeDataNode总空间：5.51 TB已使用：3.32 TB使用率：60.33%2013-2-1到现在的数据已经导入Hadoop集群44数据导入方案Hadoop集群原始文本存储服务器SqlServer数据库Oracle数据库45数据导入方案具体实施方案Hadoop文

22、件存储设计Hadoop文件归档服务（WCF）原始文本导入Hadoop集群服务46数据导入方案Hadoop文件存储设计历史数据当天数据weblog_2013_v4weblog_2013_04_25_v4设计目的：1、数据实时进入Hadoop集群，便于数据及时分析2、消除因为实时导入产生的小文件block碎片3、提高Hadoop分析效率47数据导入方案Hadoop文件归档服务（WCF）运用程序运用程序运用程序用途：将Hapoop集群里面的小文件合并成一个大文件Hadoop公用WCF48数据导入方案原始文本导入Hadoop集群服务导入Windows服务主服务辅助服务（监控合并文件）49数据导入方案原

23、始文本导入Hadoop集群服务导入Windows服务读取文本日志文件数据初步分析加工Hive接口批量导入方法数据进入Hadoop集群主服务50数据导入方案原始文本导入Hadoop集群服务导入Windows服务数据初步分析加工主服务文本文件数据Hadoop数据渠道来源商品购买搜索关键字移动设备访问新注册用户51数据导入方案原始文本导入Hadoop集群服务监控前一天文件是否全部入集群Hadoop文件归档服务（WCF）前一天文件合并到历史文件辅助监控服务导入Windows服务全部入集群52数据导入方案数据流文本数据分析加工文件归档采集原始文本Hadoop历史数据Hadoop当天数据53统计分析方案H

24、adoop分析愿景深度挖掘用户特征习惯，建立用户模型基于用户模型，做好市场营销推广精准广告投放预警，广告价值最大化Hadoop集群54统计分析方案Hadoop分析模型凡客用户年龄层和购物习惯模型潜在购买用户模型商品价值效应模型Hadoop集群55统计分析方案1、凡客用户年龄层和购物习惯模型从产品表获取商品属性用户年龄层商品属性年龄分类挖掘访问商品的用户信息56统计分析方案1、凡客用户年龄层和购物习惯模型购物习惯冲动型购物理性购物挖掘长期参与各种促销活动下单用户挖掘用户访问频率挖掘不定期参与促销活动极少下单用户57统计分析方案2、潜在购买用户模型潜在购买用户特征加入收藏夹访问具体单品PV超过设定

25、阀值访问单品页时间超过设定阀值加入购物车未下单58统计分析方案3、商品价值效应模型商品价值地域月份性别年龄商品的访问量商品加入购物车数量商品的收藏次数59统计分析方案统计入口HiveMapReduceHadoop集群95%5%60统计分析方案HiveHadoop集群Web界面Hive Web接口统计服务程序Hive Thrift服务WebLog权限和调用日志wcf服务61统计分析方案存在风险Hadoop集群Job程序无专人管理和优化Hadoop集群服务器硬盘空间需求部门临时性数据统计需求耗费时间管理风险进度风险移动平台数据统计分析项目迁移和开发62淘宝系统架构概述淘宝系统架构概述更强，更高，更

26、持久63 架构规定了软件的高层划分及各部分间的交互 架构不是软件，但架构决策体现于软件平台和框架之中 架构的优劣决定了业务应用系统的实施能力和发展空间 技术搭台，业务唱戏 架构搭台，应用唱戏 架构永远在随着业务的发展而变迁 拥抱变化！什么是架构？64B2B架构演化过程1999史前2001石器时代2002中世纪2005工业革命未来星际时代？PerlWebMacropojojdbcVelocityEjbWebXSpringSOAOPEN API云计算 65 Perl，CGI Mysql Apache 服务器在美国，56KModem，远程开发、测试、部署1999-史前时代66 Java服务器使用线程

27、性能比cgi技术使用进程好 Java相比Perl，可维护性好，开发效率高 Java开始在国内流行史前-石器时代原因67 开始使用Java 模板技术采用WebMacro 中间层采用Servlet技术，使用POJO封装业务逻辑和数据访问 使用BizObj对象封装基本业务逻辑和数据访问方法 其它业务对象继承BizObj方法，实现自己的业务逻辑和数据访问方法 使用JDBC访问数据库 Servlet容器使用resin，Web服务器使用Apache2001底-石器时代-www系统682001底-石器时代(续)基于POJO的biz层基于WebMacro的模板技术表现层业务层BizObj业务逻辑方法数据访问方

28、法OfferObj业务逻辑方法数据访问方法MemberObj业务逻辑方法数据访问方法CompanyObj业务逻辑方法数据访问方法基于pojo的Biz层Oracle数据库LDAP数据存储69 表现层仅仅使用模板技术，缺乏MVC框架，导致大量的servlet配置 业务逻辑层和数据访问层耦合，可维护性和可扩展性差 受到EJB风潮的影响石器时代-中世纪原因70 表现层采用WebX 模板技术Velocity 在Turbine基础上开发了自己的服务框架和一系列公共服务 通过一个delegate对象访问业务逻辑层 业务逻辑层使用EJB（SLSB，CMP，DAO等） 通过一个faade对象供表现层delega

29、te访问 Faade对象访问多个SLSB实现的controller对象实现业务逻辑 使用CMP实现单条记录的增加和删除 考虑性能，在CMP之外封装DAO对象通过JDBC访问数据库 EJB服务器使用Weblogic Web服务器使用Apache2002底-中世纪712002底-中世纪（续）搜索引擎Oracle数据库LDAP使用SLSB实现的业务逻辑对象Controlers基于Webx以及Service框架的Web层框架CMP进行单条记录的增加删除，DAO对象查找表现层商业逻辑层数据访问层数据存储delegateFaade72 Turbine的发展缓慢 EJB配置复杂,可维护性差 重量级框架，业务

30、侵入高 高度容器依赖，可测试性差 CMP性能差，导致DAO和CMP并存中世纪-工业革命原因73 表现层使用WebX和Service 框架 Velocity模板技术 自有服务框架及多种公共服务：Form Service，Template Service，Mail Service，Rundata Service，Upload Service等 通过command模式和biz层交互 无状态Web应用，基于cookie实现session，获取线性扩展性 业务逻辑层使用Alibaba Service框架，并且引入spring 框架 Spring容器和Alibaba Service框架无缝集成 AO，BO

31、 使用分布式cache缓存对象 数据访问层 透明的事务处理 引入Hibernate和iBatis，以iBatis为主2005-工业革命742005-工业革命（续）搜索引擎Oracle数据库LDAP基于Spring以及Service框架的biz层框架基于Webx以及Service框架的Web层框架分布式Cache分布式Session基于Spring以及DAO设计模式的数据访问框架表现层商业逻辑层数据访问层数据存储75 数据库成为瓶颈 - 分布式数据库 应用耦合严重 - SOA Pampas平台演化还在继续76 中文站会员数超过2000万 中文站Offer已经超过1.5亿 中文站每天的用户PV已经

32、超过1.6亿 中文站每天新发Offer超过100万 中文站每天重发Offer超过1500万 国际站略少，但是增长迅猛网站的现在77中文站/国际站应用部署图78网站镜像部署图(国际站)中供用户网站运营海外卖家79Load Balance(F5, Alteon)ApacheJbossDatabaseSearch EngineApacheJbossApacheJbossApacheStatic ResourceCacheStorage用户请求处理 80 流量随着用户量而增加 业务的变更频繁 用户行为的收集 产品角色的细分及调整 7 X 24的高可用性互联网的挑战81单击此处编辑版标题样式单击此处编辑

33、版标题样式流量激增流量激增处理用户请求RequestProcessResponseRequestProcessResponseRequestProcessResponse应对的挑战 并发(垂直) 用户数量的增加 使用资源的增加 响应(水平) 处理性能的维持82单击此处编辑版标题样式单击此处编辑版标题样式业务变更业务变更专业化细分之前offer list detailmember company personaltransaction no support专业化细分之后offer Clothing Retail Loanmember Trust Pass Special Markettransa

34、ction alipay paypal83数据挖掘offer repostnew offerbid 行为数据的采集追踪埋点异步收集采集数据的分析数据仓库分析引擎运营团队决策风险行为的控制CTU系统安全团队84单击此处编辑版标题样式单击此处编辑版标题样式网站产品的生命周期产品需求整理架构团队设计开发团队实施质量团队质检运营团队运作用户需求分析团队再细分用户需求分析商业策划市场策划 产品需求分析产品设计网站运营架构团队架构师开发团队程序员项目经理用户体验质量团队测试流程控制运营团队产品运营客户服务角色专业化细分角色专业化细分85业务1业务2业务3避免宕机集群化服务化备份切换维护时间有限新产品发布在

35、线发布叠加式发布用户透明过渡高可用性86 架构是平衡的艺术 不要把简单问题复杂化，也不要把复杂问题简单化 系统架构需要考虑哪些业务要求和质量指标？ 怎样取得平衡？ 分解复杂度 自上而下，分离关注点（总体系统局部） 分配复杂度 用合适的技术、合适的组织来解决问题架构设计理念更多用户更多数据更多功能更少硬件更少人力更少故障质量指标质量指标可用性安全性性能稳定性可维护性87分解业务应用数据合并联动的业务高藕合的数据持续发展插件式扩展能力弱藕合,易于剥离局部可优化调整可测试稳定性高可用性负载均衡线性扩展可被监控架构的考虑要点88业务划分系统细分应用优化架构考虑的方向89销售后台会员管理跟单管理财务管理

36、运营后台Offer审批会员审批类目运营数据采集分析网站前台用户登录用户前台用户后台旺铺、广告社区、论坛合作部门搜索引擎阿里旺旺支付宝总体架构 分解：按不同的业务领域、用户群来分解 分配：将业务需求分配到各个 系统/服务可独立部署和维护，它们之间多采用分布式交互业务划分(总体架构)90会员体系运营体系业务体系业务划分(总体架构)91系统架构表现层WebXVelocitySpring MVC业务逻辑层IOC (Spring)SOA (Pampus)EJB数据访问层iBatisCMPJMS工具安全容错管理监控日志Build系统架构 分解：按不同的技术层次来分解 分配：将技术需求分配到各个 容器/框架

37、通过特定的技术模式来透明或半透明地解决技术问题92网站应用系统BOPS系统资源系统系统细分93应用优化存储系统DACSANNAS搜索引擎全文索引目录索引数据库索引数据复制水平分割垂直分割Cache内容静态化数据库缓存对象缓存客户端缓存局部调优（数据存取） 分解：按数据的位置、读写、计算特性等分解 分配：将数据分配到各个 不同的存储技术适合于不同的数据存取需求94读写应用优化95 总体架构 考虑面向服务体系 系统架构 更加专业化、服务化的信息收集系统 更加全面化、自动化的配置管理 更加有效率的镜像同步、切换 局部应用优化 分布式文件系统 优化数据同步系统 读写分离展望未来96 架构随着业务发展不

38、断演进 架构发展要有方向有节奏总结97大型网站架构的目标与挑战网站架构演变及其技术脉络架构设计理论与原则讨论及总结98架构设计理论与原则网站架构设计的精神食粮99架构设计理论与原则关于数据一致性ACID vs BASE nACID（ Atomicity 、 Consistency 、 Isolation 、 Durability ）是关系型数据库的最基本原则，遵循ACID原则强调一致性，对成本要求很高，对性能影响很大。n问题：ACID原则适用于互联网应用吗？可用性似乎比一致性重要些nBASE（ Basically Available 、 Soft state 、 Eventually cons

39、istent ）策略BASE策略与ACID不同，其基本思想就是通过牺牲强一致性，以获得更好的可用性或可靠性基本可用数据能够保证80%一致性就够了，剩下20%就不要过于纠结了。可参考八二定律软状态在不过分追求数据一致性（强一致性）前提下可考虑软状态策略，例如把数据缓存（State）在客户端一段时间，过后若没有新请求的话，就清除此缓存（Soft）最终一致性在某一段短时间内允许数据不一致，但经过一段较长时间，等所有节点上数据的拷贝都整合在一起的时候，数据会最终达到完全一致100架构设计理论与原则关于分布式系统CAP理论 一致性分布式系统中，数据一般会存储在不同节点，一致性就是要保证对数据操作的原子性

40、可用性确保客户访问数据时可得到响应。不强调各个节点上数据要保持一致性。分区容忍性数据分区存储后，即使部分分区组件不可用，其施加的操作也能够完成CAP理论指出：一个分布式系统不可能同时满足一致性、可用性和分区容忍性这三项需求，最多只能同时满足其中两个。101架构设计理论与原则无共享架构（Share Nothing Architecture） 102架构设计理论与原则ED-SOA架构 nED-SOA，事件驱动，面向服务架构nSOA是系统组件化、模块化构建性理论；ED是系统组件之间同步通信，采取事件机制异步化，提高响应速度n基于ED-SOA构建松耦合系统可以显著改善网站可伸缩性架构进化与退化-奥卡姆

41、剃刀原理n进化寻找最适合的；退化简化不必要的n简单就好，慎防过渡设计103架构设计理论与原则考量成本，先硬后软原则 104大型网站架构的目标与挑战网站架构演变及其技术脉络架构设计理论与原则讨论及总结105讨论及总结大型网站架构是怎么样子的？ 存在万能的架构吗？架构本质是什么？ 网站架构如何选型？开发语言重要吗？ 架构只是浮云？神马才是重要的？。 106高并发高负载系统架构如何用JavaJava进行高性能网站开发107目录1.进行高并发和高负载的研究2.高并发和高负载的约束条件3.解决之道硬件篇4.解决之道部署篇5.解决之道环境篇6.解决之道SiteEngine篇7.解决之道测试篇8.结尾108

42、为什么要进行高并发和高负载的研究1. 产品发展的需要2. 公司发展的需要3. 当前形式决定的109高并发和高负载的约束条件1、硬件2、部署3、操作系统4、Web 服务器5、PHP6、MySQL7、测试110解决之道硬件篇处理能力的提升：部署多颗CPU，选择多核心、具备更高运算频率、更大高速缓存的CPU；处理能力的提升最直接的反应在于Web请求的处理效率和PHP程序的执行效率。内存带宽与容量：更大的内存带宽和容量；内存带宽与容量的提升最直接的反应在于应对数据库大量的数据交换。磁盘搜索与I/O能力：选择更高的转速、更大的硬盘缓存、组件磁盘阵列（RAID）；磁盘搜索与I/O能力的提升最直接反应在于数

43、据库大量的查询和读写以及文件的读写。网络带宽的提升可考虑的因素包括： 更大带宽、多线路接入、独享带宽；服务器在大负载的情况下，对网络带宽的占用是十分可观的。策略：硬件设施是应对大负载的基础，硬件设施的投入可根据实际压力和预算量力而行。111解决之道部署篇1、服务器分离2、数据库集群和库表散列3、镜像4、负载均衡分类：1)、DNS轮循2）代理服务器负载均衡 3）地址转换网关负载均衡 4）NAT负载均衡 5）反向代理负载均衡 6）混合型负载均衡策略：根据硬件投入和业务需求，选择合理的部署方案。112解决之道部署篇方案一适用范围：静态内容为主体的网站和应用系统；对系统安全要求较高的网站和应用系统。M

44、ain Server：主服务器承载程序的主体运行压力，处理网站或应用系统中的动态请求；将静态页面推送至多个发布服务器；将附件文件推送至文件服务器；安全要求较高，以静态为主的网站，可将服务器置于内网屏蔽外网的访问。DB Server：数据库服务器承载数据库读写压力；只与主服务器进行数据量交换，屏蔽外网访问。File/Video Server：文件/视频服务器承载系统中占用系统资源和带宽资源较大的数据流；作为大附件的存储和读写仓库；作为视频服务器将具备视频自动处理能力。发布服务器组：只负责静态页面的发布，承载绝大多数的Web请求；通过Nginx进行负载均衡部署。113解决之道部署篇方案二适用范围：

45、以动态交互内容为主体的网站或应用系统；负载压力较大，且预算比较充足的网站或应用系统；Web服务器组：Web服务无主从关系，属平行冗余设计；通过前端负载均衡设备或Nginx反向代理实现负载均衡；划分专用文件服务器/视频服务器有效分离轻/重总线；每台Web服务器可通过DEC可实现连接所有数据库，同时划分主从。数据库服务器组：相对均衡的承载数据库读写压力；通过数据库物理文件的映射实现多数据库的数据同步。共享磁盘/磁盘阵列将用于数据物理文件的统一读写用于大型附件的存储仓库通过自身物理磁盘的均衡和冗余，确保整体系统的IO效率和数据安全；方案特性：通过前端负载均衡，合理分配Web压力；通过文件/视频服务器

46、与常规Web服务器的分离，合理分配轻重数据流；通过数据库服务器组，合理分配数据库IO压力；每台Web服务器通常只连接一台数据库服务器，通过DEC的心跳检测，可在极短时间内自动切换至冗余数据库服务器；磁盘阵列的引入，大幅提升系统IO效率的同时，极大增强了数据安全性。114解决之道环境篇1、操作系统2、Web服务器3、Mysql4、PHP5、代理服务器（缓存服务器）115解决之道环境篇操作系统操作系统的选择，关注点在于 是否适应于搭建SiteEngine所需要的环境程序？ 系统本身占用的资源比； 系统安全性； 系统是否易于操作？策略：我们选择FreeBSD，而且是最小化安装以后的FreeBSD。1

47、16解决之道环境篇Web服务器Web服务器很大一部分资源占用来自于处理Web请求，通常情况下这也就是Apache产生的压力，Apache是世界使用排名第一的Web服务器软件。它可以运行在几乎所有广泛使用的计算机平台上。在高并发连接的情况下，Nginx是Apache服务器不错的替代品。Nginx (“engine x”) 是俄罗斯人编写的一款高性能的 HTTP 和反向代理服务器。在国内，已经有新浪、搜狐通行证、网易新闻、网易博客、金山逍遥网、金山爱词霸、校内网、YUPOO相册、豆瓣、迅雷看看等多家网站、频道使用 Nginx 服务器。Nginx的优势：高并发连接：官方测试能够支撑5万并发连接，在实

48、际生产环境中跑到23万并发连接数。 内存消耗少：在3万并发连接下，开启的10个Nginx 进程才消耗150M内存（15M*10=150M）。 内置的健康检查功能：如果 Nginx Proxy 后端的某台 Web 服务器宕机了，不会影响前端访问。 策略：相对于老牌的Apache，我们选择Lighttpd和Nginx这些具有更小的资源占用率和更高的负载能力的web服务器。117解决之道环境篇MysqlMySQL本身具备了很强的负载能力，MySQL优化是一项很复杂的工作，因为这最终需要对系统优化的很好理解。大家都知道数据库工作就是大量的、短时的查询和读写，除了程序开发时需要注意建立索引、提高查询效率

49、等软件开发技巧之外，从硬件设施的角度影响MySQL执行效率最主要来自于磁盘搜索、磁盘IO水平、CPU周期、内存带宽。根据服务器上的硬件和软件条件进行MySQl优化。MySQL优化的核心在于系统资源的分配，这不等于无限制的给MySQL分配更多的资源。在MySQL配置文件中我们介绍几个最值得关注的参数：改变索引缓冲区长度(key_buffer) 改变表长(read_buffer_size) 设定打开表的数目的最大值(table_cache) 对缓长查询设定一个时间限制(long_query_time) 如果条件允许 ，一般MySQL服务器最好安装在Linux操作系统中，而不是安装在FreeBSD中

50、。策略： MySQL优化需要根据业务系统的数据库读写特性和服务器硬件配置，制定不同的优化方案，并且可以根据需要部署MySQL的主从结构。118解决之道环境篇PHP1、加载尽可能少的模块；2、如果是在windows平台下，尽可能使用IIS或者Nginx来替代我们平常用的Apache；3、安装加速器（都是通过缓存php代码预编译的结果和数据库结果来提高php代码的执行速度） eAcceleratoreAccelerator是一个自由开放源码php加速器，优化和动态内容缓存，提高了性能php脚本的缓存性能，使得PHP脚本在编译的状态下，对服务器的开销几乎完全消除。ApcAlternative PHP

51、 Cache（APC）是 PHP 的一个免费公开的优化代码缓存。它用来提供免费，公开并且强健的架构来缓存和优化 PHP 的中间代码。memcachememcache是由Danga Interactive开发的，高性能的，分布式的内存对象缓存系统，用于在动态应用中减少数据库负载，提升访问速度。主要机制是通过在内存里维护一个统一的巨大的hash表，Memcache能够用来存储各种格式的数据，包括图像、视频、文件以及数据库检索的结果等Xcache国人开发的缓存器，策略： 为PHP安装加速器。119解决之道环境篇代理服务器Squid Cache（简称为Squid）是一个流行的自由软件（GNU通用公共许

52、可证）的代理服务器和Web缓存服务器。Squid有广泛的用途，从作为网页服务器的前置cache服务器缓存相关请求来提高Web服务器的速度，到为一组人共享网络资源而缓存万维网，域名系统和其他网络搜索，到通过过滤流量帮助网络安全，到局域网通过代理上网。Squid主要设计用于在Unix一类系统运行。策略：安装Squid 反向代理服务器，能够大幅度提高服务器效率。120解决之道环境篇总结推荐的服务器环境配置：操作系统：FreeBSD web服务器：Nginx程序语言： PHP+ Zend Optimizer+ eAccelerator数据库： MySQL 121解决之道SiteEngine篇SiteE

53、ngine 历史上为了解决高并发高负载做了那些工作：1、静态化；2、缓存；3、内存表；4、定长表；5、尽可能少用join 还有IN。122解决之道SiteEngine篇SiteEngine在实施高并发高负载中出现的问题：SiteEngine在前期的发展中，一直是面向通用型的中小网站来设计的。从底层上就有不适应高并发高负载的机制存在。具体表现在：1、原有缓存功能，特别是类别的缓存无用武之地；2、无用的sql查询和sql查询的效率问题；3、多语言设计导致很多查询都变得复杂，导致效率低下；4、Mysql中的查询方法太多；5、前台的动态交互太少。123解决之道SiteEngine篇为了让SiteEng

54、ine更好的适应高并发高负载的环境。主要从以下几个方面进行改进：1、加入Memcache 缓存技术；2、开发一套精简版高效率的SiteEngine开发框架，专门应对系统开发；3、 MySQL数据库考虑转为innodb数据引擎；4、前台更大量的加入Ajax元素；5、改变类别模式或者改变类别算法，取消类别缓存机制；6、成立专门的研发部门，将项目开发和软件研发分开；7、加强测试和团队合作。124解决之道测试篇1、测试方法2、测试用例3、压力测试压力测试是一种基本的质量保证行为，它是每个重要软件测试工作的一部分。压力测试的基本思路很简单：不是在常规条件下运行手动或自动测试，而是在计算机数 量较少或系统

55、资源匮乏的条件下运行测试。通常要进行压力测试的资源包括内部内存、CPU 可用性、磁盘空间和网络带宽等。一般用并发来做压力测试。压力测试工具：webbench，ApacheBench等3、漏洞测试在我们的系统中漏洞主要包括：sql注入漏洞，xss跨站脚本攻击等。安全方面还包括系统软件，如操作系统漏洞，mysql、apache等的漏洞，一般可以通过升级来解决。漏洞测试工具：Acunetix Web Vulnerability Scanner125结尾在系统的开发过程中和项目实施过程中，大家肯定能够得到很大程度的提升，但是要真正解决高并发和高负载的问题，并不能立竿见影，还需要大家真真正正一点一滴的去

56、了解问题，思考解决方法，不断尝试，不断创新，这个过程是漫长而又艰苦的。还希望我们全体公司成员团结一致、群策群力，为实现我们的目标艰苦奋斗，去开创属于我们大家更美好的明天。谢谢！126高并发高负载系统架构如何用JavaJava进行高性能网站开发127生成对象时，合理分配空间和大小：Java中的很多类都有它的默认的空间分配大小，对于一些有大小的对象的初始化，应该预计对象的大小，然后使用进行初始化。例如：我们在使用Vector，当声明Vector vectnew Vector()时，系统调用：public Vector() / 缺省构造函数this(10); / 容量是 10;缺省分配10个对象大小

57、容量。当执行add方法时，可以看到具体实现为：.public synchronized boolean add(Object o) modCount+;ensureCapacityHelper(elementCount+1);elementDataelementCount+ =o;return true;Java程序性能优化程序性能优化技巧技巧128生成对象时，合理分配空间和大小：private void ensureCapacityHelper(int minCapacity) int oldCapacity = elementData.length;if (minCapacity oldC

58、apacity) Object oldData = elementData;int newCapacity = (capacityIncrement 0) ? (oldCapacity + capacityIncrement) :(oldCapacity * 2);if (newCapacity minCapacity) newCapacity = minCapacity;elementData = new ObjectnewCapacity;System.arraycopy(oldData, 0, elementData, 0, elementCount);我们可以看到，当Vector大小超

59、过原来的大小时，一些代码的目的就是为了做容量的扩充，在预先知道该Vector大小的话，可以指定其大小，避免容量扩充的开销。 Java程序性能优化程序性能优化技巧技巧129优化循环体：循环是比较重复运行的地方，如果循环次数很大，循环体内不好的代码对效率的影响就会被放大而变的突出。让我们看看下面的代码片：.Vector vect = new Vector(1000);.for( inti=0; ivect.size(); i+).for循环部分改写成：int size = vect.size();for( int i=0; isize; i+).如果size=1000，就可以减少1000次size

60、()的系统调用开销，避免了循环体重复调用。Java程序性能优化技巧程序性能优化技巧130优化循环体：再看如下的代码片：.for (int i = 0;i 100000;i+)if (i%10 = 9) . / 每十次执行一次改写成也可以提高效率：.for(inti =0,j =10; i100000; i+,j-)if(j = 0). / 每十次执行一次j = 10;所以，当有较大的循环时，应该检查循环内是否有效率不高的地方，寻找更优的方案加以改进。 Java程序性能优化技巧程序性能优化技巧131少用newnew初始化一个实例：尽量少用new来初始化一个类的实例，当一个对象是用new进行初始化