高并发、高性能、高可用
高并发、高性能、高可用
部分转载：分布式架构中的三高：高并发、高性能、高可用-腾讯云开发者社区-腾讯云 (tencent.com)
概念
高并发、高可用和高性能是三个不同的概念，分别描述了系统在不同方面的特点和需求。以下是对它们的详细解释以及对应的措施：
高并发：
- 含义：高并发指系统能够同时处理大量的请求和事务，并保持良好的性能和响应速度。
- 实现措施：
- 负载均衡：通过将请求分发到多个服务器上，分担每个服务器的压力。
- 横向扩展：通过增加服务器数量来提高系统的并发处理能力。
- 缓存技术：使用缓存来减轻数据库的负担，提高系统的并发能力。
- 异步处理：将一些耗时的操作转换为异步处理，释放请求线程的资源。
- 优化数据库：通过优化数据库的查询语句、索引和结构等，提高数据库的并发性能。
高可用：
- 含义：高可用指系统具备持续稳定运行的能力，即使在出现故障或异常情况下也能保持连续的服务。
- 实现措施：
- 容错设计：采用冗余部署、备份和容灾机制来保障系统在故障时的恢复能力。
- 自动故障切换：实现自动故障检测和故障转移，确保服务的连续性。
- 监控和告警：建立监控系统，及时发现故障和异常，并触发告警通知。
- 数据备份与恢复：定期备份数据，并建立可靠的数据恢复和灾难恢复方案。
高性能：
- 含义：高性能指系统具备快速响应、高效利用资源和处理能力的能力。
- 实现措施：
- 优化算法和数据结构：选择高效的算法和数据结构，提高系统的执行效率。
- 并发编程：通过并发编程模型来充分利用多核处理能力，提高系统的并行处理能力。
- 持久化技术优化：对数据库的读写操作进行优化，例如使用批量操作和合理的事务处理。
- 缓存和数据库优化：通过使用内存缓存、分布式缓存等技术来减少对数据库的访问，并优化数据库的查询和索引。
需要根据具体的系统需求和架构来选择合适的措施来实现高并发、高可用和高性能。在设计和实施时，需要综合考虑系统的规模、负载、业务特点和资源限制等因素。
关于高并发
高并发场景
互联网应用以及云计算的普及，使得架构设计和软件技术的关注点从如何实现复杂的业务逻 辑，转变为如何满足大量用户的高并发访问请求。
一个简单的计算处理过程，如果一旦面对大量的用户访问，整个技术挑战就会变得完全不 同，软件开发方法、技术团队组织、软件的过程管理都会完全不同。
架构策略
垂直伸缩
垂直伸缩，就是提升单台服务器的处理能力。
比如用更快频率的 CPU，用更多核的 CPU，用更大的内存，用更快的网卡，用更多的磁盘组成一台服务器，使单台服务器的处理能力得到提升。
垂直伸缩带来的价格成本和服务器的处理能力并不一定呈线性关系。
增加同样的费用，并不能得到同样的计算能力。而且计算能力越强大，需要花费的钱就越多。
而且，受计算机硬件科技水平的制约，单台服务器的计算能力并不能无限增加，而互联网，特别是物联网的计算要求几乎是无限的。
因此，在互联网以及物联网领域，并不使用垂直伸缩这种方案，而是使用水平伸缩。
水平伸缩
所谓的水平伸缩，指的是不去提升单机的处理能力，而是使用更多的服务器，将这些服务器构成一个分布式集群，通过这个集群，对外统一提供服务，以此来提高系统整体的处理能力。
但是要想让更多的服务器构成一个整体，就需要在架构上进行设计，让这些服务器成为整体 系统的一个部分，将这些服务器有效地组织起来，统一提升系统的处理能力。
这就是互联网应用和云计算中普遍采用的分布式架构方案。
分布式技术方案
将这些分布式技术整合起来，就是分布式架构方案
互联网分布式架构演化
单机架构
微服务架构
分布式缓存架构
负载均衡架构
数据库读写分离
消息队列&反向代理&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%。
在互联网企业中，为了更好地管理系统的可用性，界定好系统故障以后的责任，通常会用故障分进行管理。
架构策略
- 提高应灾能力
- 冗余备份：数据库主主复制
- 负载均衡
- 异地多活
- 保护策略
- 失败隔离：限制影响范围。主要架构技术是消息队列
- 限流降级