那些年,我们见过的 Java 服务端“问题”

导读

明代著名的心学集大成者王阳明先生在《传习录》中有云:

道无精粗,人之所见有精粗。如这一间房,人初进来,只见一个大规模如此。处久,便柱壁之类,一一看得明白。再久,如柱上有些文藻,细细都看出来。然只是一间房。

是的,知识理论哪有什么精粗之分,只是人的认识程度不同而已。笔者在初创公司摸爬滚打数年,接触了各式各样的Java服务端架构,见得多了自然也就认识深了,就能分辨出各种方案的优劣了。这里,笔者总结了一些初创公司存在的Java服务端问题,并尝试性地给出了一些不成熟的解决方案。

1.系统不是分布式

随着互联网的发展,计算机系统早就从单机独立工作过渡到多机器协同工作。计算机以集群的方式存在,按照分布式理论构建出庞大复杂的应用服务,早已深入人心并得到广泛地应用。但是,仍然有不少创业公司的软件系统停留在"单机版"。

1.1.单机版系统抢单案例

这里,用并发性比较高的抢单功能为例说明:

// 抢取订单函数
public synchronized void grabOrder(Long orderId, Long userId) {// 获取订单信息OrderDO order = orderDAO.get(orderId);if (Objects.isNull(order)) {throw new BizRuntimeException(String.format("订单(%s)不存在", orderId));}// 检查订单状态if (!Objects.equals(order.getStatus, OrderStatus.WAITING_TO_GRAB.getValue())) {throw new BizRuntimeException(String.format("订单(%s)已被抢", orderId));}// 设置订单被抢orderDAO.setGrabed(orderId, userId);
}

以上代码,在一台服务器上运行没有任何问题。进入函数grabOrder(抢取订单)时,利用synchronized关键字把整个函数锁定,要么进入函数前订单未被人抢取从而抢取订单成功,要么进入函数前订单已被抢取导致抢取订单失败,绝对不会出现进入函数前订单未被抢取而进入函数后订单又被抢取的情况。

但是,如果上面的代码在两台服务器上同时运行,由于Java的synchronized关键字只在一个虚拟机内生效,所以就会导致两个人能够同时抢取一个订单,但会以最后一个写入数据库的数据为准。所以,大多数的单机版系统,是无法作为分布式系统运行的。

1.2.分布式系统抢单案例

添加分布式锁,进行代码优化:

// 抢取订单函数
public void grabOrder(Long orderId, Long userId) {Long lockId = orderDistributedLock.lock(orderId);try {grabOrderWithoutLock(orderId, userId);} finally {orderDistributedLock.unlock(orderId, lockId);}
}// 不带锁的抢取订单函数
private void grabOrderWithoutLock(Long orderId, Long userId) {// 获取订单信息OrderDO order = orderDAO.get(orderId);if (Objects.isNull(order)) {throw new BizRuntimeException(String.format("订单(%s)不存在", orderId));}// 检查订单状态if (!Objects.equals(order.getStatus, OrderStatus.WAITING_TO_GRAB.getValue())) {throw new BizRuntimeException(String.format("订单(%s)已被抢", orderId));}// 设置订单被抢orderDAO.setGrabed(orderId, userId);
}

优化后的代码,在调用函数grabOrderWithoutLock(不带锁的抢取订单)前后,利用分布式锁orderDistributedLock(订单分布式锁)进行加锁和释放锁,跟单机版的synchronized关键字加锁效果基本一样。

1.3.分布式系统的优缺点

分布式系统(Distributed System)是支持分布式处理的软件系统,是由通信网络互联的多处理机体系结构上执行任务的系统,包括分布式操作系统、分布式程序设计语言及其编译系统、分布式文件系统分布式数据库系统等。

分布式系统的优点:

  1. 可靠性、高容错性:

一台服务器的崩溃,不会影响其它服务器,其它服务器仍能提供服务。

  1. 可扩展性:

如果系统服务能力不足,可以水平扩展更多服务器。

  1. 灵活性:

可以很容易的安装、实施、扩容和升级系统。

  1. 性能高:

拥有多台服务器的计算能力,比单台服务器处理速度更快。

  1. 性价比高:

分布式系统对服务器硬件要求很低,可以选用廉价服务器搭建分布式集群,从而得到更好的性价比。

分布式系统的缺点:

  1. 排查难度高:

由于系统分布在多台服务器上,故障排查和问题诊断难度较高。

  1. 软件支持少:

分布式系统解决方案的软件支持较少。

  1. 建设成本高:

需要多台服务器搭建分布式系统。

曾经有不少的朋友咨询我:"找外包做移动应用,需要注意哪些事项?"

