WannaRunning的博客

分布式任务调度-分片模式如果数据来源于数据库等稳定的数据源，这种情况下数据量分散的逻辑比较好实现。可以使用分布式任务调度中的分片模式，把批处理均衡的分散到各个机器节点去执行，每个机器的任务调度只处理一部分数据，通过这种方式提高了资源使用效率而且缩短了任务处理是耗时。但是如果批处理的数据来源于外部接口,分片处理的业务逻辑就不太好实现，这种情况下如何分散处理呢？单节点收集数据+MQ队列分散执行任务任务job中只收集要处理的数据，然后通过MQ中转，通过MQ集群消费模式把数据处理分散到集群中的

什么环节占用库存通常在提交订单时占用库存较为合理。 如果再提交订单之后，支付前占用库存就会出现库存不足支付失败的情况，在用户体验上明显不合理。库存占用功能设计思路redis + mq + mysql 实现高并发减库存操。把商品的可售卖库存做缓存例如Redis，在提交订单时基于Redis缓存的可售卖库存做库存是否充足的校验和减库存操作，然后通过发送MQ即异步的方式在消费端执行数据库中得减库存操作。根据订单中商品数量扣减redis中缓存的可售卖库存，扣减时如果没有缓存则回源DB查询门店.

ShardingSphere中的sharding-jdbc可以支持单主库、多从库的主从架构来完成分片环境下的读写分离，暂时不支持多主库的应用场景。读请求-负载均衡在数据库主从集群中从库一般会有多台,所以sharding-jdbc默认提供了随机（Random）和轮询（RoundRobin）这两种负载均衡算法。读请求-主库强制路由另一方面，由于主库和从库之间存在一定的同步时延和数据不一致情况，所以在有些场景下，我们可能更希望从主库中获取最新数据。ShardingSphere同样考虑到了这方面需求

目录如何确定分库还是分表分库分表的拆分方式垂直拆分水平拆分水平拆分的实现方式哈希分片范围分片(range)在写请求多的情况下,常见的方案就是分库分表,但是具体是分库还是分表要结合实际场景决定。如何确定分库还是分表分库分表使用的场景不一样:分表是因为数据量比较大，导致事务执行缓慢；分库是因为单库的性能无法满足要求。当数据库中表数据量过大造成事务执行缓慢时,就要考虑分表。注意是事务查询或更新等操作,因为减少每次查询数据总量是解决数据查询或更新缓慢的主要原因。 为了

商品SKU模型在我们的系统中，产品的配置通常都是一个SKU一个菜品标签，这种通常情况下SKU数量和最终拆单后的制作单项数量比值为1:1,也就是一个SKU（一个菜品），生成一个制作单。但是还有一些特殊的产品配置是N个数量的菜品即N个SKU做为一个SPU售卖,这种情况sku和制作单比值为N:1,也就是N个SKU（N个菜品）对应生成一个制作单。履约制作单拆分设计订单接单后会对应每个订单拆分创建制作单，制作单拆单设计中是以sku为最小粒度拆分为一个制作单项,同一个sku点了N份就对应N个制作单项。例

看了架构设计的一节课，结合实际写一下并发库存扣减功能设计的优化点。之前写过基于Redis扣减+MQ异步写库的实现方式，这种实现相对于同步数据库操作大大提升了并发性能。但是随之带来的就是一些不可靠性，比如Redis与数据库是异步的数据同步过程中可能会丢数据，还有Redis本身不支持ACID一旦宕机也会导致数据不同步问题。课程中介绍的实现其实是Redis和数据库同步操作，借助于数据库事务的回滚功能解决缓存与数据库之间数据不同步的问题。可能会有疑问，使用Redis不就是因为数据库并发读写性能差么？

首先二者都是线程安全的队列。LinkedBlockingQueueLinkedBlockingQueue是阻塞队列,其阻塞是基于ReentrantLock锁机制实现的。阻塞队列中元素的存取是支持阻塞的。当队列为空时，获取元素方法会阻塞等待有元素存入后再获取元素返回;如果队列设置了大小,队列满时无法存放，存放元素方法会阻塞等待有空位时再存放。offer()基于ReentrantLock锁机制存放元素,该方法是阻塞的,如果queue设置了大小且当前已经满了,则方法会阻塞等待有空位置是存放元素

