Redis Lettuce 客戶端與IO阻塞VS非阻塞 同步VS異步的總結(jié)

概念簡介

簡單介紹，不做過多描述，網(wǎng)上很多詳細(xì)介紹

  • TCP/IP
    屬于網(wǎng)絡(luò)協(xié)議
  • SOCKET 為內(nèi)核向用戶提供的可以實(shí)現(xiàn)各種網(wǎng)絡(luò)通信協(xié)議的api
  • FD Linux 一切皆文件,進(jìn)程可以打開成百上千個(gè)文件，為了表示和區(qū)分已經(jīng)打開的文件，Linux 會(huì)給每個(gè)文件分配一個(gè)編號(hào)（一個(gè) ID），這個(gè)編號(hào)就是一個(gè)整數(shù)，被稱為文件描述符（File Descriptor）

IO模型(Unix 網(wǎng)絡(luò)編程P124)

首先一個(gè)IO操作其實(shí)分成了兩個(gè)步驟：發(fā)起IO請(qǐng)求和實(shí)際的IO操作，

同步IO和異步IO的區(qū)別就在于第二個(gè)步驟是否阻塞，如果實(shí)際的IO讀寫阻塞請(qǐng)求進(jìn)程，那么就是同步IO，因此阻塞IO、非阻塞IO、IO復(fù)用、信號(hào)驅(qū)動(dòng)IO都是同步IO，如果不阻塞，而是操作系統(tǒng)幫你做完IO操作再將結(jié)果返回給你，那么就是異步IO。

阻塞IO和非阻塞IO的區(qū)別在于第一步，發(fā)起IO請(qǐng)求是否會(huì)被阻塞，如果阻塞直到完成那么就是傳統(tǒng)的阻塞IO，如果不阻塞，那么就是非阻塞IO。

同步：所謂同步，就是在發(fā)出一個(gè)功能調(diào)用時(shí)，在沒有得到結(jié)果之前，該調(diào)用就不返回。

異步：異步的概念和同步相對(duì)。當(dāng)一個(gè)異步過程調(diào)用發(fā)出后，調(diào)用者不能立刻得到結(jié)果。實(shí)際處理這個(gè)調(diào)用的部件在完成后，通過狀態(tài)、通知和回調(diào)來通知調(diào)用者。

  • 阻塞blocking I/O
    可讀事件和實(shí)際數(shù)據(jù)讀全過程全阻塞


    blocking-io.jpg

-非阻塞 nonblocking I/O
可讀事件由用戶態(tài)輪詢,數(shù)據(jù)讀取過程阻塞


non-blocking-io.jpg

  • IO復(fù)用 I/O multiplexing (select and poll)


    multiplexing-io.jpg

1.2 IO多路復(fù)用的歷史
select, poll, epoll 都是I/O多路復(fù)用的具體的實(shí)現(xiàn)，之所以有這三個(gè)鬼存在，其實(shí)是他們出現(xiàn)是有先后順序的。

I/O多路復(fù)用這個(gè)概念被提出來以后， select是第一個(gè)實(shí)現(xiàn) (1983 左右在BSD里面實(shí)現(xiàn)的)。

select
select 被實(shí)現(xiàn)以后，很快就暴露出了很多問題。

select 會(huì)修改傳入的參數(shù)數(shù)組，這個(gè)對(duì)于一個(gè)需要調(diào)用很多次的函數(shù)，是非常不友好的。

select 如果任何一個(gè)sock(I/O stream)出現(xiàn)了數(shù)據(jù)，select 僅僅會(huì)返回，但是并不會(huì)告訴你是那個(gè)sock上有數(shù)據(jù)，于是你只能自己一個(gè)一個(gè)的找，10幾個(gè)sock可能還好，要是幾萬的sock每次都找一遍，這個(gè)無謂的開銷就頗有海天盛筵的豪氣了。

select 只能監(jiān)視1024個(gè)鏈接， 這個(gè)跟草榴沒啥關(guān)系哦，linux 定義在頭文件中的，參見FD_SETSIZE。

select 不是線程安全的，如果你把一個(gè)sock加入到select, 然后突然另外一個(gè)線程發(fā)現(xiàn)，尼瑪，這個(gè)sock不用，要收回。對(duì)不起，這個(gè)select 不支持的，如果你喪心病狂的竟然關(guān)掉這個(gè)sock, select的標(biāo)準(zhǔn)行為是。。呃。。不可預(yù)測(cè)的， 這個(gè)可是寫在文檔中的哦.

