redis安装配置-在centos上

一、redis安装

1、下载获得redis-3.0.4.tar.gz后将它放入我们的Linux目录/opt
2、/opt目录下,解压命令:tar -zxvf redis-3.0.4.tar.gz
3、解压完成后出现文件夹:redis-3.0.4,进入目录:cd redis-3.0.4
4、看到源码包中的 makefile ,直接控制台输入 make 命令编译源代码。
5、
报错1:找不到 gcc ,就直接yum安装 或者 用光盘安装,输入pwd 显示当前路径。
报错2:jomalloc/jomalloc.h 没有那个文件或目录,之前缺gcc编译报错留下残余文件造成的。make distclean 清除之前 make 失败生成的文件
6、编译成功后,输入 make install 安装命令。usr 目录是 程序安装目录 /usr/local/bin /etc 是配置文件目录。

二、编辑配置文件

1、找到redis的配置文件,编辑  成 damen=yes 【vim 进入行末尾 shift + 4 】
2、查找配置文件方法  –>    /etc/redis.conf

[root@superguy ~]# rpm -qa | grep -i redis
redis-3.2.12-1.el7.x86_64
[root@superguy ~]# rpm -ql redis-3.2.12-1.el7.x86_64
/etc/logrotate.d/redis
/etc/redis-sentinel.conf
/etc/redis.conf
/etc/systemd/system/redis-sentinel.service.d
/etc/systemd/system/redis-sentinel.service.d/limit.conf
/etc/systemd/system/redis.service.d
/etc/systemd/system/redis.service.d/limit.conf
/usr/bin/redis-benchmark
/usr/bin/redis-check-aof
/usr/bin/redis-check-rdb
/usr/bin/redis-cli
/usr/bin/redis-sentinel
/usr/bin/redis-server
/usr/lib/systemd/system/redis-sentinel.service
/usr/lib/systemd/system/redis.service
/usr/libexec/redis-shutdown
/usr/share/doc/redis-3.2.12
/usr/share/doc/redis-3.2.12/00-RELEASENOTES
/usr/share/doc/redis-3.2.12/BUGS
/usr/share/doc/redis-3.2.12/CONTRIBUTING
/usr/share/doc/redis-3.2.12/MANIFESTO
/usr/share/doc/redis-3.2.12/README.md
/usr/share/licenses/redis-3.2.12
/usr/share/licenses/redis-3.2.12/COPYING
/usr/share/man/man1/redis-benchmark.1.gz
/usr/share/man/man1/redis-check-aof.1.gz
/usr/share/man/man1/redis-check-rdb.1.gz
/usr/share/man/man1/redis-cli.1.gz
/usr/share/man/man1/redis-sentinel.1.gz
/usr/share/man/man1/redis-server.1.gz
/usr/share/man/man5/redis-sentinel.conf.5.gz
/usr/share/man/man5/redis.conf.5.gz
/var/lib/redis
/var/log/redis
/var/run/redis
[root@superguy ~]# 

三、运行redis服务

redis-server /etc/redis.conf

四、使用redis客户端

[root@superguy ~]# redis-cli
127.0.0.1:6379> exit
[root@superguy ~]# 

 

redis订阅

一、订阅含义

进程间的一种消息通信模式:发送者(pub)发送消息,订阅者(sub)接收消息。

订阅/发布消息图:

三、订阅举例

先订阅后发布 后才能收到消息,
1 可以一次性订阅多个,SUBSCRIBE c1 c2 c3

2 消息发布,PUBLISH c2 hello-redis
=========================================================
3 订阅多个,通配符*, PSUBSCRIBE new*
4 收取消息, PUBLISH new1 redis2015

redis事务-概述

一、事务含义

可以一次执行多个命令,本质是一组命令的集合。一个事务中的所有命令都会序列化,按顺序地串行化执行而不会被其它命令插入,不许加塞。一个队列中,一次性、顺序性、排他性的执行一系列命令。
redis 支持 有限的事务。

二、基本操作流程

