promisessh的博客

前提：最近公司在搞活动，预计会来一波业务高峰，流量会达到平时的6倍，所以各个系统都在优化、压测。目前我所负责的系统为支付系统，也就是整个链路的最下游，目前支付系统单节点TPS峰值150，10个节点，压测目标是3000+，这差了将近2倍，基于此背景下开始各种优化优化先从代码上优化，主要的优化点有：1、整个支付链路涉及到调用外部接口的地，全部异步处理，等支付完成在处理。（如果不是支付时必要的参数）2、对一些配置表的读取增加了缓存3、数据库连接从10改成了30，数据库使用的是polardb（阿里云的

2

1、

一、背景背景在上期已讲，点击这里现在要对着5亿数据做导出，单次导出不超过100万，导出时间不超过10分钟。二、架构设计1、导出功能交互由同步改为异步+通知2、借助es做二级索引，es只存查询条件并返回数据库ID3、用es返回的数据库ID去数据库做全量查询4、使用oss做断点续传5、查询es只返回id 避免回表6、数据库批量查询5000改为1000（经验值范围）7、ES查询由form+size改为scroll再改为searchAfter（解决深分页问题）8、增加机器提高并行处理能力9

一、背景目前数据库中单表数据量已达到5亿，使用的是阿里云数据库polarDB(mysql plus版)；带索引键的查询是没问题的，如果非索引查询或区分度不高的索引查询很慢，聚合查询也非常慢，这种OLTP类型的数据库本来就不适合聚合查询。恰好业务场景就是：分页查询每页需要返回当前搜索条件下的总价钱count(price)每页需要返回当前搜索条件下的总数据量count(*)而搜索条件会强制带上索引键，即使带上索引键，聚合查询还是非常慢，大约要30s左右，基于这个场景下如何优化呢？二、优化步骤

一、背景随着业务发展，对数据库的要求及数据库的维护成本越来越高，使用云数据库已成为大势所趋；云数据库具有以下优点：1、轻松部署、一键扩容2、实时备份3、高可靠、故障自动切换4、完善的监控目前需要将自建机房中的数据库迁移到阿里云数据库，需要平滑迁移，对上层业务无感，并且发版期间一直有增量的数据写入，而且程序发版期间还有产生双写：方案1:方案2:方案3:方案4:方案5:方案6:方案6执行步骤：1、阿里云数据库增加id自增起始值2、建立M5到阿里云DTS3、建立反项

背景：  楼主目前正在负责XX公司的退款系统；此系统经过N多人迭代，N多个兼容版本、N多种代码风格，目前已经无法维护下去了；借此机会，将整个系统推倒重来、彻底重构了一遍；  经压测，重构后性能(吞吐量)提升了12倍之前系统架构图：大体介绍下这个系统是干什么的，都做了些什么事：这是一个退款系统，由上游系统发起退款申请(相当于底层服务)多场景：退款的场景有N多种，现在每一种退款都维护一套单独逻辑(需要抽象)退款单组装：接收到退款请求后，做了一些基本的校验，校验通过后去组装退款单实体，组装实