一份平民化的应用性能优化CheckList（完整篇）

最新推荐文章于 2024-03-24 09:36:00 发布

安正勋

最新推荐文章于 2024-03-24 09:36:00 发布

阅读量1.3k

点赞数 1

文章标签：性能优化应用二进制可扩展通信

工具及其它专栏收录该内容

125 篇文章 110 订阅

订阅专栏

1 总原则

作者说：这是一些正确但稍显废话的原则，但能指导后面每个章节的优化，所以还是要啰嗦一次。

（1）可扩展性架构，堆机器能不能解决问题是最最优先考虑的问题
（2）去中心化的点对点通信，优于通过中心代理的通信
（3）池化的长连接，优于短连接
（4）二进制数据，优于文本数据
（5）尽量减少交互，一次调用的粗粒度聚合接口优于多次调用的细粒度接口
（6）尽量减少交互，批量接口优于循环调用
（7）尽量只交互必要的数据
（8）尽量就近访问
（9）尽量使用缓存
（10）总是设定超时
（11）在合适的场景，并行化执行
（12）在合适的场景，异步化执行

2 环境准备

保证符合自家各种规范（没有的话赶紧回家写一个），尤其线下压测服务器的配置要与生产环境一致。

2.1 操作系统

自家规范调优应包含TCP内核参数，网卡参数及多队列绑定，IO&swap内核参数，ulimit资源限制等。

2.2 JVM与应用服务器

使用JDK7.0 u80 或 JDK8 最新版；
检查JVM启动参数已按自家规范调优；
检查应用服务器(Tomcat或微服务容器) 已按自家指南调优，如线程数等。

2.3 周边依赖系统

检查数据库，缓存，消息系统，已按自家指南调优。

2.4 后台辅助程序

检查日志收集，系统监控等，已使用最新版本，最优配置；
最好其最大消耗已被控制（通过cgroup，taskset等方式）。

2.5 测试程序

压测工具如JMeter，启动参数要参考真实客户端优化（如JVM参数，Netty参数等）；
测试脚本和客户端程序经过review，不存在影响性能的步骤，不存在System.out.println()等明显的瓶颈。

2.6 流量模型

扇入模型：平时与高峰期的流量估算，各接口的流量比例，响应时间要求；
扇出模型：各接口对远程服务、数据库、缓存、消息系统的调用比例，响应时间估算，缓存的命中率，击穿时的访问模式。

大家在心里都有这么一个大概的模型，但很少认真写出来。行文到此，大家大概可以感受到这份checklist的风格，都是大家明白的道理，但可能一时也会忘掉的，这里啰啰嗦嗦的給写下来。

3 数据库

仅以MySQL举例，特别鸣谢，我司DBA，如聂超大侠，文中大量观点均来自他们。

3.1 拓扑

根据扩展性原则考虑：

垂直拆分：按业务将表拆分到不同的库；
水平拆分：分表分库；
读写分离：在业务允许的情况下，在从库读取非实时数据。

3.2 Schema

自家规范应包含：

统一的存储引擎，主键策略。
禁用存储过程，函数，触发器，外键约束。
列类型永远越短越好，建议：布尔/枚举：tinyint，日期与时间戳：timestamp或int，char/text/blob:
尽量用符合实际长度的varchar(n)，小数及货币：移位转为int 或 decimal，IP地址：int。
索引策略：索引字段的顺序需要考虑字段值去重之后的个数，较多的放前面，合理创建联合索引，避免冗余索引，合理利用覆盖索引等。

3.3 SQL

自家规范应包含：

禁止多于3表的join，禁用子查询
禁止where子句中对字段施加函数使索引失效，如to_date(add_time)>xxxxx
不建议使用%前缀模糊查询影响索引使用，模糊查询较多时建议使用ElasticSearch
避免隐式类型转化，如ISENDED=1 与 ISENDED=’1’

根据尽量少数据原则与尽量少交互的原则来设计SQL:

禁止select *
复杂度合理的SQL语句，减少交互次数。

根据扩展性原则，将负载放在更容易伸缩的应用服务实例上：

尽量不要做数学运算，函数运算, 或者输出格式转换等非必要操作
避免count(*)，计数统计实时要求较强使用memcache或者redis，非实时统计使用定时更新的单独统计表。
甚至排序都是不鼓励的，尽量在应用侧进行。另外避免多余的排序，使用GROUP BY 时，默认会进行排序，当你不需要排序时，可以使用order
by null。

联系DBA进行MySQL统计的慢查询的Review，解析SQL查询计划时尽量避免extra列出现：Using File Sort，Using Temporary

3.4 DAO框架