1、开启:以MULTI开始一个事务
2、入队:将多个命令入队到事务中,接到这些命令并不会立即执行,而是放到等待执行的事务队列里面
3、执行:由EXEC命令触发事务

(1)如果输入到队列的操作,发现又一个错误,则全体操作都不执行。
(2)如果输入到队列的操作,在执行前没有发现错误,执行时才发现错误。那么错误命令不执行,正确的命令会执行。
(3)如果中途输入 discard 放弃执行事务,则不会执行。

三、watch监控

对某个对象watch添加了CAS(Check And Set),相当于添加了乐观锁。

1、悲观锁(Pessimistic Lock), 顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁。

2、 乐观锁(Optimistic Lock), 顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改, 所以不会上锁 ,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号等机制。乐观锁适用于多读的应用类型,这样可以提高吞吐量,乐观锁策略:提交版本必须大于记录当前版本才能执行更新

初始化信用卡可用余额和欠额
无加塞篡改,先监控再开启multi, 保证两笔金额变动在同一个事务内
有加塞篡改
  监控了key,如果key被修改了,后面一个事务的执行失效
 unwatch
一旦执行了exec之前加的监控锁都会被取消掉了
小结
  Watch指令,类似乐观锁,事务提交时,如果Key的值已被别的客户端改变, 比如某个list已被别的客户端push/pop过了,整个事务队列都不会被执行
  通过WATCH命令在事务执行之前监控了多个Keys,倘若在WATCH之后有任何Key的值发生了变化, EXEC命令执行的事务都将被放弃,同时返回Nullmulti-bulk应答以通知调用者事务执行失败

四、redis事务特性

1、没有隔离级别的概念:队列中的命令没有提交之前都不会实际的被执行,因为事务提交前任何指令都不会被实际执行,也就不存在“事务内的查询要看到事务里的更新,在事务外查询不能看到这个让人万分头痛的问题

2、不保证原子性:redis同一个事务中如果有一条命令执行失败,其后的命令仍然会被执行,没有回滚。【所谓的支持有限的事务】

redis持久化-主从复制和读写分离

一、含义

主机数据更新后根据配置和策略,自动同步到备机的master/slaver机制,Master以写为主,Slave以读为主。

二、操作方法

I、配从(库)不配主(库)
从库配置:slaveof 主库IP 主库端口
(1)每次与master断开之后,都需要重新连接,除非你配置进redis.conf文件
(2)Info replication【查看从属信息】
II、单台主机,配置多个redis实例,需要修改配置文件细节操作
拷贝多个redis.conf文件
开启daemonize yes
Pid文件名字
指定端口
Log文件名字
Dump.rdb名字

三、常见用法

(1)一主二仆
一个Master两个Slave
(2)薪火相传
上一个Slave可以是下一个slave的Master,Slave同样可以接收其他 slaves的连接和同步请求,那么该slave作为了链条中下一个的master, 可以有效减轻master的写压力
中途变更转向:会清除之前的数据,重新建立拷贝最新的
Slaveof 新主库IP 新主库端口
(3)反客为主
SLAVEOF no one
使当前数据库停止与其他数据库的同步,转成主数据库

四、哨兵模式-自动化主从复制

1、是什么
反客为主的自动版,能够后台监控主机是否故障,如果故障了根据投票数自动将从库转换为主库
2、怎么玩(使用步骤)
(1)调整结构,6379端口实例 带着6380、6381
SLAVEOF    IP   端口
(2)配置哨兵,填写内容:
自定义的/myredis目录下新建sentinel.conf文件,名字绝不能错。

sentinel monitor 被监控数据库名字(自己起名字) 127.0.0.1 6379 1
上面最后一个数字1,表示主机挂掉后salve投票看让谁接替成为主机,得票数多少后成为主机

(3)启动哨兵
Redis-sentinel /myredis/sentinel.conf
上述目录依照各自的实际情况配置,可能目录不同
3、正常主从演示
原有的master挂了
投票新选
重新主从继续开工,info replication查查看
问题:如果之前的master重启回来,会不会双master冲突?【不会之前的master会变成slave】

