随着互联网的普及，电商、金融等各种网站 的用户量 也越来越多，如何设计出 高并发、高可用、高性能的系统？
目录
一、性能指标
1. 响应时间
从 完成 一个 操作 所需要的 时间 的角度来看的。
这个操作可以是：
1）打开一个网站
2）一次数据库操作
3）磁盘寻址
4）一次 redis 缓存查询操作
5）Java程序的 方法执行
6）数据在网络中的传输
等等。。。。
所以，如果对响应时间有要求的话，那就要把 需要的操作 类型 明确下来，这样才能 有参考意义。
目标就是 用最小的响应时间 来 对一次操作 进行响应。
2. 并发数
倾向于描述 同一时刻 能够 接收处理 的 请求 的 数量。
并发数 越大，说明 在同一时刻 能够 处理的 请求数越大。
当 接收了请求之后，这些请求的 服务处理，交由系统完成，但是 系统能不能 给这些请求 完成响应，要看 系统的 吞吐量
并发数，可以 看成是 饭店的服务员 同时接待的客户。
3. 吞吐量
倾向于描述 单位时间内 系统能够处理的 请求数量。(为什么是单位时间呢？我觉得是因为：系统完成响应是需要时间的，比如，1s钟可以处理 100个 请求并且给出响应，而不是 13:13:13 这个时刻 接收到了 100个请求。)
吞吐量，可以看成是 饭店的厨师 可以在单位时间内 做出来多少道菜。
4. 并发数与吞吐量的关系
并发数 == 吞吐量 ， 这个时候 网站 性能会 趋于 最大值并稳定
并发数 < 吞吐量， 这个时候 网站性能 受到 并发数限制，
并发数> 吞吐量， 这个时候 网站的星期 受到 吞吐量的限制，这个时候 系统资源被耗尽，无法完成响应。
4. 性能计数器
CPU 使用情况
内存 使用情况
磁盘 和 网络IO 的情况
System Load ，系统负载。 指： 正在被 cpu执行的进程数目 + 等待被cpu执行的进程数目，可以使用top命令查看
二、影响因素
简单来说，就是 IO、磁盘；
因为 需要进行计算机互联 才能完成一整套完成的功能，就是需要 网络IO
因为 需要将数据 持久化，就需要 磁盘存储
而且，对于 不同的应用组件，和操作系统本身，能够支持的 并发连接数也是由限的
所以，最终的一个目的，就是 尽可能的 增加系统能够支持的 并发连接，减少 网络IO、磁盘IO，提高系统 并发数、提高系统的吞吐量，减少 数据的重复传输。
三、如何解决
一个网站，并不是在发布的那一刻 就能够支持 高并发，必定是一个 循序渐进、慢慢发展的。但是，时至今日，已经存在了能够支持高并发、大数据量、高性能、高可用的网站了。及时 没有经历过其中的发展过程，但是 也可以学习一下他们的技术方案。
1. 数据库瓶颈
我做的大多数的项目，系统，数据的创建、更新的频率 是小于 数据的查询的。
因此，可以使用下面的方式来解决数据库瓶颈
1） 使用缓存
2） 数据库拆分
一般都是垂直拆分：
就是 把不同的数据，放在不同的表、库；每个库可以部署到不同的服务器上。
或者可以这样理解：
假如一个业务需求 有 20个字段来描述，那么，可以把20个字段放在一个表里，也可以把20个字段 分类，放在不同的表里，而这些不同的表可以放在一个库里，也可以放在不同的库。这就是垂直拆分。
也有水平拆分：
就是把相同的数据，表结构是一样的，存储在不同的库中；每个库可以部署到不同的服务器上
或者可以这样理解：
假如一个业务需求 有20个字段来描述，并且是在一张表中的。随着业务的发展，表里的数据越来越多，导致很多问题。那么 就可以 把这些数据 按照某种规则 分配到 表结构相同，但是属于不同的数据库中，这样就可以用不同的服务器来存储这些数据了。这就是水平拆分。
3）读写分离
对于数据的使用，大部分都是 查询。因此可以 进行读写分离设计
4）使用搜索引擎
有一些数据的查询，可以用搜索引擎来处理，不用过 缓存和数据库
2. 服务器瓶颈
单个服务器的资源是有限的，集群是最好的一种扩展方式
另外，对于应用的开发方式，现在大多数都采用了 微服务的设计，可能以后还有其他的设计。
3. 网络瓶颈
网络是不可靠的，除了不可靠，还有一个就是 比较耗时，对于性能要求高的网站，如果存在大量的网络服务调用，是不行的。
1）MQ
使用 MQ可以异步化网络服务调用，提高系统的响应时间
2）使用前端技术
CDN
前端缓存
四、提高可扩展能力
一个网站的设计，是服务于业务需求。
在初期完成业务需求的同时，尽可能的 提高系统的可扩展性，这样就有利于后期的 网站架构升级
328
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
