九大服务架构性能优化方式

泉源：九大服务架构性能优化方式

目录
性能优化九大方式：
缓存
利用什么样的缓存
缓存常见标题
缓存淘汰
缓存数据同等性
并行化处理
批量化处理
数据压缩合并
无锁化
顺序写
分片化
避免请求
池化
异步处理
总结

---

最近做了一些服务性能优化，文章池服务均匀耗时跟p99耗时都下降80%左右，事件底层页服务均匀耗时下降50%多左右，主要优化项目中一些不合理计划，例如服务间利用json传输数据，监控上报处理逻辑在主流程中，重复数据每次都请求下游服务，多个耗时操作串行请求等，这些标题都对服务有着严重的性能影响。
在服务架构计划时通常可以利用一些中间件去提升服务性能，例如利用mysql，redis，kafka等，因为这些中间件有着很好的读写性能。除了利用中间件提升服务性能外，也可以通过探索它们通过什么样的底层计划实现的高性能，将这些计划应用到我们的服务架构中。
常用的性能优化方法可以分为以下几种：
性能优化九大方式：

缓存

性能优化，缓存为王，以是开始先介绍一下缓存。缓存在我们的架构计划中无处不在的，常规请求是浏览器发起请求，请求服务端服务，服务端服务再查询数据库中的数据，每次读取数据都会至少需要两次网络I/O，性能会差一些，我们可以在整个流程中增加缓存来提升性能。首先是浏览器测，可以通过Expires、Cache-Control、Last-Modified、Etag等相关字段来控制浏览器是否利用本地缓存。
其次我们可以在服务端服务利用本地缓存大概一些中间件来缓存数据，例如redis。redis之以是这么快，主要因为数据存储在内存中，不需要读取磁盘，因为内存读取速率通常是磁盘的数百倍甚至更多；
然后在数据库测，通常利用的是mysql，mysql的数据存储到磁盘上，但是mysql为了提升读写性能，会利用bufferpool缓存数据页。mysql读取时会按照页的粒度将数据页读取到bufferpool中，bufferpool中的数据页利用LRU算法淘汰长期没有效到的页面，缓存最近访问的数据页。

别的小到cpu的l1、l2、l3级cache，大到浏览器缓存都是为了进步性能，缓存也是进行服务性能优化的重要手段，利用缓存时需要思量以下几点。
利用什么样的缓存

利用缓存时可以利用redis大概呆板内存来缓存数据，利用redis的好处可以保证不同呆板读取数据的同等性，但是读取redis会增加一次I/O，利用内存缓存数据时大概会出现读取数据不同等，但是读取性能好。例如文章的阅读数数据，如果利用呆板内存作为缓存，容易出现不同呆板上缓存数据的不同等，用户不同刷次会请求到不同服务端呆板，读取的阅读数不同等，大概会出现阅读数变小的环境，用户体验欠好。对于阅读数这种经常变更的数据比较适合利用redis来同一缓存。
也可以将两者结合提升服务的性能,例如在内容池服务，利用redis跟呆板内存缓存热门文章详情，优先读取呆板内存中的数据，数据不存在的时候会读取redis中的缓存数据，当redis中的数据也不存在的时候，会读取下游长期化存储中的全量数据。其中内存级缓存逾期时间为15s，在数据变更的时候不保证数据同等性，通过数据天然逾期来保证终极同等性。redis中缓存数据需要保证与长期化存储中数据同等性，怎样保证同等性在后续讲解。可以根据自己的业务场景可以选择合适的缓存方案。
利用缓存时可以利用redis大概呆板内存来缓存数据，利用redis的好处可以保证不同呆板读取数据的同等性，但是读取redis会增加一次I/O，利用内存缓存数据时大概会出现读取数据不同等，但是读取性能好。例如文章的阅读数数据，如果利用呆板内存作为缓存，容易出现不同呆板上缓存数据的不同等，用户不同刷次会请求到不同服务端呆板，读取的阅读数不同等，大概会出现阅读数变小的环境，用户体验欠好。对于阅读数这种经常变更的数据比较适合利用redis来同一缓存。
也可以将两者结合提升服务的性能,例如在内容池服务，利用redis跟呆板内存缓存热门文章详情，优先读取呆板内存中的数据，数据不存在的时候会读取redis中的缓存数据，当redis中的数据也不存在的时候，会读取下游长期化存储中的全量数据。其中内存级缓存逾期时间为15s，在数据变更的时候不保证数据同等性，通过数据天然逾期来保证终极同等性。redis中缓存数据需要保证与长期化存储中数据同等性，怎样保证同等性在后续讲解。可以根据自己的业务场景可以选择合适的缓存方案。