五、复制原理

Slave启动成功连接到master后会发送一个sync命令
Master接到命令启动后台的存盘进程,同时收集所有接收到的用于修改数据集命令, 在后台进程执行完毕之后,master将传送整个数据文件到slave,以完成一次完全同步

全量复制:而slave服务在接收到数据库文件数据后,将其存盘并加载到内存中。
增量复制:Master继续将新的所有收集到的修改命令依次传给slave,完成同步
但是只要是重新连接master,一次完全同步(全量复制)将被自动执行

六、复制的缺点

由于所有的写操作都是先在Master上操作,然后同步更新到Slave上,所以从Master同步到Slave机器有一定的延迟,当系统很繁忙的时候,延迟问题会更加严重,Slave机器数量的增加也会使这个问题更加严重。

redis持久化-RDB和AOF

aof和rdb可以共存,首先加载aof,如果aof文件损坏,redis启动报错。
RDB的数据不实时,同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢?
作者建议不要,因为RDB更适合用于备份数据库(AOF在不断变化不好备份),
快速重启,而且不会有AOF可能潜在的bug,留着作为一个万一的手段。

一、RDB

1、RDB含义

在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里。

Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能。

如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

2、fork方法

Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据(变量、环境变量、程序计数器等)数值都和原进程一致,但是是一个全新的进程,并作为原进程的子进程。

3、触发rdb方法

(1)配置文件中默认的快照配置。
save 900 1
save 300 10
save 60 10000
(2)命令save或者是bgsave
Save:save时只管保存,其它不管,全部阻塞。
BGSAVE:Redis会在后台异步进行快照操作,
快照同时还可以响应客户端请求。可以通过lastsave
命令获取最后一次成功执行快照的时间。
(3)执行flushall命令,也会产生dump.rdb文件,但里面是空的,无意义。

3、恢复信息方法

(1)将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可。
(2)CONFIG GET dir获取目录。

4、优势和劣势

优势
适合大规模的数据恢复。
对数据完整性和一致性要求不高。
劣势
在一定间隔时间做一次备份,所以如果redis意外down掉的话,就会丢失最后一次快照后的所有修改。
Fork的时候,内存中的数据被克隆了一份,大致2倍的膨胀性需要考虑。

5、禁用rdb

动态所有停止RDB保存规则的方法:redis-cli config set save “”

二、AOF

1、AOF的含义

以日志的形式来记录每个写操作,将Redis执行过的所有写指令记录下来(读操作不记录),
只许追加文件但不可以改写文件,redis启动之初会读取该文件重新构建数据,换言之,redis
重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

2、启用AOF

在配置文件中,修改默认的appendonly no,改为yes

3、Rewrite重写机制

(1)含义:
AOF采用文件追加方式,文件会越来越大为避免出现此种情况,新增了重写机制,当AOF文件的大小超过所设定的阈值时,Redis就会启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof。
(2)原理:
AOF文件持续增长而过大时,会fork出一条新进程来将文件重写(也是先写临时文件最后再rename),
遍历新进程的内存中数据,每条记录有一条的Set语句。重写aof文件的操作,并没有读取旧的aof文件,
而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,这点和快照有点类似。
(3)触发机制:
Redis会记录上次重写时的AOF大小,默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。

4、恢复信息

正常恢复
将有数据的aof文件复制一份保存到对应目录(config get dir)
恢复:重启redis然后重新加载
异常恢复
备份被写坏的AOF文件
修复:
Redis-check-aof –fix进行修复
恢复:重启redis然后重新加载

5、优势和劣势

优势:
每修改同步:appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好
每秒同步:appendfsync everysec 异步操作,每秒记录 如果一秒内宕机,有数据丢失
不同步:appendfsync no 从不同步
劣势:
相同数据集的数据而言aof文件要远大于rdb文件,恢复速度慢于rdb
Aof运行效率要慢于rdb,每秒同步策略效率较好,不同步效率和rdb相同

三、性能比较

