Databases

Remote Dictonary Server(Redis)是一个基于key-value键值对的持久化数据库存储系统。redis和大名鼎鼎的Memcached缓存服务很像,但是redis支持的数据存储类型更丰富,包括string(字符串)、list(链表)、set(集合)和zset(有序集合)、Hash等。 这些数据类型都支持push/pop,add/remove及取交集、并集和差集及更丰富的操作,而且这些操作都是原子性的。在此基础上，redis支持各种不同方式的排序。与memcached缓存服务一样，为了保证效率数据都是缓存在内存中提供服务。和memcached不同的是，redis持久化缓存服务还会周期性的把更新的数据写入到磁盘以及把修改的操作记录追加到文件里记录下来，比memcached更有优势的是，redis还支持master-slave(主从)同步,这点很类似关系型数据库MySQL。 Redis是一个开源的、使用C语言编写、３万多行代码、支持网络、可基于内存亦可久化的日志型、Key-Value数据库，并提供多种语言的API从2010年3月15日起，Redis开发工作由VMware主持。 Redis的出现，再一定程度上弥补了memcached这类key-value内存缓存服务的不足,在部分场合可以对关系数据库起到很好的补充作用.redis提供了Python, Ruby, Erlang, PHP客户端，使用很方便。redis官方文档如下：http://www.redis.io/documentation Redis的优点 与memcached不用，redis可以持久化存储数据。 性能很高：Redis能支持超过10w/秒的读写频率。 丰富的数据类型：redis支持二进制的Strings, Lists, Hashes, Sets及sorted sets等数据类型操作。 原子：Redis的所有操作都是原子性的,同时Redis还支持对几个操作全并后的原子性执行。 丰富的特性：Redis还支持publish/subscribe(发布/订阅)，通知，key过期等等特性。 redis支持异步主从复制。 Redis的应用场景 传统的MySQL+Memcached的网站架构遇到的问题： MySQL数据库实际上是适合进行海量数据存储的,加上通过Memcached将热点数据 存放到到内存cache里,达到加速数据访问的目的,绝大部分公司都曾经使用过这样的架构,但随着业务数据量的不断增加,和访问量的增长,很多问题就会暴漏出来： 需要不断的对MySQL进行拆库拆表Memcached也需不断跟着扩容,扩容和维护工作占据大量开发运维时间。 Memcached与MySQL数据库数据一致性问题是个老大难。 Memcached数据命中率低或down机,会导致大量访问直接穿透到数据库,导致MySQL无法支撑访问。 跨机房cache同步一致性问题。 redis在微博中的应用 计数器：微博（评论、转发、阅读、赞等） 用户（粉丝、关注、收藏、双向关注等） redis在短信中的应用 发送短信后存入redis中60秒过期。 redis的最佳应用场景 Redis最佳试用场景是全部数据in-memory。 Redis更多场景是作为Memcached的替代品来使用。 当需要除key/value之外的更多数据类型支持时,使用Redis更合适。 数据比较重要，对数据一致性有一定要求的业务。 当存储的数据不能被剔除时,使用Redis更合适。 更多 Redis作者谈Redis应用场景 http://blog.nosglfan.com/html/2235.html 使用redis bitmap进行活跃用户统计 http://blog.nosqlfun.com/html/3501.html 计数、cache服务、展示最近、最热、点击率最高、活跃度最高等等条件的top list、用户最近访问记录表、relation list/Message Queue、粉丝列表 Key-Value Store更加注重对海量数据存取的性能、分布式、扩展性支持上，并不需要传统关系数据库的一些特征。例如：Schema事务、完整SQL查询支持等等，因此在布式环境下的性能相对于传统的关系数据库有较大的提升。 redis的生产经验教训 要进行Master-slave主从同步配置，在出现服务故障时可以切换。 在master禁用数据据持久化只需在slave上配置数据持久化。 物理内存+虚拟内存不足，这个时候dump一直死着，时间久了机器挂掉。这个情就是灾难。 当Redis物理内存使用超过内存总容量的3/5时就会开始比较危险了，就开始做swap，内存碎片大！ 当达到最大内存时，会清空带有过期时间的如 redis与DB同步写的问题，先写DB，后写redis，因为写内存基本上没有问题。 业务场景 提高了DB的可扩展性,只需要将新加的数据放到新加的服务器上就可以了。 提高了DB的可用性,只影响到需要访问的shard服务器上的数据的用户。 提高了DB的可维护性,对系统的升级和配里可以按shard一个个来搞,对服务产生的影响小。 小的数据库存的查询压力小,查询更快,性能更好。 使用过程中的一些经验与教训,做个小结： 要进行Master-slave配置,出现服务故障时可以支持切换。 在master侧禁用数据持久化,只需在slave上配置数据持久化。 物理内存+虚拟内存不足时,这个时候dump已知死着,时间久了机器挂掉。这个情况就是灾难。 当Redis物理内存使用超过内存总容量的3/5时就会开始比较危险了,就开始做swap,内存碎片大。 当达到最大内存时,会清空带有过期时间的key,即使key未到过期时间。 redis与DB同步写的问题,先写DB,后写redis,因为写内存基本上没有问题。 安装配置Redis 下载安装Redis redis官方网站：www....

