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

1 大型网站系统的特点

2 大型网站架构演化历程

21 初始阶段架构

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

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

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

22 应用服务和数据服务分离

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

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

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

23 使用缓存改善性能

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

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

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

24 使用应用服务器集群

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

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

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

25 数据库读写分离

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

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

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

26 反向代理和 CDN 加速

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

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

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

27 分布式文件系统和分布式数据库

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

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

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

28 使用 NoSQL 和搜索引擎

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

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

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

29 业务拆分

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

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

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

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

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

210 分布式服务

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

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

3 大型网站架构模式

31 分层

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

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

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

32 分割

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

33 分布式

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

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

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

常用的分布式方案：

34 集群

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

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

35 缓存

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

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

常见缓存手段：

使用缓存有两个前提：

36 异步

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

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

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

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

37 冗余

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

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

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

38 自动化

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

39 安全

4 大型网站核心架构要素

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

41 性能

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

42 可用性

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

43 伸缩性

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

44 扩展性

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

45 安全性

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

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

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

今年年中，一位前谷歌、前亚马逊的工程师推出了他创作的开源内存数据缓存系统 Dragonfly，用 C/C++ 编写，基于 BSL 许可（Business Source License）分发。

根据过往的基准测试结果来看， Dragonfly 可能是世界上最快的内存存储系统，它提供了对 Memcached 和 Redis 协议的支持，但能够以更高的性能进行查询，运行时内存消耗也更少。与 Redis 相比，Dragonfly 在典型工作负载下实现了 25 倍的性能提升；单个 Dragonfly 服务器每秒可以处理数百万个请求；在 5GB 存储测试中，Dragonfly 所需的内存比 Redis 少 30%。

作为一个开源软件，Dragonfly 在短短两个月获得了 92K GitHub 星，177 个 fork 分支。虽然这些年，涌现了不少类似的 Redis 兼容型内存数据存储系统，例如 KeyDB、Skytable，但是都没能像这次这么“轰动”。毕竟 Redis 诞生了十多年，这时从头开始设计一个缓存系统，可以抛弃 历史 包袱，更好地利用资源。

为回击新冒头的 Dragonfly，Redis 的联合创始人兼 CTO Yiftach Shoolman 和 Redis Labs 的首席架构师 Yossi Gottlieb、Redis Labs 的性能工程师 Filipe Oliveira 联合发布了一篇名为《13 年后，Redis 是否需要新的架构》的文章。

在文章中，他们特地给出了自认更加公平的 Redis 70 vs Dragonfly 基准测试结果：Redis 的吞吐量比 Dragonfly 高 18% - 40%，以及一些有关 Redis 架构的观点和思考，以证明 “为什么 Redis 的架构仍然是内存实时数据存储（缓存、数据库，以及介于两者之间的所有内容）的最佳架构”。

虽然他们强调 Redis 架构仍然是同类最佳，但也没法忽视 Dragonfly 这些新软件提供的一些新鲜、有趣的想法和技术，Redis 表示其中的一些甚至有可能在未来进入 Redis（比如已经开始研究的 io_uring 、更现代的 dictionaries、更有策略地使用线程等）。

另外，Redis 指出 Dragonfly 基准测试的比较方法 “不能代表 Redis 在现实世界中的运行方式” 。对此，Reddit 上有网友反驳称：

还有人表示，这篇文章是 Redis 团队在有礼貌地否认“Dragonfly 是最快的缓存系统”，但更多网友表示，Redis 发文章进行“回击”，就已经代表他们的营销部门输了：

我们当然一直在寻求为 Redis 提升性能、扩充功能的创新方向，但这里我们想聊聊自己的观点和思考，阐释 Redis 时至今日为何仍是最出色的实时内存数据存储（包括缓存、数据库以及介于二者之间的一切）方案之一。

接下来，我们将重点介绍 Redis 对于速度和架构差异的观点，再以此为基础做出比较。在文章的最后，我们还会提供基准测试结果、与 Dragonfly 项目的详尽性能比较信息，欢迎大家自行对比参考。

