• 1. Redis介绍
  • 2. 1,简介 2,API 3,redis高级实用特性 3.1,安全性 3.2,持久化机制 3.3,主从复制 3.4,过期时间设置 3.5,事务处理 3.6,发布订阅消息 3.7,虚拟内存的使用
  • 3. Redis安装windows版本: https://github.com/MSOpenTech/redis 直接解压即可 在../ redis-2.8/bin/release里边有一个 redis-2.8.17.zip的压缩包,包含服务器端、客户端程序,可以方便的启动服务 官方版本: http://www.redis.io/download
  • 4. (本页无文本内容)
  • 5. Redis简介Redis 是完全开源免费的,遵守BSD协议,先进的key - value持久化产品。它通常被称为数据结构服务器,因为值(value)可以是 字符串(String), 哈希(Map), 列表(list), 集合(sets) 和 有序集合(sorted sets)等类型。
  • 6. Redis简介redis是一个Key-Value存储系统。它支持存储的Value类型很多,包括string(字符串)、hash、list(链表)、set(集合)、zset(有序集合)。这些数据类型支持push/pop、add/remove及取交集和并集及更丰富的操作,redis支持各种不同方式的排序。为了保证效率,数据都是缓存在内存中,它也可以周期性的把更新的数据写入磁盘或者把修改操作追加的记录文件。
  • 7. redis配置daemonize如果需要后台运行,把该项设置为yes pidfile配置多个pid的地址 bind绑定ip,设置后只接受该ip的请求 port监听端口,默认为6379 timeout设置客户端链接时的超时时间,单位为秒 loglevel分为四级,debug、verbose、notice、warning logfile配置log文件地址 databases设置数据库个数,默认使用的数据库为0 save设置redis进行数据库镜像的频率
  • 8. redis配置appendfsync设置appendonly.aof文件同步的频率 vm-enabled是否开启虚拟内存支持 vm-swap-file设置虚拟内存的交换文件路径 vm-max-memory设置redis使用的最大物理内存 vm-page-size设置交换文件的总的page数量 vm-max-threads设置VMIO同时使用的线程数量 Glueoutputbuf把晓得输出缓存存放在一起 hash-max-zipmap-entries设置hash的临界值 Activerehashing重新hash
  • 9. redis配置rdbcompression在进行镜像备份时,是否进行压缩 Dbfilename镜像备份文件的文件名默认dump.rdb Dir数据镜像备份的文件放置路径 Slaveof设置数据库为其他数据库的从数据库 Masterauth主数据库连接需要的密码验证 Requirepass设置登录时需要使用的密码 Maxclients限制同时连接的客户数量 Maxmemory设置redis能够使用的最大内存 Appendonly开启append only模式 注:关于配置文件http://blog.chinaunix.net/uid-790245-id-3766268.html中的“7 、Redis配置说明”有十分详细的介绍。
  • 10. API
  • 11. String类型及操作String是最简单的类型,一个Key对应一个Value。Redis的String类型可以包含任何数据,比如jpg图片或者序列化对象。
  • 12. string类型set 设置key对应的值为String类型的value get setnx 如果key不存在,就设置key对应字符串value。 setex 设置key对应字符串value,并且设置key在给定的seconds时间之后超时过期。 setrange 设置指定key的value值的子字符串 mset mget msetnx getrange
  • 13. string类型incr incrby decr decrby append strlen
  • 14. hashes类型redis hash是一个String类型的field和value的映射表。hash特别适合用于存储对象,相较于将对象的每个字段存成单个String类型。将一个对象存储在hash类型中会占用更少的内存,并且可以更方便的存取整个对象。
  • 15. hashes类型及操作hset hget hsetnx hmset hkeys hvals hgetall hincrby hexists hdel
  • 16. (本页无文本内容)
  • 17. list类型list类型是一个链表结构,主要功能push、pop、获取一个范围内的所有值等等,操作中key理解为链表的名字。redis的list类型其实就是每一个子元素都是String类型的双向链表。我们可以通过push、pop操作从链表的头部或者尾部添加删除元素,这样list既可以作为栈,又可以作为队列。
  • 18. list操作lpush 在key对应list头部添加一个元素 rpush 在key对应list尾部添加一个元素 lrange 取出key对应list里边的元素 linsert 在key对应list特定位置前或后添加字符串 lset 设置list中指定下标的元素值 lrem 从key对应list中删除n个和value相同的元素 lpop 从头弹出一个元素 rpop 从尾弹出一个元素
  • 19. Sets类型sadd 向名称为key的set中添加元素 smembers 查看 srem 删除 sdiff返回所有给定key与第一个key的差集 sinter 返回所有给定key的交集 sunion 返回所有给定key的并集 smove scard
  • 20. Sorted sets类型Sorted set是一个set的一个升级版本,它在set的基础上增加了一个顺序属性,这一属性在添加修改元素的时候可以指定,每次指定后,sorted set会自动重新按新的值调整顺序。可以理解为有两列的MySQL表,一列存value,一列存顺序。操作中key理解为sorted set 的名字。
  • 21. Sorted sets类型zadd zrem zrange zrevrange zrangebyscore zcount ……
  • 22. Redis高级实用特性
  • 23. 1,安全性 2,持久化机制 3,主从复制 4,事务处理 5,过期时间设置 6,发布订阅消息 7,虚拟内存的使用
  • 24. 安全性官方文档:Redis is designed to be accessed by trusted clients inside trusted environments. This means that usually it is not a good idea to expose the Redis instance directly to the internet or, in general, to an environment where untrusted clients can directly access the Redis TCP port or UNIX socket. Redis的是要在安全的环境下被安全的用户访问。
  • 25. 安全性In general, Redis is not optimized for maximum security but for maximum performance and simplicity. Redis安全性不高,但是性能卓越,操作简单
  • 26. 安全性 设置客户端连接后进行任何其他指定操作前需要使用密码。 因为redis速度很快,所以在一台比较好的服务器下,一个外部的用户可以在一秒钟进行150K次的密码尝试,这意味着你需要指定非常强大的密码来防止暴力破解。
  • 27. 官方文档:The password is set by the system administrator in clear text inside the redis.conf file. It should be long enough to prevent brute force attacks for two reasons:Redis is very fast at serving queries. Many passwords per second can be tested by an external client. The Redis password is stored inside the redis.conf file and inside the client configuration, so it does not need to be remembered by the system administrator, and thus it can be very long.
  • 28. 安全性 配置文件: # requirepass foobared 修改: requirepass password 授权:auth命令
  • 29. AUTH password 为redis服务请求设置一个密码。redis可以设置在客户端执行commands请求前需要通过密码验证。通过修改配置文件的requirepass就可以设置密码。 如果密码与配置文件里面设置的密码一致,服务端就会发会一个OK的状态码,接受客户端发送其他的请求命令,否则服务端会返回一个错误码,客户端需要尝试使用新的密码来进行连接。 注意: 因为redis的高性能能在短时间接受非常多的尝试性密码,所以请务必设置一个足够复杂的密码以防止可能的攻击。
  • 30. Data encryption supportRedis does not support encryption. In order to implement setups where trusted parties can access a Redis instance over the internet or other untrusted networks, an additional layer of protection should be implemented, such as an SSL proxy. Redis不支持加密。为了实现安全用户通过网络(包括不被信任的网络)进入redis instance进行操作,需要设置一个额外的保护层,比如SSL proxy
  • 31. 持久化机制Redis是一个支持持久化的内存数据库,也就是说redis需要经常将内存中的数据同步到硬盘来保证持久化。 Redis支持两种持久化方式: 1,snapshotting(快照)也是默认方式 (将数据做备份,存到文件中) 2,Append-only file (缩写aof)的方式 (将写、更改操作存到文件中)
  • 32. Snapshotting方式快照是默认的持久化方式。这种方式是将内存中的数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。可以通过配置设置自动做快照持久化的方式。我们可以配置redis在n秒内如果超过m个key被修改就自动做快照。 配置文件: save 900 1 #900秒如果超过一个key被修改,则发起快照保存 save 300 10 #300秒如果超过10个key被修改,则发起快照保存 save 60 10000
  • 33. Aof方式由于快照方式是在一定间隔时间做一次的,如果redis意外down掉的话,就会丢失最后一次快照后的所有修改。 aof比快照方式有更好的持久性,是由于在使用aof时,redis会将每一个收到的命令都通过write函数追加到文件中,当redis重启时会通过重新执行文件中保存的命令来在内存中重建整个数据库的内容。
  • 34. Aof方式当然由于os会在内核中缓存write做的修改,所以可能不是立即写在磁盘上。这样aof方式的持久化也还是有可能会丢失部分修改。 可以通过配置文件告诉redis我们想要通过fsync函数强制os写入磁盘的时机。 配置文件: appendonly yes //启动aof持久化方式 # appendfsync always //收到写命令就立即写入磁盘,最慢,但是保证最完全的持久化 appendfsync everysec //每秒钟写入磁盘一次,在性能和持久化方面做了很好的折中 # appendfsync no //完全依赖os,性能最好,持久化没保证
  • 35. bgrewriteaof命令
  • 36. no-appendfsync-on-rewrite no #在日志重写时,不进行命令追加操作,而只是将其放在缓冲区里,避免与命令的追加造成DISK IO上的冲突。 auto-aof-rewrite-percentage 100 #当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时,自动启动新的日志重写过程。 auto-aof-rewrite-min-size 64mb #当前AOF文件启动新的日志重写过程的最小值,避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。
  • 37. 对比快照重启速度更快 aof对数据完整性保障更高 参考文档: http://blog.chinaunix.net/uid-20682890-id-3603246.html
  • 38. 主从复制Redis主从复制配置和使用都非常简单。通过主从复制可以允许多个slave server拥有和master server相同的数据库副本。
  • 39. Redis主从复制的特点1,redis使用异步复制。从redis2.8开始,slave会定期的对来自replication stream的the amount of data processed进行确认。 2,master可以拥有多个slave 3,多个slave可以连接同一个master外,还可以连接到其他slave 4,主从复制不会阻塞master,在同步数据时,master可以继续处理client请求 5,提高系统的伸缩性
  • 40. Redis主从复制过程1,slave与master建立连接,发送sync同步命令 2,master会启动一个后台进程,将数据库快照保存到文件中,同时master主进程会开始收集新的写命令并缓存。 3,后台完成保存后,就将此文件发送给slave 4, slave将此文件保存到硬盘上。 5,如果master和slave断开,重连时总是会执行全同步操作,但在redis2.8版本开始,部分同步操作成为可能。
  • 41. 配置主从服务器配置slave服务器很简单,只需要在slave的配置文件中假如一下配置: 配置文件: # slaveof 修改: slaveof 192.168.0.50 6379#指定master的ip和端口 如果主机有设置密码: 配置文件: # masterauth 修改: masterauth password #这是主机的密码
  • 42. 查看服务器角色infoINFO [section] 获取服务器的详细信息 role: slave master_link_status : up role : master slave0:192.168.0.50,6379,online
  • 43. Safety of replication when master has persistence turned off In setups where Redis replication is used, it is strongly advised to have persistence turned on in the master, or when this is not possible, for example because of latency concerns, instances should be configured to avoid restarting automatically. To better understand why masters with persistence turned off configured to auto restart are dangerous, check the following failure mode where data is wiped from the master and all its slaves: We have a setup with node A acting as master, with persistence turned down, and nodes B and C replicating from node A. A crashes, however it has some auto-restart system, that restarts the process. However since persistence is turned off, the node restarts with an empty data set. Nodes B and C will replicate from A, which is empty, so they'll effectively destroy their copy of the data. When Redis Sentinel is used for high availability, also turning off persistency on the master, together with auto restart of the process, is dangerous. For example the master can restart fast enough for Sentinel to don't detect a failure, so that the failure mode described above happens. Every time data safety is important, and replication is used with master configured without persistence, auto restart of instances should be disabled.
  • 44. Redis需要注意的问题资料来源:http://www.searchdatabase.com.cn/showcontent_63439.htm 1.Master写内存快照,当快照比较大时对性能影响是非常大的,会间断性暂停服务,所以Master最好不要写内存快照。 2.Master AOF持久化,如果不重写AOF文件,这个持久化方式对性能的影响是最小的,但是AOF文件会不断增大,AOF文件过大会影响Master重启的恢复速度。 3.Master调用BGREWRITEAOF重写AOF文件,AOF在重写的时候会占大量的CPU和内存资源,导致服务load过高,出现短暂服务暂停现象。
  • 45. 4.Redis主从复制的性能问题,第一次Slave向Master同步的实现是:Slave向Master发出同步请求,Master先dump出 rdb文件,然后将rdb文件全量传输给slave,然后Master把缓存的命令转发给Slave,初次同步完成。第二次以及以后的同步实现 是:Master将变量的快照直接实时依次发送给各个Slave。不管什么原因导致Slave和Master断开重连都会重复以上过程。Redis的主从 复制是建立在内存快照的持久化基础上,只要有Slave就一定会有内存快照发生。虽然Redis宣称主从复制无阻塞,但由于Redis使用单线程服务,如 果Master快照文件比较大,那么第一次全量传输会耗费比较长时间,且文件传输过程中Master可能无法提供服务,也就是说服务会中断,对于关键服 务,这个后果也是很可怕的。
  • 46. 5.单点故障问题,由于目前Redis的主从复制还不够成熟,所以存在明显的单点故障问题,这个目前只能自己做方案解决,如:主动复制,Proxy实现 Slave对Master的替换等,这个也是Redis作者目前比较优先的任务之一,作者的解决方案思路简单优雅,详情可见 Redis Sentinel design draft http://redis.io/topics/sentinel-spec。
  • 47.   1.Master最好不要做任何持久化工作,包括内存快照和AOF日志文件,特别是不要启用内存快照做持久化。   2.如果数据比较关键,某个Slave开启AOF备份数据,策略为每秒同步一次。   3.为了主从复制的速度和连接的稳定性,Slave和Master最好在同一个局域网内。   4.尽量避免在压力较大的主库上增加从库    5.为了Master的稳定性,主从复制不要用图状结构,用单向链表结构更稳定,即主从关系 为:Master<--Slave1<--Slave2<--Slave3.......,这样的结构也方便解决单点故障问题,实现 Slave对Master的替换,也即,如果Master挂了,可以立马启用Slave1做Master,其他不变。
  • 48. Redis需要注意的问题Couchbase在数据的持久性方面它区别于其他nosql 的唯一大亮点是不受限于其内存分配了多少,只要磁盘空间够大,数据就会一直往里面写,也就是说无论给Couchbase分配了多少内存,甚至内存满了,只要磁盘还有空间,内存中的数据也还会慢慢同步到磁盘,Redis在方面就不行,redis内存满了,就不会向磁盘同步数据.
  • 49. 解决方案1. 加内存 2. 缩短(或设置)数据过期时间,以释放内存 3. redis集群
  • 50. 过期时间设置setex 设置key对应字符串value,并且设置key在给定的seconds时间之后超时过期。这个命令等效于执行下面的命令: SET mykey value EXPIRE mykey seconds expire 设置key的过期时间。如果key已过期,将会被自动删除。设置了过期时间的key被称之为volatile。 在key过期之前可以重新更新他的过期时间,也可以使用PERSIST命令删除key的过期时间。 返回值 整数,如下的整数结果 1 如果设置了过期时间 0 如果没有设置过期时间,或者不能设置过期时间 persist 移除给定key的生存时间。 ttl 以秒为单位,返回给定 key 的剩余生存时间(TTL, time to live)。
  • 51. pexpire 这个命令和 EXPIRE 命令的作用类似,但是它以毫秒为单位设置 key 的生存时间,而不像 EXPIRE 命令那样,以秒为单位。 返回值: 设置成功,返回 1 key 不存在或设置失败,返回 0 pexpireat PEXPIREAT这个命令和 EXPIREAT命令类似,但它以毫秒为单位设置 key 的过期 unix 时间戳,而不是像 EXPIREAT 那样,以秒为单位。 返回值: 设置成功,返回 1 key 不存在或设置失败,返回 0
  • 52. (本页无文本内容)
  • 53. 发布和订阅消息
  • 54. 事务处理Redis对事物的支持目前还比较简单。Redis只能保证一个client发起的事务中的命令可以连续的执行,而中间不会插入其他其他client的命令。当一个client在一个连接中发出multi命令时,这个链接就会进入一个事务上下文,该链接后续的命令不会立即执行,而是先放到一个队列中,当执行exec命令时,redis会顺序的执行队列中的所有命令。
  • 55. 事务处理APIMulti 标记一个事务块的开始随后的指令将在执行EXEC时作为一个原子执行。 exec 执行事务中所有在排队等待的指令并将链接状态恢复到正常 当使用WATCH 时,只有当被监视的键没有被修改,且允许检查设定机制时,EXEC会被执行 watch 标记所有指定的key 被监视起来,在事务中有条件的执行(乐观锁)。 unwatch 刷新一个事务中已被监视的所有key。 如果执行EXEC 或者DISCARD, 则不需要手动执行UNWATCH 。 discard 刷新一个事务中所有在排队等待的指令,并且将连接状恢复到正常。 如果已使用 WATCH,DISCARD将释放所有WATCH的key。
  • 56. Demo
  • 57. Demo
  • 58. 事务回滚由于age是个数字,它可以有自增运算,但name是个字符窜,无法对其进行自增运算,所以会报错,如果按传统型关系数据库的思路来讲,整个事物都会回滚,但是redis却将可执行的命令提交了。 官方: 1,redis只有在语法错误或者数据类型使用错误等一些在开发过程中会出现的错误才会失败; 2,redis牺牲事物回滚而保证了它最核心的东西——简明高效
  • 59. Why Redis does not support roll backs? If you have a relational databases background, the fact that Redis commands can fail during a transaction, but still Redis will execute the rest of the transaction instead of rolling back, may look odd to you.
  • 60. However there are good opinions for this behavior:Redis commands can fail only if called with a wrong syntax (and the problem is not detectable during the command queueing), or against keys holding the wrong data type: this means that in practical terms a failing command is the result of a programming errors, and a kind of error that is very likely to be detected during development, and not in production. Redis is internally simplified and faster because it does not need the ability to roll back.
  • 61. An argument against Redis point of view is that bugs happen, however it should be noted that in general the roll back does not save you from programming errors. For instance if a query increments a key by 2 instead of 1, or increments the wrong key, there is no way for a rollback mechanism to help. Given that no one can save the programmer from his errors, and that the kind of errors required for a Redis command to fail are unlikely to enter in production, we selected the simpler and faster approach of not supporting roll backs on errors.
  • 62. 取消一个事务
  • 63. 发布订阅消息发布订阅(pub/sub)是一种消息通信模式,主要目的是解除消息发布者和消息订阅者之间的耦合,redis作为一个pub/sub的server,在订阅者和发布者之间起到了消息路由的功能。订阅者可以通关过subscribe和psubscribe命令向redis server订阅自己感兴趣的消息类型,redis将消息类型称为通道(channel)。当发布者通过publish命令想redis server发送特定类型的信息时,订阅该信息类型的全部client都会接收到此消息。
  • 64. 虚拟内存的使用redis的虚拟内存与操作系统的虚拟内存不是一回事,但是思路和目的都是一相同的,就是把暂时不经常访问的数据从内存交换到磁盘中,从而腾出宝贵的内存空间用于其他需要访问的数据。尤其是对于redis这样的内存数据库,内存总是不够用的。使用虚拟内存把那些不经常访问的数据交换到磁盘上能够提高数据库容量。
  • 65. 虚拟内存的配置下面是vm相关配置: vm-enabled yes #开启vm功能 vm-swap-file ./redis.swap#交换出来的value保存的文件路径 vm-max-memory 100 #redis使用的最大内存 vm-page-size 32 #每个页面的大小 vm-pages 10000000 #最多使用多少页面 vm-max-threads 4 #交换文件执行I/O操作时所能用到的最大线程数
  • 66. log4js介绍
  • 67. 下载log4js包~ npm install log4js log4js@0.6.6 node_modules\log4js ├── dequeue@1.0.3 ├── semver@1.1.4 ├── async@0.1.15 └── readable-stream@1.0.2
  • 68. log4js
  • 69. appenders中配置了两个输出,一个是控制台输出,一个是文件输出。 { type: 'console' }, //控制台输出 { type: ‘file’ }, //文件输出 appenders.type=file的对象,指定文件输出位置及文件大小,当超过maxLogSize大小时,会自动生成一个新文件。logs的文件目录要动手创建 maxLogSize :1024 指定
  • 70. log4js的输出级别logger.trace(‘Entering cheese testing’); logger.debug(‘Got cheese.’); logger.info(‘Cheese is Gouda.’); logger.warn(‘Cheese is quite smelly.’); logger.error(‘Cheese is too ripe!’); logger.fatal(‘Cheese was breeding ground for listeria.’)
  • 71. 我们在配置log4js时会有一个问题。就是所有配置信息都是在app.js中做的,logger也是在这里直接定义的。如果在控制器(routes)想用log4js进行输出,我们现在拿不到logger的句柄。