根据数据特点和数据库特点确定数据库选型

1.for循环扣减:对数据进行存储时,第一需要考虑的就是数据存储选型,mysql, redis,elasticsearch,mq,每种存储都有擅长的地方,和不擅长甚至容易出问题的地方.需要根据存储数据的特点结合数据存储的特点来选择;

先分析数据存储的特点:

从上可以归纳出个数据库都有一个极为擅长的点:

    mysql:多行事务

    mq:写入快且支持单行事务

    elasticsearch:支持大规模分片查询

    redis:写入快,查询快,支持频繁删除

elasticsearch和redis的区别在于elasticsearch可以持久化存储数据可以做到节点崩溃数据还在,redis本身就会在GC时删除键,redis也不支持分片存储无法自动路由(只能根据key的hash值来路由),如果希望数据一直在存储里,且是大规模数据,应该选用elasticsearch.

再来归纳数据的属性

因此可以根据数据库的特点来反推数据是否依赖这些特性.来确定选型.可以列一个表,分析数据在六个方面的属性特点,来决定选用哪种选型;实际上如果支持

如商品数量,具有写入速度快,需要查询的特点,那么就是redis.

如商品介绍,商品详情,数据量很大,可以使用elasticsearch,

再如定时任务:需要频繁删除,可以用redis;

秒杀任务:写入速度高,需要事务,用mq.

    如果使用debezium记录mysql binlog,在同步到kafka,进而来到redis,由于kafka每秒50000tps,因此debezium到kafka延迟在100ms内,mysql到debezium200ms左右, kafka消费端到redis100ms以内,整体延迟不超过500ms,

    实际的问题应该是,redis键消失时,可以通过mysql从库来更新,

因此高铁抢票业务:

    redis扣减票数->写日志到rocketmq里->mq消费者写mysql->debezium消费binlog->同步到kafka里->kafka消费者同步到redis里

        mysql操作:

                        1.扣减票数

                        2.建立订单消息.    实际上mysql主库仍然需要一个订单状态表,来保证扣减票数和建立订单是一个本地事务,因此不同的车票需要放到不同的库,

              扣票逻辑:

                        1.建立订单, 写消息队列,预扣redis里的库寸,订单信息可以同步到redis里,之后延迟写到mysql表

                        2.根据支付状态扣减库寸,更新同库里的扣减状态,支付状态也可以放到redis里,加快查询;

                        3.根据扣减状态,更新订单内容

            那么综上,核心库票库需要保留扣减状态表和数据表.

        唯一id需要反应订单建立时间,以天为单位.