根据尽量少交互与尽量少数据的原则，需使用对SQL完全可控的DAO框架，建议为MyBatis 或 Spring JDBC Template。
必须使用prepareStatement，提升性能与防注入。
根据一切皆有超时的原则，配置SQL执行的超时。可在连接池里设置default值，可在MyBatis的Mapper定义里设置每个请求的超时，可惜规范是秒级的。
JDBC driver规范本身不支持异步模式，如果一定要异步，可以像Quasar那样把请求封装成Callable交给另外的线程池执行，但注意其额外开销。

3.5 事务

不使用事务，连接池设置autocommit，使用其他方式来保持数据一致性。
通过@Transaction控制事务，事务跨度尽量短，把非事务范围内的业务逻辑剔除到被标注的函数之外。
只读事务可以不加事务标注。

3.6 连接池

选型：

在水平分库分表时，根据点对点通信优先的原则，尽量使用客户端分片的实现。功能不满足时才用MyCat中央代理。
推荐使用性能最高HikariCP，或者Druid，或者Tomcat JDBC，不推荐c3p0与DBCP。

连接池的配置：

配置连接初始值，再联系DBA获得线上数据库支持的连接数，计算最大连接数。
连接有效性的检查，只在连接空闲检测时执行，不在获取和归还连接时执行。直接使用数据库的Ping方案，不要配置检查的SQL。
根据总是设置超时的原则，配置获取连接的超时时间。
配置合理的空闲连接回收间隔和空闲时间。

4 缓存

4.1 多级缓存

根据缓存原则，缓存 > 数据库/远程调用
根据就近原则，堆内缓存 > 堆外缓存 > 集中式缓存
堆内缓存受大小限制，并影响GC
堆内缓存与堆外缓存，分布在每一台应用服务器上，所以刷新方式比集中式的复杂
堆外缓存与集中式缓存，需要序列化/反序列化对象
集中式缓存，有网络传输的成本，特别是数据超过一个网络包的大小。如果一次获取多个键时，在有分区的情况下，更需要收发多个网络包。

使用上述条件选择合适的缓存方案，或同时使用多级缓存，逐层回源。

4.2 公共

需要对回源进行并发控制，当key失效时，只有单一线程对该key回源。
基于二进制优于文本数据的原则，JSON的序列化方案较通用与更高的可读性。
而较大，结构较复杂的对象，基于Kyro，PB，Thrift的二进制序列化方案的性能更高，见后面的序列化方案部分。

4.3 堆内缓存

选型：

推荐Guava Cache。
Ehcache较重，性能也较差。更不要使用存在严重并发bug的Jodd Cache。

GuavaCache：

正确设置并行度等参数。
重载load()函数，实现单一线程回源。
Guava Cache能在后台刷新，在刷新的过程中，依然使用旧数据响应请求，不会造成卡顿，但需要重载实现reload()函数。
Guava Cache同时还支持并发安全版的WeakHashMap。

4.4 堆外缓存

选型：

推荐Cassandra的OHC 或者 OpenHFT的Chronical map2。
OHC够简单，其实R大不喜欢Chronical，玩的太深，换个JDK都可能跑不起来。
Chronical map3的license则较不友好，复杂度高且要求JDK8。
其他如Ehcache的Terracota Offheap 一向不喜欢。

4.5 Memcached

客户端：

基于点对点通信优于网关的原则，使用客户端一致性哈希分区。
推荐Spymemcached。 XMemcached 太久没更新，Folsom知名度不高。
注意Spymemcached为单线程单连接架构（一个SpyClient只有一条IO线程，与每个Memcached只有一条连接），必要时可多建几个SpyClient随机选择,但不要用Commons Pool去封装它，把Spy原本的设计一笔抹杀。
根据在合适场景使用并发的原则，Spymemcached支持异步API。
根据一切皆设超时的原则，可在ConnectionFactory中设置最大超时数，默认值两秒半太长。

数据结构：

Key必须设置失效时间。
Key必须有长度限制。
Value长度需要控制，以不超过1个网络包(MTU 1500byte)为佳。
Value大小差别较大的缓存类型，建议拆分到不同MC集群，否则会造成低使用率并且产生踢出。

4.6 Redis as Cache

Redis拓扑，基于点对点通信优于网关的原则：

无HA的普通分片：由Jedis客户端完成分片路由。
Redis Cluster：同样由Jedis客户端封装分区，跳转，重试等逻辑。最好使用最新的Jedis版本，旧版太多bug。

服务端：

Cache节点与持久化数据节点不要混用。
Cache节点是否需要持久化要衡量。
对热键进行监控，发现不合理的热健要进行分拆等处理。

