redis（2）redis的基础入门（linux）

标签：after   serve   数据保存   获取   ISE   man   diff   优化   乐观锁   

1.memcached与redis对比

　　memcahced只有一种string数据结构，而redis有5种数据数据存储，memcahced具有的方法redis基本全部都有，且redis代码更简洁，更加易读，更加具有维护性，性能方面基本差不多，redis支持持久化，memcache自身不支持持久化。

2.redis数据类型与api

string，list，set，hash，zset

redis  api

http://redisdoc.com/

备注：incr ，decr，incrby，decrby 是原子性操作

3.通用命令：

Tab：补全命令

redis-server redis.conf；//按指定配置文件启动服务器

redis-cli  -p  6379 ；//-h没写默认为localhost ，-p端口，启动客户端

redis-check-aof  aof文件名；// aof文件修复，这里需要使用diff命令比较一下与原文件的差异

redis-check-rdb  rdb文件名；//rdb文件修复，这里需要使用diff命令比较一下与原文件的差异

config set  配置文件参数 ；//修改配置参数

config get  配置文件参数 ；//获取配置参数

redis-benchmark  -h ip  -p port  -c number  -n number  //redis性能测试

redis-benchmark参数说明：http://www.runoob.com/redis/redis-benchmarks.html

4.登录客户端后的常用命令

clear：清屏 ； 

flushdb：清空当前库且将数据保存持久化；

flushall：清空所有库且将数据保存持久化 ；

shutdown：将数据持久化并关闭会话

exit：将数据持久化并退出；  

save ：将数据持久化，同步阻塞，保证数据安全；

bgsave：异步进行快照，可以通过lastsave获取最后一次保存的快照的时间，保证效率

select  库 //切换库

dbsize //查看当前库的key的大小

5.设置密码//一般没有必要，因为他不是做安全的

获取密码：config get requirepass //默认没有密码

设置密码：config set  requirepass  12345678

登录 ：auth  密码

redis的配置文件中的说明

6.分布式中的cap原理

C:Consistency（强一致性）

A:Availability（可用性）

P:Partition tolerance（分区容错性）

选用原则

由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。 AP 大多数网站架构的选择， CA 传统Oracle数据库

7.redis的持久化aof与rdb

1)rdb的持久化

redis中的配置中设置如下：

只要满足以下三个条件中的任意一个，BGSAVE命令就会被执行

服务器在900秒之内，对数据库进行了至少1次修改;
服务器在300秒之内，对数据库进行了至少10次修改;

服务器在60秒之内，对数据库进行了至少10000次修改.

2)aof持久化

appendonly no；//默认为关闭，开启设置为yes

appendfilename appendonly.aof；//默认的aof的文件文件名

appendfsync everysec ；//默认写入策略

参数如下

no：表示等操作系统进行数据缓存同步到磁盘（快） 

always：表示每次更新操作后手动调用fsync()将数据写到磁盘（慢，安全） 

everysec：表示每秒一次（折衷，默认值）

备注：no太慢，always太快系统易崩溃

3)rdb与aof的比较

rdb在恢复大数据集时的速度比 aof的恢复速度要快，rdb远比aof文件小，发生故障停机aof比rdb丢失的数据少

4)aof的重写原理：

当aof文件达到一定的值后（配置文件中默认为64M，auto-aof-rewrite-percentage 100，

auto-aof-rewrite-min-size 64mb），会fork出一条新进程来将文件重写(先写临时文件，然后删除原文件，最后再rename)，遍历新进程的内存中数据，重写aof文件,优化文件大小(前面多条set或者incr等，最后就只剩一下，一个键和一条值，一个set语句)，并没有读取旧的aof文件，将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。

备注：rdb与aof出现错误后的修复前面已写，一般而言两个都开启，倘若flush了，那么可以打开相应的aof文件，删除flush语句重新加载可以修复，但是在重写aof后不能恢复，aof文件优先于rbd文件加载。

8.Redis的事务

1)api

开启事物multi

取消事务：discard

提交事物exec  //提交之后无论失败还是成功都会取消监控

监控：watch

取消监控：unwatch  //取消所有的监控

2)回滚

