数据缓存

来源:互联网 发布:大风刮过知乎 编辑:程序博客网 时间:2024/05/07 08:49
NoSQL数据库的四大分类
  1、键值对存储 优:快速查询 劣:存储数据缺少内容 redis
  2、列存储 优:查找速度快,扩展性强 劣:功能相对局限 hbase
  3、文档数据库 优:数据结构要求不严格 劣:查询性能不高 ,缺少统一的查询语法 mongodb
  4、图形数据库 优:利用图结构的相关算法 劣:需要对整个图做计算才能得出结果,不容易做分布式的集群方案
redis 的五大数据类型
  1、字符串类型
  2、列表类型
  3、集合类型
  4、有序集合类型
  5、散列类型
Redis缓存
string:比如想知道什么时候封锁一个IP地址(访问超过几次),INCRBY命令让这些变得很容易,通过原子递增保持计数。  
Hash:比如我们要存储一个用户信息对象数据
List:
set: 比如在微博应用中,每个人的好友存在一个集合(set)中,这样求两个人的共同好友的操作,可能就只需要用求交集命令即可。  
Sort Set:全班同学成绩的SortedSets,value可以是同学的学号,而score就可以是其考试得分,这样数据插入集合的,就已经进行了天然的排序。 
redis的RDB与AOF:
内存到磁盘,磁盘到内存
rdb:快照形式是直接把内存中的数据保存到一个dump文件中,定时保存,保存策略
缺点:不能完全保证数据持久化、写操作多影响性能
save 900 1     #900秒时间,至少有一条数据更新,则保存到数据文件中
save 300 10    #300秒时间,至少有10条数据更新,则保存到数据文件中
save 60 10000  #60秒时间,至少有10000条数据更新,则保存到数据文件中
rdbcompression yes   数据rdb压缩设置
dbfilename dump.rdb #指定rdb保存到本地数据库文件名
rdbchecksum yes    #对rdb文件进行校验
出厂默认配置:
一分钟一万
五分钟十次
十五分一次
aof:把所有的对redis的服务器进行修改的命令都存到一个文件里,命令的集合
appendonly yes
appendfilename appendonly.aof  
# always:表示每次更新操作后手动调用fsync()将数据写到磁盘(慢,安全) 
# appendfsync always      
# everysec:表示每秒同步一次(折衷,默认值)
appendfsync everysec       
# no:表示等操作系统进行数据缓存同步到磁盘(快) 
# appendfsync no             
RDB[snapshots]优点:
使用单独子进程来进行持久化,主进程不会进行任何IO操作,保证了redis的高性能;
恢复大数据的时候,rdb会更快一些
RDB缺点:
RDB是间隔一段时间进行持久化,如果持久化redis发生故障,会发生数据丢失
AOF优点:
可以保持更高的数据完整性
Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大
RDB缺点:
aof经常fork子进程保存数据到磁盘;AOF文件比RDB文件大,且恢复速度慢
性能建议:
1、因为RDB文件只用作后备用途,建议只在Slave上持久化RDB文件,而且只要15分钟备份一次就够了,只保留save 900 1这条规则
2、如果Enalbe AOF,好处是在最恶劣情况下也只会丢失不超过两秒数据,启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO,二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。
3、只要硬盘许可,应该尽量减少AOF rewrite的频率,AOF重写的基础大小默认值64M太小了,可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。  
4、如果不Enable AOF ,仅靠Master-Slave Replication 实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉,会丢失十几分钟的数据,启动脚本也要比较两个Master/Slave中的RDB文件,载入较新的那个。
Redis事务:
case1:正常执行 执行exec全部成功
Case2:放弃事务 执行Discard
Case3:全体连坐在向事物队列中添加命令的时候报错,然后执行Exec会全部失败。
Case4:冤头债主在向事物队列中添加命令的时候没有报错,但在执行Exec的时候某一条命令执行失败,只会影响这一个其他的会执行成功。这种为部分成功。
Case5:watch监控
原创粉丝点击