这篇文章主要介绍“MySQL大型网站技术架构核心原理是什么”，在日常操作中，相信很多人在mysql大型网站技术架构核心原理是什么问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”mysql大型网站技术架构核心原理是什么”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！

成都创新互联公司2013年成立，先为错那等服务建站，错那等地企业，进行企业商务咨询服务。为错那企业网站制作PC+手机+微官网三网同步一站式服务解决您的所有建站问题。

一、大型网站架构演化

A.大型网站软件系统的特点

高并发，大流量；高可用；海量数据；用户分布广泛，网络情况复杂；安全环境恶劣；需求快速变更，发布频繁；渐进式发展；

B.大型网站架构演化发展历程

1.初始阶段：一台服务器，LNMP

2.应用服务和数据服务分离：应用服务器（CPU）；数据库服务器（快速磁盘检索和数据缓存）；文件服务器（大硬盘）；

3.使用缓存改善网站性能：缓存在应用服务器上的本地缓存（访问速度快，受应用服务器内存限制，数据量有限）、远程分布式缓存（使用集群部署大内存的服务器作为专门的缓存服务器）

4.应用服务器集群：通过负载均衡调度

5.数据库读写分离

6.使用反向代理和CDN加速：cdn（部署在最近的网络机房）、反向代理 （部署在中心机房）

7.使用分布式文件系统和分布式数据库系统

8.使用NOSQL和搜索引擎

9.业务拆分

10.分布式服务

C.大型网站架构演化的价值观

1.大型网站架构技术的核心价值是随网站所需灵活应对

2.驱动大型网站技术发展的主要力量是网站的业务发展

D.网站架构设计误区

1.一味追随大公司的解决方案

2.为了技术而技术

3.企图用技术解决所有问题：技术是用来解决业务问题的，而业务的问题，也可以通过业务的手段去解决

二、大型网站架构模式

模式：每一个模式描述了一个在我们周围不断重复发生的问题及该问题解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复工作。模式的关键在于模式的可重复性。

A.网站架构模式

1.分层

• 分层：是企业应用系统中最常见的一种架构模式，将系统在横向维度上切分成几个部分，每个部分负责一部分相对比较单一的职责，然后通过上层对下层的依赖和调用组成一个完整的系统。

• 将网站软件系统分为应用层（视图层、业务逻辑层）、服务层（数据接口层、逻辑处理层）、数据层

• 可以更好地将一个庞大的软件系统切分成不同的部分，便于分工合作开发和维护；各层之间具有一定的独立性，只要维持调用接口不变，各层可以根据具体问题独立深化发展而不需要其他层必须 做出相应调整。

2.分割

• 纵向方面进行切分。将不同的功能和服务分割开来，包装成高内聚低耦合的模块单元。大型网站分割的粒度可能会很小。

3.分布式

• 即将不同的模块部署在不同的服务器上，通过远程调用协同工作。意味着可以使用更多的计算机完成同样的功能。

• 问题：通过网络可能会对性能造成严重影响；服务器多宕机的概率大；数据在分布式的环境中保持数据一致性也非常困难；导致网站依赖错综复杂开发被处理维护困难；

• 常见的分布式方案：分布式应用和服务；分布式静态资源；分布式数据和存储；分布式计算（Hadoop及其MapReduce）；分布式配置；分布式锁；分布式文件等；

4.集群

• 多台服务器部署相同应用构成一个集群，通过负载均衡设备共同对外提供服务。

5.缓存

• 缓存就是将数据有些话在距离计算最近的位置以加快处理速度。

• CDN、反向代理、本地缓存、分布式缓存。

• 使用缓存的两个前提条件：一是数据访问热点不均衡；二是数据在某个时间段内有效；

6.异步

• 业务之间的消息传递不是同步调用，而是将一个业务操作分成多个阶段，每个阶段之间通过共享数据的方式异步执行进行协作。

