MyBatis与JPA在ORM映射、可移植性、日志系统及SQL优化方面存在显著差异：MyBatis为半自动ORM，需手写SQL，耦合性较高但优化灵活，日志功能较弱；JPA为全自动ORM，支持HQL，对象与数据库解耦好，日志系统健全但复杂SQL处理能力有限。MyBatis支持简单类型、集合及JavaBean作为输入输出参数，通过属性名映射。实现一对多关联查询可使用嵌套查询（通过collection标签调用子查询）或嵌套结果（联表查询后映射子集合）。$与#的区别在于#使用预编译防注入且高效，$直接拼接参数用于动态列名等特殊场景，虽不安全但必要。MyBatis XML与Mapper接口通过namespace属性绑定。自定义分页效率高于插件分页，因可针对大数据偏移优化。MyBatis缓存分两级：一级为SqlSession级默认启用，二级为SqlSessionFactory级需手动开启，基于LRU策略，缓存SELECT结果并在增删改时刷新。cookie与session在存储位置、容量、安全性、生命周期等方面不同，session依赖cookie传递SESSIONID实现状态跟踪。GET请求幂等、参数暴露于URL且长度受限，适用于非敏感数据获取；POST非幂等、参数在请求体无长度限制，适合创建资源或传输敏感数据。400错误表示请求参数语义错误。乱码问题可通过统一客户端与服务端编码解决，GET需配置

Redis Cluster在3.0提供分布式能力，能突破单机内存、并发与流量瓶颈，实现负载均衡，但限制批量/事务操作只能在同slot键上，单库、单层复制等也受限。Hash在键值对≤512且长度<64 B时采用压缩列表（ziplist），否则使用字典（hashtable），并通过渐进式 REHASH 动态扩容/收缩。Zset 同样在元素≤128且长度<64 B时使用 ziplist，否则采用由字典和跳跃表（skiplist）组合的 zset 结构，兼顾按成员和按分值的高效访问。利用 Redis 的高性能键值存储，可实现跨节点的分布式 Session（将 SessionID 存于 Redis）以及分布式锁（基于 SETNX/SET‑EX 并配合超时、唯一标识和 Lua 脚本保证原子性），解决多服务器环境下的状态共享和并发竞争问题。

消息队列用于解耦、异步和削峰；生产者‑消费者通过共享队列或BlockingQueue实现。保证顺序消费需同一键/分区或同一队列；防止丢失通过持久化、ACK/confirm、复制及手动offset提交；避免重复消费要幂等或唯一ID检查。失败消息通常转入死信队列重试。推模式适合广播，拉模式适合定制查询。RabbitMQ侧重可靠性和实时性，Kafka侧重高吞吐量和流式处理，两者在架构、确认机制和负载均衡上不同。

分布式系统核心围绕CAP原则展开，该定理指出在分布式环境中，一致性（C）、可用性（A）和分区容错性（P）三者不可兼得，最多只能同时满足两个。其中一致性要求所有节点数据实时同步，可用性强调服务持续可访问，分区容错性保障系统在网络故障时仍能对外提供服务。实际架构中常根据业务需求在三者间权衡取舍。 高并发设计需兼顾高性能、高可用与高可扩展三大宏观目标。性能优化关注平均响应时间与TP99等分位指标，通过集群部署、多级缓存、分库分表、异步化、限流削峰等手段提升吞吐并降低延迟；可用性保障依赖冗余部署、故障转移、超时重试、降级熔断及全链路监控；可扩展性则通过分层架构、服务无状态化、存储拆分等实现灵活扩容，避免单点瓶颈。 分布式存储实现形式多样：HDFS采用中心控制节点（NameNode）管理元数据、DataNode存储数据的架构，适合高吞吐场景；Ceph和Swift采用无中心设计，前者通过计算映射定位数据，后者基于一致性哈希算法实现数据分布与负载均衡，均具备良好的横向扩展能力。 分布式事务旨在跨服务/数据库保证数据一致性，常见方案包括两阶段提交（2PC/XA）——虽实现简单但存在单点与阻塞问题；TCC模式通过Try-Confirm-Cancel三阶段实现柔性事务，支持补偿机制，适用于高并发业务

分布式系统旨在保证最终一致性，面临的关键挑战在于处理分布式事务。传统方案如两阶段提交（2PC）和三阶段提交（3PC）通过协调者与参与者之间的交互来实现，但存在阻塞、单点故障和脑裂等问题，可用性受限。阿里巴巴提出的TCC协议尝试通过Try-Confirm-Cancel模式优化事务处理，具备一定自我修复能力，但极端情况下仍可能出现不一致。 实际应用中，由于2PC和3PC的复杂性和性能问题，TCC也并非完美，最终一致性往往通过更轻量级的模式实现。例如，查询模式用于追踪操作状态；补偿模式通过逆向操作修正错误；异步确保模式利用消息队列实现异步处理；定期校对模式通过批量校对发现并修复不一致；可靠消息模式确保消息传递的可靠性；缓存一致性模式则牺牲强一致性以提升性能。 对于分布式系统的单点问题，无状态服务易于水平扩展，而有状态服务则需考虑去状态化或采用主备方案，并通过引入第三方服务（如ZooKeeper）或选举算法来保证高可用性。HTTP和RPC的区别主要体现在传输协议、效率、性能、负载均衡和服务治理等方面。RPC更适合内部服务调用，HTTP则更通用。