SpringMVC的异步请求模式是Spring3.2就推出了，它是基于基Servlet3.0规范实现的，而此规范是2011年推出的，距现在已经有近10的历史了，可谓是非常非常成熟的一种技术规范了。SpringMVC的异步与同步的区别之前有写过关于对tomcat处理HTTP请求的理解的文章。提到tomcat中合理配置maxThreads参数（请求处理线程的最大数量）可以提高tomcat性能。但是当maxThreads参数因为CPU等条件限制到达最佳数值不能再增加时，提高单个线程的处理请求的速度又.

履约系统上游是订单支付操作完成,履约流程从支付完成后创建制作单,接单制作,制作完成,出餐配送一系列流程节点,还包括制作单取消(制作单创建但未接单制作),退货(制作中)等异常流程节点。制作单创建考虑高峰期存在订单量激增的情况,订单支付到履约单创建环节的通信使用MQ消息+定时任务pull做兜底方案实现支付后创建履约单的流程操作。接收到MQ消息,创建制作单入库(状态与订单同步为待商家接单状态),以门店维度按支付完成时间排序基于Redis的zset结构保存制作单号,同时以门店维度基于Hash结构保存制

JDK中java.util.concurrent包下的DelayQueue是基于过期时间段实现可延迟消费的目的。DelayQueue内部基于可排序的PriorityQueue优先队列来实现的,但是PriorityQueue本身是非线程安全的,所以DelayQueue在实现上通过加ReentrantLock的方式保证线程安全,同时出队和入队都是使用的同一把锁，所以出入队操作不能同时执行。消息入队public class DelayQueue<E extends Delayed> e.

目录改进思路履约系统新的设计方案创建制作单后加入待接单延迟队列延迟队列消费实现自动接单制作中状态流转在之前写的第一篇履约系统设计里，方案中关于履约单的整个生命周期即从创建制作单到接单和制作中的流转都是基于Redis存储和Redis操作实现的，功能是完整的，但是从服务运行监测的效果来看存在一些隐患问题。1.下单高峰期会明显导致Redis的并发显著上升，压测时甚至会导致Redis服务的延迟。2.虽然制作单处理是基于任务调度分片的，但是整个系统中每个制作单从创建到完成整合生命周.

业务场景顾客在门店点餐后，需要打印餐品小票。打印数据服务接口功能设计服务需要提供一个接口，功能是通过指定的设备ID信息查询设备下等待打印的餐品信息。如果前端设备与数据服务接口使用基于接单动作触发调用的方案进行数据的拉取，那高峰期订单量骤增会导致该数据接口的并发随之骤增，显然这种方式是不可行的。那另一种方案就是去前端设备使用主动轮训的方式调用数据服务接口，这样就可以有效避免并发带来的系统压力，这种方案是可行的。但是大部分时间都处于非用餐高峰期，从优化的角度来看的话主动轮询的方式在大部分时间是存

背景按门店分类存储订单信息，维护在一个ConcurrentHashMap<String，ConcurrentLinkedQueue>的结构中,实际业务中存在并发。所以功能的实现要考虑从map结构中取值操作关于value的非空判断和初始化操作的并发安全问题。功能实现可以忽略从Map取出ConcurrentLinkedQueue队里和往队列放订单这两步操作的原子性,业务中允许订单顺序存在一定误差。第一版代码实现之前有文章写过ConcurrentHashMap并发场景下的使用方式，可以

目录背景PathChildrenCachePathChildrenCache的start(StartMode mode)方法子节点监听实现之前一篇文章写了ZK客户端自我监听可以实现连接断开后尝试自动重连的机制。这篇文章写一下ZK中子节点变化的监听。背景在履约系统设计中使用基于本地服务内存存储的延迟队列，依赖于服务本身的内存所以存在宕机丢失数据的问题。所以在设计中数据的更新是与DB同步的，宕机后可以从DB中重新筛选未处理的数据，但是需要及时感知服务宕机并及时筛选出没处理完的数据。.