nosql和cdn,nosql是什么

大型互联网架构概述，看完文章又涨知识了

1. 大型网站系统的特点

2. 大型网站架构演化历程

2.1. 初始阶段架构

问题：网站运营初期，访问用户少，一台服务器绰绰有余。

特征：应用程序、数据库、文件等所有的资源都在一台服务器上。

描述：通常服务器操作系统使用 linux，应用程序使用 PHP 开发，然后部署在 Apache 上，数据库使用 Mysql，通俗称为 LAMP。汇集各种免费开源软件以及一台廉价服务器就可以开始系统的发展之路了。

2.2. 应用服务和数据服务分离

问题：越来越多的用户访问导致性能越来越差，越来越多的数据导致存储空间不足，一台服务器已不足以支撑。

特征：应用服务器、数据库服务器、文件服务器分别独立部署。

描述：三台服务器对性能要求各不相同：应用服务器要处理大量业务逻辑，因此需要更快更强大的 CPU；数据库服务器需要快速磁盘检索和数据缓存，因此需要更快的硬盘和更大的内存；文件服务器需要存储大量文件，因此需要更大容量的硬盘。

2.3. 使用缓存改善性能

问题：随着用户逐渐增多，数据库压力太大导致访问延迟。

特征：由于网站访问和财富分配一样遵循二八定律：80% 的业务访问集中在 20% 的数据上。将数据库中访问较集中的少部分数据缓存在内存中，可以减少数据库的访问次数，降低数据库的访问压力。

描述：缓存分为两种：应用服务器上的本地缓存和分布式缓存服务器上的远程缓存，本地缓存访问速度更快，但缓存数据量有限，同时存在与应用程序争用内存的情况。分布式缓存可以采用集群方式，理论上可以做到不受内存容量限制的缓存服务。

2.4. 使用应用服务器集群

问题：使用缓存后，数据库访问压力得到有效缓解。但是单一应用服务器能够处理的请求连接有限，在访问高峰期，成为瓶颈。

特征：多台服务器通过负载均衡同时向外部提供服务，解决单一服务器处理能力和存储空间不足的问题。

描述：使用集群是系统解决高并发、海量数据问题的常用手段。通过向集群中追加资源，提升系统的并发处理能力，使得服务器的负载压力不再成为整个系统的瓶颈。

2.5. 数据库读写分离

问题：网站使用缓存后，使绝大部分数据读操作访问都可以不通过数据库就能完成，但是仍有一部分读操作和全部的写操作需要访问数据库，在网站的用户达到一定规模后，数据库因为负载压力过高而成为网站的瓶颈。

特征：目前大部分的主流数据库都提供主从热备功能，通过配置两台数据库主从关系，可以将一台数据库服务器的数据更新同步到一台服务器上。网站利用数据库的主从热备功能，实现数据库读写分离，从而改善数据库负载压力。

描述：应用服务器在写操作的时候，访问主数据库，主数据库通过主从复制机制将数据更新同步到从数据库。这样当应用服务器在读操作的时候，访问从数据库获得数据。为了便于应用程序访问读写分离后的数据库，通常在应用服务器端使用专门的数据访问模块，使数据库读写分离的对应用透明。

2.6. 反向代理和 CDN 加速

问题：中国网络环境复杂，不同地区的用户访问网站时，速度差别也极大。

特征：采用 CDN 和反向代理加快系统的静态资源访问速度。

描述：CDN 和反向代理的基本原理都是缓存，区别在于 CDN 部署在网络提供商的机房，使用户在请求网站服务时，可以从距离自己最近的网络提供商机房获取数据；而反向代理则部署在网站的中心机房，当用户请求到达中心机房后，首先访问的服务器时反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，就将其直接返回给用户。

2.7. 分布式文件系统和分布式数据库

问题：随着大型网站业务持续增长，数据库经过读写分离，从一台服务器拆分为两台服务器，依然不能满足需求。

特征：数据库采用分布式数据库，文件系统采用分布式文件系统。

描述：分布式数据库是数据库拆分的最后方法，只有在单表数据规模非常庞大的时候才使用。不到不得已时，更常用的数据库拆分手段是业务分库，将不同的业务数据库部署在不同的物理服务器上。

2.8. 使用 NoSQL 和搜索引擎

问题：随着网站业务越来越复杂，对数据存储和检索的需求也越来越复杂。