• 单一服务器内部可通过多线程共享内存队列的方式实现异步；分布式系统中，多个服务器集群通过分布式消息队列实现异步。

• 典型的生产者消费者模式，两者不存在直接调用，特性：提高系统可用性；加快网站响应速度；消除并发访问高峰。

• 使用异步方式处理业务可能会对用户体验、业务流程造成影响，需要产品设计方面的支持。

7.冗余

• 要想保证在服务器宕机的情况下网站依然可以继续服务，不丢失数据，就需要一定程度的服务器冗余运行，数据冗余备份。

• 小型网站也需要至少两台服务器构建集群，数据库除定期备份保存实现冷备份外，也需要进行主从分享实时同步热备。

• 大型公司可能会对整个数据中心备份并同步到各地灾备中心。

8.自动化

• 主要集中在发布运维方面。

• 发布过程自动化：自动化代码管理、自动化测试、自动化安全检测、自动化部署。

• 自动化监控：自动化报警、自动化失效转移、自动化失效恢复、自动化降级、自动化分配资源。

9.安全

B.架构模式在新浪微博的应用

三、大型网站核心架构要素

架构：最高层次的规划，难以改变的决定。

软件架构：有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。

A.性能

• 浏览器端：浏览器缓存、页面压缩、合理布局、减少Cookie传输、CDN等

• 应用服务器端：服务器本地缓存、分布式缓存、异步操作与消息队列配合、集群等

• 代码：多线程、改善内存管理等

• 数据库：索引、缓存、SQL优化、NoSQL技术

B.可用性

• 服务器、数据库及文件存储等运行环境的主要手段是冗余。

• 软件开发时通过预发布验证、自动化测试、自动化发布、灰度发布等手段

C.伸缩性

• 伸缩性是指通过不断向集群中加入服务器的手段来缓解不断上升的用户并发访问压力和不断增长的数据存储需求。加入新的服务器是否可以提供和原来的服务器无差别的服务。

• 应用服务器：通过合适的负载均衡设备可以向集群中不断加入服务器。

• 缓存服务器：加入新的可能会导致缓存路由失效。需要路由算法。

• 关系数据库：通过路由分区等手段。

D.扩展性

• 衡量标准：网站增加业务产品时，是否可以实现对现有产品透明无影响；不同产品这间是否很少耦合；

• 手段：事件驱动架构（消息队列）、分布式服务（将业务和可利用服务分享，通过分布式服务框架调用）

E.安全性

四、瞬时响应：网站的高性能架构

A.网站性能测试

1.不同视角

• 用户视角的网站性能：优化页面HTML样式、利用浏览器端的并发和异步特性、调整浏览器缓存策略、使用CDN服务、反射代理等。

• 开发人员视角的网站性能：使用缓存加速数据读取、使用集群提高吞吐能力、使用异步消息加快请求响应及实现削峰、使用代码优化手段改善程序性能。

• 运维人员视角的网站性能：建设优化骨干网、使用高性价比定制服务器、利用虚拟化技术优化资源利用等。

2.性能测试指标

• 响应时间：测试办法是重复请求，测试一万次总时间之和除以一万。

• 并发数：系统能够同时处理请求的数目（网站系统用户数>>网站在线用户数>>网站并发用户数），测试程序通过多线程模拟并发用户的办法来测试系统的并发处理能力。

• 吞吐量：单位时间内系统处理的请求数量（TPS、HPS、QPS等）

• 性能计数器：描述服务器或操作系统性能的一些数据操纵杆。包括System Load、对象与线程数、内存使用、CPU使用、磁盘与网络I/O等。

3.性能测试方法：性能测试、负载测试、压力测试、稳定性测试

4.性能测试是一个不断对系统增加访问压力，以获得系统性能指标、最大负载能力、最大压力承受能力的过程。所谓增加访问压力，就是不断增加测试程序的并发请求数。

5.性能优化策略

• 性能分析：检查请求处理的各个环节的日志，分析哪个环节响应时间不合理、超过预期；然后检查监控数据 。

