Redis内存数据库

为什么要把数据存入内存？
快

常见的内存数据库：

• MemCached（常用于session一致性，MemCached + keepalive实现）：看成Redis前身，严格来说，MemCached不能叫数据库，只能叫缓存
  不支持持久化。如果内存停电，数据丢失。
• Redis：内存数据库，支持持久化，支持HA
• Oracle TimesTen

Redis适合用来做什么？

• 共享Cache ，不怕丢数据，丢了可以从DB中reload；
• 共享Session ，不怕丢数据，丢了可以重新登录；
• batch job的中间结果。不怕丢数据，丢了重新跑job就可以了；
• 一些简单数据的存储，低频改动，但是会被频繁读取。比如首页推荐的产品列表。但此时必须增加HA的防护，sentinel、cluster或者自定义的机制都可以；
• 一些更加复杂存储的building block，比如分布式锁，此时需要多节点来实现一个简单的quorum

特别注意，不要用Redis存储任何需要“认真对待”的数据，请用支持ACID事务的数据库。

Redis特性

1.速度快

数据存放在内存中；单线程模式，避免了线程上下文切换及多线程竞争访问；c语言实现，更容易接近系统api；采用epoll非阻塞IO，不在网络上浪费时间；

2.支持多种数据类型

支持8种数据类型：String、Hash、List、Set、 SortSet、Bitmaps、HyperLogLog、GEO；

3.功能丰富

丰富的API，如可设置键过期，存在即设置（这可以用来解决分布式锁问题），基于发布订阅可实现简单的消息队列，通过Lua创建新命令，具有原子性，管道（pipeline）功能，解决网络开销；

4.服务器简单

开源代码优雅，容易阅读源码，采用单线程模型，避免并发问题，redis自己实现了多路复用；

5.客户端语言版本多

如Java、Php、Go

6.支持多种持久化方式

RDB和AOP，这两种持久化深入分析请看：https://blog.csdn.net/u014229282/article/details/81121214

7.支持集群部署

支持主从复制，高可用集群，内部集群方式与Memcache做集群实现不一样的机制。

Redis和Memcached区别

1.支持持久化：RDB快照、AOF日志
2.支持丰富的数据类型
详细比较：https://www.cnblogs.com/JavaBlackHole/p/7726195.html

安装Redis

tar -zxvf redis-3.0.5.tar.gz 
cd redis-3.0.5/
make
make PREFIX=/usr/local/redis install

若make不了，检查下gcc

bin中的命令介绍

• redis-benchmark Redis提供的压力测试工具。模拟产生客户端的压力
• redis-check-aof 检查aof日志文件
• redis-check-dump 检查rdb文件
• redis-cli Redis客户端脚本
• redis-sentinel 哨兵
• redis-server Redis服务器脚本

核心配置文件:redis.conf
将源码包中的conf复制过来，并修改

42 daemonize yes
50 port 6379

启动redis ./bin/redis-server conf/redis.conf

操作Redis

命令行

redis-cli	
			./bin/redis-cli
			
			127.0.0.1:6379> set key1 value1
			OK
			127.0.0.1:6379> get key1
			"value1"
			127.0.0.1:6379> keys *
			1) "key1"
			
			对数据的操作：
			127.0.0.1:6379> set money 100
			OK
			127.0.0.1:6379> incr money
			(integer) 101
			127.0.0.1:6379> get money
			"101"
			127.0.0.1:6379> incrby money 1000
			(integer) 1101

JAVA


连接池需要包jedis-2.7.0.jar和commons-pool2-2.3.jar

Redis的事务

不是真正的事务，是一种模拟

（1）复习：事务（关系型数据库）
			（*）什么是事务？
				事务有一组DML语句组成。DML 插入更新删除操作
		
			（*）事务的特点
				要么都成功，要么都失败
				
			（*）Oracle中事务的本质：将事务的DML操作写入日志。日志写入成功，则事务执行成功。
			
		（2）Redis事务的本质：将一组操作放入队列中，一次执行（批处理）。
		
		（3）对比Oracle和Redis事务的区别

