本文目录一览：
Redis随笔-rename效率问题
rename 是redis中给key重命名命令， rename key newkey 的意思就是将key重命名为newkey。
Redis 是基于内存的，内存的读写速度非常快，因此 Redis 的单线程执行效率也非常高。Redis 是单线程的，省去了很多上下文切换线程的时间，这也是 Redis 能够快速处理请求的原因之一 。
这是因为 Redis 的作者是想通过不同编码实现效率和空间的平衡，然而数据量越大使用的内部编码就越复杂，而越是复杂的内部编码存储的性能就越低。
在小于等于0版本中，如果key和newkey相同，则会报错。如果在rename之前，键已经存在，那么它的值也将被覆盖 为避免重命名覆盖已有键的问题，可应用命令 renamenx ，确保只有newkey不存在时候才能覆盖。
如何保证redis与mysql数据最终一致性
这种情况应该是先删除缓存，然后在更新数据库，如果删除缓存失败，那就不要更新数据库，如果说删除缓存成功，而更新数据库失败，那查询的时候只是从数据库里查了旧的数据而已，这样就能保持数据库与缓存的一致性。
SAGA或者TCC - 这两种需要业务代码的大量配合。通过业务代码来补偿一致性。 现实当中有XA协议。比如Ehcache是支持XA协议的。但是性能表现不佳，运维也麻烦。
二者数据同步的关键在于mysql数据库中主键，方案是在redis启动时区mysql读取所有表键值存入redis中，往redis写数据是，对redis主键自增并进行读取，若mysql更新失败，则需要及时清除缓存及同步redis主键。
如果要“保证”数据的安全性，那么会带来开销的进一步提升，以至于使用redis带来的性能优势都会丧失。正确的做法是区分不同的业务，使得并不需要“保证”数据一致性的场合，可以使用redis优化。而敏感的场合依然使用mysql。
架构设计 通过上述结构设计图可以很清晰的知道用到的组件：MySQL、Canal、Kafka、ZooKeeper、Redis。
方案1 （推荐学习：Redis视频教程）做缓存，就要遵循缓存的语义规定：读：读缓存redis，没有，读mysql，并将mysql的值写入到redis。写：写mysql，成功后，更新或者失效掉缓存redis中的值。
SpringCache优化、缓存一致性、多级缓存
SpringCache是写库之后更新的策略，对缓存一致性的不太友好 继承RedisCacheManager重写createRedisCache，继承RedisCache重写put 缓存一致性有两个方案，一个是先写库再删除缓存、第二个是先删除缓存再写库。
题主是想询问“spring@cacheable查询很慢的原因”，原因是：缓存策略不当：缓存策略的选择直接影响到缓存的效率，如果选择的策略不当，例如缓存时间过长或者缓存的数据量过大，会导致缓存效率低下，反而降低了系统性能。
当然这里Redis不是必须的，换成其他的缓存服务器一样可以，只要实现Spring的Cache类，并配置到XML里面就行了。1，降低了组件之间的耦合性，实现了软件各层之间的解耦。2，可以使用容器提供的众多服务，如事务管理，消息服务等。
Spring在访问三级缓存时遵循逐级访问原则，首先访问第一级，对象不存在则访问第二级，二级缓存不存在则访问第三级，第三级不存在则创建。
使用二级缓存，二级缓存缓存的是增强后的bean。这个与spring加载流程不符合。spring加载流程是：实例化，设置属性，初始化，增强。在有循环引用的时候，之前的bean并不会增强后放入到二级缓存。