B.Web前端性能优化

1.浏览器访问优化：减少http请求（合并CSS/JS/图片）、使用浏览器缓存（HTTP头中Cache-Control和Expires）、启用压缩 （Gzip）、CSS放在页面最上面JS放在页面最下面、减少Cookie传输

2.CND加速

3.反向代理：通过配置缓存功能加速Web请求。（还可以保护真实服务器及实现负载均衡的功能）

C.应用服务器性能优化

1.分布式缓存

• 网站性能优化第一定律：优先考虑使用缓存优化性能

• 主要用来存放那些读写比很高、很少变化的数据。缓存无法命中时读取数据库并将数据再写入缓存。

2.合理使用缓存：不要频繁修改的数据、没有热点的访问、数据不一致与脏读、缓存可用性（缓存热备）、缓存预热（在程序启动时预先加载一些缓存）、缓存穿透

3.分布式缓存架构：需要更新同步的分布式缓存（JBoss Cache）、不互相通信的分布式缓存（Memcached）

4.异步操作：使用消息队列（可改善网站的扩展性和性能），具有很好的削峰作用，将短时间高并发产生的事务消息存储在消息队列中。

5.使用集群

6.代码优化：

• 多线程（IO阻塞与多CPU，启动线程数=[任务执行时间/(任务执行时间-IO等待时间)]*CPU内核数，需要注意线程安全：将对象设计为无状态对象、使用局部对象、并发访问资源时使用锁）；

• 资源复用（单例和对象池）；

• 数据结构；

• 垃圾回收

D.存储性能优化

1.数据库多采用两级索引的B+树，树的层次最多三层。可能需要5次磁盘访问才能更新一条记录。

2.这么多NoSQL产品使用LSM树，可以看作一个N阶合并树。

3.RAID（廉价磁盘冗余阵列），RAID0，RAID1，RAID10，RAID5，RAID6，传统关系数据库及文件系统中应用广泛。

4.HDFS（Hadoop分布式文件系统），配合MapReduce进行大数据处理。

五、万无一失：网站的高可用架构

A.网站可用性的度量与考核

1.网站可用性度量

• 网站不可用时间（故障时间）=故障修复时间点-故障发现（报告）时间点

• 网站年度可用性指标=（1-网站不可用时间/年度总时间）*100%

• 2个9是基本可用，88小时；3个9是较高可用，9小时；4个9是具有自动恢复能力的高可用，53分钟；5个9具有极高可用性，小于5分钟；QQ为99.99，4个9，一年大约53分钟不可用。

2.网站可用性考核

• 故障分：指对网站故障进行分类加权计算故障责任的方法

• 故障分=故障时间（分钟）*故障权重

B.高可用的网站架构

主要手段就是数据和服务的冗余备份及失效转移。对于应用层和服务层，以集群通过负载均衡实现高可用，数据层通过数据同步复制实现冗余备份来实现高可用。

C.高可用应用

1.通过负载均衡进行无状态服务的失效转移：即使应用访问量非常少，也至少部署两台服务器使用负载均衡构建一个小型集群。

2.应用服务器集群的Session管理

• Session复制：服务器间同步Session，小型集群

• Session绑定：利用源地址Hash将源于同一IP的请求分发到同一台服务器上，对高可用性有影响。

• 利用Cookie记录Session：大小限制、每次请求响应都需要传输、关闭cookie则无法访问

• Session服务器：利用分布式缓存、数据库等，高可用、高伸缩、性能较好

D.高可用服务

1.分级管理：运维上将服务器进行分级，核心应用和服务优先使用更好的硬件，在运维响应速度上也格外迅速。

2.超时设置：在应用程序中设置服务调用的超时时间，一旦超时，通信框架就抛出异常，应用程序根据服务调度策略，可选择继续重试或将请求转移到提供相同服务的其他服务器上。

3.异步调用：应用对服务的调用通过消息队列等异步方式完成，避免一个服务失败导致整个应用请求失败的情况。