特征：系统引入 NoSQL 数据库及搜索引擎。

描述：NoSQL 数据库及搜索引擎对可伸缩的分布式特性具有更好的支持。应用服务器通过统一数据访问模块访问各种数据，减轻应用程序管理诸多数据源的麻烦。

2.9. 业务拆分

问题：大型网站的业务场景日益复杂，分为多个产品线。

特征：采用分而治之的手段将整个网站业务分成不同的产品线。系统上按照业务进行拆分改造，应用服务器按照业务区分进行分别部署。

描述：应用之间可以通过超链接建立关系，也可以通过消息队列进行数据分发，当然更多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。

纵向拆分：将一个大应用拆分为多个小应用，如果新业务较为独立，那么就直接将其设计部署为一个独立的 Web 应用系统。纵向拆分相对较为简单，通过梳理业务，将较少相关的业务剥离即可。

横向拆分：将复用的业务拆分出来，独立部署为分布式服务，新增业务只需要调用这些分布式服务横向拆分需要识别可复用的业务，设计服务接口，规范服务依赖关系。

2.10. 分布式服务

问题：随着业务越拆越小，存储系统越来越庞大，应用系统整体复杂程度呈指数级上升，部署维护越来越困难。由于所有应用要和所有数据库系统连接，最终导致数据库连接资源不足，拒绝服务。

特征：公共业务提取出来，独立部署。由这些可复用的业务连接数据库，通过分布式服务提供共用业务服务。

3. 大型网站架构模式

3.1. 分层

大型网站架构中常采用分层结构，将软件系统分为应用层、服务层、数据层：

分层架构的约束：禁止跨层次的调用（应用层直接调用数据层）及逆向调用（数据层调用服务层，或者服务层调用应用层）。

分层结构内部还可以继续分层，如应用可以再细分为视图层和业务逻辑层；服务层也可以细分为数据接口层和逻辑处理层。

3.2. 分割

将不同的功能和服务分割开来，包装成高内聚低耦合的模块单元。这有助于软件的开发和维护，便于不同模块的分布式部署，提高网站的并发处理能力和功能扩展能力。

3.3. 分布式

大于大型网站，分层和分割的一个主要目的是为了切分后的模块便于分布式部署，即将不同模块部署在不同的服务器上，通过远程调用协同工作。

分布式意味可以用更多的机器工作，那么 CPU、内存、存储资源也就更丰富，能够处理的并发访问和数据量就越大，进而能够为更多的用户提供服务。

分布式也引入了一些问题：

常用的分布式方案：

3.4. 集群

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

集群需要具备伸缩性和故障转移机制：伸缩性是指可以根据用户访问量向集群添加或减少机器；故障转移是指，当某台机器出现故障时，负载均衡设备或失效转移机制将请求转发到集群中的其他机器上，从而不影响用户使用。

3.5. 缓存

缓存就是将数据存放在距离最近的位置以加快处理速度。缓存是改善软件性能的第一手段。

网站应用中，缓存除了可以加快数据访问速度以外，还可以减轻后端应用和数据存储的负载压力。

常见缓存手段：

使用缓存有两个前提：

3.6. 异步

软件发展的一个重要目标和驱动力是降低软件耦合性。事物之间直接关系越少，彼此影响就越小，也就更容易独立发展。

大型网站架构中，系统解耦的手段除了分层、分割、分布式等，还有一个重要手段——异步。

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

异步架构是典型的生产者消费模式，二者不存在直接调用。异步消息队列还有如下特性：

3.7. 冗余

大型网站，出现服务器宕机是必然事件。要保证部分服务器宕机的情况下网站依然可以继续服务，不丢失数据，就需要一定程度的服务器冗余运行，数据冗余备份。这样当某台服务器宕机是，可以将其上的服务和数据访问转移到其他机器上。

访问和负载很小的服务也必须部署 至少两台服务器构成一个集群，目的就是通过冗余实现服务高可用。数据除了定期备份，存档保存，实现 冷备份 外；为了保证在线业务高可用，还需要对数据库进行主从分离，实时同步实现 热备份。

为了抵御地震、海啸等不可抗因素导致的网站完全瘫痪，某些大型网站会对整个数据中心进行备份，全球范围内部署 灾备数据中心。网站程序和数据实时同步到多个灾备数据中心。

3.8. 自动化