“If a file descriptor being monitored by select() is closed in another thread, the result is unspecified”
霸不霸氣

poll
于是14年以后(1997年）一幫人又實(shí)現(xiàn)了poll, poll 修復(fù)了select的很多問題，比如

poll 去掉了1024個(gè)鏈接的限制，于是要多少鏈接呢， 主人你開心就好。

poll 從設(shè)計(jì)上來說，不再修改傳入數(shù)組，不過這個(gè)要看你的平臺(tái)了，所以行走江湖，還是小心為妙。

其實(shí)拖14年那么久也不是效率問題， 而是那個(gè)時(shí)代的硬件實(shí)在太弱，一臺(tái)服務(wù)器處理1千多個(gè)鏈接簡直就是神一樣的存在了，select很長段時(shí)間已經(jīng)滿足需求。

但是poll仍然不是線程安全的， 這就意味著，不管服務(wù)器有多強(qiáng)悍，你也只能在一個(gè)線程里面處理一組I/O流。你當(dāng)然可以那多進(jìn)程來配合了，不過然后你就有了多進(jìn)程的各種問題。

select/poll的幾大缺點(diǎn)
1、每次調(diào)用select/poll，都需要把fd集合用戶態(tài)拷貝到內(nèi)核態(tài)，這個(gè)開銷在fd很多時(shí)會(huì)很大
2、同時(shí)每次調(diào)用select/poll都需要在內(nèi)核遍歷傳遞進(jìn)來的所有fd，這個(gè)開銷在fd很多時(shí)也很大
3、針對(duì)select支持的文件描述符數(shù)量太小了，默認(rèn)是1024
4.select返回的是含有整個(gè)句柄的數(shù)組，應(yīng)用程序需要遍歷整個(gè)數(shù)組才能發(fā)現(xiàn)哪些句柄發(fā)生了事件；
5.select的觸發(fā)方式是水平觸發(fā)。（個(gè)人理解：如交易系統(tǒng)每筆交易會(huì)觸發(fā)一次，一次就是把所有fd集合從用戶態(tài)拷貝到內(nèi)核態(tài)，所有表示select觸發(fā)頻率也很高）

epoll
于是5年以后, 在2002, 大神 Davide Libenzi 實(shí)現(xiàn)了epoll.

epoll 可以說是I/O 多路復(fù)用最新的一個(gè)實(shí)現(xiàn)，epoll 修復(fù)了poll 和select絕大部分問題, 比如：
epoll 現(xiàn)在是線程安全的。
epoll 現(xiàn)在不僅告訴你sock組里面數(shù)據(jù)，還會(huì)告訴你具體哪個(gè)sock有數(shù)據(jù)，你不用自己去找了。

  1. select的本質(zhì)是采用32個(gè)整數(shù)的32位，即32*32= 1024來標(biāo)識(shí)，fd值為1->1024。當(dāng)fd的值超過1024限制時(shí)，就必須修改FD_SETSIZE的大小。這個(gè)時(shí)候就可以標(biāo)識(shí)32*max值范圍的fd。
    這種設(shè)計(jì)遍歷的過程非?？?，因?yàn)橛梦坏倪壿嫴僮骶涂梢?br> 缺點(diǎn)：
    a. fd超過1024時(shí)，性能無法滿足，在linux 早期并發(fā)沒有那么大，還可以大范圍支持。
    b. 網(wǎng)絡(luò)一般分兩步操作，一步是獲取io事件，另一步是數(shù)據(jù)讀取，從內(nèi)核態(tài)讀到用戶態(tài).select兩步都是阻塞的

  2. poll
    沒有1024限制，但依然是兩步IO都是阻塞的

  3. epoll
    沒有1024 限制，但第二步依賴阻塞，這也是java nio 所謂的同步非阻塞IO

  • signal driven I/O (SIGIO)


    signal-driven-io.jpg
  1. 異步 IO
    兩步都不阻塞

  • asynchronous I/O (the POSIX aio_functions)


    asynchronous-io.jpg

  • 比較


    compare-io.gif

Synchronous I/O versus Asynchronous I/O

POSIX defines these two terms as follows:

  • A synchronous I/O operation causes the requesting process to be blocked until that I/O operation completes.
  • An asynchronous I/O operation does not cause the requesting process to be blocked.