4.服务降级：拒绝服务，拒绝低优先级应用的调用或者随机拒绝部分请求调用；关闭功能，关闭部分不重要的服务或服务内部关闭部分不重要的功能。

5.幂等性设计：在服务层保证服务重复调用和调用一次产生的结果相同，即服务具有幂等性。

E.高可用的数据

1.CAP原理

• 高可用的数据：数据持久性（永久性存储、备份副本不会丢失）、数据可访问性（不同设备下快速切换）、数据一致性（多副本的情况下保证副本数据一致）

• CAP原理：一个提供数据服务的存储系统无法同时满足数据一致性（Consistency）、数据可用性（Availibility）、分区耐受性（Partition Tolerance，系统具有 跨网络分区的伸缩性）这三个条件。

• 大型网站通常会选择强化分布式系统的可用性（A）和伸缩性（P），而在某种程度上放弃一致性（C）。一般来说，数据不一致通常出现在系统高并发写操作或者集群状态不稳的情况下，应用系统需要对分布式数据处理系统的数据不一致性有所了解并进行一定意义上的补偿和纠错，以避免出现应用系统数据不正确。

• 数据一致性又可分为：数据强一致（各种操作都是一致的）、数据用户一致（副本可能不一致但用户访问时通过纠错的校验确定一个正确的数据返回给用户）、数据最终一致（副本和用户访问可能都不一致，但系统经过一段时间的自我恢复和修正达到一致）

2.数据备份

• 异步热备：多份数据副本的写入操作异步完成，应用程序收到数据服务系统的写操作成功响应时，只写成功一份，存储系统将会异步地写其他副本（可能会失败）

• 同步热备：多份数据副本的写入操作同步完成，即应用程序收到数据服务系统的写成功响应时，多份数据都已经写操作成功。

3.失效转移

• 失效确认：心跳检测、应用程序访问失败

• 访问转移：确认某台服务器宕机后，将数据读写访问重新路由到其他服务器上

• 数据恢复：从健康的服务器复制数据，将数据副本数目恢复到设定值

F.高可用网站的软件质量保证

1.网站发布

2.自动化测试：工具Selenium

3.预发布验证：先发布到预发布机器上，开发工程师和测试工程师在预发布服务器上进行预发布验证。需要和生产环境相同配置、环境、数据中心等

4.代码控制：svn、git；主干开发、分支发布；分支开发、主干发布（主流）；

5.自动化发布

6.灰度发布：将集群服务器分成若干部分，每天只发布一部分服务器，观察运行稳定没有故障，期间如果发现问题，只需要回滚已发布的一部分服务器即可。也常用于用户测试（AB测试）。

G.网站运行监控

1.监控数据的采集

• 用户行为日志收集：用户操作系统与浏览器版本、IP地址、页面访问路径、页面停留时间等。包括服务器端日志收集、客户端浏览器日志收集。

• 服务器性能收集：如系统Load、内存占用、磁盘IO、网络IO等，工具Ganglia等

• 运行数据报告：如缓冲命中率、平均响应延迟时间、每分钟发送邮件数目、待处理的任务总数等。

2.监控管理

• 系统报警：设定各项监控指标设定阈值，使用邮件、即时通信工具、短信等报警

• 失效转移：主动通知应用，进行失效转移

• 自动优雅降级：根据监控参数判断应用负载，适当卸载应用低负载应用部分服务器，重新安装高负载应用使应用负载总体均衡。

六、永无止境：网站的伸缩性架构

所谓网站的伸缩性是指不需要改变网站的软硬件设计，仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务处理能力。

A.网站架构的伸缩性设计

1.不同功能进行物理分离实现伸缩：纵向分离（分层后分离），将业务处理流程上的不同部分分离部署，实现系统伸缩性；横向分离（业务分割后分离），将不同的业务模块分离部署，实现系统伸缩性。

2.单一功能通过集群规模实现伸缩