因为RDB文件只用作后备用途,建议只在Slave上持久化RDB文件,而且只要15分钟备份一次就够了,只保留save 900 1这条规则。

如果Enalbe AOF,好处是在最恶劣情况下也只会丢失不超过两秒数据,启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO,二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可,应该尽量减少AOF rewrite的频率,AOF重写的基础大小默认值64M太小了,可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。

如果不Enable AOF ,仅靠Master-Slave Replication 实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉,会丢失十几分钟的数据,启动脚本也要比较两个Master/Slave中的RDB文件,载入较新的那个。新浪微博就选用了这种架构 。

 

 

redis配置文件-常见总结

参数说明
redis.conf 配置项说明如下:
1. Redis默认不是以守护进程的方式运行,可以通过该配置项修改,使用yes启用守护进程
daemonize no
2. 当Redis以守护进程方式运行时,Redis默认会把pid写入/var/run/redis.pid文件,可以通过pidfile指定
pidfile /var/run/redis.pid
3. 指定Redis监听端口,默认端口为6379,作者在自己的一篇博文中解释了为什么选用6379作为默认端口,因为6379在手机按键上MERZ对应的号码,而MERZ取自意大利歌女Alessia Merz的名字
port 6379
4. 绑定的主机地址
bind 127.0.0.1
5.当 客户端闲置多长时间后关闭连接,如果指定为0,表示关闭该功能
timeout 300
6. 指定日志记录级别,Redis总共支持四个级别:debug、verbose、notice、warning,默认为verbose
loglevel verbose
7. 日志记录方式,默认为标准输出,如果配置Redis为守护进程方式运行,而这里又配置为日志记录方式为标准输出,则日志将会发送给/dev/null
logfile stdout
8. 设置数据库的数量,默认数据库为0,可以使用SELECT 命令在连接上指定数据库id
databases 16
9. 指定在多长时间内,有多少次更新操作,就将数据同步到数据文件,可以多个条件配合
save
Redis默认配置文件中提供了三个条件:
save 900 1
save 300 10
save 60 10000
分别表示900秒(15分钟)内有1个更改,300秒(5分钟)内有10个更改以及60秒内有10000个更改。

10. 指定存储至本地数据库时是否压缩数据,默认为yes,Redis采用LZF压缩,如果为了节省CPU时间,可以关闭该选项,但会导致数据库文件变的巨大
rdbcompression yes
11. 指定本地数据库文件名,默认值为dump.rdb
dbfilename dump.rdb
12. 指定本地数据库存放目录
dir ./
13. 设置当本机为slav服务时,设置master服务的IP地址及端口,在Redis启动时,它会自动从master进行数据同步
slaveof
14. 当master服务设置了密码保护时,slav服务连接master的密码
masterauth
15. 设置Redis连接密码,如果配置了连接密码,客户端在连接Redis时需要通过AUTH 命令提供密码,默认关闭
requirepass foobared
16. 设置同一时间最大客户端连接数,默认无限制,Redis可以同时打开的客户端连接数为Redis进程可以打开的最大文件描述符数,如果设置 maxclients 0,表示不作限制。当客户端连接数到达限制时,Redis会关闭新的连接并向客户端返回max number of clients reached错误信息
maxclients 128
17. 指定Redis最大内存限制,Redis在启动时会把数据加载到内存中,达到最大内存后,Redis会先尝试清除已到期或即将到期的Key,当此方法处理 后,仍然到达最大内存设置,将无法再进行写入操作,但仍然可以进行读取操作。Redis新的vm机制,会把Key存放内存,Value会存放在swap区
maxmemory
18. 指定是否在每次更新操作后进行日志记录,Redis在默认情况下是异步的把数据写入磁盘,如果不开启,可能会在断电时导致一段时间内的数据丢失。因为 redis本身同步数据文件是按上面save条件来同步的,所以有的数据会在一段时间内只存在于内存中。默认为no
appendonly no
19. 指定更新日志文件名,默认为appendonly.aof
appendfilename appendonly.aof
20. 指定更新日志条件,共有3个可选值:
no:表示等操作系统进行数据缓存同步到磁盘(快)
always:表示每次更新操作后手动调用fsync()将数据写到磁盘(慢,安全)
everysec:表示每秒同步一次(折衷,默认值)
appendfsync everysec

