踩坑日常

xxl-job升个版本，认认真真工作一天，只得来一行代码 领导又说我摸鱼 可领导，这次我真没摸鱼了！

最近，业务上了个canal，需要将数据同步到其他地方。本来也没什么，非常常见的场景，用的也比较多了。也是直接上手开始干。然后就发现了canal-spring-boot-starter下面的一些用

前言 最近碰上有个业务，查询的sql如下： 本来也没什么，很简单常见的一种sql。 问题是我们使用的是mybatis-plus，然后写的时候有没有考虑到后面的查询条件，这里用的是mybatis-plu

前言 记得刚到公司的时候，不久就和组内同事分享了一些对事务的看法。没想到最近线上又因为事务的问题出现事故，有时候确实感觉有点心累了。 这里和大家分享一下自己的看法，如果认同，希望能给你一些启发。如果不

前言 相信很多朋友在工作中都会遇到ToB的项目，而其中最耳熟能详的代表就是saas系统。 虽然目前的行情各种各样的行业saas系统数不胜数，但其中的核心思维和项目演进的过程其实看上去都是大同小异。 本

前言 最近闲来没事，一直在掘金上摸鱼，看了不少高并发相关的文章，突然有感而发，想到了几年前做的一个项目，也多少和高并发有点关系。 这里我一边回忆落地细节一边和大家分享下，兴许能给大家带来点灵感。 正文

前言 前段时间评完需求，看了看觉得还是有点复杂，于是分完任务便让同事们先写一下设计文档，两天后一起评审一下。 结果两天后一看，基本没有达到想要的结果，要么是过于简单几句话搞定，要么是原文照着需求说明抄

前段时间公司准备做一个新系统，类似于工业ERP的SAAS系统，系统中大量存在导出的业务。趁着这个机会，原来的导出服务用起来确实不怎么样，于是重新写了一套公共导出的逻辑。 设计需求 1.基本要求是

前言 今年某月，线上突然爆出OOM，欢乐的气氛突然变得紧张 干活 第一步，运维重启节点并下载dump文件 第二步，打开MAT开始分析 第三步，查看日志当前运行线程的堆占用情况 好了，一看这个线程就不正

前言 产品：我们系统在给供应商们下单之后，需要隔几天后提醒他们接单，接单后隔几天后提醒发货，以此类推不停的提醒供应商完成流程。 我：同事A，需求分给你了，你准备怎么做呢？ 同事A：就按以前的思路，下单

事务不是那么随随便便的东西，如何通过简单的补偿机制减少甚至消除对事务的依赖，解决问题不一定只有一种思路。