1、 SQL调优的基本步骤如下：
- 确认性能瓶颈：首先要确定数据库中哪些查询是慢的，哪些查询最需要优化。可以通过监控数据库的CPU、磁盘I/O、网络I/O、缓存等指标来确定性能瓶颈。
- 优化查询语句：如果查询语句本身存在问题，例如使用了不必要的子查询、重复的连接操作等，就需要对查询语句进行优化。
- 优化索引：索引是提高查询性能的关键因素之一。可以通过创建、修改、删除索引来优化查询性能。
- 优化数据结构：如果数据库中的表结构存在问题，例如表设计不合理、字段类型选择不当等，就需要对数据结构进行优化。
- 优化系统参数：系统参数对数据库性能也有很大的影响，可以通过调整系统参数来优化数据库性能。
- 测试优化效果：对于每一次优化操作，都需要进行测试验证，以确保优化操作能够真正提高数据库的性能。
spring cloud
Spring Cloud是一个构建分布式系统的框架，它为开发人员提供了一系列的组件和工具，用于快速搭建云原生应用、微服务和微服务架构。
以下是一些常用的Spring Cloud组件：
- Spring Cloud Netflix：Netflix是Spring Cloud中最重要的组件之一，它包括多个子项目，如Eureka、Hystrix、Zuul等。Eureka是一种服务注册和发现组件，Hystrix是一种容错和延迟处理工具，Zuul是一种网关组件，用于处理请求路由、过滤等。
- Spring Cloud Config：Config是一种分布式配置管理工具，它提供了集中式的配置管理服务，可以将应用的配置信息存储在远程仓库中，并将其分发到不同的应用中。
- Spring Cloud Stream：Stream是一种消息驱动的微服务框架，它提供了一套简单的编程模型，用于构建可扩展的事件驱动的微服务。
- Spring Cloud Data Flow：Data Flow是一种数据集成和工作流编排工具，它提供了一种可视化的方式来组合和编排各种批处理和实时数据处理任务。
- Spring Cloud Security：Security是一种安全框架，用于处理各种安全问题，例如身份验证、授权等。
- Spring Cloud Sleuth：Sleuth是一种分布式跟踪工具，它用于跟踪和记录微服务之间的请求和响应。
除了上述组件外，Spring Cloud还有很多其他的组件，如Spring Cloud Bus、Spring Cloud Consul、Spring Cloud Kubernetes等。开发人员可以根据自己的需求选择适合的组件来构建分布式系统。
基本功
- 面向对象的特征
1. 封装（Encapsulation）：封装是一种将数据和方法组合在一起的机制，通过这种机制可以限制外部访问对象的内部数据和方法。封装可以保护数据的安全性，防止非法访问和修改数据。
2. 继承（Inheritance）：继承是一种通过现有类创建新类的机制，新类可以继承现有类的属性和方法，并可以添加自己的属性和方法。继承可以实现代码的重用，减少代码的重复。
3. 多态（Polymorphism）：多态是一种对象的属性，它指的是同一个方法在不同的对象上具有不同的实现方式。多态可以使代码更加灵活，增强代码的可扩展性和可维护性。
4. 抽象（Abstraction）：抽象是一种将对象的共同特征提取出来形成类的机制，通过抽象可以将对象的共性和个性分离，从而实现代码的复用性和可扩展性。
- final, finally, finalize 的区别
final关键字：final可以用来修饰类、方法和变量。当用final修饰类时，表示这个类不能被继承；当用final修饰方法时，表示这个方法不能被重写；当用final修饰变量时，表示这个变量的值不能被修改。final关键字主要用于声明不变量，以提高程序的健壮性和安全性。
finally关键字：finally是一个Java中的关键字，它通常与try-catch语句一起使用。finally块中的代码会在try或catch块中的代码执行完毕后执行，无论是否抛出异常。finally块通常用来释放资源或进行一些清理操作。
finalize方法：finalize是Object类中的一个方法，它是Java虚拟机用来回收对象的一种机制。当一个对象不再被引用时，Java虚拟机会自动调用该对象的finalize方法进行垃圾回收。在finalize方法中，可以进行对象的清理和资源的释放等操作。但是，由于finalize方法的调用时机不确定，所以不建议在该方法中进行重要的操作，也不建议过多地依赖该方法来进行资源的释放。
- int 和 Integer 有什么区别
int和Integer是Java中两种不同的数据类型，它们的主要区别如下：
int是Java的一种基本数据类型，而Integer是Java中的一个类，它是int类型的包装类。
int在内存中占用4个字节，表示范围是-2^31 ~ 2^31-1；而Integer类是一个对象，它在内存中占用8个字节（64位JVM），并且还要存储一些额外的信息，因此比int类型占用更多的内存空间。
int类型的变量可以直接进行数值运算，而Integer类型的变量需要先进行自动拆箱（即将Integer类型转换为int类型），再进行数值运算。
int类型的变量可以直接进行比较，而Integer类型的变量需要通过equals方法进行比较。
int类型的变量可以直接赋值，而Integer类型的变量需要通过new关键字进行创建对象。
总之，int是一种基本数据类型，它的操作速度更快、占用内存更小；而Integer是一种对象类型，它可以使用面向对象的操作和方法，但是由于要存储一些额外的信息，因此占用的内存空间相对更大。在实际开发中，应该根据具体的需求选择使用哪种类型。
- 重载和重写的区别
重载指在同一个类中定义两个或以上的方法，它们具有相同的名称，但参数列表不同（包括参数个数、类型、顺序），重载方法的返回值可以不同。
重写指在子类中重新定义一个与父类具有相同名称、相同参数列表、相同返回类型的方法。重写方法必须与父类方法具有相同的方法签名，即方法名称、参数列表和返回类型必须相同。
重载和重写的区别主要有：
方法名相同，参数列表不同，即重载是两个或以上的方法名称相同，但参数列表不同；重写是子类重写父类的方法，方法名和参数列表都相同。
返回类型可以不同，即重载方法的返回类型可以不同；重写方法的返回类型必须相同。
重载对应的是同一个类中的方法，重写对应的是继承关系中父类和子类中的方法。
重载是编译时多态，重写是运行时多态。
- 抽象类和接口有什么区别
抽象类可以包含普通方法和抽象方法，接口只能包含抽象方法。
类只能继承一个抽象类，但可以实现多个接口。
抽象类的方法可以有public、protected和default访问修饰符，接口的方法默认是public。
抽象类可以有实例变量，接口只能有静态常量。
抽象类可以有构造方法，接口不能有构造方法。
- 说说反射的用途及实现
反射是Java的一个重要特性，它可以在运行时动态获取类的信息，并可以动态创建对象、调用方法、访问属性等。反射主要应用于框架开发、动态代理、单元测试等场景。实现反射可以使用Java自带的反射API，如Class类、Method类、Constructor类等。
- 说说自定义注解的场景及实现
自定义注解是Java中的一种元编程技术，可以在代码中定义注解，并在程序运行时通过反射获取注解信息。自定义注解可以应用于很多场景，如框架开发、代码生成、测试框架等。实现自定义注解需要使用Java的注解API，如@Retention、@Target、@Inherited等。
- HTTP 请求的 GET 与 POST 方式的区别
GET和POST是HTTP协议中常用的两种请求方式。GET请求会将参数放在URL中，而POST请求会将参数放在请求体中。因此，GET请求比较适合请求数据，而POST请求比较适合提交数据。GET请求的请求参数长度有限制，而POST请求没有长度限制。GET请求可以被缓存，而POST请求不能被缓存。
- session 与 cookie 区别
session和cookie是Web应用中常用的状态管理技术。cookie是客户端存储状态的一种方式，它可以在浏览器端存储一些数据，如用户ID、用户名等，以便下一次访问时可以直接使用。session是服务器端存储状态的一种方式，它可以在服务器端存储一些数据，如用户信息、购物车信息等，以便用户在不同页面之间可以共享数据。session和cookie都可以实现用户状态的跟踪和管理，但session相对更安全，因为session数据存储在服务器端，不容易被窃取。
- session 分布式处理
在分布式系统中，由于请求可能被多个服务器处理，因此session需要进行分布式处理，以保证不同服务器之间的session数据同步。常用的session分布式处理方案有以下几种：基于数据库的session共享、基于缓存的session共享、基于cookie的session共享、基于NFS的session共享等。
- JDBC 流程- 加载数据库驱动程序- 建立数据库连接- 创建Statement对象- 执行SQL语句- 处理查询结果集- 关闭Statement和数据库连接
- MVC 设计思想
MVC是一种常用的设计思想，它将应用程序分为三个部分：模型（Model）、视图（View）和控制器（Controller）。模型表示应用程序的数据和业务逻辑，视图表示用户界面，控制器协调模型和视图之间的交互。MVC设计思想的主要优点是代码分层明确、易于维护和重用。
- equals 与 == 的区别
在Java中，==是比较两个对象的引用是否相等，而equals是比较两个对象的内容是否相等。具体来说，==比较的是两个对象的内存地址，即它们是否指向同一个对象；而equals比较的是两个对象的内容，即它们是否具有相同的属性和状态。对于基本数据类型，==比较的是它们的值是否相等，而对于引用类型，==比较的是它们的引用是否相等。通常情况下，我们应该使用equals来比较两个对象的内容是否相等。
集合
- List和Set区别： List是一个有序的集合，允许重复元素存在。Set是一个无序的集合，不允许重复元素存在。
- List和Map区别： List是一个有序的集合，可以包含重复元素，元素访问通过索引进行。Map是一个键值对集合，可以通过键来访问值，键不允许重复，值允许重复。
- ArrayList与LinkedList区别： ArrayList底层使用数组实现，支持快速随机访问，但在插入和删除元素时需要移动其他元素。LinkedList底层使用链表实现，插入和删除元素时只需要修改指针，但随机访问需要遍历链表。
- ArrayList与Vector区别： ArrayList和Vector都是动态数组，它们的主要区别在于线程安全性和效率。Vector是线程安全的，但效率相对较低，而ArrayList是非线程安全的，但效率相对较高。
- HashMap和Hashtable的区别： HashMap和Hashtable都是键值对映射的集合，但它们的主要区别在于线程安全性和效率。Hashtable是线程安全的，但效率相对较低，而HashMap是非线程安全的，但效率相对较高。此外，HashMap允许键和值为null，而Hashtable不允许。
- HashSet和HashMap区别： HashSet是基于HashMap实现的，它是一个不允许重复元素的集合。HashMap是一个键值对映射的集合，键不允许重复，但值允许重复。
- HashMap和ConcurrentHashMap的区别： HashMap和ConcurrentHashMap都是键值对映射的集合，但它们的主要区别在于线程安全性和效率。HashMap是非线程安全的，效率相对较高，适用于单线程环境。ConcurrentHashMap是线程安全的，效率相对较低，但适用于多线程环境。
- HashMap的工作原理及代码实现： HashMap底层使用哈希表实现，可以快速访问和修改元素。哈希表是由一个数组和一些链表或红黑树组成的。当元素被添加到HashMap中时，先根据元素的hashcode计算出它在数组中的位置，如果该位置已经有元素，就把新元素加入到链表或红黑树中，否则直接放入该位置。当访问元素时，根据元素的hashcode找到它在数组中的位置，然后在链表或红黑树中查找该元
线程
创建线程的方式及实现： Java中有两种方式创建线程：继承Thread类和实现Runnable接口。继承Thread类需要重写run()方法，该方法体中的代码会在线程启动后执行。实现Runnable接口需要实现run()方法，并将其传入Thread类的构造方法中，然后调用Thread的start()方法启动线程。
sleep()、join()、yield()有什么区别： sleep()方法让当前线程休眠一段时间，期间不会释放锁；join()方法让当前线程等待另一个线程执行完毕后再继续执行；yield()方法让出当前线程的CPU时间片，给其他线程执行的机会。区别在于sleep()和join()方法会暂停当前线程的执行，而yield()方法只是让出一部分CPU时间片。
CountDownLatch原理： CountDownLatch是一个同步工具类，允许一个或多个线程等待其他线程完成操作后再执行。它通过一个计数器来实现，计数器初始化为一个正整数，每个线程完成操作时调用countDown()方法将计数器减1，当计数器变为0时，所有等待线程被唤醒。CountDownLatch的实现基于AQS（AbstractQueuedSynchronizer）同步器，通过维护一个同步状态和一个等待队列来实现线程的等待和唤醒。
CyclicBarrier原理： CyclicBarrier也是一个同步工具类，允许多个线程在某个屏障处等待，直到所有线程都到达该屏障后再继续执行。与CountDownLatch不同，CyclicBarrier的计数器可以重复使用。CyclicBarrier的实现也基于AQS同步器，每个线程到达屏障后调用await()方法进行等待，直到所有线程都到达屏障后才一起继续执行。
Semaphore原理： Semaphore是一个同步工具类，允许多个线程同时访问一定数量的资源。Semaphore通过一个计数器来实现，初始化时指定可访问资源的数量，每个线程访问资源时调用acquire()方法将计数器减1，当计数器为0时，所有访问资源的线程被阻塞。当一个线程释放资源时调用release()方法将计数器加1，唤醒一个被阻塞的线程。Semaphore的实现也基于AQS同步器
Exchanger 原理:Exchanger 是一个并发工具，可以用于两个线程之间交换数据。Exchanger 可以在两个线程之间提供一个同步点，当两个线程都到达这个同步点时，会交换它们持有的数据，并继续执行。Exchanger 的实现原理是使用了 LockSupport 类提供的 park 和 unpark 方法。当一个线程调用 Exchanger 的 exchange 方法时，它会被阻塞，直到另一个线程也调用 exchange 方法。这时，Exchanger 会将两个线程持有的数据进行交换，然后唤醒这两个线程，使它们继续执行。
CountDownLatch 与 CyclicBarrier 区别:CountDownLatch 和 CyclicBarrier 都是 Java 并发包中的同步工具，但是它们的使用场景不同。CountDownLatch 用于一个线程等待其他线程完成某个任务之后再继续执行。CountDownLatch 可以让一个线程等待多个线程完成，也可以让多个线程等待一个线程完成。它的核心方法是 await() 和 countDown()。CyclicBarrier 用于多个线程互相等待，直到所有线程都到达一个同步点之后再继续执行。CyclicBarrier 可以重复使用，即当所有线程都到达同步点之后，CyclicBarrier 可以被重置，重新开始下一轮的等待。它的核心方法是 await()。
ThreadLocal 原理分析:ThreadLocal 是一个线程本地变量，每个线程都可以独立地改变它的值，而不会影响其他线程的值。ThreadLocal 通常被用来解决线程安全问题。ThreadLocal 的原理是使用一个 ThreadLocalMap 类型的成员变量来存储每个线程的值。ThreadLocalMap 是一个类似于 Map 的数据结构，它的 key 是 ThreadLocal 实例，value 是该线程持有的值。每个线程都有自己的 ThreadLocalMap 实例，并且可以独立地修改其中的值。ThreadLocal 在获取值时，会根据当前线程获取该线程对应的 ThreadLocalMap 实例，并根据 ThreadLocal 实例获取对应的值。
线程池的实现原理线程池是为了解决线程创建和销毁的开销，以及过多线程竞争系统资源的问题，而提出的一种解决方案。线程池中主要包含一个任务队列和一组线程，当任务到来时，线程池会分配一个空闲线程来处理该任务，当所有线程都处于忙碌状态时，新任务会被加入到任务队列中等待执行。线程池的实现主要涉及到线程池的初始化、任务提交、任务执行、线程池关闭等几个方面。线程池的实现可以使用 JDK 提供的 ThreadPoolExecutor 类，也可以手动实现线程池。
线程池的几种方式Java 中常见的线程池有以下几种：(1) FixedThreadPool：固定大小线程池，线程数量固定，线程池中的线程数不会改变，适用于负载比较重的服务器。(2) CachedThreadPool：缓存线程池，线程数量不固定，根据任务数量动态调整线程池中的线程数，适用于执行短时间的任务。(3) SingleThreadExecutor：单线程线程池，只有一个线程在执行任务，适用于需要保证顺序执行的任务。(4) ScheduledThreadPool：定时任务线程池，可以定时执行任务，适用于周期性执行任务的场景。
线程的生命周期线程的生命周期主要包括以下几个状态：(1) 新建状态（New）：当线程对象创建后，它就处于新建状态。(2) 就绪状态（Runnable）：当调用 start() 方法后，线程进入就绪状态，等待 CPU 分配时间片，开始执行任务。(3) 运行状态（Running）：当线程获得 CPU 时间片后，进入运行状态，开始执行任务。(4) 阻塞状态（Blocked）：当线程因为某些原因无法执行任务时，进入阻塞状态。(5) 等待状态（Waiting）：当线程因为某些原因需要等待另一个线程执行完毕后再执行时，进入等待状态。(6) 超时等待状态（Timed Waiting）：当线程因为某些原因需要等待一段时间后再执行时，进入超时等待状态。(7) 终止状态（Terminated）：当线程执行完毕或出现异常时，进入终止状态。
锁机制
线程安全问题:线程安全问题是多线程编程中常见的问题，由于多个线程同时访问同一个资源，可能会导致数据的不一致或者程序出现异常。常见的线程安全问题包括：竞态条件、死锁、饥饿等。
volatile 实现原理: volatile 是一种轻量级的同步机制，用来保证变量的可见性和禁止指令重排序优化。volatile 的实现原理是使用了 CPU 的缓存一致性协议，当一个变量被 volatile 修饰后，对这个变量的读写操作都会直接从内存中读取或者写入，不会使用 CPU 缓存，从而保证了变量的可见性。
synchronize 实现原理:synchronize 是一种重量级的同步机制，用来保证线程安全。synchronize 的实现原理是使用了对象的监视器，当一个线程获取了对象的监视器后，其他线程就不能再访问这个对象的 synchronized 方法和代码块，直到持有对象监视器的线程释放锁。
synchronized 与 lock 的区别
synchronized 和 lock 都可以用来保证线程安全，但是两者有一些区别：
synchronized 是 JVM 提供的关键字，而 lock 是一个接口，需要程序员自己实现。
synchronized 可以修饰方法和代码块，而 lock 只能用来修饰代码块。
synchronized 在程序执行完 synchronized 代码块或者方法后会自动释放锁，而 lock 必须手动释放锁。
CAS 乐观锁:CAS（Compare And Swap）是一种乐观锁机制，用来保证线程安全。CAS 操作包括三个操作数：内存位置、期望的原值和新值。当期望的原值和内存位置的值相同时，将内存位置的值更新为新值，否则什么也不做。CAS 操作是原子操作，因此可以保证线程安全。
ABA 问题:ABA 问题是 CAS 操作中的一个问题，当一个线程修改了某个变量的值，然后又将其修改为原来的值，此时另外一个线程也修改了该变量的值并将其修改为和原来一样的值，这样就出现了 ABA 问题。为了解决 ABA 问题，可以使用带有版本号的 CAS 操作。
乐观锁的业务场景及实现方式: 乐观锁适用于多读少写的业务场景，通过在数据上加一个版本号（或者时间戳等），来实现对数据的同步控制。当读取数据的时候，先读取版本号，然后执行业务逻辑，最后更新数据的时候，检查版本号
核心篇
数据存储
- MySQL 索引使用的注意事项
- 在频繁进行查询、排序、分组、连接等操作的字段上建立索引。
- 避免使用过长的索引字段，建议使用整数类型。
- 对于经常修改的表，不宜建立太多的索引。
- 联合索引的顺序要考虑查询语句的where条件以及排序和分组的字段。
- 避免在索引字段上使用函数、表达式或类型转换。
- 注意对null值的处理，null值不会被索引。
说说反模式设计: 反模式是指在软件设计和开发中，使用了被证实不良的做法和方法，可能会导致软件质量的下降、开发成本的增加、可维护性的降低等问题。一些常见的反模式包括：大类、大方法、复杂继承、复杂逻辑、破窗效应等。
说说分库与分表设计
分库与分表是指将一个大的数据库或表，拆分成多个小的数据库或表来存储数据。这种设计可以解决单表数据量过大的问题，提高数据库的并发能力和性能。分库与分表的设计需要考虑以下几点：- 划分原则：可以按照业务模块、数据的关联性、地域等因素进行划分。- 切分键选择：在划分的过程中需要选择一个或多个切分键，确保数据可以均匀地分布到各个库或表中。- 跨库查询：跨库查询可能会影响性能，需要根据具体情况进行优化。- 数据迁移：在数据量增大或业务变更的情况下，需要考虑数据的迁移问题。分库与分表带来的分布式困境与应对之策
分库分表是常见的水平分割技术，它可以将一个大型的数据库分成多个小型的数据库或表，以便于提高数据库的扩展性、容量和性能等。但是，分库分表也带来了分布式困境，需要采取一些应对措施。数据一致性问题分库分表后，数据的分布变得分散，这样在数据同步、数据备份、数据恢复等方面都会带来挑战。因此，在设计分库分表的架构时，必须考虑到数据一致性的问题。常见的解决方案包括两阶段提交、消息队列等技术，保证数据的可靠性和一致性。跨节点查询问题在分库分表的架构中，查询数据的时候，需要跨多个节点进行查询，这可能会导致查询速度变慢。为了解决这个问题，可以采用数据路由和查询优化技术，将查询请求路由到正确的节点，从而提高查询速度。系统可用性问题分库分表架构中，由于多个节点参与，因此系统的可用性会变得更加脆弱。如果一个节点出现故障，可能会影响整个系统的可用性。为了解决这个问题，可以采用主从复制、数据备份和容错技术等，确保系统的高可用性。数据迁移问题分库分表后，数据的分布变得更加分散，如果需要进行数据迁移，可能会变得非常困难。为了解决这个问题，需要采用数据迁移和数据备份技术，确保数据的安全和可靠性。总之，分库分表架构是一种非常实用的技术，但是也需要考虑到分布式困境，从而采取相应的应对措施，保证系统的稳定和可靠性。说说 SQL 优化之道
优化查询语句，尽量避免全表扫描；避免在 WHERE 子句中使用函数或表达式，会导致索引失效；尽量使用覆盖索引，减少回表操作；使用合适的索引，根据查询的列和条件进行创建；避免 JOIN 查询中的笛卡尔积，减少数据量；对大量数据的表进行分区，提高查询效率；限制结果集大小，避免一次查询过多的数据；使用数据库缓存，如 Memcached 或 Redis，提高查询速度；合理设计数据库架构，分表分库，避免单点故障。MySQL 遇到的死锁问题
MySQL 中的死锁问题指的是当两个或多个事务相互等待对方释放资源而导致的系统无法进行的情况。解决 MySQL 死锁问题的常用方法包括：设计合理的数据库结构，减少数据冲突；尽量使用索引，避免全表扫描；限制事务的持续时间，避免长时间锁定资源；将锁定的资源按照相同的顺序进行访问，避免交叉等待。存储引擎的 InnoDB 与 MyISAM
InnoDB 支持事务，MyISAM 不支持；InnoDB 支持行级锁，MyISAM 支持表级锁；InnoDB 支持外键，MyISAM 不支持；InnoDB 的主键索引与数据存储在一起，MyISAM 主键索引与数据分开存储；InnoDB 的数据缓存使用的是 InnoDB Buffer Pool，MyISAM 使用的是系统缓存。综上所述，对于事务性较强的业务，建议使用 InnoDB 存储引擎，对于读写分离，只有读操作的业务，建议使用 MyISAM 存储引擎。数据库索引的原理
数据库索引是一种数据结构，用于加快数据的查找和访问速度。索引的原理是将数据库中的数据按照一定的规则，建立起一张索引表，索引表中记录了数据在实际表中的位置，当我们需要查找数据时，可以先在索引表中找到数据对应的位置，再去实际表中查找，从而提高查询效率。为什么要用 B-tree
B-tree 是一种多路搜索树，相比于二叉搜索树，它每个节点可以存储多个元素，从而减少了树的高度，提高了搜索效率。因此，在数据库中，B-tree 索引能够支持高效的范围查询，对于大量数据的情况下，使用 B-tree 索引可以大幅提高查询效率。聚集索引与非聚集索引的区别
聚集索引是按照索引的顺序来存储表中的数据，通常一个表只能有一个聚集索引，它的叶子节点存储的是完整的数据行，因此在通过聚集索引查询数据时，可以直接通过索引访问数据。而非聚集索引则是将索引和数据分开存储，叶子节点存储的是索引值和指向数据行的指针，查询时需要先根据索引值找到对应的指针，再通过指针访问数据行。因此，在通过非聚集索引查询数据时，需要进行两次查找操作，因此查询效率相对较低。limit 20000 加载很慢怎么解决
尽可能减少查询的数据量，例如使用更加严格的查询条件或者采用分页查询等方式；对查询条件进行优化，例如对需要查询的字段添加索引；优化数据库的性能，例如升级硬件、调整数据库参数等；使用缓存技术，例如将查询结果缓存到 Redis 中，以便后续快速访问。选择合适的分布式主键方案
在分布式系统中，生成唯一的主键是必要的。因为每个节点的主键都要保证唯一性，所以分布式系统中的主键需要保证全局唯一。常见的分布式主键方案有以下几种：UUID：使用UUID算法可以在任何地方生成唯一的标识符，而不需要进行协调。但是，UUID不太适合作为数据库主键，因为它不是递增的，这可能会导致索引的性能问题。雪花算法：雪花算法是Twitter开发的一种算法，用于生成唯一ID。它的优点是ID是递增的，因此更适合作为数据库主键。但是，雪花算法需要在分布式环境中进行协调。数据库自增主键：使用数据库自增主键可以保证主键是唯一的，而且是递增的。但是，在分布式系统中使用数据库自增主键可能会导致性能瓶颈和锁竞争。综上所述，选择适合自己的分布式主键方案需要考虑业务需求、性能、唯一性等因素。选择合适的数据存储方案
数据访问模式：根据应用程序的数据访问模式，选择合适的数据存储方案。例如，如果应用程序的数据访问模式是随机读写，那么关系型数据库可能更适合。数据量和数据类型：根据数据量和数据类型，选择适合的存储方案。例如，如果数据量较大，那么NoSQL数据库可能更适合。数据的一致性要求：根据数据的一致性要求，选择合适的存储方案。例如，如果需要高度一致性的数据，那么关系型数据库可能更适合。数据的可扩展性要求：根据数据的可扩展性要求，选择合适的存储方案。例如，如果需要水平扩展，那么NoSQL数据库可能更适合。ObjectId 规则
ObjectId是MongoDB中文档（Document）的唯一标识符，是由MongoDB中的驱动程序生成的。它由12个字节组成，其中前4个字节表示时间戳，接下来的3个字节表示机器ID，然后的2个字节是进程ID，最后的3个字节是一个计数器值。这些字节按照特定的顺序进行排列，以便MongoDB可以对它们进行排序。在ObjectId中，时间戳部分占据了前4个字节，因此可以使用ObjectId来确定文档的创建时间。由于ObjectId是唯一的，因此可以用作文档的主键。此外，ObjectId还提供了一些其他的功能，如在MongoDB的分片集群中进行数据分片时使用的哈希分片键值。聊聊 MongoDB 使用场景
无模式的数据存储：MongoDB不需要事先定义表的结构，可以根据需要随时创建新的文档并存储数据。这使得它在需要存储大量不规则或半结构化数据的场景中非常有用。大数据处理：MongoDB具有分布式处理和集群管理功能，可以处理大量的数据和高并发请求。它还支持多种数据处理方式，包括MapReduce、聚合管道和全文搜索等。实时数据存储和查询：MongoDB具有高速的读写速度和实时查询性能，能够满足实时应用程序对数据的存储和查询需求。它还支持多种查询方式，包括索引、范围查询和全文搜索等。IoT数据管理：MongoDB可以快速存储和查询物联网设备生成的数据，如传感器数据、位置数据等。它还支持地理位置查询和地图可视化等功能。内容管理系统：MongoDB可以作为内容管理系统（CMS）的后端数据库，用于存储和查询文档、图像、视频和音频等媒体文件。它还支持多种数据格式，如JSON、BSON和GridFS等。总之，MongoDB具有灵活的数据模型、高可扩展性、实时查询性能和高性能数据处理能力，适合于处理大量的半结构化和不规则数据。它在Web应用程序、物联网、大数据分析、移动应用程序等各种场景中都有着广泛的应用。倒排索引
倒排索引（Inverted Index）是一种数据结构，它将文档中的每个单词映射到包含该单词的文档列表中。倒排索引是信息检索系统中最常用的数据结构之一，主要用于快速定位包含给定单词的文档。在倒排索引中，每个单词都会有一个对应的单词项（Term），单词项包含一个指向包含该单词的所有文档的指针列表。指针列表的元素包含文档 ID 和单词出现的位置等信息，这些信息可以用于计算文档的相关性和排名。倒排索引可以支持文本检索、全文搜索、关键字搜索等功能，在搜索引擎、数据库、数据仓库等领域得到了广泛应用。在搜索引擎中，倒排索引通常存储在内存或者磁盘中，可以通过 MapReduce 等分布式计算框架实现并行处理。聊聊 ElasticSearch 使用场景
ElasticSearch是一款开源的全文搜索引擎，基于Lucene搜索库构建而成，具有分布式、高可用、高性能、可伸缩等特性，被广泛应用于日志分析、全文搜索、数据挖掘、企业级搜索等领域。以下是ElasticSearch的使用场景：搜索引擎：ElasticSearch的全文搜索能力非常强大，能够帮助企业快速、精准地查询相关信息。例如，可以通过ElasticSearch实现电商网站的商品搜索、社交网站的用户搜索、新闻网站的文章搜索等。日志分析：ElasticSearch可以快速处理大量的日志数据，并提供实时的分析和查询功能。例如，可以通过ElasticSearch实现服务器日志分析、应用程序日志分析、安全日志分析等。监控系统：ElasticSearch可以存储和查询各种监控数据，例如服务器性能指标、网络流量、应用程序性能等。通过对这些数据的分析和统计，可以实现对系统的实时监控和预警。企业级搜索：ElasticSearch可以作为企业内部搜索引擎，帮助员工快速找到所需信息，提高工作效率。例如，可以通过ElasticSearch实现员工信息搜索、文档搜索、邮件搜索等。数据挖掘：ElasticSearch可以作为数据挖掘平台，支持各种复杂的查询和聚合操作，可以帮助企业发现隐藏在数据中的规律和趋势。例如，可以通过ElasticSearch实现销售数据分析、客户行为分析、舆情分析等。
缓存使用
Redis 有哪些类型
Redis 有以下五种数据类型：String：最基本的类型，存储字符串、数字等。List：链表结构，支持在链表两端插入和删除元素，可以实现队列、栈等数据结构。Set：无序集合，不允许重复元素，可以对集合求交、并、差等操作。Hash：类似于字典或关联数组，可以对其中的元素进行单独的增、删、改、查操作。Zset（Sorted Set）：有序集合，每个元素都有一个权重（分数），可以进行区间查询和排名查询等操作。HyperLogLogHyperLogLog 是用来做基数统计的算法，它的基本思路是通过随机映射和计数器来统计元素数量，这样就可以使用比较小的空间，达到接近准确的结果。GeoRedis 3.2 版本之后，增加了对地理位置的支持。Geo 数据类型可以用来存储经纬度信息，同时支持多种距离计算方式。通过 Geo 数据类型，可以很方便地实现位置服务，比如查找附近的人、商家等。Redis 内部结构
网络层：负责接收客户端的请求，并将请求发送到相应的命令处理器进行处理。命令处理器：负责处理客户端的请求，并将结果返回给客户端。数据库：存储 Redis 的所有数据，Redis 支持多个数据库。线程池：负责处理各种耗时操作，如持久化操作和后台任务等。订阅与发布系统：支持订阅与发布消息。聊聊 Redis 使用场景
缓存：Redis 可以作为缓存服务器，减轻数据库的压力。分布式锁：通过 Redis 的分布式锁机制，可以保证在分布式环境下的数据一致性。会话管理：可以将用户的会话信息存储在 Redis 中，提高会话管理的效率。计数器：可以将计数器的值存储在 Redis 中，提高计数器的并发性能。消息队列：可以使用 Redis 的消息队列功能实现简单的消息队列。Redis 持久化机制
RDB：Redis 数据库快照，将 Redis 在某个时间点上的数据集合保存到一个 RDB 文件中，可以通过该文件进行数据恢复。AOF：Redis 的追加式日志，将 Redis 执行的写命令追加到 AOF 文件中，可以通过重放 AOF 文件来实现数据恢复。Redis 如何实现持久化
执行写命令。将写命令缓存到缓存区中。根据配置的持久化方式将缓存区中的写命令进行持久化。如果启用了 AOF 持久化方式，还需要将 AOF 文件进行重写。Redis 集群方案与实现
Redis集群方案主要有两种：Redis Sentinel 方案Redis Sentinel 是 Redis 官方推荐的高可用解决方案，它通过监控 Redis 实例的运行状况来实现自动故障转移。当 Redis 实例宕机时，Sentinel 会自动将请求转发到其他健康的实例上，确保 Redis 集群的高可用性。Redis Sentinel 方案支持读写分离，但不支持分片。Redis Cluster 方案Redis Cluster 是 Redis 官方提供的分布式解决方案，支持多个节点之间的数据分片和负载均衡。Redis Cluster 方案采用哈希槽分配算法将数据分片到不同的节点上，每个节点可以负责多个哈希槽，确保了集群的高可用和可扩展性。Redis Cluster 方案支持读写分离和分片。Redis Cluster 方案相对于 Redis Sentinel 方案更加适合大规模的数据存储和高并发访问场景，但也需要更多的配置和管理工作。在选择 Redis 集群方案时，需要根据实际业务需求和运维成本进行综合考虑。Redis 为什么是单线程的
Redis 是单线程的主要原因是为了避免多线程的竞争和上下文切换带来的额外开销。虽然 Redis 是单线程的，但是 Redis 的单线程并不是独占 CPU，因为 Redis 使用了 I/O 多路复用技术，可以在一个线程中同时处理多个客户端的请求。当 Redis 接收到客户端的请求时，它会将请求放入队列中，然后轮询所有的客户端，判断是否有客户端请求已经就绪，如果就绪就执行相应的操作。由于 Redis 所有的数据都存储在内存中，所以 Redis 可以快速地执行读写操作，从而避免了多线程同步带来的性能问题。此外，Redis 在实现单线程的同时，还采用了多进程的方式，通过主从复制的方式实现数据的备份和容错，以此来保证 Redis 集群的高可用性。==========================================现在的版本redis不是多线程了嘛？Redis的早期版本确实是单线程的，但是从Redis 6.0版本开始，引入了多线程IO（I/O Threads）的特性，可以使用多个线程处理网络I/O，同时保留了单线程处理命令的核心特性。需要注意的是，Redis 仍然是单线程处理命令，每个客户端请求仍然会被单独处理，保证了数据的一致性和线程安全性。多线程IO仅仅是用来处理网络I/O，提高Redis的吞吐量和性能，而不是用来加速命令处理的。缓存奔溃
缓存奔溃指的是缓存出现故障或不可用的情况，导致请求无法正常响应或响应时间过长，甚至可能导致系统崩溃的情况。缓存奔溃的原因可能包括但不限于以下几种：硬件故障：例如服务器硬盘损坏、内存故障等。软件故障：例如缓存软件程序错误、操作系统问题等。网络问题：例如网络断连、网络延迟等。内存溢出：如果缓存中存储的数据量超过了缓存所能承受的极限，可能会导致内存溢出。为了避免缓存奔溃对系统造成不可预测的影响，我们需要进行一些预防措施和应对措施：高可用架构：使用多个节点组成的集群，确保缓存的高可用性，提供高可靠的缓存服务。容错机制：在架构设计中加入容错机制，例如主备切换、数据备份等，以保证缓存出现故障时可以快速切换到备用节点。监控和预警：对缓存的使用情况进行监控，并设置预警机制，一旦出现问题可以及时发现和处理。熔断机制：在高并发场景下，对缓存服务进行熔断，避免缓存压力过大导致缓存服务奔溃。性能测试和优化：对缓存服务进行性能测试和优化，尽量避免出现缓存服务压力过大的情况。缓存击穿指的是某个热点 key 在缓存中过期或者被删除，导致大量的请求直接落到了数据库上，导致数据库压力过大，甚至可能会导致数据库宕机缓存降级
缓存降级是指在高并发场景下，为了保证核心流程的正常运行，对一些非核心但对系统稳定性有一定影响的服务进行临时屏蔽或降级处理，以保证核心流程的稳定运行。通俗地讲，就是暂时关闭或降级一些不太重要的服务，来保证系统的可用性。举个例子，假设我们在电商网站中使用了商品推荐系统，该系统的核心作用是给用户推荐商品。但是，如果在高并发场景下，商品推荐系统因为访问量过大而导致服务瘫痪，这将会给整个电商系统带来严重影响，可能导致整个系统瘫痪。这时候，我们可以暂时关闭商品推荐系统，来保证整个系统的可用性。缓存降级可以通过一些开关或配置来实现，可以根据系统的实际情况灵活调整。但是需要注意的是，缓存降级并不是一种完美的解决方案，因为一旦关闭或降级某些服务，将会对系统的用户体验和功能造成一定影响。因此，我们需要根据实际情况综合考虑，来选择最合适的解决方案。使用缓存的合理性问题
数据的时效性：缓存数据可能不是实时的，如果缓存数据过期或被更新，可能会导致数据不一致。因此需要根据业务场景和数据特点合理设置缓存的过期时间，以及及时更新缓存。缓存空间：缓存的数据量可能非常大，需要合理分配缓存空间。同时也需要考虑缓存数据的淘汰策略，以及合理利用内存空间。系统复杂度：使用缓存可能会增加系统复杂度，需要考虑缓存数据和数据库数据的一致性，以及缓存和数据库的同步等问题。高并发下的缓存穿透和缓存雪崩：高并发场景下，缓存可能会出现缓存穿透和缓存雪崩问题，需要采取相应的措施来避免。redis 缓存策略
LRU（Least Recently Used）：最近最少使用，即优先淘汰最近最少使用的缓存数据；LFU（Least Frequently Used）：最不经常使用，即优先淘汰使用频次最少的缓存数据；TTL（Time to Live）：即缓存数据的存活时间，超过设定的时间，数据将被自动淘汰；Random：随机淘汰一些缓存数据。``````import java.util.HashMap;import java.util.LinkedList;import java.util.Map;public class LRUCache { private int capacity; private Map<Integer, Integer> cache; private LinkedList<Integer> order; public LRUCache(int capacity) { this.capacity = capacity; this.cache = new HashMap<>(); this.order = new LinkedList<>(); } public int get(int key) { if (!cache.containsKey(key)) { return -1; } order.removeFirstOccurrence(key); order.add(key); return cache.get(key); } public void put(int key, int value) { if (cache.containsKey(key)) { order.removeFirstOccurrence(key); } else if (cache.size() == capacity) { int oldest = order.removeFirst(); cache.remove(oldest); } cache.put(key, value); order.add(key); }}=================================================== 这个实现中，我们使用了一个HashMap（cache）来存储缓存的数据，以及一个LinkedList（order）来记录缓存数据的访问顺序。当访问缓存时，我们首先检查该数据是否存在于缓存中，如果存在，则将其移动到order的末尾以更新其访问顺序，并返回数据；如果不存在，则返回-1。当向缓存中插入新数据时，我们检查是否已存在该数据，如果存在，则将其移动到order的末尾以更新其访问顺序；如果不存在，则检查缓存是否已满，如果满了，则删除order中最早访问的数据，并从cache中删除该数据，最后将新数据插入cache和order中。
消息队列
- 消息队列的使用场景
消息队列通常用于解耦异步处理，异步处理包括：任务异步化、异步通知、消息推送等，例如：订单系统中，订单的异步处理、退款的异步处理；消息推送系统，用户行为触发消息推送、广告推送、短信通知等；数据处理，如日志处理、数据清洗、实时计算等。 - 消息的重发补偿解决思路
在使用消息队列时，消息可能会因为各种原因未能被消费者及时消费，导致消息的丢失或处理失败。此时，我们需要对消息进行重发补偿。一般的解决思路有：定时重发：将未成功消费的消息重新投递到消息队列中，并设置重试时间间隔和重试次数，达到一定重试次数后可以选择将消息进行丢弃或者存储到死信队列中等待人工处理。手动触发：提供一个接口或者命令来手动触发消息的重发，通常用于特殊情况的处理，比如重要的业务消息。异常回调：对于一些无法自动处理的异常，可以采用回调方式进行处理，将异常信息通过消息通知管理员，由管理员手动处理异常。 - 消息的幂等性解决思路
在使用消息队列时，为了防止消息被重复消费，需要保证消息的幂等性。一般的解决思路有：消息去重：在消费消息前，先对消息进行去重操作，判断消息是否已经被消费过。唯一标识：为每条消息设置唯一标识符，消费者在消费消息时，可以根据标识符判断消息是否已经被消费过。消息状态检查：在消费消息前，先检查消息的状态，判断消息是否已经被消费过，如果已经被消费，则不再处理。 - 消息的堆积解决思路
消息的堆积是指由于消费能力不足、消费者出现故障等原因导致消息在队列中积压，无法及时消费的情况。为解决消息的堆积问题，可以采用以下几种解决思路：消费能力提升：提高消费者的并发数或者增加消费者的数量，增加消费能力，从而缩短消息积压的时间。可以通过水平扩展消费者节点的方式来实现消费能力的提升。消息预处理：在消息进入队列之前进行一些必要的处理，减少消息在队列中的存留时间。例如，可以对消息进行一些必要的过滤、验证、转换等操作，避免无用消息进入队列，从而减少消息在队列中的积压时间。消息批量处理：针对一些可以批量处理的消息，可以将多个消息合并成一个消息进行处理，从而减少消息在队列中的数量，缩短消息积压的时间。消息定时清理：对于一些已经处理完成的消息，可以定期清理掉，避免占用过多的存储空间，从而避免队列的存储空间被占满导致消息无法写入的情况。消息队列监控：对消息队列进行实时监控，及时发现消息堆积的情况，并采取相应的措施进行处理，避免由于消息堆积导致消息处理失败的情况。可以使用一些开源的消息队列监控工具，如Kafka Manager、RabbitMQ Management等。 - 自己如何实现消息队列
数据存储：可以使用内存、文件、数据库等作为数据存储方式，其中内存是最常用的方式，速度最快，但也有容量限制，需要考虑如何合理地管理内存空间，文件和数据库可以考虑使用文件系统、SQLite、MySQL 等。消息传输方式：可以考虑使用 TCP、UDP、HTTP 等传输协议，其中 TCP 和 HTTP 是最常用的方式。消息序列化方式：可以使用 JSON、XML、二进制等方式将消息序列化为字节流，便于传输和存储。消息的发布和订阅机制：可以使用观察者模式或者订阅者模式来实现。消息的持久化：可以考虑使用数据库或者文件系统将消息持久化存储，以便在系统故障等情况下能够恢复消息。消息的重试机制：当消息处理失败时，可以考虑将消息放入重试队列，定时进行重试，直到消息处理成功或者达到最大重试次数为止。 - 如何保证消息的有序性
保证发送顺序和消费顺序一致：生产者在发送消息时按照顺序发送，消费者在处理消息时也按照相同的顺序消费。这种方式对于消息量较小、业务简单的场景比较适用。基于消息队列的顺序消费：将消息发送到同一个队列中，并在队列中为每个消息赋予序列号。消费者在消费消息时按照序列号的大小依次消费。这种方式对于消息量较大、处理逻辑较为复杂的场景比较适用。基于分区的顺序消费：将消息根据一定的规则进行分区，同一个分区内的消息保证顺序消费，不同分区的消息并行消费。这种方式可以在保证消息有序性的同时提高消费的效率。使用消息中间件提供的顺序消费功能：像 Kafka、RocketMQ 等消息中间件提供了顺序消费的功能。生产者将消息发送到同一个主题中，消息中间件根据一定的规则为消息分配分区，同一个分区内的消息保证顺序消费，消费者在消费消息时也按照分区的顺序依次消费。这种方式对于消息量较大、处理逻辑较为复杂的场景比较适用。
框架篇
Spring
- BeanFactory 和 ApplicationContext 有什么区别
BeanFactory 是 Spring 框架中的最基本的接口，定义了 IoC 容器的基本功能规范，提供了基本的 IoC 功能，是最简单的容器，只负责 Bean 的实例化、配置和管理。ApplicationContext 是 BeanFactory 接口的子接口，继承了 BeanFactory 的所有功能，并且在此基础上增加了大量面向企业级应用的功能，如国际化支持、资源访问、事件传播、AOP 支持等。ApplicationContext 是 Spring 框架中较为重要的一个接口，也是一个更加高级的 IoC 容器。 - Spring Bean 的生命周期
Spring Bean 的生命周期包括以下几个阶段：实例化：容器根据配置文件中定义的 Bean 配置信息，实例化出 Bean 的实例对象。属性赋值：将配置文件中定义的 Bean 的属性值和对其他 Bean 的引用赋值给 Bean 对象对应的属性上。检查 Aware 接口：检查是否实现了 BeanNameAware、BeanFactoryAware 等接口，如果实现了，则将容器相关信息注入到对应的属性中。BeanPostProcessor 前置处理：如果 Bean 实现了 BeanPostProcessor 接口，则调用 postProcessBeforeInitialization 方法。初始化：如果 Bean 实现了 InitializingBean 接口，则调用 afterPropertiesSet 方法，同时调用 Bean 中的 init 方法。BeanPostProcessor 后置处理：如果 Bean 实现了 BeanPostProcessor 接口，则调用 postProcessAfterInitialization 方法。使用：Bean 可以正常使用了。销毁：如果 Bean 实现了 DisposableBean 接口，则调用 destroy 方法，同时调用 Bean 中的自定义的销毁方法。 - Spring IOC 如何实现
读取配置文件：Spring 会通过 ResourceLoader 读取配置文件。解析配置文件：Spring 使用 BeanDefinitionReader 接口的实现类来解析配置文件。注册 Bean 定义：Spring 会将解析出来的 Bean 定义注册到 BeanDefinitionRegistry 中。实例化 Bean：Spring 会根据 Bean 的定义，使用反射等技术实例化 Bean 对象。属性赋值：Spring 会调用 Bean 的 setter 方法，将配置文件中的属性值赋值给 Bean 对应的属性上。Bean 生命周期：Spring 会根据 Bean 的配置信息，调用相应的方法，如 BeanPostProcessor 的 postProcessBeforeInitialization 方法等。 - 说说 Spring AOP
Spring AOP是Spring框架中的一个重要特性，是基于Java语言的动态代理机制实现的。它通过在目标方法的前后等特定位置织入切面逻辑，从而实现对目标方法进行拦截、增强、改变其行为的效果，是实现事务管理、性能监控、安全控制等方面的重要工具。 - Spring AOP 实现原理
Spring AOP的实现原理主要依赖于Java语言中的反射机制和动态代理技术。在Spring AOP中，核心组件包括切面（Aspect）、连接点（Join Point）、切点（Pointcut）、通知（Advice）、织入（Weaving）等。具体来说，Spring AOP的实现过程如下：定义切面类：定义一个Java类，实现了Advice接口，并提供了要织入的逻辑代码。定义切入点：定义一个Pointcut对象，用来匹配需要被拦截的目标方法。定义通知：定义一个Advice对象，包括Before、After、Around等不同类型的通知。将切面类和切入点结合：通过AspectJ或者Spring AOP提供的注解或配置方式，将切面类和切入点进行绑定。创建代理对象：当目标方法被调用时，Spring AOP框架会根据定义好的切面和切入点，动态地生成一个代理对象，并将其织入到目标方法中。执行目标方法：当代理对象调用目标方法时，Spring AOP框架会根据切入点的配置，将预定义的通知逻辑织入到目标方法的前后。 - 动态代理（cglib 与 JDK）
动态代理是一种代理模式，它允许在程序运行时创建一个代理对象，该代理对象可以代替原始对象进行某些操作。在 Java 中，动态代理有两种实现方式：基于接口的 JDK 动态代理和基于继承的 CGLIB 动态代理。JDK 动态代理通过实现被代理对象的接口，在运行时动态生成代理类并返回。JDK 动态代理只能为接口创建代理实例，也就是说，被代理类必须实现至少一个接口。JDK 动态代理是 Java 标准库自带的一种动态代理方式，由于使用了反射机制，会增加一定的开销，但代理类的生成速度比 CGLIB 快。CGLIB 动态代理是基于继承实现的。它通过生成一个被代理类的子类来完成代理操作，因此被代理类不需要实现任何接口。CGLIB 动态代理的代理类是被代理类的子类，因此可以调用被代理类的所有方法，而 JDK 动态代理只能代理实现了接口的类的方法。CGLIB 动态代理在创建代理类时，使用了 Enhancer 类的 create() 方法来生成代理类，生成代理类的过程比 JDK 动态代理的 Proxy.newProxyInstance() 方法要慢，但在运行时的代理效率比 JDK 动态代理高。 - Spring 事务实现方式
Spring 提供了多种方式来实现事务，主要包括编程式事务和声明式事务两种。编程式事务主要是通过编写代码来实现事务，需要手动在代码中开启、提交、回滚事务，使用起来较为繁琐，但是在特殊的场景下，如一些复杂的事务控制时，可能会需要使用编程式事务。声明式事务则是通过配置来实现事务，可以通过 XML 配置文件或者注解的方式实现，相比编程式事务，使用起来更为方便快捷。声明式事务底层依赖于 AOP 实现，对于声明式事务的控制，Spring 主要使用了两种方式，分别是基于注解和基于 XML 配置。在基于注解的声明式事务中，常用的注解包括 @Transactional，可以用来标注在方法或类级别上，表示对应的方法或类使用事务进行控制。在基于 XML 配置的声明式事务中，则需要在 XML 配置文件中进行相应的配置，包括指定事务管理器、配置事务的传播行为和隔离级别等。无论是基于注解还是基于 XML 配置的声明式事务，在底层都是通过 AOP 进行实现，将事务管理的代码逻辑织入到目标方法中。通过这种方式，可以将事务控制和业务逻辑分离，提高了代码的可维护性和可扩展性。 - Spring 事务底层原理
事务管理器（Transaction Manager）：Spring 提供了多种事务管理器，如 JDBC 事务管理器、Hibernate 事务管理器、JPA 事务管理器等。事务管理器主要负责管理事务的生命周期，控制事务的提交和回滚，以及与底层的资源（如数据库连接）进行交互。事务代理（Transaction Proxy）：事务代理是 Spring 实现事务的关键。Spring AOP 通过拦截器和动态代理来实现事务代理。在使用 @Transactional 注解时，Spring AOP 会在方法执行前后加入拦截器，在方法执行前开启事务，在方法执行后根据方法执行结果决定事务是提交还是回滚。事务同步器（Transaction Synchronization）：Spring 使用事务同步器来协调事务中的多个资源的状态。当事务提交或回滚时，事务同步器会通知所有的资源提交或回滚，以保证事务的一致性。事务状态管理器（Transaction State Manager）：事务状态管理器是 Spring 中的一个重要组件，用于管理事务状态。在一个事务中，可能存在多个资源，每个资源都有自己的事务状态。事务状态管理器负责管理每个资源的状态，以及在事务提交或回滚时统一处理每个资源的状态。总的来说，Spring 事务底层原理主要是通过事务管理器、事务代理、事务同步器和事务状态管理器等组件的协同工作来实现的。Spring AOP 技术是实现事务代理的核心技术，它能够在运行时动态地创建代理对象，从而实现事务的控制。事务同步器则负责在事务提交或回滚时协调事务中的多个资源的状态，以保证事务的一致性。 - 如何自定义注解实现功能
定义注解类：使用 @interface 关键字定义。例如：public @interface MyAnnotation { String name(); int age();}这个注解类定义了两个元素，一个是 name，类型为 String，另一个是 age，类型为 int。使用注解：使用注解需要在元素上加上注解名称，后面用小括号括起来，传入参数。例如：@MyAnnotation(name = "John", age = 18)public class MyClass {}这样 MyClass 类上就加上了 MyAnnotation 注解，并传入了参数。获取注解参数：使用反射机制获取注解的参数值。例如：Class clazz = MyClass.class;MyAnnotation annotation = clazz.getAnnotation(MyAnnotation.class);String name = annotation.name();int age = annotation.age();这样就获取了 MyClass 的 MyAnnotation 注解的参数值。实现功能：通过获取注解参数值，实现相应功能。例如，在 MyClass 中可以根据 age 属性值来判断是否成年。 - Spring MVC 运行流程
Spring MVC是一种基于MVC设计模式的Web框架，其运行流程可以简述如下： 1. 客户端发送请求到DispatcherServlet。2. DispatcherServlet收到请求后，根据请求路径找到对应的Controller。 3. Controller执行业务逻辑，返回ModelAndView对象。 4. DispatcherServlet根据ViewResolver找到对应的视图。 5. 渲染视图，并返回给客户端。 具体的详细流程如下： 1. 客户端发送请求到DispatcherServlet，DispatcherServlet是一个前端控制器，是Spring MVC的核心。 2. DispatcherServlet通过HandlerMapping找到对应的处理器（即Controller），HandlerMapping是一个接口，由多个实现类实现，根据请求的URL找到对应的处理器。 3. 处理器（即Controller）处理请求，根据业务逻辑调用Service层进行处理，返回一个ModelAndView对象。 4. DispatcherServlet通过ViewResolver找到对应的视图，ViewResolver是一个接口，由多个实现类实现，根据视图名称找到对应的视图。 5. 渲染视图，将ModelAndView中的数据填充到视图中，最终返回给客户端。 在整个过程中，Spring MVC采用了多种设计模式，如前端控制器模式、MVC模式、工厂模式、策略模式等，保证了框架的灵活性和可扩展性。 - Spring MVC 启动流程
容器初始化当Web应用程序启动时，Servlet容器会加载Spring MVC框架的核心组件，并初始化Spring容器。在初始化Spring容器的过程中，会读取并解析配置文件，创建Bean实例，以及进行依赖注入等操作。Spring MVC框架的核心组件包括DispatcherServlet、HandlerMapping、HandlerAdapter、ViewResolver等。请求处理当客户端发送请求时，Servlet容器会将请求转发给DispatcherServlet。DispatcherServlet是Spring MVC框架的核心控制器，它负责处理所有的请求，并将请求分发给相应的处理器Handler。处理器映射在请求到达DispatcherServlet后，DispatcherServlet会将请求交给HandlerMapping处理器映射器。HandlerMapping会根据请求的URL和HTTP方法，查找并返回相应的Handler处理器对象。处理器适配器在获得Handler处理器对象之后，DispatcherServlet会将请求交给HandlerAdapter处理器适配器。HandlerAdapter主要负责将请求数据转换成Handler处理器对象所需的参数格式。如果Handler处理器对象是一个Controller控制器对象，则会执行Controller中对应的方法进行具体业务处理。视图解析器在Handler处理器对象执行完业务逻辑后，DispatcherServlet会将处理结果返回给客户端。在返回结果之前，DispatcherServlet会将处理结果交给ViewResolver视图解析器进行处理。ViewResolver会根据返回结果所需的视图格式，查找并返回相应的View视图对象。渲染视图在返回View视图对象之后，DispatcherServlet会将View视图对象渲染成客户端能够识别的HTML或JSON等格式，并将结果返回给客户端。总之，Spring MVC的启动流程是一个非常复杂的过程，需要涉及到多个组件的协作和交互，开发人员需要深入理解Spring MVC框架的原理和机制，才能更好地使用和掌握这个框架。 - Spring 的单例实现原理
提前创建实例：在容器初始化时就创建单例实例，并将其缓存起来，之后每次请求都返回同一个实例对象。懒加载：在容器初始化时不创建单例实例，而是当第一次请求对象的时候再创建对象，并将其缓存起来。 - Spring 框架中用到了哪些设计模式
工厂模式（Factory Pattern）：Spring框架中最常用的设计模式之一，它负责创建和管理对象实例。在Spring框架中，BeanFactory和ApplicationContext都是工厂模式的经典实现。代理模式（Proxy Pattern）：Spring框架中的AOP（Aspect Oriented Programming）就是基于代理模式实现的。Spring框架中的代理包括静态代理和动态代理，其中动态代理又分为基于JDK的动态代理和基于CGLib的动态代理。单例模式（Singleton Pattern）：Spring框架中的Bean默认都是单例的，即Spring容器中只会创建一个Bean实例，并在需要时重复使用。观察者模式（Observer Pattern）：Spring框架中的事件机制就是基于观察者模式实现的。在Spring框架中，事件源和事件监听器是观察者模式的核心组件。模板方法模式（Template Method Pattern）：Spring框架中的JdbcTemplate就是基于模板方法模式实现的。JdbcTemplate封装了JDBC API，提供了一组模板方法，简化了JDBC编程的复杂性。适配器模式（Adapter Pattern）：Spring框架中的HandlerAdapter就是适配器模式的经典实现。HandlerAdapter负责将请求数据转换成Handler处理器对象所需的参数格式。 - Spring 其他产品（Srping Boot、Spring Cloud、Spring Secuirity、Spring Data、Spring AMQP 等）
Spring Boot：Spring Boot是一个快速构建基于Spring框架的Web应用程序的工具。它提供了自动配置、快速开发、无代码生成等特性，可以帮助开发人员快速构建高效、可靠的Web应用程序。Spring Cloud：Spring Cloud是一个基于Spring Boot的微服务框架，它提供了多个组件，包括服务发现、负载均衡、断路器、配置中心等，可以帮助开发人员快速构建和管理分布式系统。Spring Security：Spring Security是一个基于Spring框架的安全框架，它提供了多种安全功能，包括身份认证、授权、密码管理等，可以帮助开发人员保护Web应用程序的安全性。Spring Data：Spring Data是一个数据访问框架，它提供了多个组件，包括JPA、MongoDB、Redis等，可以帮助开发人员快速、简便地访问和操作各种数据源。Spring AMQP：Spring AMQP是一个基于Spring框架的消息队列框架，它提供了多种消息传递协议，包括RabbitMQ、ActiveMQ等，可以帮助开发人员实现异步消息传递、事件驱动编程等。总之，Spring框架是一个非常强大、灵活的框架，它提供了多个产品，可以帮助开发人员快速构建和管理各种应用程序和系统。每个产品都有自己的特性和优点，开发人员可以根据具体需求选择适合自己的产品。
Netty
- 为什么选择 Netty
高性能：Netty基于Java NIO技术实现，可以实现高并发、高吞吐量的网络IO操作。可扩展性：Netty提供了多种IO模型、线程池模型和编解码器等组件，可以根据不同的需求进行灵活配置。易于使用：Netty提供了简单易用的API和丰富的文档，可以帮助开发人员快速上手。社区活跃：Netty拥有一个活跃的社区，提供了丰富的第三方组件和解决方案，可以帮助开发人员快速解决各种网络编程问题。 - 说说业务中，Netty 的使用场景
高性能TCP服务器：Netty可以用于开发高性能、高并发的TCP服务器，可以支持数十万甚至百万级别的并发连接。分布式系统通信：Netty可以用于分布式系统之间的通信，支持多种协议的实现，包括HTTP、WebSocket等。实时通信系统：Netty可以用于开发实时通信系统，包括聊天系统、游戏服务器等。大规模数据采集：Netty可以用于大规模数据采集和传输，支持多种协议的实现，包括UDP、HTTP等。高性能代理服务器：Netty可以用于开发高性能的代理服务器，可以支持数万级别的并发连接。 - 原生的 NIO 在 JDK 1.7 版本存在 epoll bug
在JDK 1.7版本中，原生的NIO库存在epoll bug，会导致Selector空轮询，从而导致CPU使用率飙升和系统性能下降。这个bug主要是由于epoll的实现方式不同于其他操作系统，在Linux系统中会出现这种问题。为了解决这个问题，可以采用一些第三方的NIO库，如Netty等。 - 什么是TCP 粘包/拆包
TCP粘包/拆包是指在TCP传输过程中，由于数据包的大小和发送时机的不同，可能会导致发送方发送的多个数据包被接收方合并成一个数据包，或者一个数据包被拆分成多个数据包接收。这种情况会导致接收方无法正确解析数据，从而影响系统的稳定性和可靠性。 - TCP粘包/拆包的解决办法
固定长度：发送方在发送数据时，将所有数据按照固定的长度进行分割，接收方在接收数据时，按照固定长度进行拼接。特殊分隔符：发送方在发送数据时，在数据末尾添加特殊的分隔符，接收方在接收数据时，根据分隔符进行拆分。消息头：发送方在发送数据时，将数据长度信息作为消息头一起发送，接收方在接收数据时，先读取消息头，然后根据消息头中的长度信息进行拆分。 - Netty 线程模型
Netty的线程模型主要分为两种：传统的IO模型和基于EventLoop的NIO模型。传统的IO模型采用一个线程负责处理一个连接的读写操作，如果连接数过多，将会导致线程数过多，造成系统性能下降；而基于EventLoop的NIO模型采用多个EventLoop线程负责处理多个连接的读写操作，每个EventLoop线程处理多个连接，能够更好地利用CPU资源，提高系统的性能和可靠性。 - 说说 Netty 的零拷贝
Netty的零拷贝是指在数据传输过程中，避免了多次内存复制操作，从而提高了系统的性能。Netty的零拷贝主要通过以下两种方式实现FileRegion：在传输文件时，Netty采用FileRegion技术，将文件的内容直接发送到操作系统的内核缓冲区，避免了数据在用户态和内核态之间的复制。CompositeByteBuf：在传输字节流时，Netty采用CompositeByteBuf技术，将多个ByteBuf对象合并成一个复合的ByteBuf对象，避免了多次内存复制操作。 - Netty 内部执行流程
初始化：创建EventLoopGroup和Bootstrap对象，配置通道类型、编解码器、处理器等组件。绑定端口：调用Bootstrap对象的bind方法，将通道绑定到指定的端口。接收连接：当有新的连接请求时，Netty会创建一个新的Channel对象，并将其注册到EventLoop线程池中的某个EventLoop线程上。处理数据：当Channel对象接收到数据时，Netty会将数据转发给ChannelPipeline中的第一个处理器，然后依次经过ChannelPipeline中的各个处理器进行处理。关闭连接：当Channel对象关闭时，Netty会自动将其从EventLoop线程池中移除，并释放相关资源。 - Netty 重连实现
在 ChannelHandler 中添加一个 ChannelInactive 事件的处理逻辑，当连接断开时触发重连逻辑。在重连逻辑中，可以使用 ScheduledExecutorService 实现定时重连。当连接断开后，设置一个定时任务，在一定时间后重新尝试连接。在连接成功后，取消定时任务。可以使用一个计数器来记录尝试重连的次数，如果达到一定次数仍然无法连接，则停止重连。下面是一个简单的实现示例：下面是一个简单的实现示例：
java
public class ReconnectHandler extends ChannelInboundHandlerAdapter {
private final EventLoopGroup group;
private final Bootstrap bootstrap;
private final int maxRetries;
private Channel channel;
private int retries;
public ReconnectHandler(EventLoopGroup group, Bootstrap bootstrap, int maxRetries) {
this.group = group;
this.bootstrap = bootstrap;
this.maxRetries = maxRetries;
}
@Override
public void channelInactive(ChannelHandlerContext ctx) throws Exception {
if (retries < maxRetries) {
System.out.println("Lost connection, retrying...");
final EventLoop eventLoop = ctx.channel().eventLoop();
eventLoop.schedule(() -> {
try {
bootstrap.connect().addListener(new ChannelFutureListener() {
@Override
public void operationComplete(ChannelFuture future) throws Exception {
if (future.isSuccess()) {
System.out.println("Reconnected");
retries = 0;
channel = future.channel();
} else {
System.out.println("Failed to reconnect");
retries++;
channelInactive(ctx);
}
}
});
} catch (Exception e) {
System.out.println("Failed to reconnect: " + e.getMessage());
retries++;
channelInactive(ctx);
}
}, 5, TimeUnit.SECONDS);
} else {
System.out.println("Max retries reached, giving up");
ctx.close();
}
}
@Override
public void channelActive(ChannelHandlerContext ctx) throws Exception {
System.out.println("Connected");
retries = 0;
channel = ctx.channel();
super.channelActive(ctx);
}
}
在上面的示例中，ReconnectHandler 继承了 ChannelInboundHandlerAdapter，实现了 channelInactive 和 channelActive 方法。在 channelInactive 方法中，如果重连次数小于最大重连次数，会设置一个定时任务，在一定时间后重新尝试连接。在 channelActive 方法中，会记录连接成功后的 Channel 对象，以便在后续使用。
微服务篇
微服务
- 前后端分离是如何做的
前后端分离是指将前端和后端的开发分离出来，前后端可以独立开发、独立部署。前端负责展示界面、用户交互等，后端负责数据处理、业务逻辑等。前后端通过接口进行通信，前端通过调用后端提供的 API 获取数据，后端通过接收前端传递的数据进行业务处理，并返回数据给前端。前后端分离的实现可以通过以下步骤完成：1）确定前端和后端的开发团队，并明确各自的职责和工作内容。2）确定前后端接口的规范和格式，包括数据格式、接口地址、请求方法等。3）前端开发使用前端框架进行页面开发和数据展示，后端开发使用后端框架进行业务逻辑和数据处理。4）前端通过调用后端提供的 API 获取数据，后端通过接收前端传递的数据进行业务处理，并返回数据给前端。 - 微服务哪些框架
1）Spring Cloud：Spring Cloud 是基于 Spring Boot 的微服务框架，提供了服务发现、负载均衡、配置中心、断路器等功能。2）Dubbo：Dubbo 是阿里巴巴开源的微服务框架，提供了服务发现、负载均衡、服务治理等功能。3）Kubernetes：Kubernetes 是容器编排平台，可以用于部署和管理微服务应用。4）Consul：Consul 是一个服务治理框架，提供了服务发现、健康检查、负载均衡等功能。5）Zookeeper：Zookeeper 是一个分布式协调框架，可以用于服务发现和配置中心。 - 你怎么理解 RPC 框架
RPC（Remote Procedure Call，远程过程调用）是一种远程调用协议，它允许一个程序调用另一个程序的子程序，而不需要程序员显式编写远程调用代码。RPC 框架是实现 RPC 协议的框架，它可以简化远程调用的实现，提高调用效率和可靠性。RPC 框架通常包括以下组件：1）序列化/反序列化组件：将数据对象序列化为字节流，并将字节流反序列化为数据对象。2）传输协议组件：用于在客户端和服务端之间传输数据。3）代理组件：代理客户端和服务端的交互，隐藏底层的细节。4）注册中心组件：用于服务发现和服务注册，管理服务的地址和状态。 - 说说 RPC 的实现原理
RPC 的实现原理可以简单概括为以下几个步骤：1）客户端调用代理对象的方法，代理对象将调用信息封装为请求对象。2）请求对象通过序列化组件将其序列化为字节流。3）字节流通过传输协议组件传输到服务端。4）服务端接收到请求后，通过反序列化组件将请求对象反序列化为调用信息。5）服务端根据调用信息调用相应的服务方法，处理完请求后返回响应信息。6）响应信息通过序列化组件将其序列化为字节流。7）字节流通过传输协议组件传输到客户端。8）客户端接收到响应后，通过反序列化组件将响应信息反序列化为响应对象。 - 说说 Dubbo 的实现原理
Dubbo 的实现原理可以简单概括为以下几个步骤：1）服务提供者启动时，向注册中心注册自己提供的服务。2）服务消费者启动时，从注册中心订阅自己需要的服务。3）服务消费者通过代理类调用服务提供者的方法，代理类将调用信息封装为请求对象。4）请求对象通过序列化组件将其序列化为字节流。5）字节流通过传输协议组件传输到服务提供者。6）服务提供者接收到请求后，通过反序列化组件将请求对象反序列化为调用信息。7）服务提供者根据调用信息调用相应的服务方法，处理完请求后返回响应信息。8）响应信息通过序列化组件将其序列化为字节流。9）字节流通过传输协议组件传输到服务消费者。10）服务消费者接收到响应后，通过反序列化组件将响应信息反序列化为响应对象。
- 你怎么理解 RESTful
RESTful 是一种软件架构风格，它定义了一组约束条件和原则，用于设计和开发 web 服务。RESTful 架构风格是基于 HTTP 协议的，它使用 HTTP 方法来定义操作，使用 URI 来标识资源，使用 MIME 类型来表示数据格式，使用状态码表示操作结果。RESTful 架构风格的主要特点包括：1）客户端-服务器架构：客户端和服务器分离，分别处理自己的逻辑。2）无状态：每个请求都是独立的，服务器不会保存客户端的状态信息。3）可缓存性：客户端可以缓存资源，提高性能。4）统一接口：定义统一的接口，包括资源标识符、资源操作、资源表述等。5）分层系统：系统可以分为多个层，每个层都有自己的功能和责任。 - 说说如何设计一个良好的 API
）清晰的命名：使用简洁、明确的命名方式，避免使用缩写和单词缩写。2）统一的风格：保持 API 的风格一致，包括 URL、HTTP 方法、参数格式等。3）明确的返回格式：定义清晰的返回格式，包括状态码、错误信息、数据格式等。4）良好的文档：提供清晰、详细的文档，包括 API 的用途、参数说明、返回值说明等。5）安全性和可靠性：保障 API 的安全性和可靠性，包括身份验证、参数校验、异常处理等。6）版本管理：使用版本管理来管理 API 的变更和兼容性。7）性能和可扩展性：考虑 API 的性能和可扩展性，包括缓存、负载均衡、分布式等。 - 如何理解 RESTful API 的幂等性
RESTful API 的幂等性是指在对同一个资源进行多次相同请求操作时，其结果应该是相同的。也就是说，无论进行多少次相同的请求，对资源的状态都不会发生改变，也不会引起任何副作用。实现幂等性可以提高 API 的可靠性和稳定性，同时也方便开发者进行测试和调试。在设计和开发 RESTful API 时，需要考虑如何保证 API 的幂等性，通常可以采用以下几种方式：1.使用 HTTP 方法的幂等性：HTTP 协议中，GET 和 HEAD 方法是幂等的，而 PUT 和 DELETE 方法也应该是幂等的。2.使用唯一标识符：为每个资源分配一个唯一的标识符，例如 UUID，保证对同一个资源的多次操作都是相同的。3.使用版本控制：在更新资源时，使用版本控制机制，保证每次更新都是基于最新版本进行的，避免出现冲突和错误。4.使用重试机制：在某些情况下，可能由于网络或其他原因导致请求失败，此时可以使用重试机制，确保请求的幂等性。 - 如何保证接口的幂等性
唯一标识符：使用唯一标识符来识别每一个请求，如订单ID、会话ID等，确保同一标识符的请求只会执行一次。幂等性校验：在服务端对每个请求进行幂等性校验，判断该请求是否已经被执行过，如果已经被执行，则不再执行请求。Token机制：为每个请求生成一个Token，保证同一个Token的请求只会执行一次，同时可以记录Token的过期时间，过期后同一请求可以再次执行。重复请求过滤：在客户端进行请求时，对相同请求的重复请求进行过滤，确保相同的请求只会发送一次。数据库事务：对于需要修改数据库数据的操作，使用数据库事务进行处理，确保所有操作在一个事务中完成，避免重复操作。 - 说说 CAP 定理、 BASE 理论
CAP 定理是指在一个分布式系统中，无法同时保证一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）三个特性的完整性。具体来说，一致性指的是在任何时刻系统中的数据都是相同的，可用性指的是系统在任何时刻都能够提供正常服务，而分区容错性指的是系统能够继续工作即使在网络中断时发生了数据分区。由于满足 CAP 定理需要在三个特性之间做出平衡，因此在实际应用中需要考虑具体的业务需求和系统设计，从而在可接受的损失范围内调整三个特性的权衡。BASE 理论是对 CAP 定理的一个补充，它认为在一些大规模分布式系统中，非一致性、基本可用性、软状态（Soft state）和最终一致性（Eventually consistency）四个特性是可以接受的。其中，基本可用性指的是系统在出现故障时仍然能够保证可用；软状态是指系统中的数据会出现中间短暂的不一致，但在一定时间内会趋于一致；最终一致性则是指在一定时间内，系统中的数据最终会达到一致状态。BASE 理论强调了在大规模分布式系统中，一致性并不是绝对需要的，而是需要在各种因素和权衡之间取得平衡。 - 怎么考虑数据一致性问题
数据的可靠性：在多个节点的环境下，确保数据的正确性和完整性，让不同节点之间的数据达成一致。数据的可见性：在数据发布、访问、修改等过程中，要确保数据的可见性，让所有数据访问者都能看到正确的数据。数据的同步性：在分布式系统中，要确保各节点之间数据的同步性，避免出现数据不一致的现象。数据的可靠性：当某个节点出现故障时，要能够快速地恢复数据。 - 说说最终一致性的实现方案
基于版本控制的最终一致性方案：基于版本的最终一致性方案是一种实现方式，数据在更新时，每个节点都将保存一个版本号，基于特定的冲突解决策略，确保数据在每个节点上的最终状态是一致的。基于时间序列的最终一致性方案：基于时间序列的最终一致性方案是一种实现方式，数据在每个节点上都会有一个时间戳，当需要同步时，通过比较时间戳的方式，将数据同步到每个节点上。基于 CRDT 的最终一致性方案：CRDT（Conflict-free replicated data type）是指一类数据类型，该数据类型可以在多个节点上复制并保持数据一致，即使在节点之间存在网络分区或交互延迟的情况下，也能保证最终一致性。基于消息队列的最终一致性方案：消息队列可以在异步情况下，对多个节点之间的数据同步进行协调。当数据变化时，将变更的消息放入消息队列，通过队列来实现数据的同步。基于 Paxos 的最终一致性方案：Paxos 算法是一个经典的分布式共识算法，其实现方式可以实现最终一致性。在 Paxos 算法中，每个节点通过向其他节点发送消息来达成共识，确保最终所有节点都收到相同的数据。 - 你怎么看待微服务
微服务架构具有以下优点：高可伸缩性：每个微服务都是独立的，可以根据需要进行水平或垂直扩展，以应对流量的高峰。高灵活性：微服务架构可以让开发人员更加灵活地开发、部署和更新功能，而不需要整个应用都重新部署。易于维护：每个微服务都可以独立维护，使得故障排查和问题定位更加容易。技术栈多样性：不同的微服务可以使用不同的技术栈，因此可以选择最适合该服务的技术栈，从而提高服务的效率和性能。更好的团队协作：通过微服务架构，不同的开发团队可以分别负责不同的服务，避免出现功能耦合和代码冲突。但是，微服务架构也存在以下挑战：复杂性：微服务架构需要开发人员熟练掌握分布式系统、服务发现、容错处理等技术，因此对开发人员的技能要求更高。服务治理：微服务架构需要对服务进行监控、管理和调度，需要建立完善的服务治理机制。分布式事务：微服务架构可能涉及到多个服务之间的交互，因此需要考虑分布式事务的处理，以保证数据的一致性。 - 微服务与 SOA 的区别
规模：微服务通常是一组小型服务的集合，而SOA更多地是指企业范围内的服务组合。因此，微服务架构更加轻量级，服务粒度更细。独立性：微服务被设计为自治的服务，每个服务都有自己的数据存储、通信方式、部署模式等，因此服务之间的独立性更高。SOA中的服务则通常更加集中，依赖于中央的服务总线来协调服务之间的通信和数据共享。技术栈：微服务架构通常鼓励使用不同的技术栈，每个服务都可以使用最适合的技术栈。而SOA则通常要求使用同样的技术栈和标准，以确保服务的互操作性和共享性。部署：微服务的部署方式更加灵活，可以根据需要进行独立部署。而SOA中的服务通常要求在集中式的部署环境中进行部署。组织：微服务通常与小型、敏捷的开发团队相关联，这些团队负责一个或多个服务的开发和维护。而SOA通常是由更加成熟的企业架构团队设计和维护的。 - 如何拆分服务
基于业务领域：将服务按照业务领域进行划分，每个服务负责一个或多个相关的业务功能，如订单服务、用户服务、支付服务等。这种拆分方式可以帮助保持服务的内聚性和自治性，同时减少服务之间的耦合。基于数据隔离：将服务按照数据隔离的原则进行拆分，将数据相关的服务划分到同一服务中，避免数据在服务之间的混淆。例如，一个用户服务可以负责用户的信息管理，另一个订单服务可以负责订单的管理。基于功能模块：将服务按照功能模块进行拆分，每个服务负责一个或多个功能模块，如认证服务、日志服务、缓存服务等。这种拆分方式可以提高服务的复用性和可维护性，同时降低服务之间的耦合度。基于性能优化：将服务按照性能瓶颈进行拆分，将高负载、高并发的服务拆分到单独的服务中，提高服务的性能和可伸缩性。例如，将数据查询服务和数据写入服务分别拆分到不同的服务中，提高服务的并发能力。基于团队组织：将服务按照团队的组织方式进行拆分，每个团队负责一个或多个服务的开发和维护。这种拆分方式可以提高团队的自治性和责任感，同时减少服务之间的沟通和协调成本。 - 微服务如何进行数据库管理
每个服务都有自己的数据库：这是最常见的策略，每个服务都有自己的数据库，并且只能通过服务的 API 访问。这种策略可以提高服务的自治性和独立性，同时避免数据库之间的耦合。但是这种策略也会带来一些数据一致性和数据迁移的问题。公用一个数据库：将多个服务的数据存储在同一个数据库中，通过服务的 API 进行访问。这种策略可以提高数据一致性和减少数据冗余，但是会带来一些数据库之间的耦合。使用数据库复制和同步：使用数据库复制和同步技术，将多个服务的数据库复制到多个节点中，保证数据的高可用性和数据一致性。这种策略可以提高数据的可用性和一致性，但是会带来一些数据同步的延迟和成本。使用分布式事务：使用分布式事务技术来保证数据的一致性，将多个服务的数据库操作放在同一个事务中进行。这种策略可以保证数据的一致性，但是会带来一些性能和复杂性的问题 - 如何应对微服务的链式调用异常
隔离服务：为每个服务建立独立的容器和网络环境，确保服务之间的隔离和安全性。这可以防止一个服务的异常影响到其他服务的正常运行。断路器：使用断路器模式来保护链式调用，当一个服务出现异常时，断路器会快速切断该服务的请求，并返回一个预先定义的错误响应。这可以避免因为一个服务的异常而导致整个链式调用的失败。降级：当一个服务出现异常时，可以使用降级策略来替代原有的服务，返回一个类似但更简单的响应。这可以保证服务的可用性和可靠性，但是可能会影响服务的功能和性能。重试：当一个服务出现异常时，可以尝试重新调用该服务，直到请求成功或达到最大重试次数。这可以提高服务的可用性，但也可能会带来一些性能和延迟的问题。监控和日志：建立完善的监控和日志系统，及时发现和记录服务的异常和错误信息，并进行分析和优化。这可以帮助提高服务的稳定性和可维护性，减少出现异常的可能性。 - 对于快速追踪与定位问题
监控和日志系统：建立完善的监控和日志系统，记录软件系统运行的各种指标和事件。通过监控和日志系统，可以及时发现和诊断系统问题，并快速定位问题所在。APM（Application Performance Management）工具：APM工具可以监测和分析应用程序性能，识别和定位性能问题。它们可以提供各种度量和指标，包括响应时间、吞吐量、错误率、资源使用等。一些流行的APM工具包括New Relic、AppDynamics、Dynatrace等。Debug工具：使用Debug工具可以帮助程序员追踪和分析代码中的问题。一些流行的Debug工具包括GDB、Eclipse Debugger、Visual Studio Debugger等。Profiler工具：Profiler工具可以帮助程序员分析应用程序的性能瓶颈和瓶颈所在。它们可以提供函数调用的时间和内存占用等信息。一些流行的Profiler工具包括Java VisualVM、Gprof、perf等。Tracing工具：Tracing工具可以追踪程序在运行过程中的各个步骤，以及它们之间的相互作用。一些流行的Tracing工具包括Dapper、Zipkin、Jaeger等。 - 微服务的安全
认证和授权：微服务需要对其服务进行身份验证和授权，以确保只有授权的用户或服务可以访问它们。常见的身份验证和授权协议包括OAuth、JWT和SAML等。数据加密：微服务通常需要加密来保护敏感数据。应该使用适当的加密算法和密钥管理策略来保护数据。常用的加密算法包括AES和RSA等。网络安全：微服务架构通常需要通过网络进行通信，因此需要采取一些安全措施来保护网络。包括网络隔离、TLS/SSL等。服务发现和注册：微服务需要一个服务发现和注册机制来确保安全性。服务发现机制可以防止未授权的服务访问，并确保服务能够正常运行。日志和审计：监控和审计系统可以追踪每个微服务的活动，以便在发生安全事件时进行快速定位和调查。此外，日志和审计还可以帮助识别安全漏洞和异常行为。
分布式
- 谈谈业务中使用分布式的场景
分布式系统在处理大规模数据、高并发访问和高可用性等方面具有优势。在业务中使用分布式的场景包括：大流量的网站、分布式计算系统、数据分析和挖掘系统、大规模的物联网系统、云计算系统等。 - Session 分布式方案
在分布式环境中，如果用户的请求在不同的服务器之间进行切换，那么 Session 会丢失。因此，需要一种 Session 分布式方案来保证在不同的服务器之间共享 Session 数据。常见的 Session 分布式方案包括：基于 Cookie、基于数据库、基于缓存集群、基于网络会话等。 - 分布式锁的场景
分布式锁通常用于控制分布式环境中的资源访问。常见的分布式锁场景包括：分布式任务调度、分布式定时任务、分布式事务、分布式缓存等。 - 分布是锁的实现方案
分布式锁的实现方案包括：基于数据库、基于缓存、ZooKeeper 等。在分布式环境中，基于缓存和 ZooKeeper 的实现方案被广泛采用。 - 分布式事务
分布式事务通常在不同的服务器之间共享数据时使用。分布式事务需要确保数据的原子性、一致性、隔离性和持久性。通常采用的分布式事务方案包括：XA 协议、TCC 协议、SAGA 协议等。 - 集群与负载均衡的算法与实现
集群和负载均衡常用于提高系统的可用性和扩展性。常见的负载均衡算法包括：轮询、随机、加权轮询、加权随机、最少连接等。常用的负载均衡工具包括：Nginx、HAProxy 等。 - 说说分库与分表设计
分库与分表设计通常用于解决单表数据量过大的问题。分库与分表的设计需要考虑到数据的分布、查询的效率、事务的一致性等问题。在实际应用中，通常采用的方案包括：垂直分库、水平分库、垂直分表、水平分表等。 - 分库与分表带来的分布式困境与应对之策
分库与分表会带来一些分布式困境，如跨节点 Join、全局主键生成、事务一致性等问题。常见的解决方案包括：数据冗余、分布式缓存、分布式锁、最终一致性等。同时，需要在架构设计、开发、测试和运维等多个方面做好分布式系统的管理和维护。
安全&性能
安全问题
- 安全要素与 STRIDE 威胁
安全要素包括机密性、完整性、可用性、可靠性和可审计性。STRIDE威胁模型包括以下6个方面：Spoofing、Tampering、Repudiation、Information Disclosure、Denial of Service、Elevation of Privilege。在应对各种威胁时，需要根据具体情况考虑应用哪些安全要素和采用什么策略进行防范和控制。 - 防范常见的 Web 攻击
常见的Web攻击包括跨站脚本攻击（XSS）、跨站请求伪造（CSRF）、SQL注入攻击、文件包含攻击等。防范这些攻击的方法包括输入验证、输出编码、限制访问权限、避免暴露敏感信息等。 - 服务端通信安全攻防
服务端通信安全攻防需要采用一些安全措施来保护通信的安全性，例如使用加密协议（如SSL/TLS）、验证客户端身份、防范中间人攻击等。 - HTTPS 原理剖析
HTTPS使用了SSL/TLS协议来加密HTTP通信，其基本原理是在传输层对HTTP协议进行加密和认证。HTTPS的安全性主要依赖于SSL/TLS协议的安全性，其采用了非对称加密、对称加密、消息摘要等多种安全算法来保护通信的安全性。 - HTTPS 降级攻击
HTTPS降级攻击是一种利用中间人攻击的方法，通过劫持加密通道并欺骗客户端与服务端之间建立非加密的通信来进行攻击。防范这种攻击的方法包括使用HSTS（HTTP Strict Transport Security）、检查证书有效性等。 - 授权与认证
授权和认证是保证系统安全的关键要素，认证用于确认用户的身份，授权用于确定用户对系统资源的访问权限。常见的认证方法包括密码认证、令牌认证、双因素认证等，常见的授权方法包括基于角色的访问控制和基于数据的访问控制 - 基于角色的访问控制
基于角色的访问控制是指根据用户的角色来确定其对系统资源的访问权限。该方法可以有效地简化权限管理，减少管理成本。实现方法包括建立角色和权限的映射关系、将用户授权给特定角色等。 - 基于数据的访问控制
基于数据的访问控制是指在授权时根据数据的属性和内容来限制用户对数据的访问权限。这种访问控制方法可以更精细地控制用户对数据的访问，使得系统更加安全。基于数据的访问控制通常需要以下步骤：定义数据的属性和内容：需要确定数据的敏感度、访问控制等级以及其他相关属性。制定访问策略：根据数据的属性和内容，确定访问策略，如仅允许授权用户访问、仅允许在特定时间段内访问、仅允许访问特定的数据字段等。实现数据访问控制：可以采用数据库层面的访问控制，如视图、存储过程等，也可以采用应用层面的访问控制，如通过代码逻辑实现访问控制。监控和审计数据访问：需要实时监控数据的访问情况，及时发现异常访问行为，并对访问行为进行审计，以便追踪和排查数据泄露和其他安全问题
性能优化
- 性能指标有哪些
- 如何发现性能瓶颈
使用性能分析工具：可以使用各种性能分析工具，如Profiling工具、性能监视器等，通过对程序的CPU、内存、IO、网络等方面进行监测和分析，找到性能瓶颈所在。进行代码审查：可以对代码进行审查，找出可能会影响性能的代码段，并进行优化。比如，是否存在多余的循环、过于频繁的IO操作等。进行基准测试：可以针对程序中的各个模块进行基准测试，比较不同模块的性能差异，并找出哪些模块存在性能瓶颈。日志分析：可以通过日志来分析程序在运行时的情况，比如某个接口的响应时间、某个功能的访问量等，以便找出程序的性能瓶颈。硬件监测：可以监测服务器的CPU、内存、磁盘、网络等硬件指标，以便找出是否存在硬件瓶颈，如CPU使用率过高等。 - 性能调优的常见手段
代码优化：通过对代码进行优化，比如消除重复计算、避免过度的IO操作、使用高效的数据结构等，来提高程序的运行效率。数据库优化：数据库是大多数应用程序的核心组件，优化数据库可以显著提高程序的性能。比如，使用索引、优化查询语句、避免全表扫描等。缓存优化：合理使用缓存可以显著提高程序的性能。比如，使用本地缓存、分布式缓存、页面缓存等。硬件优化：硬件优化可以提高程序的运行效率，比如更换高性能CPU、增加内存、使用SSD硬盘等。并发优化：优化程序的并发能力可以提高程序的性能。比如，使用线程池、使用异步编程、合理地进行分布式架构等。代码审查：通过对代码的审查，找出程序中可能存在的性能瓶颈，并进行优化。性能测试：通过性能测试，找出程序的性能瓶颈，并进行优化。 - 说说你在项目中如何进行性能调优
测试和分析：首先需要对程序进行测试，并分析测试结果。通过对程序的运行时间、CPU和内存使用情况、网络IO等方面进行监测，找出可能存在的性能瓶颈。找出瓶颈：根据测试和分析结果，找出程序中存在的性能瓶颈。可能是代码中存在的性能问题，也可能是数据库、网络等外部组件的性能问题。优化方案：根据性能瓶颈找出的问题，制定相应的优化方案。可以考虑从代码优化、数据库优化、缓存优化、硬件优化等方面入手，确定优化目标和优化方式。实施优化：根据优化方案，对程序进行相应的优化。可能需要对代码进行优化、更改数据库索引、增加缓存等。再次测试：对程序进行再次测试，验证优化效果。比较优化前后的运行时间、CPU和内存使用情况、网络IO等方面的数据，看是否有明显的提升。持续监测：即使优化完成，也需要持续监测程序的性能，及时发现可能存在的新问题，并进行优化。 需要注意的是，性能调优需要根据具体情况制定方案，不同项目的性能瓶颈和优化方式可能不同。同时，需要注意优化前后程序的正确性和稳定性，避免优化过度导致新的问题。
工程篇
需求分析
- 你如何对需求原型进行理解和拆分
理解需求原型需要从多个角度入手，比如从用户角度、业务角度、技术角度等。我会首先对需求原型进行整体的了解和分析，然后逐步拆分成更加详细的需求，并将其细化为功能性需求和非功能性需求。同时，我也会对需求原型中存在的风险和问题进行分析和识别，并采取相应的措施进行解决和改进。 - 说说你对功能性需求的理解
功能性需求指产品必须要实现的功能，这些功能通常是用户直接能够感知和使用的。对于功能性需求，我会在拆分需求的过程中尽可能的详细和具体，明确需求的输入、输出和处理流程，并对每个需求进行适当的优先级排序和细化，以确保产品能够完整、正确、高效地实现所有功能。 - 说说你对非功能性需求的理解
非功能性需求指产品的性能、安全、可用性等方面的要求。这些需求通常是用户不直接感知到的，但对产品的质量和用户体验有重要的影响。对于非功能性需求，我会结合产品特点和用户需求，对不同的需求进行权衡和分析，制定合理的实现方案和测试方案，确保产品能够满足用户的期望和需求。 - 你针对产品提出哪些交互和改进意见
对于产品的交互和改进，我会从用户角度出发，对产品的使用流程、界面布局、功能实现等方面进行评估和分析，找出问题所在，并提出相应的改进意见和建议。同时，我也会参考市场上的同类产品和用户反馈，汲取优秀的设计思路和实践经验，提高产品的用户体验和市场竞争力。 - 你如何理解用户痛点
用户痛点是指用户在使用产品过程中遇到的困难、疑虑、不满意等问题。我会通过用户调研、用户反馈、产品数据等渠道，了解用户的痛点和需求，并将其作为优化和改进产品的关键点。同时，我也会通过对用户痛点的分析和总结，提高自己对产品的设计和优化能力，不断提升产品的用户体验和市场价值。
设计能力
- 说说你在项目中使用过的 UML 图
用例图：用于描述系统的功能需求，以及各个用例之间的关系和依赖。类图：用于描述系统中各个类的属性和方法，以及类之间的关系，包括继承、聚合、关联等。时序图：用于描述系统中各个对象之间的交互和消息传递，以及时序关系。活动图：用于描述系统中各个流程和活动的执行过程，以及流程中的各种判断和条件。状态图：用于描述系统中各个对象的状态和状态之间的转换，以及状态转换的触发条件和动作。部署图：用于描述系统的物理部署结构，包括各个节点之间的关系和通信方式。 - 你如何考虑组件化
模块化设计：将整个系统按照模块进行划分，每个模块都有自己的职责和功能，并且模块之间通过定义接口进行通信。这样做可以保证模块之间的高内聚低耦合。组件库：将一些通用的功能封装成组件，例如登录组件、分页组件、表单组件等，以便在不同的系统中进行复用。代码规范和标准化：对于不同的组件，要求开发人员使用同一种编码规范和标准化，以便在后期进行维护和升级时，代码风格保持一致。单元测试：对于每个组件都需要进行单元测试，保证其功能正确性和稳定性。版本控制：对于每个组件都需要进行版本控制，以便在后期进行升级或者回滚时，能够快速定位到所需要的版本。文档化：对于每个组件都需要进行文档化，包括其功能、接口、使用方法等，以便其他开发人员可以快速了解和使用组件。 - 你如何考虑服务化
划分服务边界：在进行服务化之前，需要对系统进行边界划分，将不同的功能模块划分为不同的服务。这需要考虑到系统的业务逻辑、数据流向、耦合度等因素。设计服务接口：每个服务都应该有明确的接口和协议，用于与其他服务进行通信。在设计服务接口时，需要考虑到接口的稳定性、兼容性和可扩展性。选择合适的通信协议：不同的服务之间需要进行通信，因此需要选择合适的通信协议，如HTTP、RPC等。在选择通信协议时，需要考虑到协议的稳定性、性能、安全性等因素。管理服务注册和发现：在系统中存在大量的服务，因此需要进行服务的注册和发现，以便其他服务能够找到它们。可以使用服务注册中心或者配置中心等工具来管理服务的注册和发现。保证服务的高可用性：由于系统中的服务数量众多，因此需要保证服务的高可用性。可以使用负载均衡、容错机制等方法来保证服务的可靠性和可用性。 - 你如何进行领域建模
建立领域模型：我们可以根据业务流程和业务实体建立领域模型，包括实体、属性、关系等。这可以帮助我们更好地理解业务，把握业务逻辑。划分职责：在建立领域模型的基础上，我们可以根据领域模型中的实体、属性、关系等，划分出不同的职责，明确各个模块的职责和功能。识别业务规则：我们可以通过领域建模，识别出业务流程中的各种规则，如数据校验规则、业务流程规则等，从而更好地保证系统的正确性和可靠性。进行迭代开发：在建立领域模型和识别业务规则的基础上，我们可以进行迭代开发，逐步完善系统功能和业务规则。 - 你如何划分领域边界
根据业务流程进行划分：我们可以根据业务流程，将业务流程中的不同部分划分成不同的领域，每个领域处理不同的业务流程。这样可以更好地保证系统的职责划分清晰。根据业务实体进行划分：我们可以将业务实体划分成不同的领域，每个领域处理不同的业务实体。这样可以更好地保证数据结构和数据流动的清晰和可控性。根据业务能力进行划分：我们可以将系统的各个模块按照其业务能力进行划分，每个模块负责不同的业务能力。这样可以更好地保证系统的模块划分清晰。根据团队能力进行划分：我们可以将系统的各个模块按照团队的能力进行划分，每个团队负责不同的模块。这样可以更好地保证系统的开发效率和质量。 - 说说你项目中的领域建模
在我参与的项目中，我们通过领域建模来更好地理解业务，梳理业务流程，划分模块边界，从而更好地进行系统设计和开发。我们通常采用 UML 中的用例图、活动图、类图和时序图等来进行领域建模。首先，我们会根据需求和业务流程，用用例图对业务进行建模，以明确系统的业务目标和涉及到的各方利益相关者。在用例图中，我们会定义各种用例，包括主要用例和次要用例，以及各种参与者。然后，我们使用活动图来进一步描述用例的执行流程，包括用例的各个步骤、条件和分支等，以帮助我们更好地理解业务流程。接着，我们使用类图来描述系统的数据结构和类之间的关系，以帮助我们更好地设计系统的数据模型和各个模块之间的协作关系。最后，我们使用时序图来描述系统中各个对象之间的交互，以帮助我们更好地理解系统的交互流程和消息传递方式。通过领域建模，我们可以更好地理解业务需求，梳理业务流程，划分模块边界，从而为系统的设计和开发提供更好的指导。 - 说说概要设计
概要设计的目的概要设计的主要目的是将需求转换为可执行的软件方案，并提供设计者进行详细设计和编码的依据。它的任务是在需求的基础上，定义系统的体系结构、模块划分、模块之间的接口和数据结构等。概要设计的内容概要设计通常包括以下内容：系统的体系结构：指出系统的总体结构、组件之间的关系以及如何满足系统的需求。模块划分：将系统按照不同的功能划分为不同的模块。接口定义：定义模块之间的接口，包括函数接口、数据结构接口等。数据结构设计：设计系统中使用的各种数据结构，包括数据库表结构、文件结构等。系统的性能、安全、可靠性等方面的设计：考虑系统的性能、安全、可靠性等非功能性需求，制定相应的设计方案。我的做法在进行概要设计时，我通常会采用如下步骤：了解需求：在开始概要设计前，我会认真阅读需求文档，了解系统的需求和功能。设计系统的体系结构：在设计系统体系结构时，我会考虑系统的可扩展性、可维护性、可靠性和安全性等因素。划分模块：我会根据系统的功能和需求，将系统分解成多个模块，并明确每个模块的职责和功能。定义接口：在定义模块之间的接口时，我会尽可能地减少接口的复杂度，并保证接口的兼容性和可扩展性。设计数据结构：我会根据系统的需求，设计合适的数据结构，并考虑数据的安全性和可靠性。考虑非功能性需求：在进行系统性能、安全、可靠性等方面的设计时，我会充分考虑系统的特点和需求，设计出相应的方案。总之，在进行概要设计时，我会充分考虑系统的需求和特点，并根据实际情况制定相应的设计方案，确保系统的可靠性、安全性和可维护性等方面得到保证。
设计模式
- 你项目中有使用哪些设计模式
单例模式：确保系统中某个类只有一个实例，例如数据库连接池、日志管理等；工厂模式：根据需求动态创建对象，例如配置文件解析器、数据访问对象等；观察者模式：定义对象间的一对多依赖关系，使得每当一个对象改变状态，则所有依赖它的对象都会得到通知并自动更新；策略模式：定义一系列算法，将每个算法都封装起来，并且使它们可以互换；模板方法模式：定义一个操作中的算法骨架，将一些步骤延迟到子类中，使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。 - 说说常用开源框架中设计模式使用分析
Spring 框架中使用了工厂模式、代理模式、装饰器模式、适配器模式、单例模式等，其中最为显著的是依赖注入（DI）和面向切面编程（AOP），两者都采用了代理模式。Hibernate ORM 框架使用了工厂模式、代理模式、单例模式等，其中最为显著的是对象关系映射（ORM）模式，即将对象和数据库中的表之间建立映射关系，使得可以使用面向对象的方式操作数据库。MyBatis 框架使用了工厂模式、代理模式等，其中最为显著的是对象关系映射（ORM）模式，与 Hibernate 不同的是，MyBatis 采用了半自动化的方式，即通过 SQL 映射文件定义 SQL 语句和参数，再使用代码中的接口调用。Netty 框架使用了观察者模式、模板方法模式等，其中最为显著的是事件驱动模型，即通过观察者模式实现对事件的监听和处理，同时也采用了模板方法模式来简化网络编程。 - 说说你对设计原则的理解
设计原则是指在软件设计中，针对不同的需求和场景，提出的一些通用性的规范、约束或指导思想，以保证软件设计具有可维护性、可扩展性、可复用性等良好的软件质量属性。常见的设计原则包括 SOLID 原则、DRY 原则、KISS 原则、YAGNI 原则等。 - 23种设计模式的设计理念
可以将23种设计模式分为创建型模式、结构型模式、行为型模式三大类。创建型模式：用于描述对象的创建方式，主要包括工厂模式、抽象工厂模式、建造者模式、原型模式和单例模式。结构型模式：用于描述对象之间的关系，主要包括适配器模式、桥接模式、组合模式、装饰者模式、外观模式、享元模式和代理模式。行为型模式：用于描述对象之间的通信方式和协作方式，主要包括责任链模式、命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板方法模式和访问者模式。工厂方法模式（Factory Method）：定义一个用于创建对象的接口，让子类决定将哪一个类实例化。使一个类的实例化延迟到其子类。抽象工厂模式（Abstract Factory）：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。单例模式（Singleton）：保证一个类仅有一个实例，并提供一个访问它的全局访问点。建造者模式（Builder）：将一个复杂对象的构建与其表示分离，使得同样的构建过程可以创建不同的表示。原型模式（Prototype）：用原型实例指定创建对象的种类，并通过拷贝这些原型创建新的对象。适配器模式（Adapter）：将一个类的接口转换成客户希望的另一个接口。使得原本由于接口不兼容而不能一起工作的类可以一起工作。桥接模式（Bridge）：将抽象部分与实现部分分离，使它们可以独立变化。组合模式（Composite）：将对象组合成树形结构以表示“部分-整体”的层次结构，使得客户端对单个对象和组合对象的使用具有一致性。装饰模式（Decorator）：动态地给一个对象添加一些额外的职责，就增加功能而言，装饰模式比生成子类更为灵活。外观模式（Facade）：为子系统中的一组接口提供一个一致的界面，使得子系统更加容易使用。享元模式（Flyweight）：运用共享技术来有效地支持大量细粒度对象的复用。代理模式（Proxy）：为其他对象提供一种代理以控制对这个对象的访问。职责链模式（Chain of Responsibility）：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。命令模式（Command）：将一个请求封装成一个对象，从而可以用不同的请求对客户进行参数化。使得请求的命令对象和接收者对象分离，从而可以支持命令的撤销和重做。解释器模式（Interpreter Pattern）是一种行为型设计模式，它定义了一种语言的文法，并且定义了一个解释器用于解释这个语言中的句子。该模式中的解释器通过使用一些类表示文法规则的元素来解析句子。解释器模式可以用于自然语言处理、编译器、计算器等领域。迭代器模式（Iterator）：提供一种方法来访问聚合对象中各个元素，而不用暴露其内部的表示方法。中介者模式（Mediator）：定义一个中介对象来封装一系列对象之间的交互，使各对象不需要显示地互相作用，从而使耦合松散，而且可以独立地改变它们之间的交互。备忘录模式（Memento）：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可以将该对象恢复到原先保存的状态。观察者模式（Observer）：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。状态模式（State）：允许对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。策略模式（Strategy）：定义一系列算法，将它们封装起来，并使它们可以相互替换。本模式使得算法可以独立于使用它的客户而变化。模板方法模式（Template Method）：定义一个操作中算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重新定义该算法的某些特定步骤。 - 设计模式之间的异同，例如策略模式与状态模式的区别
策略模式（Strategy）和状态模式（State）的主要区别在于它们的目的不同：策略模式是通过定义一系列算法来完成某个任务，并且在运行时动态地选择适合的算法来执行，从而实现灵活性和扩展性。状态模式是通过定义一系列状态来描述对象的行为，并且在运行时动态地切换状态，从而实现不同状态下的行为变化。具体来说，策略模式通常用于解决算法的选择问题，例如排序算法、搜索算法等等。而状态模式通常用于解决状态转换问题，例如电视机的开关状态、交通信号灯的变化等等。此外，策略模式和状态模式在实现上也有所不同。策略模式通常是通过定义一个接口来封装算法，然后让具体的算法类实现这个接口，并且在运行时动态地选择算法。而状态模式通常是通过定义一个抽象状态类和具体状态类来描述对象的行为，并且在运行时动态地切换状态。 - 设计模式之间的结合，例如策略模式+简单工厂模式的实践
策略模式和简单工厂模式是两种常用的设计模式，它们可以结合使用，以提高代码的可维护性和扩展性。具体的实践方式是在简单工厂模式的基础上，使用策略模式来实现具体的业务逻辑。简单工厂模式负责根据不同的参数返回不同的策略实现对象，而策略模式则负责对具体的业务逻辑进行抽象和封装。举例来说，假设我们有一个电商平台，需要根据不同的促销策略来计算订单的优惠金额。我们可以先定义一个促销策略的接口，例如：public interface PromotionStrategy { BigDecimal calculateDiscount(BigDecimal totalAmount);}然后，针对不同的促销策略，我们实现具体的策略类，例如：public class FullReductionPromotionStrategy implements PromotionStrategy { // 满减优惠活动 @Override public BigDecimal calculateDiscount(BigDecimal totalAmount) { // 具体的计算逻辑 }}public class DiscountPromotionStrategy implements PromotionStrategy { // 折扣优惠活动 @Override public BigDecimal calculateDiscount(BigDecimal totalAmount) { // 具体的计算逻辑 }}接下来，我们可以使用简单工厂模式来根据不同的促销策略参数返回对应的策略对象。例如：public class PromotionStrategyFactory { public static PromotionStrategy getPromotionStrategy(String promotionType) { if ("full_reduction".equals(promotionType)) { return new FullReductionPromotionStrategy(); } else if ("discount".equals(promotionType)) { return new DiscountPromotionStrategy(); } else { throw new IllegalArgumentException("Unknown promotion type: " + promotionType); } }}最后，我们在订单类中使用促销策略对象来计算订单的优惠金额：public class Order { private BigDecimal totalAmount; private PromotionStrategy promotionStrategy; public Order(BigDecimal totalAmount, String promotionType) { this.totalAmount = totalAmount; this.promotionStrategy = PromotionStrategyFactory.getPromotionStrategy(promotionType); } public BigDecimal calculateDiscountAmount() { return promotionStrategy.calculateDiscount(totalAmount); }}通过这种方式，我们可以很方便地扩展新的促销策略，并且将具体的业务逻辑和框架代码分离开来，提高代码的可维护性和扩展性 - 设计模式的性能，例如单例模式哪种性能更好。
设计模式的性能表现因实现方式和具体应用场景而异，因此不能一概而论。下面以单例模式为例，介绍两种实现方式的性能比较。在单线程环境中，饿汉式单例模式的性能要优于懒汉式单例模式。因为在饿汉式单例模式中，实例在类加载时就已经被创建，因此在调用时无需加锁等操作，直接返回实例即可。而在懒汉式单例模式中，需要通过加锁等机制来保证线程安全，因此在高并发环境下会有性能瓶颈。然而，在多线程环境下，饿汉式单例模式会出现线程安全问题。因为在多线程环境下，多个线程可能会同时访问getInstance()方法，从而创建多个实例。而懒汉式单例模式则通过加锁等机制来保证线程安全，因此在多线程环境下更为可靠。 - 单例模式实现
饿汉式单例模式public class Singleton { private static final Singleton INSTANCE = new Singleton(); private Singleton() { // private constructor } public static Singleton getInstance() { return INSTANCE; }}懒汉式单例模式public class Singleton { private static Singleton INSTANCE; private Singleton() { // private constructor } public static synchronized Singleton getInstance() { if (INSTANCE == null) { INSTANCE = new Singleton(); } return INSTANCE; }}双重校验锁单例模式public class Singleton { private static volatile Singleton INSTANCE; private Singleton() { // private constructor } public static Singleton getInstance() { if (INSTANCE == null) { synchronized (Singleton.class) { if (INSTANCE == null) { INSTANCE = new Singleton(); } } } return INSTANCE; }}静态内部类单例模式public class Singleton { private Singleton() { // private constructor } private static class SingletonHolder { private static final Singleton INSTANCE = new Singleton(); } public static Singleton getInstance() { return SingletonHolder.INSTANCE; }}枚举单例模式public enum Singleton { INSTANCE; public void doSomething() { // do something }}ThreadLocal单例模式：public class Singleton { private static final ThreadLocal<Singleton> INSTANCE_THREAD_LOCAL = new ThreadLocal<Singleton>() { @Override protected Singleton initialValue() { return new Singleton(); } }; private Singleton() {} public static Singleton getInstance() { return INSTANCE_THREAD_LOCAL.get(); }}
业务工程
- 你系统中的前后端分离是如何做的
在前后端分离的架构下，前端和后端是分开独立开发的。前端主要负责界面和交互的开发，后端主要负责业务逻辑和数据的处理。我在之前的项目中采用了前后端分离的架构。具体实现上，我们使用了 Vue.js 作为前端框架，使用 Spring Boot 作为后端框架，前后端之间通过 RESTful API 进行通信。前端和后端的开发是并行进行的，前端可以在后端还未完成开发的情况下先进行开发，而后端则可以在前端还未完成开发的情况下先进行开发，这样可以大大提高开发效率 - 说说你的开发流程
我的开发流程通常是先进行需求分析，了解用户需求，确定产品功能。然后进行系统设计，根据需求设计系统架构和模块划分。接下来是编写代码，我们采用敏捷开发的方法，采用迭代开发，每个迭代周期通常为两周，根据产品需求和客户反馈进行迭代优化。在编写代码时，我通常遵循代码规范和设计原则，保证代码的可读性和可维护性。最后是测试和部署，我们采用自动化测试工具进行测试，并使用 Docker 进行应用的打包和部署。 - 你和团队是如何沟通的
日常会议：我们会每日举行短暂的站立会议，讨论每个人的工作进展和遇到的问题。远程会议：如果有需要，我们也会进行远程会议，讨论一些需要讨论的事项。代码评审：在进行代码评审时，我们会对代码的质量和设计进行讨论，交流各自的看法和建议。项目管理工具：我们使用项目管理工具来跟踪任务和进度，通过这种方式来确保团队成员之间的协作和沟通。 - 你如何进行代码评审
代码风格是否符合规范；代码逻辑是否清晰易懂；是否有注释或文档说明，代码是否易于维护；是否有潜在的性能问题或安全隐患。我会将以上内容与公司制定的开发规范进行比对，给出具体的改进意见和建议。同时，我也会注重评审的及时性和有效性，以保证开发工作的进度和质量。 - 说说你对技术与业务的理解
技术和业务是相辅相成的，技术是为了服务于业务。我认为技术是实现业务的手段，而业务是技术的目的。一个成功的项目需要技术和业务的双重支持，技术能够为业务提供解决方案，而业务需求也是技术的驱动力。 - 说说你在项目中经常遇到的 Exception
在项目开发中，我经常遇到的 Exception 包括：空指针异常、数组越界异常、类型转换异常、数据库访问异常等。这些异常通常都是由于代码逻辑不当、输入参数异常、资源不足等原因引起的。为了尽可能避免这些异常的发生，我通常会进行代码审查和测试，同时加入必要的异常处理机制来提高代码的健壮性和容错性。 - 说说你在项目中遇到感觉最难Bug，怎么解决的
在一个项目中，我遇到过一个感觉最难的 bug，它表现为程序在特定情况下会崩溃，而且出错时没有任何提示信息。我尝试了很多种方法来解决这个问题，包括加入日志输出、增加断点调试、逐步排除等。最终，我在代码中发现了一个并发问题，通过加入同步机制来解决了这个问题。这个经历让我深刻认识到了多线程程序开发的重要性，也让我更加注重对多线程程序的测试和调试。 - 说说你在项目中遇到印象最深困难，怎么解决的
在一个大数据分析的项目中，需要处理数十亿条数据，并生成相应的报表和图表。我们发现在处理数据时，代码效率非常低，大量时间花费在循环处理上，导致整个系统性能下降。经过多次优化，我们使用了多线程和分布式计算来提升效率，最终解决了这个问题。 - 你觉得你们项目还有哪些不足的地方
在我们的项目中，有时候我们过于专注于功能实现，忽略了代码的可读性和可维护性，导致在后期维护和升级时遇到了很多困难。因此，我们在后续开发中更加注重代码规范和可读性，以提高代码的可维护性和可扩展性。 - 你是否遇到过 CPU 100% ，如何排查与解决
在遇到 CPU 100% 的情况时，我们首先需要定位是哪些进程或线程占用了 CPU 资源。可以使用一些工具如 top、htop、ps 等来查看系统进程和资源占用情况。定位到具体的进程或线程后，可以使用一些工具如 perf、strace 等来进行进一步的分析和排查。针对具体问题可以使用一些优化手段如线程池、缓存、减少锁的竞争等来解决问题。 - 你是否遇到过 内存 OOM ，如何排查与解决
在遇到内存 OOM 的情况时，我们首先需要定位是哪些进程或线程占用了过多的内存资源。可以使用一些工具如 top、htop、ps 等来查看系统进程和资源占用情况。定位到具体的进程或线程后，可以使用一些工具如 jmap、jstat、jstack 等来进行进一步的分析和排查。常见的内存泄漏问题可以通过及时释放对象、避免不必要的对象创建、使用缓存等优化手段来解决问题。 - 说说你对敏捷开发的实践
遵循了一些核心原则，比如频繁的迭代、持续的集成、以用户为中心等等。我们也使用了一些敏捷开发工具，如Jira、Confluence和Slack等等，来促进团队协作和项目管理。我们的团队也尝试不断地改进我们的工作流程和实践，例如采用Scrum方法管理迭代，进行技术评审和Code Review，定期召开Review会议来讨论项目进展和遇到的问题等等。通过这些实践，我们的团队不断提高了软件开发的效率和质量。 - 说说你对开发运维的实践
我认为开发运维是一个不可分割的整体，它们之间需要紧密协作，以确保软件开发的成功。在我的经验中，我们的开发团队和运维团队之间有着密切的合作，我们使用了一些工具和技术，如DevOps、Docker、Kubernetes、ELK等等，来帮助我们更好地管理和部署我们的应用程序。我们的开发团队会在应用程序的设计和开发过程中考虑运维方面的问题，例如可扩展性、可靠性、监控等等。我们也会使用自动化工具来帮助我们测试和部署应用程序，以提高开发和运维的效率。 - 介绍下工作中的一个对自己最有价值的项目，以及在这个过程中的角色
我参与过一个名为“智能化机器人”的项目，我在其中担任了前端工程师的角色。该项目旨在设计和开发一个基于机器学习和人工智能技术的智能化机器人，能够自主学习和执行各种任务，以帮助用户完成日常生活和工作中的任务。在这个项目中，我负责了前端界面和交互设计、开发和测试。我与我的团队成员密切合作，采用了敏捷开发方法，定期召开会议和Code Review会议，确保项目进展顺利，并及时解决问题。我们也使用了一些新技术和工具，例如React、Webpack、ES6、Less等等，来提高我们的开发效率和代码质量。这个项目对我来说很有价值，因为它让我更深入地了解了前端开发、机器学习和人工智能技术，并提高了我的团队协作和项目管理技能。
软实力
- 说说你的亮点
- 说说你最近在看什么书
- 说说你觉得最有意义的技术书籍《计算机程序设计艺术》、《代码大全》、《重构：改善既有代码的设计》
- 工作之余做什么事情
- 说说个人发展方向方面的思考
如果对技术比较感兴趣，可以深入学习某一领域的知识，如分布式系统、云计算、机器学习等，成为该领域的专家。如果想要从管理方面发展，可以学习项目管理、团队管理等知识，成为优秀的技术管理者。除了技术能力之外，个人发展也需要具备一些软技能，如沟通能力、协作能力、领导能力等。这些能力在工作中同样重要，也需要不断的学习和提升。 - 说说你认为的服务端开发工程师应该具备哪些能力
扎实的编程基础知识，熟悉常用的编程语言和框架，如Java、Python、Spring、Django等。掌握常见的数据库和数据结构算法，能够设计和优化数据库结构，并能根据需求选择合适的算法。熟悉常用的网络协议，如HTTP、TCP/IP等，并能进行网络编程和网络性能调优。熟悉分布式系统架构和相关技术，如Zookeeper、Dubbo、Spring Cloud等，并能根据业务需求设计合适的分布式架构。具备良好的系统架构设计能力，能够根据需求进行系统设计和优化。具备良好的沟通能力和团队协作能力，能够与团队成员合作开发，并能与其他团队进行沟通和协作。熟悉常用的开发流程和工具，如Git、Jenkins等，能够进行代码管理、自动化测试和持续集成。 - 说说你认为的架构师是什么样的，架构师主要做什么
- 说说你所理解的技术专家
HR 篇
- 你为什么离开之前的公司
- 你为什么要进我们公司
- 说说职业规划
- 你如何看待加班问题
- 谈一谈你的一次失败经历
- 你觉得你最大的优点是什么
- 你觉得你最大的缺点是什么
- 你在工作之余做什么事情
- 你为什么认为你适合这个职位
- 你觉得自己那方面能力最急需提高
- 你来我们公司最希望得到什么
- 你希望从这份工作中获得什么
- 你对现在应聘的职位有什么了解
- 您还有什么想问的
- 你怎么看待自己的职涯
- 谈谈你的家庭情况
- 你有什么业余爱好
- 你计划在公司工作多久
版权归原作者 吹林 所有， 如有侵权，请联系我们删除。