目录
本文主要讲解，在高可用和高性能建设方面一些经验和总结。
一 合理设置网络超时时间
1.1 什么叫网络调用超时时间呢？
如应用服务器之间、应用服务器与 redis 服务器之间、应用服务器与 mq 服务器之间的网络请求，这些网络请求一般有三个超时时间：
- connectRequestTimeout ：客户端从连接池获取连接超时时间。
- connectTimeout：客户端与服务端建立连接超时时间。
- socketTimeout ：客户端与服务端读取数据超时时间。
1.2 为什么需要设置超时时间？
由于系统的连接池或者线程池的资源是有限的，假设没有设置超时时间，由于下游服务慢或者下游服务异常，将会出现大量的线程在傻傻的等待下游服务返回，
一些正常的请求将等待或者被拒绝，服务响应变慢，吞吐率下降，QPS 变低，用户体验变差。这种情况是可以通过设置超时时间来避免的。
1.3 如何合理的设置超时时间？
简单的原则就是：socketTimeout, connectTimeout，connectRequestTimeout 3个超时时间，不要超过300ms，在系统能接受的情况下尽量短。超时时间代码实现：
HttpClient实战：连接池设置_新猿一马的博客-CSDN博客_httpclient 设置连接池一 为什么 HttpClient 需要连接池 一次创建连接是一次 TCP 进行三次握手的操作，一次销毁连接是一次 TCP 进行四次挥手的操作。采用连接池技术管理连接，连接可以得到复用，能给减少在创建连接和销毁连接所花的时间，减少服务器资源的消耗，能够达到较高的并发。二 连接池的配置public class HttpClientUtils { // 客户端从服务端...
https://blog.csdn.net/jack1liu/article/details/99697995可以根据系统的99线来设置超时时间。所谓的99线，就是满足百分之九十九的网络请求所需要的最低耗时。简单点说，假设我们这块的有一个接口一天请求了1万次，计算能保证9900次请求所需要的最低耗时就叫99线。具体计算可以参考这篇文章：
TP50、TP90、TP99的理解和使用_新猿一马的博客-CSDN博客_tp90 tp99 怎么获得一 TP50、TP90、TP99 的概念1.1 什么是 TPTP 是 Top Percentile 的缩写，中文译作百分位。1.2 什么是百分位百分位是一个统计学的术语。如果将一组数据从小到大排序，并计算相应的累计百分位，则某一百分位所对应数据的值就称为这一百分位的百分位数。可表示为：一组N个观测值按数值大小排列。如，处于P%位置的值称第P百分位数。1.3 TP50、TP90、TP99 怎么理解TP50、TP90、TP99 是工程性能指标，以网络请求耗时为例：TP50：表https://blog.csdn.net/jack1liu/article/details/116085362redis 正常读写在2-3ms，超时时间需要设置更短，尽量不要超过 50ms。mq 的超时也是同样。
二 核心和非核心业务分离
每一个公司都有核心业务和非核心业务，针对核心业务可以梳理出来核心链路，所谓的核心链路应该是公司最值钱的业务，在链路上核心业务只能调用核心业务，
非核心业务只能调用非核心业务。如果公司可以的话，实现核心业务双机房、甚至多机房部署。
三 合理配置 tomcat 线程数
合理配置线程数，比如 CPU 型密集型的可以配置少些，IO 密集型的可以配置多些。 具体可以参考这篇文章 :
四 代码中尽量不要出现重试
如果没有什么特殊原因，请不要在代码中重试，重试尽量是业务重试，由上游业务人员进行重试操作。
4.1 为什么不要在代码中重试呢？
如果在代码中重试，这块很容易出现流量放大，平时1倍的量，如果重试5次，流量将是平时的5倍。很容易将服务打挂。
五 非必要依赖进行弱化处理
5.1 什么叫弱依赖化？
所谓的弱依赖化，就是对主流程影响较小的流程进行弱依赖。
如 mq/redis 在发生 timeout exception 时，如果不影响主要功能，需要 catch 异常，不要抛到上层。举例来说：
String value = redis.get(“key”);
if(value == null) {
value = dao.getOneColumn(“”);
}
}如果没有catch弱依赖redis，在 redis 故障时，直接向上层抛出异常，无法从数据库读出数据。
mq 的容错除了catch 以外，需要考虑在 mq 不可用时，丢失的消息如何处理？比如改发 mq 为记录日志，后期再处理。
六 数据库事务精简
事务内的操作应当尽可能少，减少事务执行时间，绝对不能有 RPC 调用。
七 SQL性能优化要点
7.1 怎么定义慢SQL？
理论上用户侧 SQL 的执行应该在10ms内，超过50ms已经可以归为慢 SQL。
7.2 SQL查询数量限制多少合适？
比如 limit 限制不允许超过100或者200，in 的 id 限制也在100或者200。
7.3 如何查看新增的 SQL 没有问题呢？
使用 explain 可以查看 SQL 的执行计划。
给相关的查询字段添加索引，加快查询速度。
具体的优化详情，请参考这篇文章：
SQL优化最佳实践_新猿一马的博客-CSDN博客本文是通过实践总结的，SQL优化的重点和要点。还需要在实践中灵活运用。https://blog.csdn.net/jack1liu/article/details/123146941?spm=1001.2014.3001.5502
八 上线过程尽量做到平滑
比如数据库迁移，方案设计和上线流程过程中一定要考虑到两个核心点：最大程度控制影响面、快速恢复。
如何最大程度控制影响面？
- 可以考虑灰度过程，逐步放量。
- 为了验证功能，可以添加白名单等。
如何将功能快速恢复？
- 添加一些动态开关，能快速恢复功能。
- 提前准备好，线上回滚方案。
九 限流、熔断、降级、排队处理异常流量
笔者就遇到过，因为异常流量导致服务暂不可用的问题，详情可以看：
记一次大量499http状态码问题出现与处理_新猿一马的博客-CSDN博客_499 http目录问题描述问题分析问题解决总结思考问题描述1 19:38 DBA 发现加解密数据库 DTS 出现延迟，查看数据库监控，发现 ALI 机房出现大量写入。2 19:41 架构组研发查看 cat 监控，发现加解密服务、消息中心服务等一些其他的服务出现总共2万多的499状态码。3 19:43 加解密数据库 DTS 恢复正常，加解密数据库的 ALI 机房不再有大量写入。4 20:00 加解密服务研发发现流量主要来源是消息中心服务，马上联系消息中心服务的负责人，了解业务情况。.https://blog.csdn.net/jack1liu/article/details/112135898当然了，针对服务中的异常流量也可以使用熔断、降级和排队技术。只要能解决问题，都是ok的。
十 完善日志和监控功能
我们应该打印合理且必要的日志数据。
10.1 什么叫合理且必要的日志呢？
能给我们排查业务问题、排查系统问题的日志都是合理且必要的。
10.2 为什么需要完善监控功能？
如果没有监控，我们会感觉我们的额服务其实在裸奔，假设出现了问题，监控能更快、更有效的帮助我们发现、复现、解决问题。
扫一扫
851
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
