关于高并发
高并发场景
互联网应用以及云计算的普及，使得架构设计和软件技术的关注点从如何实现复杂的业务逻 辑，转变为如何满足大量用户的高并发访问请求。
一个简单的计算处理过程，如果一旦面对大量的用户访问，整个技术挑战就会变得完全不 同，软件开发方法、技术团队组织、软件的过程管理都会完全不同。
科普文：Nginx 高并发魔法打破性能瓶颈的终极秘籍-CSDN博客
实战：搞懂Redisson、分布式锁、限流器_redisson分布式限流-CSDN博客
科普文：12种常见的软件架构_软件系统架构有哪几种-CSDN博客
限流：深入理解微服务高可用三板斧“限流”_微服务治理三板斧-CSDN博客
科普文：深入理解负载均衡（四层负载均衡、七层负载均衡）_第七层负载均衡-CSDN博客
Java web应用性能分析之【高并发之降级】-CSDN博客
Java web应用性能分析之【高并发之限流】_web服务限流-CSDN博客
Java web应用性能分析之【高并发之缓存-多级缓存】_java多级缓存-CSDN博客
架构策略
垂直伸缩
垂直伸缩，就是提升单台服务器的处理能力。
比如用更快频率的 CPU，用更多核的 CPU，用更大的内存，用更快的网卡，用更多的磁盘组成一台服务器，使单台服务器的处理能力得到提升。
垂直伸缩带来的价格成本和服务器的处理能力并不一定呈线性关系。
增加同样的费用，并不能得到同样的计算能力。而且计算能力越强大，需要花费的钱就越多。
而且，受计算机硬件科技水平的制约，单台服务器的计算能力并不能无限增加，而互联网，特别是物联网的计算要求几乎是无限的。
因此，在互联网以及物联网领域，并不使用垂直伸缩这种方案，而是使用水平伸缩。
水平伸缩
所谓的水平伸缩，指的是不去提升单机的处理能力，而是使用更多的服务器，将这些服务器构成一个分布式集群，通过这个集群，对外统一提供服务，以此来提高系统整体的处理能力。
但是要想让更多的服务器构成一个整体，就需要在架构上进行设计，让这些服务器成为整体 系统的一个部分，将这些服务器有效地组织起来，统一提升系统的处理能力。
这就是互联网应用和云计算中普遍采用的分布式架构方案。
分布式技术方案
- 分布式缓存
- 负载均衡
- 反向代理与 CDN
- 分布式消息队列
- 分布式数据库
- NoSQL 数据库
- 分布式文件
- 搜索引擎
- 微服务
将这些分布式技术整合起来，就是分布式架构方案
互联网分布式架构演化
单机架构
微服务架构
分布式缓存架构
负载均衡架构
数据库读写分离
消息队列&反向代理&CDN&分布式数据库架构
海量数据的存储，主要通过分布式数据库、分布式文件系统、NoSQL 数据库解决。
直接在数据库上查询已经无法满足这些数据的查询性能要求，还需要部署独立的搜索引擎提供查询服务。
同时减少数据中心的网络带宽压力，提供更好的用户访问延时，使用 CDN 和反向代理提供前置缓存，尽快返回静态文件资源给用户。
为了使各个子系统更灵活易于扩展，则使用分布式消息队列将相关子系统解耦，通过消息的发布订阅完成子系统间的协作。
使用微服务架构将逻辑上独立的模块在物理上也独立部署，单独维护，应用系统通过组合多个微服务完成自己的业务逻辑，实现模块更高级别的复用，从而更快速地开发系统和维护系统。
关于高性能
高性能场景
互联网应用以及云计算的普及，使得架构设计和软件技术的关注点从如何实现复杂的业务逻 辑，转变为如何满足大量用户的高并发访问请求。
衡量指标
4个性能指标：并发数不变，响应时间足够快，单位时间的吞吐量就会相应的提高。
- 响应时间：指从发出请求开始到收到最后响应数据所需要的时间。反映系统快慢。
- 并发数：系统同时处理的请求数。反映系统负载。
- 吞吐量：单位时间内，系统处理请求的数量。体现系统处理能力。
- HTTP请求数：HPS
- 每秒事务数：TPS
- 每秒查询数：QPS
- 性能计数器：
- 系统负载System Load
- 对象和线程数
- 内存使用
- CPU使用
- 磁盘和网络
性能测试
- 性能测试
- 负载测试
- 压力测试
- 稳定性测试
性能优化
性能优化5个过程
- 1.性能测试
- 2.性能分析
- 3.性能优化
- 4.性能测试
- 5.是否符合预期性能目标
性能优化策略
- 1.数据中心优化
- 2.硬件优化
- 3.操作系统优化
- 4.虚拟机优化
- 5.基础组件优化
- 6.架构优化
- 缓存
- 消息队列
- 集群
- 7.代码优化
- 使用合理的数据结构优化性能
- 编写性能更好的SQL语句
- 实现异步I/O与异步方法调用
关于高可用
高可用场景
我们知道，Web 应用在各种情况下都有可能不可访问，也就是不可用。
各种硬件故障，比如应用服务器及数据库宕机、网络交换机宕机、磁盘损坏、网卡松掉等等。还有各种软件故障，程序 Bug 什么的。即使没有 Bug，程序要升级，必须要关闭进程重新启动，这段时间应用也是不可用的；
此外，还有外部环境引发的不可用，比如促销引来大量用户访问，导致系统并发压力太大而崩溃，以及，黑客攻击、机房火灾、挖掘机挖断光缆，各种情况导致的应用不可用。
而互联网的高可用是说，在上面各种情况下，应用都要是可用的，用户都能够正常访问系统，完成业务处理。
衡量指标
业界通常用多少个 9 来说明互联网应用的可用性。
- 两个9：系统基本可用，年度不可用时间小于88小时
- 三个9：系统较高可用，年度不可用时间小于9个小时
- 四个9：具有自动恢复能力的高可用，年度不可用时间
- 五个9：极高的可用性，年度不可用时间小于5分钟
我们熟悉的互联网产品的可用性大多是 4 个 9。淘宝、百度、微信，差不多都是这样。
相对支付宝的可用性超过 99.99%，Twitter 的可用性只有 98%。
在互联网企业中，为了更好地管理系统的可用性，界定好系统故障以后的责任，通常会用故障分进行管理。
架构策略
- 提高应灾能力
- 冗余备份：数据库主主复制
- 负载均衡
- 异地多活
- 保护策略
- 失败隔离：限制影响范围。主要架构技术是消息队列
- 限流降级