缓存常见标题

1、缓存雪崩：缓存雪崩是指缓存中的大量数据同时失效大概逾期，导致大量的请求直接读取到下游数据库，导致数据库瞬时压力过大，通常的办理方案是将缓存数据设置的逾期时间随机化。在事件服务中就是利用固定逾期时间+随机值的方式进行文章的淘汰，避免缓存雪崩。
2、 缓存穿透：缓存穿透是指读取下游不存在的数据，导致缓存命中不了，每次都请求下游数据库。这种环境通常会出现在线上非常流量攻击大概下游数据被删除的状况，针对缓存穿透可以利用布隆过滤器对不存在的数据进行过滤，大概在读取下游数据不存在的环境，可以在缓存中设置空值，防止不绝的穿透。事件服务大概会出现查询文章被删除的环境，就是利用设置空值的方法防止被删除数据的请求不绝穿透到下游。
3、 缓存击穿: 缓存击穿是指某个热门数据在缓存中被删除大概逾期，导致大量的热门请求同时请求数据库。办理方案可以对于热门数据设置较长的逾期时间大概利用分布式锁避免多个相同请求同时访问下游服务。在新闻业务中，对于热门新闻经常会出现这种环境，事件服务利用golang的singlefilght保证同一篇文章请求在同一时刻只有一个会请求到下游，防止缓存击穿。
4、热门key: 热门key是指缓存中被频繁访问的key，导致缓存该key的分片大概redis访问量过高。可以将可热门key分散存储到多个key上，例如将热门key+序列号的方式存储，不同key存储的值都是相同的，在访问时随机访问一个key，分散原来单key分片的压力；别的还可以将key缓存到呆板内存中，避免redis单节点压力过大，在新闻业务中，对于热门文章就是采用这种方式，将热门文章存储到呆板内存中，避免存储热门文章redis单分片请求量过大。

1. key val    =>  key1 val 、  key2 val、  key3 val 、 key4 val

复制代码

缓存淘汰

缓存的巨细是有限的，因为需要对缓存中数据进行淘汰，通常可以采用随机、LRU大概LFU算法等淘汰数据。LRU是一种最常用的置换算法，淘汰最近最久未利用的数据，底层可以利用map+双端队列的数据布局实现。

最原生的LRU算法是存在一些标题标，不知道大家在利用过有没有遇到过标题。首先需要留意的是在数据布局中有互斥锁，因为golang对于map的读写会产生panic，导致服务非常。利用互斥锁之后会导致整个缓存性能变差，可以采用分片的思想，将整个LRUCache分为多个，每次读取时读取其中一个cache片，降低锁的粒度来提升性能，常见的本地缓存包通常就利用这种方式实现的。

1. type LRUCache struct {
2.     sync.Mutex
3.     size int     
4.     capacity int
5.     cache map[int]*DLinkNode
6.     head, tail *DLinkNode
7. }
8. type DLinkNode struct {
9.     key,value int
10.     pre, next *DLinkNode
11. }

复制代码

mysql也会利用LRU算法对buffer pool中的数据页进行淘汰。由于mysql存在预读，在读取磁盘时并不是按需读取，而是按照整个数据页的粒度进行读取，一个数据页会存储多条数据，除了读取当前数据页，大概也会将接下来大概用到的相邻数据页提前缓存到bufferpool中，如果下次读取的数据在缓存中，直接读取内存即可,不需要读取磁盘，但是如果预读的数据页一直没有被访问，那就会存在预读失效的环境，淘汰原来利用到的数据页。mysql将buffer pool中的链表分为两部分，一段是新生代，一段是老生代，新老生代的默认比是7:3，数据页被预读的时候会先加到老生代中，当数据页被访问时才会加载到新生代中，这样就可以防止预读的数据页没有被利用反而淘汰热门数据页。别的mysql通常会存在扫描表的请求，会顺序请求大量的数据加载到缓存中，然后将本来缓存中所有热门数据页淘汰，这个标题通常被称为缓冲池污染，mysql中的数据页需要在老生代停顿时间超过配置时间才会老生代移动到新生代时来办理缓存池污染。