大型网站架构的自动化架构设计主要集中在发布运维方面：

3.9. 安全

4. 大型网站核心架构要素

架构 的一种通俗说法是：最高层次的规划，难以改变的决定。

4.1. 性能

性能问题无处不在，所以网站性能优化手段也十分繁多：

4.2. 可用性

可用性指部分服务器出现故障时，还能否对用户提供服务

4.3. 伸缩性

衡量伸缩的标准就是是否可以用多台服务器构建集群，是否容易向集群中增删服务器节点。增删服务器节点后是否可以提供和之前无差别的服务。集群中可容纳的总服务器数是否有限制。

4.4. 扩展性

衡量扩展性的标准就是增加新的业务产品时，是否可以实现对现有产品透明无影响，不需要任何改动或很少改动，既有功能就可以上线新产品。主要手段有：事件驱动架构和分布式服务。

4.5. 安全性

安全性保护网站不受恶意攻击，保护网站重要数据不被窃取。

欢迎工作一到五年的Java工程师朋友们加入Java程序员开发： 721575865

群内提供免费的Java架构学习资料（里面有高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料）合理利用自己每一分每一秒的时间来学习提升自己，不要再用"没有时间“来掩饰自己思想上的懒惰！趁年轻，使劲拼，给未来的自己一个交代！

相关问答

Q1: ?cdn的原理是什么？

cdn是把网站常用的数据存储在加速节点服务器上，这些加速节点分布在全国的光纤干线上，用户访问这些数据时能节约很多时间，可以大大缩短反应时间。

Q2: 【软件架构篇】互联网架构模板

架构图如下图所示。这张图基本涵盖了互联网技术公司的大部分技术点，不同公司只是在具体的技术实现上稍有差异，但不会跳出这个框架的范畴。

SQL： 常用的有mysql，用于存储业务数据。互联网发展初期，各个业务一般都会独立运营mysql集群，但随着业务越来越多，mysql集群规模越来越大，那就有必要做成SQL平台。

NoSQL: 翻译为Not Only SQL，作为mysql的一种补充。Nosql一般本身就提供集群，且使用起来很方便，公司业务发展初期没有必要。一般Nosql集群的数量越来越多，那就有必要做成Nosql平台。

小文件： 互联网中有很多小文件，比如商品图片，Facebook的图片。这类小文件具有数据小、数量巨大、访问大的特点。如果每个业务都去考虑小文件存储的话，就会出现重复造轮子现象，那就有必要做成小文件平台了。

大文件： 互联网的大文件主要分为两类：一类是业务上的大数据，例如Youtube的视频、电影网站的电影；另一类是海量的日志数据，例如各种访问日志。实力雄厚的一些大公司会基于开源方案做成大数据平台。

开发框架： 比如常见的Spring框架。

Web服务器： 常见的有tomcat、jetty等。

容器： Docker可以极大降低运维成本，以及在实现动态扩容上非常方便。

配置中心： 故名思义，配置中心就是集中管理各个系统的配置。

服务中心： 解决跨系统依赖的配置和调度问题。比如有10个系统依赖A系统的x接口，此时A系统实现了一个y接口可以更好地支持x接口，那么如果直接更新10个系统依赖的配置将会很麻烦。

消息队列： 支持系统解耦。

负载均衡： 充当任务分配器的职责。

CDN： 可以对一些常用文件进行就近缓存，来提高访问速度。

多机房： 多机房的主要目的是备灾，当机房故障时可以快速地将业务切换到另外一个机房，这种切换操作允许一定时间的中断，比如10分钟，1个小时。

多中心： 多中心的要求就更高了，要求同时对外提供服务，且业务能够自动在多中心之间切换，故障后不需人工干预或者很少的人工干预就能自动恢复。

用户管理： 对各个系统的用户进行统一管理。

消息推送： 根据不同途径分为短信、邮件、站内信、App推送。

存储云： 实现是CDN+小文件存储。

图片云： 实现也是CDN+小文件存储。为何不与存储云统一一套系统呢？这是因为图片业务的复杂性导致的。图片涉及的业务会更多，包括裁剪、压缩、美化、审核、水印等。

业务千差万别，各个互联网业务面对的主要问题是复杂度越来越高。此时就要用到拆和合的技术。拆即将一个大系统拆分为多个子系统，降低复杂度。当子系统越来越多，有可能就需要采用合的技术。

