（伊春三）【中】：Redis「服务器」和客〖户端的〗通讯

admin 科技 2021-06-25 139 2

Redis〖客户端使用〗RESP（Redis序列化协议）与Redis服务器举行通讯，RESP在位于TCP之上，而网络模子上客户端和服务器是保持的双工的毗邻。如图1

而一个简朴的请求/响应的串行通讯模子如下图：

“串行”化通讯

“串行”化通讯比较简朴，上面那张图就很外面的反映出来这种通讯方式，同一个Connction需要在等上一个下令执行完成之后在执行下一个下令，我们在前面文章讲Redis各种类型的时刻做的测试，就是用这种方式。客户端发送一个指令到Redis实例，Redis实例处置完成之后将效果返回给客户端。

《前面文》章说Redis（为什）么要用多线程中有说过，Redis处置请求的速率稀奇快，我们一个请求的瓶颈主要是在I/O上面，而对于“串行”化通讯，每一个请求的发送都要等到上一个请求的响应先容，因此在串行模式下，单毗邻的大部分时间都虚耗在网络守候上，没有充实的行使服务器的处置能力。

管道手艺

Redis在很早的时刻就支持管道手艺了，简朴来说，就是可以完全无需守候服务端应答地发送多条指令给服务端，并最终一次性读取所有应答。管道手艺最显著的优势是提高了redis服务的性能，通过管道手艺来举行大批量的操作的时刻，可以节约许多在网络延迟上的[时间。

在.net core 的Redis客户端StackExchange.Redis“则”是基于Task来实现管道手艺，而StackExchangeRedis自己的异步也都是通过管道手艺来实现。

『事』务

在菜鸟教程中是这么先容的

Redis 『事』务可以一次执行多个下令，而且带有以下三个主要的保证：

批量操作在发送 EXEC 下令前被放入行列缓存。

收到 EXEC 下令后进入『事』务执行，『事』务中随便下令执行失败，其余的下令依然被执行。

在『事』务执行历程，其他客户端提交的下令请求不会插入到『事』务执行下令序列中。

一个『事』务从最先到执行会履历以下三个阶段：

最先『事』务。

下令入队。

执行『事』务

放弃『事』务

原理很简朴，客户端发送下令MULTI，服务器会将后续的下令都放入行列缓存，直到收到EXEC下令才会依次执行下令。单个Redis的下令是原子性的，然则Redis并没有在『事』务上增添任何的维持原子性的机制，当中心某条下令失败并不会导致其他下令的回滚，这个跟我们在关系型数据库的明白不一样，更多的像一个打包的批处置剧本。

{菜鸟中有这么一句话}

在『事』务执行历程，其他客户端提交的下令请求不会插入到『事』务执行下令序列中。

大略一看我还明白为『事』务开启会壅闭其他客户端的下令，吓得我马上做了一下测试

在客户端1中开启『事』务multi，并发送一个set 和 get 的下令，能看到都是QUEUED的状态，注释是准确的入队了

接着在客户端2中获取key1发现值是null，说明客户端1的下令还没有真正执行，接着设置key1的值为value2，接着取得key1的值，在客户端1中开启『事』务后，在客户端2是可以顺遂执行下令的，菜鸟中的话的意思实在客户端的下令不会进入开启『事』务谁人客户端的下令行列中。

我们接着在客户端1提交下令，key1《的值变为》value1，客户端2中设置的value2被更改为value1了。

我们将Redis『事』务与数据库『事』务的四大特征对比下


原子性	不支持	Redis单个指令是具有原子性的，然则『事』务没有
『一致性』	不支持	在上面的例子就可以瞥见，在客户端1的『事』务开启的时刻，我仍然能修改key1的值，在关系型数据库中我们有消极锁和乐观锁来解决这种并发问题，Redis也通过Watch可以实现乐观锁的效果，然则我照样没有体会出来有什么用处。在关系型数据中的『事』务，我们可能会先取出来值，在举行修改，最后提交『事』务，若是没有锁来保证，那么我们最后的数据就没有『一致性』了，然则对于Redis我照样没想出来什么场景下会需要用乐观锁来控制并发，知道的小伙伴贫苦见告一声。
隔离性	支持	Redis自己是没有隔离性这个说法的，之以是我以为是支持隔离性，【〖由于〗我以为】Redis的『事』务都是在最后才执行，而自己下令又是原子性的，以是隔离性对Redis是无意义的。
持久性	不支持	Redis有持久化方案，然则最高数据安全性的方式-AOF中的修改同步，仍然会在异常情况下导致数据丢失。

实在这个对比不太适当，Redis的『事』务只是顶着『事』务这个名字，做的照样批量处置的事情，它的关注点不应该在正真的『事』务上

剧本

在说『事』务的时刻有说『事』务更像是批处置的感受，而剧本也是批处置，差别的是，我们可以凭据上一个指令的效果作为我们下个<指令的>参数，《这是》处置逻辑问题的时刻稀奇有用。

Redis剧本是通过Eval下令实现，当客户都安使用Eval下令的时刻，Redis实例会通过lua注释器来执行剧本，我们这里的剧本也是lua剧本，用Abp中消灭缓存的的源码作为示[例

EVAL "local keys = redis.call('keys', ARGV[1]) 
                for i=1,#keys,5000 
                do 
                redis.call('del', unpack(keys, i, math.min(i+4999, #keys)))
                end" 
                0 'Test_*'

这个剧本第一步将以Test做为前缀的key所有取出来存入变量keys,接着从1最先，以keys的长度为最大值，步长为5000举行遍历，每一步都是删除5000个key。为什么要用每次5000遍向来执行呢？〖由于〗unpack 函数在数目太多的时[刻会泛起 'too many results to unpack' 的错误，我们来实际操作下，往实例中添加10个用Test_为前缀的值，然后执行上面的剧本