7. 锁粒度
在某些业务场景中，为了防止多个线程并发修改某个共享数据，造成数据异常。
为了解决并发场景下，多个线程同时修改数据，造成数据不一致的情况。通常情况下，我们会：加锁。
但如果锁加得不好，导致锁的粒度太粗，也会非常影响接口性能。
7.1 synchronized
在java中提供了synchronized关键字给我们的代码加锁。
通常有两种写法：在方法上加锁 和 在代码块上加锁。
先看看如何在方法上加锁：
public synchronized doSave(String fileUrl) { mkdir(); uploadFile(fileUrl); sendMessage(fileUrl); }
这里加锁的目的是为了防止并发的情况下，创建了相同的目录，第二次会创建失败，影响业务功能。
但这种直接在方法上加锁，锁的粒度有点粗。因为doSave方法中的上传文件和发消息方法，是不需要加锁的。只有创建目录方法，才需要加锁。
我们都知道文件上传操作是非常耗时的，如果将整个方法加锁，那么需要等到整个方法执行完之后才能释放锁。显然，这会导致该方法的性能很差，变得得不偿失。
这时，我们可以改成在代码块上加锁了，具体代码如下：
public void doSave(String path,String fileUrl) { synchronized(this) { if(!exists(path)) { mkdir(path); } } uploadFile(fileUrl); sendMessage(fileUrl); }
这样改造之后，锁的粒度一下子变小了，只有并发创建目录功能才加了锁。而创建目录是一个非常快的操作，即使加锁对接口的性能影响也不大。
最重要的是，其他的上传文件和发送消息功能，任然可以并发执行。
当然，这种做在单机版的服务中，是没有问题的。但现在部署的生产环境，为了保证服务的稳定性，一般情况下，同一个服务会被部署在多个节点中。如果哪天挂了一个节点，其他的节点服务任然可用。
多节点部署避免了因为某个节点挂了，导致服务不可用的情况。同时也能分摊整个系统的流量，避免系统压力过大。
同时它也带来了新的问题：synchronized只能保证一个节点加锁是有效的，但如果有多个节点如何加锁呢?
答：这就需要使用：分布式锁了。目前主流的分布式锁包括：redis分布式锁、zookeeper分布式锁 和 数据库分布式锁。
由
public void doSave(String path,String fileUrl) { try { String result = jedis.set(lockKey, requestId, "NX", "PX", expireTime); if ("OK".equals(result)) { if(!exists(path)) { mkdir(path); uploadFile(fileUrl); sendMessage(fileUrl); } return true; } } finally{ unlock(lockKey,requestId); } return false; }
于zookeeper分布式锁的性能不太好，真实业务场景用的不多，这里先不讲。
下面聊一下redis分布式锁。
7.2 redis分布式锁
在分布式系统中，由于redis分布式锁相对于更简单和高效，成为了分布式锁的首先，被我们用到了很多实际业务场景当中。
使用redis分布式锁的伪代码如下：
跟之前使用synchronized关键字加锁时一样，这里锁的范围也太大了，换句话说就是锁的粒度太粗，这样会导致整个方法的执行效率很低。
其实只有创建目录的时候，才需要加分布式锁，其余代码根本不用加锁。
于是，我们需要优化一下代码：
public void doSave(String path,String fileUrl) { if(this.tryLock()) { mkdir(path); } uploadFile(fileUrl); sendMessage(fileUrl); } private boolean tryLock() { try { String result = jedis.set(lockKey, requestId, "NX", "PX", expireTime); if ("OK".equals(result)) { return true; } } finally{ unlock(lockKey,requestId); } return false; }
上面代码将加锁的范围缩小了，只有创建目录时才加了锁。这样看似简单的优化之后，接口性能能提升很多。说不定，会有意外的惊喜喔。哈哈哈。
redis分布式锁虽说好用，但它在使用时，有很多注意的细节，隐藏了很多坑，如果稍不注意很容易踩中。详细内容可以看看我的另一篇文章《聊聊redis分布式锁的8大坑》
7.3 数据库分布式锁
mysql数据库中主要有三种锁：
表锁：加锁快，不会出现死锁。但锁定粒度大，发生锁冲突的概率最高，并发度最低。
行锁：加锁慢，会出现死锁。但锁定粒度最小，发生锁冲突的概率最低，并发度也最高。
间隙锁：开销和加锁时间界于表锁和行锁之间。它会出现死锁，锁定粒度界于表锁和行锁之间，并发度一般。
并发度越高，意味着接口性能越好。
所以数据库锁的优化方向是：
优先使用行锁，其次使用间隙锁，再其次使用表锁。
赶紧看看，你用对了没？
8.分页处理
有时候我会调用某个接口批量查询数据，比如：通过用户id批量查询出用户信息，然后给这些用户送积分。
但如果你一次性查询的用户数量太多了，比如一次查询2000个用户的数据。参数中传入了2000个用户的id，远程调用接口，会发现该用户查询接口经常超时。
调用代码如下：
List<User> users = remoteCallUser(ids);
众所周知，调用接口从数据库获取数据，是需要经过网络传输的。如果数据量太大，无论是获取数据的速度，还是网络传输受限于带宽，都会导致耗时时间比较长。
那么，这种情况要如何优化呢？
答：分页处理。
将一次获取所有的数据的请求，改成分多次获取，每次只获取一部分用户的数据，最后进行合并和汇总。
其实，处理这个问题，要分为两种场景：同步调用 和 异步调用。
8.1 同步调用
如果在job中需要获取2000个用户的信息，它要求只要能正确获取到数据就好，对获取数据的总耗时要求不太高。
但对每一次远程接口调用的耗时有要求，不能大于500ms，不然会有邮件预警。
这时，我们可以同步分页调用批量查询用户信息接口。
具体示例代码如下： List<List<Long>> allIds = Lists.partition(ids,200); for(List<Long> batchIds:allIds) { List<User> users = remoteCallUser(batchIds); }
代码中我用的google的guava工具中的Lists.partition方法，用它来做分页简直太好用了，不然要巴拉巴拉写一大堆分页的代码。
8.2 异步调用
如果是在某个接口中需要获取2000个用户的信息，它考虑的就需要更多一些。
除了需要考虑远程调用接口的耗时之外，还需要考虑该接口本身的总耗时，也不能超时500ms。
这时候用上面的同步分页请求远程接口，肯定是行不通的。
那么，只能使用异步调用了。
代码如下：
List<List<Long>> allIds = Lists.partition(ids,200); final List<User> result = Lists.newArrayList(); allIds.stream().forEach((batchIds) -> { CompletableFuture.supplyAsync(() -> { result.addAll(remoteCallUser(batchIds)); return Boolean.TRUE; }, executor); })
使用CompletableFuture类，多个线程异步调用远程接口，最后汇总结果统一返回。
9.加缓存
解决接口性能问题，加缓存是一个非常高效的方法。
但不能为了缓存而缓存，还是要看具体的业务场景。毕竟加了缓存，会导致接口的复杂度增加，它会带来数据不一致问题。
在有些并发量比较低的场景中，比如用户下单，可以不用加缓存。
还有些场景，比如在商城首页显示商品分类的地方，假设这里的分类是调用接口获取到的数据，但页面暂时没有做静态化。
如果查询分类树的接口没有使用缓存，而直接从数据库查询数据，性能会非常差。
那么如何使用缓存呢？
9.1 redis缓存
通常情况下，我们使用最多的缓存可能是：redis和memcached。
但对于java应用来说，绝大多数都是使用的redis，所以接下来我们以redis为例。
由于在关系型数据库，比如：mysql中，菜单是有上下级关系的。某个四级分类是某个三级分类的子分类，这个三级分类，又是某个二级分类的子分类，而这个二级分类，又是某个一级分类的子分类。
这种存储结构决定了，想一次性查出这个分类树，并非是一件非常容易的事情。这就需要使用程序递归查询了，如果分类多的话，这个递归是比较耗时的。
所以，如果每次都直接从数据库中查询分类树的数据，是一个非常耗时的操作。
这时我们可以使用缓存，大部分情况，接口都直接从缓存中获取数据。操作redis可以使用成熟的框架，比如：jedis和redisson等。
用jedis伪代码如下：
String json = jedis.get(key); if(StringUtils.isNotEmpty(json)) { CategoryTree categoryTree = JsonUtil.toObject(json); return categoryTree; } return queryCategoryTreeFromDb();
先从redis中根据某个key查询是否有菜单数据，如果有则转换成对象，直接返回。如果redis中没有查到菜单数据，则再从数据库中查询菜单数据，有则返回。
此外，我们还需要有个job每隔一段时间，从数据库中查询菜单数据，更新到redis当中，这样以后每次都能直接从redis中获取菜单的数据，而无需访问数据库了。
这样改造之后，能快速的提升性能。
但这样做性能提升不是最佳的，还有其他的方案，我们一起看看下面的内容。
9.2 二级缓存
上面的方案是基于redis缓存的，虽说redis访问速度很快。但毕竟是一个远程调用，而且菜单树的数据很多，在网络传输的过程中，是有些耗时的。
有没有办法，不经过请求远程，就能直接获取到数据呢？
答：使用二级缓存，即基于内存的缓存。
除了自己手写的内存缓存之后，目前使用比较多的内存缓存框架有：guava、Ehcache、caffine等。
我们在这里以caffeine为例，它是spring官方推荐的。
第一步，引入caffeine的相关jar包
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-cache</artifactId> </dependency> <dependency> <groupId>com.github.ben-manes.caffeine</groupId> <artifactId>caffeine</artifactId> <version>2.6.0</version> </dependency>
第二步，配置CacheManager，开启EnableCaching
@Configuration @EnableCaching public class CacheConfig { @Bean public CacheManager cacheManager(){ CaffeineCacheManager cacheManager = new CaffeineCacheManager(); //Caffeine配置 Caffeine<Object, Object> caffeine = Caffeine.newBuilder() //最后一次写入后经过固定时间过期 .expireAfterWrite(10, TimeUnit.SECONDS) //缓存的最大条数 .maximumSize(1000); cacheManager.setCaffeine(caffeine); return cacheManager; } }
第三步，使用Cacheable注解获取数据
@Service public class CategoryService { @Cacheable(value = "category", key = "#categoryKey") public CategoryModel getCategory(String categoryKey) { String json = jedis.get(categoryKey); if(StringUtils.isNotEmpty(json)) { CategoryTree categoryTree = JsonUtil.toObject(json); return categoryTree; } return queryCategoryTreeFromDb(); } }
调用categoryService.getCategory()方法时，先从caffine缓存中获取数据，如果能够获取到数据，则直接返回该数据，不进入方法体。
如果不能获取到数据，则再从redis中查一次数据。如果查询到了，则返回数据，并且放入caffine中。
如果还是没有查到数据，则直接从数据库中获取到数据，然后放到caffine缓存中。
具体流程图如下：
该方案的性能更好，但有个缺点就是，如果数据更新了，不能及时刷新缓存。此外，如果有多台服务器节点，可能存在各个节点上数据不一样的情况。
由此可见，二级缓存给我们带来性能提升的同时，也带来了数据不一致的问题。使用二级缓存一定要结合实际的业务场景，并非所有的业务场景都适用。
但上面我列举的分类场景，是适合使用二级缓存的。因为它属于用户不敏感数据，即使出现了稍微有点数据不一致也没有关系，用户有可能都没有察觉出来。
10. 分库分表
有时候，接口性能受限的不是别的，而是数据库。
当系统发展到一定的阶段，用户并发量大，会有大量的数据库请求，需要占用大量的数据库连接，同时会带来磁盘IO的性能瓶颈问题。
此外，随着用户数量越来越多，产生的数据也越来越多，一张表有可能存不下。由于数据量太大，sql语句查询数据时，即使走了索引也会非常耗时。
这时该怎么办呢？
答：需要做分库分表。
如下图所示：
图中将用户库拆分成了三个库，每个库都包含了四张用户表。
如果有用户请求过来的时候，先根据用户id路由到其中一个用户库，然后再定位到某张表。
路由的算法挺多的：
根据id取模，比如：id=7，有4张表，则7%4=3，模为3，路由到用户表3。
给id指定一个区间范围，比如：id的值是0-10万，则数据存在用户表0，id的值是10-20万，则数据存在用户表1。
一致性hash算法
分库分表主要有两个方向：垂直和水平。
说实话垂直方向（即业务方向）更简单。
在水平方向（即数据方向）上，分库和分表的作用，其实是有区别的，不能混为一谈。
分库：是为了解决数据库连接资源不足问题，和磁盘IO的性能瓶颈问题。
分表：是为了解决单表数据量太大，sql语句查询数据时，即使走了索引也非常耗时问题。此外还可以解决消耗cpu资源问题。
分库分表：可以解决 数据库连接资源不足、磁盘IO的性能瓶颈、检索数据耗时 和 消耗cpu资源等问题。
如果在有些业务场景中，用户并发量很大，但是需要保存的数据量很少，这时可以只分库，不分表。
如果在有些业务场景中，用户并发量不大，但是需要保存的数量很多，这时可以只分表，不分库。
如果在有些业务场景中，用户并发量大，并且需要保存的数量也很多时，可以分库分表。
关于分库分表更详细的内容，可以看看我另一篇文章，里面讲的更深入《阿里二面：为什么分库分表？》
11. 辅助功能
优化接口性能问题，除了上面提到的这些常用方法之外，还需要配合使用一些辅助功能，因为它们真的可以帮我们提升查找问题的效率。
11.1 开启慢查询日志
通常情况下，为了定位sql的性能瓶颈，我们需要开启mysql的慢查询日志。把超过指定时间的sql语句，单独记录下来，方面以后分析和定位问题。
开启慢查询日志需要重点关注三个参数：
slow_query_log 慢查询开关
slow_query_log_file 慢查询日志存放的路径
long_query_time 超过多少秒才会记录日志
通过mysql的set命令可以设置：
set global slow_query_log='ON'; set global slow_query_log_file='/usr/local/mysql/data/slow.log'; set global long_query_time=2;
设置完之后，如果某条sql的执行时间超过了2秒，会被自动记录到slow.log文件中。
当然也可以直接修改配置文件my.cnf
[mysqld] slow_query_log = ON slow_query_log_file = /usr/local/mysql/data/slow.log long_query_time = 2
但这种方式需要重启mysql服务。
很多公司每天早上都会发一封慢查询日志的邮件，开发人员根据这些信息优化sql。
11.2 加监控
为了出现sql问题时，能够让我们及时发现，我们需要对系统做监控。
目前业界使用比较多的开源监控系统是：Prometheus。
它提供了 监控 和 预警 的功能。
架构图如下：
我们可以用它监控如下信息：
接口响应时间
调用第三方服务耗时
慢查询sql耗时
cpu使用情况
内存使用情况
磁盘使用情况
数据库使用情况
等等。。。
它的界面大概长这样子：
可以看到mysql当前qps，活跃线程数，连接数，缓存池的大小等信息。
如果发现数据量连接池占用太多，对接口的性能肯定会有影响。
这时可能是代码中开启了连接忘了关，或者并发量太大了导致的，需要做进一步排查和系统优化。
截图中只是它一小部分功能，如果你想了解更多功能，可以访问Prometheus的官网：https://prometheus.io/
11.3 链路跟踪
有时候某个接口涉及的逻辑很多，比如：查数据库、查redis、远程调用接口，发mq消息，执行业务代码等等。
该接口一次请求的链路很长，如果逐一排查，需要花费大量的时间，这时候，我们已经没法用传统的办法定位问题了。
有没有办法解决这问题呢？
用分布式链路跟踪系统：skywalking。
架构图如下：
通过skywalking定位性能问题：
在skywalking中可以通过traceId（全局唯一的id），串联一个接口请求的完整链路。可以看到整个接口的耗时，调用的远程服务的耗时，访问数据库或者redis的耗时等等，功能非常强大。
之前没有这个功能的时候，为了定位线上接口性能问题，我们还需要在代码中加日志，手动打印出链路中各个环节的耗时情况，然后再逐一排查。
