Redis get挖出的乱码之谜（redis的get乱码）

Redis get挖出的乱码之谜

最近在使用Redis对数据进行缓存时，遇到一个挖掘乱码之谜的问题。

我们在工程中使用Spring Boot搭建服务，使用Jedis作为Redis的客户端。在进行Redis数据读取时，我们使用了get方法，但是在读取到缓存中存储的某个值时，我们得到了一堆乱码。很显然，这个值本来应该是一串字符串，但现在看起来是完全不可读的奇怪字符。

经过排查，我们发现这个问题并不是由Redis缓存的存储导致的，而是由Jedis客户端在读取缓存数据时的序列化或反序列化过程引起的。我们深入调查了Jedis客户端源代码，特别注重了序列化/反序列化相关的代码，以确保我们的数据是按预期缓存和检索的。

我们注意到，Jedis使用JDK的序列化机制来对存储的数据进行序列化和反序列化。即使存储区域的数据采用的是二进制格式，它们在进行存储和读取时也会被转换为Java对象。这意味着，我们必须确保传递的数据是可序列化的，否则就会出现不可预知的结果，其中之一就是乱码。

使用Spring Boot时，我们默认使用Jackson库进行序列化和反序列化，但是在我们的项目中，有一个POJO类（一般用于定义简单的Java对象，用于实现数据对象的封装和功能对象的解耦）使用了Kryo进行序列化和反序列化。Kryo是一个高效且紧凑的序列化库，它可以将Java对象序列化为一个紧凑的二进制格式，以优化序列化的大小和效率。

基于这个发现，我们进一步深入研究了Kryo序列化和反序列化的机制。我们发现，Kryo会对一部分类型进行特殊处理，例如Map和List。对于这些类型，Kryo将在对象序列化到二进制格式之前先将它们转换为一个保持唯一性的ID，这将使得Kryo在反序列化时可以区分两个不同的Map或List。但是，由于我们使用了自定义的POJO类，使得Kryo无法进行特殊处理，因此在反序列化时出现了问题。

为了解决问题，我们通过将存在问题的POJO类替换为与Kryo默认支持的兼容类型，并使用默认的序列化机制代替Kryo，解决了这个问题。

总结一下，当我们在使用Redis进行缓存时，一定要注意序列化和反序列化机制的兼容性，否则就会出现乱码等无法预知的问题。此外，如果您遵循了Java的最佳实践，就应该使用可序列化的POJO类和默认的序列化和反序列化机制，这将使您的应用程序更加稳定和可靠。