2020年08月_DatDreamer

原创 secKill项目 --- 总结 + 推荐阅读顺序 + 源码地址

先上源码地址：https://github.com/HermanCho/seckill项目总结本项目基于慕课网的秒杀项目，源代码的参考很多来源于以下博客商城秒杀系统改进的地方：（主要是前两个）消息可靠性传输的实现，包括投递、持久化、消费 + 幂等性， 3 + 1 的实现redis预减库存的库存补充方案改进了 @AccessLimit的使用整合了log4j2，方便维护进行了springboot版本升级整合。源项目的版本太低，导致rabbitMQ很多问题，踩

2020-08-15 12:03:03 3370 1

原创 Redis分布式锁的注意点总结 + 参考代码

推荐阅读:Redis分布式锁的正确实现方式介绍直接说重点：setnx命令，key自然是锁名。value是requestId，即请求标识，能够区分不同的客户端，保证锁只能由加锁的客户端释放expireTime 直接作为setnx的参数，而不是单独的设置过期时间，保证原子性释放锁时，判断value是否相等，然后再释放锁。但**关键是用lua脚本，保证原子性**因为文章里都讲得很好很清楚，我就不赘述了。感叹一下在实际做项目前，准备面试点，只理解到setnx一同设置过期时间，还觉得这个问题很简单

2020-08-15 11:31:37 588

原创 secKill项目 --- 限制同一用户只有一个请求生效 + 回补Redis库存如何反馈到内存标识的思考（有库存，买不到）

