Redis与Memcached之间的比较.ppt

?RDB存在哪些优势呢？ ? ? 1). 一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。 ? ? 2). 对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。 ? ? 3). 性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。 ? ? 4). 相比于AOF机制，如果数据集很大，RDB的启动效率会更高。 * 当然由于os会在内核中缓存 write做的修改，所以可能不是立即写到磁盘上，不过我们可以通过配置文件告诉redis我们想要 通过fsync函数强制os写入到磁盘的时机。有三种方式如下（默认是：每秒fsync一次） * 主从复制，首先是解决数据安全备份的这一问题 ，还有就是可以提高读写性能。可以把从配为读（如果数据实时性要求不是那么高的话） redis主从复制的一些特点1.master可以有多个slave2.除了多个slave连到相同的master外，slave也可以连接其他slave形成图状结构3.主从复制不会阻塞master。也就是说当一个或多个slave与master进行初次同步数据时，master可以继续处理client发来的请求。相反slave在初次同步数据时则会阻塞不能处理client的请求。4.主从复制可以用来提高系统的可伸缩性,我们可以用多个slave 专门用于client的读请求，比如sort操作可以使用slave来处理。也可以用来做简单的数据冗余5.可以在master禁用数据持久化，只需要注释掉master 配置文件中的所有save配置，然后只在slave上配置数据持久化。 * 1.Slave端在配置文件中添加了slave of指令，于是Slave启动时读取配置文件，初始状态为REDIS_REPL_CONNECT。 2.Slave端在定时任务serverCron(Redis内部的定时器触发事件)中连接Master，发送sync命令，然后阻塞等待master发送回其内存快照文件(最新版的Redis已经不需要让Slave阻塞)。 3.Master端收到sync命令简单判断是否有正在进行的内存快照子进程，没有则立即开始内存快照，有则等待其结束，当快照完成后会将该文件发送给Slave端。 4.Slave端接收Master发来的内存快照文件，保存到本地，待接收完成后，清空内存表，重新读取Master发来的内存快照文件，重建整个内存表数据结构，并最终状态置位为 REDIS_REPL_CONNECTED状态，Slave状态机流转完成。 5.Master端在发送快照文件过程中，接收的任何会改变数据集的命令都会暂时先保存在Slave网络连接的发送缓存队列里（list数据结构），待快照完成后，依次发给Slave,之后收到的命令相同处理，并将状态置位为 REDIS_REPL_ONLINE。 * 丰富的数据结构使得redis的设计非常的有趣。如何迁移或者设计KV数据结构？ * select b.name, b.author? from tag t1, tag t2, book b where t1.tagname = 'web' and t2.tagname = 'ruby' and t1.book_id = t2.book_id and b.id = t1.book_id * 多线程模型可以发挥多核作用，但是引入了cache coherency和锁的问题，比如，Memcached最常用的stats 命令，实际Memcached所有操作都要对这个全局变量加锁，进行计数等工作，带来了性能损耗。 对于单纯只有IO操作来说，单线程可以将速度优势发挥到最大，但是Redis也提供了一些简单的计算功能，比如排序、聚合等，对于这些操作，单线程模型实际会严重影响整体吞吐量，CPU计算过程中，整个IO调度都是被阻塞住的。 * 　总结： 　　1.Redis使用最佳方式是全部数据in-memory。 　　2.Redis更多场景是作为Memcached的替代者来使用。 　　3.当需要除key/value之外的更多数据类型支持时，使用Redis更合适。 　　4.当存储的数据不能被剔除时，使用Redis更合适。 * 临时计数 ? 小黄签提醒 ? 新粉丝，新@，新评论 ? 未读微博 ? 聚合计算 ? 页面js每隔一段时间请求一次 * 主从复制 配置：