旅游b2b分销网站建设谷歌搜索排名

ACID特性无需多言。我们知道关系数据库比如mysql可以实现事务的ACID特性，begin,commit,回滚实现。
那么redis可以实现ACID吗，结论是不能完全保证。

首先要知道redis通过MULTI关键字开启事务，中间一系列操作，加到操作队列中并不执行。然后通过EXEC提交事务，真正执行命令。

原子性分析：
如果中间操作发生错误，原子性可以保证吗？分三种情况看。
第一种情况是，在执行EXEC命令前，客户端发送的操作命令本身就有错误（比如语法错误，使用了不存在的命令），在命令入队时就被Redis实例判断出来了。这种整个事务会放弃执行，可以保证原子性。
第二种：事务操作入队时，命令和操作的数据类型不匹配，但Redis实例没有检查出错误。但是，在执行完EXEC命令以后，Redis实际执行这些事务操作时，就会报错。不过，需要注意的是，虽然Redis会对错误命令报错，但还是会把正确的命令执行完。在这种情况下，事务的原子性就无法得到保证了。redis并没有回滚机制。

第三种情况：在**执行事务的EXEC命令时，Redis实例发生了故障，导致事务执行失败。**在这种情况下，如果Redis开启了AOF日志，那么，只会有部分的事务操作被记录到AOF日志中。我们需要使用redis-check-aof工具检查AOF日志文件，这个工具可以把已完成的事务操作从AOF文件中去除。

一致性是可以保证的。

再看隔离性。隔离包括：读未提交（B可以读到A没有提交的数据，出现脏读，读的数据是旧数据，不存在的数据很严重）读已提交/不可重复读（B只能读A已经提交的数据，但是事务A多次读取同一数据，如果中间B修改了数据，并提交，A多次读取的数据不一致） 可重复读（多次读取数据一致，但是会出现幻读，就是第一次读取数据不存在，但是准备insert时发现数据一斤存在无法插入，为什么会这样，因为中间可能B插入了该条数据，但是A读取的仍然是开始的视图，依然没有记录为了保证可重复读，具体二者MVCC机制不展开说了）
最强的就是串行化可以一起读，但是只能一个写，mysql默认的是可重复读。
对于redis,如果并发操作在EXEC前面，那么用watch机制可以保证隔离性，WATCH如果观察变量变化了，就不执行命令。如果并发是在EXEC后面，那么由于redis是单线程的，隔离性肯定能保证。

持久性肯定是不行的。如果Redis没有使用RDB或AOF，那么事务的持久化属性肯定得不到保证。如果Redis使用了RDB模式，那么，在一个事务执行后，而下一次的RDB快照还未执行前，如果发生了实例宕机，这种情况下，事务修改的数据也是不能保证持久化的。
如果Redis采用了AOF模式，因为AOF模式的三种配置选项no、everysec和always都会存在数据丢失的情况，所以，事务的持久性属性也还是得不到保证。

所以，综上。ACID特性
对于原子性，如果命令没错但是操作类型对不上（比如string类型POP），EXEC后执行某个命令才出错，原子性不能保证，没有回滚机制的。如果在EXEC之前就发现错误，这些都不会执行。

对于一致性，可以保证的。

对于隔离性，如果并发操作在EXEC之前，用WATCH可以保证，并发在EXEC后面，由redis单线程执行命令天然就能保证。

对于持久性，不能保证，因为AOF,RDB落盘前redis崩溃无法恢复。