阿里P8架构师谈：多线程、架构、异步消息、Redis等性能优

常见性能优化策略分类

1.代码

之因此把代码放到第一位，是由于这一点最容易引发技术人员的忽视。不少技术人员拿到一个性能优化的需求之后，言必称缓存、异步、JVM等。实际上，第一步就应该是分析相关的代码，找出相应的瓶颈，再来考虑具体的优化策略。有一些性能问题，彻底是因为代码写的不合理，经过直接修改一下代码就能解决问题的，好比for循环次数过多、做了不少无谓的条件判断、相同逻辑重复屡次等。

2.数据库

数据库的调优，总的来讲分为如下三部分：

3.SQL调优

这是最经常使用、每个技术人员都应该掌握基本的SQL调优手段（包括方法、工具、辅助系统等）。这里以MySQL为例，最多见的方式是，由自带的慢查询日志或者开源的慢查询系统定位到具体的出问题的SQL，而后使用explain、profile等工具来逐步调优，最后通过测试达到效果后上线。这方面的细节，能够参考MySQL索引原理及慢查询优化。

4.架构层面的调优

这一类调优包括读写分离、多从库负载均衡、水平和垂直分库分表等方面，通常须要的改动较大，可是频率没有SQL调优高，并且通常须要DBA来配合参与。那么何时须要作这些事情？咱们能够经过内部监控报警系统（好比Zabbix），按期跟踪一些指标数据是否达到瓶颈，一旦达到瓶颈或者警惕值，就须要考虑这些事情。一般，DBA也会按期监控这些指标值。

5.链接池调优

咱们的应用为了实现数据库链接的高效获取、对数据库链接的限流等目的，一般会采用链接池类的方案，即每个应用节点都管理了一个到各个数据库的链接池。随着业务访问量或者数据量的增加，原有的链接池参数可能不能很好地知足需求，这个时候就须要结合当前使用链接池的原理、具体的链接池监控数据和当前的业务量做一个综合的判断，经过反复的几回调试获得最终的调优参数。

缓存分类：本地缓存+分布式缓存

本地缓存（HashMap/ConcurrentHashMap、Ehcache、Guava Cache等） 缓存服务（Redis/Tair/Memcache等）

1.使用场景

什么状况适合用缓存？考虑如下两种场景：

短期内相同数据重复查询屡次且数据更新不频繁，这个时候能够选择先从缓存查询，查询不到再从数据库加载并回设到缓存的方式。此种场景较适合用单机缓存。 高并发查询热点数据，后端数据库不堪重负，能够用缓存来扛。 2.选型考虑

若是数据量小，而且不会频繁地增加又清空（这会致使频繁地垃圾回收），那么能够选择本地缓存。具体的话，若是须要一些策略的支持（好比缓存满的逐出策略），能够考虑Ehcache；如不须要，能够考虑HashMap；如须要考虑多线程并发的场景，能够考虑ConcurentHashMap。 其余状况，能够考虑缓存服务。目前从资源的投入度、可运维性、是否能动态扩容以及配套设施来考虑，咱们优先考虑Tair。除非目前Tair还不能支持的场合（好比分布式锁、Hash类型的value），咱们考虑用Redis。 3.设计关键点

何时更新缓存？如何保障更新的可靠性和实时性？

更新缓存的策略，须要具体问题具体分析。 4.缓存是否会满，缓存满了怎么办？

对于一个缓存服务，理论上来讲，随着缓存数据的日益增多，在容量有限的状况下，缓存确定有一天会满的。如何应对？

① 给缓存服务，选择合适的缓存逐出算法，好比最多见的LRU。

② 针对当前设置的容量，设置适当的警惕值，好比10G的缓存，当缓存数据达到8G的时候，就开始发出报警，提早排查问题或者扩容。

③ 给一些没有必要长期保存的key，尽可能设置过时时间。

5.缓存是否容许丢失？丢失了怎么办？

根据业务场景判断，是否容许丢失。若是不容许，就须要带持久化功能的缓存服务来支持，好比Redis或者Tair。更细节的话，能够根据业务对丢失时间的容忍度，还能够选择更具体的持久化策略，好比Redis的RDB或者AOF。

6.缓存被“击穿”问题

对于一些设置了过时时间的key，若是这些key可能会在某些时间点被超高并发地访问，是一种很是“热点”的数据。这个时候，须要考虑另一个问题：缓存被“击穿”的问题。

概念：缓存在某个时间点过时的时候，刚好在这个时间点对这个Key有大量的并发请求过来，这些请求发现缓存过时通常都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