Dragonfly 基准测试其实是将独立单进程 Redis 实例（只能使用单一核心）与多线程 Dragonfly 实例（可以使用虚拟机 / 服务器上的全部可用核心）进行比较。很明显，这样的粗暴比较并不能代表 Redis 在现实场景下的运行状态。作为技术构建者，我们希望更确切地把握自有技术同其他方案间的差异，所以这里我们做了一点公平性调整：将具有 40 个分片的 Redis 70 集群（可使用其中的大部分实例核心）与 Dragonfly 团队在基准测试中使用的最大实例类型（AWS c4gn16xlarge）进行性能比较。

在这轮测试中，我们看到 Redis 的吞吐量比 Dragonfly 要高出 18% 至 40%，而这还仅仅只用到全部 64 个 vCore 中的 40 个。

在我们看来，每一位多线程项目的开发者在立项之前，都会根据以往工作中经历过的痛点来指导架构决策。我们也承认，在多核设备上运行单一 Redis 进程（这类设备往往提供几十个核心和数百 GB 内存）确实存在资源无法充分利用的问题。但 Redis 在设计之初也确实没有考虑到这一点，而且众多 Redis 服务商已经拿出了相应的解决方案，借此在市场上占得一席之地。

Redis 通过运行多个进程（使用 Redis 集群）实现横向扩展，包括在单一云实例背景下也是如此。在 Redis 公司，我们进一步拓展这个概念并建立起 Redis Enterprise。Redis Enterprise 提供管理层，允许用户大规模运行 Redis，并默认启用高可用性、即时故障转移、数据持久与备份等功能。

下面，我们打算分享幕后使用的一些原则，向大家介绍我们如何为 Redis 的生产应用设计良好的工程实践。

通过在每个虚拟机上运行多个 Redis 实例，我们可以：

我们不允许单一 Redis 进程的大小超过 25 GB（运行 Redis on Flash 时上限为 50 GB）。如此一来，我们就能：

以横向扩展的方式灵活运行内存数据存储，是 Redis 获得成功的关键。下面来看具体原因：

我们仍然欣赏由社区提出的种种有趣思路和技术方案。其中一部分有望在未来进入 Redis（我们已经开始研究 io_uring、更现代的字典、更丰富的线程使用策略等）。但在可预见的未来，我们不会放弃 Redis 所坚守的无共享、多进程等基本架构原则。这种设计不仅具备最佳性能、可扩展性和d性，同时也能够支持内存内实时数据平台所需要的各类部署架构。

附录：Redis 70 对 Draonfly 基准测试细节

版本：

目标：

客户端配置：

资源利用与配置优化：

最后，我们还发现 Redis 和 Dragonfly 都不受网络每秒数据包或传输带宽的限制。我们已经确认在 2 个虚拟机间（分别作为客户端和服务器，且均使用 c6gn16xlarge 实例）使用 TCP 传递约 300 B 大小的数据包负载时，可以让每秒数据包传输量达到 1000 万以上、传输带宽超过 30 Gbps。

单 GET 通道延迟低于 1 毫秒：

30 条 GET 通道：

单 SET 通道延迟低于 1 毫秒：

30 条 SET 通道:

用于各变体的 memtier_benchmark 命令：

单 GET 通道延迟低于 1 毫秒

30 条 GET 通道

单 SET 通道延迟低于 1 毫秒

30 条 SET 通道

在本次比较测试中，我们在客户端（用于运行 memtier_benchmark）和服务器（用于运行 Redis 和 Dragonfly）使用了相同的虚拟机类型，具体规格为：

参考链接：

>1-技术有什么区别
首先通信上目前的主流是>

三级缓存高可以提升应用的执行速度，每次打开应用都会保存一点数据在cpu中，就是这点数据，再下次读取的时候可以大幅度提升应用的响应速度，多任务切换。

三级缓存是为读取二级缓存后未命中的数据设计的—种缓存，在拥有三级缓存的CPU中，只有约5%的数据需要从内存中调用，这进一步提高了CPU的效率。其运作原理在于使用较快速的储存装置保留一份从慢速储存装置中所读取数据且进行拷贝，当有需要再从较慢的储存体中读写数据时，缓存(cache)能够使得读写的动作先在快速的装置上完成，如此会使系统的响应较为快速。

