redis自学3----redis的管道和事务

1.什么是redis的管道

• Redis是一种基于客户端-服务端模型以及请求/响应协议的TCP服务。这意味着通常情况下一个请求会遵循以下步骤：客户端向服务端发送一个查询请求，并监听socket返回，通常以阻塞模式，等待服务器响应；服务器将结果返回给客户端。当客户端与服务器存在网络延时时，从客户端发送消息到服务器返回消息时间会很长，这样就会导致性能问题。
• 所以redis为了解决这个问题，利用管道，客户端一次发送多个请求给服务端而不需要等服务端响应，带所有命令都发送完后再一次性读取服务的响应，这样可以极大提升性能。

2.使用管道的注意事项

• 由于中间执行结果会先缓冲到内存，所以如果命令执行结果数据比较多的话会导致服务器端内存暴增(例:keys、smembers命令)
• 当已经把网络包填充满后，在增加多的命令，并不能提升性能，主要是看tcp最大报文段长度的值

3.redis的事务

• multi，开启一个事务
• exec，执行事务中所有的命令，即multi后所有的命令
• discard，类似回滚，即不执行multi后的命令
• watch，类似于乐观锁的实现，当事务执行期间(其实就是事务开始时，因为redis时单线程，一旦开始执行，数据不会被其它线程命令修改)，被观察的key的值发生变化，则事务不会执行
• unwatch，取消观察，即取消乐观锁

4.事务的本质理解

• 类似于命令队列，保证命令的顺序性，并会检查入队列的每个命令的语法合法性
• 所有命令执行过程不会被打断，即使中间某个命令执行失败，也会把剩下的所有命令都执行完成，并不会将已经执行成功的命令回滚，所以不能保证一致性、原子性
• 当事务通过exec或者discard后，watch乐观锁会失效

5.redis的ACID

• A(原子性)：事务中的命令要么都执行，要么都不执行
  • redis的原子性有一定的局限性，它只能检查语句的合法性(入队检查)，如果进入队列的语法不合法，则整个事务不会提交
  • 如果采用乐观锁(watch)，则当对应的key值发生变化是，事务不会提交
• C(一致性)：事务提交前后，数据保持一致
  • 因为redis是单线程执行，即同时刻只能有一个命令在执行，因此不会出现在执行过程中数据被其他命令修改的情况
  • 执行过程中宕机不会导致数据不一致，因为通过持久化机制可以按照执行成功的标准检测
  • 有一定的局限性：没有事务回滚机制，一旦某个命令执行失败(剩下的命令依然会继续执行)，会导致整个事务的数据不能完整
• I(隔离性)：事务和事务之间互相隔离
  • redis是单线程执行，所有具备很好的隔离性
• D(持久性)：事务提交后，对数据的修改是永久性的
  • 依赖redis的持久化机制，如果采用aof，则需要设置appendfsync为always，每个命令的执行都会写入磁盘

6.redis事务总结

• 并不能像关系型数据库那样严谨
• 一般的语句执行错误都是由于命令错误等bug导致，某些命令执行总会成功，不如mset命令；因此，为了获取比较高的性能，在不是很严格的业务场景还是可以大胆的使用的，如果在非常严谨的场景使用，建议增加类似数据校验机制进行数据的验证和纠正处理