⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 juejin.im/post/6854573218322513933 「浪漫先生」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

前言

最近，因为增加了一些风控措施，导致新人拼团订单接口的QPS、TPS下降了约5%~10%.这还了得！首先，快速解释一下【新人拼团】活动： 业务简介：顾名思义，新人拼团是由新用户发起的拼团，如果拼团成功，系统会自动奖励新用户一张满15.1元减15的平台优惠券。这相当于是无门槛优惠了。每个用户仅有一次机会。新人拼团活动的最大目的主要是为了拉新。 新用户判断标准：是否有支付成功的订单 ? 不是新用户 : 是新用户。 当前问题：由于像这种优惠力度较大的活动很容易被羊毛党、黑产盯上。因此，我们完善了订单风控系统，让黑产无处遁形！然而由于需要同步调用风控系统，导致整个下单接口的的QPS、TPS的指标皆有下降，从性能的角度来看，【新人拼团下单接口】无法满足性能指标要求。因此CTO指名点姓让我带头冲锋……冲啊！

问题分析

风控系统的判断一般分为两种：在线同步分析和离线异步分析。在实际业务中，这两者都是必要的。在线同步分析可以在下单入口处就拦截掉风险，而离线异步分析可以提供更加全面的风险判断基础数据和风险监控能力。最近我们对在线同步这块的风控规则进行了加强和优化，导致整个新人拼团下单接口的执行链路更长，从而导致TPS和QPS这两个关键指标下降。

解决思路

要提升性能，最简单粗暴的方法是加服务器！然而，无脑加服务器无法展示出一个出色的程序员的能力。CTO说了，要加服务器可以，买服务器的钱从我工资里面扣…… 在测试环境中，我们简单的通过使用StopWatch来简单分析，伪代码如下：

@Transactional(rollbackFor = Exception.class)
public CollageOrderResponseVO colleageOrder(CollageOrderRequestVO request) {
    StopWatch stopWatch = new StopWatch();

    stopWatch.start("调用风控系统接口");
    // 调用风控系统接口, http调用方式
    stopWatch.stop();

    stopWatch.start("获取拼团活动信息"); //
    // 获取拼团活动基本信息. 查询缓存
    stopWatch.stop();

    stopWatch.start("获取用户基本信息");
    // 获取用户基本信息。 http调用用户服务
    stopWatch.stop();

    stopWatch.start("判断是否是新用户");
    // 判断是否是新用户。 查询订单数据库
    stopWatch.stop();

    stopWatch.start("生成订单并入库");
    // 生成订单并入库
    stopWatch.stop();

    // 打印task报告
    stopWatch.prettyPrint();

   // 发布订单创建成功事件并构建响应数据
    return new CollageOrderResponseVO();
}

执行结果如下：

StopWatch '新人拼团订单StopWatch': running time = 1195896800 ns
---------------------------------------------
ns         %     Task name
---------------------------------------------
014385000  021%  调用风控系统接口
010481800  010%  获取拼团活动信息
013989200  015%  获取用户基本信息
028314600  030%  判断是否是新用户
028726200  024%  生成订单并入库

在测试环境整个接口的执行时间在1.2s左右。其中最耗时的步骤是【判断是否是新用户】逻辑。这是我们重点优化的地方（实际上，也只能针对这点进行优化，因为其他步骤逻辑基本上无优化空间了）。

确定方案

在这个接口中，【判断是否是新用户】的标准是是用户是否有支付成功的订单。因此开发人员想当然的根据用户ID去订单数据库中查询。我们的订单主库的配置如下：

这配置还算豪华吧。然而随着业务的积累，订单主库的数据早就突破了千万级别了，虽然会定时迁移数据，然而订单量突破千万大关的周期越来越短……（分库分表方案是时候提上议程了，此次场景暂不讨论分库分表的内容）而用户ID虽然是索引，但毕竟不是唯一索引。因此查询效率相比于其他逻辑要更耗时。通过简单分析可以知道，其实只需要知道这个用户是否有支付成功的订单，至于支付成功了几单我们并不关心。因此此场景显然适合使用redis的bitmap数据结构来解决。在支付成功方法的逻辑中，我们简单加一行代码来设置bitmap：

// 说明：key表示用户是否存在支付成功的订单标记
// userId是long类型
String key = "order:f:paysucc";
redisTemplate.opsForValue().setBit(key, userId, true);

通过这一番改造，在下单时【判断是否是新用户】的核心代码就不需要查库了，而是改为：

Boolean paySuccFlag = redisTemplate.opsForValue().getBit(key, userId);
if (paySuccFlag != null && paySuccFlag) {
    // 不是新用户,业务异常
}

修改之后，在测试环境的测试结果如下：