（一）三级缓存分类

Cache（三级缓存），分为两种，早期的是外置，以后的升级产品都是内置的。而它的实际作用即是，L3缓存的应用可以进一步降低内存延迟，同时提升大数据量计算时处理器的性能。降低内存延迟和提升大数据量计算能力对游戏软件都很有帮助。而在服务器领域增加L3缓存在性能方面仍然有显著的提升。

如具有较大L3缓存的配置利用物理内存会更有效，故它比较慢的磁盘I/O子系统可以处理更多的数据请求。具有较大L3缓存的处理器提供更有效的文件系统缓存行为及较短消息和处理器队列长度。

其实最早的L3缓存被应用在AMD发布的K6-III处理器上，当时的L3缓存受限于制造工艺，并没有被集成进芯片内部，而是集成在主板上。在只能够和系统总线频率同步的L3缓存同主内存其实差不了多少。后来使用L3缓存的是英特尔为服务器市场所推出的Itanium处理器。

接着就是P4EE和至强MP。Intel还打算推出一款9MB L3缓存的Itanium2处理器，和以后24MB L3缓存的双核心Itanium2处理器。但基本上L3缓存对处理器的性能提高显得不是很重要，如配备1MB L3缓存的Xeon MP处理器却仍然不是Opteron的对手，由此可见前端总线的增加，要比缓存增加带来更有效的性能提升。

（二）一级、二级和三级缓存谁更重要？

一级最重要，但是现在CPU的一级缓存几乎都一样，所以忽略。

二级缓存的话对于Intel的CPU是很重要的，Intel的CPU的二级缓存越大性能提升非常明显，而AMD的CPU虽然二级缓存也很重要，但是二级缓存大小对AMD的CPU的性能提升不是很明显。

三级缓存其实只是做了个辅助的作用，除了服务器，其实对大多数家庭机没什么用的，内存还是很重要的，但如果运行大型程序或游戏来说三级缓存就显得重要了，目前新型CPU已经有三级缓存了。

（三）主频、二级缓存和三级缓存哪个更重要？

要说主频、二级缓存和三级缓存哪个更重要，这个问题完全还要看你使用电脑追求什么了，主要执行什么任务。主频高运算速度快，二级缓存（L2）和三级缓存（L3）起到内存和CPU之间的缓冲作用，缓解内存和CPU速度不匹配问题会影响到CPU执行的效率。所以大的L2、L3在CPU长时间大量数据处理的时候效率会比较高。高主频在短时间内少量数据的处理上会比较快，其实3项这都很重要 ，哪一项达不到一定标准都会出现瓶颈效应。

IntelXeon 7100系列CPU（16MB三级缓存）

Intel正式发布了针对高端服务器的最新双核Xeon处理器，代号Tulsa的Xeon 7100系列。该处理器依然基于上一代NetBurst架构，但在性能和功耗表现方面都有不小的改进。

CPU和内存CPU的类型、主频和数量在相当程度上决定着服务器的性能；服务器应采用专用的ECC校验内存，并且应当与不同的CPU搭配使用。

芯片组与主板即使采用相同的芯片组，不同的主板设计也会对服务器性能产生重要影响。

网卡服务器应当连接在传输速率最快的端口上，并最少配置一块千兆网卡。对于某些有特殊应用的服务器（如FTP、文件服务器或视频点播服务器），还应当配置两块千兆网卡。

硬盘和RAID卡硬盘的读取/写入速率决定着服务器的处理速度和响应速率。除了在入门级服务器上可采用IDE硬盘外，通常都应采用传输速率更高、扩展性更好的SCSI硬盘。对于一些不能轻易中止运行的服务器而言，还应当采用热插拔硬盘，以保证服务器的不停机维护和扩容。

磁盘冗余采用两块或多块硬盘来实现磁盘阵列；网卡、电源、风扇等部件冗余可以保证部分硬件损坏之后，服务器仍然能够正常运行。

热插拔是指带电进行硬盘或板卡的插拔 *** 作，实现故障恢复和系统扩容。

1、服务器处理器主频