21. 指定是否启用虚拟内存机制,默认值为no,简单的介绍一下,VM机制将数据分页存放,由Redis将访问量较少的页即冷数据swap到磁盘上,访问多的页面由磁盘自动换出到内存中(在后面的文章我会仔细分析Redis的VM机制)
vm-enabled no
22. 虚拟内存文件路径,默认值为/tmp/redis.swap,不可多个Redis实例共享
vm-swap-file /tmp/redis.swap
23. 将所有大于vm-max-memory的数据存入虚拟内存,无论vm-max-memory设置多小,所有索引数据都是内存存储的(Redis的索引数据 就是keys),也就是说,当vm-max-memory设置为0的时候,其实是所有value都存在于磁盘。默认值为0
vm-max-memory 0
24. Redis swap文件分成了很多的page,一个对象可以保存在多个page上面,但一个page上不能被多个对象共享,vm-page-size是要根据存储的 数据大小来设定的,作者建议如果存储很多小对象,page大小最好设置为32或者64bytes;如果存储很大大对象,则可以使用更大的page,如果不 确定,就使用默认值
vm-page-size 32
25. 设置swap文件中的page数量,由于页表(一种表示页面空闲或使用的bitmap)是在放在内存中的,,在磁盘上每8个pages将消耗1byte的内存。
vm-pages 134217728
26. 设置访问swap文件的线程数,最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的,可能会造成比较长时间的延迟。默认值为4
vm-max-threads 4
27. 设置在向客户端应答时,是否把较小的包合并为一个包发送,默认为开启
glueoutputbuf yes
28. 指定在超过一定的数量或者最大的元素超过某一临界值时,采用一种特殊的哈希算法
hash-max-zipmap-entries 64
hash-max-zipmap-value 512
29. 指定是否激活重置哈希,默认为开启(后面在介绍Redis的哈希算法时具体介绍)
activerehashing yes
30. 指定包含其它的配置文件,可以在同一主机上多个Redis实例之间使用同一份配置文件,而同时各个实例又拥有自己的特定配置文件
include /path/to/local.conf

redis用法-基本数据类型操作

redis <k,V>中k的操作

keys *
exists key的名字,判断某个key是否存在
move key db —>当前库就没有了,被移除了
expire key 秒钟:为给定的key设置过期时间
ttl key 查看还有多少秒过期,-1表示永不过期,-2表示已过期
type key 查看你的key是什么类型

一、String(字符串)

string是redis最基本的类型,你可以理解成与Memcached一模一样的类型,一个key对应一个value。
string类型是二进制安全的。意思是redis的string可以包含任何数据。比如jpg图片或者序列化的对象 。
string类型是Redis最基本的数据类型,一个redis中字符串value最多可以是512M。

 set/get/del/append/strlen
Incr/decr/incrby/decrby,一定要是数字才能进行加减
 getrange/setrange
 setex(set with expire)键秒值/setnx(set if not exist)
 mset/mget/msetnx
 getset(先get再set)

二、Hash(哈希,类似java里的Map)

Redis hash 是一个键值对集合。 类似Java里面的Map<String,Object>
Redis hash是一个string类型的field和value的映射表,hash特别适合用于存储对象。

 hset/hget/hmset/hmget/hgetall/hdel
 hlen
 hexists key 在key里面的某个值的key
 hkeys/hvals
 hincrby/hincrbyfloat
 hsetnx

三、List(列表)

Redis 列表是简单的字符串列表,按照插入顺序排序。你可以添加一个元素导列表的头部(左边)或者尾部(右边)。它的底层实际是个链表。