如何解决：业界比较经常使用的作法，是使用mutex。简单地来讲，就是在缓存失效的时候（判断拿出来的值为空），不是当即去load db，而是先使用缓存工具的某些带成功操做返回值的操做（好比Redis的SETNX或者Memcache的ADD）去set一个mutex key，当操做返回成功时，再进行load db的操做并回设缓存；不然，就重试整个get缓存的方法。相似下面的代码：

public String get(key) {

String value = redis.get(key);

if (value == null) { //表明缓存值过时

//设置3min的超时，防止del操做失败的时候，下次缓存过时一直不能load db

if (redis.setnx(key_mutex, 1, 3 * 60) == 1) { //表明设置成功

value = db.get(key);

redis.set(key, value, expire_secs);

redis.del(key_mutex);

} else { //这个时候表明同时候的其余线程已经load db并回设到缓存了，这时候重试获取缓存值便可

sleep(50);

get(key); //重试

}

} else {

return value;

}

}

异步消息调用

1.使用场景

针对某些客户端的请求，在服务端可能须要针对这些请求作一些附属的事情，这些事情其实用户并不关心或者用户不须要当即拿到这些事情的处理结果，这种状况就比较适合用异步的方式处理这些事情。

2.做用

缩短接口响应时间，使用户的请求快速返回，用户体验更好。 避免线程长时间处于运行状态，这样会引发服务线程池的可用线程长时间不够用，进而引发线程池任务队列长度增大，从而阻塞更多请求任务，使得更多请求得不到技术处理。 线程长时间处于运行状态，可能还会引发系统Load、CPU使用率、机器总体性能降低等一系列问题，甚至引起雪崩。异步的思路能够在不增长机器数和CPU数的状况下，有效解决这个问题。 4.常见作法

一种作法，是额外开辟线程，这里能够采用额外开辟一个线程或者使用线程池的作法，在IO线程（处理请求响应）以外的线程来处理相应的任务，在IO线程中让response先返回。

若是异步线程处理的任务设计的数据量很是巨大，那么能够引入阻塞队列BlockingQueue做进一步的优化。具体作法是让一批异步线程不断地往阻塞队列里扔数据，而后额外起一个处理线程，循环批量从队列里拿预设大小的一批数据，来进行批处理（好比发一个批量的远程服务请求），这样进一步提升了性能。

另外一种作法，是使用消息队列（MQ）中间件服务，MQ天生就是异步的。一些额外的任务，可能不须要我这个系统来处理，可是须要其余系统来处理。这个时候能够先把它封装成一个消息，扔到消息队列里面，经过消息中间件的可靠性保证把消息投递到关心它的系统，而后让这个系统来作相应的处理。

好比C端在完成一个提单动做之后，可能须要其它端作一系列的事情，可是这些事情的结果不会马上对C端用户产生影响，那么就能够先把C端下单的请求响应先返回给用户，返回以前往MQ中发一个消息便可。并且这些事情理应不是C端的负责范围，因此这个时候用MQ的方式，来解决这个问题最合适。

NoSQL和缓存的区别

先说明一下，这里介绍的和缓存那一节不同，虽然可能会使用同样的数据存储方案（好比Redis或者Tair），可是使用的方式不同，这一节介绍的是把它做为DB来用。若是看成DB来用，须要有效保证数据存储方案的可用性、可靠性。

1.使用场景

须要结合具体的业务场景，看这块业务涉及的数据是否适合用NoSQL来存储，对数据的操做方式是否适合用NoSQL的方式来操做，或者是否须要用到NoSQL的一些额外特性（好比原子加减等）。

若是业务数据不须要和其余数据做关联，不须要事务或者外键之类的支持，并且有可能写入会异常频繁，这个时候就比较适合用NoSQL（好比HBase）。

JVM调优何时调？ 经过监控系统（如没有现成的系统，本身作一个简单的上报监控的系统也很容易）上对一些机器关键指标（gc time、gc count、各个分代的内存大小变化、机器的Load值与CPU使用率、JVM的线程数等）的监控报警，也能够看gc log和jstat等命令的输出，再结合线上JVM进程服务的一些关键接口的性能数据和请求体验，基本上就能定位出当前的JVM是否有问题，以及是否须要调优。

怎么调？

1.若是发现高峰期CPU使用率与Load值偏大，这个时候能够观察一些JVM的thread count以及gc count（可能主要是young gc count），若是这两个值都比以往偏大（也能够和一个历史经验值做对比），基本上能够定位是young gc频率太高致使，这个时候能够经过适当增大young区大小或者占比的方式来解决。

