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语言编写、3万多行代码、支持网络、可基于内存亦可久化的日志型、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.redis.io
|
|
命令执行完成后,会在/app/redis-3.2.8/bin/目录下生成5个可执行文件
|
|
配置并启动Redis服务
文件头部分
操作命令:
|
|
查看命令帮助
|
|
启动redis服务
创建配置文件,redis的配置文件在二进制安装包解压目录下的 redis.conf
|
|
启动命令
|
|
启动错误
|
|
原因:此参数确定了TCP连接中已完成队列(完成三次握手之后)的长度, 当然此值必须不大于Linux系统定义的/proc/sys/net/core/somaxconn值,默认是511,而Linux的默认参数值是128。当系统并发量大并且客户端速度缓慢的时候,可以将这二个参数一起参考设定。
暂时解决:redis.conf中 tcp backlog=128
|
|
原因:
overcommit_memory参数说明:
设置内存分配策略(可选,根据服务器的实际情况进行设置)/proc/sys/vm/overcommit_memory可选值:0、1、2。
0:当用户空间请求更多的内存时,内核尝试估算出剩余可用的内存。
1:设这个参数值为1时,内核允许超量舒勇内存直到用完为止,主要用于科学计算。(最大限度的使用内存)
2:当设这个参数值为2时,内核会使用一个决不过量使用内存的算法,即系统整个内存地址空间不能超过swap+50%的RAM值,50%参数的设定是在overcommit_ratio中设定。
解决:sysctl vm.overcommit_memory=1*
|
|
原因
临时解决方法:
|
|
参考文档:http://blog.csdn.net/a491857321/article/details/52006376
客户端测试redis服务
redis-cli客户端帮助
|
|
使用redis-cli客户端连接redis
指定密码 ip 端口登陆
|
|
在Linux命令行操作redis
|
|
使用telnet连接redis
|
|
通过NC连接redis
|
|
关闭redis服务
|
|
通过客户端测试redis服务
PHP安装Redis扩展
源码地址:
https://github.com/phpredis/phpredis
http://pecl.php.net/package/redis
安装
|
|
修改php.ini设置
|
|
查看结果
Redis配置文件注解
|
|
更多配置详情:http://www.cnblogs.com/zhang-ke/p/5981108.html