redis中也会利用LRU进行淘汰逾期的数据，如果redis将缓存数据都通过一个大的链表进行管理，在每次读写时将最新访问的数据移动到链表队头，那样会严重影响redis的读写性能,别的会增加额外的存储空间，降低整体存储数目。redis是对缓存中的对象增加一个最后访问时间的字段，在对对象进行淘汰的时候，会采用随机采样的方案，随机取5个值，淘汰最近访问时间最久的一个，这样就可以避免每次都移动节点。但是LRU也会存在缓存污染的环境，一次读取大量数据会淘汰热门数据，因此redis可以选择利用LFU进行淘汰数据，是将原来的访问时间字段变更为最近访问时间+访问次数的一个字段，这里需要留意的是访问次数并不是单纯的次数累加，而是根据最近访问时间跟当前时间的差值进行时间衰减的，简单说也就是访问越久以及访问次数越少计算得到的值也越小，越容易被淘汰。

1. typedef struct redisObject {
2.  unsigned type:4;
3.  unsigned encoding:4;
4.  unsigned lru:LRU_BITS; /* LRU time (relative to global lru_clock) or
5.  * LFU data (least significant 8 bits frequency
6.  * and most significant 16 bits access time). */
7.  int refcount;
8.  void *ptr;
9. } obj ;

复制代码

可以看出不同中间件对于传统的LRU淘汰策略都进行了一定优化来保证服务性能，我们也可以参考不同的优化策略在自己的服务中进行缓存key的淘汰。
缓存数据同等性

当数据库中的数据变更时，怎样保证缓存跟数据库中的数据同等，通常有以下几种方案：更新缓存再更新DB，更新DB再更新缓存，先更新DB再删除缓存，删除缓存再更新DB。这几种方案都有大概会出现缓存跟数据库中的数据不同等的环境，最常用的照旧更新DB再删除缓存，因为这种方案导致数据不同等的概率最小，但是也依然会存在数据不同等的标题。例如在T1时缓存中无数据，数据库中数据为100，线程B查询缓存没有查询到数据，读取到数据库的数据100然后去更新缓存，但是此时线程A将数据库中的数据更新为99，然后在T4时刻删除缓存中的数据，但是此时缓存中还没有数据，在T5的时候线程B才更新缓存数据为100，这时候就会导致缓存跟数据库中的数据不同等。

为保证缓存与数据库数据的同等性。常用的办理方案有两种，一种是延时双删，先删除缓存，后续更新数据库，休眠一会再删除缓存。文章池服务中就是利用这种方案保证数据同等性，怎样实现延迟删除，是通过go语言中channel实现简单延时队列，没有引入第三方的消息队列，主要为了防止服务的复杂化；另外一种可以订阅DB的变更binlog，数据更新时只更新DB，通过消耗DB的binlog日记，解析变更操作进行缓存变更，更新失败时不进行消息的提交，通过消息队列的重试机制实现终极同等性。

并行化处理

redis在版本6.0之前都是号称单线程模型，主要是利用epllo管理用户海量毗连，利用一个线程通过事件循环来处理用户的请求，优点是避免了线程切换和锁的竞争，以及实现简单，但是缺点也比较显着，不能有效的利用cpu的多核资源。随着数据量和并发量的越来越大，I/O成了redis的性能瓶颈点，因此在6.0版本引入了多线程模型。redis的多线程将处理过程最耗时的sockect的读取跟解析写入由多个I/O 并发完成，对于命令的实验过程仍旧由单线程完成。

mysql的主从同步过程从数据库通过I/Othread读取住主库的binlog，将日记写入到relay log中，然后由sqlthread实验relaylog进行数据的同步。其中sqlthread就是由多个线程并发实验加速数据的同步，防止主从同步延迟。sqlthread多线程化也经历了多个版本迭代，按表维度分发到同一个线程进行数据同步，再到按行维度分发到同一个线程。