（4）举例：模拟银行转账
set tom 1000
		set mike 1000
		tom --> mike 转账操作必须在事务中，要么都成功，要么都不成功
		multi
		decrby tom 100
		incrby mike 100
		exec
		
		127.0.0.1:6379> set tom 1000
		OK
		127.0.0.1:6379> set mike 1000
		OK
		127.0.0.1:6379> multi
		OK
		127.0.0.1:6379> decrby tom 100
		QUEUED
		127.0.0.1:6379> incrby mike 100
		QUEUED
		127.0.0.1:6379> exec
		1) (integer) 900
		2) (integer) 1100

	（5）举例：买票
		set tom 1000
		set ticket 1
		multi
		decrby tom 500
		decr ticket
		exec
		
		在exec前，从另一个窗口，decr ticket
		
		127.0.0.1:6379> set tom 1000
		OK
		127.0.0.1:6379> set ticket 1
		OK
		127.0.0.1:6379> multi
		OK
		127.0.0.1:6379> decrby tom 500
		QUEUED
		127.0.0.1:6379> decr ticket
		QUEUED
		127.0.0.1:6379> exec
		1) (integer) 500
		2) (integer) -1

Redis锁机制

执行事务操作的时候，如果监视的值发生了变化，则提交失败。

命令：watch

举例：买票
		set tom 1000
		set ticket 1
		watch ticket -----> 相当于给ticket加了锁。认为在下面执行事务的时候，值不会变。
		multi
		decrby tom 500
		decr ticket
		exec
		
		127.0.0.1:6379> set tom 1000
		OK
		127.0.0.1:6379> set ticket 1
		OK
		127.0.0.1:6379> watch ticket
		OK
		127.0.0.1:6379> multi
		OK
		127.0.0.1:6379> decrby tom 500
		QUEUED
		127.0.0.1:6379> decr ticket
		QUEUED
		127.0.0.1:6379> exec
		(nil)
		127.0.0.1:6379> get tom
		"1000"
		
		nil 代表操作没有执行或者执行失败。

Redis的消息机制：消息系统

（1）消息的类型
			（*）Queue消息：队列，点对点。
			（*）Topic消息：主题，群发：发布消息，订阅消息
			
		（2）Redis消息机制：
			只支持Topic消息。
			
			命令：发布消息 publish
			订阅：subscribe 
				psubscribe 订阅消息  可以用通配符来订阅消息
		
		（3）常用的消息系统：
			Redis 只支持 Topic
			Kacka 只支持Topic 需要Zookeeper支持。
			JMS Java Messging Service java消息服务标准。支持Queue Topic
				产品：Weblogic

Redis持久化

本质：备份和恢复

（1）RDB快照：默认
			
			（*）看成一种快照，备份。每隔段时间，将内存汇总的数据保存到硬盘上。产生RDB文件。
			
			（*）RDB 生成策略：
			
				147 save 900 1       900秒内，有1个key发生变化
				148 save 300 10      300内，如果有10个key发生变化，执行RDB
				149 save 60 10000    60秒内，如果有10000个key发生变化，执行RDB
				
				save 时间 发生变化的key的个数
				
			（*）其他参数
				164 stop-writes-on-bgsave-error yes  当后台写进程出错时，禁止写入新的数据
				
				170 rdbcompression yes      是否压缩。如果看重性能，设置成no
					压缩会节省空间，但会影响备份和恢复性能
					
				182 dbfilename dump.rdb
				192 dir ./
			
			（*）RDB的优点和缺点
				优点：快 恢复速度快
				缺点：在两次RDB之间，可能会造成数据的丢失。
					解决：AOF
				
		
		（2）AOF日志
			客户端在操作Redis时，把操作记录到文件中，如果发生崩溃，读取日志，把操作完全执行一遍。
			
			（*）默认是禁用。
				509 appendonly no  参数修改成yes
				
			（*）AOF记录策略
				538 # appendfsync always       	每个操作都记录日志：优点安全 缺点：慢
				539 appendfsync everysec
				540 # appendfsync no			由操作系统来决定记录日志的方式。不会用的到。
		
			（*）AOF日志重写：overwrite
				举例：
				set money 0
				incr money
				..100次
				
				set money 100
				
				 ./redis-benchmark -n 100000   
				 模拟客户端100000次请求
			
			（*）参数设置
				561 no-appendfsync-on-rewrite no   执行重写的时候，不写入新的日志
				581 auto-aof-rewrite-min-size 64mb  执行重写的文件大小。到64M触发重写。
			
		
		（3）当两个同时存在时，优先执行哪个？
			504 # If the AOF is enabled on startup Redis will load the AOF, that is the file
			505 # with the better durability guarantees.
			
			AOF开启时，优先使用AOF

