qq_38196449的博客

其实就是与输入法快捷键冲突了，一般用的最多的就是windows自带输入法和搜狗输入法，我们只需要把两个输入法的快捷键取消即可解决。

既可以约束前端传入的时间类型参数格式，也可以约束后端响应前端的时间类型格式；也就是说不光解决了你前端传参格式化的问题，后端返回给前端的Date类型也帮你格式化了。这两个注解是前后台日期类型字段交互的时候格式化的一个操作。字符串2024-09-24 10:20:00。只能约束前端入参时间类型的格式。比如后台实体类Dept有个。先说说这俩注解是干嘛的。这样就可以解决此问题了。

如果Eureka服务器在配置的时间间隔内未能从某个服务器实例收到心跳，它通常会将该实例从注册列表中移除，认为该实例不可用。然而，在自我保护模式下，如果Eureka服务器在短时间内丢失了对大量服务实例的心跳（15分钟超过85%的客户端），它会认为这是一个网络问题，而不是所有这些服务实例都突然不可用。Eureka的自我保护模式正是一种针对网络异常波动的安全保护措施，使用自我保护模式能使Eureka集群更加的健壮，稳定的运行。自我保护模式默认是开启的，因为它可以在网络不稳定的环境中提供更稳定的服务发现功能。

对于一个包含多个词汇的文档，倒排索引会将每个词汇作为一个关键字（Term），然后记录下该词汇所在的文档编号（Document ID）及该词汇在文档中的位置（Term Position）。这样，当用户输入一个关键字时，就可以快速地查找到包含该关键字的文档编号，然后通过文档编号再查找到对应的文档内容。倒排索引的结构与传统的索引结构相反，传统的索引结构是由文档构成的，每个文档包含了若干个词汇，然后根据这些词汇建立索引。而倒排索引是由词汇构成的，每个词汇对应了若干个文档，然后根据这些文档建立索引。

HTTP 短连接模型，每次客户端请求都会创建和销毁 TCP 连接，TCP 协议销毁的连接状态是 WAIT_TIME，完全释放还需要一定时间，当 TPS 和 QPS 较高时，服务器端和客户端可能有大量的 WAIT_TIME 状态连接，从而会导致 connect time out 错误或者 Cannot assign requested address 的问题。通过心跳续约，当服务机器上升时，特别是类似 Dubbo 的接口级服务较多时，心跳及配置元数据的轮询数量众多，导致集群 TPS 很高，系统资源压力较大。

充血模型（Domain Driven Design）是一种面向对象的软件设计方法，它强调将业务逻辑封装在领域对象中。假设有一个电商网站，需要对商品进行购买、库存管理等操作。在充血模型中，我们可以定义一个 Product 类来表示商品。Product 类会包含商品的属性（例如名称、价格、库存等），并且也会包含一些行为（例如购买商品、更新库存等）。这些行为是直接封装在 Product 类中的，以便于对商品进行操作。

QPS指的是系统每秒能处理的请求数量（Query Per Second），在Web应用中我们更关注的是Web应用每秒能处理的request数量。这个是衡量系统性能的重要指标。RT指的是响应时间（Response Time），是指从客户端发一个请求开始计时，到客户端接收到从服务器端返回的响应结果结束所经历的时间。

作为一个Java后台开发，我们写出的大部分代码都决定着用户的使用体验。如果我们的后端代码性能不好，那么用户在访问我们的网站时就要浪费一些时间等待服务器的响应。这可能导致用户投诉甚至用户的流失。关于性能优化是一个很大的话题。《Java程序性能优化》说性能优化包含五个层次：设计调优、代码调优、JVM调优、数据库调优、操作系统调优等。而每一个层次又包含很多方法论和最佳实践。本文不想大而广的概述这些内容。只是举几个常用的Java代码优化方案，读者看完之后可以真正的实践到自己代码中的方案。

可以让多个数据中心在不同地理位置提供相同的服务，并且能够实现数据的实时同步和故障切换。通常用于需要在全球范围内提供高可能性和低延迟的应用场景，例如在线游戏、社交媒体、金融交易等。异地多活架构需要考虑多个因素，例如数据同步和冲突解决、负载均衡和故障切换、安全性和隐私保护等。通常需要采用分布式数据库、消息队列、负载均衡器、DNS解析等技术来支持异地多活的实现架构。