小到线程的并发处理，大到redis的集群，以及kafka的分topic分区都是通过多个client并行处理进步服务的读写性能。在我们的服务计划中可以通过创建多个容器对外服务进步服务的吞吐量，服务内部可以将多个串行的I/O操作改为并行处理，缩短接口的响应时长，提升用户体验。对于I/O存在相互依赖的环境，可以进行多阶段分批并行化处理，另外一种常见的方案就是利用DAG加速实验，但是需要留意的是DAG会存在开发维护成本较高的环境，需要根据自己的业务场景选择合适的方案。并行化也不是只有好处没有弊端的，并行化有大概会导致读扩散严重，以及线程切换频繁存在一定的性能影响。
批量化处理

kafka的消息发送并不是直接写入到broker中的，发送过程是将发送到同一个topic同一个分区的消息通过main函数的partitioner组件发送到同一个队列中，由sender线程不绝拉取队列中消息批量发送到broker中。利用批量发送消息处理，节省大量的网络开销，进步发送服从。

redis的长期化方式有RDB跟AOF两种，其中AOF在实验命令写入内存后，会写入到AOF缓冲区，可以选择合适的时机将AOF缓冲区中的数据写入到磁盘中，革新到磁盘的时间通过参数appendfsync控制，有三个值always、everysec、no。其中always会在每次命令实验完都会革新到磁盘来保证数据的可靠性；everysec是每秒批量写入到磁盘，no是不进行同步操作，由操作系统决定革新到写回磁盘，当redis非常退出时存在丢数据的风险。AOF命令革新到磁盘的时机会影响redis服务写入性能，通常配置为everysec批量写入到磁盘，来平衡写入性能和数据可靠性。

我们读取下游服务大概数据库的时候，可以一次多查询几条数据，节省网络I/O;读取redis的还可以利用pipeline大概lua脚本处理多条命令，提升读写性能；前端请求js文件大概小图片时，可以将多个js文件大概图片合并到一起返回，减少前端的毗连数，提升传输性能。同样需要留意的是批量处理多条数据，有大概会降低吞吐量，以及自己下游就不支持过多的批量数据，此时可以将多条数据分批并发请求。对于事件底层页服务中不同组件下配置的不同文章id，会同一批量请求下游内容服务获取文章详情，对于批量的条数也会做限定，防止单批数据量过大。
数据压缩合并

redis的AOF重写是利用bgrewriteaof命令进行AOF文件重写，因为AOF是追加写日记，对于同一个key大概存在多条修改修改命令，导致AOF文件过大，redis重启后加载AOF文件会变得缓慢，导致启动时间过长。可以利用重写命令将对于同一个key的修改只生存一条记录，减小AOF文件体积。

大数据领域的Hbase、cassandra等nosql数据库写入性能都很高，它们的底层存储数据布局就是LSM树(log structured merge tree),这种数据布局的焦点思想是追加写，积攒一定的数据后合并成更大的segement，对于数据的删除也只是增加一条删除记录。同样对一个key的修改记录也有多条。这种存储布局的优点是写入性能高，但是缺点也比较显着，数据存在冗余和文件体积大。主要通过线程进行段合并将多个小文件合并成更大的文件来减少存储文件体积，提升查询服从。

对于kafka进行传输数据时，在生产者端和消耗者端可以开启数据压缩。生产者端压缩数据后，消耗者端收到消息会自动解压，可以有效减小在磁盘的存储空间和网络传输时的带宽消耗，从而降低成本和提升传输服从。需要留意生产者端和消耗者端指定相同的压缩算法。
在降本增效的海潮中，降低redis成本的一种方式，就是对存储到redis中的数据进行压缩，降低存储成本,重构后的内容微服务通过长期化存储全量数据，采用snappy压缩，压缩后只是原来数据的40%-50%；还有一种方式是将服务之间的调用从http的json改为trpc的pb协议，因为pb协议编码后的数据更小，提升传输服从，在服务优化时，将原来请求tab的协议从json转成pb，降低几毫秒的时延，别的内容微服务存储的数据采用flutbuffer编码，相比较于protobuffer有着更高的压缩比跟更快的编解码速率；对于JS/CSS多个文件下发也可以进行肴杂和压缩通报；对于存储在es中的数据也可以手动调用api进行段合并，减小存储数据的体积，进步查询速率；在我们工作中还有一个比较常见的标题是接口返回的冗余数据特别多，一个接口服务下发的数据大而全，而不是对于当前场景做定制化下发，不满足接口最小化原则，白白浪费了很多带宽资源和降低传输服从。
无锁化

