在本文中，我们主要针对Redis中的“键”和“值”进行了学习。我们可以注意到，Redis是一个C/S架构的数据库，在我们目前的认知中，它是通过终端中的一条条命令来存储和读取的，即它是一个非常典型的“请求-响应”模型。可是我们知道在实际的应用中，我们要面对的或许是更为复杂的业务逻辑，因为Redis中不存在传统关系型数据库中表的概念，因此在使用Redis的过程中，我们要面对两个实际的问题，即如何更好的维护数据库中的”键“、如何在高效执行命令的同时保证命令执行成功。对于前者，我认为这是一个设计上的问题，而对于后者，我认为这是一个技术上的问题。所以，这篇文章的核心内容就是找到这两个问题的答案。带着这样的问题出发，我们就可以正式进入这篇文章的主题：Redis中的事务处理。 从数据库事务说起 通常我们提及数据库都不可避免的要提到事务，那么什么是事务呢?事务是指作为单个逻辑工作单元执行的一系列操作。所以，首先事务是一系列操作，这一系列操作具有二态性，即完全地执行或者完全地不执行。因此事务处理可以确保除非事务单元内的所有操作的成功完成，否则不会永久更新面向数据的资源。我们这里举一个例子，数据库中除查询操作以外，插入(Insert)、删除(Delete)和更新(Update)这三种操作都会对数据造成影响，因为事务处理能够保证一系列操作可以完全地执行或者完全不执行，因此在一个事务被提交以后，该事务中的任何一条SQL语句在被执行的时候，都会生成一条撤销日志(Undo Log)，而撤销日志中记录的是和当前擦作完全相反的操作，比如删除的相反操作是插入，插入的相反操作是删除等。我们通常所说的事务回滚其实就是去执行这些插销日志里的相反操作，这同样告诉我们一个道理，只有事务中的一系列操作完全执行的情况下可以回滚，如果是在意外情况下导致事务中的一系列操作没有完全执行，这个时候我们是不能保证数据一定可以回滚的。 在数据库相关理论中，一个逻辑工作单元想要成为事务，就必须满足ACID，即原子性、一致性、隔离性和持久性。(1)：原子性这个概念其实就是指，一个事务内的所有SQL操作都是一个整体，因此只有所有的SQL操作都完全执行成功，该事务方可以认为提交成功。如果在提交事务过程中某一条SQL语句执行失败，则整个事务必须回滚到事务提交前的状态。(2)：而一致性这个概念则是指，事务在完成的时候，必须要保证所有的数据都保持一致的状态，而落实到数据库的各个组成部分上，则要求开发人员能够保证数据、索引、约束、日志等在事务前后具备一致性。(3)：隔离性这个概念主要针对并发，其核心思想就是不同的并发事务对数据产生的修改必须是相互隔离的，假设有两个不同的事务A和B并发执行，那么对A来讲，它在执行前的状态只有两种，即B执行前和B执行后。同理，对B来讲同样是如此，这样的特性我们就称为隔离性。(4)：持久性相对简单，是指事务完成以后它对数据的影响是永久性的。 Redis中的事务处理 好了，截止到目前为止，我们对数据库中事务处理的相关理论有了一个基本的认识，或许这个世界上的数据库系统千差万别，但我相信在事务处理这个问题上它们最终会殊途同归，就像我们解决并发过程中的冲突问题，常规的做法依然是加锁一样，这是我之所以要花费精力去理解和解释这些理论知识的原因，技术可谓是日新月异，如果我们总是一味地为新技术而疲于奔命，那么或许我们会渐渐地失去对这个行业的热爱，我相信原理永远比框架更为重要，没有系统学习过计算机专业的课程，这件事情让我至今都颇为遗憾。Redis中的事务是可以视为一个队列，即我们可以通过MULTI开始一个事务，这相当于我们声明了一个命令队列。接下来，我们向Redis中提交的每条命令，都会被排入这个命令队列。当我们输入EXEC命令时，将触发当前事务，这相当于我们从命令队列中取出命令并执行，所以Redis中一个事务从开始到执行会经历 开始事务 、 命令入队 和 执行事务 三个阶段。下面是一个在Redis中使用事务的简单示例：
|
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