StopWatch '新人拼团订单StopWatch': running time = 82207200 ns
---------------------------------------------
ns         %     Task name
---------------------------------------------
014113100  017%  调用风控系统接口
010193800  012%  获取拼团活动信息
013965900  017%  获取用户基本信息
014532800  018%  判断是否是新用户
029401600  036%  生成订单并入库

测试环境下单时间变成了0.82s，主要性能损耗在生成订单入库步骤，这里涉及到事务和数据库插入数据，因此是合理的。接口响应时长缩短了31%！相比生产环境的性能效果更明显……接着舞！

晴天霹雳

这次的优化效果十分明显，想着CTO该给我加点绩效了吧，不然我工资要被扣完了呀~ 一边这样想着，一边准备生产环境灰度发布。发完版之后，准备来个葛优躺好好休息一下，等着测试妹子验证完就下班走人。然而在我躺下不到1分钟的时间，测试妹子过来紧张的跟我说：“接口报错了，你快看看！”What? 当我打开日志一看，立马傻眼了。报错日志如下：

io.lettuce.core.RedisCommandExecutionException: ERR bit offset is not an integer or out of range
at io.lettuce.core.ExceptionFactory.createExecutionException(ExceptionFactory.java:135) ~[lettuce-core-5.2.1.RELEASE.jar:5.2.1.RELEASE]
at io.lettuce.core.ExceptionFactory.createExecutionException(ExceptionFactory.java:108) ~[lettuce-core-5.2.1.RELEASE.jar:5.2.1.RELEASE]
at io.lettuce.core.protocol.AsyncCommand.completeResult(AsyncCommand.java:120) ~[lettuce-core-5.2.1.RELEASE.jar:5.2.1.RELEASE]
at io.lettuce.core.protocol.AsyncCommand.complete(AsyncCommand.java:111) ~[lettuce-core-5.2.1.RELEASE.jar:5.2.1.RELEASE]
at io.lettuce.core.protocol.CommandHandler.complete(CommandHandler.java:654) ~[lettuce-core-5.2.1.RELEASE.jar:5.2.1.RELEASE]
at io.lettuce.core.protocol.CommandHandler.decode(CommandHandler.java:614) ~[lettuce-core-5.2.1.RELEASE.jar:5.2.1.RELEASE]
…………

bit offset is not an integer or out of range。这个错误提示已经很明显：我们的offset参数out of range。为什么会这样呢？我不禁开始思索起来：redis bitmap的底层数据结构实际上是string类型redis对于string类型有最大值限制不得超过512M，即2^32次方byte…………我靠！！！

恍然大悟

由于测试环境历史原因，userId的长度都是8位的，最大值99999999，假设offset就取这个最大值。那么在bitmap中，bitarray=999999999=2^29byte。因此setbit没有报错。而生产环境的userId，经过排查发现用户中心生成ID的规则变了，导致以前很老的用户的id长度是8位的，新注册的用户id都是18位的。以测试妹子的账号id为例：652024209997893632 = 2^59byte，这显然超出了redis的最大值要求。不报错才怪！紧急回退版本，灰度发布失败~还好，CTO念我不知道以前的这些业务规则，放了我一马~该死，还想着加绩效，没有扣绩效就是万幸的了！本次事件暴露出几个非常值得注意的问题，值得反思：

懂技术体系，还要懂业务体系 对于bitmap的使用，我们是非常熟悉的，对于多数高级开发人员而言，他们的技术水平也不差，但是因为不同业务体系的变迁而无法评估出精准的影响范围，导致无形的安全隐患。本次事件就是因为没有了解到用户中心的ID规则变化以及为什么要变化从而导致问题发生。
预生产环境的必要性和重要性 导致本次问题的另一个原因，就是因为没有预生产环境，导致无法真正模拟生产环境的真实场景，如果能有预生产环境，那么至少可以拥有生产环境的基础数据：用户数据、活动数据等。很大程度上能够提前暴露问题并解决。从而提升正式环境发版的效率和质量。
敬畏心 要知道，对于一个大型的项目而言，任何一行代码其背后都有其存在的价值：正所谓存在即合理。别人不会无缘无故这样写。如果你觉得不合理，那么需要通过充分的调研和了解，确定每一个参数背后的意义和设计变更等。以尽可能降低犯错的几率。

后记

通过此次事件，本来想着优化能够提升接口效率，从而不需要加服务器。这下好了，不仅生产环境要加1台服务器以临时解决性能指标不达标的问题，还要另外加7台服务器用于预生产环境的搭建！因为bitmap，搭进去了8台服务器。痛并值得。接着奏乐，接着舞~~~

芋道源码 —— 纯源码解析博客

因为 BitMap，白白搭进去 8 台服务器。。。

前言

问题分析

解决思路

确定方案

晴天霹雳

恍然大悟

后记