自建商城在设计之初，业务部门就提出了两个要求：不崩 & 快速上线。

在立项之后，团队还没有完全配备好，一边从其他团队里调取人手，一边大力招聘，与此同时，我们的架构师也在搭建一套分布式商城开发框架，编写 Demo，让新加入的同学能快速上手。

暴露问题

问题一：分布式事务

为什么会使用分布式事务？

这个暂且可以归因于快速上线，因为生成订单会调用到商品服务扣减库存，使用了分布式事务解决了因为跨服务调用引起库存超卖的问题，带来的问题就是性能上的消耗。

问题二：数据库压力

在大促活动期间，有个实时统计是直接从业务库上直接查询统计的，运营部门的小姐姐在不断地刷新，导致该接口上的压力山大，而且没有使用缓存，连 SQL 查询条件的时间都是动态的，导致 DB 层的缓存也使用不上，每次请求都打到 DB 上。

开发和测试环境是使用自建的 MySQL，生产环境使用的是 PolarDB，从阿里云官网上看到：

• 集群架构，计算与存储分离

• 读写分离

我们主观地认为，只要我们使用了集群连接地址就会自动进行读写分离，但是实际上并没有，后来发现在方法上显式的指定只读事务就有请求走到只读节点上了。

@Transactional(readOnly = true)

# 优化思路：

1）从 SQL 洞察和慢 SQL 里找调用响应时间最长和频度最高的 SQL；

2）结合代码，能用缓存代替的直接处理掉，不用能缓存的优化查询，结合阿里云提供的优化分析工具，调整索引；

3）活动高峰时段，禁止分析统计类的查询执行，临时改代码已经来不及了，幸亏 AHAS（阿里云的一款限流降级产品） 的接口限流和 SQL 限流功能；

4）TP 和 AP 分离，避免分析类直接查询到业务库（这是一个比较漫长的过程）。

问题三：缓存压力

除了前面所提到的分布式事务之后，发现还有同事写了使用 Keys 模糊查询 Redis，直接导致 Redis 的 CPU 飙升严重，通过阿里云提供的 Redis 管理工具可以很方便地查看到有哪些慢查询。

另外一个低级错误，我们相信应该不是第一个，也不会是最后一个，本来要设置一个 Key 的过期时间，结果少写了个 Unit 参数，第三个就变更偏移量了。

redisTemplate.opsForValue().set(key, value, offset)

# 为什么我们花了10分钟左右才解决？

1）惯性思维，review 代码没发现出来；

2）在错误日志里发现 Redisson 锁失败时，怀疑是 Redis 写满了；

3）使用阿里云的工具去查大 Key 时发现了 Key 很大，但是直接在网页查看值的时候只看到保存了一个字符，问题就出在这里，因为 RDS 管控台里获取到的值看起来是正确的，大概又过了2分钟左右，我觉得不太对劲，然后登录上去用 redis-cli 查看，傻眼了，里面塞满了 0x00。

问题四：

商城上线当月有一个促销活动，因为瞬间进来的流量过大，小程序前端埋点事件上报的接口连接数爆了，商城实时数据统计调用了流量统计服务的接口，然而服务调用超时时间设置的是60s，导致过多请求积压，CPU 突然飙升得很厉害。

# 优化思路：

1）充分利用 Nginx 的并发处理能力，Lua 脚本提供了强大的处理能力，将 Java 处理请求改为使用 OpenResty 接收；

2）接收到请求之后做好基本的校验之后，使用 lua-resty-kafka 模块异步发送到 Kafka；

3）Kafka 落盘到 HDFS 后，由 Spark 离线计算日志数据；

4）后端接口独立部署，实时数据统计调用接口设置更短的超时时间；

经过以上改造之后，前端日志上报服务单机处理能力由原来的 1K 提升 40K，那种如丝般顺滑的体验实在是太好了。

迭代

从当时的情形来看，针对双11的活动做大动作调整代码优化基本上是来不及了，离活动还有不到两个星期的时间，即便改了，风险也很高。

1、压测

作为一个新上线的项目，数据量还比较小，使用云服务来搭建一套1比1的压测环境还是比较容易的，在这个时间节点上，我们需要模拟真实的场景摸清楚目前的系统能承受多大的压力，需要多少机器。

阿里云上有个 PTS 的压测工具，可以直接导入 Jmeter 脚本，使用起来很方便，接下来说说我们的使用步骤：

1）先是按过往一个月的用户行为日志里，找出用户的路径和每个行为的思考时间，做了一个大概的模型；

2）按照双十一活动的运营节奏，定义了两到三个场景；

3）使用 ECS 搭建 Jmeter 集群，内网对接口进行施压，目的是减少网络开销，让请求都能打到后端服务器上；

4）观察服务器的压力，调节应用内存分配，再通过 PolarDB 性能分析，找出有性能瓶颈的 SQL 尽可能地优化掉；

5）将 Jmeter 脚本导入到 PTS，关联上数据库和 ECS 机器的云监控，设置好思考时间等相关的参数后施压，可以动态秒级调整压力，生成的压测报告就是我们想要的结果，需要拿这个结果来进行下一步的限流控制。

2、限流

1）在接入 AHAS 过程中，由于微商城项目当前版本接入的是spring-cloud-alibaba-dependencies-0.9.0.RELEASE版本来使用阿里云的 OSS 与 SMS，在接入 AHAS 后，需要对依赖 Alibaba 版本的升级，涉及包括 Nacos 配置中心与服务发现的升级和包路径的命名变更修改；

2）在接入 AHAS 的 gateway 网关路由限流，采用的是 SDK 接入方式，AHAS 采用了符合 springboot-starter 特性的 SDK 开发，这样在我们微商城接入 gateway 时只需要在项目 POM 中加入 spring-cloud-gateway-starter-ahas-sentinel，在接入 gateway 的时候发现，网关路由限流采集上传的 API 出现了没有兼容 Restfull 风格 API 的问题，导致 URL 上出现参数时多个url没有合并一起的情况，阿里云 AHAS 支持团队立即发布 Fix 版本，提供新的 SentinelWebInterceptor 拦截器进行清洗 Restful 风格 API 处理；

3）在接入 AHAS 的应用模块限流，采用的也是 SDK 接入方式，在按官网文档进行接入的时候，发现我们微商城采用的是最新版本的 Mybatis Plus 版本，在接入 SQL 限流分析功能时发现出现ahas报错，在将此反馈到ahas钉钉团队支援群后，当时已经差不多凌晨一点了，ahas团队的及时响应以及第二天早上就发布了兼容 Mybatis Plus 版本的SQL 限流分析版本给到我们微商城，在我们接入新版本后，SQL 分析和限流功能也能正常使用了；

4）在使用 AHAS 接入的时候，发现 AHAS 除了接口的 API 限流功能外，还提供了CPU/Load 的限流，对服务器性能情况的监控和保护做了很好的护航，在微商城服务器压力过高时能够很好的保护服务器不被高并发压垮，保证了服务的高可用，同时在服务器压力大的时候，做到了实时 QPS 日志上传的隔离，避免上传抢占服务器资源，保证了服务器在接入 AHAS 后也能保持良好的性能。

参考：完美日记分享