MySQL-HandlerSocket交易

在Redis中可以通过以下方式完成交易：

redis.watch('powerlevel')
current = redis.get('powerlevel')
redis.multi()
redis.set('powerlevel', current + 1)
redis.exec()

>是否可以使用HandlerSocket执行此操作？
>使用事务提供的处理程序的一般功能是什么？

解决方法:

将Redis的“交易”与通用事务引擎进行比较总是会产生误导. Redis WATCH / MULTI / EXEC块是：

>不是原子的(发生错误时不会回滚)
>一致(Redis并没有太多的一致性规则)
>完全隔离(所有内容都已序列化)
>如果选择了AOF fsync策略,则可能持久

因此,Redis不能完全提供通常用于定义事务的完整ACID属性.与大多数事务引擎相反,Redis提供了非常强的隔离性,并且没有尝试提供任何回滚功能.

问题中提供的示例并不是真正具有代表性的IMO,因为可以通过使用以下方法以更简单的方式实现相同的行为：

redis.incr(“ powerlevel”)

因为Redis单一操作始终是原子的且孤立的.

WATCH / MULTI / EXEC块通常在必须加强各种密钥之间的一致性或实现乐观锁定模式时使用.换句话说,如果您的目的只是增加隔离计数器的数量,则无需使用WATCH / MULTI / EXEC块.

HandlerSocket是完全不同的野兽.它建立在MysqL的通用处理程序之上,并且取决于基础存储引擎,事务行为将有所不同.例如,当与MyISAM一起使用时,它将不使用ACID事务,但是将通过表级别的R / W锁来确保一致性.使用InnoDB,ACID事务将以默认隔离级别使用(可以在InnoDB配置AFAIK中设置). InnoDB实现了MVCC(多版本并发控制),因此锁定比MyISAM复杂得多.

HandlerSocket与两个工作线程池一起使用(一个用于只读连接,一个用于面向写连接).人们应该使用几个读取工作线程,但是只能使用一个写入线程(可能是为了减少锁定争用).因此,在基本配置中,写入操作是序列化的,而不是读取操作. AFAIK具有与Redis相同的隔离语义的唯一可能性是仅使用面向写的套接字来执行读和写操作,并仅保留一个写线程(所有操作的完全序列化).但是它将影响可伸缩性.

根据HandlerSocket协议,无法访问事务功能.在每个事件循环迭代中,它收集所有操作(来自所有套接字),并为所有这些操作执行唯一事务(仅与InnoDB相关). AFAIK,用户无法更改此交易的范围.

结论是,通常不可能使用HandlerSocket模拟Redis WATCH / MULTI / EXEC块的行为.

现在回到示例,如果目的只是以一致的方式增加计数器,则the HandlerSocket protocol完全支持该功能.例如,可以使用/-(增加/减少)操作,并且还可以使用U?.操作(类似于Redis GETSET命令)或？/-？ (增加/减少,返回前一个值).