Using these definitions, the first four I/O models blocking, nonblocking, I/O multiplexing, and signal-driven I/O are all synchronous because the actual I/O operation (recvfrom) blocks the process. Only the asynchronous I/O model matches the asynchronous I/O definition.

requesting process 可以理解為用戶態(tài)當(dāng)前進(jìn)程

長鏈接VS短鏈接

TCP協(xié)議中有長連接和短連接之分。短連接在數(shù)據(jù)包發(fā)送完成后就會(huì)自己斷開，長連接在發(fā)包完畢后，會(huì)在一定的時(shí)間內(nèi)保持連接，即我們通常所說的Keepalive（存活定時(shí)器）功能。

默認(rèn)的Keepalive超時(shí)需要7,200,000 milliseconds，即2小時(shí)，探測(cè)次數(shù)為5次。它的功效和用戶自己實(shí)現(xiàn)的心跳機(jī)制是一樣的。開啟Keepalive功能需要消耗額外的寬帶和流量，盡管這微不足道，但在按流量計(jì)費(fèi)的環(huán)境下增加了費(fèi)用，另一方面，Keepalive設(shè)置不合理時(shí)可能會(huì)因?yàn)槎虝旱木W(wǎng)絡(luò)波動(dòng)而斷開健康的TCP連接。

image
  • 保活

keepalive并不是TCP規(guī)范的一部分。在Host Requirements RFC羅列有不使用它的三個(gè)理由：

（1）在短暫的故障期間，它們可能引起一個(gè)良好連接（good connection）被釋放（dropped），（2）它們消費(fèi)了不必要的寬帶，

（3）在以數(shù)據(jù)包計(jì)費(fèi)的互聯(lián)網(wǎng)上它們（額外）花費(fèi)金錢。

然而，需要在應(yīng)用層實(shí)現(xiàn)心跳檢測(cè)與鏈接重連

  1. 網(wǎng)絡(luò)單通

  2. 連接被防火墻Hand 住

  3. 長時(shí)間GC或者通信線程發(fā)生非預(yù)期異常

  4. 會(huì)導(dǎo)致連接不可用，而又無法及時(shí)發(fā)現(xiàn)。

應(yīng)用場(chǎng)景

  • 長鏈接
  1. 鏈接固定且頻繁
  • 長連接多用于操作頻繁，點(diǎn)對(duì)點(diǎn)的通訊，而且連接數(shù)不能太多情況。每個(gè)TCP連接都需要三步握手，這需要時(shí)間，如果每個(gè)操作都是先連接，再操作的話那么處理速度會(huì)降低很多，所以每個(gè)操作完后都不斷開，每次處理時(shí)直接發(fā)送數(shù)據(jù)包就OK了，不用建立TCP連接。例如：數(shù)據(jù)庫的連接用長連接， 如果用短連接頻繁的通信會(huì)造成socket錯(cuò)誤，而且頻繁的socket 創(chuàng)建也是對(duì)資源的浪費(fèi)。
  1. 推送業(yè)務(wù)

  • 短鏈接

    a. 隨機(jī)訪問

  • 而像WEB網(wǎng)站的http服務(wù)一般都用短鏈接，因?yàn)殚L連接對(duì)于服務(wù)端來說會(huì)耗費(fèi)一定的資源，而像WEB網(wǎng)站這么頻繁的成千上萬甚至上億客戶端的連接用短連接會(huì)更省一些資源，如果用長連接，而且同時(shí)有成千上萬的用戶，如果每個(gè)用戶都占用一個(gè)連接的話，資源占用太大。所以并發(fā)量大，但每個(gè)用戶無需頻繁操作情況下需用短連好。

實(shí)際場(chǎng)景分析(lettuce 客戶端)

redis 的lettuce客戶端

  • 驗(yàn)證客戶端的connection與tcp鏈接的關(guān)系，即與fd的關(guān)系，這里tcp物理連接與fd一一對(duì)應(yīng).


    TCP協(xié)議

由于tcp是網(wǎng)絡(luò)層協(xié)議，主要關(guān)系圖中的第三層，主要幾個(gè)字段source-->ip:port到destination ip:port

  • 驗(yàn)證代碼
    引自 lettuce官方example
/*
 * Copyright 2011-2018 the original author or authors.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */
package com.lambdaworks.examples;

import com.lambdaworks.redis.RedisClient;
import com.lambdaworks.redis.RedisURI;
import com.lambdaworks.redis.api.StatefulRedisConnection;
import com.lambdaworks.redis.api.sync.RedisCommands;

