Redis的Java客户端

1. Jedis
   • 以 Redis 命令作为方法名称，学习成本低，简单实用。
   • Jedis 是线程不安全的，并且频繁的创建和销毁连接会有性能损耗，因此推荐使用 Jedis 连接池代替Jedis的直连方式。
2. lettuce
   • Lettuce是基于Netty实现的，支持同步、异步和响应式编程方式，并且是线程安全的。支持Redis的哨兵模式、集群模式和管道模式。
3. Redisson
   • Redisson是一个基于Redis实现的分布式、可伸缩的Java数据结构集合。包含了诸如Map、Queue、Lock、Semaphore、AtomicLong等强大功能。

SpringDataRedis

• 定义：SpringData是Spring中数据操作的模块，包含对各种数据库的集成，其中对Redis的集成模块就叫做SpringDataRedis。
• 特点：
  • 提供了对不同 Redis 客户端的整合（Lettuce和 Jedis）。
  • 提供了 RedisTemplate 统一API来操作Redis。
  • 支持Redis的发布订阅模型。
  • 支持Redis哨兵和Redis集群。
  • 支持基于Lettuce的响应式编程。
  • 支持基于JDK、JSON、字符串、Spring对象的数据序列化及反序列化。
  • 支持基于Redis的JDKcollection实现。

RedisTemplate

• SpringDataRedis中提供了RedisTemplate工具类，其中封装了各种对Redis的操作。并且将不同数据类型的操作API封装到了不同的类型中:
  

序列化方式

• RedisTemplate 可以接收任意 Object 作为值写入Redis，只不过写入前会把 Obiect 序列化为字节形式，默认是采用JDK序列化，得到的结果如下，可读性差，内存占用较大。
  
• 可以自己定义序列化方式：
  
• 为了在反序列化时知道对象的类型，JSON序列化器会将类的class类型写入json结果中并存入Redis，会带来额外的内存开销。为了节省内存空间，我们并不会使用JSON序列化器来处理valuje，而是统一使用String序列化器，要求只能存储String类型的key和value。当需要存储java对象时，手动完成对象的序列化和反序列化。Spring默认提供了一个StringRedisTemplate类，它的key和value的序列化方式默认就是String方式，省去了我们自定义RedisTemplate的过程：
  

有状态 & 无状态

• 有状态（Stateful）和无状态（Stateless）是计算机领域中描述系统或协议是否依赖“状态信息”的核心概念，尤其在 Web 开发和 API 设计中至关重要。以下是通俗易懂的解释和对比：

有状态

• 定义：服务器端会保存客户端的状态信息（如用户身份、临时数据），每个请求的处理需要依赖之前请求的上下文。
• 典型场景：用户登录、购物车、多步骤表单等需要跟踪用户行为的场景。
• 特点：
  • 依赖服务器存储：用户的状态信息（如登录状态、购物车数据）存储在服务器内存、数据库或缓存（如 Redis）中。
  • 请求关联性：客户端每次请求需携带标识（如 Session ID），服务器需通过标识查找对应的状态数据。
• 优点：
  • 精准控制：服务端可随时修改或销毁状态（如强制用户退出）。
  • 安全性高：敏感数据（如权限）不暴露给客户端。
• 缺点：
  • 扩展性差：集群部署时需同步状态（如 Redis 共享 Session）。
  • 资源占用：高并发时大量状态存储会增加服务器压力。

无状态

• 定义：服务器不保存客户端的状态信息，每个请求独立且自包含（无需依赖之前的请求）。
• 典型场景：RESTful API、微服务通信、跨域接口等分布式场景。
• 特点：
  • 客户端携带完整信息：每次请求需附带所有必要信息（如 JWT 令牌），服务器直接解析无需查询存储。
  • 请求独立性：服务器处理请求时不依赖历史记录。
• 优点：
  • 扩展性强：无需共享状态，天然支持分布式和横向扩展。
  • 性能高：省去了服务端查询状态的步骤。
• 缺点：
  • 令牌管理复杂：无法直接撤销令牌（需黑名单或短有效期）。
  • 数据暴露风险：令牌内容可被解码（需避免存储敏感信息）。

通俗类比：去餐厅消费。

• 有状态：你告诉服务员手机号（Session ID），服务员根据号码查询会员信息（服务端存储的状态，每次消费需报手机号）。
• 无状态：你直接给服务员一张会员卡（JWT），卡里已包含身份信息、余额、有效期等信息（自包含状态，服务员无需查系统，直接读卡即可完成交易）。