彩虹马的博客

开发类 名称 地址 Jetbrains激活 https://ckey.run/ jrebel激活 https://www.jpy.wang/page/jrebel.html 23种设计模式 https://refactoringguru.cn/design-patterns 手册类 名称 地址 Elasticsearch中文文档 https://doc.codingdict.com/elasticsearch/323/ Elasticsearch中文文档 https://learnku.com/docs/elasticsearch73/7.3 工具类 名称 地址 青龙面板 https://github.com/whyour/qinglong AutoHotkey https://www.autohotkey.com 数据库建模工具PDManer https://gitee.com/robergroup/pdmaner 站长素材 http://sc.chinaz.com/moban 网站模板 https://www.fre ...

引言在Spring框架中，针对Bean之间的循环依赖，Spring通过三级缓存的机制已经解决和规避了部分场景Bean的循环依赖。但是仍需了解Spring解决循环依赖的原理和注意Spring无法解决循环依赖的场景，避免出现此类问题。 循环依赖示例12345678910111213@Servicepublic class AServiceImpl implements AService { @Autowired private BService bService;}@Servicepublic class BServiceImpl implements BService{ @Autowired private AService aService;} 这个例子是非常经典的Spring Bean循环依赖的场景，在这种循环依赖场景，Spring已经帮我们解决了循环依赖的问题，所以服务可以正常启动和运行。 Spring循环依赖的场景构造器注入12345678910111213141516171819@Servicepublic cl ...

引言零拷贝(Zero-Copy)技术指在计算机执行操作时，CPU不需要先将数据从一个内存区域复制到另一个内存区域，从而可以减少上下文切换以及CPU的拷贝时间。作用是在数据从网络设备到用户程序空间传递的过程中，减少数据拷贝次数，减少系统调用，实现CPU的零参与，消除CPU在这方面的负载。 零拷贝思想零拷贝是一个通过尽量避免拷贝操作来缓解CPU压力的解决方案。Linux下常见的零拷贝技术可以分为两大类：一是针对特定场景，去掉不必要的拷贝；二是去优化整个拷贝的过程。零拷贝并没有真正做到“0”拷贝，它更多是一种思想，很多的零拷贝技术都是基于这个思想去做的优化。 原始数据拷贝 传统数据拷贝产生了四次数据拷贝，即使使用了DMA(Direct Memory Access)处理了硬件的通讯，CPU仍然需要处理两次数据拷贝。同时，CPU在用户态和内核态也发生了多次上下文切换，增加了CPU的负担。在此过程中，如果没有对数据做任何修改，那么在内核态和用户态间来回拷贝数据就是一种浪费。 零拷贝的几种方法用户态直接IO 对于这种数据传输方式来说，应用程序可以直接访问硬件存储，操作系统内核只是辅助数据传输。这 ...

客服系统服务中使用Servlet3.0异步长轮训，服务压力大时，导致消息错乱。 描述对Servlet请求应答对象的生命周期理解不够深入，IM服务在服务压力大，并且Nginx断开请求回收资源后，依然将用户消息进行下发，最后导致消息下发到其他请求中。 原因分析错误代码伪代码服务使用异步的Servlet方法进行长轮训 123456789101112131415161718192021@WebServlet(asyncSupported = true)public class CometServlet extends HttpServlet { @Override protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { //启动异步请求 AsyncContext context = request.startAsync(); //设置超时 ...

引言在MQ中，Producer和Consumer因为各种原因会进行消息重试处理，在消费消息时，会按照一定规则推送消息到消费端进行消息消费。既然有重试，那么就少不了幂等。 幂等概念在消息重试多次时，消费端对该重复消息消费多次与消费一次的结果是相同的，并且多次消费没有对系统产生副作用，那么就称这个过程是消息幂等的。 例如：支付场景下，消费者消费扣款消息，对一笔订单进行扣款操作，该扣款操作需要扣除10元。 这个扣款操作重复多次与执行一次的效果相同，只进行一次真实扣款，用户的扣款记录中对应该笔订单的只有一条扣款流水。不会多扣。那么可以说这个扣款操作是符合要求的，这个消费过程是消息幂等的。 消息幂等的场景Producer发送消息重复​ 生产者发送消息时，消息成功投递到broker，但此时发生网络闪断或者生产者down掉，导致broker发送ACK失败。此时生产者由于未能收到消息发送响应，认为发送失败，因此尝试重新发送消息到broker。当消息发送成功后，在broker中就会存在两条相同内容的消息，最终消费者会拉取到两条内容一样并且Message ID也相同的消息，因此造成了消息 ...

引言项目中遇到一个问题，由于后台数据库表ID使用分布式唯一算法生成的Long类型(19位数字)，导致转成json传至前端js使用时报错，因为js的数字类型最大只能表示15位数字长度【JavaScript Number 对象】。 解决方案：使用Spring自定义Json序列化方式，将过长的Long类型转成String类型。 默认序列化配置默认序列化方式会将Long类型不做转换，直接传递给前端。 1234567891011121314151617<mvc:annotation-driven> <mvc:message-converters> <bean class="org.springframework.http.converter.StringHttpMessageConverter"> <constructor-arg ref="utf8charset"/> <property name=&q ...

引言由于MQ经常处于复杂的分布式系统中，考虑网络波动、服务宕机、程序异常因素，很有可能出现消息发送或者消费失败的问题。因此，消息的重试就是所有MQ中间件必须考虑到的一个关键点。如果没有消息重试，就可能产生消息丢失的问题，可能对系统产生很大的影响。 Consumer重试重试条件在RocketMQ中，只有当消费模式为MessageModel.CLUSTERING(集群模式)时，Broker才会自动进行重试，对于MessageModel.BROADCASTING(广播消息)是不会重试的。集群模式下，当消息消费失败时，RMQ会通过消息重试机制重新投递消息，努力使该消息消费成功。对于一直无法消费成功的消息，RMQ会在达到最大重试次数之后，将该消息投递至死信队列。然后我们可以关注死信队列DLQ(Dead Letter Queue)，并对该死信消息业务做人工补偿操作。 当消费者消费该重试消息后，需要返回结果给broker，告知broker消费成功(ConsumeConcurrentlyStatus.CONSUME_SUCCESS)或者需要重新消费(ConsumeConcurrentlyStatus ...

引言Logback日志输出使用 AsyncAppender 时，输出的文件行号信息是 ?:? ，问题产生原因及解决方案。 问题在 logback推荐配置 一文中，列举了logback常用的几种配置，使用的是logback异步输出日志AsyncAppender。但在实际的开发中，遇到了日志没有输出类和行号，而输出的文件行号信息是 **?:?**。 输出的日志类似于这种： 12345678framework-server-demo 2017-07-17 14:15:11,876 INFO [main] o.s.j.e.a.AnnotationMBeanExporter [?:?] - Located managed bean 'refreshScope': registering with JMX server as MBean [org.springframework.cloud.context.scope.refresh:name=refreshScope,type=RefreshScope]framework-server-demo 2017-07-17 14:1 ...