举例：使用数据库备份工具在生产服务器上运行备份任务，而无需停机，以确保数据持续可用。就像我们通常做的数据库的主从同步，事实上就是热备的一种实现。综合来看，冷备、热备和暖备的选择应该根据不同的业务需求来综合考虑。一般而言，如果数据恢复时间并不要求特别及时，举例：一般是在某个应用程序的专属功能能快速大到限制外访问的情况下备份数据，以减轻备份操作对业务的影响。冷备、热备和暖备是备份和恢复方案中常见的术语，它们表示备份和恢复方案的不同类型和不同级别。举例：在深夜停机时备份整个数据库，在一个网站的低峰期备份数据库。

删除C盘下webstorm64.exe.vmoptions文件

客户端不应该依赖于它不需要的接口。一个类不应该强迫它的客户端依赖于它们不需要的方法。这要求我们要使用多个小的专门的接口，而不要使用一个大的接口。这要求我们写出的程序依赖于抽象接口，而不是具体的实现。任何一个父类出现的地方，都可以用它的子类来替代，而不会导致程序的错误或者异常。这个原则鼓励你将复杂系统分解为许多小的、相对独立的模块，模块之间的交互通过最少的接口进行。这意味着你应该通过扩展已有模块实现新的功能，而不是直接修改已有的代码。这个原则推崇对象组合和聚合的方式来构建复杂的对象系统，而不是依赖继承。

所以，SpringCloud就自己推出了Spring Cloud LoadBalancer来代替Ribbon，所以，在Spring Cloud 2020.0版本中，Ribbon已经被标记为过时，官方推荐使用Spring Cloud LoadBalancer。Spring Cloud LoadBalancer 默认提供了一些常见的负载均衡算法，例如轮询、随机等。LoadBalancer是Spring Cloud官方提供的负载均衡组件，可用于替代Ribbon。在上面的示例中，在调用。

准备一个linux服务（CentOS或者Ubuntu均可）安装并配置JDK上传Jar包运行jar包准备Linux运行环境（java项目并不需要完整的操作系统，仅仅是基础运行环境即可）安装并配置JDK拷贝jar包配置启动脚本上述步骤中的每一次操作其实都是在生产一些文件（系统运行环境、函数库、配置最终都是磁盘文件），所以镜像就是一堆文件的集合。由于制作镜像的过程中，需要逐层处理和打包，比较复杂，所以Docker就提供了自动打包镜像的功能。

首先打开。

一开始new ArrayList(); 底层创建容量为0的数组，当我们add()第一个元素时，触发第一次扩容，将容量0变为10，当数组容量存满10个，add()第11个元素时触发第二次扩容，扩容为原理的1.5倍，也就是15。当我们add()到第16个元素，触发第三次扩容

将应用程序分为三个部分，分别是模型（Model）、视图（View）和控制器（Controller），它们之间通过定义清晰的接口进行交互。这种模式可以将业务逻辑与用户界面分离，使得应用程序更容易维护和优化。将对象之间的一对多的依赖关系封装起来，当一个对象发生改变时，它的所有依赖者都会得到通知并自动更新。这种模式可以减少对象之间的耦合度，使得系统更加灵活和易于维护。动态地给一个对象添加一些额外的职责，而不需要修改这个对象的代码。这种模式可以保持对象的功能扩展性更好且更具灵活性。

Feign是Spring Cloud中的一个声明式的HTTP客户端库，用于简化编写基于HTTP的服务调用代码。但是从Spring Cloud 2020版本开始，官方宣布Feign将不再维护和支持，推荐使用OpenFeign作为替代方案。但是，随着SpringCloud 2022的发布，官方宣布OpenFeign将被视为功能完整。这意味着Spring Cloud团队将不再向模块添加新特性。只会修复bug和安全问题。

SpringBoot自带的定时任务非常简单操作，其实就是一个@Scheduled注解。我们发现每隔5s打印，实现定时任务整合。

在分库分表的过程中，我们需要有一个字段用来进行分表，比如按照用户分表、按照时间分表、按照地区分表。这里面的用户、时间、地区就是所谓的分表字段。那么，比如说我们要对交易订单进行分表的时候，我们可以选择的信息有很多，比如买家Id、卖家Id、订单号、时间、地区等等，具体应该如何选择呢？通常，如果没有特殊的诉求，比如按照月度汇总、地区汇总等以外，我们通常建议大家按照买家Id进行分表。因为这样可以避免一个关键的问题那就是——数据倾斜（热点数据）。