发布与订阅 Publish/Subscribe 发布订阅(pub/sub)是一种消息通信模式，主要的目的是解耦消息发布者和消息订阅者之间的藕合，这点和设计模式中的观察者模式比较相似。pub/sub不仅仅解决发布者和订阅者直接代码级别耦合也解决两者在物理部署上的耦合。Redis作为一个pub/sub的server,在订阅者和发布者之间起到了消息路由的功能。订阅者可以通过subscribe和psubscribe命令向Redis server订阅自己感兴趣的消息类型，Redis将消息类型称为通道(channel)。当发布者通过publish命令向Redis server发送特定类型的消息时。订阅该消息类型的全部client 都会收到此消息。这里消息的传递是多对多的。一个client可以订阅多个channel,也可以向多个channel发送消息。 Redis支持这样一种特性，你可以将数据推到某个信息管道中，然后其它人可以通过订阅这些管道来获取推送过来的信息。 用一个客户端订阅频道 bash 1 2 3 4 5 6 psubscribe new #### 1.批量订阅 127.0.0.1:6379> publish news news-test (integer) 1 127.0.0.1:6379> publish video video-test (integer) 1 此时可以见到接受的信息 bash 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 127.0.0.1:6379> psubscribe news video Reading messages... (press Ctrl-C to quit) 1) "psubscribe" 2) "news" 3) (integer) 1 1) "psubscribe" 2) "video" 3) (integer) 2 1) "pmessage" 2) "news" 3) "news" 4) "news-test" 1) "pmessage" 2) "video" 3) "video" 4) "video-test" 数据过期设置及机制 Redis key的过期机制 Redis对过期键采用了lazy expiration：在访间key的时候判定key是否过期，如果过期，则进行过期处理（过期的key没有被访间可能不会被删除）。其次，每秒对volatile keys进行抽样测试，如果有过期键，那么对所有过期key进行处理。...

Redis的所有数据都存储在内存中，但是他也提供对这些数据的持久化。 Redis是一个支持持久化的内存数据库，Redis需要经常将内存中的数据同步到磁盘来保证持久化。Redis支持四种持久化方式，一种是 Snapshotting(快照)也是默认方式 ，另一种是 Append-only file(aof)的方式 。 RDB持久化方式 Snapshotting方式是将内存中数据以快照的方式写入到二进制文件中，默认的文件名为dump.rdb。可以通过配置设置自动做快照持久化。例如可以配置redis在n秒内如果超过m个key被修改就自动做快照。 实现机制 Redis调用fork子进程。 父进程继续处理client请求，子进程负责将内存内容写入到临时文件。由于os的实时复制机制(copy on write)父子进程会共享相同的物理页面，当父进程处理写请求时os会为父进程要修改的页面创建副本，而不是写共享的页面。所以子进程地址空间内的数据是fork时刻整个数据库的一个快照。 当子进程将快照写入临时文件完毕后，用临时文件替换原来的快照文件，然后子进程退出。client也可以使用save或者bgsave命令通知redis做一次快照持久化。save操作是在主线程中保存快照的，由于redis是用一个主线程来处理所有client的请求，这种方式会阻塞所有clien:请求。所以不推荐使用。另一点需要注意的是，每次快照持久化都是完整写入到磁盘一次并不是增量的只同步变更数据。如果数据量大的话，而且写操作比较多，必然会引起大量的磁盘IO操作，可能会严重影响性能。 缺点： 快照方式是在一定间隔时间做一次的，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改。如果应用要求不能丢失任何修改的话，可以采用aof持久化方式。 相关配置 bash 1 2 3 4 5 6 7 8 save 900 1 #←900秒内至少有1个key被改变 save 300 10 #←300秒内至少有10个key被改变 save 60 10000 #←60秒内至少有10000个key被改变 stop-writes-on-bgsave-error yes #←后台存储错误后停止写。如：磁盘空间不足 rdbcompression yes #←使用LZF压缩rdb文件 rdbchecksum yes #←存储和加载rdb文件时校验 dbfilename dump.rdb #←存储rdb文件名 dir /app/redis/db/ #←rdb文件路径 持久化测试 bash 1 2 3 4 5 11512:M 22 Apr 01:04:47.028 * 5 changes in 60 seconds....

