大摩羯先生

本篇聊聊公司自研数据存储迁移到MySQL过程中的技术选型、技术方案设计。围绕数据层进行的实时、离线数据链路进行迁移同步，不再完全依靠应用层的繁重设计，减轻心智负担。最后简单对项目做了反思和建议。

Activiti工作流与业务整合进行实践，技术调研对比JBPM与Activiti工作流的特性，结合实际业务和技术背景对Activiti进行改造和融合，通过Aop切面抽离工作流业务，通过Spel进行形参实参绑定及复杂数据结构传参，通过合理的流程设计、架构设计实现Activiti与业务逻辑整合

  这是一篇关于供应链业务相关的OMS系统实战技术文章，整理自近半年的开发实践，由于业务背景的差异化、具体落地的独特性以及个人业务知识的局限性，这里不做普适性供应链业务领域的深入讨论，仅论述自身业务场景中技术方案的实现过程，部分内容略有一些特殊性和局限性。....................................

分布式事务实战方案汇总

1、JSF启动报错，排查jsf使用到的jar包，如netty-all、javassist等2、金融网关序列化对Long、String会转换，所以字段端名称不可使用此类关键词3、金融网关序列化对Long会有精度丢失，使用String替代，front层做转换4、金融网关方法名称全局唯一性，使用带有项目业务属性的名称规避命名重复5、启动tomcat异常，注意关注启动日志，一般会有jar冲突，特别是log4j126、核心服务尽量提供release包，确保引用方jar包稳定性，更新快照jar要充分考虑给调用

数据落库自动加解密实现

缓存处理逻辑优化、缓存击穿、缓存过滤、缓存移除

流量加权负载控制

基于事件驱动机制解耦、设计模式

Future超时阻塞与线程池拒绝策略

数据库与消息队列分布式事务设计

Redis，竞争锁，失败异步获取兜底优化

分布式缓存更新的脏读问题总结

Spring事务管理，TransactionSynchronization的精细化使用，例举了实战中数据库事务与MQ绑定

Spel提供了强大的各种结构化参数解析能力为动态传参赋值提供了友好支持，Aop提供了切面编程的便利，两者结合使得大量共同的业务逻辑可以抽象成切面，使得代码维护更便利

