建设银行临夏分行网站,商务咨询网站源码,房产网二手房,3a汽车集团公司网络营销方案一)Redis持久化之RDBredisDataBase: 什么是持久化: 1)持久性:和持久化说的是同一回事#xff0c;衡量持久性的前提是重启进程或者是重启主机以后数据是否还存在 持久:把数据存储在硬盘上#xff0c;那么就是持久性 不持久:把数据存储在内存中 2)redis是一个内存级别的数据库redisDataBase: 什么是持久化: 1)持久性:和持久化说的是同一回事衡量持久性的前提是重启进程或者是重启主机以后数据是否还存在 持久:把数据存储在硬盘上那么就是持久性 不持久:把数据存储在内存中 2)redis是一个内存级别的数据库是把数据存储在内存中的内存中的数据是不持久的要想能够做到持久就必须让redis把数据存储在硬盘上面但是redis相比于MYSQL这样的数据库最明显的优势就是快效率高就是数据保存在内存中为了保证数据快数据肯定还是在内存中但是为了持久数据肯定还得想办法存储在硬盘上redis最终得出策略是内存中也存数据硬盘上也存数据实际上这两份数据理论上是完全相同的但是实际上可能有小小的概率是不相同的取决于如何进行持久化的操作 3)当要进行插入一个新的数据的时候就需要把这个数据同时写入到内存和磁盘当查询某一个数据的时候同时写入到内存和磁盘当读取某一条数据的时候直接从内存中读取硬盘的数据主要是在redis重启的时候内存数据没了用来恢复内存中的数据的硬盘的数据平时都不用相当于是一个备份代价就是消耗了更多的空间同一份数据存储了两遍毕竟磁盘比较便宜这样的开销不会带来更多的成本 4)虽然说具体在向redis中写入数据的时候同时写入到内存和硬盘但是实际上怎么写硬盘还有不同的策略可以保证整体的效率还是足够高 RDB:定期备份每半年把我电脑上面的硬盘资料整体的备份到这个备份盘中 AOF:实时备份只要我下载了一个学习资料就立即把这个学习资料往备份盘中进行拷贝 RDB:RDB定期的把redis内存中的所有数据都给写入到磁盘中生成一个快照就是redis给内存中存储的数据赶紧拍个照片生成一个文件存储在硬盘中后续redis一旦重启了内存中的数据就没了后续redis一旦重启了就可以根据刚才的快照就能把内存中的数据回复回来了这里的定期有两种方式: 1)手动触发:程序员通过redis客户端执行特定的命令来触发快照生成: save:执行save的时候redis就会全力以赴的生成快照文件这样的操作将内存中的所有数据写到磁盘里面此时就会阻塞redis其他客户端的操作因为redis本身是一个单线程的系统一次只能处理一个命令类似于keys *的后果如果此时使用redis作为缓存可能导致MYSQL和redis都挂了一般不建议save bgsave:back ground在后面save是在前台进行持久化bgsave不会影响redis服务器处理其他的请求和命令这样既可以保证redis能够进行持久化还能够处理其他客户端的请求此时没有采用多线程此处redis使用的是多进程的方式完成并发编程实现bgsave bgsave的执行流程: 1)当前可能需要bgsave的进程有很多系统会进行判断当前是否已经存在有着其他工作的子进程比如说现在已经有一个子进程正在执行bgsave那么就直接把当前执行的bgsave返回 2)如果没有其它的工作子进程就通过fork这样的系统调用创建出一个子进程来在这个fork的过程中父进程会阻塞redis的其他命令在fork过程中主进程是会阻塞的但是通常情况下该指令执行的速度比较快对性能影响不大 2.1)进程和线程JAVA进行并发编程主要是通过多线程的方式fork是linux系统提供的一个创建子进程的API也就是系统调用fork创建子进程简单粗暴就直接把当前的父进程复制一份作为子进程一旦复制完成了父子进程就是两个完全相同的进程就各自执行各自的了这个fork的过程中会复制PCB虚拟地址空间(内存中的数据)文件描述符表也就是说本来在redis-server中有若干变量保存了一些键值对的数据随着这样fork的进行子进程中的内存里面也会存在着和父进程一模一样的变量 2.2)因此复制出来的克隆体(子进程)的内存数据就是和本体父进程的是一样的接下来就去安排子进程去进行持久化操作相当于是把父进程这里面的内存数据给持久化了父进程打开了一个文件fork了以后子进程也是可以直接进行使用这个文件的这样也就导致了子进程持久化写入的那一个文件和父进程是一模一样的 如果当前redis服务器中存储的数据特别多内存消耗特别大比如说100GB此时再去执行上面的复制操作是否存着很大的性能开销呢 2.3)此时的性能开销其实挺小的fork在进行内存拷贝的时候不是简单无脑的直接把所有的数据都直接拷贝一遍而是通过写时拷贝这样的机制来完成的如果子进程的内存数据和父进程的内存数据是相同的此时就不会触发真正的拷贝操作其实爷俩使用同一份数据但是其实这俩的内存空间应该是相互独立的一旦某一方针对于这个内存数据进行了修改就会立即触发真正的物理内存上的数据拷贝 接下来父进程在这里面产生修改将10变成20 2.4)在进行bgsave的场景中绝大部分的内存数据是不需要进行改变的整体上来说RDB的执行速度还是很快的在这个短时间内父进程不会有大量的数据的变化因此子进程的写实拷贝不会触发很多次也就保证了整体的拷贝时间是可控的高效的所以当前基于fork的方式创建子进程并由子进程完成持久化的思路是完全行得通的一方面子进程完全继承于父进程的内存数据同时也继承于父进程的文件描述符表另一方面还有写时拷贝的支撑让这样的继承过程并不是很低效redis子进程完成持久化的过程是完全可行的 3)子进程创建RDB文件对原有的rdb文件进行替换find / -name dump.rdb RDB的触发时机: dir /var/lib/redis默认是redis的工作目录dofilename dump.rdb表示的是rdb文件的名字 rdb的触发时机: 1)手动触发:save bgsave注意redis配置文件修改以后必须重启redis服务器以后才会生效 2)自动触发:在配置文件中进行配置save 关闭自动生成快照 2)自动触发: 2.1)在redis配置文件中设置一下让redis每个多隔长时间每产生多少次修改就进行触发save seconds changes一个是秒数一个是次数是在具体的修改的秒数范围内修改的次数虽然上面的这些数值都是可以自行修改配置的但是基于修改上述数据的时候要有一个最基本的原则生成一次rdb快照这个成本是一个比较高的成本不能让这个操作执行的太频繁因为这个操作要把内存中的所有键值对都写入到一个文件里面所以本身dump数据的操作消耗是很大的要限制操作频率正是因为rdb快照不能生成的太频繁这就很有可能导致快照中的数据和当前实施的数据情况可能会存在偏差save 60 10000这个参数代表的意思就是60秒内数据修改了10000次就要生成rdb文件 2.2)问题:12:00:00生成了rdb文件此时硬盘上面的快照文件和内存中的数据是一致的但是从12:00:01开始服务器收到了redis的大量的key的请求但是redis在12:00:02开始才会生成快照文件在这段区间也就是12:00:00到12:00:01这段区间如果redis服务器宕机了就会导致12:00:01后面的数据都丢失了但是AOF就是解决这些问题的方案 1)当手动执行bgsave触发一次生成内存快照的操作: 从redis服务器进行测试以后发现我们向redis服务器中插入几个键值对然后等待一段时间之后打开rdb文件发现文件内容并没有发生变化此时就可以手动执行save或者是bgsave由于这里的数据量比较小执行bgsave瞬间就完成了立即查看应该就是有结果的但是以后接触到的数据多了执行bgsave就很有可能消耗一定的时间立即查看不一定就生成完毕了redis再进行重新启动的时候加载了rdb的文件内容恢复了之前内存中的状态了 2)插入新的key不手动执行bgsave: 重新启动redis服务器发现新插入的键值对竟然在重启后仍然存在如果是通过正常流程重新启动redis服务器此时当redis服务器会在退出的时候自动触发生成rdb操作但是如果是异常重启kill -9或者是服务器掉电此时redis服务器来不及生成rdb内存中没有保存到快照中的数据就会随着服务器重启而消失 总结:rdb生成快照不仅仅是通过手动执行命令才触发也是可以自动触发的: 1)通过刚才配置文件中的save执行M时间内修改N次 2)通过shutDown命令也就是redis中的一个命令关闭redis服务器也会触发 3)当redis进行主从复制的时候主节点也会生成rdb快照然后把rdb快照文件内容传输给从节点实际开发中更害怕的是出现异常情况比如说通过kill -9命令杀死 手动观察RDB文件替换: 1)bgsave的执行流程是先创建子进程子进程完成持久化操作以后持久化就会把数据写入到新的文件中然后使用新的文件来替换旧的文件但是持久化本身速度太快了因为数据量比较少所以很难观察到子进程但是使用新的文件替换旧的文件这个是很容易观察到的 2)stat dump.rdb命令可以显示文件的inode编号inode相当于是rdb文件的唯一身份标识有的时候文件不是同一个文件了不过内容是一样的 3)如果这里面直接使用save命令此时是不会触发子进程和文件替换逻辑的如果是save就直接在当前进程中往刚才的同一个文件里面写入数据了flushall会清空rdb文件 手动破坏rdb文件: 1)手动的把rdb文件内容改坏然后一定是通过kill进程的方式重启redis服务器如果通过service redis-server start的方式重启就会在redis服务器退出的时候重新生成rdb快照就会把刚才咱们修改坏了的文件给替换掉了 2)手动将rdb文件内容破坏也就是在rdb文件内容的结尾写上一大堆的乱七八糟的字符串然后杀死redis进程然后重启redis文件发现仍能启动成功并且能够正确地获取redis中的数据但是这里取决于redis怎么样取决于rdb的文件坏在哪里如果像刚才这样修改坏的位置在文件末尾那么就对前面的内容没啥影响但是如果是中间的位置坏了可就不一定了 3)当redis服务器挂了可以查看redis日志: rdb文件是二进制的直接就把坏的rdb文件交给redis服务器来使用得到的结果是不可预期的可能redis服务器能启动但是也有可能得到的数据是错误的也有可能redis服务器直接启动失败redis本身提供了rdb文件的检查工具可以先来通过检查工具检查一下rdb文件是否符合要求就是redis-check-rdb *redis-check-rdb dump.rdb redis-server /etc/redis.conf RDB的特点: 1)rdb是一个紧凑压缩的二进制文件代表redis在某一个时间节点的二进制快照非常适用于备份全量复制等场景比如说每隔6h做一次bgsave备份并把rdb文件复制到远程机器或者是文件系统中用于灾备Redis加载rdb文件格式的数据远远快于AOF的方式因为rdb这里面使用二进制方式来组织数据直接把数据读取到内存里面按照字节的方式放到结构体和对象中即可AOF是使用文本的方式来组织数据的则需要手动的进行字符串切分操作 2)rdb最大的问题就是不能实时的持久化保存数据在两次生成快照之间实时的数据可能会随着重启而丢失 二)Redis持久化操作之AOF 1)AOF顾名思义就是append only file类似于MYSQL的binlog日志因为MYSQL把用户的每一个操作都记录到了文件中当开启AOF的时候rdb就不生效了启动的时候也就不在读取rdb文件内容了当redis重新启动的时候就会读取这个AOF文件中的内容用来恢复数据 AOF默认一般是关闭状态修改配置文件来开启AOF功能 2)可以使用appendonly yes来手动开启AOFappendfilename表示aof生成的文件名字这个aof所在的文件的位置也是和rdb所在的目录一样/var/lib/redis同样也是可配置的 3)AOF文件本身记录了用户执行操作以后的命令AOF本身是一个文本文件每一次进行的操作都会被记录到文本文件中通过一些特殊符号来作为分隔符来针对于命令的细节来做区分 4)redis虽然本身是一个单线程的服务器但是速度非常快为啥速度快一个非常重要的原因就是只是操作内存引入AOF以后又要写内存又要写磁盘还能和之前一样快了吗 实际上是没有影响的她并没有影响到redis处理请求的速度 5)AOF机制是否影响了redis处理请求的速度呢 5.1)AOF机制并非是直接让工作线程把数据写入到磁盘而是先写入到一个内存的缓冲区积累一波之后再来进行写入磁盘的操作这样就大大降低了写硬盘的次数假设现在有100个请求100个请求的数据一次性写入到硬盘比分100次每一次写一个请求要快很多但是实际上写硬盘的时候写入磁盘数据的多少对性能的影响不是很大但是写入磁盘的次数就影响很大了 5.2)在硬盘上面读写数据顺序读写的速度是比较快的虽然还是要比内存慢很多但是随机访问速度还是要慢很多的AOF操作是每一次把新的操作写入到原有文件的末尾是随机写入 AOF缓冲区的刷新策略: 但是此时如果把数据写入到缓冲区里面本质上还是在内存中万一这个时候突然进程挂了或者是主机掉电了是不是缓冲区的数据就丢了对的但是redis提供了缓冲区的刷新策略刷新频率越高性能影响就越大同时数据的可靠性就越高刷新频率越低性能影响就越小同时数据的可靠性就越低通过在配置文件中使用everyfsync来配置 1)always:当命令写入到AOF缓冲区中调用fsyc立即刷新到AOF文件中这种方式频率最高数据可靠性最高但是性能最低 2)everyesc:命令写入到AOF缓冲区中每一秒由同步线程刷新到缓冲区中本身频率要低一些数据可靠性也会降低但是性能会提升 3)no:命令写入到AOF中redis就不管了由OS控制fsyc刷新到缓冲区中频率最低数据可靠性也是最低了性能是最高的 AOF重写机制: 因为随着AOF记录的内容越来越多体积越来越大会影响到redis下一次的启动时间因为redis本身在进行启动的时候要去读取AOF文件的内容但是AOF文件本身只是记录了中间的过程但是实际上redis在重新启动的时候他是只是会记录中间的结果因为本身AOF的文件有很多的信息是冗余的比如说假设有一个客户端对于redis做了下面的操作 因此redis本身就存在着这样一个机制能够针对于AOF文件做整理操作这个整理就是能够剔除这里面的荣誉操作并且能够合并一些操作从而达到给AOF文件本身瘦身的这样一个效果 AOF的重写机制的触发时机: 1)手动触发:调用bgrewriteof命令 2)自动触发:根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentge参数来确定自动触发时机 auto-aof-rewrite-min-size:表示触发重写的时候的aof的最小文件大小默认是64MB auto-aof-rewrite-percentge:代表AOF占用大小相比较于上次重写的时候增加的比例 AOF重写的流程: 1)父进程仍然负责接受请求子进程仍然负责针对于AOF文件进行重写重写的时候不关心AOF文件中原来都有啥只是关心内存中最终的数据状态子进程只是需要把内存中的数据获取出来以AOF的格式写入到一个新的AOF文件中但是实际上AOF在进行重写的过程中并不需要遍历所有的命令进行压缩因为内存中的数据已经是最终的结果了也就是说AOF文件中的数据的状态就已经是相当于把AOF文件中的数据整理以后的结果了 2)此处这个子进程写数据的过程非常类似于RDB生成一个快照文件的过程只不过是RDB是按照二进制的方式来生成的AOF重写是按照AOF这里面生成的文本格式来生成的都是为了把当前内存中的所有的数据状态记录到文件中只不过是写入的数据的方式不一样一个是文本一个是二进制 3)在子进程写AOF文件的同时父进程仍然在不断的不停的接受客户端的新的请求但是父进程仍然会将这些新的请求写入到原来的缓冲区中然后再刷新到旧的AOF文件中 4)但是在创建子进程的那一时刻子进程就继承了父亲进程的当前的内存状态因此此时的子进程的内存数据就是父亲进程fork之前的状态那么在fork以后的时候新来的请求对内存进行的修改对子进程没有影响解决的方案就是在父亲进程里面又准备了一个aof_rewrite-buf缓冲区这个缓冲区专门用来存放父进程fork出来的子进程以后新增的命令所以此时父进程就很忙了父进程既要写原来的aof缓冲区又要写aof_rewrite_buf缓冲区两个缓冲区都要写一个是往旧的缓冲区里面写一个是往新的缓冲区里面写 5)当子进程这边把新的AOF的文件的数据写完以后会通过一个信号机制通知一下父进程然后父进程再把aof_rewrite_buf缓冲区中的数据也写入到新的AOF缓冲区里面 新的AOF文件来源于两方面: 1)父进程fork子进程那一时刻的内存的数据 2)子进程在重写期间父进程向aof_rewrite_buf中写的数据 6)新的AOF文件替换原来的AOF文件 总结:整个重写过程分成两个阶段一份是fork之前的父进程内存中的数据子进程直接写入到新的AOF文件中一份是fork之后父进程收到命令修改后的数据由父进程现存放到AOF重写缓冲区以后等待子进程发送重写完成的信号再由父进程将重写缓冲区里面的数据写入到新的AOF文件中 AOF重写的问题: 1)如果在执行bgrewriteaof的时候当前redis已经正在进行AOF重写了会咋样呢此时就不会再执行AOF重写了就会直接返回了只有等待一段时间以后AOF重写才会起到立竿见影的成果 2)如果在执行bgrewriteaof的时候发现当前redis在生成rdb文件快照的时候会咋样呢 此时aof重写操作就会等待等待rdb生成快照完毕以后再来进行aof重写操作 3)rdb本身对于fork之后的新数据就置之不理了但是AOF对于fork之后的新数据采取了AOF_rewrite_buf的缓冲区来进行处理因为本身rdb的设计理念就是用来做定期备份数据的只要是定期备份就很难和最新的数据保持一份aof的设计理念就是实时备份实时备份比定期备份的系统开销比较大但是现在的系统中系统的资源一般来说都是比较充裕的上一些更好的服务器更好的配置更好的服务器AOF的开销也就不算事但是AOF的加载速度比较慢 4)当前父进程fork完毕以后就已经让子进程写新的AOF文件了并且随着时间的推移子进程已经写完了新的文件并且要让新的AOF代替旧的但是父亲进程还是在继续写这个即将消亡的旧的AOF文件是否还有意义 不能不写旧的文件假设在重写过程中重写了一半了突然间服务器挂了这样的重写显然是无法继续了如果主机挂了aof_rewrite_buf中的数据就没了服务器就不完整子进程内存中的数据就会丢失新的AOF文件的内容还不完整如果父进程不坚持写旧的AOF文件重启以后就无法保证数据的完整性了 三)混和持久化: 混合持久化既可以保证aof文件没有那么大还可以保证服务器启动以后加载的效率 1)混合持久化的定义:AOF本来是按照文本的方式来写入文件的但是以文本的方式写文件后续加载的成本是比较高的于是redis就引入了混和持久化的方式本身结合了rdb和aof的特点按照aof的方式每一个请求/操作都记录到文件里面但是在触发AOF重写以后就会把当前内存的状态按照rdb二进制的形式写入到新的AOF文件中后续再进行操作redis仍然是按照aof文本的方式追加到文件的后面 2)aof-use-rdb-preamble yes表示开启混和持久化修改配置以后要记得重启服务器才可以生效如果不开启混和持久化那么重写AOF文件就是按照AOF文本格式来记录的本质上还是命令 四)关于信号的理解: 当redis上同时存在rdb和aof快照的时候以AOF为主rdb就直接被忽略了因为AOF包含的数据比RDB更全 1)信号表达的信息有限并非能够像socket这样的方式来进行传输数据因此像上述父子进程场景中子进程表示我干完了这种简单的信息传输使用信号也是OK当然其他进程中通信方式就是OK和JS的事件是类似的 2)事件事件源事件类型事件处理函数虽然不知道事件什么时候来但是当用户点击这个按钮就弹出一个对话框或者是进行提交信号就可以理解成linux内核版本的事件机制: 信号源信号类型信号的处理函数在内核中更关注的是信号发给谁kill -9表示给指定进程发送9号信号信号处理函数等同于事件处理函数 3)function(datastatus){把重写缓冲区中的数据写到新的AOF文件中} 五)Redis事务: 1)原子性:redis中的事务到底存不存在原子性存在争议原子就是不可以拆分的最小单元 原子性最初的含义是:是将多个操作打包到一起要么全都执行成功要么全都不执行redis做到了上述的含义但是MYSQL这里面的原子性走得更远也是把多个操作打包到一起要么全部执行正确要么全都不执行但是redis这里面的事务不保证成功redis是将这些操作打包了是全部执行了但是它只是保证执行但是成功与否与我无瓜redis中的事务由若干个操作存在有失败的那就失败把不会执行回滚操作但是MYSQL中的事务如果有操作执行失败就会进行回滚把中间已经执行的操作全部回退redis这里面的事务只是打包MYSQL是打包在一起正确执行 2)不具备一致性:redis没有约束也没有回滚机制事务执行过程中一旦出现了某一个修改操作出现失败就可能会引起数据不一致的情况 3)持久性:不具备持久性redis本身就是一个内存数据库数据是存储在内存中虽然redis也有持久化机制但是这里的持久化机制和事务没啥关系MYSQL保证只要执行事务最终修改的数据就一定保存在硬盘上但是redis事务和持久性没啥关系 4)隔离性:不涉及隔离性redis是一个单线程模型的服务器程序所有的请求和事务都是串行执行的MYSQL中的隔离性只有说并发执行事务才会出现执行但是现在redis完全串行执行 1)redis的事务主要的意义就是为了打包一起避免其他客户端的命令插队插到中间Redis本身实现事务是引入了一个队列这是每一个客户端都存在一个开启事务的时候此时客户端输入的命令就会发送给服务器并且进入到这个队列里面而不是立即执行当遇到了执行事务这个命令以后此时就会把队列中的这些任务都按照顺序依次执行这些任务的执行都是在主线程中完成的主线程会先把事务中的操作都执行完成再来执行处理别的客户端redis中的事务只是保证执行但是最终执行的结果对不对redis说的不算 2)redis中的事务为什么就搞得这个简单为什么不像MYSQL那样子弄得那么强大呢 因为MYSQL中的事务在背后付出了很大的代价要花费更多的空间来存储更多的数据时间上也有很大的执行开销正是因为MYSQL有了上述的问题才有了redis上场的机会 啥时候需要使用到Redis中的事务呢如果我们将多个操作打包进行使用事务是比较合适的 超卖是放货5000台实际上如果让5001个人下单成功实际上就属于超卖问题 如果不加上任何限制就很有可能存在线程安全问题因为在以前多线程的时候是通过加锁的方式来避免插队的但是在redis中直接使用事务就可以 1)当第二个客户端的执行事务命令发送过来以后服务器才真正的执行第二个事务里面的内容此时第一个事务执行完成事务命令已经运行过了此时第二个事务get到的count就已经是第一个事务自减以后的结果了实际上在这个过程没加锁也可以解决问题 2)从上面的角度来看redis的原生命令里面是不支持条件判定的但是redis中支持lua脚本通过lua脚本就可以实现上述的条件判定并且也是和事务一起是打包一起批量执行的lua脚本的实现方式是事务的进阶版本redis如果是按照集群部署不支持事务 事务的操作: 开启事务:multi向里面添加命令只是向服务器的事务队列中添加了并且保存了上述请求此时如果另外在开启一个客户端再尝试查询这几个key对应的数据是不存在结果的 执行事务:exec 回滚事务:discrad丢弃这个事务中添加任务队列中的任务 1)当开启事务并且给服务器发送若干个命令以后服务器的事务相当于是discard当执行multi以后是把命令发送给服务器的任务队列里面但是并没有执行但是任务队列是内存的数据 2)通过watch命令来监控某一个key在任务执行前是否发生了改变下面结果是222 1)由于在客户端1得是exec执行了才会真正的执行set key 222这个操作实际上变成了更晚的操作所以最终值就是222 2)在刚才这个场景中我们就可以使用watch命令来监控这个key看看这个key在事务的multi和exec之间set key以后是否存在着外部被其他客户端修改了如果加上了这个监控指标此时当exec执行命令的时候发现外部的key存在着修改于是真正执行set key 222的时候就会报错就没有真正执行虽然watch命令没有真正的实现加锁但是可以得知外部的客户端针对于当前的key造成的修改和变化从而不会导致其他客户端进行修改从而造成结果上的一些歧义和影响 watch的实现:底层是基于乐观锁实现的 1)乐观锁和悲观锁指的不是某一把具体的锁而是指的是某一类锁的特性锁冲突的意思就是两个线程针对于同一个锁加锁一个线程加锁成功另一个就得阻塞等待 乐观锁:在加锁之前就有一个心理预期预计锁冲突的概率比较低 悲观锁:在加锁之前也有一个心理预期预计锁冲突的概率比较高 redis本身就是基于版本号这样的机制来实现了乐观锁 2)当执行watch key的时候就会给key安排一个版本号版本号可以理解成一个整数每一次进行修改key的时候key的版本号就会变大注意:版本号会变大但是不会自增 1)watch必须搭配事务来进行使用况且这个命令执行必须在multi之前 2)当执行watch命令的时候当前的redis客户端就会给这个key分配一个版本号并且当前事务会记录这个版本号别的客户端想要针对于当前这个key作出修改就会引起版本号变大比如说客户端让key的版本号变成了2 3)当客户端1执行了命令的时候此时就会做出判定当前这个key的版本号和最初watch时候的版本号是否一致如果不一致说明key在其它客户端已经被修改了就会执行失败直接丢弃事务中的操作exec直接返回nil如果一致那么就说明当前key在事务开启的过程中到最终执行的过程中没有别的客户端修改这个key才能真正进行设置watch本质上是给exec家伙是那个了一个版本号的判断条件是基于乐观锁实现的底层就是基于CAS实现 总结:redis中的事务要比MYSQL做的事务要简单得多 1)原子性:Redis中的事务并不支持回滚只是可以保证这些操作可以在一起执行 2)一致性:Redis本身并不会保证事务执行前和执行后内容统一数据一致 3)持久性:redis的数据是保存在内存里面的持久化机制和事务的持久性没有任何关联关系 4)隔离性:redis本身是单线程执行的服务器模型上面处理的请求本质上是串行执行的官方网站上说类似于事务的操作都是可以通过lua脚本来实现的