redis通过单线程避免了锁的竞争，避免了线程之间频繁切换才有这很好的读写性能。
go语言中提供了atomic包，主要用于不同线程之间的数据同步，不需要加锁，本质上就是封装了底层cpu提供的原子操作指令。别的go语言最开始的调理模型时GM模型，所有的内核级线程想要实验goroutine需要加锁从全局队列中获取，以是不同线程之间的竞争很激烈，调理服从很差。

后续引入了P(Processor)，每一个M(thread)要实验G(gorontine)的时候需要绑定一个P，其中P中会有一个待实验G的本地队列，只由当前M可以进行读写（少数环境会存在偷其他协程的G），读取P本地队列时不需要进行加锁，通过降低锁的竞争大幅度提升调理G的服从。

mysql利用mvcc实现多个事务进行读写并发时保证数据的同等性和隔离型，也是办理读写并发的一种无锁化计划方案之一。它主要通过对每一行数据的变更记录维护多个版本链来实现的，通过隐藏列rollptr和undolog来实现快照读。在事务对某一行数据进行操作时，会根据当前事务id以及事务隔离级别判断读取那个版本的数据，对于可重复读就是在事务开始的时候天生readview，在后续整个事务期间都利用这个readview。mysql中除了利用mvcc避免互斥锁外，bufferpool还可以设置多个，通过多个bufferpool降低锁的粒度，提升读写性能，也是一种优化方案。
日常工作 在读多写少的场景下可以利用atomic.value存储数据，减少锁的竞争，提升系统性能，例如配置服务中数据就是利用atomic.value存储的；syncmap为了提升读性能，优先利用atomic进行read操作，然后再进行加互斥锁操作进行dirty的操作，在读多写少的环境下也可以利用syncmap。
秒杀系统的本质就是在高并发下准确的增减商品库存，不出现超卖少卖的标题。因此所有的用户在抢到商品时需要利用互斥锁进行库存数目的变更。互斥锁的存在必然会成为系统瓶颈，但是秒杀系统又是一个高并发的场景，以是怎样进行互斥锁优化是进步秒杀系统性能的一个重要优化手段。

无锁化计划方案之一就是利用消息队列，对于秒杀系统的秒杀操作进行异步处理，将秒杀操作发布一个消息到消息队列中，这样所有效户的秒杀举动就形成了一个先辈先出的队列，只有前面先添加到消息队列中的用户才能抢购商品乐成。从队列中消耗消息进行库存变更的线程是个单线程，因此对于db的操作不会存在冲突，不需要加锁操作。

另外一种优化方式可以参考golang的GMP模型，将库存分成多份，分别加载到服务server的本地，这样多机之间在对库存变更的时候就避免了锁的竞争。如果本地server是单进程的，因此也可以形成一种无锁化架构；如果是多进程的，需要对本地库存加锁后在进行变更，但是将库存分散到server本地，降低了锁的粒度，进步整个服务性能。

顺序写

mysql的InnoDB存储引擎在创建主键时通常会建议利用自增主键，而不是利用uuid，最主要的原因是InnoDB底层采用B+树用来存储数据，每个叶子结点是一个数据页，存储多条数据记录，页面内的数据通过链表有序存储，数据页间通过双向链表存储。由于uuid是无序的，有大概会插入到已经空间不足的数据页中间，导致数据页分裂成两个新的数据页以便插入新数据，影响整体写入性能。
别的mysql中的写入过程并不是每次将修改的数据直接写入到磁盘中，而是修改内存中buffer pool内存储的数据页，将数据页的变更记录到undolog和binlog日记中，保证数据变更不丢失，每次记录log都是追加写到日记文件尾部，顺序写入到磁盘。对数据进行变更时通过顺序写log，避免随机写磁盘数据页，提升写入性能，这种将随机写转变为顺序写的思想在很多中间件中都有所体现。