案例
   lpush/rpush/lrange
   lpop/rpop
   lindex,按照索引下标获得元素(从上到下)
   llen
   lrem key 删N个value
   ltrim key 开始index 结束index,截取指定范围的值后再赋值给key
   rpoplpush 源列表 目的列表
   lset key index value
   linsert key  before/after 值1 值2
  
性能总结:
它是一个字符串链表,left、right都可以插入添加; 
如果键不存在,创建新的链表; 如果键已存在,新增内容; 
如果值全移除,对应的键也就消失了。 
链表的操作无论是头和尾效率都极高,但假如是对中间元素进行操作,效率就很惨淡了。

四、Set(集合)

Redis的Set是string类型的无序集合。它是通过HashTable实现实现的。

 sadd/smembers/sismember
 scard,获取集合里面的元素个数
 srem key value 删除集合中元素
 srandmember key 某个整数(随机出几个数)
 spop key 随机出栈
 smove key1 key2 在key1里某个值      作用是将key1里的某个值赋给key2
 数学集合类
  差集:sdiff
  交集:sinter
  并集:sunion

 

五、Zset(sorted set:有序集合)

Redis zset 和 set 一样也是string类型元素的集合,且不允许重复的成员。 不同的是每个元素都会关联一个double类型的分数。
redis正是通过分数来为集合中的成员进行从小到大的排序。 zset的成员是唯一的,但分数(score)却可以重复。

多说一句
  在set基础上,加一个score值。 之前set是k1 v1 v2 v3, 现在zset是k1 score1 v1 score2 v2
常用
案例
   zadd/zrange
    Withscores
   zrangebyscore key 开始score 结束score
   zrem key 某score下对应的value值,作用是删除元素
   zcard/zcount key score区间/zrank key values值,作用是获得下标值/zscore key 对应值,获得分数
   zrevrank key values值,作用是逆序获得下标值
   zrevrange
   zrevrangebyscore  key 结束score 开始score

 

redis用法-入门操作常识

Redis索引都是从零开始

一、启动与关闭

运行方式:  redis-server 配置文件目录
           redis-cli  -p 6379
           ping   pong
                   
           set k1 hello
           get k1 
关闭    SHUTDOWN 
       exit

 二、单进程

单进程模型来处理客户端的请求。对读写等事件的响应是通过对epoll函数的包装来做到的。
Redis的实际处理速度完全依靠主进程的执行效率。
Epoll是Linux内核为处理大批量文件描述符而作了改进的epoll,是Linux下多路复用IO接口select/poll的增强版本,它能显著提高程序在大量并发连接中只有少量活跃的情况下的系统CPU利用率。

 三、数据库

1、默认16个数据库,类似数组下表从零开始,初始默认使用零号库。可以使用SELECT 命令在连接上指定数据库id
2、Dbsize查看当前数据库的key的数量。Flushdb:清空当前库。Flushall;通杀全部库。

 四、安全

统一密码管理,16个库都是同样密码,要么都OK要么一个也连接不上。
config get requirepass
config set requirepass 123456
操作: auth 123456

redis入门概述

一、redis含义

Redis:REmote DIctionary Server(远程字典服务器)

是完全开源免费的,用C语言编写的,遵守BSD协议,是一个高性能的(key/value)分布式内存数据库,基于内存运行并支持持久化的NoSQL数据库,是当前最热门的NoSql数据库之一,也被人们称为数据结构服务器。

Redis 与其他 key – value 缓存产品有以下三个特点:
1、Redis支持数据的持久化,可以将内存中的数据保持在磁盘中,重启的时候可以再次加载进行使用。
2、Redis不仅仅支持简单的key-value类型的数据,同时还提供list,set,zset,hash等数据结构的存储。
3、Redis支持数据的备份,即master-slave模式的数据备份。

二、redis用处

(1)内存存储和持久化:redis支持异步将内存中的数据写到硬盘上,同时不影响继续服务。
(2)取最新N个数据的操作,如:可以将最新的10条评论的ID放在Redis的List集合里面。
(3)模拟类似于HttpSession这种需要设定过期时间的功能.
(4)发布、订阅消息系统。
(5)定时器、计数器。

 