1、单链表实现public class LinkedList { private final Integer[] week; public LinkedList() { week = new Integer[]{1, 2, 3, 4, 5, 6, 7};//一周中的7天 } public static Integer[] orderByWeekDayWithLinkedList(Integer[] week, int day) {

1、原理通过RPC框架提供的RpcContext进行traceId传递，RpcContext是大多数RPC框架提供的一个ThreadLocal内部实现，供使用方进行传参要在rpc调用前进行设置才可以，否则下游provider拿不到，因为调用后即销毁 保证传值key唯一性，防止无意中被覆盖这里使用了session而不是原始的attachment，是处于某个方法调用声明周期中间调用多个provider，防止调用一次失效（待验证复杂链路追踪）2、实现全局切面/** * @description

配置中心配置成json格式便于扩展，可以针对不同日志类型进行等级控制[{ "name":"root", "level":"debug"},{ "name":"com.jdd", "level":"info"}]代码实现/** * @description: 日志配置 */@Component("logConfig")public class LogConfig { private final static Logger LOGGER = Lo

从dbcp数据库连接池参数调优、网络情况优化、logback日志优化、缓存连接等方面对服务接口耗时进行评估分析，给出实战中的解决方案

探究复杂业务逻辑治理，通过责任链设计模式、ThreadLocal本地线程变量作为原始素材进行设计，抽象Context、Processor、Executor、Handler等领域模型进行复杂逻辑治理和探究

业务背景在业务量初期，数据量很小，大多数开发人员都选择了采用单库单表进行研发方案设计和构建。单库单表的好处是开发快，业务模型构建与库表映射简单，便于理解和沟通。随着业务增长，伴随单库单表而来的是查询瓶颈问题，首先在单表突破百万甚至千万，在已有索引的前提下查询优化空间并不多，而且数据变更往往要小心翼翼，一旦有大事务会直接拖慢整个数据库的查询性能，连锁雪崩效应带来的后果不堪设想，往往我们会对单库单表进行垂直和水平拆分以达到优化查询的目的。问题描述在水平拆分的过程中，通常都是以一个字段作为切分键对数据进行拆

设计背景概念先简单解释下什么是分布式多级缓存，所谓分布式简单理解就是异地跨机房服务应用部署；所谓多级缓存，这里狭义语义指定的是应用服务级别的缓存，通常泛指Redis、Memcached等；所谓多级缓存，这里是将JVM级的驻留缓存和外部依赖的缓存服务相比而言的。Redis、Memcached等都提供了性能优越的缓存服务，在高并发场景下作为提高吞吐量、优化服务性能的利器立下了汗马功劳。场景一般情况下，缓存我们只使用Redis作为唯一缓存就可以满足大多数业务场景。这里我们不考虑一般的业务场景，现在试图将服

一年一度的618、双11，是各大电商平台投入资源最多、用户参与最广泛、流量最爆棚、系统最经受考验的时候，作为程序员的一份子，有幸能在工作中接触到这种流量的洗礼，能在一年中最考验系统健壮性的时刻来接收检验，真是让人斗志满满。每逢大促，琳琅满目各式各样的大促运营活动比比皆是，吸引用户眼球的是各类商品补贴、红包、优惠券、免单，活动玩法有签到、完成任务、游戏对战、组团等，获取收益的方式有抽奖、兑换等，最终这些活动的目的就是拉新促活，为平台带来流量，增加平台活跃度，提高用户参与度，激发下单意愿，提高成交转换率。

简单谈谈线程池在使用过程中出现异常的一些处理策略，合理使用线程池，必须能够识别主线程与线程池直接的关系、充分了解线程池机制，发挥优点，了解盲区，合理利用不留坑。先demo几个例子，有时间展开论述下使用场景和异常处理。/** * created by guanjian on 2020/6/18 15:30 */public class ThreadPoolExecutorTest extends BaseTest { @Resource private ThreadPool

目录1、决策树二叉寻果策略匹配1.1策略匹配示意图1.2方案总结2、决策表映射寻果策略匹配1.1策略匹配示意图1.2方案总结1.3实战1、决策树二叉寻果策略匹配1.1策略匹配示意图1.2方案总结※ 时间复杂度分析平均时间复杂度O(log2N)，根据实际业务场景判断配置，极大可能是不平衡树，规则越多则判定路径越长，寻果越慢，反之越快，极端情况退化成单向链表O(N)※ 适用场景适合多级条件判断，前后有顺序依赖判定场景2、决策表映射...

【实战总结】分布式任务交替协作

问题背景我们一般分库分表的路由字段是用户的账户ID（userId），有些业务场景外部不以此做业务，而是以业务请求ID等进行业务交互所以我们内部系统通过userId来串联业务关系，但是与外部交互要使用到bizId等这些代表业务唯一性的字段，这两个字段不同路由可能会打到不同的库是没办法做数据库事务处理的出现这些场景时的一个需要解决的问题是，按照userId路由字段落库了，但是外部服务交互只有bizId没有userId，导致无法通过bizId反查userId路由到内部的业务数据。常见的解决方.

最近在做一个模糊地址查询的需求，剖析需求本质无非就是提供接口入参

使用地图经纬度及范围查询坐标点信息的场景，在现实开发中还是有很多机会遇到的，比如地图导航类应用计算两点之间的距离及范围、大众点评美团等点餐按照买家和商家的坐标点进行计算距离，等等。最近在项目中的一个需求和以上问题类似，需要按照用户的地图坐标经纬度查询一定范围内的商户信息。静下心来思考下，把问题拆解分析下就是，已知一个坐标点，按照距离求设定范围的所有坐标点集合。1、知识准备计算两点之间的...