背景
项目使用Spring的RedisTemplate进行Redis数据存取操作，实际应用中发现Redis中key和value会出现“无意义”乱码前缀\xac\xed\x00\x05t\x00-（样例\xac\xed\x00\x05t\x00-abcd:abc:xxxxxx:passport:associated:key:29708）。
这个乱码前缀是怎么产生的呢？有什么含义？是不是固定的？带着这三个问题，我们一探究竟。
疑问探究
怎么产生的
org.springframework.data.redis.core.RedisTemplate实例化需要序列化和反序列化组件，如果我们不指定，默认使用org.springframework.data.redis.serializer.JdkSerializationRedisSerializer进行序列化，而JdkSerializationRedisSerializer最终使用的是Java原生java.io.ObjectOutputStream.ObjectOutputStream(OutputStream)进行序列化。
这个乱码前缀就是ObjectOutputStream进行序列化时添加的。
有什么含义
\x对应0x
\xac\xed对应是0xaced，是ObjectOutputStream的序列化魔数（见java.io.ObjectStreamConstants.STREAM_MAGIC）。
\x00\x05对应是5，是ObjectOutputStream的序列化版本（见java.io.ObjectStreamConstants.STREAM_VERSION）。
这里引出一个小问题：为什么是\x00\x05而不是\x05？
因为上面2个值write时采用的是short，占2个字节。
样例乱码\x05后面有个t，不是很明显。t是转化后的ASCII码值对应字符，对应16进制是0x74，是ObjectOutputStream分配给String类型标记（见java.io.ObjectStreamConstants.TC_STRING）。
\x00-是有\x00和-组成的，是一起的，表示数据的字节数。-是转化后的ASCII码值对应字符，对应16进制是0x2d（10进制是45，样例abcd:abc:xxxxxx:passport:associated:key:29708的字符数就是45，1个字符1个字节，字节数也是45）。
是不是固定的
由上面的描述可知，乱码前缀中\xac\xed\x00\x05是固定的，t在String类型情况是不变的，后面2个位（样例\x00-）是数据的字节数，是随key动态变化的。
衍生疑问
为什么显示不一样
为什么有些16进制\x显示，有些ASCII码值对应字符显示？
结合ASCII码对应的字符表，推测和显示系统能支持的字符集有关。
0x20 到 0x7e，都是比较正常的字符，可以显示出来。
参考ASCII码
字符长度超长会怎样
2个字节表示数据字节数，即最大0xffff，10进制为65535，key长度超过后会怎么样？
经试验，
key长度65535时，乱码为\xac\xed\x00\x05t\xff\xff
key长度65545时，乱码为\xac\xed\x00\x05|\x00\x00\x00\x00\x00\x01\x00\x09
t上面说过，是转化后的ASCII码值对应字符，对应16进制是0x74，是ObjectOutputStream分配给String类型标记（见java.io.ObjectStreamConstants.TC_STRING）。
|也是转化后的ASCII码值对应字符，对应16进制是0x7c，是ObjectOutputStream分配给长字符串类型标记（见java.io.ObjectStreamConstants.TC_LONGSTRING）。
同时，表示数据字节数的数值位数也变成了8位bigint。
综上，不用担心key长度越界。
应用
通过上面的探究，我们知道了“无意义”乱码前缀的含义。
如果我们新接手一个系统，它是这样使用RedisTemplate的。现在我们需要排查一个和缓存相关的问题，需要看下Redis中某个缓存值是否存在？
我们梳理业务组合出key，通过redis-cli尝试get key是获取不到结果的，此时我们可以根据上面规则自己生成“乱码前缀”，通过get “乱码前缀”+key 就可以判断缓存值是否存在了。
总结
- 上面使用RedisTemplate的方式是不好的，实际应用中key序列化可以采用StringRedisSerializer。这也是网上大部分文章建议的。
- 大部分文章只说了表象原因，没有分析更深入的原因。对从已存在数据中排查问题没有帮助，还是需要自己深究。