首先,确定是否需要用分布式系统。软件预算有多少?预计用户量有多少?预计访问量有多少?是否只是业务前期试水版?单台服务器能否解决?是否接收短时间宕机?……如果综合考虑,单机版系统就可以解决的,那就不要采用分布式系统了。因为单机版系统和分布式系统的差别很大,相应的软件研发成本的差别也很大。

其次,确定是否真正的分布式系统。分布式系统最大的特点,就是当系统服务能力不足时,能够通过水平扩展的方式,通过增加服务器来增加服务能力。然而,单机版系统是不支持水平扩展的,强行扩展就会引起一系列数据问题。由于单机版系统和分布式系统的研发成本差别较大,市面上的外包团队大多用单机版系统代替分布式系统交付。那么,如何确定你的系统是真正意义上的分布式系统呢?从软件上来说,是否采用了分布式软件解决方案;从硬件上来说,是否采用了分布式硬件部署方案

1.4.分布式软件解决方案

作为一个合格的分布式系统,需要根据实际需求采用相应的分布式软件解决方案。

1.4.1.分布式锁

分布式锁是单机锁的一种扩展,主要是为了锁住分布式系统中的物理块或逻辑块,用以此保证不同服务之间的逻辑和数据的一致性。

目前,主流的分布式锁实现方式有3种:

  1. 基于数据库实现的分布式锁;
  2. 基于Redis实现的分布式锁;
  3. 基于Zookeeper实现的分布式锁。

1.4.2.分布式消息

分布式消息中间件是支持在分布式系统中发送和接受消息的软件基础设施。常见的分布式消息中间件有ActiveMQ、RabbitMQ、Kafka、MetaQ等。

MetaQ(全称Metamorphosis)是一个高性能、高可用、可扩展的分布式消息中间件,思路起源于LinkedIn的Kafka,但并不是Kafka的一个拷贝。MetaQ具有消息存储顺序写、吞吐量大和支持本地和XA事务等特性,适用于大吞吐量、顺序消息、广播和日志数据传输等场景。

1.4.3.数据库分片分组

针对大数据量的数据库,一般会采用"分片分组"策略:

分片(shard):主要解决扩展性问题,属于水平拆分。引入分片,就引入了数据路由和分区键的概念。其中,分表解决的是数据量过大的问题,分库解决的是数据库性能瓶颈的问题。

分组(group):主要解决可用性问题,通过主从复制的方式实现,并提供读写分离策略用以提高数据库性能。

1.4.4.分布式计算

分布式计算( Distributed computing )是一种"把需要进行大量计算的工程数据分割成小块,由多台计算机分别计算;在上传运算结果后,将结果统一合并得出数据结论"的科学。

当前的高性能服务器在处理海量数据时,其计算能力、内存容量等指标都远远无法达到要求。在大数据时代,工程师采用廉价的服务器组成分布式服务集群,以集群协作的方式完成海量数据的处理,从而解决单台服务器在计算与存储上的瓶颈。Hadoop、Storm以及Spark是常用的分布式计算中间件,Hadoop是对非实时数据做批量处理的中间件,Storm和Spark是对实时数据做流式处理的中间件。

除此之外,还有更多的分布式软件解决方案,这里就不再一一介绍了。

1.5.分布式硬件部署方案

介绍完服务端的分布式软件解决方案,就不得不介绍一下服务端的分布式硬件部署方案。这里,只画出了服务端常见的接口服务器、MySQL数据库、Redis缓存,而忽略了其它的云存储服务、消息队列服务、日志系统服务……

1.5.1.一般单机版部署方案

架构说明:

只有1台接口服务器、1个MySQL数据库、1个可选Redis缓存,可能都部署在同一台服务器上。

适用范围:

适用于演示环境、测试环境以及不怕宕机且日PV在5万以内的小型商业应用。

1.5.2.中小型分布式硬件部署方案

架构说明:

通过SLB/Nginx组成一个负载均衡的接口服务器集群,MySQL数据库和Redis缓存采用了一主一备(或多备)的部署方式。

适用范围:

适用于日PV在500万以内的中小型商业应用。

1.5.3.大型分布式硬件部署方案

架构说明:

通过SLB/Nginx组成一个负载均衡的接口服务器集群,利用分片分组策略组成一个MySQL数据库集群和Redis缓存集群。

适用范围:

适用于日PV在500万以上的大型商业应用。

2.多线程使用不正确

多线程最主要目的就是"最大限度地利用CPU资源",可以把串行过程变成并行过程,从而提高了程序的执行效率。

2.1.一个慢接口案例

假设在用户登录时,如果是新用户,需要创建用户信息,并发放新用户优惠券。例子代码如下:

