为了更好评估后端接口性能，我们需要对不同行为的耗时进行比较。从上图可以看出，一个CPU周期少于1纳秒，而一次从北京到上海的跨地域访问可能需要约30毫秒。怎么计算跨地域耗时呢？
我们已知光在真空中传播，折射率为 1，其光速约为 c=30 万公里/秒，当光在其他介质里来面传播，其介质折射自率为 n,光在其中的速度就降为 v=c/n，光纤的材料是二氧化硅，其折射率 n 为 1.44 左右，计算延迟的时候，可以近似认为 1.5，我们通过计算可以得出光纤中的光传输速度近似为 v=c/1.5= 20 万公里/秒。
以北京和深圳为例，直线距离 1920 公里，接近 2000 公里，传输介质如果使用光纤光缆，那么延迟时间 t=L/v = 0.2 万公里/20 万公里/秒=10ms ，也就是说从北京到深圳拉一根 2000 公里的光缆，单纯的距离延迟就要 10ms ，实际上是没有这么长的光缆的，中间是需要通过基站来进行中继，并且当光功率损耗到一定值以后，需要通过转换器加强功率以后继续传输，这个中转也是要消耗时间的。另外数据包在网络中长距离传输的时候是会经过多次的封包和拆包，这个也会消耗时间。
综合考虑各种情况以后，以北京到深圳为例，总的公网延迟大约在 40ms 左右，北京到上海的公网延迟大约在 30ms，如果数据出国的话，延迟会更大，比如中国到美国，延迟一般在 150ms ~ 200ms 左右，因为要经过太平洋的海底光缆过去的。
如果让你进行后端接口的优化，你是首选优化代码行数？还是首选避免跨地域访问呢？
在评估接口性能时，我们需要首先找出最耗时的部分，并优化它，这样优化效果才会立竿见影。上图提供了一个很好的参考。
需要注意的是，上图中没有显示机房内网络的耗时。一次机房内网络的延迟（Ping）通常在1毫秒以内，相比跨地域网络延迟要少很多。
对于机房内的访问，Redis缓存的访问耗时通常在1-5毫秒之间，而数据库的主键索引访问耗时在5-15毫秒之间。当然，这两者最大的区别不仅仅在于耗时，而更重要的是它们在承受高并发访问方面的能力。Redis单机可以承受10万并发（往往瓶颈在网络带宽和CPU），而MySQL要考虑主从读写分离和分库分表，才能稳定支持5千并发以上的访问。
我曾经对用户（会员）主页接口进行了优化，该接口返回的数据非常庞大。由于各个模块的数据都在同一个接口中，只要其中一部分数据的查询耗时较长，整体性能就会下降，导致接口的失败率增加，前端无法展示核心数据。这主要是因为核心数据和非核心数据没有进行隔离，耗时数据和非耗时数据没有分开。
对于庞大的接口，我们需要先梳理每个模块中数据的获取逻辑和性能情况，明确前端必须展示和重点关注的核心数据，并确保这些数据能够快速、稳定地响应给前端。而非核心的数据和性能较差的数据则可以拆分到另外的接口中，即使这些接口的失败率较高，对用户影响也不大。
这种优化方式除了能保证快速返回核心数据，也能提高稳定性。如果非核心数据故障，可以单独降级，不会影响核心数据展示，大大提高了稳定性。
后端提供给前端的接口应保证能够独立调用，避免出现需要先调用A接口再调用B接口的情况。如果接口设计不合理，前端需要的总耗时将是A接口耗时与B接口耗时之和。相反，如果接口能够独立调用，总耗时将取决于A接口和B接口中耗时较长的那个。显然，后者的性能更优。
在A接口与B接口都依赖相同的公共数据的情况下，会导致重复查询。为了优化总耗时，重复查询是无法避免的，因此应着重优化公共数据的性能。
在代码设计层面，应封装每个模块的取值逻辑，避免A接口与B接口出现重复代码或拷贝代码的情况。
在提单接口中，需要校验用户对应商品的可见性、是否符合优惠活动规则以及是否可用对应的优惠券等内容。由于用户可能篡改报文来伪造提单请求，后端必须进行校验。然而，由于提单链路本身耗时较长，多次校验以上数据将大大增加接口的耗时。那么，是否可以不进行以上内容的校验呢？
是可以的。在用户提单页面，商品数据、优惠活动数据以及优惠券等数据都是预览接口校验过的。后端可以生成一个预览Token，并将预览结果存在缓存中，前端在提单接口中指定预览Token。后端将校验提单数据和预览数据是否一致，如果不一致，则说明用户伪造了请求。
为了避免预览数据占用过多的缓存空间，可以设置一个过期时间，例如预览数据在15分钟内不进行下单操作，则会自动失效。另外，还可以对关键数据进行MD5加密处理，加密后的数据只有64位，数据量大大减少。后端在提单接口中对关键数据进行MD5加密，并与缓存中的MD5值进行比对，如果不一致，则说明用户伪造了提单数据。
更详细请参考 # 如何防止提单数据被篡改？
在写接口耗时较高的情况下，可以采取将接口拆分为两步来优化性能。首先，第一步是接收请求并创建一个异步任务，然后将任务交给后端进行处理。第二步是前端轮训异步任务的执行结果，以获取最终结果。
通过将同步接口异步化，可以避免后端线程资源被长时间占用，并且可以避免浏览器和服务器的socket连接被长时间占用，从而提高系统的并发能力和稳定性。
此外，还可以在前端接口设置更长的轮训时间，以有效提高接口的成功率，降低同步接口超时失败的概率，提升系统的性能和用户体验。
在电商领域，商品详情页和活动详情页通常会有非常高的流量，特别是在秒杀场景或大促场景下，流量会更高。同时，商品详情页通常包含大量的信息，例如商品介绍、商品参数等，导致每次访问商品详情都需要访问后端接口，给后端接口带来很大的压力。
为了解决这个问题，可以考虑将商品详情页中不会变动的部分（如商品介绍、头图、商品参数等）静态化到html文件中，前端浏览器直接访问这些静态文件，而无需访问后端接口。这样做可以极大地减轻商品详情接口的查询压力。
然而，对于未上架的商品详情页、后台管理等页面，仍然需要查询商品详情接口来获取最新的信息。
页面静态化需要先使用模版工具例如Thymeleaf等，将商品详情数据渲染到Html文件，然后使用运维工具（rsync）将html文件同步到各个nginx机器。前端就可以访问对应的商品详情页。
当商品上下架状态变化时，将对应Html文件重新覆盖或置为失效。
CDN（内容分发网络）是一种分布式网络架构，它将网站的静态内容缓存在全球各地的服务器上，使用户能够从最近的服务器获取所需内容，从而加速用户访问。这样，用户不需要从原始服务器请求内容，可以减少因网络延迟导致的等待时间，提高用户的访问速度和体验。
通过注入静态Html文件到CDN，可以避免每次用户的请求都访问原始服务器。相反，这些文件会被缓存在CDN的服务器上，因此用户可以直接从离他们最近的服务器获取内容。这种方式可以大大减少因网络延迟导致的潜在用户流失，因为用户能够更快地获取所需的信息。
此外，CDN的使用还可以提高系统在高并发场景下的稳定性。在高并发情况下，原始服务器可能无法承受大量的请求流量，并可能导致系统崩溃或响应变慢。但是，通过将静态Html文件注入到CDN，让CDN来处理部分请求，分担了原始服务器的负载，从而提高了整个系统的稳定性。
通过将商品详情、活动详情等静态Html文件注入到CDN，可以加速用户访问速度，减少用户因网络延迟而流失的可能性，并提高系统在高并发场景下的稳定性。
调用链路优化重点减少RPC的调用、减少跨地域调用。
刚才我提到了北京到上海的跨地域调用需要耗费大约30毫秒的时间，这个耗时是相当高的，所以我们应该特别关注调用链路上是否存在跨地域调用的情况。这些跨地域调用包括Rpc调用、Http调用、数据库调用、缓存调用以及MQ调用等等。在整理调用链路的时候，我们还应该标注出跨地域调用的次数，例如跨地域调用数据库可能会出现多次，在链路上我们需要明确标记。我们可以考虑通过降低调用次数来提高性能，因此在设计优化方案时，我们应该特别关注如何减少跨地域调用的次数。
举个例子，在某种情况下，假设上游服务在上海，而我们的服务在北京和上海都有部署，但是数据库和缓存的主节点都在北京，这时候就无法避免跨地域调用。那么我们该如何进行优化呢？考虑到我们的服务会更频繁地访问数据库和缓存，如果让我们上海节点的服务去访问北京的数据库和缓存，那么跨地域调用的次数就会非常多。因此，我们应该让上游服务去访问我们在北京的节点，这样只会有1次跨地域调用，而我们的服务在访问数据库和缓存时就无需进行跨地域调用。
如果主数据库位于北京，那么南方的用户每次写请求就只能通过跨地域访问来完成吗？实际上并非如此。数据库的主库不仅可以存在于一个地域，而是可以在多个地域上部署主数据库。将每个用户归属于最近的地域，该用户的请求都会被路由到所在地域的数据库。这样的部署不仅提升了系统性能，还提高了系统的容灾等级，即使单个机房发生故障也不会影响全网的用户。
这个思想类似于CDN（内容分发网络），它能够将用户请求路由到最近的节点。事实上，由于用户的存储数据已经在该地域的数据库中，用户的请求极少需要切换到其他地域。
为了实现这一点，我们需要一个用户路由服务来提供用户所在地域的查询，并且能够提供高并发的访问。
除了数据库之外，其他的存储中间件（如MQ、Redis等）以及Rpc框架都需要具备单元化架构能力。
当我们无法避免跨地域调用时，我们可以选择整体上跨地域调用次数最少的方案来进行优化。
微服务拆分过细会导致更多的RPC调用，一次简单的请求可能就涉及四五个服务，当访问量非常高时，多出来的三五次Rpc调用会导致接口耗时增加很多。
每个服务都需要处理网络IO，序列化反序列化，服务的GC 也会导致耗时增加，这样算下来一个大服务的性能往往优于5个微服务。
当然服务过于臃肿会降低开发维护效率，也不利于技术升级。微服务过多也有问题，例如增加整体链路耗时、基础架构升级工作量变大、单个需求代码变更的服务更多等弊端。需要你权衡开发效率、线上性能、领域划分等多方面因素。
总之应该极力避免微服务过多的情况。
怎么评估微服务过多呢？我的个人经验是：团队内平均一个人两个服务以上，就是微服务过多了。例如三个人的团队6个服务，5个人的团队10个服务。
当整个系统的调用链路中涉及到过多的Rpc调用时，可以通过去除中间服务的方式减少Rpc调用。例如从A服务到E服务的调用链路包含了4次Rpc调用（A->B->C->D->E），而我们可以评估中间的B、C、D三个服务的功能是否冗余，是否只是作为转发服务而没有太多的业务逻辑，如果是的话，我们可以考虑让A服务直接调用E服务，从而避免中间的Rpc调用，减少系统的负担。
总的来说，无论是调用链路过长或是微服务过多，都可能导致过多的Rpc请求，因此可以尝试去除中间的服务来优化系统性能。
如果中间服务有业务逻辑，不能直接移除，可以考虑使用基于Java Client工具方法的服务提供方式，而非Rpc方式。
举例来说，如果存在一个调用链路为A->B->C，其中B服务有自己的业务逻辑。此时B服务可以考虑提供一个Java Client jar包给A服务使用。B服务所依赖的数据可以由A服务提供，这样就减少1次 A 服务到B 服务的Rpc调用。
这样做有一个好处，当A、B都共同依赖相同的数据，A服务查询一遍就可以提供给自己和B服务Client使用。如果基于Rpc方式，A、B都需要查询一遍。微服务过多也不好啊！
通过改变服务提供方式，尽量减少Rpc调用次数和开销，从而优化整个系统的性能。
例如社交关注关系服务。在这个服务中，需要查询用户之间的关注关系。为了提高服务性能，关注服务内部使用缓存来存储关注关系。为了降低高并发场景下的调用延迟和机器负载，关注服务提供了一个Java Client Jar查询关注关系，放弃了上游调用rpc接口的方式。这样做的好处是可以减少一次Rpc调用，避免了下游服务因GC 停顿而导致的耗时。
无论是查询还是写入，都可以使用批量调用来代替单条调用。比如，在查询用户订单的详情时，应该批量查询多个订单，而不是通过循环逐个查询订单详情。批量调用虽然会比单条调用稍微耗时多一些，但是循环调用的耗时却是单条调用的N倍，所以批量查询耗时要低很多。
在接口设计和代码流程中，我们应该尽量避免使用for循环进行单条查询或单条写入操作。正如此文所提到的，批量插入数据库的性能可能是单条插入的3-5倍。 # 10亿数据如何插入Mysql，10连问，你想到了几个？
在调用多个接口时，可以选择串行调用或并行调用的两种方式。串行调用是指依次调用每个接口，一个接口完成后才能调用下一个接口，而并行调用是指同时调用多个接口。可以看出并行调用的耗时更低，因为串行调用的耗时是多个接口耗时的总和，而并行调用的耗时是耗时最高的接口耗时。
为了灵活实现多个接口的调用顺序和依赖关系，可以使用Java中的 CompletableFuture类。 CompletableFuture可以将多个接口的调用任务编排成一个有序的执行流程，可以实现最大程度的并发查询或并发修改。
例如，可以并行调用两个接口，然后等待两个接口全部成功后，再对查询结果进行汇总处理。这样可以提高查询或修改的效率。
CompletableFuture<Void> first = CompletableFuture.runAsync(()->{
System.out.println("do something first");
Thread.sleep(200);
});
CompletableFuture<Void> second = CompletableFuture.runAsync(() -> {
System.out.println("do something second");
Thread.sleep(300);
});
CompletableFuture<Void> allOfFuture = CompletableFuture.allOf(first, second).whenComplete((m,k)->{
System.out.println("all finish do something");
});
allOfFuture.get();//汇总处理结果
CompletaleFuture 还支持自定义线程池，支持同步调用、异步调用，支持anyOf任一成功则返回等多种编排策略。由于不是本文重点，不再一一说明
在某些活动匹配的业务场景里，相当多的请求实际上是不满足条件的，如果能尽早的过滤掉这些请求，就能避免很多无效查询。例如用户匹配某个活动时，会有非常多的过滤条件，如果该活动的特点是仅少量用户可参加，那么可首先使用人群先过滤掉大部分不符合条件的用户。
前面提到如果Http接口功能过于庞大，核心数据和非核心数据杂糅在一起，耗时高和耗时低的数据耦合在一起。为了优化请求的耗时，可以通过拆分接口，将核心数据和非核心数据分别处理，从而提高接口的性能。
而在Rpc接口方面，也可以使用类似的思路进行优化。当上游需要调用多个Rpc接口时，可以并行地调用这些接口。优先返回核心数据，如果处理非核心数据或者耗时高的数据超时，则直接降级，只返回核心数据。这种方式可以提高接口的响应速度和效率，减少不必要的等待时间。
无论是查询接口还是写入接口都需要访问数据源，访问存储系统。读高写低，读低写高，读写双高等不同场景需要选择不同的存储系统。
当系统查询压力增加时，可以把MySQL数据异构到Redis缓存中。
Redis包含了一些常见的数据结构，包括字符串（String）、列表（List）、有序集合（SortSet）、哈希（Hash）和基数估计（HyperLogLog）、GEOHash等。
在不同的应用场景下，我们可以根据需求选择合适的数据结构来存储数据。举例来说，如果我们需要存储用户的关注列表，可以选择使用哈希结构（Hash）。对于需要对商品或文章的浏览量进行去重的情况，可以考虑使用基数估计结构（HyperLogLog）。而对于用户的浏览记录，可以选择列表（List）等结构来存储。如果想实现附近的人功能，可以使用Redis GEOHash结构。
Redis提供了丰富的API来操作这些数据结构，我们可以根据实际需要选择适合的数据结构和相关API来简化代码实现，提高开发效率。
关于缓存结构选择可以参考这篇文章。 # 10W+TPS高并发场景【我的浏览记录】系统设计
缓存策略指的是何时更新缓存和何时将缓存标记为过期或清理缓存。主要有两种策略。
策略1：是当数据更新时，更新缓存，并且在缓存Miss（即缓存中没有所需数据）时，从数据源加载数据到缓存中。
策略2：是将缓存设置为常驻缓存，即缓存永远不过期。当数据更新时，会即时更新缓存中的数据。这种策略通常会占用大量内存空间，因此一般只适用于数据量较小的情况下使用。另外，定时任务会定期将数据库中的数据更新到缓存中，以兜底缓存数据的一致性。
总的来说，选择何种缓存策略取决于具体的应用需求和数据规模。如果数据量较大，一般会选择策略1；而如果数据量较小且要求缓存数据的实时性，可以考虑策略2。
关于缓存使用，可以参考我的踩坑记录： #点击这里了解 第一次使用缓存翻车了
Redis相比传统数据库更快且具有更强的抗并发能力。然而，与本地缓存相比，Redis缓存仍然较慢。前面提到的Redis访问速度大约在3-5毫秒之间，而使用本地缓存几乎可以忽略不计。
如果频繁访问Redis获取大量数据，将会导致大量的序列化和反序列化操作，这会显著增加young gc频率，也会增加CPU负载。
本地缓存的性能更强，当使用Redis仍然存在性能瓶颈时，可以考虑使用本地缓存。可以设置多级缓存机制，首先访问本地缓存，如果本地缓存中没有数据，则访问Redis分布式缓存，如果仍然不存在，则访问数据库。通过使用多级缓存策略来实现更高效的性能。
本地缓存可以使用Guava Cahce 。参考 本地缓存框架Guava Cache
也可以使用性能更强的Caffeine。 点击这里了解
Redis由于单线程架构，在热点缓存应对上稍显不足。使用本地缓存可以极大的解决缓存热点问题。例如以下代码创建了Caffeine缓存，最大长度1W，写入后30分钟过期，同时指定自动回源取值策略。
public LoadingCache<String, User> createUserCache() {
return Caffeine.newBuilder()
.initialCapacity(1000)
.maximumSize(10000L)
.expireAfterWrite(30L, TimeUnit.MINUTES)
//.concurrencyLevel(8)
.recordStats()
.build(key -> userDao.getUser(key));
}
当存在热点key和大key时，Redis集群的负载会变得不均衡，从而降低整个集群的性能。这是因为Redis是单线程执行的系统，当处理热点key和大key时，会对整个集群的性能产生影响。
相比之下，Memcached缓存是多线程执行的，它可以更好地处理热点key和大key的问题，因此可以更好地应对上述性能问题。如果遇到这些问题，可以考虑使用Memcached进行替代。
另外，还可以通过使用本地缓存并结合Redis来处理热点key和热点大key的情况。这样可以减轻Redis集群的负担，并提升系统的性能。
在后台管理页面中，通常需要对列表页进行多条件检索。MySQL 无法满足多条件检索的需求，原因有两点。第一点是，拼接条件检索的查询SQL非常复杂且需要进行定制化，难以进行维护和管理。第二点是，条件检索的查询场景非常灵活，很难设计合适的索引来提高查询性能，并且难以保证查询能够命中索引。
相比之下，ElasticSearch是一种天然适合于条件检索场景的解决方案。无论数据量的大小，对于列表页查询和检索等场景，推荐首选ElasticSearch。
可以将多个表的数据异构到ElasticSearch中建立宽表，并在数据更新时同步更新索引。在进行检索时，可以直接从ElasticSearch中获取数据，无需再查询数据库，提高了检索性能。
MySQL并不适合大数据量存储，若不对数据进行归档，数据库会一直膨胀，从而降低查询和写入的性能。针对大数据量的读写需求，可以考虑以下方法来存储订单数据。
首先，将最近1年的订单数据存储在MySQL数据库中。这样可以保证较高的数据库查询性能，因为MySQL对于相对较小的数据集来说是非常高效的。
其次，将1年以上的历史订单数据进行归档，并将这些数据异构（转储）到HBase中。HBase是一种分布式的NoSQL数据库，可以存储海量数据，并提供快速的读取能力。
在订单查询接口上，可以区分近期数据和历史数据，使得上游系统能够根据自身的需求调用适当的订单接口来查询订单详情。
在将历史订单数据存储到HBase时，可以设置合理的RowKey。RowKey是HBase中数据的唯一标识，在查询过程中可以通过RowKey来快速找到目标数据。通过合理地设置RowKey，可以进一步提高HBase的查询性能。
通过将订单数据分别存储在MySQL和HBase中，并根据需求进行区分查询，可以满足大数据量场景的读写需求。MySQL用于存储近期数据，以保证查询性能；而HBase用于存储归档的历史数据，并通过合理设置的RowKey来提高查询性能。
将写请求从同步转为异步可以显著提升接口的性能。
以发送短信接口为例，该接口需要调用运营商接口并在公网上进行调用，因此耗时较高。如果业务方选择完全同步发送短信，就需要处理失败、超时、重试等与稳定性有关的问题，且耗时也会非常高。因此，我们需要采用同步加异步的处理方式。
公司的短信平台应该采用Rpc接口发送短信。在收到请求后，首先进行校验，包括校验业务方短信模板的合法性以及短信参数是否合法。待校验完成后，我们可以将短信发送任务存入数据库，并通过消息队列进行异步处理。而对业务方提供的Rpc接口的语义也发生了变化：我们成功接收了发送短信的请求，稍后将以异步的方式进行发送。至于发送短信失败、重试、超时等与稳定性和可靠性有关的问题，将由短信平台保证。而业务方只需确保成功调用短信平台的Rpc接口即可
在高并发的查询场景下，打印日志可能导致接口性能下降的问题。我曾经不认为这会是一个问题，直到我的同事犯了这个错误。有同事在排查问题时顺手打印了日志并且带上线。第二天高峰期，发现接口的 tp99 耗时大幅增加，同时 CPU 负载和垃圾回收频率也明显增加，磁盘负载也增加很多。日志删除后，系统回归正常。
特别是在日志中包含了大数组或大对象时，更要谨慎，避免打印这些日志。
不打日志，无法有效排查问题。怎么办呢？
为了有效地排查问题，建议引入白名单机制。具体做法是，在打印日志之前，先判断用户是否在白名单中，如果不在，则不打印日志；如果在，则打印日志。通过将公司内的产品、开发和测试人员等相关同事加入到白名单中，有利于及时发现线上问题。当用户提出投诉时，也可以将相关用户添加到白名单，并要求他们重新操作以复现问题。
这种方法既满足了问题排查的需求，又避免了给线上环境增加压力。（在测试环境中，可以完全开放日志打印功能）
在进行查询操作时，应尽量将单次调用改为批量查询或分页查询。不论是批量查询还是分页查询，都应注意避免一次性查询过多数据，比如每次加载10000条记录。因为过大的网络报文会降低查询性能，并且Java虚拟机（JVM）倾向于在老年代申请大对象。当访问量过高时，频繁申请大对象会增加Full GC（垃圾回收）的频率，从而降低服务的性能。
建议最好支持动态配置批量查询的数量。当接口的性能较差时，可以通过动态配置批量查询的数量来优化接口的性能，根据实际情况灵活地调整每次查询的数量。
深度分页指的是对一个大数据集进行分页查询时，每次只查询一页的数据，但是要获取到指定页数的数据，就需要依次查询前面的页数，这样查询的范围就会越来越大，导致查询效率变低。
在进行深度分页时，MySQL和ElasticSearch会先加载大量的数据，然后根据分页要求返回少量的数据。这种处理方式导致深度分页的效率非常低，同时也给MySQL和ElasticSearch带来较高的内存压力和CPU负载。因此，我们应该尽可能地避免使用深度分页的方式。
为了避免深度分页，可以采用每次查询时指定最小id或最大id的方法。具体来说，当进行分页查询时，可以记录上一次查询结果中的最小id或最大id（根据排序方式来决定）。在进行下一次查询时，指定查询结果中的最小id或最大id作为起始条件，从而缩短查询范围。这样每次只获取前N条数据，可以提高查询效率。
关于分页可以参考 我的文章 # 四选一，如何选择适合你的分页方案？
为了查询数据库和下游接口所需的字段，我们可以采取一些方法。例如，商品数据的字段非常多，如果每次调用都返回全部字段，将导致数据量过大。因此，上游可以指定使用的字段，从而有效降低接口的数据量，提升接口的性能。
这种方式不仅可以减少网络IO的耗时，而且还可以减少Rpc序列化和反序列化的耗时，因为接口的数据量较少。
对于访问量极大的接口来说，处理这些多余的字段将会增加CPU的负载，并增加Young GC的次数。因此不要把所有的字段都返回给上游！应该按需定制。
对于访问量较低的接口来说，通常首次接口的响应时间较长。原因是JVM需要加载类、Spring Aop首次动态代理，以及新建连接等。这使得首次接口请求时间明显比后续请求耗时长。
然而在流量较低的接口中，这种影响会更大。用户可能尝试多次请求，但依然经常出现超时，严重影响了用户体验。每次服务发布完成后，接口超时失败率都会大量上升！
那么如何解决接口预热的问题呢？可以考虑在服务启动时，自行调用一次接口。如果是写接口，还可以尝试更新特定的一条数据。
另外，可以在服务启动时手动加载对应的类，以减少首次调用的耗时。不同的接口预热方式有所不同，建议使用阿里开源的诊断工具arthas，通过监控首次请求时方法调用堆栈的耗时来进行接口的预热。
arthas使用文档 https://arthas.aliyun.com/doc/trace.html
使用arthas trace命令可以查看 某个方法执行的耗时情况。
trace com.xxxx.ClassA function1
增加MySQL数据库的从节点来实现负载均衡，减轻主节点的查询压力，让主节点专注于处理写请求，保证读写操作的高性能。
除此之外，当需要跨地域进行数据库的查询时，由于较高网络延迟等问题，接口性能可能变得很差。在数据实时性不太敏感的情况下，可以通过在多个地域增加从节点来提高这些地域的接口性能。举个例子，如果数据库主节点在北京，可以在广州、上海等地区设置从节点，在数据实时性要求较低的查询场景，可有效提高南方地区的接口性能。
查询和更新SQL必须命中索引。查询SQL如果没命中索引，在访问量较大时，会出现大量慢查询，严重时会导致整个MySQL集群雪崩，影响到其他表、其他数据库。所以一定要严格审查SQL是否命中索引。可以使用explain命令查看索引使用情况。
在SQL更新场景，MySQL会在索引上加锁，如果没有命中索引会对全表加锁，全表的更新操作都会被阻塞住。所以更新SQL更要确保命中索引。
因此，为了避免这种情况的发生，需要严格审查SQL是否命中索引。可以使用"explain"命令来查看SQL的执行计划，从而判断是否有使用索引。这样可以及早发现潜在的问题，并及时采取措施进行优化和调整。
除此之外，最好索引字段能够完全覆盖查询需要的字段。MySQL索引分主键索引和普通索引。普通索引命中后，往往需要再查询主键索引获取记录的全部字段。如果索引字段完全包含查询的字段，即索引覆盖查询，就无需再回查主键索引，可以有效提高查询性能。
更详细请参考本篇文章 # 深入理解mysql 索引特性
date(created_at) = 'XXXX'等.字符处理等。mysql将无法使用相应索引当索引数量过多时，索引的数据量就会增加，这可能导致数据库无法将所有的索引数据加载到内存中，从而使得查询索引时需要从磁盘读取数据，进而大大降低索引查询的性能。举例来说，我们组有张表700万条数据，共4个索引，索引数据量就达到2.8GB。在一个数据库中通常有多张表，在进行分库分表时，可能会存在100张表。100张表就会产生280GB的索引数据，这么庞大的数据量无法全部放入内存，查询索引时会大大降低缓存命中率，进而降低查询和写入操作的性能。简而言之，避免创建过多的索引。
可以选择最通用的查询字段作为联合索引最左前缀，让索引覆盖更多的查询场景。
为了提高接口并发量，需要避免大事务。当需要更新多条数据时，避免一次性更新过多的数据。因为update，delete语句会对索引加锁，如果更新的记录数过多，会锁住太多的数据，由于执行时间较长，会严重限制数据库的并发量。
间隙锁是MySQL在执行更新时为了保证数据一致性而添加的锁定机制。虽然更新的记录数量很少，但MySQL可能会锁定比更新数量更大的范围。因此，需要注意查询语句中的where条件是否包含了较大的范围，这样可能会锁定不应该被锁定的记录。
如果有批量更新的情况，需要降低批量更新的数量，缩小更新的范围。
其次在事务内可能有多条SQL，例如扣减库存和新增库存扣减流水有两条SQL。因为两个SQl在同一个事务内，所以可以保证原子性。但是需要考虑两个SQL谁先执行，谁后执行？
建议先扣库存，再增加流水。
扣减库存的更新操作耗时较长且使用了行锁，而新增流水的速度较快但是串行执行，如果先新增流水再扣减库存，会导致流水表被锁定的时间更长，限制了流水表的插入速度，同时会阻塞其他扣减库存的事务。相反，如果先扣减库存再新增流水，流水表被锁定的时间较短，有利于提高库存扣减的并发度。
MySQL单库单表的性能瓶颈很容易达到。当数据量增加到一定程度时，查询和写入操作可能会变得缓慢。这是因为MySQL的B+树索引结构在单表行数超过2000万时会达到4层，同时索引的数据规模也会变得非常庞大。如果无法将所有索引数据都放入内存缓存中，那么查询索引时就需要进行磁盘查询。这会导致查询性能下降。参考 # 10亿数据如何插入Mysql，10连问，你想到了几个？
为了克服这个问题，系统设计在最初阶段就应该预测数据量，并设置适合的分库分表策略。通过将数据分散存储在多个库和表中，可以有效提高数据库的读写性能。此外，分库分表也可以突破单表的容量限制。
分库分表工具推荐使用 Sharding-JDBC
使用分库分表后，索引的使用受到限制。例如，在关注服务中，需要满足两个查询需求：1. 查询用户的关注列表；2. 查询用户的粉丝列表。关注关系表包含两个字段，即关注者的fromUserId和被关注者的toUserId。
对于查询1，我们可以指定 fromUserId = A，即可查询用户A的关注列表。
对于查询2，我们可以指定 toUserId = B，即可查询用户B的粉丝列表。
在单库单表的情况下，我们可以设计fromUserId和toUserId这两个字段作为索引。然而，当进行分库分表后，我们面临选择哪个字段作为分表键的困扰。无论我们选择使用fromUserId还是toUserId作为分表键，都会导致另一个查询场景变得难以实现。
解决这个问题的思路是：存储结构不仅要方便写入，还要方便查询。既然查询不方便，我们可以冗余一份数据，以便于查询。我们可以设计两张表，即关注列表表（Follows）和粉丝列表表（Fans）。其中，Follows表使用fromUserId作为分表键，用于查询用户的关注列表；Fans表使用toUserId作为分表键，用于查询用户的粉丝列表。
通过冗余更多的数据，我们可以提高查询性能，这是常见的优化方案。除了引入新的表外，还可以在表中冗余其他表的字段，以减少关联查询的次数。
关注关系设计 请参考 #解密亿级流量【社交关注关系】系统设计
MySQL并不适合存储大数据量，如果不对数据进行归档，数据库会持续膨胀，从而降低查询和写入的性能。为了满足大数据量的读写需求，需要定期对数据库进行归档。
在进行数据库设计时，需要事先考虑到对数据归档的需求，为了提高归档效率，可以使用ctime（创建时间）进行归档，例如归档一年前的数据。
可以通过以下SQL语句不断执行来归档过期数据：
delete from order where ctime < ${minCtime} order by ctime limit 100;
需要注意的是， 执行delete操作时，ctime字段应该有索引，否则将会锁住整个表！
另外，在将数据库数据归档之前，如果有必要，一定要将数据同步到Hive中，这样以后如果需要进行统计查询，可以使用Hive中的数据。如果归档的数据还需要在线查询，可以将过期数据同步到HBase中，这样数据库可以提供近期数据的查询，而 HBase可以提供历史数据的查询。可参考上述 MySQL转HBase的内容。
MySQL的性能取决于内存大小、CPU核数和SSD硬盘读写性能。为了适配更强的宿主机，可以进行以下MySQL优化配置
缓冲池是数据和索引缓存的地方。默认大小为128M。这个值越大越好决于CPU的架构，这能保证你在大多数的读取操作时使用的是内存而不是硬盘。典型的值是5-6GB(8GB内存)，20-25GB(32GB内存)，100-120GB(128GB内存)。
数据库最大连接数。可以适当调大数据库链接
控制MySQL刷新数据到磁盘的策略。
mysql crash时可能丢失1s的数据。 innodb_thread_concurrency默认是0，则表示没有并发线程数限制，所有请求都会直接请求线程执行。
当并发用户线程数量小于64，建议设置innodb_thread_concurrency=0； 在大多数情况下，最佳的值是小于并接近虚拟CPU的个数；
设置InnoDB存储引擎的读取线程数。默认值是4，表示使用4个线程来读取数据。可以根据服务器的CPU核心数来调整这个值。例如调整到16甚至32。
innodb_io_capacity InnoDB可用的总I/O容量。该参数应该设置为系统每秒可以执行的I/O操作数。该值取决于系统配置。当设置 innodb_io_capacity时，主线程会根据设置的值来估算后台任务可用的I/O带宽
innodb_io_capacity_max: 如果刷新操作过于落后，InnoDB可以超过 innodb_io_capacity的限制进行刷新，但是不能超过本参数的值
默认情况下，MySQL 分别配置了200 和2000的默认值。
当磁盘为SSD时，可以考虑设置 innodb_io_capacity= 2000，innodb_io_capacity_max=4000。
压缩文本数据可以有效地减少该数据所需的存储空间，从而提高数据库和缓存的空间利用率。然而，压缩和解压缩的过程会增加CPU的负载，因此需要仔细考虑是否有必要进行数据压缩。此外，还需要评估压缩后数据的效果，即压缩对数据的影响如何。
例如下面这一段文字我们使用 GZIP 进行压缩
假设上游服务在上海，而我们的服务在北京和上海都有部署，但是数据库和缓存的主节点都在北京，这时候就无法避免跨地域调用。那么我们该如何进行优化呢？考虑到我们的服务会更频繁地访问数据库和缓存，如果让我们上海节点的服务去访问北京的数据库和缓存，那么跨地域调用的次数就会非常多。因此，我们应该让上游服务去访问我们在北京的节点，这样只会有1次跨地域调用，而我们的服务在访问数据库和缓存时就无需进行跨地域调用。
该段文字使用UTF-8编码，共570位byte。使用GZIP 压缩后，变为328位Byte。压缩效果还是很明显的。
压缩代码如下
//压缩
public static byte[] compress(String str, String encoding) {
if (str == null || str.length() == 0) {
return null;
}
byte[] values = null;
ByteArrayOutputStream out = new ByteArrayOutputStream();
GZIPOutputStream gzip;
try {
gzip = new GZIPOutputStream(out);
gzip.write(str.getBytes(encoding));
gzip.close();
values = out.toByteArray();
out.close();
} catch (IOException e) {
log.error("gzip compress error.", e);
throw new RuntimeException("压缩失败", e);
}
return values;
}
// 解压缩
public static String uncompressToString(byte[] bytes, String encoding) {
if (bytes == null || bytes.length == 0) {
return null;
}
ByteArrayOutputStream out = new ByteArrayOutputStream();
ByteArrayInputStream in = new ByteArrayInputStream(bytes);
try {
GZIPInputStream ungzip = new GZIPInputStream(in);
byte[] buffer = new byte[256];
int n;
while ((n = ungzip.read(buffer)) >= 0) {
out.write(buffer, 0, n);
}
String value = out.toString(encoding);
out.close();
return value;
} catch (IOException e) {
log.error("gzip uncompress to string error.", e);
throw new RuntimeException("解压缩失败", e);
}
}
值得一提的是使用 GZIP压缩算法的cpu负载和耗时都是比较高的。使用压缩非但不能起到降低接口耗时的效果，可能导致接口耗时增加，要谨慎使用。除此之外，还有其他压缩算法在压缩时间和压缩率上有所权衡。可以选择适合的自己的压缩算法。
无论是Young GC还是Full GC，在进行垃圾回收时都会暂停所有的业务线程。因此，需要关注垃圾回收的频率，以确保对业务的影响尽可能小。
插播提问：为什么young gc也需要stop the world ？ 阿里面试官问我的，把我问懵逼了。
一般情况下，通过调整堆大小和新生代大小可以解决大部分垃圾回收问题。其中，新生代是用于存放新创建的对象的区域。对于Young GC的频率增加的情况，一般是系统的请求量大量增长导致。但如果young gc增长非常多，就需要考虑是否需要增加新生代的大小。
因为如果新生代过小，很容易被打满。这导致本可以被Young GC掉的对象被晋升（Promotion）到老年代，过早地进入老年代。这样一来，不仅Young GC频繁触发，Full GC也会频繁触发。
gc场景非常多，建议参考美团的技术文章详细概括了9种CMS GC问题。# Java中9种常见的CMS GC问题分析与解决
如果cpu负载较高 可以考虑提高每个实例cpu数量，提高实例个数。同时关注网络IO负载，如果机器流量较大，网卡带宽可能成为瓶颈。
高峰期和低峰期如果机器负载相差较大，可以考虑设置弹性伸缩策略，高峰期之前自动扩容，低峰期自动缩容，最大程度提高资源利用率。
我曾经负责过B端商品数据创建，当时产品提到创建完虚拟商品后要立即跳转到商品列表页。当时我们使用ElasticSearch 实现后台管理页面的商品查询，但是ElasticSearch 在新增记录时，默认是每 1 秒钟构建1次索引，所以如果创建完商品立即跳转到商品列表页是无法查到刚创建的商品的。于是和产品沟通商品创建完成跳转到商品详情页是否可以，沟通后产品也认可这个交互。
于是我无需调整ElasticSearch 构建索引的时机。（后来了解到 ElasticSearch 提供了API。新增记录后，可立即构建索引，就不存在1秒的延迟了。但是这样操作索引文件会非常多，影响索引查询性能，不过后台管理对性能要求不高，也能接收。）
通过和产品沟通交互和业务逻辑，有时候能解决很棘手的技术问题。 有困难，不要闷头自己扛哦~
在社交类产品中用户关注功能。如果不限制用户可以关注的人数，可能会出现恶意用户大量关注其他用户的情况，导致系统设计变得复杂。
为了判断用户A是否关注用户B，可以查看A的关注列表中是否包含B，而不是检查B的粉丝列表中是否包含A。这是因为粉丝列表的数量可能非常庞大，可能达到上千万。而正常用户的关注列表通常不会很多，一般只有几百到几千人。
为了提高关注关系的查询性能，可将关注列表数据导入到Redis Hash结构中。系统通过限制用户的最大关注上限，避免出现Redis大key的情况，也避免大key过期时的性能问题，保证集群的整体性能的稳定。避免恶意用户攻击系统。
可以看这篇文章 详细了解关注系统设计。 # 解密亿级流量【社交关注关系】系统设计