mysql-redis事务的比较

mysql-redis事务的比较


最近刚好回去看redis的源代码,不得不说这个源代码写的真心不错,很有味道.刚好之前系统学了MySQL,于是就到了和redis进行对比作为本周博客主题.

mysql acid

提到mysql的事务(transaction),必然要提到无论那那一本数据库叫教科书里面必然提到关系型数据库的acid.这也是记牢数据库事务的核心

  • 原子性(Atomicity)

原子性是指事务包含的所有操作要么全部成功,要么全部失败回滚.实现事务的原子性,要支持回滚操作,在某个操作失败后,回滚到事务执行之前的状态。

  • 一致性(Consistency)

一致性是指事务必须使数据库从一个一致的状态变到另外一个一致的状态,也就是执行事务之前和之后的状态都必须处于一致的状态。MySQL数据库innodb的事务,是通过redo log(innodb log),undo log,锁机制,来维护这个一致性的

在事务T开始时,此时数据库有一种状态,这个状态是所有的MySQL对象处于一致的状态,例如数据库完整性约束正确,日志状态一致等,当事务T提交后,这时数据库又有了一个新的状态,不同的数据,不同的索引,不同的日志等,但此时,约束,数据,索引,日志等MySQL各种对象还是要保持一致性(正确性)。 这就是 从一个一致性的状态,变到另一个一致性的状态。也就是事务执行后,并没有破坏数据库的完整性约束(一切都是对的)。

  • 隔离性(Isolation)

隔离性是指当多个用户并发访问数据库时,比如操作同一张表时,数据库为每一个用户开启的事务,不能被其他事务的操作所干扰,多个并发事务之间要相互隔离

即要达到这么一种效果:对于任意两个并发的事务T1和T2,在事务T1看来,T2要么在T1开始之前就已经结束,要么在T1结束之后才开始,这样每个事务都感觉不到有其他事务在并发地执行。

  • 持久性(Durability)

持久性是指一个事务一旦被提交了,那么对于数据库中的数据改变就是永久性的,即便是在数据库系统遭遇到故障的情况下也不会丢失提交事务的操作。

在提交事务方法后,提示用户事务操作完成,当我们程序执行完成直到看到提示后,就可以认定事务以及正确提交,即使这时候数据库出现了问题,也必须要将我们的事务完全执行完成,否则就会造成我们看到提示事务处理完毕,但是数据库因为故障而没有执行事务的重大错误。

mysql事务的扩展讨论

除却mysql事务中最基本的acid之外,还需要了解事务的隔离等级,数据库系统要能进行隔离操作,实质是包括复制环境下的通过日志如何达成事务.

除此之外还需要了解mysql的锁机制与日志机制.本人博客一贯秉持尽量推荐优秀的博客和官方文档,而不是作者自己似懂非懂瞎几把写和复制.关于mysql事务的进一步讨论,我推荐读者自己去阅读官方文档,与下面这两篇博客
- MySQL中事务的实现
- 理解事务 - MySQL 事务处理机制

redis的事务

我们看看redis的事务.
事务是一个单独的隔离操作:事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中,不会被其他客户端发送来的命令请求所打断。

对于发生在 EXEC 执行之前的错误,客户端以前的做法是检查命令入队所得的返回值:如果命令入队时返回 QUEUED ,那么入队成功;否则,就是入队失败。如果有命令在入队时失败,那么大部分客户端都会停止并取消这个事务。

不过,从 Redis 2.6.5 开始,服务器会对命令入队失败的情况进行记录,并在客户端调用 EXEC 命令时,拒绝执行并自动放弃这个事务。

Redis 不支持回滚(roll back)

redis并不像关系型数据库那么复杂(这也是因为redis非常快的原因,他的每一个操作都是原子化的网络模型也是io复用不支持多线程,简单而快速是redis的特性).它的事务和mysql最大的区别就在于不支持回滚.同时由于redis是操作原子化的,每一步操作结束后才会进行下一步操作,所以也就不需要考虑隔离级别,不需要考虑脏读.

  • Redis 命令只会因为错误的语法而失败(并且这些问题不能在入队时发现),或是命令用在了错误类型的键上面:这也就是说,从实用性的角度来说,失败的命令是由编程错误造成的,而这些错误应该在开发的过程中被发现,而不应该出现在生产环境中。
  • 因为不需要对回滚进行支持,所以 Redis 的内部可以保持简单且快速。

关于redis的事务更详细的介绍我推荐大家阅读文档

猜你喜欢

转载自blog.csdn.net/u011822516/article/details/82562888
今日推荐