// 登录函数(示意写法)
public UserVO login(String phoneNumber, String verifyCode) {// 检查验证码if (!checkVerifyCode(phoneNumber, verifyCode)) {throw new ExampleException("验证码错误");}// 检查用户存在UserDO user = userDAO.getByPhoneNumber(phoneNumber);if (Objects.nonNull(user)) {return transUser(user);}// 创建新用户return createNewUser(user);
}// 创建新用户函数
private UserVO createNewUser(String phoneNumber) {// 创建新用户UserDO user = new UserDO();...userDAO.insert(user);// 绑定优惠券couponService.bindCoupon(user.getId(), CouponType.NEW_USER);// 返回新用户return transUser(user);
}

其中,绑定优惠券(bindCoupon)是给用户绑定新用户优惠券,然后再给用户发送推送通知。如果随着优惠券数量越来越多,该函数也会变得越来越慢,执行时间甚至超过1秒,并且没有什么优化空间。现在,登录(login)函数就成了名副其实的慢接口,需要进行接口优化。

2.2.采用多线程优化

通过分析发现,绑定优惠券(bindCoupon)函数可以异步执行。首先想到的是采用多线程解决该问题,代码如下:

// 创建新用户函数
private UserVO createNewUser(String phoneNumber) {// 创建新用户UserDO user = new UserDO();...userDAO.insert(user);// 绑定优惠券executorService.execute(()->couponService.bindCoupon(user.getId(), CouponType.NEW_USER));// 返回新用户return transUser(user);
}

现在,在新线程中执行绑定优惠券(bindCoupon)函数,使用户登录(login)函数性能得到很大的提升。但是,如果在新线程执行绑定优惠券函数过程中,系统发生重启或崩溃导致线程执行失败,用户将永远获取不到新用户优惠券。除非提供用户手动领取优惠券页面,否则就需要程序员后台手工绑定优惠券。所以,用采用多线程优化慢接口,并不是一个完善的解决方案。

2.3.采用消息队列优化

如果要保证绑定优惠券函数执行失败后能够重启执行,可以采用数据库表、Redis队列、消息队列的等多种解决方案。由于篇幅优先,这里只介绍采用MetaQ消息队列解决方案,并省略了MetaQ相关配置仅给出了核心代码。

消息生产者代码:

// 创建新用户函数
private UserVO createNewUser(String phoneNumber) {// 创建新用户UserDO user = new UserDO();...userDAO.insert(user);// 发送优惠券消息Long userId = user.getId();CouponMessageDataVO data = new CouponMessageDataVO();data.setUserId(userId);data.setCouponType(CouponType.NEW_USER);Message message = new Message(TOPIC, TAG, userId, JSON.toJSONBytes(data));SendResult result = metaqTemplate.sendMessage(message);if (!Objects.equals(result, SendStatus.SEND_OK)) {log.error("发送用户({})绑定优惠券消息失败:{}", userId, JSON.toJSONString(result));}// 返回新用户return transUser(user);
}

注意:可能出现发生消息不成功,但是这种概率相对较低。

消息消费者代码:

// 优惠券服务类
@Slf4j
@Service
public class CouponService extends DefaultMessageListener<String> {// 消息处理函数@Override@Transactional(rollbackFor = Exception.class)public void onReceiveMessages(MetaqMessage<String> message) {// 获取消息体String body = message.getBody();if (StringUtils.isBlank(body)) {log.warn("获取消息({})体为空", message.getId());return;}// 解析消息数据CouponMessageDataVO data = JSON.parseObject(body, CouponMessageDataVO.class);if (Objects.isNull(data)) {log.warn("解析消息({})体为空", message.getId());return;}// 绑定优惠券bindCoupon(data.getUserId(), data.getCouponType());}
}

解决方案优点:

采集MetaQ消息队列优化慢接口解决方案的优点:

  1. 如果系统发生重启或崩溃,导致消息处理函数执行失败,不会确认消息已消费;由于MetaQ支持多服务订阅同一队列,该消息可以转到别的服务进行消费,亦或等到本服务恢复正常后再进行消费。
  2. 消费者可多服务、多线程进行消费消息,即便消息处理时间较长,也不容易引起消息积压;即便引起消息积压,也可以通过扩充服务实例的方式解决。
  3. 如果需要重新消费该消息,只需要在MetaQ管理平台上点击"消息验证"即可。

3.流程定义不合理

3.1.原有的采购流程

这是一个简易的采购流程,由库管系统发起采购,采购员开始采购,采购员完成采购,同时回流采集订单到库管系统。

其中,完成采购动作的核心代码如下:

/** 完成采购动作函数(此处省去获取采购单/验证状态/锁定采购单等逻辑) */
public void finishPurchase(PurchaseOrder order) {// 完成相关处理......// 回流采购单(调用HTTP接口)backflowPurchaseOrder(order);// 设置完成状态purchaseOrderDAO.setStatus(order.getId(), PurchaseOrderStatus.FINISHED.getValue());
}