服务器处理器主频也叫时钟频率，单位是MHz，用来表示CPU的运算速度。CPU的主频=外频×倍频系数。很多人认为主频就决定着CPU的运行速度，这不仅是个片面的，而且对于服务器来讲，这个认识也出现了偏差。至今，没有一条确定的公式能够实现主频和实际的运算速度两者之间的数值关系，即使是两大处理器厂家Intel和AMD，在这点上也存在着很大的争议，我们从Intel的产品的发展趋势，可以看出Intel很注重加强自身主频的发展。像其他的处理器厂家，有人曾经拿过一快1G的全美达来做比较，它的运行效率相当于2G的Intel处理器。

所以，CPU的主频与CPU实际的运算能力是没有直接关系的，主频表示在CPU内数字脉冲信号震荡的速度。在Intel的处理器产品中，我们也可以看到这样的例子:1GHzItanium芯片能够表现得差不多跟266GHzXeon/Opteron一样快，或是15GHzItanium2大约跟4GHzXeon/Opteron一样快。CPU的运算速度还要看CPU的流水线的各方面的性能指标。

当然，主频和实际的运算速度是有关的，只能说主频仅仅是CPU性能表现的一个方面，而不代表CPU的整体性能。

2、服务器前端总线(FSB)频率

前端总线(FSB)频率(即总线频率)是直接影响CPU与内存直接数据交换速度。有一条公式可以计算，即数据带宽=(总线频率×数据带宽)/8，数据传输最大带宽取决于所有同时传输的数据的宽度和传输频率。比方，现在的支持64位的至强Nocona，前端总线是800MHz，按照公式，它的数据传输最大带宽是64GB/秒。

外频与前端总线(FSB)频率的区别:前端总线的速度指的是数据传输的速度，外频是CPU与主板之间同步运行的速度。也就是说，100MHz外频特指数字脉冲信号在每秒钟震荡一千万次;而100MHz前端总线指的是每秒钟CPU可接受的数据传输量是100MHz×64bit÷8Byte/bit=800MB/s。

其实现在“HyperTransport”构架的出现，让这种实际意义上的前端总线(FSB)频率发生了变化。之前我们知道IA-32架构必须有三大重要的构件:内存控制器Hub(MCH),I/O控制器Hub和PCIHub，像Intel很典型的芯片组Intel7501、Intel7505芯片组，为双至强处理器量身定做的，它们所包含的MCH为CPU提供了频率为533MHz的前端总线，配合DDR内存，前端总线带宽可达到43GB/秒。

但随着处理器性能不断提高同时给系统架构带来了很多问题。而“HyperTransport”构架不但解决了问题，而且更有效地提高了总线带宽，比方AMDOpteron处理器，灵活的HyperTransportI/O总线体系结构让它整合了内存控制器，使处理器不通过系统总线传给芯片组而直接和内存交换数据。这样的话，前端总线(FSB)频率在AMDOpteron处理器就不知道从何谈起了。

3、处理器外频

外频是CPU的基准频率，单位也是MHz。CPU的外频决定着整块主板的运行速度。说白了，在台式机中，我们所说的超频，都是超CPU的外频(当然一般情况下，CPU的倍频都是被锁住的)相信这点是很好理解的。但对于服务器CPU来讲，超频是绝对不允许的。前面说到CPU决定着主板的运行速度，两者是同步运行的，如果把服务器CPU超频了，改变了外频，会产生异步运行，(台式机很多主板都支持异步运行)这样会造成整个服务器系统的不稳定。

目前的绝大部分电脑系统中外频也是内存与主板之间的同步运行的速度，在这种方式下，可以理解为CPU的外频直接与内存相连通，实现两者间的同步运行状态。外频与前端总线(FSB)频率很容易被混为一谈，下面的前端总线介绍我们谈谈两者的区别。

4、CPU的位和字长

位:在数字电路和电脑技术中采用二进制，代码只有“0”和“1”，其中无论是“0”或是“1”在CPU中都是一“位”。

