通常，功能上线之前，压测是必不可少的，可以从以下几个点进行优化 ：
1、Redis连接数、大key(hash key)。但凡用到线程池的地方，都是有优化空间的，合理设置线程池参数可以提高吞吐量。这些参数的设置是经过很多次的压测调整再压测这样试出来的；
2、Dubbo线程数、超时时间等；
3、内存缓存。如果分布式缓存还是不够快的话，可以增加内存缓存，SpringBoot支持很多内存缓存框架的。事实上，一般都是要加内存缓存的，不然TPS上不去。加了内存缓存以后，内存缓存的刷新就成为了一个新问题，一般可以采用定时任务刷新、MQ消息通知、ZK监听等方式；
4、MySQL读写分离就不用说了，连接数、索引等等，一般问题不大。因为，大部分的应用是读多写少；多说一句，其实有一些数据也可以考虑异步批量写入MySQL；
5、不同业务之间要进行隔离。最常见的是，一台机器上只部署一个服务，这样可以减小受其它服务的影响。但有时候，这样也不够，比如限时抢购、直播商品等，就是某些商品的访问量非常大，而其它大部分商品的访问量小，虽然可能同属商品服务，但是其它商品还是会受到这些热点商品的影响，这种情况下建议把这些热点商品单独拿出来放到一个地方，比如，我们提前把这些商品放到一个单独的redis中。做多了之后呢，可以把这种业务场景单独抽取成一个服务；
6、能异步就绝不同步。如果有些操作可以异步执行的话就异步执行吧，都同步操作那谁受得了啊。比如，直播间中的弹幕、聊天消息、礼物等等，都可以通过MQ做成异步的；
7、加机器。通过增加服务的数量可以提高服务的吞吐量，最好是自动（弹性）扩缩容的，毕竟服务器是要钱的；
8、不必要的日志少打一点儿。日志毕竟是要写到磁盘上的，当然一般影响不大，但是如果实在没办法可以试试这一招，日志太多会占用磁盘IO；
最重要的是，多压测，找出系统瓶颈，并加以优化，通过压测可以找到各项参数的最佳值。这个时候，监控就显得尤为重要，各个组件的监控，各种维度的监控，越详细越好。
隔离，一定要隔离，业务隔离，避免相互影响，断路器
监控和告警，出现问题可以第一时间发出告警和通知
Pinpoint是一个很有用的工具，可以每一个请求在每一步花费的时间
QPS：Queries Per Second，意思是“每秒查询率”。是一台服务器每秒能够响应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
TPS：Transactions Per Second，意思是每秒事务数。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。TPS是衡量系统性能的一个非常重要的指标。
显然，QPS不能描述增删改，因此TPS才能更好反应服务的吞吐量。
如果没有定义事务，会把每个请求作为一个事务。
如果是对一个接口（单场景）压测，且这个接口内部不会再去请求其它接口，那么TPS等于QPS，否则，TPS不等于QPS。
如果是对多个接口（混合场景）压测，不加事务控制器，jmeter会统计每个接口的tps，而混合场景是要测试这个场景的tps，显然这样得不到混合场景的tps，所以，要加了事物控制器，结果才是整个场景的tps。
在JMeter聚合报告中，Throughput是用来衡量请求的吞吐量，也就是TPS，tps=样本数/运行时间。
开关，涉及老数据的功能，上线之前不妨加个开关，比如OpenSearch切换程ElasticSearch等，有了开关就可以在必要的时候（出现问题的时候）手动切回去
HashMap是无序的，LinkedHashMap是有序的
修数据、迁移数据方案：
1、数据量少的话，写个程序跑一下就好；
2、数据量大的话，建议用MQ，写一个生产者程序读数据，启动多个消费者写数据。
采用MQ方式有两个好处：
（1）消费者越多，处理速度越快，这比一个程序里启多个线程来处理要强得多；
（2）一旦出错，数据仍然在队列中。否则，你就要扒日志去找哪些处理失败了，当然也可以记录到表中，回头再重新执行一遍；
重要的业务要加强代码Review，review要及时，可以先用代码规范插件扫一遍，bug永远出在最意想不到的地方，老司机也可能翻车，
索引、默认值等不必再说，无论mysql还是mongodb
少自己造*，多用开源的工具类和开源的解决方案，Hutool了解一下 https://hutool.cn/
多用stream，多用parallelStream，不过一定要注意用法和场景
多关注线上异常，及时清理线上异常
多关注系统性能，多看看系统监控，阿里云，自定义的grafana，反正多看看监控，可以及早发现问题，重点是领导一般不会关注具体功能实现，而关注的是数据
人与人之间是有能量场的，谁的能量强，气场就强，能量小的人就被比下去了
多表现自己，高调做事，低调做人