key/value介绍 Redis key值是二进制安全的，这意味着可以用任何二进制序列作为key值，从形如“0foo”的简单字符串到一个JPG文件的内容都可以。空字符串也是有效key值。 关于key的几条规则： 太长的键值，例如1024字节的键值，不仅因为消耗内存，而且在数据中查找这类键值的计算成本很高。 太短的键值，如果你要用 u:1000:pwd来代替user:1000:password，这没有什么问题，但后者更易阅读，并且由此增加的空间消耗相对于key object和value object本身来说很小.当然，没人阻止您一定要用更短的键值节省一丁点空间。 最好坚持一种模式;。例如：object-type:id:field就是个不错的注意，像这样user:1000:password。我喜欢对多单词的字段名中加上一个点，就像这样：comment.1234.renlv_to key建议：object-type:id:field 长度10-20 value建议：string不要超过2K set sortedset元素不要超过5000 bash 1 2 3 4 $ redis-cli set user_list:user_id:5 zhangsan OK $ redis-cli get user_list:user_id:5 "zhangsan" 通用操作 找到全部给定模式的匹配到的key bash 1 2 3 4 5 6 7 127.0.0.1:6379> keys * #<==打印全部key 1) "name" 2) "site" 127.0.0.1:6379> keys na[ma]e #<==返回正则匹配到的key 1) "name" 127.0.0.1:6379> keys nam? 1) "name" randomkey返回随机key bash 1 2 3 4 127.0.0.1:6379> randomkey "name" 127.0.0.1:6379> randomkey "site" exists检查key是否存在 bash 1 2 3 4 127....

Replication的工作原理 设置一个Slave，无论是第一次还是重连到Master，它都会发出一个sync命令。当Master收到sync命令之后，会做两件事： Master执行BGSAVE，即在后台保存数据到磁盘（rdb快照文件）。 Master同时将新收到的写入和修改数据集的命令存入缓冲区（非查询类）。 当Master在后台把数据保存到快照文件完成之后，把这个快照传送给Slave，而Slave则把内存清空后，加载该文件到内存中。而Master也会把此前收集到缓冲区中的命令，通过Reids命令协议形式转发给Slave，Slave执行这些命令，实现和Master的同步。Master/Slave此后会不断通过异步方式进行命令的同步。 注：在redis2.8之前，主从之间一旦发生重连都会引发全量同步操作。但在2.8之后版本，也可能是部分同步操作。 部分复制 2.8后，当主从之间的连接断开之后，他们之间可以采用持续复制处理方式代替采用全量同步。Master端为复制流维护一个内存缓冲区（in-memory backlog），记录最近发送的复制流命令；同时，Master和Slave之间都维护一个复制偏移量(replication offset)和当前Master服务器ID（Master run id）。当网络断开，Slave尝试重连时： 如果MasterID相同（即仍是断网前的Master服务器），并且从断开时到当前时刻的历史命令依然在Master的内存缓冲区中存在，则Master会将缺失的这段时间的所有命令发送给Slave执行，然后复制工作就可以继续执行了 否则，依然需要全量复制操作。 Redis 2.8 的这个部分重同步特性会用到一个新增的PSYNC内部命令， 而 Redis 2.8以前的旧版本只有SYNC命令，不过，只要从服务器是Redis 2.8或以上的版本，它就会根据主服务器的版本来决定到底是使用 PSYNC还是SYNC。 如果主服务器是 Redis 2.8 或以上版本，那么从服务器使用 PSYNC 命令来进行同步。 如果主服务器是 Redis 2.8 之前的版本，那么从服务器使用 SYNC 命令来进行同步。 redis主从同步特点 一个Master可以有多个Slave。 Redis使用异步复制。从2.8开始，Slave会周期性（每秒一次）发起一个ack确认复制流（replication stream）被处理进度； 不仅主服务器可以有从服务器， 从服务器也可以有自己的从服务器， 多个从服务器之间可以构成一个图状结构； 复制在Master端是非阻塞模式的，这意味着即便是多个Slave执行首次同步时，Master依然可以提供查询服务； 复制在Slave端也是非阻塞模式的：如果你在redis.conf做了设置，Slave在执行首次同步的时候仍可以使用旧数据集提供查询；你也可以配置为当Master与Slave失去联系时，让Slave返回客户端一个错误提示； 当Slave要删掉旧的数据集，并重新加载新版数据时，Slave会阻塞连接请求（一般发生在与Master断开重连后的恢复阶段）； 复制功能可以单纯地用于数据冗余（data redundancy），也可以通过让多个从服务器处理只读命令请求来提升扩展性（scalability）： 比如说， 繁重的 SORT 命令可以交给附属节点去运行。 可以通过修改Master端的redis.config来避免在Master端执行持久化操作（Save），由Slave端来执行持久化。 redis replication配置文件详解 bash 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 slaveof [masterip] [masterport] #←该redis为slave ip和port是master的ip和port masterauth <master-password> #←如果master设置了安全密码，此处为master的安全密码 slave-serve-stale-data yes#←当slave丢失master或同步正在进行时，如果发生对slave的服务请求： slave-serve-stale-data no #←slave返回client错误:"SYNC with master in progress" slave-serve-stale-data yes #←slave依然正常提供服务 slave-read-only yes #←设置slave不可以写数据，只能用于同步 repl-ping-slave-period 10 #←发送ping到master的时间间隔 repl-timeout 60 #←IO超时时间 repl-backlog-size 1mb #←backlog的大小，当从库连接不到主库时，backlog的队列能放多少 repl-backlog-ttl 3600 #←backlog的生命周期 min-slaves-max-lag 10 #←延迟小于min-slaves-max-lag秒的slave才认为是健康的slave # 当master不可用,Sentinel会根据slave的优先级选举一个master。 # 最低的优先级的slave,当选master....