开启事务后在exec之前报错，那么会全部回滚，假如在exec之后报错，那么没出错的语句继续执行，不会回滚

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set k1  v1
QUEUED
127.0.0.1:6379> getset k2
(error) ERR wrong number of arguments for ‘getset‘ command
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> get k1
(nil)

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> incr k1
QUEUED
127.0.0.1:6379> exec
1) OK
2) (error) ERR value is not an integer or out of range
127.0.0.1:6379> get k1
"v1"

3)watch与unwatch

watch指令，类似乐观锁，事务提交时，如果Key的值已被别的客户端改变，整个事务队列都不会被执行，通过watch命令在事务执行之前监控了多个Keys，倘若在watch之后multi之前有任何Key的值发生了变化，exec命令执行的事务都将被放弃，同时返回Nullmulti-bulk应答以通知调用者事务执行失败.

客户端1 //成功案例
127.0.0.1:6379> set k1 1000
OK
127.0.0.1:6379> set k2  0
OK
127.0.0.1:6379> WATCH k1
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> DECRby k1 500
QUEUED
127.0.0.1:6379> INCRby k2 500
QUEUED
127.0.0.1:6379> exec
1) (integer) 500
2) (integer) 500

客户端1//在multi之前，watch之后修改了数据，所以multi中的内容无效
127.0.0.1:6379> set  k1 1000
OK
127.0.0.1:6379> set  k2 0
OK
127.0.0.1:6379> WATCH  k1
OK
127.0.0.1:6379> set  k1 500
OK
127.0.0.1:6379> MULTI 
OK
127.0.0.1:6379> DECRBY k1 500
QUEUED
127.0.0.1:6379> INCRBY  k2 500
QUEUED
127.0.0.1:6379> exec
(nil)
127.0.0.1:6379> get k1
"500"

客户端1//正常走
127.0.0.1:6379> set  k1 1000
OK
127.0.0.1:6379> set  k2 0
OK
127.0.0.1:6379> WATCH  k1
OK
127.0.0.1:6379> MULTI 
OK
127.0.0.1:6379> DECRBY k1 500
QUEUED
127.0.0.1:6379> INCRBY  k2 500
QUEUED
127.0.0.1:6379> exec
(nil)
127.0.0.1:6379> get k1
"2000"

客户端2//设置值，导致上述失败
set k1  2000

备注：

单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。没有隔离级别的概念：队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都不会被实际执行，不保证原子性：redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚。

悲观锁：认为别人对自己是不安全的，将整个相应的空间都锁起来，例如表锁，写锁等

乐观锁：认为别人对自己是安全的，类似行锁，在修改行后面加一个版本号，例如当版本是1，两个人都同时哪一个数据，差不多时间提交，当有人提交后，变为2，然后后提交的版本与当前版本冲突，就需要解决冲突后提交，类似版本管理。

9.redis的发布订阅

略，基本不会使用，因为基本上都使用activemq

10.主从复制//优点：读写分离，容灾恢复

1)文件配置（一主二仆）

需要修改的配置（端口和文件地址）

port 

pidfile

logfile

dbfilename

appendfilename (开启aof之后需要更改)

2）1为主2，3为从

主//info replication

从 //SLAVEOF 127.0.0.1 6379，另一个从类似

备注：只能主写，从不能写，主掉了，两仆还是两仆，主回来后依旧是主

3）薪火相传

另一个挂在一个从上，但是被挂载的从，还是从

备注：主掉了，仆还是仆，主回来后依旧是主

4）反客为主//SLAVEOF no one

备注：反客为主后跟主没关系了

4）哨兵模式

配置文件

新建sentinel.conf文件，名字绝不能错，文件内的内容

sentinel monitor mymaster 127.0.0.1 6379 1   // mymaster主机名能谁便取， ip  ，prot,投票数

sentinel down-after-milliseconds mymaster 5000  //配置多长时间检测一次，默认30秒，这里配置5秒
sentinel failover-timeout mymaster 900000
sentinel parallel-syncs mymaster 2

启动 redis-sentinel   sentinel.conf文件路径

备注：主掉线之后，从机进行投票，在从机中自动的选出主机，主回来后变从机

redis（2）redis的基础入门（linux）

标签：after   serve   数据保存   获取   ISE   man   diff   优化   乐观锁   

原文地址：https://www.cnblogs.com/gg128/p/9526046.html