由于函数backflowPurchaseOrder(回流采购单)调用了HTTP接口,可能引起以下问题:

  1. 该函数可能耗费时间较长,导致完成采购接口成为慢接口;
  2. 该函数可能失败抛出异常,导致客户调用完成采购接口失败。

3.2.优化的采购流程

通过需求分析,把"采购员完成采购并回流采集订单"动作拆分为"采购员完成采购"和"回流采集订单"两个独立的动作,把"采购完成"拆分为"采购完成"和"回流完成"两个独立的状态,更方便采购流程的管理和实现。

拆分采购流程的动作和状态后,核心代码如下:

/** 完成采购动作函数(此处省去获取采购单/验证状态/锁定采购单等逻辑) */
public void finishPurchase(PurchaseOrder order) {// 完成相关处理......// 设置完成状态purchaseOrderDAO.setStatus(order.getId(), PurchaseOrderStatus.FINISHED.getValue());
}/** 执行回流动作函数(此处省去获取采购单/验证状态/锁定采购单等逻辑) */
public void executeBackflow(PurchaseOrder order) {// 回流采购单(调用HTTP接口)backflowPurchaseOrder(order);// 设置回流状态purchaseOrderDAO.setStatus(order.getId(), PurchaseOrderStatus.BACKFLOWED.getValue());
}

其中,函数executeBackflow(执行回流)由定时作业触发执行。如果回流采购单失败,采购单状态并不会修改为"已回流";等下次定时作业执行时,将会继续执行回流动作;直到回流采购单成功为止。

3.3.有限状态机介绍

3.3.1.概念

有限状态机(Finite-state machine,FSM),又称有限状态自动机,简称状态机,是表示有限个状态以及在这些状态之间的转移和动作等行为的一个数学模型。

3.3.2.要素

状态机可归纳为4个要素:现态、条件、动作、次态。

现态:指当前流程所处的状态,包括起始、中间、终结状态。

条件:也可称为事件;当一个条件被满足时,将会触发一个动作并执行一次状态的迁移。

动作:当条件满足后要执行的动作。动作执行完毕后,可以迁移到新的状态,也可以仍旧保持原状态。

次态:当条件满足后要迁往的状态。“次态”是相对于“现态”而言的,“次态”一旦被激活,就转变成新的“现态”了。

3.3.3.状态

状态表示流程中的持久状态,流程图上的每一个圈代表一个状态。

初始状态: 流程开始时的某一状态;

中间状态: 流程中间过程的某一状态;

终结状态: 流程完成时的某一状态。

使用建议:

  1. 状态必须是一个持久状态,而不能是一个临时状态;
  2. 终结状态不能是中间状态,不能继续进行流程流转;
  3. 状态划分合理,不要把多个状态强制合并为一个状态;
  4. 状态尽量精简,同一状态的不同情况可以用其它字段表示。

3.3.4.动作

动作的三要素:角色、现态、次态,流程图上的每一条线代表一个动作。

角色: 谁发起的这个操作,可以是用户、定时任务等;

现态: 触发动作时当前的状态,是执行动作的前提条件;

次态: 完成动作后达到的状态,是执行动作的最终目标。

使用建议:

  1. 每个动作执行前,必须检查当前状态和触发动作状态的一致性;
  2. 状态机的状态更改,只能通过动作进行,其它操作都是不符合规范的;
  3. 需要添加分布式锁保证动作的原子性,添加数据库事务保证数据的一致性;
  4. 类似的动作(比如操作用户、请求参数、动作含义等)可以合并为一个动作,并根据动作执行结果转向不同的状态。

4.系统间交互不科学

4.1.直接通过数据库交互

在一些项目中,系统间交互不通过接口调用和消息队列,而是通过数据库直接访问。问其原因,回答道:"项目工期太紧张,直接访问数据库,简单又快捷"。

还是以上面的采购流程为例——采购订单由库管系统发起,由采购系统负责采购,采购完成后通知库管系统,库管系统进入入库操作。采购系统采购完成后,通知库管系统数据库的代码如下:

/** 执行回流动作函数(此处省去获取采购单/验证状态/锁定采购单等逻辑) */
public void executeBackflow(PurchaseOrder order) {// 完成原始采购单rawPurchaseOrderDAO.setStatus(order.getRawId(), RawPurchaseOrderStatus.FINISHED.getValue());// 设置回流状态purchaseOrderDAO.setStatus(order.getId(), PurchaseOrderStatus.BACKFLOWED.getValue());
}

其中,通过rawPurchaseOrderDAO(原始采购单DAO)直接访问库管系统的数据库表,并设置原始采购单状态为已完成。

