txpcg面经总结

• spring security是怎么结合的，底层原理是什么了解吗
  Spring Security 是一个功能强大且灵活的身份验证和授权框架，它是建立在 Spring 框架之上的。用于保护企业级应用程序，包括身份验证、授权、攻击防范等功能。
  底层原理包括：
  过滤器链：核心就是过滤器链，由一系列的过滤器组成，每一个过滤器负责一个特定的任务，比如身份验证、授权、会话管理等。过滤器链会在用户发起请求时依次执行，每个过滤器都有机会对请求进行处理，直到最终的目标资源被访问或请求被拒绝。
  安全上下文：Spring Security 使用安全上下文来存储当前用户的安全信息，包括用户的身份（Principal）、权限（Authorities）、认证状态（Authenticated）等。安全上下文可以通过 SecurityContextHolder 进行访问和管理。
  用户认证：提供了多种用户认证的方式，包括基于用户名密码的认证、基于 Token 的认证。用户认证过程通常会包括用户提供凭证、验证凭证、创建安全上下文等步骤。
  授权：可以基于角色、权限、表达式等对用户进行授权。授权过程通常会在用户认证成功后进行，根据用户的身份和权限来判断是否允许访问特定的资源。
  安全配置： 使用安全配置来定义应用程序的安全策略，包括哪些请求需要进行身份验证、哪些请求需要授权、如何处理认证和授权错误等。安全配置通常通过 Java 配置或者 XML 配置的方式进行定义。
• oauth2协议和微信登录的安全性是如何保证的呢
  OAuth 2.0 协议是一种用于授权的开放标准，它允许用户让第三方应用访问其在另一个服务提供商上存储的私有资源，而无需将用户名和密码提供给第三方应用
  安全认证流程：通过授权服务器、资源服务器和客户端之间的安全通信，确保用户的身份信息和授权信息得到安全地传输和处理。
  授权码授权方式：微信登录通常使用授权码授权方式，该方式通过授权码的方式进行授权，有效地避免了第三方应用直接获取用户的用户名和密码。在该流程中，用户登录微信，授权给第三方应用后，微信生成授权码并返回给第三方应用，第三方应用再使用授权码向微信获取访问令牌，从而实现对用户资源的访问。
  安全验证机制：包括用户登录态验证、验证码验证、微信支付密码验证等，保障了用户的身份和授权信息的安全性。
  安全沙箱机制：允许开发者在安全隔离的环境中进行测试和开发，避免了潜在的安全风险对生产环境造成的影响。
• refresh_token和access_token有什么区别呢，都存储在哪里，哪个会返回哪个不会
  refresh_token 和 access_token 是 OAuth 2.0 协议中的两种不同类型的令牌，用于实现对资源的访问和授权。
  在 OAuth 2.0 认证流程中，通常客户端首先使用授权码（authorization code）向授权服务器请求 access_token 和 refresh_token。授权服务器验证授权码并颁发 access_token 和 refresh_token 给客户端。然后客户端使用 access_token 访问受保护的资源，当 access_token 过期时，可以使用 refresh_token 向授权服务器请求新的 access_token
  access_token 通常存储在客户端，例如移动应用程序或 Web 前端。refresh_token 通常存储在安全的服务器端，例如授权服务器
• 如果token被劫持了怎么办，如何让安全性提高一个等级，再提高一个等级，还有更好的方法吗？
  使用 HTTPS 进行通信
  限制 token 的生命周期
  使用短期 token
  实现多因素身份验证
  限制 token 的访问范围
• Redis的multi事务和lua选型，redisson
  Redis 的 MULTI/EXEC 事务是一种原子性操作集合，通过 MULTI 命令开始一个事务，然后将多个命令依次放入队列中，最后通过 EXEC 命令将队列中的命令原子地执行。事务中的所有命令要么全部执行成功，要么全部执行失败，不存在中间状态。
  Redis 支持 Lua 脚本，在 Lua 脚本中可以编写复杂的业务逻辑，支持条件判断、循环、异常处理等操作。可以原子地执行一组 Redis 命令，保证操作的原子性。
  Redisson 是一个基于 Redis 的 Java 客户端工具，提供了丰富的功能和高性能的操作。支持对象映射、分布式锁、分布式集合、分布式对象等功能
• 分布式事务
  分布式事务是指涉及多个参与者（如数据库、消息队列、缓存等）的事务操作，这些参与者分布在不同的计算机节点上，分布式事务的实现需要解决分布式环境下的一致性、隔离性、持久性等问题。
  方案：
  两阶段提交（2PC）分布式事务协议，通过协调者（Coordinator）和参与者（Participant）之间的消息交互来保证事务的原子性。它分为投票阶段（Voting Phase）和执行阶段（Execution Phase）两个阶段。在投票阶段，协调者询问所有参与者是否可以执行事务；在执行阶段，如果所有参与者都同意执行事务，则协调者通知所有参与者执行事务，否则回滚事务。2PC 的缺点是存在阻塞、单点故障、协调者效应等问题，不适用于高并发和高可用场景。
  **补偿事务：**分布式事务执行失败时，系统会触发相应的补偿操作来修正已经执行的操作，使系统达到一致状态
  saga模式：Saga 是一种分布式事务模式，通过将一个大事务拆分为多个小事务，并以可逆序列（可补偿序列）的方式执行这些小事务。每个小事务都有对应的补偿操作，当一个小事务失败时，系统执行相应的补偿操作来修正已执行的操作，使系统达到一致状态。Saga 模式通过将事务拆分为多个小事务来降低事务的复杂性，提高了系统的可靠性和可扩展性。
  消息队列事务：消息队列可以用作事务的协调者，通过事务消息（Transactional Message）来保证消息的可靠传输和事务的一致性。消息队列事务通过将事务操作和消息发送封装在同一个事务中，使得事务操作和消息发送可以保持一致，保证系统的数据一致性。
• CAP理论
  在分布式系统中，Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容错性）这三个特性不可能同时满足，只能同时满足其中的两个