banner

IT运维工程师学习笔记-Redis笔记(7):redis数据安全-故障处理及事务

系统故障处理

redis跟传统ACID保证的关系数据库不同,在为后端构建应用程序的时候,用户需要多做一些准备工作才能保证数据的一致性。

注:

  

  

ACID是指原子性、一致性、隔离性和耐久性,如果一个数据库想实现可靠的数据事务,那么它就必须保证CID性质。

1,验证快照文件和AOF文件

redis提供了2个数据恢复工具:redis-check-aof和redis-check-dump。它们可在故障发生后,检查aof文件和快照文件的状态,并在有需要的情况下对文件进行修复。

redis-check-aof --fix aof文件,--fix参数添加够将尝试修复oaf文件,发现出错命令的时候,会删除出错命令后的所有命令,只保留出错命令前的正确命令。

redis-check-dump是无法修复快照文件的。目前也并没有办法可以修复出错的快照文件。

2,更换故障主服务器

A:主服务器  B:从服务器 C:新增服务器

如果A发生故障,添加C到redis集群中,首先B执行SAVE命令(因为从服务器默认不会有写入,因此也不需要使用BGSAVE)。将生成快照文件发送给C,在C上启动redis,最后让B称为C的从服务器。

另外一种思路是将B服务器升级为主服务器,C服务器加入为从服务器。

   

redis事务

redis的事务和传统关系数据库的事务并不相同。

关系数据库中,用户首先向数据库服务器发送begin,然后执行各个相互一致的写操作和读操作,最后用户可以选择发送COMMIT来确认之前索索的修改,或者发送ROLIBACK来放弃那些修改。

redis数据库中,以MULTI为开始,之后跟着用户传入的多个命令,最后以EXEC为结束。由于这种简单的事务在EXEC命令被调用之前不会执行任何实际操作,所以用户将没办法根据读取到的数据来做决定。导致无法以一致性的形式读取数据所以有一些型的问题变得难以解决。因为在多个事务处理同一个对象时通常需要用到二阶提交,所以事务不能一致的形式读取数据,二阶提交将不能实现。

注:

  

  

延迟执行事务有助于提升性能

因为redis在执行事务的过程中,会延迟执行一如对的命令直到客户端发送EXEC命令为止,因此很多redis客户端会等到事务包含所有的命令都出现了之后,才一次性的将MULTI命令、要在十五中执行的一系列命令、以及EXEC命令全部发送给redis,然后等待直到接收到所有命令的回复为止。这种方式可以减少客户端与redis服务器之间的网络通信册书来提示redis在执行多个命令时的性能

   

注:

  

  

为什么redis没有实现典型的加锁功能?

在访问以写入为目的数据的时候(sq中的SELECT FOR UPDATE),关系数据库会对被访问的数据进行加锁,直到事务被提交(COMMIT)或者被回滚(ROLLBACK)为止,如果有其他客户端视图对被加锁的数据进行写入,那么该客户端将被阻塞,直到第一个事务执行完毕为止。加锁在实际使用中非常有效,基本上所有关系数据库都实现了这种加锁功能,它的缺点在于,持有锁的客户端运行越慢,等待解锁的客户端被阻塞的时间就越长。

因为加锁有可能会造成长时间等待,所以redis并不会再执行WATCH命令时对数据进行加锁、相反地,redis只会在数据已经被其他客户端抢先修改了的情况下,通知执行WATCH命令的客户端,这种做法被称为乐观锁,而关系数据库实际执行的加锁操作则被称为悲观锁。乐观锁在实际使用中同游非常有效,因为客户端永远不必花时间去等待第一个取得锁的客户端,他们只需要在主机的事务执行失败时候进行重试就可以了。

 

推荐阅读:

我被北京清退了

每个家乡都有一个传说:库隆峰传说之雷劈夜

redhat镜像红帽iso百度云系统下载

阅读: 784
在同意共创许可协议(CC BY-NC-SA-4.0)的前提下,您可以转载本文。
付生保个人博客
https://shengbao.org/715.html

相关阅读

留言评论

暂无留言