2.若是发现关键接口响应时间很慢，能够结合gc time以及gc log中的stop the world的时间，看一下整个应用的stop the world的时间是否是比较多。若是是，可能须要减小总的gctime，具体能够从减少gc的次数和减少单次gc的时间这两个维度来考虑，通常来讲，这两个因素是一对互斥因素，咱们须要根据实际的监控数据来调整相应的参数（好比新生代与老生代比值、eden与survivor比值、MTT值、触发cms回收的old区比率阈值等）来达到一个最优值。

3.若是发生full gc或者old cms gc很是频繁，一般这种状况会诱发STW的时间相应加长，从而也会致使接口响应时间变慢。这种状况，大几率是出现了“内存泄露”，Java里的内存泄露指的是一些应该释放的对象没有被释放掉（还有引用拉着它）。那么这些对象是如何产生的呢？为啥不会释放呢？对应的代码是否是出问题了？问题的关键是搞明白这个，找到相应的代码，而后对症下药。因此问题的关键是转化成寻找这些对象。怎么找？综合使用jmap和MAT，基本就能定位到具体的代码。

多线程与分布式

1.使用场景

离线任务、异步任务、大数据任务、耗时较长任务的运行**，适当地利用，可达到加速的效果。

注意：线上对响应时间要求较高的场合，尽可能少用多线程，尤为是服务线程须要等待任务线程的场合（不少重大事故就是和这个息息相关），若是必定要用，能够对服务线程设置一个最大等待时间。

2.常见作法

若是单机的处理能力能够知足实际业务的需求，那么尽量地使用单机多线程的处理方式，减小复杂性；反之，则须要使用多机多线程的方式。

对于单机多线程，能够引入线程池的机制，做用有二：

提升性能，节省线程建立和销毁的开销

限流，给线程池一个固定的容量，达到这个容量值后再有任务进来，就进入队列进行排队，保障机器极限压力下的稳定处理能力在使用JDK自带的线程池时，必定要仔细理解构造方法的各个参数的含义，如core pool size、max pool size、keepAliveTime、worker queue等，在理解的基础上经过不断地测试调整这些参数值达到最优效果。 若是单机的处理能力不能知足需求，这个时候须要使用多机多线程的方式。这个时候就须要一些分布式系统的知识了。首先就必须引入一个单独的节点，做为调度器，其余的机器节点都做为执行器节点。调度器来负责拆分任务，和分发任务到合适的执行器节点；执行器节点按照多线程的方式（也多是单线程）来执行任务。这个时候，咱们整个任务系统就由单击演变成一个集群的系统，并且不一样的机器节点有不一样的角色，各司其职，各个节点之间还有交互。这个时候除了有多线程、线程池等机制，像RPC、心跳等网络通讯调用的机制也不可少。后续我会出一个简单的分布式调度运行的框架。

4.度量系统（监控、报警、服务依赖管理）

严格来讲，度量系统不属于性能优化的范畴，可是这方面和性能优化息息相关，能够说为性能优化提供一个强有力的数据参考和支撑。没有度量系统，基本上就没有办法定位到系统的问题，也没有办法有效衡量优化后的效果。不少人不重视这方面，但我认为它是系统稳定性和性能保障的基石。

5.关键流程

若是要设计这套系统，整体来讲有哪些关键流程须要设计呢？

① 肯定指标

② 采集数据

③ 计算数据，存储结果

④ 展示和分析

须要监控和报警哪些指标数据？须要关注哪些？ 按照需求出发，主要须要二方面的指标：

接口性能相关，包括单个接口和所有的QPS、响应时间、调用量（统计时间维度越细越好；最好是，既能以节点为维度，也能够以服务集群为维度，来查看相关数据）。其中还涉及到服务依赖关系的管理，这个时候须要用到服务依赖管理系统 单个机器节点相关，包括CPU使用率、Load值、内存占用率、网卡流量等。若是节点是一些特殊类型的服务（好比MySQL、Redis、Tair），还能够监控这些服务特有的一些关键指标。 1.数据采集方式

一般采用异步上报的方式，具体作法有两种：第一种，发到本地的Flume端口，由Flume进程收集到远程的Hadoop集群或者Storm集群来进行运算；第二种，直接在本地运算好之后，使用异步和本地队列的方式，发送到监控服务器。

2.数据计算

能够采用离线运算（MapReduce/Hive）或者实时/准实时运算（Storm/Spark）的方式，运算后的结果存入MySQL或者HBase；某些状况，也能够不计算，直接采集发往监控服务器。

3.展示和分析

提供统一的展示分析平台，须要带报表（列表/图表）监控和报警的功能。

其余

除了上面介绍的以外，优化还涉及前端、分布式文件系统、CDN、全文索引、空间索引等几方面。限于篇幅，咱们留到后续再作介绍的。

喜欢加关注哦