标签:
按照Redis官网定义,Redis是一个开源的基于BSD协议的强大的K-V内存数据库。它提供了五种数据结构:strings、hashes、lists、sets和sorted sets。Redis完全基于ANSI C编写。
Redis通常被用作缓存目的,而在Java界流行的缓存框架还有Memcached、EhCache。于是我想探究下Redis和Memcached的区别,如下:
我比较关注上面第3条,于是我特地更深入地就这条查看了几篇文章。对Redis作为数据库(Database)的描述如下:
1
2
3
4
|
Redis虽然是一个内存数据库,但也可以将数据持久化到硬盘,有两种持久化方式:RDB和AOF。 RDB持久化方式定时将数据快照写入磁盘。这种方式并不是非常可靠,因为可能丢失数据,但非常快速。 AOF持久化方式更加可靠,将服务端收到的每个写操作都写入磁盘。在服务器重启时,这些写操作被重新执行来 重新构建数据集。 |
相比之下Memcached没有提供这种持久化机制,为什么Memcached不提供呢?原因应该有很多条(见仁见智),这里列举两条:
1
2
3
4
5
6
7
8
9
10
|
考察下面的场景: A. 用户更新账户信息,账户状态为A B. 你的代码更新数据库(比如MySQL数据库),数据库中的账户状态为A C. 你的代码更新缓存,缓存中的账户状态为A D. 你将缓存Dump到磁盘并开始在部署了缓存的主机上工作,磁盘和缓存中的账户状态都为A E. 用户再次更新账户信息,账户状态为B F. 你的代码更新数据库,数据库中的账户状态为B G. 你的代码未能更新缓存(因为这个时候缓存服务器宕机了) H. 你从磁盘恢复缓存,缓存中的账户状态为A I. 用户查看账户信息,得到的账户状态为A |
针对上面第2条提到的问题,有人可能会建议将F、G更换顺序,先更新缓存,再更新数据库,只有缓存更新成功了才更新数据库。这在某些情况下的确可以解决这种写缓存失败导致的读缓存数据不一致问题。但现在写入性能下降了。使用缓存框架的理想状态是:不对写性能造成影响,同时极大提高读性能,并且保证比较高的数据一致性(或准确性、数据时新性)。因此写缓存的推荐方式是异步写,将F、G更换顺序的建议并不太妥当。
这里体现了几个使用缓存框架时的折衷:
没有万金油式的解决方案,因为技术服务于业务,而业务场景又是千变万化的。
标签:
原文地址:http://www.cnblogs.com/zengda/p/4781529.html