/**
 * @author Mark Paluch
 */
public class ReadWriteExample {
    public static void main(String[] args) {
        // Syntax: redis://[password@]host[:port][/databaseNumber]
        RedisClient redisClient = RedisClient.create(RedisURI.create("redis://localhost:6379/0"));
        StatefulRedisConnection<String, String> connection = redisClient.connect();
//創(chuàng)建10個(gè)connection
        for (int i=0;i<10;i++) {
            redisClient.connect();
        }
        System.out.println("Connected to Redis");
        RedisCommands<String, String> sync = connection.sync();
        sync.set("foo", "bar");
        String value = sync.get("foo");
        System.out.println(value);
        connection.close();
        redisClient.shutdown();
    }
}

redis-client 監(jiān)控結(jié)果
10個(gè)tcp鏈接對(duì)于10個(gè)fd

localhost:0>client list
"id=220 addr=127.0.0.1:62381 fd=13 name= age=42 idle=42 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=NULL
id=221 addr=127.0.0.1:62382 fd=12 name= age=42 idle=42 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=NULL
id=222 addr=127.0.0.1:62383 fd=11 name= age=42 idle=42 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=NULL
id=223 addr=127.0.0.1:62384 fd=18 name= age=42 idle=42 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=NULL
id=224 addr=127.0.0.1:62385 fd=14 name= age=42 idle=42 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=NULL
id=225 addr=127.0.0.1:62386 fd=8 name= age=42 idle=42 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=NULL
id=226 addr=127.0.0.1:62387 fd=15 name= age=42 idle=42 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=NULL
id=227 addr=127.0.0.1:62388 fd=9 name= age=42 idle=42 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=NULL
id=36 addr=127.0.0.1:57381 fd=16 name= age=18865 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client
id=217 addr=127.0.0.1:62378 fd=20 name= age=42 idle=42 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=NULL
id=218 addr=127.0.0.1:62379 fd=10 name= age=42 idle=42 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=NULL
id=219 addr=127.0.0.1:62380 fd=19 name= age=42 idle=42 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=NULL
"
localhost:0>

AbstractRedisClient相關(guān)netty代碼

{

        Bootstrap redisBootstrap = new Bootstrap();
        redisBootstrap.option(ChannelOption.WRITE_BUFFER_HIGH_WATER_MARK, 32 * 1024);
        redisBootstrap.option(ChannelOption.WRITE_BUFFER_LOW_WATER_MARK, 8 * 1024);
        redisBootstrap.option(ChannelOption.ALLOCATOR, BUF_ALLOCATOR);

        SocketOptions socketOptions = getOptions().getSocketOptions();

        redisBootstrap.option(ChannelOption.CONNECT_TIMEOUT_MILLIS,
                (int) socketOptions.getConnectTimeoutUnit().toMillis(socketOptions.getConnectTimeout()));

        if (LettuceStrings.isEmpty(redisURI.getSocket())) {
            redisBootstrap.option(ChannelOption.SO_KEEPALIVE, socketOptions.isKeepAlive());
            redisBootstrap.option(ChannelOption.TCP_NODELAY, socketOptions.isTcpNoDelay());
        }

        connectionBuilder.timeout(redisURI.getTimeout(), redisURI.getUnit());
        connectionBuilder.password(redisURI.getPassword());

        connectionBuilder.bootstrap(redisBootstrap);
        connectionBuilder.channelGroup(channels).connectionEvents(connectionEvents).timer(timer);
        connectionBuilder.commandHandler(handler).socketAddressSupplier(socketAddressSupplier).connection(connection);
        connectionBuilder.workerPool(genericWorkerPool);
    }

netty 客戶端的chnnel 創(chuàng)建

