文章采集api(分布式事务为什么会使用分布式商城开发框架？(图))

　　文章采集api(分布式事务为什么会使用分布式商城开发框架？(图))

　　开始

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

　　项目立项后，团队还没有完全装备好。在从其他团队招聘人员的同时，我们也在大力招聘。同时，我们的架构师也在搭建分布式商城开发框架，编写demo，让新生可以快速上手。

　　暴露问题

　　问题 1：分布式事务

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

　　这暂时可以归结为快速上线，因为订单的生成会调用商品服务去扣库存，而使用分布式事务解决了跨服务调用导致的库存超卖问题，是性能消耗。

　　问题二：数据库压力

　　大促的时候有直接从业务数据库查询的实时统计，运营部*敏*感*词*姐不断刷新，给界面造成很大压力，没有使用缓存，所以连接 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 code；

　　2）当在错误日志中发现Redisson锁失败时，怀疑Redis已满；

　　3）我用阿里云的工具查大key的时候发现key很大，但是直接在网页上查值的时候只看到保存了一个字符。值好像是对的，但是大概过了2分钟左右，感觉不对劲，然后登录用redis-cli查看，傻眼了，里面全是0x00。

　　问题四：

　　商场开张当月有促销。由于瞬间进来的流量过大，小程序前端嵌入事件上报的接口连接数呈爆炸式增长。商城实时数据统计调用流量统计服务接口，但服务调用超时时间设置为60s，导致请求过多积压，CPU突然暴涨。

　　# 优化思路：

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

　　2）收到请求并做基础验证后，使用lua-resty-kafka模块异步发送到Kafka；

　　3）Kafka放到HDFS上后，Spark会离线计算日志数据；

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

　　经过上述改造，前端日志上报服务的单机处理能力由原来的1K增加了40K。丝般顺滑的体验真的很棒。

　　迭代

　　从当时的情况来看，为双十一活动调整代码优化基本上已经来不及了，距离活动还有不到两周的时间。就算改了，风险也很大。

　　1、压力测试

　　作为一个新推出的项目，数据量比较少。使用云服务搭建1:1压测环境相对容易。这个时间点，我们需要模拟真实场景来了解当前的系统性能。需要多少压力，需要多少台机器。

　　阿里云上有一个PTS压力测量工具，可以直接导入Jmeter脚本，使用非常方便。先说一下我们的使用步骤：

　　1）首先，根据近一个月的用户行为日志，找出用户的路径和每个行为的思考时间，并做了一个粗略的模型；

　　2）根据双十一活动的运行节奏，定义两个或三个场景；

　　3）使用ECS搭建Jmeter集群，内网对接口施加压力，以减少网络开销，允许向后端服务器发送请求；

　　4）观察服务器压力，调整应用内存分配，然后通过PolarDB的性能分析，找出存在性能瓶颈的SQL，尽可能优化；

　　5）将Jmeter脚本导入PTS，将数据库与ECS机器的云监控关联，设置思考时间等相关参数并施加压力，可以秒级动态调整压力，产生的压力测试报告是我们想要的结果，需要用于接下来的限流控制。

　　2、电流限制

　　上传的API与Restful风格的API不兼容，导致URL出现参数时多个URL没有合并在一起的情况。阿里云 AHAS 支持团队立即发布了 Fix 版本，并提供了新的 SentinelWebInterceptor *敏*感*词*来清理 Restful 风格的 API 处理。; 在访问AHAS的应用模块进行限流时，也是使用SDK的访问方式。根据官网文档访问时，发现我们的微商城使用的是最新版本的Mybatis Plus版本。访问SQL限流分析时发现函数执行过程中出现ahas错误。将此情况报告给ahas钉钉团队的支持小组后，已经快凌晨1:00了 ahas团队及时响应，次日上午发布了兼容Mybatis Plus版本的SQL限流分析版本。对我们的微商城来说，进入新版本后，SQL分析和限流功能也可以正常使用了；在使用AHAS访问时，发现AHAS提供了CPU/Load的限流，为监控和保护服务器性能做了很好的保驾护航。当微商城服务器压力过大时，可以很好的保护服务器不被高并发压垮，保证服务的高可用。当服务器压力较大时，实现实时QPS日志上传的隔离，避免上传抢占服务器资源，并确保服务器在访问AHAS后能够保持良好的性能。未来

　　未来计划做：

　　1）按服务拆分Redis；

　　2）数据库读写分离，分库分表，TP/AP分离；

　　3）业务集中：建立业务中心，打通商品中心、库存中心、用户中心、交易中心；