kakfa中的每个分区是一个有序不可变的消息队列，新的消息会不绝的添加的partition的尾部，每个partition由多个segment组成，一个segment对应一个物理日记文件，kafka对segment日记文件的写入也是顺序写。顺序写入的好处是避免了磁盘的不绝寻道和旋转次数，极大的进步了写入性能。
顺序写主要会应用在存在大量磁盘I/O操作的场景，日常工作中创建mysql表时选择自增主键，大概在进行数据库数据同步时顺序读写数据，避免底层页存储引擎的数据页分裂，也会对写入性能有一定的提升。
分片化

redis对于命令的实验过程是单线程的，单机有着很好的读写性能，但是单机的呆板容量跟毗连数究竟有限，因此单机redis必然会存在读写上限跟存储上限。redis集群的出现就是为了办理单机redis的读写性能瓶颈标题，redis集群是将数据自动分片到多个节点上，每个节点负责数据的一部分，每个节点都可以对外提供服务，突破单机redis存储限定跟读写上限，进步整个服务的高并发本领。除了官方推出的集群模式，署理模式codis等也是将数据分片到不同节点，codis将多个完全独立的redis节点组成集群，通过codis转发请求到某一节点，来进步服务存储本领和读写性能。

同样的kafka中每个topic也支持多个partition，partition分布到多个broker上，减轻单台呆板的读写压力，通过增加partition数目可以增加消耗者并行消耗消息，进步kafka的水平扩展本领和吞吐量。

新闻每日会生产大量的图文跟视频数据，底层是通过tdsql存储，可以分采分片化的存储思想，将图文跟视频大概其他介质存储到不同的数据库大概数据表中，同一种介质每日的生产量也会很大，这时候就可以对同一种介质拆分成多个数据表，进一步进步数据库的存储量跟吞吐量。另外一种角度去优化存储还可以将冷热数据分离，最新的数据采用性能好的呆板存储，之前老数据访问量低，采用性能差的呆板存储，节省成本。
在微服务重构过程中，需要进行数据同步，将总库中存储的全量数据通过kafka同步到内容微服务新的存储中，预期同步qps高达15k。由于kafka的每个partition只能通过一个消耗者消耗，要到达预期qps，因此需要创建750+partition才能够实现，但是kafka的partition过多会导致rebalance很慢，影响服务性能，成本和可维护行都不高。采用分片化的思想，可以将同一个partition中的数据，通过一个消耗者在内存中分片到多个channel上，不同的channel对应的独立协程进行消耗，多协程并发处理消息进步消耗速率，消耗乐成后写入到对应的乐成channel，由同一的offsetMaker线程消耗乐成消息进行offset提交，保证消息消耗的可靠性。

避免请求

为提升写入性能，mysql在写入数据的时候，对于在bufferpool中的数据页，直接修改bufferpool的数据页并写redolog;对于不在内存中的数据页并不会立刻将磁盘中的数据页加载到bufferpool中，而是仅仅将变更记录在缓冲区，等后续读取磁盘上的数据页到bufferpool中时会进行数据合并，需要留意的是对于非唯一索引才会采用这种方式，对于唯一索引写入的时候需要每次都将磁盘上的数据读取到bufferpool才能判断该数据是否已存在，对于已存在的数据会返回插入失败。
另外mysql查询例如select * from table where name = 'xiaoming' 的查询，如果name字段存在二级索引，由于这个查询是*，表示需要地点行的所有字段，需要进行回表操作，如果仅需要id和name字段，可以将查询语句改为select id , name from tabler where name = 'xiaoming' ，这样只需要在name这个二级索引上就可以查到所需数据，避免回表操作，减少一次I/O，提升查询速率。

