21 | 缓冲区：一个可能引发“惨案”的地方

应用程序和Redis实例交互时，应用程序中使用的客户端需要使用缓冲区吗？如果使用的话，对Redis的性能和内存使用有什么影响？ 客户端需要使用缓冲区，好处如下。 1、客户端和服务端交互，一般都会制定一个交互协议，客户端给服务端发数据时，都会按照这个协议把数据拼装好，然后写到客户端buffer中，客户端再一次性把buffer数据写到操作系统的网络缓冲区中，最后由操作系统发送给服务端。这样服务端就能从网络缓冲区中读取到一整块数据，然后按照协议解析数据即可。使用buffer发送数据会比一个个发送数据到服务端效率要高很多。 2、客户端还可以使用Pipeline批量发送命令到服务端，以提高访问性能。不使用Pipeline时，客户端是发送一个命令、读取一次结果。而使用Pipeline时，客户端先把一批命令暂存到buffer中，然后一次性把buffer中的命令发送到服务端，服务端处理多个命令后批量返回结果，这样做的好处是可以减少来回网络IO的次数，降低延迟，提高访问性能。当然，Redis服务端的buffer内存也会相应增长，可以控制好Pipeline命令的数量防止buffer超限。 缓冲区其实无处不在，客户端缓冲区、服务端缓冲区、操作系统网络缓冲区等等，凡是进行数据交互的两端，一般都会利用缓冲区来降低两端速度不匹配的影响。没有缓冲区，就好比一个个工人搬运货物到目的地，每个工人不仅成本高，而且运输效率低。而有了缓冲区后，相当于把这些货物先装到一个集装箱里，然后以集装箱为单位，开车运送到目的地，这样既降低了成本，又提高了运输效率。缓冲区相当于把需要运送的零散数据，进行一块块规整化，然后分批运输。 另外，关于Redis服务端为客户端分配的输出缓冲区，我想补充一点：主库上的从库输出缓冲区（slave client-output-buffer）是不计算在Redis使用的总内存中的，也就是说主从同步延迟，数据积压在主库上的从库输出缓冲区中，这个缓冲区内存占用变大，不会超过maxmemory导致淘汰数据。只有普通客户端和订阅客户端的输出缓冲区内存增长，超过maxmemory时，才会淘汰数据。

有几个问题希望老师帮忙解答一下 1、TCP已经有读写缓冲区，redis为何还要单独维护读写缓冲区，两者的作用看起来是一致的 2、缓冲区类似队列，读写变成异步，主线程跟缓冲区交互，是什么线程负责缓冲区跟tcp的数据同步

各位大牛，是有额外的线程来处理 输入输出缓冲区吗，否则，是主线程处理的话，主线程阻塞的时候，客户端的数据是如何到输入缓冲区的？

这个坑踩得很深，分享一个计算repl大小的脚本。https://blog.csdn.net/MyySophia/article/details/107126459

qbuf=0 qbuf-free=0 这是什么情况导致的？

老师, 我想问一下复制缓冲区(replication_buffer)在全量复制完成之后命令也同步完了还会存在么?

大佬，文章里客户端输入缓冲区是个什么概念？程序客户端有redis连接池，每个连接对于redis server都是一个客户端，每个连接都在redis server里有一个输入缓冲区吗？

Redis 原本就是当做缓存在用，然后它又有自己的缓冲区，果然是应了那句话，在计算机领域，没有什么问题是加一层缓存解决不了的。 直接跳到课后问题，应用程序和 Redis 实例交互时，应用程序客户端应该也会使用缓冲区，对于 Redis 的性能和内存同样会有影响。如果不想造成缓冲区溢出那么也需要设置合理的缓冲区参数，以及设置合理的读写速率。 课后题的解答主要靠课代表 @Kaito

有几个疑问希望老师帮忙解答： 1、tcp已经有读写缓冲区， redis 为何还要再单独维护读写缓冲区，两者的作用看起来是一样的

服务器端处理请求的速度过慢，例如，Redis 主线程出现了间歇性阻塞，无法及时处理正常发送的请求，导致客户端发送的请求在缓冲区越积越多。 这句话有点没理解，redis大部分请求是阻塞的，对客户端来说需要等待服务器的相应结果，虽然相应结果不一定有用，但这样的情况，redis服务端如果处理请求较慢，那么客户端输入缓冲区应该是当前请求一直在hold吧？服务器处理慢会导致等待的客户端变多，整体积压的输入缓冲变多，但对单个缓冲区来说，溢出应该不是主要的吧？ 不知道上述理解是否正确……