1.实现唯一ID服务端,客户端, 

        服务端: 集群代理交给nacos,单点提供服务,

        客户端:提供重试机制,核心是CompletableFuture的onException,失败时重新发起服务,超过重试次数后就返回错误

        客户端实现,该方式需要Feign或者Dubbo,为了保证改动,可以提前定义一个接口来实现这个功能

    由于试错机制是每个实现类都需要的公共逻辑,可以抽取一个AbstractUniqueIdService,或者使用aop切面

 首先使用feign作为实现:

    public class UniqueIgGetterFeignImpl implenments UniqueIdGetter{　　　　　　　　UniqueIdFeignService uniqueIdFeignService;
　　　　　　　　public long getUniqueId(){　　　　　　　　　　　　//CompletableFuture提供试错机制.　　　　　　　　　　　return　uniqueIdFeignService.getUniqueId();　　　　　　　　}
}

 添加SpringAop切面

@Aspect
@Component
@Slf4j
public class UniqueIdServiceAspect {
    @Value("uniqueService.retry.times")
    Integer uniqueIdRetryTimes;
    // 定义环绕通知，拦截被@Loggable注解标记的方法
    @Around("execution(* com.cinus.order.service.UniqueIdService.getUniqueId(..))")
    public Object aroundGetUniqueId(ProceedingJoinPoint joinPoint) throws Throwable {
        String methodName = joinPoint.getSignature().getName();
        log.debug("开始执行方法: {}" , methodName);
        long start = System.currentTimeMillis();
        Object result=null;
        for (int i = 0; i < uniqueIdRetryTimes; i++) {
            result = joinPoint.proceed(); // 远程调用.
            if(result==null||Long.valueOf(result.toString())<0){
                continue;
            }else {
                log.debug("unique获取成功,uniqueId={}",result);
                return result;
            }
        }
        long elapsedTime = System.currentTimeMillis() - start;
        System.out.println("uniqueId获取失败: " + methodName + "，执行时间：" + elapsedTime + "毫秒");
        return null;
    }
    
}

方案缺点:    feign基于http1的请求应答模式,并发性能不好,未来可以借鉴lettuce的管道发送方式作为改善.

提交订单,扣减库寸的逻辑:

    数据分析:订单提交tps很高,要求单行事务,可以使用rocketmq来实现,此外还要扣减在redis里的库寸,如果redis里面没有货了,需要回滚日志.可以把消息写入到redis里,加快后续查询.提交订单成功后就可以调取支付模块了.这需要客户端重新发起连接.是后续的事情.

      redis扣减库寸逻辑:

        redis扣减库寸使用Lua脚本实现,同时,库寸不足时需要回滚这个同样在lua里面实现.lua脚本:

        1.for循环扣减

        2.取出当前值,若小于扣减数量,将flag定为false,将Index定义为当前i值中断逻辑

        3.如果flag为false,执行for循环,恢复库存

提交订单方法名:

public int submitOrderWithMessageQueue(OrderSubmitVo orderSubmitVo);

整体上扣减库存流程:

    1.redis写订单

    2.扣减库存

    3.写消息队列

    4.消息队列失败需要回滚redis,

    需要定义redis写订单,扣库寸,回滚的方法

    public int submmitOrderToRedis(){}//提交订单,可以保存到用户为key的zset里　　public int kjOrderToRedis(List<>){}//扣减库存　　public int rollbackToRedis(List<>,long orderId,long userId){}redis回滚　　public int sendToMessageQueue(Order order){}//发送到消息队列

库寸扣减lua

--商品库寸扣减lua
local index=1
local flag=1
local limit=tonumber(ARGV[1])
for i=2,limit  do
    local num= tonumber(redis.call('GET',KEYS[i]));-- 获取商品数量
    local result= redis.call('decrby',KEYS[i],ARGV[i])
    if num<tonumber(ARGV[i]) then　　-- 小于扣减的商品数量就将flag置为0
        index=i
        flag=0
        break
    end
end
if (flag==0) then
    for i=2 ,index do
        redis.call('INCRBY',KEYS[i],tonumber(ARGV[i])) --回退商品
    end
    return index
end
return 0

扣减库存是要不要锁MySQL,实际上商品数量小于订单数量是一个小概率事件,大部分商品都不会销售者那么快,所以只在redis里扣减库寸

redis目前使用Jedis,似乎lettuce在实现上不支持批量redis.

提交订单的方法:

    1.根据购物车选项创建订单项,计算总价格,填写收货地址

    2.生成订单id

    3.提交订单内容(到redis里)

    4.扣减库存

    5.写消息队列

    6.判断是否需要回滚

    可以并行的路线有:

        1.1->3->4    

        2.2

        1,2结束后写消息队列, 6根据消息队列来判断是否需要回滚

     顾客在购物车处选择确认订单实际上生成了一个只读的订单内容,提交到服务端,服务端会生成一个版本号,防重令牌.防重令牌代表着一次购物车里选中的购物项,这需要远程调用购物

    购物车的内容有可能很多,避免这种写入,

    1.调用购物车服务,拿到选中的商品

    2.调用运费计算模块,计算运费

    3.生成订单以及订单明细

    4.写消息队列.

    那么顾客在提交订单支付时,会携带这个防重令牌,服务端根据这个防重令牌,找到zset,并找到购物车里的内容,计算价格

      后续支持:实际上得益于唯一id,根据订单号就可以查询支付状态,进行库寸扣减.那么支付成功后,实际上扣减库寸仍然会进行,我们要明白,其实已经经过redis预扣了,不至于大量没有.

    这里的问题其实是redis,和mysql的数据延迟,如果两者相近,

rocketmq消费者消费:

        1.由于订单异步落库,消费者需要异步处理多个任务:

                a.扣减库寸

                b.建立订单

                c.回单

                d.支付成功后的业务, 应该就是回调通知用户就结束了. 

                e.支付成功后立即发货.

                    这个其实可以通过回调来实现.

                    支付成功->写消息队列. 两个消费者,一个负责回调用户,一个负责发货.用户客户端负责校验.

        扣减库寸由支付回调函数实现, 第三方支付成功后会回调地址,该url对应的函数写支付成功消息队列

        建立订单由消息队列实现,mq消费者消费订单明细

        回单采用延迟任务实现,消费者将已提交订单消息队列里的订单号写入延迟队列

        发货逻辑:对于支付成功的订单,执行发货逻辑.这里也可以用延迟队列来实现.

回单属于延迟任务,用于超时支付. 这里可以用消息队列再次写消息队列实现.        
扣减库存,消息队列扣减库存,其实可以提供两次机会,支付成功后回调时再扣减一次,这时还没有就算了.        
支付成功后,需要快速判断扣减成功以及能否派货. 这个需求当前业务是做不到的.        
建立订单,另一个消费者执行,        由于分布式的情况, 派货业务无法立即开始,因为不知道什么时候支付成功了,        数据库扣减库存逻辑:    支付成功后回调写消息队列,消息队列的消费者扣减库存,如果库寸不足直接报告失败.写入退款的消息队列

1.建立订单,分为订单详情和订单明细:

    由消息队列消费者实现,拿到消息队列后异步扣减.此处应该需要shardingJDBC,因此也是用接口先实现

        通过OnMessage,onMessage会自动提交消息位移,

    优化:采用多线程消费者进一步加快消息消费进度.因为本质就是写数据库而已.不需要顺序消费

@Component@Slf4j
@RocketMQMessageListener(topic = "tbmall-order", consumerGroup = "tbmall-order-toDb-consumer-group",
//        selectorType = SelectorType.SQL92,
//        selectorExpression = "age > 12",
        messageModel= MessageModel.CLUSTERING
)
public class OrderToDbConsumer implements RocketMQListener<String> {

    @Override
    public void onMessage(String message) {
        OrderCreateTo orderCreateTo = JSON.parseObject(message, OrderCreateTo.class);
        mqOrderToDbService.saveOrder(orderCreateTo); //插入到数据库中
    }
}

插入数据库方法名:

@Componentpublic class MqOrderToDbServiceAloneImpl implements MqOrderToDbService {
    @Autowired
    OrderService orderService;
    @Override
    public int saveOrder(OrderCreateTo orderCreateTo) {
        orderService.saveOrder(orderCreateTo);
        return 0;
    }
}

2.扣减库寸消费者,

    消费者需要根据订单明细,实现扣减库寸的逻辑.消费者可以从redis或者mysql里拿到订单明细,

    其实正确的方法应该是,支付回调时同步写入订单详细信息.但我们应该明白支付宝不一定能拿到的.靠谱的做法还是消息不存在就直接写到另一个消息队列里,实际上用不了这么久.订单表需要实现分库分表,多线程消费情况下比扣减库存逻辑快得多.扣减库寸tps可能也就2000qps,插入订单的逻辑只要分的库够多应该可以达到上万的tps,这点没问题.托底就是放入延迟队列,稍后扣减库存.

@Component@Slf4j
@RocketMQMessageListener(topic = "tbmall-order-sub", consumerGroup = "tbmall-order-toDb-substract-consumer-group",
//        selectorType = SelectorType.SQL92,
//        selectorExpression = "age > 12",
        messageModel= MessageModel.CLUSTERING,
        consumeMode = ConsumeMode.CONCURRENTLY
)
public class OrderToSubstractConsumer implements RocketMQListener<String> {
    @Override
    public void onMessage(String message) {
      Long orderId=  Long.valueOf(message);　　　　Order order=getOrderFromDb(orderId);//从数据库,redis里获取数据　　　int status=　executeOrder(Order);//扣减库存;返回值表示是否成功 这里不仅要扣减库存还要插入一条数据,表示插入已经成功,作为幂等性验证.　　　　//失败就要发起退款操作了;,　　　　if(!status) rollabckOrder(order);//这里是写消息队列,表示现在要退款了;    }
}

    public int KjStockInDb(Long orderId){
        WareSkuLockStatusEntity statusEntity = wareSkuLockStatusService.getById(orderId);
        if(statusEntity!=null){
            /**
             * 扣减由两种情况, 扣减成功1 扣减失败-1 ,扣减失败表示有商品库寸不足,需要退货,因此
             */
            //status不为0,1表示已经扣减成功,2表示回退成功,都表示不需要再消费本次消费,
            //实际上只要status不为null,就表示肯定扣减成功了.
            return 0;
        }
        WareSkuLockVo wareSkuLockVoFromDb = getWareSkuLockVoFromDb(orderId);
        
        return 0;    }