一般情况下,直接通过数据访问的方式是不会有问题的。但是,一旦发生竞态,就会导致数据不同步。有人会说,可以考虑使用同一分布式锁解决该问题。是的,这种解决方案没有问题,只是又在系统间共享了分布式锁。

直接通过数据库交互的缺点:

  1. 直接暴露数据库表,容易产生数据安全问题;
  2. 多个系统操作同一数据库表,容易造成数据库表数据混乱;
  3. 操作同一个数据库表的代码,分布在不同的系统中,不便于管理和维护;
  4. 具有数据库表这样的强关联,无法实现系统间的隔离和解耦。

4.2.通过Dubbo接口交互

由于采购系统和库管系统都是内部系统,可以通过类似Dubbo的RPC接口进行交互。

库管系统代码:

/** 采购单服务接口 */
public interface PurchaseOrderService {/** 完成采购单函数 */public void finishPurchaseOrder(Long orderId);
}
/** 采购单服务实现 */
@Service("purchaseOrderService")
public class PurchaseOrderServiceImpl implements PurchaseOrderService {/** 完成采购单函数 */@Override@Transactional(rollbackFor = Exception.class)public void finishPurchaseOrder(Long orderId) {// 相关处理...// 完成采购单purchaseOrderService.finishPurchaseOrder(order.getRawId());}
}

其中,库管系统通过Dubbo把PurchaseOrderServiceImpl(采购单服务实现)以PurchaseOrderService(采购单服务接口)定义的接口服务暴露给采购系统。这里,省略了Dubbo开发服务接口相关配置。

采购系统代码:

/** 执行回流动作函数(此处省去获取采购单/验证状态/锁定采购单等逻辑) */
public void executeBackflow(PurchaseOrder order) {// 完成采购单purchaseOrderService.finishPurchaseOrder(order.getRawId());// 设置回流状态purchaseOrderDAO.setStatus(order.getId(), PurchaseOrderStatus.BACKFLOWED.getValue());
}

其中,purchaseOrderService(采购单服务)为库管系统PurchaseOrderService(采购单服务)在采购系统中的Dubbo服务客户端存根,通过该服务调用库管系统的服务接口函数finishPurchaseOrder(完成采购单函数)。

这样,采购系统和库管系统自己的强关联,通过Dubbo就简单地实现了系统隔离和解耦。当然,除了采用Dubbo接口外,还可以采用HTTPS、HSF、WebService等同步接口调用方式,也可以采用MetaQ等异步消息通知方式。

4.3.常见系统间交互协议

4.3.1.同步接口调用

同步接口调用是以一种阻塞式的接口调用机制。常见的交互协议有:

  1. HTTP/HTTPS接口;
  2. WebService接口;
  3. Dubbo/HSF接口;
  4. CORBA接口。

4.3.2.异步消息通知

异步消息通知是一种通知式的信息交互机制。当系统发生某种事件时,会主动通知相应的系统。常见的交互协议有:

  1. MetaQ的消息通知;
  2. CORBA消息通知。

4.4.常见系统间交互方式

4.4.1.请求-应答

适用范围:

适合于简单的耗时较短的接口同步调用场景,比如Dubbo接口同步调用。

4.4.2.通知-确认

适用范围:

适合于简单的异步消息通知场景,比如MetaQ消息通知。

4.4.3.请求-应答-查询-返回

适用范围:

适合于复杂的耗时较长的接口同步调用场景,比如提交作业任务并定期查询任务结果。

4.4.4.请求-应答-回调

适用范围:

适合于复杂的耗时较长的接口同步调用和异步回调相结合的场景,比如支付宝的订单支付。

4.4.5.请求-应答-通知-确认

适用范围:

适合于复杂的耗时较长的接口同步调用和异步消息通知相结合的场景,比如提交作业任务并等待完成消息通知。

4.4.6.通知-确认-通知-确认

适用范围:

适合于复杂的耗时较长的异步消息通知场景。

5.数据查询不分页

在数据查询时,由于未能对未来数据量做出正确的预估,很多情况下都没有考虑数据的分页查询。

5.1.普通查询案例

以下是查询过期订单的代码:

/** 订单DAO接口 */
public interface OrderDAO {/** 查询过期订单函数 */@Select("select * from t_order where status = 5 and gmt_create < date_sub(current_timestamp, interval 30 day)")public List<OrderDO> queryTimeout();
}/** 订单服务接口 */
public interface OrderService {/** 查询过期订单函数 */public List<OrderVO> queryTimeout();
}

当过期订单数量很少时,以上代码不会有任何问题。但是,当过期订单数量达到几十万上千万时,以上代码就会出现以下问题:

  1. 数据量太大,导致服务端的内存溢出;
  2. 数据量太大,导致查询接口超时、返回数据超时等;
  3. 数据量太大,导致客户端的内存溢出。

所以,在数据查询时,特别是不能预估数据量的大小时,需要考虑数据的分页查询。

这里,主要介绍"设置最大数量"和"采用分页查询"两种方式。

5.2.设置最大数量

"设置最大数量"是一种最简单的分页查询,相当于只返回第一页数据。例子代码如下:

/** 订单DAO接口 */
public interface OrderDAO {/** 查询过期订单函数 */@Select("select * from t_order where status = 5 and gmt_create < date_sub(current_timestamp, interval 30 day) limit 0, #{maxCount}")public List<OrderDO> queryTimeout(@Param("maxCount") Integer maxCount);
}/** 订单服务接口 */
public interface OrderService {/** 查询过期订单函数 */public List<OrderVO> queryTimeout(Integer maxCount);
}

适用于没有分页需求、但又担心数据过多导致内存溢出、数据量过大的查询。

5.3.采用分页查询

"采用分页查询"是指定startIndex(开始序号)和pageSize(页面大小)进行数据查询,或者指定pageIndex(分页序号)和pageSize(页面大小)进行数据查询。例子代码如下:

/** 订单DAO接口 */
public interface OrderDAO {/** 统计过期订单函数 */@Select("select count(*) from t_order where status = 5 and gmt_create < date_sub(current_timestamp, interval 30 day)")public Long countTimeout();/** 查询过期订单函数 */@Select("select * from t_order where status = 5 and gmt_create < date_sub(current_timestamp, interval 30 day) limit #{startIndex}, #{pageSize}")public List<OrderDO> queryTimeout(@Param("startIndex") Long startIndex, @Param("pageSize") Integer pageSize);
}/** 订单服务接口 */
public interface OrderService {/** 查询过期订单函数 */public PageData<OrderVO> queryTimeout(Long startIndex, Integer pageSize);
}

适用于真正的分页查询,查询参数startIndex(开始序号)和pageSize(页面大小)可由调用方指定。

5.3.分页查询隐藏问题

假设,我们需要在一个定时作业(每5分钟执行一次)中,针对已经超时的订单(status=5,创建时间超时30天)进行超时关闭(status=10)。实现代码如下:

/** 订单DAO接口 */
public interface OrderDAO {/** 查询过期订单函数 */@Select("select * from t_order where status = 5 and gmt_create < date_sub(current_timestamp, interval 30 day) limit #{startIndex}, #{pageSize}")public List<OrderDO> queryTimeout(@Param("startIndex") Long startIndex, @Param("pageSize") Integer pageSize);/** 设置订单超时关闭 */@Update("update t_order set status = 10 where id = #{orderId} and status = 5")public Long setTimeoutClosed(@Param("orderId") Long orderId)
}/** 关闭过期订单作业类 */
public class CloseTimeoutOrderJob extends Job {/** 分页数量 */private static final int PAGE_COUNT = 100;/** 分页大小 */private static final int PAGE_SIZE = 1000;/** 作业执行函数 */@Overridepublic void execute() {for (int i = 0; i < PAGE_COUNT; i++) {// 查询处理订单List<OrderDO> orderList = orderDAO.queryTimeout(i * PAGE_COUNT, PAGE_SIZE);for (OrderDO order : orderList) {// 进行超时关闭......orderDAO.setTimeoutClosed(order.getId());}// 检查处理完毕if(orderList.size() < PAGE_SIZE) {break;}}}
}

粗看这段代码是没有问题的,尝试循环100次,每次取1000条过期订单,进行订单超时关闭操作,直到没有订单或达到100次为止。但是,如果结合订单状态一起看,就会发现从第二次查询开始,每次会忽略掉前startIndex(开始序号)条应该处理的过期订单。这就是分页查询存在的隐藏问题

当满足查询条件的数据,在操作中不再满足查询条件时,会导致后续分页查询中前startIndex(开始序号)条满足条件的数据被跳过。

可以采用"设置最大数量"的方式解决,代码如下:

/** 订单DAO接口 */
public interface OrderDAO {/** 查询过期订单函数 */@Select("select * from t_order where status = 5 and gmt_create < date_sub(current_timestamp, interval 30 day) limit 0, #{maxCount}")public List<OrderDO> queryTimeout(@Param("maxCount") Integer maxCount);/** 设置订单超时关闭 */@Update("update t_order set status = 10 where id = #{orderId} and status = 5")public Long setTimeoutClosed(@Param("orderId") Long orderId)
}/** 关闭过期订单作业(定时作业) */
public class CloseTimeoutOrderJob extends Job {/** 分页数量 */private static final int PAGE_COUNT = 100;/** 分页大小 */private static final int PAGE_SIZE = 1000;/** 作业执行函数 */@Overridepublic void execute() {for (int i = 0; i < PAGE_COUNT; i++) {// 查询处理订单List<OrderDO> orderList = orderDAO.queryTimeout(PAGE_SIZE);for (OrderDO order : orderList) {// 进行超时关闭......orderDAO.setTimeoutClosed(order.getId());}// 检查处理完毕if(orderList.size() < PAGE_SIZE) {break;}}}
}

后记

本文是《那些年,我们见过的Java服务端“乱象”》的姐妹篇,前文主要介绍的是Java服务端规范上的问题,而本文主要介绍的是Java服务端方案上的问题。

谨以此文献给当年"E代驾"下的"KK拼车"团队,怀念曾经一起奋斗过的兄弟们,怀念那段为代驾司机深夜返程保驾护航的岁月。深感遗憾的是,"KK拼车"刚刚崭露头角,还没来得及好好发展,就被公司断臂裁撤了。值得欣慰的是,"KK拼车"自在人心,据说现在已经成为了一个"民间组织"。


原文链接
本文为云栖社区原创内容,未经允许不得转载。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/517750.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

中兴通讯uSmart云电脑,开启安全办公新时代

2020年春天&#xff0c;以5G、人工智能、云计算为代表的“新基建”蔚然成风&#xff0c;着眼国家数字经济体系建设&#xff0c;打造数字经济体系底座的“新基建”&#xff0c;无疑成为中国经济整体应对未来发展的核心方案。可以说&#xff0c;没有任何一个时期比现在更能够彰显…

阿里张磊:云计算生态价值点正迅速聚焦到“应用”上

导读&#xff1a;云原生不再只是基础设施的开发和运维人员的关注点&#xff0c;在应用交付领域小组成立之后&#xff0c;CNCF 基金会正在同应用开发和应用运维人员更紧密的联系在一起。 云原生的理念如今正如火如荼。它不仅仅是一种技术&#xff0c;更是社区基于对云的思考&…

SpringBoot 整合 Spring Cloud Alibaba Nacos 连通性+负载均衡

文章目录一、整合版本说明1. 毕业版本依赖关系(推荐使用)2. 组件版本关系3. 演示版本二、整合实战2.1. 聚合模块设计2.2. 创建聚合parent2.3. 依次创建子项目三、子模块配置3.1. 订单模块3.2. 产品模块3.3. 用户模块3.4. 扣库存模块3.5. 购物车模块四、测试案例4.1. 订单模块4.…

使用dubbo后尽量不用要@Service可能引起冲突

如下有几个包都含有Service dubbo最新版本2.7.8&#xff0c;已经把Service换成DubboService 示例实现类 package com.dubboprovider.service;import org.apache.dubbo.config.annotation.DubboService; import org.springframework.stereotype.Component;//zookeeper 服务注…

面试中遇到这 3 个SQL问题,最容易掉坑里!

作者 | Nathan R译者 | 天道酬勤&#xff0c;责编 | Carol封图 | CSDN下载自视觉中国在本文中&#xff0c;作者将介绍来自3个在技术面试中的真实的SQL问题&#xff0c;这些问题都是在实际公司进行技术筛选时提出的。最常见的读者问题&#xff1a;我应该如何准备SQL面试&#xf…

云原生数据库POLARDB专场“硬核”解析

POLARDB是阿里巴巴自主研发的云原生关系型数据库&#xff0c;目前兼容三种数据库引擎&#xff1a;MySQL、PostgreSQL、Oracle。POLARDB的计算能力最高可扩展至1000核以上&#xff0c;存储容量可达100TB。 POLARDB融合了商业数据库稳定、可靠、高性能的特征&#xff0c;同时具有…

K8s 从懵圈到熟练 – 集群网络详解

导读&#xff1a;阿里云 K8S 集群网络目前有两种方案&#xff1a;一种是 flannel 方案&#xff1b;另外一种是基于 calico 和弹性网卡 eni 的 terway 方案。Terway 和 flannel 类似&#xff0c;不同的地方在于 terway 支持 Pod 弹性网卡&#xff0c;以及 NetworkPolicy 功能。本…

使用dubbo后尽量不用要@Reference可能引起冲突

使用dubbo后尽量不用要Reference可能引起冲突 dubbo最新版本2.7.8&#xff0c;已经把Reference换成DubboReference

年薪高达30万,人才缺口40万,这个神仙职业今年太火了!

我见过市面上很多的 Python 讲解教程和书籍&#xff0c;他们大都这样讲 Python 的&#xff1a;先从 Python 的发展历史开始&#xff0c;介绍 Python 的基本语法规则&#xff0c;Python 的 list, dict, tuple 等数据结构&#xff0c;然后再介绍字符串处理和正则表达式&#xff0…

不吹不黑,今天我们来聊一聊 Kubernetes 落地的三种方式

出身豪门、大厂背书的 Kubernetes 项目自 2014 年 6 月开源以来&#xff0c;在众多厂商和开源爱好者的共同努力下迅速崛起&#xff0c;时至今日已成长为容器管理领域的事实标准。凭借超前的设计理念、开放的参与门槛、国内外大厂和开发者的大力支持&#xff0c;它的成功不言而喻…

当我们在聊 Serverless 时你应该知道这些

作者 | 杨泽强&#xff08;竹涧&#xff09;阿里云技术专家 说起当前最火的技术&#xff0c;除了最新的区块链、AI&#xff0c;还有一个不得不提的概念是 Serverless。Serverless 作为一种新型的互联网架构&#xff0c;直接或间接推动了云计算的发展&#xff0c;从 AWS Lambda…

nacos集成dubbo实现远程服务调用

文章目录1. 模块划分设计2. 创建父工程3. 创建公共接口4. 服务端5. 客户端6. nacos7. 测试8. 码云开源地址1. 模块划分设计 模块名工程名端口父工程nacos-dubbo无服务端nacos-dubbo-provider9000消费端nacos-dubbo-consumer8000公共接口nacos-dubbo-interface无 2. 创建父工程…

如何在容器内高效编程?

作者 | Daniel Lemire译者 | 苏本如&#xff0c;责编 | 郭芮头图 | CSDN 下载自东方IC出品 | CSDN&#xff08;ID&#xff1a;CSDNnews&#xff09;以下为译文&#xff1a;我个人的编程环境中包括了一些服务器、笔记本电脑和台式电脑。我的服务器是在不同的时间购买和配置的&am…

(企业案例)Nacos Config 进阶使用

文章目录一、SpringBoot 使用 Nacos Config 实现多环境切换1. 现象2. 引入依赖3. 添加bootstrap.yaml配置文件4. 配置对应关系图5. 文件格式简述6. 启动nacos7. 添加生产配置8. 添加测试controller9. 启动Springboot工程并观察到如下日志则为成功10. 浏览器验证11. 调整激活环境…

OceanBase如何获得TPC-C测试第1名?

阿里妹导读&#xff1a;TPC-C是TPC组织&#xff08;国际事务性能委员会&#xff09;制定的关于商品销售的订单创建和订单支付等的基准测试标准&#xff0c;是数据库联机交易处理系统的权威基准测试标准。 蚂蚁金服自研的分布式关系数据库OceanBase获得TPC-C测试第一名后&#…

由一次磁盘告警引发的“血案”——你知道 du 和 ls 区别吗?

来源 | 程序猿石头责编 | Carol封图 | CSDN下载自视觉中国图来源于 SkyPixel知道为什么会有上面的结果吗&#xff1f;什么又是稀疏文件&#xff1f;这篇文章将为你揭秘。问题背景确切地说&#xff0c;不是收到的自动告警短信或者邮件告诉我某机器上的磁盘满了&#xff0c;而是某…

如何优化大规模推荐?下一代算法技术JTM来了

阿里妹导读&#xff1a;搜索&#xff0c;推荐和广告是互联网内容提供商进行价值创造的核心业务&#xff0c;在阿里巴巴的电子商务交易平台上&#xff0c;搜索&#xff0c;推荐和广告业务同样具有举足轻重的意义和价值。现在&#xff0c;阿里推荐技术又双叒优化了&#xff0c;新…

Sentinel 基于Nacos规则持久化-推模式

文章目录一、推模式架构图二、原理简述2.1. 组件版本关系2.2. 控制台推送规则三、Sentinel控制台改造3.1. 下载源码3.2. 修改pom3.3. 重要文件复制3.4. 注册地址修改3.5. 请求实例需改3.6. 菜单新增四、编译 & 启动4.1. 先启动nacos4.2. 编译打包4.3. 创建微服务 &&…

都听我的,会养猪种菜的工程师最帅了!

来了&#xff01;今天&#xff0c;阿里数字农业事业部在黑龙江首次亮相&#xff0c;并且定了一个小目标&#xff1a;到2022年&#xff0c;阿里涉农产品全年网络销售额破4000亿元。 黑龙江省牡丹江市的阿里巴巴响水大米种植基地&#xff0c;又到了收割季 数字农业事业部将建立产…

清华硕士一针见血:这些才是机器学习必备的数学基础

现如今&#xff0c;计算机科学、人工智能、数据科学已成为技术发展的主要推动力。无论是要翻阅这些领域的文章&#xff0c;还是要参与相关任务&#xff0c;你马上就会遇到一些拦路虎&#xff1a;想过滤垃圾邮件&#xff0c;不具备概率论中的贝叶斯思维恐怕不行&#xff1b;想试…