nosql入门概述-(4)-CAP原理与ACID

一、关系型数据库遵循ACID规则

事务在英文中是transaction,和现实世界中的交易很类似,它有如下四个特性:

1、A (Atomicity) 原子性

原子性很容易理解,也就是说事务里的所有操作要么全部做完,要么都不做,事务成功的条件是事务里的所有操作都成功,只要有一个操作失败,整个事务就失败,需要回滚。比如银行转账,从A账户转100元至B账户,分为两个步骤:1)从A账户取100元;2)存入100元至B账户。这两步要么一起完成,要么一起不完成,如果只完成第一步,第二步失败,钱会莫名其妙少了100元。

2、C (Consistency) 一致性

一致性也比较容易理解,也就是说数据库要一直处于一致的状态,事务的运行不会改变数据库原本的一致性约束。

3、I (Isolation) 独立性

所谓的独立性是指并发的事务之间不会互相影响,如果一个事务要访问的数据正在被另外一个事务修改,只要另外一个事务未提交,它所访问的数据就不受未提交事务的影响。比如现有有个交易是从A账户转100元至B账户,在这个交易还未完成的情况下,如果此时B查询自己的账户,是看不到新增加的100元的

4、D (Durability) 持久性

持久性是指一旦事务提交后,它所做的修改将会永久的保存在数据库上,即使出现宕机也不会丢失。

二、nosql中的cap原理

C:Consistency(强一致性) A:Availability(可用性) P:Partition tolerance(分区容错性)

CAP理论就是说在分布式存储系统中,最多只能实现上面的两点。

因此,根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类:
CA – 单点集群,满足一致性,可用性的系统,通常在可扩展性上不太强大。
CP – 满足一致性,分区容忍必的系统,通常性能不是特别高。
AP – 满足可用性,分区容忍性的系统,通常可能对一致性要求低一些。

而由于当前的网络硬件肯定会出现延迟丢包等问题,所以分区容忍性是我们必须需要实现的。
所以我们只能在一致性和可用性之间进行权衡,没有NoSQL系统能同时保证这三点。
=========================================================
C:强一致性    A:高可用性      P:分布式容忍性
CA 传统Oracle数据库   AP 大多数网站架构的选择    CP Redis、Mongodb

注意:分布式架构的时候必须做出取舍。
一致性和可用性之间取一个平衡。多余大多数web应用,其实并不需要强一致性。
因此牺牲C换取P,这是目前分布式数据库产品的方向
=========================================================
一致性与可用性的决择:对于web2.0网站来说,关系数据库的很多主要特性却往往无用武之地。

数据库事务一致性需求
很多web实时系统并不要求严格的数据库事务,对读一致性的要求很低, 有些场合对写一致性要求并不高。允许实现最终一致性。

数据库的写实时性和读实时性需求
对关系数据库来说,插入一条数据之后立刻查询,是肯定可以读出来这条数据的,但是对于很多web应用来说,并不要求这么高的实时性,比方说发一条消息之 后,过几秒乃至十几秒之后,我的订阅者才看到这条动态是完全可以接受的。

对复杂的SQL查询,特别是多表关联查询的需求
任何大数据量的web系统,都非常忌讳多个大表的关联查询,以及复杂的数据分析类型的报表查询,特别是SNS类型的网站,从需求以及产品设计角 度,就避免了这种情况的产生。往往更多的只是单表的主键查询,以及单表的简单条件分页查询,SQL的功能被极大的弱化了。

三、base解决方案

在AP方案中,如何解决一致性问题:

BASE其实是下面三个术语的缩写:
基本可用(Basically Available)
软状态(Soft state)
最终一致(Eventually consistent)

它的思想是通过让系统放松对某一时刻数据一致性的要求来换取系统整体伸缩性和性能上改观。为什么这么说呢,缘由就在于大型系统往往由于地域分布和极高性能的要求,不可能采用分布式事务来完成这些指标,要想获得这些指标,我们必须采用另外一种方式来完成,这里BASE就是解决这个问题的办法