/**
     * Connect and initialize a channel from {@link ConnectionBuilder}.
     *
     * @param connectionBuilder must not be {@literal null}.
     * @return the {@link ConnectionFuture} to synchronize the connection process.
     * @since 4.4
     */
    @SuppressWarnings("unchecked")
    protected <K, V, T extends RedisChannelHandler<K, V>> ConnectionFuture<T> initializeChannelAsync(
            ConnectionBuilder connectionBuilder) {

        SocketAddress redisAddress = connectionBuilder.socketAddress();

        if (clientResources.eventExecutorGroup().isShuttingDown()) {
            throw new IllegalStateException("Cannot connect, Event executor group is terminated.");
        }

        logger.debug("Connecting to Redis at {}", redisAddress);

        CompletableFuture<Channel> channelReadyFuture = new CompletableFuture<>();
        Bootstrap redisBootstrap = connectionBuilder.bootstrap();

        RedisChannelInitializer initializer = connectionBuilder.build();
        redisBootstrap.handler(initializer);

        clientResources.nettyCustomizer().afterBootstrapInitialized(redisBootstrap);
        CompletableFuture<Boolean> initFuture = initializer.channelInitialized();
//物理TCP鏈接創(chuàng)建
        ChannelFuture connectFuture = redisBootstrap.connect(redisAddress);

        connectFuture.addListener(future -> {

            if (!future.isSuccess()) {

                logger.debug("Connecting to Redis at {}: {}", redisAddress, future.cause());
                connectionBuilder.commandHandler().initialState();
                channelReadyFuture.completeExceptionally(future.cause());
                return;
            }

            initFuture.whenComplete((success, throwable) -> {

                if (throwable == null) {
                    logger.debug("Connecting to Redis at {}: Success", redisAddress);
                    RedisChannelHandler<?, ?> connection = connectionBuilder.connection();
                    connection.registerCloseables(closeableResources, connection);
                    channelReadyFuture.complete(connectFuture.channel());
                    return;
                }

                logger.debug("Connecting to Redis at {}, initialization: {}", redisAddress, throwable);
                connectionBuilder.commandHandler().initialState();
                Throwable failure;

                if (throwable instanceof RedisConnectionException) {
                    failure = throwable;
                } else if (throwable instanceof TimeoutException) {
                    failure = new RedisConnectionException("Could not initialize channel within "
                            + connectionBuilder.getTimeout() + " " + connectionBuilder.getTimeUnit(), throwable);
                } else {
                    failure = throwable;
                }
                channelReadyFuture.completeExceptionally(failure);

                CompletableFuture<Boolean> response = new CompletableFuture<>();
                response.completeExceptionally(failure);

            });
        });

        return new DefaultConnectionFuture<>(redisAddress, channelReadyFuture.thenApply(channel -> (T) connectionBuilder
                .connection()));
    }

由代碼和監(jiān)控可確認(rèn)，luttuce redis 的connection對(duì)netty的channel一一對(duì)應(yīng)，同時(shí)服務(wù)器會(huì)一一創(chuàng)建tcp鏈接?。?code>這里強(qiáng)調(diào)一下是lettuce的redis 客戶端，而spring的封裝并非如此）

Spring Boot RedisTemplate

由于本地redis 這里的demo未使用集群模式，不影響測(cè)試效果

  • 配置文件
#spring.redis.cluster.nodes= 192.168.2.10:9000,192.168.2.14:9001,192.168.2.13:9000
#spring.redis.cluster.max-redirects=3
spring.redis.host=127.0.0.1
spring.redis.port=6379
spring.redis.timeout=5000ms

# Lettuce
# 連接池最大連接數(shù)（使用負(fù)值表示沒有限制）
spring.redis.lettuce.pool.max-active=8
# 連接池最大阻塞等待時(shí)間（使用負(fù)值表示沒有限制）
spring.redis.lettuce.pool.max-wait=1ms
# 連接池中的最大空閑連接
spring.redis.lettuce.pool.max-idle=10
# 連接池中的最小空閑連接
spring.redis.lettuce.pool.min-idle=8
# 關(guān)閉超時(shí)時(shí)間
spring.redis.lettuce.shutdown-timeout=100ms
#驅(qū)逐時(shí)間 初始化延遲時(shí)間 默認(rèn)-1
#if (delay > 0L) 必須>時(shí)才初始化
(這句很重要，這個(gè)參數(shù)默認(rèn)為-1,不>0L則驅(qū)逐任務(wù)不會(huì)生成，池中的idel max 等參數(shù)等于沒配置，不會(huì)生效。第二，如果是默認(rèn)配置，即使生效也不會(huì)讀池中鏈接，更浪費(fèi)資源?。?！代碼見下邊引用)
#spring.redis.lettuce.pool.time-between-eviction-runs=1s

引用驅(qū)逐器代碼
BaseGenericObjectPool

final void startEvictor(long delay) {
        Object var3 = this.evictionLock;
        synchronized(this.evictionLock) {
            EvictionTimer.cancel(this.evictor, this.evictorShutdownTimeoutMillis, TimeUnit.MILLISECONDS);
            this.evictor = null;
            this.evictionIterator = null;
            if (delay > 0L) {
                this.evictor = new BaseGenericObjectPool.Evictor();
                EvictionTimer.schedule(this.evictor, delay, delay);
            }

        }
    }
  • 測(cè)試代碼
