The people who read this article had better read the article written by the Great God first Http://blog.csdn.net/defonds/article/details/48716161#plain
This article mainly solves the custom build strategy and the 16 part question, welcome everybody to spit the slot
1 The method name of the first custom cache policy should not be customkeygenerator, but should be keygenerator, for specific reasons you can see the source code of the Cachingconfigurersupport class.
In order to verify the above problems, we have to solve the 16 binary problem, that is, \xe7\x9c\x81t\x00\x0323e this type of data in Redis (in addition to the command redis-cli stored in Chinese by cmd--raw can store read display Chinese)
Add the following method to Rediscacheconfig (a Redis custom configuration class that inherits Cachingconfigurersupport from the original blogger's demo):
Redistemplate.setkeyserializer (Stringredisserializer);
Redistemplate.setvalueserializer (Stringredisserializer);
Redistemplate.sethashkeyserializer (Stringredisserializer);
Redistemplate.sethashvalueserializer (Stringredisserializer);
As for why part of the comment out, you can not comment off the run to see (will be error-OH). As for key does not (specifically because the data is serialized after the deposit into Redis 16, you can also here Baidu underlying principle http://blog.csdn.net/yiluoak_47/article/details/22041301),
Finally there is the so-called Custom cache policy key (why does the wood have value?). The value of the service layer should not be a string, the original blogger's case listed as a list or entity class, so the conversion failed. But key is a string, and finally found that the key value is the full package name + Class name + method name.
Other than that. As for why the original blogger deposit value, why return two keys, one for keys, a flavor key, we can look at the following picture, the best and the original blogger's attention to the picture of the matter in the comparison, I believe it can solve the