B.应用服务器集群的伸缩性设计

1.应用服务器应该设计成无状态的，不存储请求上下文信息。

2.负载均衡：

• HTTP重定向负载均衡：根据用户的HTTP请求计算一台真实的Web服务器地址，并将该服务器地址写入HTTP重定向响应中返回给用户浏览器。优点简单，缺点：需要两次请求；重定向服务器自身的处理能力可能成为瓶颈；302跳转可能影响SEO。

• DNS域名解析负载均衡：在DNS服务器配置多个A记录指向不同IP，优点是将负载均衡的工作转交给DNS，不少还支持地理位置返回最近的服务器。缺点是可能缓存A记录，控制权在域名服务商那里。

• 反射代理负载均衡：浏览器访问请求的地址是反向代理服务器，反向代理服务器收到请求后，根据负载均衡算法计算得到一台真实物理服务器的地址，并将请求转发给真实服务器，处理完成后将响应返回给反向代理服务器，反向代理服务器再将响应返回给用户。也叫应用层（HTTP层）负载均衡。优点是部署简单，缺点是反向代理服务器作为中转站性能可能成为瓶颈。

• IP负载均衡：用户请求数据包到达负载均衡服务器后，负载均衡服务器在操作系统内核进程获取网络数据包，根据负载均衡算法计算得到一台真实web服务器，然后将数据目的IP地址修改为真实服务器，不需要通过用户进程处理。真实服务器处理完成后，响应数据包回到负载均衡服务器，负载均衡服务器再将数据包源地址修改为自身的IP地址发送给用户浏览器。

• 数据链路层负载均衡：三角传输模式，负载均衡服务器数据分发过程中不修改IP地址，只修改目的mac地址，通过所有服务器的虚拟IP地址与负载均衡服务器的IP地址一致，不修改数据包的源地址和目的地址，由于IP一致，可将响应数据包直接返回给用户浏览器。又称为直接路由方式（DR）。代表产品LVS（Linux Virtual Server）。

3.负载均衡算法：

• 轮询（Round Robin，RR）：所有请求集资分发到每台应用服务器上

• 加权轮询（Weighted Round Robin，WRR）：根据服务器硬件性能情况，在轮询的基础上按照配置的权重进行分发

• 随机（Random）：请求被随机分配到各个应用服务器

• 最少连接（Least Connections）：记录服务器正在处理的连接数，将新的请求分发到最少连接的服务器上

• 源地址散列（Source Hashing）：根据请求来源的IP地址进行Hash计算

C.分布式缓存集群的伸缩性设计

1.Memcached分布式缓存集群的访问模型

通过KEY输入路由算法模块，路由算法计算得到一台Memcached服务器，进行读取和写入。

2.Memcached分布式缓存集群的伸缩性挑战

简单的路由算法使用余数Hash：用服务器数目除缓存数据KEY的Hash值，余数为服务器列表下标编号。伸缩性不好。

3.分布式缓存的一致性Hash算法

先构造一个长度为2的32次方的整数环（一致性Hash环），根据节点名称的Hash值将缓存服务器节点放置在这个Hash环上。然后根据需要缓存的数据的KEY值计算Hash值，然后在Hash环上顺时针查找距离这个KEY的Hash值最近的缓存服务器节点，完成KEY到服务器的Hash映射查找 。

D.数据存储服务器集群的伸缩性设计

1.关系数据库集群的伸缩性设计

数据复制（主从）、分表分库、数据分片（ Cobar）

2.NoSql数据库的伸缩性设计

NoSQL放弃了以关系代数为基础的结构化查询语言（SQL）和事务一致性保证（ACID）。强化了高可用性和伸缩性。（Apache HBase） 

到此，关于“mysql大型网站技术架构核心原理是什么”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注创新互联网站，小编会继续努力为大家带来更多实用的文章！

分享题目：mysql大型网站技术架构核心原理是什么
本文URL：http://kswjz.com/article/pppjdo.html