测试平台的核心目的是提升测试效率。

运维平台的核心职责分为四大块：配置、部署、监控、应急。

数据平台的核心职责主要包含三部分：数据管理、数据分析和数据应用。

管理平台的核心职责就是权限管理。

Q3: 架构中的业务能力和技术能力

谈架构我们谈什么，如果单单谈技术是不行的，架构师起到承上启下的作用，上负责与客户与业务涉众沟通，下负责让团队理解需求和如何通过技术实现需求。架构师的语言包括架构图，同时我们还要谈论 业务能力 和 技术能力 。

业务能力是我们从业务需求、系统类别、行业背景分析出的，主要是按业务范围或业务领域进行一定的划分，比如说合同系统，那么合同审批、合同签署、合同存档等就是业务能力。

技术能力是从我们选择的技术、平台、基础结构中体现出来的。如AWS S3的对象存储能力，Lambda的无服务器计算能力，DynamoDB的NoSQL数据存储能力，ElasticSearch的搜索能力，又如ElastiCache的缓存能力和CloudFront的CDN能力。

架构师所做的架构设计实际上就是一个函数f(x)，x是业务能力，所得f(x)是从业务能力映射出的技术能力。技术能力的全景图就是技术架构图，同时我们也可以通过技术债列表反应出我们所需要的技术能力以及技术能力的风险。

架构师跟客户及业务团队、涉众通过业务能力以“业务语言”进行沟通，比如“合同审批需要支持多级可打回的自定义审批流程”、“合同签署需要支持电子合同签署”、“合同归档要实现合同扫描件及电子合同的保存”等等。这里我们不提及要使用的技术、产品、服务、品牌、平台和基础设施，原因是客户和涉众并不能理解你的这些技术词汇。

架构师跟应用开发和运维团队以“技术语言”进行沟通，比如“合同审批采用开源，支持多节点并行审批并可退回前节点的自定义工作流产品”、“合同签署采用Web界面和签名采样控件进行电子签署”、“合同归档需要满足ISOxxxx的合同记录管理系统”等等，这里我们要提起技术、产品、服务、品牌、平台和基础设施，帮助开发和运维团队理解在未来的时间里他们需要做哪些准备和工作，项目经理需要明白还需要何种能力的人力或其他工作资源。

通过业务语言和技术语言的双向沟通，架构师起到承上启下帮助技术团队理解业务需求，通过技术满足客户和涉众所提需求的目的。

Q4: 网站响应时间过长是怎么回事？

网站响应时间过长是怎么回事？花了太长时间进行响应;无法访问此网站 响应时间过长 ERR_CONNECTION_TIMED_OUT,无法访问此网站 服务器响应时间过长; 遇到过类似问题，我认为有以下几个原因：



无法访问此网站 (图) 服务器响应时间过长

1、网站服务器故障维修（这种情况只能等段时间重新登录试试）

2、网络连接不通（查看网线接口处是否插好）

3、网站地址被和谐了（用代理）

4、本身网站程序卡死了(程序问题)

服务器网站响应时间过长的问题解决方法如下：

1、机器的配置。包括服务器端与客户机端的硬件配置程度，同样的网络环境下，双核的服务器的运算能力肯定要强一些，毫无疑问的，同样的网络环境下，用一台赛扬的机器和奔四双核处理器的电脑，打开同样的网页，速度，也肯定不一样。

2、服务器软件。软件多少、稳定和软件的正确配置，都会影响到服务器环境，以致影响到网络速度。服务器安装软件防火墙，会牺牲一些网络速度，所以VPS、或独立服务器用户装一个防火墙足矣。

3、DNS解析时间。DNS解析包括往返解析的次数及每次解析所花费的时间，两者的积就是DNS解析所消耗的时间，因此，很多人忽视了DNS的问题。

4、网络最小带宽。这是最主要的因素，在慢的网站放在好的带宽下访问速度一样快（就是多花钱），网络的带宽包括对网站所在服务器带宽和用户端两个位置，对接点指的是出口端与入口端（如电信对网通的对接点），另一个就是用户本身的最小带宽，如果用户办的是512K宽带咱就爱莫能助了。

5、网页内容的大小（重要）。网页文件的大小是网站是

否能快速打开最重要一个因素，如果说服务器等硬件方面决定不了，强烈建议从这里下手，不管是表格还是DIV+CSS，适当的优化代码，都能减少网页大小。尽量优化代码，用最少的代码。同时大量错误、冗余代码也是拖慢网站速度之一。