package com.sparrow.spring.boot;

import com.sparrow.spring.Application;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.data.redis.connection.RedisConnection;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.data.redis.core.types.RedisClientInfo;
import org.springframework.test.context.junit4.SpringRunner;

import java.io.IOException;
import java.util.ArrayList;
import java.util.List;

@RunWith(SpringRunner.class)
@SpringBootTest(classes = {Application.class})
public class RedisConnectionTest {
    @Autowired
    private RedisTemplate redisTemplate;
    @Test
    public void test() throws IOException {
        List<RedisClientInfo> redisClientInfos = redisTemplate.getClientList();
        List<RedisConnection> redisConnections = new ArrayList<>();
//模擬多線程訪問場(chǎng)景，如果按lettuce 的邏輯，這里應(yīng)該每個(gè)鏈接都會(huì)對(duì)應(yīng)一個(gè)socket 鏈接?
        for (int i = 0; i < 200; i++) {
            new Thread(new Runnable() {
                @Override
                public void run() {
                    while (true) {
                        redisTemplate.opsForValue().get("a" + System.currentTimeMillis());
                    }
                }
            }).start();
        }
        System.in.read();
    }
}
  • 執(zhí)行后的redis client list結(jié)果
    只有兩條鏈接(fd),其中一條為當(dāng)前client
localhost:0>client list
"id=36 addr=127.0.0.1:57381 fd=16 name= age=20394 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client
id=250 addr=127.0.0.1:63325 fd=14 name= age=18 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=get
"
localhost:0>
  • 可見結(jié)果，spring boot redistemplate 不管開多少個(gè)線程，都只有一個(gè)鏈接，為什么？

摘自LettuceConnectionFactory官方代碼注釋
This factory creates a new @link LettuceConnection on each call to @link #getConnection(). Multiple @link LettuceConnection's share a single thread-safe native connection by default.
當(dāng)我們調(diào)用getConnection()方法獲取鏈接時(shí)，多個(gè)LettuceConnection會(huì)共享一個(gè)線程安全的 native connection(默認(rèn)情況，意思就是說可以重寫，可以改)

/**
 * Connection factory creating <a >Lettuce</a>-based connections.
 * <p>
 * This factory creates a new {@link LettuceConnection} on each call to {@link #getConnection()}. Multiple
 * {@link LettuceConnection}s share a single thread-safe native connection by default.
當(dāng)我們調(diào)用getConnection()方法獲取鏈接時(shí)，多個(gè)LettuceConnection會(huì)共享一個(gè)線程安全的`native connection`
 * <p>
 * The shared native connection is never closed by {@link LettuceConnection}, therefore it is not validated by default
 * on {@link #getConnection()}. Use {@link #setValidateConnection(boolean)} to change this behavior if necessary. Inject
 * a {@link Pool} to pool dedicated connections. If shareNativeConnection is true, the pool will be used to select a
 * connection for blocking and tx operations only, which should not share a connection. If native connection sharing is
 * disabled, the selected connection will be used for all operations.
 * <p>
 * ....
 */
public class LettuceConnectionFactory
        implements InitializingBean, DisposableBean, RedisConnectionFactory, ReactiveRedisConnectionFactory {

總結(jié)

  • redis 長鏈接情況下，物理鏈接非常少，甚至可以共享一個(gè)，而并不影響并發(fā)效果，線上壓測(cè)結(jié)果 qps 40000左右，CPU不到2%，當(dāng)然測(cè)試效果與實(shí)際key有關(guān)，但5W左右是沒有問題的
  • redis 的client list 命令和info clients 命令可以查看當(dāng)前服務(wù)器的tcp鏈接數(shù)
  • tcp 物理鏈接與netty的channel一一對(duì)應(yīng),可以簡單理解netty的channel 是對(duì)tcp鏈接的封裝，里邊實(shí)現(xiàn)了很多事。具體可以參考，李林峰老師的《netty權(quán)威指南》
  • channel可以被多線程共享
  • tcp鏈接與fd一一對(duì)應(yīng)，受內(nèi)核的最大fd數(shù)限制，但非1024限制，該值可以修改，與內(nèi)存有關(guān)，理論上不受限。
最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡書系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容