在我们做了分库分表之后，数据会散落在不同的数据库中，这时候在需要进行跨库或跨表的JOIN操作时，就会比较麻烦。如果数据被分表后，分散在不同的数据库上面，那么标准的join是要在单库内执行的，所以这就会带来复杂性。还有就是不同的库可能在不同的服务器上面，那么一次join就需要和多个数据库交互，那就会有更多的网络延迟，带来性能问题。而且，有的时候一次join可能并不是2个库，而可能是多个库，比如订单和用户join，我们要查的用户可能散布在很多个库中，那么一次join就会横跨很多库。那么如何解决呢？

数据倾斜是指在分布式计算或数据库环境中，数据分布不均匀的现象。在理想的分布式系统中，数据和计算负载应该均匀分布在所有节点上。然而，由于各种原因，某些节点可能承载比其他节点更多的数据或计算负载，这就是数据倾斜。比如一个系统中共有500万数据，但是属于同一个商家的数据就有400万，那么如果数据库按照商家做分库分表，就会导致出现严重的数据倾斜。一般来说，数据倾斜发生在分库分表的场景中比较多，因为主要是因为分表字段选择的不够合适导致的。你比如说我之前做过一个定价系统，然后我们是按照付款方做的分库分表。

当HashMap中的元素个数超过数组长度 * 负载因子0.75时，就会进行数组扩容，也就是说，默认情况下，数组大小为16，那么当HashMap中的元素个数超过16 X 0.75 = 12的时候，就把数组的大小扩展为2 X 16 = 32，即扩大一倍，然后重新计算每个元素在数组中的位置，而这是一个非常耗性能的操作，所以如果我们已经预知HashMap元素的个数，就能有效的提高HashMap的性能。因为2的n次幂时哈希的分布性不是很好，所以二次hash为了让我们的数据分布的更加均匀一些，防止链表过长。

Big Key是Redis中存储了大量的数据的Key，不要误以为big key只是表示Key的值很大，他还包括这个Key对应的value占用空间很多的情况，通常在String、list、hash、set、zset等类型中出现的问题比较多。其中String类型就是字符串的值比较大，其他几个类型就是其中元素过多的情况。对于Big Key问题的处理，重点要在识别和解决上面。

（1）mybatis是支持定制化SQL、存储过程以及高级映射的优秀的持久层框架。（2）mybatis避免了几乎所有的JDBC代码（说明了mybatis底层用的就是JDBC，只不过是封装了）和手动设置参数以及获取结果集。（3）mybatis可以使用简单的XML或注解用于配置和原始映射，将接口和Java的pojo映射成数据库中的记录。

（1）mapper中定义接口/*** 根据年龄查询用户列表，分页显示* @param page 分页对象,xml中可以从里面进行取值,传递参数 Page 即自动分页,必须放在第一位* @param age 年龄* @return*/（2）mapper.xml实现--SQL片段，记录基础字段-->（3）调用接口@Test// 设置分页参数// 获取分页数据System.out.println("当前页："+page.getCurrent());

Spring Cloud 是基于 Spring Boot 和 Spring Framework 构建的，编程模型与通信协议绑定 HTTP，而 Dubbo 则是基于 Java 的 RPC 框架实现的（Dubbo 也支持 HTTP 协议，但是主要还是以 Dubbo 协议为主）。Spring Cloud 和 Dubbo 都是为了简化分布式系统开发而设计的开源框架，Dubbo 和 Spring Cloud 都侧重于对分布式系统中常见问题模式的抽象（如服务发现、负载均衡、动态配置等）

当不让使用redis分布式锁，或者集群不可用的时候，如何做到防止用户重复点击的功能呢？

根据测算，Redis将所有数据放在内存中，内存的响应时长大约为100纳秒，对于小数据包，Redis服务器可以处理80,000到100,000 QPS，这么高的对于80%的公司来说，单线程的Redis已经足够使用了。虽然现在很多服务器配备多个CPU核的，但是对于Redis来说，因为使用了单线程，在一次数据操作的过程中，有大量的CPU时间是用来耗在了网络IO的同步处理上的，并没有充分的发挥出多核的优势。但是，Redis的多IO线程只是用来处理网络请求的，对于读写命令，Redis仍然使用单线程来处理。