6、大量数据库操作。小网站在执行大量数据库操作时，也会影响网站打开速度，这里使asp+access结构的网站尤为明显，尤其是同时有大量用户提交评论时，就操作数据库锁死，导致网站打不开。

7、用很多javascript。网站上使用大量JS是大忌，不仅搜索引擎无法收录，同时会不断提交请求增加服务器负担，例如鼠标特效、栏目的特效、状态栏的特效等等。这些特效的原理是先由服务器下载到本地的机器，然后在本地机器上运行产生，然后才能看到的。

8、页面上用大图片和FLASH。图片是拖慢网速最重要一个因素，图片经过处理，可以使图片空间变小，否则很多的图片一开始都会占用很多空间又使网站打开速度变得很慢，同样FLASH也是一个道理。

9、过多引用了别的网站的内容。包括引用其他网站的图片、视频文件等，如果直接在页面引用别的网站的东西，而那个网站的速度又慢，或者那个网站的该页面已经不存在了，那么打开的速度就会非常慢。

Q5: 为什么开了cdn加速网站还是慢？

网站响应时间过长怎么回事？解决方法都有哪些？很多人在完成HTML5和CSS3部分的学习之后，都要独立完成网页制作项目实践，在这个过程中有部分同学发现网页打开很慢，即网站响应时间过长。针对这个问题，千锋老师给大家分享几种比较好的解决方法。

网站响应时间是什么?

网站响应时间是指系统对请求作出响应的时间，通俗来讲就是我们把网址输入进浏览器然后敲回车键开始一直到浏览器把网站的内容呈现给用户的这段时间。网站响应时间是越短越好，因为网站页面打开速度越快，就意味着我们的用户可以更快的访问站点或者我们的服务器。一般我们网站的响应时间保持在100-1000ms，网页打开速度越快，用户体验度越好。

如何缩短网页响应时间?

当用户请求一个网站数据的时候，实际上是发送了一个http请求，在宏观上可以分为两个部分：http请求到达目标网站服务器之前、http请求到达目标网站服务器之后。

想缩短一个网站的响应时间，本质上是提高数据的返回速度，就是要把请求数据过程中的各个步骤提高速度，你可以从以下几个方面进行：

1、客户端

客户端是发起一个网站请求的源头，这个源头施加一定的策略可以大大缩短某些数据的获取时间。其中最为常用的就是缓存，一些常用的、很少变动的资源缓存在客户端，不但能缩短获取资源的时间，而且在很大程度上能减轻服务端的压力。

2、DNS

一般网站的访问方式都采用域名的方式，这就涉及到DNS解析速度的问题，如果DNS服务解析的速度比较慢，整体过程的响应时间也会加长。当客户端发送一个DNS请求的时候，首先本地的DNS服务器会接收到请求，会在本地先查询缓存中有没有当前域名和IP的映射关系，如果有则直接返回IP信息，如果没有，则会询问其他DNS服务器。

3、网络

客户端获取到网站IP之后通过网卡把http请求发送出去，目标地址为相应的网站服务器。在这个过程当中如果客户端和服务器端有一方带宽比较小的话，就会加大响应时间。这个过程的响应时间取决于很多因素，比如路由器的路由策略是否最优、整个过程通过的网关数据量等。

4、网站

当一个请求到达网站服务器，服务器便开始处理请求，最终请求的数据会通过查询数据库来返回。现在有很多的场景采用NOsql代替关系型数据库来缩短响应时间，在正常情况下，由于关系型数据库的本身因素在特定场景下的读写速度比Nosql要慢很多，所以系统设计初期，可以考虑采用关系型数据库和Nosql混用的方案。

5、缓存

为了避免频繁查询数据库产生瓶颈，诞生了缓存。现在流行的设计在网站层和服务层都有缓存策略，只不过缓存的数据和策略有所不同，但是最终目的都是为了加快请求的响应。加了缓存之后，数据的一致性需要仔细设计。

6、CDN加速

CDN依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。CDN就是把离用户最近的数据返回给用户。

有同学认为程序异步化可以缩短响应时间，其实这是一种误解，不过程序异步化对提高吞吐量有很大作用。如果你想了解更多Web前端相关技术，可以选择专业的学习方式。