Redis的主从复制

			作用：
				主从复制，主从备份，防止主节点down机
				任务分离：分摊主节点压力。读写分离。
				

Redis集群两种部署方式
				星型模型：
				优点：效率高，两个slave地位一样，可以直接从主节点取出信息
				缺点：HA比较麻烦
				
				线性模型：
				优点：HA简单
				缺点：效率不如星型模型
				
		cp redis.conf redis6379.conf 
		cp redis.conf redis6380.conf 
		cp redis.conf redis6381.conf 
		
		主节点：关闭rdb aof
		509 appendonly no
		147 #save 900 1
		148 #save 300 10
		149 #save 60 10000
		
		从节点
		改端口号 
		50 port 6380
		改aof rdb文件名：
		182 dbfilename dump6380.rdb
		513 appendfilename "appendonly6380.aof"
		211 slaveof 192.168.109.133 6379
		
		root@node3 redis]# ./bin/redis-server ./conf/redis6379.conf 
		[root@node3 redis]# ./bin/redis-server ./conf/redis6380.conf 
		[root@node3 redis]# ./bin/redis-server ./conf/redis6381.conf 
		
		[root@node3 redis]# ps -ef | grep redis
		root      4830     1  1 22:56 ?        00:00:00 ./bin/redis-server *:6379               
		root      4834     1  2 22:56 ?        00:00:00 ./bin/redis-server *:6380               
		root      4840     1  2 22:56 ?        00:00:00 ./bin/redis-server *:6381               
		root      4846  1378  0 22:56 pts/1    00:00:00 grep redis
		[root@node3 redis]# ./bin/redis-cli -p 6379
		127.0.0.1:6379> set tom 10000
		OK
		127.0.0.1:6379> quit
		[root@node3 redis]# ./bin/redis-cli -p 6380
		127.0.0.1:6380> get tom
		"10000"
		
		默认情况下，从节点只读。
		
		注意：一次性启动从节点不要太多。

Redis的分片

多个从节点分摊读的压力

客户端代理分片工具：Twemproxy

解压
			./config --prefix=.....
			cp /usr/local/nutcracker-0.3.0/conf/nutcracker.yml ./conf/
			
		

修改server信息

检查配置文件是否正确
			./sbin/nutcracker -t conf/nutcracker.yml
			
			启动代理分片
			./sbin/nutcracker -d -c conf/nutcracker.yml
			
			./bin/redis-cli -p 22121 访问

Redis的HA（哨兵机制）

	主从结构，存在单点故障问题。
	
	redis2.4版本之后有
	
	 redis-sentinel 就是哨兵
	 
	配置：
		
		cp /usr/local/redis-3.0.5/sentitinel.conf ./conf/
		
		vim sentitinel.conf 
		
		53 sentinel monitor mymaster 192.168.109.134 6379 1
		
		bin/redis-sentinel conf/sentinel.conf
		看日志：
		
		10429:X 17 Apr 18:03:35.817 # +monitor master mymaster 192.168.109.134 6379 quorum 1
		10429:X 17 Apr 18:03:36.820 * +slave slave 192.168.109.134:6380 192.168.109.134 6380 @ mymaster 192.168.109.134 6379
		10429:X 17 Apr 18:03:36.836 * +slave slave 192.168.109.134:6381 192.168.109.134 6381 @ mymaster 192.168.109.134 6379

		kill master 检测到
		
		看日志：
		try-failover master mymaster 192.168.109.134 6379
		检测到6379挂了
		
		selected-slave slave 192.168.109.134:6380 192.168.109.134 6380 @ mymaster 192.168.109.134 6379
		select slave 选举新的主节点
		
		slave slave 192.168.109.134:6381 192.168.109.134 6381 @ mymaster 192.168.109.134 6380
		把其他的从节点连接到主节点上