完成了redis的库存的补充，redis库存和数据库库存，现在已经可以保证最终一致性了。但这并不等同于项目的正确性。先来回顾一下秒杀控制器的逻辑（核心部分源代码，其余伪代码。）此处已实现库存补偿篇所说的优化：先检查重复秒杀，再预减库存 @RequestMapping(value="/{path}/do_miaosha",method=RequestMethod.POST) @ResponseBody public Result<Integer> doMiaosha() {

2020-08-15 11:14:48 962

原创 secKill项目 --- Redis预减库存的存在的问题及库存补偿

本文建立在已完成可靠性传输的基础上，建议先阅读另一篇博文，不然可能难以理解。点击跳转先看看秒杀接口的源代码: @RequestMapping(value="/{path}/do_miaosha",method=RequestMethod.POST) @ResponseBody public Result<Integer> doMiaosha(Model model,MiaoshaUser user, @RequestParam(value="goodsId",defaultVal

2020-08-14 23:25:41 3313 1

原创 secKill项目 --- 可靠性传输的实现及易错点总结

本文只讨论可靠性传输相关的问题，预减库存的问题在另一篇博客：如何实现消息的可靠性传输，已在其他两篇博文中总结了，此处不赘述RabbitMQ实现可靠性传输理论篇RabbitMQ实现可靠性传输代码篇这里记录一下易错的，需要注意的点：消息的唯一ID是需要手动分配的，消息的持久化也是需要额外做的。两者都需要通过MessagePostProcessor完成限制重发次数交由定时任务完成。重发需要注意的点：超出限制后，记得移除redis中的相关key，并入库记录重发时，消息的co

2020-08-14 15:04:05 1415 1

原创 RabbitMQ实现可靠性传输代码篇

本文为代码篇，建议先看理论篇，点击跳转实现可靠性传输的理论篇对应的实操代码。业务相关的都用了伪代码，方便理解。环境：springboot 2.1.9.RELEASE + amqp-client-5.4.3.jar生产者确认模式application.propertiesspring.rabbitmq.publisher-confirms=true主动分配唯一Id：(这里其实需要预处理器MessagePostProcessor，在持久化的内容中有讲)public void sendMe

2020-08-13 23:23:35 690

原创 RabbitMQ实现可靠性传输理论篇

本文为理论版，另有代码版：本文内容是在参考了大量资料的同时，自己实操得出来的结论。笔者代码环境:springboot 2.1.9.RELEASE + amqp-client-5.4.3.jar如图所述，需要从三个方面解决问题:生产端，MQBroker，消费端。文章目录生产者确认模式如何保证投递成功无法被路由的消息处理如何持久化消息队列如何保证消费成功（或限流处理）生产者确认模式定义：当消息确认到达Broker后回调，(即只确认是否正确到达 Exchange 中)，broker会发送一

2020-08-13 23:19:35 695

原创需要根据异常，进行相关处理代码应该放MVC哪一层的思考

当需要根据异常进行处理，但同时也希望service回滚事务时。笔者之前的做法一直都是service层进行操作try{...}catch(xxxException e){相关处理throw e}但这个其实是不对的，常见于 controller层调用service层，应该把相关处理做法放到controller层。原因：对service来说，你是希望它回滚的，catch再抛就有点冗余。controller层本就应该处理异常，需要返回错误信息给应用人员。更本质的是，这个相关处理很多时候是与

2020-08-13 12:04:16 399

原创 RabbitMQ 消费者确认auto 和 manual 模式对异常的处理区别（含重试、requeue的影响）

本文用于解答下述疑问：消息在下面四个条件的处理方式：两种模式是否有异常、是否捕获异常是否设置重试requeue为true / false ( + default-requeue-rejected的影响)看似是 2 4 种方案，让人头疼，但其实没那么复杂。总结中也会给出简洁的答案。文章目录正文auto自动确认manual人工确认default-requeue-rejected 属性导致死循环的情况总结正文本文环境： springboot 2.1.9.RELEASE + amqp-cli

2020-08-12 09:49:16 4789 2

原创 RabbitMQ 消费者如何获取生产者设置的correlationId + 得到CorrelationId为空的解决方案 + 源码解析

本文解决：RabbitMQ消息者如何获取生产者设置的correlationId获取到的CorrelationId为空本文环境：springboot 2.1.9.RELEASE + amqp-client-5.4.3.jar本文分两部分，第一部分先直接给代码实现，第二部分进行原理解析。实现代码交换机、路由那些就自己改吧，附上全部代码很累赘，只说关键点注册一个bean@Beanpublic MessagePostProcessor correlationIdProcesso

2020-08-11 09:28:53 6074

原创 RabbitMQ，消费者获取correlationId或correlationIdString均为null的解决方案 + 源码层面解析

请留步找这个问题的，估计很多人都是找的资料都是一样的，多个抄袭的网站都是下图的答案。但实际操作就发现，这个代码是不全的，比如：this.buildMessage(content,correlationId.getId())，这个方法就是没附上的。直接黑人问号。先下个结论：按照该网站的做法，还是无法解决问题本文环境：springboot 1.5.8.RELEASE + amqp-client 4.0.3，后续版本可能修复。原本没有指定version，但2020.8.10，尝试用了最新版本的amq

2020-08-10 16:29:39 2890

原创 RabbitMQ---重新投递到不存在的exchange 导致MQ无法提供服务

记一个很神奇的bug。场景：开启生产者确认模式，指定了自定义ConfirmCallback实现类。尝试投递到不存在的exchange，成功回调confim接口，随后再次重发该信息。但意外的是，不止没有回调confirm接口。还导致整个rabbitMQ卡死，发送消息到其他交换机一样无作用。原因：上述操作：“尝试投递到不存在的exchange”，会产生一个ERROR：ERROR org.springframework.amqp.rabbit.connection.CachingConnectionF

2020-08-09 18:54:27 1411 2

原创 log4j2 输出指定单一日志级别（不是该级别及其以上！！!）

只输出单一级别，而不是本级及以上的级别日志。直接上代码eg: 只输出WARN级别<File name="FileWarn" fileName="${FILE_PATH}/warn.log" append="false"> <Filters> <ThresholdFilter level="ERROR" onMatch="DENY" onMisma

2020-08-07 17:53:34 3143 1

原创 CAP原则“大总结“及单机集群redis的所属

本来觉得CAP原则挺简单的，但一搜网上一大堆，翻译的版本不一，对概念的解析也各不相同。甚至有种越看越蒙的感觉…因此分享下CAP原则的理解，主要指出了很多版本说法存在的问题。当然，这是个人理解，如果有错。欢迎各位指出。CAP原则一致性Consistency : 访问所有节点，得到结果一致。（特别是更新操作完成后)这里不采用"同一时刻"的说法，因为数据同步是需要时间的。关键是访问得到的数据一致可用性Availability :客户端访问集群中任意一个节点，系统能在有限的时间内给出非

2020-08-05 11:20:04 1508

原创生产者消费者模式模板总结

模板的核心：消费 / 生产方法上锁try{ while(...){ 等待 } 进行消费 / 生产通知}catch (InterruptedException e) { e.printStackTrace();} finally { 需要手动解锁，则释放锁}关键点：try{} 扩住整个逻辑，这是不会影响性能的。具体请百度了解。这样后续的finally，就可以在ReetrankLock等实现中，手动地释放锁，不需要则为空即可。不用担心忘

2020-08-04 15:40:46 284

Unknownfuture的博客