字长:电脑技术中对CPU在单位时间内(同一时间)能一次处理的二进制数的位数叫字长。所以能处理字长为8位数据的CPU通常就叫8位的CPU。同理32位的CPU就能在单位时间内处理字长为32位的二进制数据。字节和字长的区别:由于常用的英文字符用8位二进制就可以表示，所以通常就将8位称为一个字节。字长的长度是不固定的，对于不同的CPU、字长的长度也不一样。8位的CPU一次只能处理一个字节，而32位的CPU一次就能处理4个字节，同理字长为64位的CPU一次可以处理8个字节。

5、倍频系数

倍频系数是指CPU主频与外频之间的相对比例关系。在相同的外频下，倍频越高CPU的频率也越高。但实际上，在相同外频的前提下，高倍频的CPU本身意义并不大。这是因为CPU与系统之间数据传输速度是有限的，一味追求高倍频而得到高主频的CPU就会出现明显的“瓶颈”效应—CPU从系统中得到数据的极限速度不能够满足CPU运算的速度。一般除了工程样版的Intel的CPU都是锁了倍频的，而AMD之前都没有锁。

6、CPU缓存

缓存大小也是CPU的重要指标之一，而且缓存的结构和大小对CPU速度的影响非常大，CPU内缓存的运行频率极高，一般是和处理器同频运作，工作效率远远大于系统内存和硬盘。实际工作时，CPU往往需要重复读取同样的数据块，而缓存容量的增大，可以大幅度提升CPU内部读取数据的命中率，而不用再到内存或者硬盘上寻找，以此提高系统性能。但是由于CPU芯片面积和成本的因素来考虑，缓存都很小。

L1Cache(一级缓存)是CPU第一层高速缓存，分为数据缓存和指令缓存。内置的L1高速缓存的容量和结构对CPU的性能影响较大，不过高速缓冲存储器均由静态RAM组成，结构较复杂，在CPU管芯面积不能太大的情况下，L1级高速缓存的容量不可能做得太大。一般服务器CPU的L1缓存的容量通常在32—256KB。

L2Cache(二级缓存)是CPU的第二层高速缓存，分内部和外部两种芯片。内部的芯片二级缓存运行速度与主频相同，而外部的二级缓存则只有主频的一半。L2高速缓存容量也会影响CPU的性能，原则是越大越好，现在家庭用CPU容量最大的是512KB，而服务器和工作站上用CPU的L2高速缓存更高达256-1MB，有的高达2MB或者3MB。

其实最早的L3缓存被应用在AMD发布的K6-III处理器上，当时的L3缓存受限于制造工艺，并没有被集成进芯片内部，而是集成在主板上。在只能够和系统总线频率同步的L3缓存同主内存其实差不了多少。后来使用L3缓存的是英特尔为服务器市场所推出的Itanium处理器。接着就是P4EE和至强MP。Intel还打算推出一款9MBL3缓存的Itanium2处理器，和以后24MBL3缓存的双核心Itanium2处理器。

但基本上L3缓存对处理器的性能提高显得不是很重要，比方配备1MBL3缓存的XeonMP处理器却仍然不是Opteron的对手，由此可见前端总线的增加，要比缓存增加带来更有效的性能提升。

四个方面。
1、发布。
2、打印。
3、数据提取。
4、缓存。servertoolServerTool是一款专业的服务器安全工具，可以称其为服务器后门检测软件。

我们都知道MySQL的TableCache是表定义的缓存，江湖上流传着各种对这个参数的调优方法。

tablecache的作用，就是节约读取表结构文件的开销。对于tablecache是否命中，其实tablecache是针对于线程的，每个线程有自己的缓存，只缓存本线程的表结构定义。不过我们发现，strace中没有关于表结构文件的open *** 作（只有stat *** 作，定位表结构文件是否存在），也就是说tablecache不命中，不一定需要读取表结构文件。这种感觉好像是：在不命中tablecache时，命中了另外一个表结构缓存。

运维建议：

我们读一下MySQL的文档，关于table_open_cache的建议值公式：建议值=最大并发数join语句涉及的表的最大个数。

通过实验我们容易理解：table_cache是针对于线程的，所以需要最大并发数个缓存。另外，一个语句join涉及的表，需要同时在缓存中存在。所以最小的缓存大小，等于语句join涉及的表的最大个数。将这两个数相乘，就得到了MySQL的建议值公式。

---