wenxinzizhu的博客

在日常开发中，延时任务是一个无法规避的话题。也存在各种不同的方案，比如：数据库轮询方案、单机内存解决方案、分布式延时队列方案。在所有的方案中，分布式延时队列方案是最佳方法，当然也是最复杂的方案。

Spring 的 @Async 注解，想必大家都非常熟悉，只需在方法上增加 @Aysnc ，便可以将其转化为异步操作，任务在后台线程池中运行。由于数据存储于内存，服务重启存在任务丢失问题，所以，只适用于要求不太严谨的业务，对于要求严格的场景，只能另选方案。

单表查询在业务开发中占比最大，是所有 CRUD Boy 的入门必备，所有人在 JavaBean 和 SQL 之间乐此不疲。而在我看来，该部分是最枯燥、最没有技术含量的“技能”。

单表查询在业务开发中占比最大，是所有 CRUD Boy 的入门必备，所有人在 JavaBean 和 SQL 之间乐此不疲。而在我看来，该部分是最枯燥、最没有技术含量的“技能”。

在各大框架中，延迟加载是一种重要的性能优化手段，所依赖的数据按需逐步完成加载（比如 Hibernate 的延迟加载）。一来，避免了全部加载带来的性能损失；二来，降低业务人员频繁进行 null 判断 和 手工加载的工作量；

在日常开发中，想必都遇到过批处理的需求，简单来说就是要求上传一个 Excel 文件，从 Excel 中读取数据，然后进行业务处理。对此，你怎么做呢？使用 poi 一行行的读取数据，然后进行类型转换，最后调用业务方法。非常不错，恭喜你完成了这项工作。但，到此为止了吗？

数据库 Join 真的太香了，但由于各种原因，在实际项目中越来越受局限，只能由开发人员在应用层完成。这种繁琐、无意义的“体力劳动”让我们离“快乐生活”越来越远。

大集合入参是性能的一大杀手，很多公司制定了规范，对数据库查询参数、RPC 调用参数进行限制，典型的有阿里P3C规范(SQL中in语句集合控制在1000以内)。我认为，只有规范没有工具是一种不负责任的表现，所以就诞生了 splitter...

1. 背景在日常开发中，延时任务是一个无法避免的话题。为了达到延时这一目的，在不同场景下会有不同的解决方案，对各个方案优缺点的认知程度决定了架构决策的有效性。本文章，以电商订单超时未支付为业务场景，推导多种解决方案，并对每个方案的优缺点进行分析，所涉及的方案包括：1.数据库轮询方案。2.单机内存解决方案。3.分布式延时队列方案。最后，为了提升研发效率，我们将使用声明式编程思想，对分布式延时队列方案进行封装，有效的分离 业务 与 技术。1.1 业务场景业务场景非常简单，就是大家最

1. 背景定时任务是实际开发中常见的一类功能，例如每天早上凌晨对前一天的注册用户数量、渠道来源进行统计，并以邮件报表的方式发送给相关人员。相信这样的需求，每个开发伙伴都处理过。你可以使用 Linux 的 Crontab 启动应用程序进行处理，或者直接使用 Spring 的 Schedule 对任务进行调度，还可以使用分布式调度系统，如果 xxl-job 等。相信你已经轻车熟路、习以为常。直到有一天你接到了一个新需求：1.新建一组任务，周期性的执行指定 SQL 并将结果以邮件的方式发送给特定人群；2.比较方便

0. 配置信息配置信息特指程序启动时对程序进行配置的信息，常见的如服务端口、数据库连接信息、线程池信息等。在系统启动时，程序会通过不同的配置方案，主动获取配置信息，以完成系统的初始化工作。因此，配置信息的管理是一件非常重要的事情。您的配置信息是怎么管理的呢？让我们一起见证下配置信息管理的不同方案。1. 将配置信息写死在业务代码中在业务代码中写死配置信息绝对是大部分新手常干的事情。该策略有以下几个特点：配置信息与源码揉在一起，没有进行分离；在编译前需要手工修改源码；不同环境所使用的 class 文件不同；不同