Lua是一种轻量小巧的脚本语言，用标准C语言编写并以源代码形式开放，其设计目的是为了嵌入应用程序中，从而为应用程序提供灵活的扩展和定制功能。它提供了非常易使用的语法，大量的库，以及可移植性，可以用于开发各种各样的应用。Lua是一种高效、轻便、可扩展的脚本语言。它具有语法简洁、操作易学，支持数据结构定义，支持函数式编程，支持面向对象编程，在功能上可以完全取代Shell、Perl，而在轻便性和可扩展性上又具有极大的优势。

假设，我们有两张表，分别是订单表和商品项表，一个订单中可以关联多个商品项。当我们从数据库中查询Order的时候，如果同时把关联的Item都返回，这就不是延迟加载，如果在后面真正用到Item的时候再调用加载，这就是延迟加载。延迟加载的主要原理是在当开启了延迟加载功能时，当查询主对象时，MyBatis会生成一个，并将代理对象返回给调用者。当后面需要访问这些关联对象时，代理对象会检查关联对象是否已加载。如果未加载，则触发额外的查询。

不过我还是比较倾向作者的观点，尽量不要minimumIdle，允许HikariCP充当固定大小的连接池，毕竟我相信追求极致的Hikari一定可以尽最大努力快速高效地添加其他连接，从而获得最佳性能和响应尖峰需求。而且作者的意思很明确，设置固定大小的连接数量肯定是没什么问题的，因为毕竟我们的系统也不太会出现长时间闲置的情况，也就是长时间系统0访问，哪怕是凌晨网站也会有用户的请求。比如你服务器是4核，最大连接数可以设置为10，如果是8核，可以设置为20。

虽然正向代理服务器和反向代理服务器所处的位置都是客户端和真实服务器之间，所做的事情也都是把客户端的请求转发给服务器，再把服务器的响应转发给客户端，但是二者之间还是有一定的差异的。对于常用的场景，就是在Web开发中用到的负载均衡服务器，客户端发送请提到负载均衡服务器上，负载均衡服务器再把请求转发给一台真正的服务器来执行，再把执行结果返回给客户端。4、正向代理和反向代理的作用和目的不同。通过反向代理服务器访问目标服务器时，客户端是不知道真正的目标服务器是谁的，甚至不知道自己访问的是一个代理。

在电商、支付等系统中，一般都是先创建订单（支付单），再给用户一定的时间进行支付，如果没有按时支付的话，就需要把之前的订单（支付单）取消掉。这种类似的场景有很多，还有比如到期自动收货、超时自动退款、下单后自动发送短信等等都是类似的问题。Redisson > RabbitMQ插件 > RabbitMQ死信队列 > RocketMQ延迟消息 ≈ Redis的zset > Redis过期监听 ≈ kafka时间轮 > 定时任务 > Netty的时间轮 > JDK自带的DelayQueue > 被动关闭。

1.1 什么是Spring？spring的核心实现思想IOC，由spring来负责控制对象的生命周期和对象间的关系。注意以前对于一个类型(类)，手动的使用new来实例化这个对象变量，现在不用你new了，交给spring控制。在传统的开发中，在一个类定义另一个类的实例，这样的话，互相依赖，耦合在一起。spring的思想是两个类是独立的，用的时候在往里放，即轻松解耦。1.2 spring优点有哪些？可以从四个方面来答，解耦、切面、方便集成各种优秀框架、一站式。

Spring的事务传播机制用于控制在多个事务方法相互调用时事务的行为。在复杂的业务场景中，多个事务方法之间的调用可能会导致事务的一致性，如出现数据丢失、重复提交等问题，使用事务传播机制可以避免这些问题的发生，保证事务的一致性和完整性。Spring的事务规定了7种事务的传播级别，默认的传播机制是。

这样直接写值不太好，我们应该创建个枚举类来封装一下。这样写是不是好多了？

总的来说，这些消息中间件都有自己的优缺点，选择哪一种取决于具体的业务需求和系统架构。

所谓脑裂，就像他的名字一样，大脑裂开了，一般来说就是指一个分布式系统中有两个子集，然后每个子集都有一个自己的大脑(Leader/Master)。那么整个分布式系统中就会存在多个大脑了，而且每个人都认为自己是正常的，从而导致数据不一致或重复写入等问题。

限流的是控制系统的并发流量，通过限制请求流量的手段防止过度的流量导致系统崩溃。一般用于应对突发流量高峰。一般是被调用方对调用方进行限流。举个例子，我提供了一个查询用户信息服务，给集团内外的很多调用方使用，但是我为了保证我的可用性，我会对每个调用方做限流，防止某个月调用方不守规矩，把我的服务打挂了。