nosql
是什么
NoSQL(Not Only SQL),意即"不仅仅是SQL"
泛指非关系型数据库。 随着互联网web2.0网站的兴起,传统的关系型数据库在应付web2.0网站,特别是超大规模和高并发的SNS类型的web2.0纯***站已经显得力不从心,暴露了很多难以克服的问题,而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战,有其是大数据应用难题,包括大规模数据的存储。
这些类型的数据存储不需要固定的模式,无需多余的操作就可以横向扩展。
能干嘛
-
易扩展
- NoSQL数据库种类繁多,但是一个共同的特点都是去掉关系型数据库的关系特性。
- 数据之间无关系,这样就非常容易扩展。业务兴建在架构的层面上带来了可扩扎的能力。
-
大数据量高性能
-
NoSQL数据库都具有非常高的读写性能,有其在大数据量下,同样表现优秀。
这得益于它的无关性数据结构简单。
-
一般的MySQL使用Query Cache,每次表的更新Cache就失效,是一种大粒度的Cache
在针对web2.0的的交互频繁的应用,Cache性能不高。
-
而NoSQL的Cache是记录级的,是一种细粒度的Cache,所以NoSQL在这个层面上来说性能就高很多。
-
-
多样两行的数据类型
- NoSQL无需事先为要存储的数据建立字段,随时可以存储自定义的数据格式。
- 在关系数据库中增加字段试衣间非常麻烦的事情。如果是非常大数据量的表,增加字段简直就是一个噩梦。
-
RDBMS vs NoSQL
- RDBMS
- 高度组织化结构化数据
- 结构化查询语言(SQL)
- 数据和关系都存储在单独的表中
- 数据操作语言,数据定义语言
- 严格的一致性
- 基础事务
- NoSQL
- 代表着不仅仅是SQL
- 没有声明性查询语言
- 没有预定义的模式
- 键 - 值 对存储,列存储,文档存储,图形数据库
- 最终一致性,而非ACID属性
- 非结构化和不可预知的数据
- CAP定理
- 高性能,高可用性和可伸缩性
- RDBMS
去哪下
- Redis
- Memcache
- Mongdb
怎么玩
- KV
- Cache
- Persistence
- ...
3V和3高
大数据时代的3V
- 海量 Volume
- 多样 Variety
- 实时 Velocity
互联网要求的3高
- 高并发
- 高可扩
- 高性能(高可用)
NoSQL数据模型简介
KV键值对(最常用)
BSON(最常用)
BSON是一种类json的二进制形式的存储格式,全称Binary JSON
它和json一样,支持内嵌的文档对象和数组对象
列族
按列存储数据,最大的特点是方便存储结构化和半结构化数据,方便做数据压缩。
对针对某一列或者某几列的查询有非常大的IO优势。
图形
图结构
CAP+BASE
CAP
CAP的3进2
- Consistence 强一致性
- Availability 可用性
- Partition tolerance 分区容错性
CAP理论就是说在分布式存储系统中,最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题,所以
分区容错性是我们必须实现的
所以我们只能在一致性和可用性之间进行权衡,没有NoSQL系统能同时保证这三点。
- CA 传统Oracle数据库
- AP 大多数网站架构的选择
- CP Redis、MongoDB
BASE
BASE就是为了解决关系数据库强一致性引起的问题而引起的可用性降低而提出的解决方案
BASE其实是下面三个术语的缩写
- 基本可用(Basically Avaulable)
- 软状态(Soft state)
- 最终一直(Eventually consistent)
它的思想是通过让系统放松对某一时刻数据一致性的要求来换取系统整体伸缩性和性能上改观。大型系统往往由于地域分布和极高性能的要求,不可能采用分布式事务来完成这些指标,想要获得这些指标,我们必须采用另外一种方式来完成,这里的BASE就是解决这个问题的办法。
分布式系统
分布式系统(distributed system),由多台计算机 不和通信的软件组件通过计算机网络连接(本地网络或广域网)组成。分布式系统是建立在网络之上的软件系统。正是因为软件的特性,所以分布式系统具有高度的内举行和透明性。因此,网络和分布式系统之间的区别更多的在于高层软件(特别是操作系统),而不是硬件。分布式系统可以应用在不同的平台上,如PC、工作站、局域网、广域网等。
简单来讲:
分布式: 不同的多台服务器上面不熟不同的服务模块(工程),它们之间通过Rpc/Rmi之间通信和调用,对外提供服务和组内协作。
集群: 不同的多台服务器上面部署相同的服务模块,通过分布式调度软件进行统一调度,对外提供服务和访问。
Redis入门介绍
入门概述
1是什么
Redis: REmote DIctionary Server(远程字典服务器)
完全开源免费的,用C语言编写的,遵守BSD协议,
是一个高性能的(K/V)分布式内存数据库,基于内存运行并支持持久化的NoSQL数据库,是当前最热门的NoSQL数据库之一,也被人们称为数据结构服务器
Redis和其他K/V型NoSQL数据库都有以下三个特点:
- Redis支持数据的持久化,可以将内存中的数据保存在磁盘中,重启的时候可以再次加载进行使用
- Redis不仅仅支持简单的key-value型数据,同时还提供lisy,set,zset,hash等数据结构的存储
- Redis支持数据的备份,即master-slave模式的数据备份。
2能干嘛
- 内存存储和持久化:redis支持异步将内存中的数据写到硬盘上,同时不影响继续服务
- 取最新N个数据的操作,如: 可以将最新的10条评论的ID放到Redis的List集合中
- 模拟类似于HttpSession这种需要设定过期时间的功能
- 发布、订阅消息系统
- 定时器、计数器
3去哪下
4怎么玩
- 数据类型、基本操作和配置
- 持久化和复制,RDB/AOF
- 事务的控制
- 复制
- ...
启动命令
启动服务器 redis-server conf-path
启动客户端 redis-cli -p 6379
Redis启动后杂项基础知识讲解
- 单进程
- 单进程模型来 处理客户端的请求。对读写等事件的响应是通过对epoll函数的包装来做到的。Redis的实际处理速度完全依靠主进程的执行效率。
- Epoll是Linux内核为处理大批量文件描述符而作了改进的epoll,是Linux下多路复用IO接口select/poll的增强版本,它能显著提高程序在大量并发连接中只有少量活跃的情况下的系统CPU利用率。
- 默认16个数据库,类似数组下标从0开始,初始默认使用0号库
- select命令切换数据库
- dbsize查看当前数据库的key的数量
- flushdb: 清空当前库
- flushall: 封杀全部库
- 统一密码管理,16个库都是同样的密码,要么都OK要么都连不上
- Redis索引都是从0开始
Redis数据类型
Redis 的五大数据类型
- String
- string类型是redis最基本的类型,一个key对应一个value
- string类型是二进制安全的。意思是redis的string可以包含任何数据。比如jpg图片或序列化的对象。
- string类型是redis最基本的数据类型,一个redis字符串value最多可以是512M。
- Hash(类似java里的Map)
- redis hash 是一个键值对集合
- redis hash是一个string类型的field和value的映射表,hash特别适合用于存储对象。
- 类似于java里面的Map<String,Object>
- List(列表)
- redis列表是简单的字符串列表,按照 插入顺序排序,你可以添加一个元素到列表的头部或尾部
- 它的底层实际是个链表
- Set(集合)
- Redis的Set是String类型的无序集合。它是通过HashTable实现的
- Zset(sorted set: 有序集合)
- redis zset 和 set一样也是string类型元素的集合,且不允许重复的成员
- 不同的每个元素都会关联一个double类型的分数
- redis正是通过分数来为集合中的成员进行从小到大的排序。zset的成员是唯一的,但分数(scope)却可以重复。
哪里去获得redis常见数据类型操作命令
Redis 键(Key)
常用:
- DEL key
- DUMP key: 序列化给定key,并返回被序列化的值
- EXPIREAT key timestamp: 给key设置过期时间,时间参数为unix时间戳
- PEXPIRE key milliseconds: 设置key的过期时间以毫秒计
- PEXPIRE key milliseconds-stamp: 设置key的过期时间戳以毫秒计
- KEYS pattern: 查找所有符合给定模式(pattern)的key
- PERSIST key: 移除key的过期时间
- PTTL key: 以毫秒为单位返回key的剩余过期时间
- RANDOMKEY: 随机从数据库中返回一个key
- RENAME key newkey: 如果newkey与其他key重合会导致覆盖原有key的value
- RENAMEKEYX key newkey: 仅当newkey不存在时,将key改名为newkey
案例:
- keys *
- exists keyname
- move key db
- expire key secend: 为给定的key设置过期时间
- ttl key: 查看还有多少秒过期,-1表示永不过期,-2表示已过期
- type key: 查看key的类型
Redis 字符串(String)
单值单value
案例:
- set/get/del/append/strlen
- Incr/decr/incrby/decrby,一定要是数字才能进行加减操作
- getrange/setrange: setrange相当于replace,getrange相当于substring
- setex(set with expire)键秒值/setnx(set if not exist)
- mset/mget/msetnx: 多次操作
- mset k1 v1 k2 v2
- mget k1 k2
- ...
- getset(先get再set)
Redis 列表(List)
单值多value
案例:
- lpush/rpush/lrange: lrange取值
- lpop/rpop
- lindex: 按照索引下标获得元素
- llen
- lrem key N 删N个value
- ltrim key start stop: 截取指定范围赋值给key
- rpoplpush source destination
- lset key index value
- linsert key before/after pivot value: 把value插到pivot前/后
如果值全移除,对应的键就消失了
如果键不存在,创建新的链表
如果键存在,新增内容
Redis 集合(Set)
单值多value
案例:
- sadd/smembers/sismember
- scard: 相当于size
- srem key value
- srandmember key count: 随机返回count个元素
- spop key: 随机出栈
- smove key1 key2 value:将key1 里的value移动到key2中
- 数学集合类:
- 差集: sdiff
- 交集: sinter
- 并集: sunion
Redis 哈希(Hash)
KV模式不变,但V是一个键值对
案例:
- hset/hget/hmset/hgetall/hdel
- hlen
- hexists key
- hkeys/hvals
- hincrby/hincrbyfloat
- hsetnx
Redis 有序集合Zset(sorted set)
多说一句:
在set基础之上,加一个score值。
之前set是k1 v1 v2 v3
现在zset是k1 score1 v1 score2 v2
案例:
- zadd/zrange withscore
- zrangebuscore key
- withscores
- ( 不包含
- Limit 作用是返回限制
- zrem key
- zcard key
- zcount key min max
- zrank key value 获得下标
- zrevrank key value
- zrevrange
- zrevrangebyscore key end start
解析配置文件redis.conf
他在哪
/opt/redis-x.x.x/redis.conf
Units单位
- 配置大小单位,开头定义了一些基本的度量单位,只支持bytes,不支持bit
- 对大小写不敏感
INCLUDES 包含
redis.conf可以作为总闸,通过includes包含其他配置文件
GENERAL通用(重点)
- daemonize(守护进程)
- pidfile
- port
- tcp-backlog
- 设置tcp的backlog,backlog其实是一个连接队列,backlog队列总和=未完成的三次握手队列+已完成的三次握手队列。在高并发管径下你需要一个高backlog值来避免慢客户端连接问题。之一Linux内核会将这个值减小到/proc/sys/net/core/somaxconn的值,所以需要确认增大somaxconn和tcp_max_syn_backlog两个值来达到想要的效果。
- timeout
- bind
- tcp-keepalive
- 单位为秒,如果设置为0,则不会进行keepalive检测,建议设置成60
- loglevel
- logfile
- syslog-enabled
- 是否把日志输出到syslog中
- syslog-ident
- 指定syslog里的日志标志
- syslog-facility
- 指定syslog设备,值可以是USER或LOCAL0-LOCAL7
- databases
SNAPSHOTTING 快照
- save
- save second change
- rdb是整个内存的压缩过的snapshot,rdb的数据结构,可以配置符合的快照触发条件
- 默认:
- save 60 10000
- save 300 10
- save 900 1
- disable
- save "" 或 save
- save second change
- stop-writes-in-bgsave-error
- 如果配置成no,表示你不在乎数据不一致货真有其他的手段发现和控制
- 默认为yes
- rdbcompression
- 对于存储到磁盘 中的快照,可以设置是否进行压缩 存储。如果是的话,redis会采用LZF算法进行压缩。如果你不想消耗CPU来 进行压缩的话,可以设置为关闭此功能
- 默认为yes
- rdbchecksum
- 在存储快照后,还可以让redis使用CRC64算法来进行数据校验,但是这样做会增加大约10%的性能消耗,如果希望获取到最大的性能 提升,可以关闭此功能
- 默认为yes
- dbfilename
- dir
REPLICATION 复制
SECURITY 安全(重点)
访问密码的查看、设置和取消
LIMITS 限制(重点)
- maxclients
- maxmemory
- maxmemory-policy
- volatile-lru: 使用LRU算法移除key,只对设置了过期时间的key
- allkeys-lru: 使用LRU算法移除key
- volatile-random: 随机移除key,只对设置了过期时间的key
- allkeys-random: 随机移除key
- volatile-ttl: 移除那些ttl值最小的key
- noeviction: 不进行移除。针对写操作,只是返回错误信息
- maxmemory-samples
- 设置样本的数量,LRU算法和最小TTL算法都并非精确的算法,而是估算值,所以你可以设置样本的大小,redis默认会检查这么多个key并选择其中LRU的那个。
APPEND ONLY MODE 追加
- appendonly
- appendfilename
- appendfsync
- always: 同步持久化,每次发生数据变更会被立即记录到磁盘,性能较差但数据完整性比较好
- everysec: 出厂默认推荐,异步操作,每秒记录,如果一秒内宕机,有数据丢失
- no
- no-appendfsync-on-rewrite: 重写时是否可以运用appendfsync,用弄人no即可,保证数据安全性
- auto-aof-rewrite-min-size: 设置重写的基准值
- auto-aof-rewrite-percentage: 设置重写的基准值
常见配置redis.conf介绍(重点)
redis.conf配置项说明如下
-
redis默认不是以守护进程的方式运行,可以通过该配置项修改,使用yes启动守护进程
daemonize no
-
当redis以守护进程方式运行时,redis会默认把pid写入/var/run/redis.pid文件,可以通过pidfile指定
pidfile /var/run/redis.pid
-
指定redis监听端口,默认端口是6379
port 6379
-
绑定主机地址
bind 127.0.0.1
-
当客户端闲置多长时间后关闭连接,如果指定为0,表示关闭该功能
timeout 300
-
指定日志记录级别,redis总共支持四个级别: debug、verbose、notice、warning,默认为verbose
loglevel verbose
-
日志记录方式,默认为标准输出,如果配置redis为守护进程方式运行,而这里又配置日志记录方式为标准输出,则日志会发送给/dev/null
logfile stdout
-
设置数据库的数量,默认数据库为0号,可以使用select< >dbid命令在连接上指定数据库id
database 16
-
指定多长时间内,有多少次更新操作,就将数据同步到数据文件,可以多个条件配合
redis默认配置文件中提供了三个条件:
save 900 1
save 300 10
save 60 10000
分别表示900秒(15分钟)内有一个更改,300秒(5分钟)内有10个更改以及60秒内有10000个更改。
-
指定存储至本地数据库时是否压缩数据,默认为yes,redis采用lzf压缩,如果为了节省cpu时间,可以关闭该选项,但会导致数据库文件变得巨大。
rdbcompression yes
-
指定本地数据库文件名,默认值为dump.rdb
dbfilename dump.rdb
-
指定本地数据库存放目录
dir ./
-
设置当本机为slav服务时,设置master服务的up地址及端口,在redis启动时,它会自动从master进行数据同步
slaveof <masterip> <masterport>
-
当master服务设置了密码保护时,slav服务连接master的密码
masterauth <master-password>
-
设置redis连接密码,如果配置了连接密码,客户端在连接redis时需要通过auth <password>命令提供密码,默认关闭
requirepass foobared
-
设置同一时间最大客户端连接数,默认无限制,redis可以同时打开的客户端连接数为redis进程可以打开的最大文件描述符数,如果设置 maxclients 0,表示不做限制。当客户端连接数到达限制时,redis会关闭新的连接并向客户端返回 max number of clients reached错误信息
maxclients 128
-
指定redis最大内存限制,redis在启动时会把数据加载到内存中,达到最大内存后,redis会先尝试清楚已经到期或即将到期的key,当此方法处理后,任然到达最大内存限制,将无法再进行写入操作,但仍然可以进行读取操作。redis新的vm机制,会把key存放内存,value会存放在swap区。
maxmemory <bytes>
-
指定是否在每次更新操作后进行日志记录,redis在默认情况下是异步的把数据写入磁盘,如火不开启,可能会在断电时导致一段数据丢失。因为redis本身同步数据文件是按上面save条件来同步的,所以有点数据会在一段时间内只存在于内存之中。默认为no
appendonly no
-
指定更新日志文件名,默认为appendonly.aof
appendfilename appendonly.aof
-
指定更新日志条件,共有3个可选值:
- no 表示等操作系统进行数据缓存同步到磁盘(快)
- always 表示每次更新操作后手动调用fsync()将数据写到磁盘(慢,安全)
- everysrc 表示每秒同步一次(折中,默认值)
appendfsync everysec
-
指定是否启用虚拟内存机制,默认值为no。简单介绍一下,vm机制将数据分页存放,由redis将访问量较少的页即冷数据swap到磁盘上,访问多的页由磁盘自动换出到内存中
vm-enabled no
-
虚拟内存文件路径,默认值为/tmp/redis.swap,不可以多个redis实例共享
vm-swap-file /tmp/redis.swap
-
将所有大于vm-max-memory的数据存入虚拟内存,无论vm-max-memory设置多小,所有索引数据都是内存存储的(redis的索引数据,就是keys),也就是说,当vm-max-memory设置为0的时候,所有的value都存在于磁盘中。默认值为0.
vm-max-memory 0
-
redis swap文件分成了很多的page,一个对象可以保存在多个page上面,但一个page上不能被多个对象共享,vm-page-size是要根据存储的数据大小来设定的,作者建议如果存储很多小对象,page大小最好设置为32或64bytes;如果存储很大对象,则可以使用更大的page,如果不确定,就使用默认值
vm-page-size 32
-
设置swap文件中的page数量,由于页表(一种表示也没满空闲或使用的bitmap)是存放在内存中的,在磁盘上,每8个pages将消耗1byte的内存
vm-pages 134217728
-
设置访问swap文件的线程数,最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的,可能会造成较长时间的延时,默认值为4
vm-max-threads 4
-
设置在向客户端应答时,是否把较小的包合并为一个包发送,默认开启
glueoutputbuf yes
-
指定在超过一定的数量或最大的元素超过某一临界值时,采用一种特殊的哈希算法
hash-max-zipmap-entries 64
hash-max-zipmap-value 512
-
制动是否激活重置hash,摸摸人为开启
activerehashing yes
-
指定报告包含其他配置文件,可以在同一主机上多喝redis实例之间使用同一份配置文件,而各个实例又拥有自己的特定配置文件
include /path/to/local.conf
Redis持久化
rdb redis database
aof append only file
RDB
-
是什么
- 在指定的时间间隔内将内存中的数据集快照写入磁盘
- snapshot快照,它恢复时是将快照文件直接读到内存中
- reids会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件,整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能。
- 如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那rdb方式就比aof方式更加高效。
- RDB的缺点是最后一次持久化的数据可能丢失。
-
fork
- fork的作用是复制一个班与当前进程一样的进程。新进程的所有数据(变量、环境变量、程序计数器) 的数值都和原进程一样,但是是一个全新的进程,并作为原进程的子进程。
-
rdb保存的是dump.rdb文件
-
配置位置
- 见解析配置文件redis.conf下的SNAPSHOTTING 快照小节
-
如何触发rdb快照
- 配置文件中默认的快照配置
- 冷拷贝后重新使用
- 可以 cp dump.rdb dump_new.rdb
- 冷拷贝后重新使用
- 命令save或者bgsave
- save: 只管保存,其他不管,全部阻塞
- bgsave: redis会在后台异步进行快照操作,快照同时还可以响应客户端请求。可以通过lastsave命令 获取左后一次成功执行快照的时间
- 执行flushall命令,也会产生dump.rdb文件,但里面是空的,无意义。
- 配置文件中默认的快照配置
-
如何恢复
- 将备份文件(dump.rdb)移动到redis安装目录并启动服务即可
- config get dir获取目录
-
优势
- 适合大规模的数据恢复
- 对数据完整性和一致性要求不高
-
劣势
- 在一定 间隔时间做一次备份,所以如果redis意外down掉,则会丢失最后一次快照后的所有修改
- fork的时候,内存中的数据被克隆了一份大致2倍的膨胀性需要考虑
-
如何停止
- 动态所有停止rdb保存规则的方法: redis-cli config set save ""
-
小总结
AOF
-
是什么
- 以日志的形式来记录每个写操作,将redis执行过的所有写指令记录下来(读指令不记录),只许追加文件但不可以改写文件,redis启动之初会读取该文件重新构建数据,换言之 ,redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
-
aof保存的是appendonly.aof文件
-
配置位置
- 解析配置文件redis.conf下的APPEND ONLY MODE 追加小节
-
aof启动/修复/恢复
- 正常恢复:
- 启动 : 设置yes(修改默认的appendonly no,改为yes)
- 将有数据 的aof文件复制一份保存到对应目录(config get dir)
- 恢复: 重启 redis然后重新加载
- 异常恢复
- 启动: 设置yes
- 备份被写坏的aof文件
- 修复
- redis-check-aof --fix filename
- 恢复: 重启redis然后重新加载
- 正常恢复:
-
rewrite
- aof采用文件追加方式,文件会越来越大,为避免出现此种情况,新增了重写机制。当aof文件的大小超过所设定的阈值时,redis就会启动aof文件的内容压缩 ,只保留可以恢复数据的最小指令集,可使用命令bgrewriteaof
- 重写原理:
- aof文件会持续增长而过大时,会fork出一条新进程来将文件重写(也是先写临时文件然后rename),遍历新进程的内存中数据,每条记录有一条set语句 。重写aof文件的操作,并没有读取旧的aof文件,而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,这点和快照有点类似。
- 触发机制: redis会记录 上次重写时的aof大小,默认配置是 当aof文件大小是上次rewrite文件的小的一倍且文件大于64M时触发。
-
劣势 :
- 相同数据集的数据而言aof文件要远大于 rdb文件,恢复速度慢于rdb
- aof运行效率要慢于rdb,每秒 同步策略效率较好,不同步效率和rdb相同。
-
小总结:

事务
是什么
可以一次执行 多个命令,本质是一组命令的集合。一个事务中的所有命令都会序列化,按顺序串行话执行而不会被其他命令插入,不许加塞。
能干嘛
一个队列中,一次性、顺序性、排他性的执行一系列命令 。
怎么玩
- 常用命令
- DISCARD: 取消事务,放弃执行事务块内 的所有命令
- EXEC: 执行所有事务块内的命令
- MULTI: 标记一个事务块的开始
- UNWATCH: 取消WATCH命令对所有key的监视
- WATCH key [key ...]: 监视一个或多个key,如果在事务执行之前这些key被其他命令所改动,那么事务将被打断
- case1 正常执行 exec
- case2 放弃事务 discard
- case3 全体连坐: 只要事务中有一条命令语法出错,则取消事务,放弃事务内所有命令
- case4 冤头债主: 事务中语法没错,但 执行时出了异常,则谁出异常谁报异常,正常的命令正常执行
- case5 watch监控
- 悲观锁/乐观锁/CAS(check and set)
- 悲观锁(Pessimistic Lock)
- 顾名思义,就是很悲观,每次去拿数据的时候都认为别人会去修改,所以每次再那数据的时候都会上锁,这样别人想拿这个数据就会block知道它拿到锁。传统的关系型数据库里边就用到了很多锁机制,比如行锁、表锁等,读锁、写锁等,都是在做操作之前先上锁。
- 乐观锁(Optimistic Lock)
- 顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会 修改,所以不会上锁,但是在更新的时候回判断一下在此期间比人有没有去更新这个数据,可以使用版本号等机制。乐观锁适用于多读的应用类型,这样可以提高吞吐量。
- 乐观锁策略: 提交版本必须大于记录当前版本才能执行更新。
- CAS
- 悲观锁(Pessimistic Lock)
- 初始化信用卡可用余额和欠额
- 无加塞篡改,先监控再开启multi,八正两笔金额变动再同一个事务内
- 有加塞篡改
- unwatch
- 一旦执行了exec之前加的监控锁都会被取消掉
- 小结
- watch指令,类似乐观锁,事务提交时,如果key的值已被别的客户端改变,比如某个list已被别的客户端push/pop过了,整个事务队列都不会执行
- 通过watch命令在事务执行之前监控了多个keys,倘若在watch之后又任何key的值发生变化,exec命令执行的事务将被放弃,同时返回nullmulti-bulk应答以通知调用者事务执行失败。
- 悲观锁/乐观锁/CAS(check and set)
- 3阶段
- 开启: multi
- 入队: 将多个命令入队到书屋中
- 执行: exec
- 3特性
- 单独的隔离操作: 事务中的所有命令都会序列化、按顺序的执行。事务在执行的过程中,不会被其他用户发送来的命令请求打断。
- 没有隔离级别的概念: 队列中的命令没有提交之前都不会实际的被运行,因为事务提交前任何命令都不会被执行,也就不存在"事务内的查询要看到书屋里的更新,在事务外查询不能看到"这个让人头疼的问题
- 不保证原子性: redis同一个事务中如果有一条命令执行失败,其后的命令任然会被执行,没有回滚。
redis的发布和订阅
是什么
进程间的一种消息通信模式: 发送者(pub)发送消息,订阅者(sub)接受消息
命令
- PSUBSCRIBE pattern [pattern ...]: 订阅一个或多个符合给定模式的频道
- PUBSUB subcommand [argument [argument ...]]: 查看订阅与发布系统状态
- PUBLISH channel message: 发送信息给指定的频道
- SUBSCRIBE channel [channel ...]: 订阅一个或对个频道的信息
- UNSUBSCRIBE [channel [channel ...]]: 退订频道
主从复制
是什么
行话: 也就是我们所说的主从复制,主机数据更新后根据配置和策略,自动同步到备机的master/slaver机制,Master以写为主,Slave以读为主
能干嘛
读写分类
容灾恢复
怎么玩
- 配从(库)不配主(库)
- 从库配置: slaveof 主库IP 主库端口
- 每次与master断开之后,都需要重新连接,除非你配置进redis.conf
- 修改配置文件细节操作
- 拷贝多个redis.conf文件
- 开启daemonize yes
- pid 文件名字
- 指定端口
- Log文件名字
- dump.rdb
- 常用三招:
- 一主二仆
- 薪火相传
- 上一个Slave可以是下一个slave的Master,Slave同样可以接收到其他slaves的连接和同步请求,那么该slave作为链条中的下一个master,可以有效减轻master的写 压力
- 中途变更专项: 会清楚之前的数据,重新建立拷贝最新的
- salveof 新主库IP 新主库端口
- 反客为主
- slaveof no one : 使当前数据库停止与其他数据库的同步,转为主数据库
复制原理
- slave启动成功连接到master后会发送一个sync命令
- master接到命令启动后台的存盘进程,同时手机所有接收到的用于修改数据集命令,在后台进程执行完毕之后,master将传送整个数据文件到slave,以完成一次同步
- 全量复制: 而salve服务在接收到数据库文件后,将其存盘并加载到内存
- 增量复制: master继续将新的所有收集到的修改命令依次传给slave,完成同步
- 但是只要是重新连接master,依次完全同步(全量复制)将被自动执行
哨兵模式
- 是什么
- 反客为主的自动版,能够后台监控主机是否故障,如果故障根据投票数自动将从库转换成主库
- 怎么玩
- 新建sentinel.conf文件,名字决不能错
- 配置哨兵,填写内容
- sentinel monitor 被监控数据库名字(自己起) 数据库IP 数据库端口 1
- 上面最后一个数字1,表示主机挂掉后salve投票看让谁称为主机,得票数多余1则 谁成为主机,如果票数一样则重新投票直到选出来为止
- 启动哨兵
- redis-sentinel sentinel.conf的路径
- 如果原主数据库挂了,经投票后选出新的主数据库,之后主数据库又重新连接了,这时主数据库会被哨兵监视到并被安排 称为新主数据库的从数据库
- 一组sentinel能同时监控多个Master
复制的缺点
- 复制延时
- 由于所有的写的操作都是现在Master上操作 ,然后同步更新到Slave上,所以从master同步到slave机器有一定的延迟,当系统繁忙的时候,延迟问题会更加严重,slave机器数量的增加也会使这个问题更加严重。
Jedis
包:
- commons-pool-1.6.jar
- Jedis-2.1.0.jar
测试连通性
Jedis jedis = new Jedis("127.0.0.1",6379);
System.out.println(jedis.ping());
//result
PONG
密码
123456