客户端：

Jedis基于Apache Commons Pool进行了多连接的封装，正确配置总连接数不超过Redis Server的允许连接数。
性能考虑，空闲连接检查不要过于频繁（建议30秒以上），另不要打开testOnBorrow等测试参数。
根据一切皆有超时的原则，设定统一的调用超时（默认2秒），获取连接的最长等待时间参数，重试次数。
根据在合适的地方异步的原则，Jedis本身没有异步API，只在PipleLine模式下支持。

数据结构：

Key必须设置失效时间。
Key必须有长度限制。
Value长度需要控制，以不超过1个网络包(MTU 1500byte)为佳。另外set和sorted的elements不要超过5000个。
除了使用序列化的String，可以考虑用Hash来存储对象，注意内部结构为ZipList与HashTable时，hmget
与hgetall的不同复杂度。

命令：

慎用的命令：LANGE(0, -1), HGETALL, SMEMBER
高复杂度的命令: ZINTERSTORE, SINTERSTORE, ZUNIONSTORE, ZREM
尽量使用多参数的命令：MGET/MSET，HMGET/HMSET, LPUSH/RPUSH等
根据减少交互的原则，尽量使用pipeline
根据减少交互的原则，必要时可使用Redis的Lua脚本

5 服务调用

5.1 接口设计

尽量少交互的原则：

支持批量接口，最大的批量，综合考虑调用者的需求与后端存储的能力。
支持粗粒度接口，在支持原子细粒度接口的同时，支持粗粒度接口/聚合层接口，将多个数据源的获取，多个动作，合并成一个粗粒度接口。

尽量少数据的原则：

在提供返回所有数据的大接口的同时，提供只提供满足部分调用者需要的轻量接口。
最好再提供能定制返回字段的接口。

二进制数据优于文本数据

同样是一个简单通用性，与性能的选择，特别是大数据量时。

5.2 RESTful

仅以Apache HttpClient为例，大部分Restful框架都是对Apache HttpClient的封装。另外OkHttp也值得看看。

不要重复创建ApacheClient实例，使用连接池，正确配置连接池的连接数。
连接池总是有锁，针对不同的服务，使用不同的Apache
HttpClient实例，将锁分散开来。在高并发时比使用全局单例的ApacheClient，有很大的性能提升。
根据一切调用皆有超时的原则，每次调用均设置超时时间。RequestConfig里共有Connect Timeout, Socket
Timout 和从Pool中获取连接的Timeout三种超时。
需要异步或并行的场景，使用Apache
AsyncHttpClient项目。但要注意AsyncHttpClient项目，检查调用超时的周期默认为1秒。

5.3 自家RPC框架

每家的RPC框架特性不同，但考虑点都类似。

6 消息异步

6.1 选型

根据就近原则，可以先尝试用JVM内的队列来解决，然后再考虑中央消息系统。
可靠性要求极高的选择RabbitMQ，可支持单条消息确认。
海量消息场景，允许极端情况下少量丢失则使用Kafka。

6.2 Kafka

根据扩展性原则，RabbitMQ本身没有分片功能，但可以在客户端自行分片。
在同步和异步之间做好权衡，异步批量发送可以极大的提高发送的速度。
关注消费者如下参数：commitInterval(自动提交offset间隔)，prefetchSize(指单次从服务器批量拉取消息的大小)，过大和过小都会影响性能，建议保持默认。

6.3 RabbitMQ

根据扩展性原则，RabbitMQ本身没有分片功能，但可以在客户端自行分片。
如非必要情况，应该保持默认的同步发送模式。
关注消费者如下参数：autocommit(自动提交确认，默认false)，在消息拉取到本地即认为消费成功，而不是真正消费成功后提交。prefetchCount(预取消息条数，默认64条)
生产者在必要时也可以临时降级不进行confirm。

7 日志

7.1 综述

Log4j2或logback，不要再使用Log4j。
除了应用启停日志，不允许使用超慢的System.out.println() 或 e.printStack();
严格控制日志量避免过高IO，对海量日志，应该有开关可以动态关停。
如果可能出现海量异常信息，可仿效JDK的优化，用RateLimiter进行限流，丢弃过多的异常日志。

7.2 内容

严格控制日志格式，避免出现消耗较大的输出如类名，方法名，行号等。
业务日志不要滥用toJSONString()来打印对象，尽量使用对象自身的toString()函数，因为JSON转换的消耗并不低。
在生产环境必定输出的日志，不要使用logger.info(“hello {}”,
name)的模式，而是使用正确估算大小的StringBuilder直接拼装输出信息。