web应用中可以利用缓存、合并css和js文件等，避免大概减少http请求，提升页面加载速率跟用户体验。
在日常移动端开发应用中，对于多tab的数据，可以采用懒加载的方式，只有效户切换到新的tab之后才会发起请求，避免很多无用请求。服务端开发随着版本的迭代，有些功能字段端上已经不展示，但是服务端依然会返回数据字段，对于这些不需要的数据字段可以从数据源获取上就做下线处理，避免无用请求。另外在数据获取时可以对请求参数的合法性做准确的校验，例如请求投票信息时，运营配置的投票ID大概是“” 大概“0”这种不合法参数，如果对请求参数不进行校验，大概会存在很多无用I/O请求。另外在函数入口处通常会请求用户的所有实验参数，只有在实验期间才会用到实验参数，在实验下线后并没有下线ab实验平台的请求，可以在非实验期间下线这部分请求，提升接口响应速率。
池化

golang作为当代原生支持高并发的语言，池化技术在它的GMP模型就存在很大的应用。对于goroutine的销毁就不是用完直接销毁，而是放到P的本地空闲队列中，当下次需要创建G的时候会从空闲队列中直接取一个G复用即可；同样的对于M的创建跟销毁也是优先从全局队列中获取大概释放。别的golang中sync.pool可以用来生存被重复利用的对象，避免反复创建和销毁对象带来的消耗以及减轻gc压力。
mysql等数据库也都提供毗连池，可以预先创建一定命目的毗连用于处理数据库请求。当请求到来时，可以从毗连池中选择空闲毗连来处理请求，请求结束后将毗连归还到毗连池中，避免毗连创建和销毁带来的开销，提升数据库性能。
在日常工作中可以创建线程池用来处理请求，在请求到来时同样的从链接池中选择空闲的线程来处理请求，处理结束后归还到线程池中，避免线程创建带来的消耗，在web框架等需要高并发的场景下非经常见。
异步处理

异步处理在数据库中同样应用广泛，例如redis的bgsave，bgrewriteof就是分别用来异步生存RDB跟AOF文件的命令，bgsave实验后会立刻返回乐成，主线程fork出一个线程用来将内存中数据天生快照生存到磁盘，而主线程继续实验客户端命令；redis删除key的方式有del跟unlink两种，对于del命令是同步删除，直接释放内存，当遇到大key时，删除操作会让redis出现卡顿的标题，而unlink是异步删除的方式，实验后对于key只做不可达的标识，对于内存的回收由异步线程回收，不阻塞主线程。
mysql的主从同步支持异步复制、同步复制跟半同步复制。异步复制是指主库实验完提交的事务后立刻将效果返回给客户端，并不关心从库是否已经同步了数据；同步复制是指主库实验完提交的事务，所有的从库都实验了该事务才将效果返回给客户端；半同步复制指主库实验完后，至少一个从库吸取并实验了事务才返回给客户端。有多种主要是因为异步复制客户端写入性能高，但是存在丢数据的风险，在数据同等性要求不高的场景下可以采用，同步方式写入性能差，适合在数据同等性要求高的场景利用。    别的对于kafka的生产者跟消耗者都可以采用异步的方式进行发送跟消耗消息，但是采用异步的方式有大概会导致出现丢消息的标题。对于异步发送消息可以采用带有回调函数的方式，当发送失败后通过回调函数进行感知，后续进行消息补偿。
在做服务性能优化中，发现之前的一些监控上报，曝光上报等操作都在主流程中，可以将这部分功能做异步处理，降低接口的时延。别的用户发布新闻后，会将新闻写入到个人页索引，对图片进行加工处理，标题进行审核，大概给用户增加运动积分等操作，都可以采用异步处理，这里的异步处理是将发送消息这个动作发送消息到消息队列中，不同的场景消耗消息队列中的消息进行各自逻辑的处理，这种计划保证了写入性能，也解耦不同场景业务逻辑，进步系统可维护性。

总结

本文主要总结进行服务性能优化的几种方式，每一种方式在我们常用的中间件中都有所体现，我想这也是我们常说多学习这些中间件的意义，学习它们不但仅是学会怎样去利用它们，也是学习它们底层良好的计划思想，理解为什么要这样计划，这种计划有什么好处，后续我们在架构选型大概做服务性能优化时都会有一定的帮助。别的性能优化方式也给出了具体的落地实践，
盼望通过现实的应用例子增强对这种优化方式的理解。别的要做服务性能优化，照旧要从自身服务架构出发，分析服务调用链耗时分布跟cpu消耗，优化有标题标rpc调用和函数。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。