2. 程式人生 > >最近學習了Http連線池

最近學習了Http連線池

阿新 • • 發佈：2019-06-10

起因

6.1大促值班發現的一個問題，一個rpc介面在0~2點使用者下單高峰的時候表現rt高（超過1s，實際上針對性優化過的介面rt超過這個值也是有問題的，通常rpc接口裡面即使邏輯複雜，300ms應該也搞定了），可以理解，但是在4~5點的時候介面的tps已經不高了，耗時依然在600ms~700ms之間就不能理解了。

查了一下，裡面有段呼叫支付寶http介面的邏輯，但是每次都new一個HttpClient出來發起呼叫，呼叫時長大概在300ms+，所以導致即使在非高峰期介面耗時依然非常高。

問題不難，寫篇文章系統性地對這塊進行一下總結。

 

用不用執行緒池的差別

本文主要寫的是“池”對於系統性能的影響，因此開始連線池之前，可以以執行緒池的例子作為一個引子開始本文，簡單看下使不使用池的一個效果差別，程式碼如下：

/**
 * 執行緒池測試
 * 
 * @author 五月的倉頡https://www.cnblogs.com/xrq730/p/10963689.html
 */
public class ThreadPoolTest {

    private static final AtomicInteger FINISH_COUNT = new AtomicInteger(0);
    
    private static final AtomicLong COST = new AtomicLong(0);
    
    private static final Integer INCREASE_COUNT = 1000000;
    
    private static final Integer TASK_COUNT = 1000;
    
    @Test
    public void testRunWithoutThreadPool() {
        List<Thread> tList = new ArrayList<Thread>(TASK_COUNT);
        
        for (int i = 0; i < TASK_COUNT; i++) {
            tList.add(new Thread(new IncreaseThread()));
        }
        
        for (Thread t : tList) {
            t.start();
        }
        
        for (;;);
    }
    
    @Test
    public void testRunWithThreadPool() {
        ThreadPoolExecutor executor = new ThreadPoolExecutor(100, 100, 0, TimeUnit.MILLISECONDS, 
                new LinkedBlockingQueue<>());
        
        for (int i = 0; i < TASK_COUNT; i++) {
            executor.submit(new IncreaseThread());
        }
        
        for (;;);
    }
    
    private class IncreaseThread implements Runnable {
        
        @Override
        public void run() {
            long startTime = System.currentTimeMillis();
            
            AtomicInteger counter = new AtomicInteger(0);
            for (int i = 0; i < INCREASE_COUNT; i++) {
                counter.incrementAndGet();
            }
            // 累加執行時間
            COST.addAndGet(System.currentTimeMillis() - startTime);
            if (FINISH_COUNT.incrementAndGet() == TASK_COUNT) {
                System.out.println("cost: " + COST.get() + "ms");
            }
        }
        
    }
    
}

邏輯比較簡單：1000個任務，每個任務做的事情都是使用AtomicInteger從0累加到100W。

每個Test方法執行12次，排除一個最低的和一個最高的，對中間的10次取一個平均數，當不使用執行緒池的時候，任務總耗時為16693s；而當使用執行緒池的時候，任務平均執行時間為1073s，超過15倍，差別是非常明顯的。

究其原因比較簡單，相信大家都知道，主要是兩點：

  • 減少執行緒建立、銷燬的開銷
  • 控制執行緒的數量，避免來一個任務建立一個執行緒，最終記憶體的暴增甚至耗盡

當然，前面也說了，這只是一個引子引出本文，當我們使用HTTP連線池的時候，任務處理效率提升的原因不止於此。

 

用哪個httpclient

容易搞錯的一個點，大家特別注意一下。HttpClient可以搜到兩個類似的工具包，一個是commons-httpclient：

<dependency>
    <groupId>commons-httpclient</groupId>
    <artifactId>commons-httpclient</artifactId>
    <version>3.1</version>
</dependency>

一個是httpclient：

<dependency>
    <groupId>org.apache.httpcomponents</groupId>
    <artifactId>httpclient</artifactId>
    <version>4.5.8</version>
</dependency>

選第二個用，不要搞錯了，他們的區別在stackoverflow上有解答：

即commons-httpclient是一個HttpClient老版本的專案，到3.1版本為止，此後專案被廢棄不再更新（3.1版本，07年8.21釋出），它已經被歸入了一個更大的Apache HttpComponents專案中，這個專案版本號是HttpClient 4.x（4.5.8最新版本，19年5.30釋出）。

隨著不斷更新，HttpClient底層針對程式碼細節、效能上都有持續的優化，因此切記選擇org.apache.httpcomponents這個groupId。

 

不使用連線池的執行效果

有了工具類，就可以寫程式碼來驗證一下了。首先定義一個測試基類，等下使用連線池的程式碼演示的時候可以共用：

/**
 * 連線池基類
 * 
 * @author 五月的倉頡https://www.cnblogs.com/xrq730/p/10963689.html
 */
public class BaseHttpClientTest {

    protected static final int REQUEST_COUNT = 5;

    protected static final String SEPERATOR = "   ";
    
    protected static final AtomicInteger NOW_COUNT = new AtomicInteger(0);
    
    protected static final StringBuilder EVERY_REQ_COST = new StringBuilder(200);
    
    /**
     * 獲取待執行的執行緒
     */
    protected List<Thread> getRunThreads(Runnable runnable) {
        List<Thread> tList = new ArrayList<Thread>(REQUEST_COUNT);
        
        for (int i = 0; i < REQUEST_COUNT; i++) {
            tList.add(new Thread(runnable));
        }
        
        return tList;
    }
    
    /**
     * 啟動所有執行緒
     */
    protected void startUpAllThreads(List<Thread> tList) {
        for (Thread t : tList) {
            t.start();
            // 這裡需要加一點延遲，保證請求按順序發出去
            try {
                Thread.sleep(300);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }
    
    protected synchronized void addCost(long cost) {
        EVERY_REQ_COST.append(cost);
        EVERY_REQ_COST.append("ms");
        EVERY_REQ_COST.append(SEPERATOR);
    }
    
}

接著看一下測試程式碼：

/**
 * 不使用連線池測試
 * 
 * @author 五月的倉頡https://www.cnblogs.com/xrq730/p/10963689.html
 */
public class HttpClientWithoutPoolTest extends BaseHttpClientTest {

    @Test
    public void test() throws Exception {
        startUpAllThreads(getRunThreads(new HttpThread()));
        // 等待執行緒執行
        for (;;);
    }
    
    private class HttpThread implements Runnable {

        @Override
        public void run() {
            /**
             * HttpClient是執行緒安全的，因此HttpClient正常使用應當做成全域性變數，但是一旦全域性共用一個，HttpClient內部構建的時候會new一個連線池
             * 出來，這樣就體現不出使用連線池的效果，因此這裡每次new一個HttpClient，保證每次都不通過連線池請求對端
             */
            CloseableHttpClient httpClient = HttpClients.custom().build();
            HttpGet httpGet = new HttpGet("https://www.baidu.com/");
            
            long startTime = System.currentTimeMillis();
            try {
                CloseableHttpResponse response = httpClient.execute(httpGet);
                if (response != null) {
                    response.close();
                }
            } catch (Exception e) {
                e.printStackTrace();
            } finally {
                addCost(System.currentTimeMillis() - startTime);
                
                if (NOW_COUNT.incrementAndGet() == REQUEST_COUNT) {
                    System.out.println(EVERY_REQ_COST.toString());
                }
            }
        }
        
    }
    
}

注意這裡如註釋所說，HttpClient是執行緒安全的，但是一旦做成全域性的就失去了測試效果，因為HttpClient在初始化的時候預設會new一個連線池出來。

看一下程式碼執行效果：

324ms   324ms   220ms   324ms   324ms

每個請求幾乎都是獨立的，所以執行時間都在200ms以上，接著我們看一下使用連線池的效果。

 

使用連線池的執行結果

BaseHttpClientTest這個類保持不變，寫一個使用連線池的測試類：

/**
 * 使用連線池測試
 * 
 * @author 五月的倉頡https://www.cnblogs.com/xrq730/p/10963689.html
 */
public class HttpclientWithPoolTest extends BaseHttpClientTest {

    private CloseableHttpClient httpClient = null;
    
    @Before
    public void before() {
        initHttpClient();
    }
    
    @Test
    public void test() throws Exception {
        startUpAllThreads(getRunThreads(new HttpThread()));
        // 等待執行緒執行
        for (;;);
    }
    
    private class HttpThread implements Runnable {

        @Override
        public void run() {
            HttpGet httpGet = new HttpGet("https://www.baidu.com/");
            // 長連線標識，不加也沒事，HTTP1.1預設都是Connection: keep-alive的
            httpGet.addHeader("Connection", "keep-alive");
            
            long startTime = System.currentTimeMillis();
            try {
                CloseableHttpResponse response = httpClient.execute(httpGet);
                if (response != null) {
                    response.close();
                }
            } catch (Exception e) {
                e.printStackTrace();
            } finally {
                addCost(System.currentTimeMillis() - startTime);
                
                if (NOW_COUNT.incrementAndGet() == REQUEST_COUNT) {
                    System.out.println(EVERY_REQ_COST.toString());
                }
            }
        }
        
    }
    
    private void initHttpClient() {
        PoolingHttpClientConnectionManager connectionManager = new PoolingHttpClientConnectionManager();
        // 總連線池數量
        connectionManager.setMaxTotal(1);
        // 可為每個域名設定單獨的連線池數量
        connectionManager.setMaxPerRoute(new HttpRoute(new HttpHost("www.baidu.com")), 1);
        // setConnectTimeout表示設定建立連線的超時時間
        // setConnectionRequestTimeout表示從連線池中拿連線的等待超時時間
        // setSocketTimeout表示發出請求後等待對端應答的超時時間
        RequestConfig requestConfig = RequestConfig.custom().setConnectTimeout(1000).setConnectionRequestTimeout(2000)
                .setSocketTimeout(3000).build();
        // 重試處理器，StandardHttpRequestRetryHandler這個是官方提供的，看了下感覺比較挫，很多錯誤不能重試，可自己實現HttpRequestRetryHandler介面去做
        HttpRequestRetryHandler retryHandler = new StandardHttpRequestRetryHandler();
        
        httpClient = HttpClients.custom().setConnectionManager(connectionManager).setDefaultRequestConfig(requestConfig)
                .setRetryHandler(retryHandler).build();
        
        // 服務端假設關閉了連線，對客戶端是不透明的，HttpClient為了緩解這一問題，在某個連線使用前會檢測這個連線是否過時，如果過時則連線失效，但是這種做法會為每個請求
        // 增加一定額外開銷，因此有一個定時任務專門回收長時間不活動而被判定為失效的連線，可以某種程度上解決這個問題
        Timer timer = new Timer();
        timer.schedule(new TimerTask() {
            @Override
            public void run() {
                try {
                    // 關閉失效連線並從連線池中移除
                    connectionManager.closeExpiredConnections();
                    // 關閉30秒鐘內不活動的連線並從連線池中移除，空閒時間從交還給連線管理器時開始
                    connectionManager.closeIdleConnections(20, TimeUnit.SECONDS);
                } catch (Throwable t) {
                    t.printStackTrace();
                }
            }
        }, 0 , 1000 * 5);
    }
    
}

這個類詳細地演示了HttpClient的用法，相關注意點都寫了註釋，就不講了。

和上面一樣，看一下程式碼執行效果：

309ms   83ms   57ms   53ms   46ms

看到除開第一次呼叫的309ms以外，後續四次呼叫整體執行時間大大提升，這就是使用了連線池的好處，接著，就探究一下使用連線池提升整體效能的原因。

 

繞不開的長短連線

說起HTTP，必然繞不開的一個話題就是長短連線，這個話題之前的文章已經寫了好多次了，這裡再寫一次。

我們知道，從客戶端發起一個HTTP請求到服務端響應HTTP請求之間，大致有以下幾個步驟：

HTTP1.0最早在網頁中使用是1996年，那個時候只是使用一些較為簡單的網頁和網路的請求，每次請求都需要建立一個單獨的連線，上一次和下一次請求完全分離。這種做法，即使每次的請求量都很小，但是客戶端和服務端每次建立TCP連線和關閉TCP連線都是相對比較費時的過程，嚴重影響客戶端和服務端的效能。

基於以上的問題，HTTP1.1在1999年廣泛應用於現在的各大瀏覽器網路請求中，同時HTTP1.1也是當前使用最為廣泛的HTTP協議（2015年誕生了HTTP2，但是還未大規模應用），這裡不詳細對比HTTP1.1針對HTTP1.0改進了什麼，只是在連線這塊，HTTP1.1支援在一個TCP連線上傳送多個HTTP請求和響應，減少了建立和關閉連線的消耗延遲，一定程度上彌補了HTTP1.0每次請求都要建立連線的缺點，這就是長連線，HTTP1.1預設使用長連線。

那麼，長連線是如何工作的呢？首先，我們要明確一下，長短連線是通訊層（TCP）的概念，HTTP是應用層協議，它只能說告訴通訊層我打算一段時間內複用TCP通道而沒有自己去建立、釋放TCP通道的能力。那麼HTTP是如何告訴通訊層複用TCP通道的呢？看下圖：

分為以下幾個步驟：

  • 客戶端傳送一個Connection: keep-alive的header，表示需要保持連線
  • 客戶端可以順帶Keep-Alive: timeout=5,max=100這個header給服務端，表示tcp連線最多保持5秒，長連線接受100次請求就斷開，不過瀏覽器看了一些請求貌似沒看到帶這個引數的
  • 服務端必須能識別Connection: keep-alive這個header，並且通過Response Header帶同樣的Connection: keep-alive，告訴客戶端我可以保持連線
  • 客戶端和服務端之間通過保持的通道收發資料
  • 最後一次請求資料，客戶端帶Connection：close這個header，表示連線關閉

至此在一個通道上交換資料的過程結束，在預設的情況下：

  • 長連線的請求數量限定是最多連續傳送100個請求，超過限制即關閉這條連線
  • 長連線連續兩個請求之間的超時時間是15秒（存在1~2秒誤差），超時後會關閉TCP連線，因此使用長連線應當儘量保持在13秒之內傳送一個請求

這些的限制都是在重用長連線與長連線過多之間做的一個折衷，因為長連線雖好，但是長時間的TCP連線容易導致系統資源無效佔用，浪費系統資源。

最後這個地方多說一句http的keep-alive和tcp的keep-alive的區別，一個經常講的問題，順便記錄一下：

  • http的keep-alive是為了複用已有連線
  • tcp的keep-alive是為了保活，即保證對端還存活，不然對端已經不在了我這邊還佔著和對端的這個連線，浪費伺服器資源，做法是隔一段時間傳送一個心跳包到對端伺服器，一旦長時間沒有接收到應答，就主動關閉連線

 

效能提升的原因

通過前面的分析，很顯而易見的，使用HTTP連線池提升效能最重要的原因就是省去了大量連線建立與釋放的時間，除此之外還想說一點。

TCP建立連線的時候有如下流程：

如圖所示，這裡面有兩個佇列，分別為syns queue（半連線佇列）與accept queue（全連線佇列），這裡面的流程就不細講了，之前我有文章https://www.cnblogs.com/xrq730/p/6910719.html專門寫過這個話題。

一旦不使用長連線而每次連線都重新握手的話，佇列一滿服務端將會發送一個ECONNREFUSED錯誤資訊給到客戶端，相當於這次請求就失效了，即使不失效，後來的請求需要等待前面的請求處理，排隊也會增加響應的時間。

By the way，基於上面的分析，不僅僅是HTTP，所有應用層協議，例如資料庫有資料庫連線池、hsf提供了hsf介面連線池，使用連線池的方式對於介面效能都是有非常大的提升的，都是同一個道理。

 

TLS層的優化

上面講的都是針對應用層協議使用連線池提升效能的原因，但是對於HTTP請求，我們知道目前大多數網站都執行在HTTPS協議之上，即在通訊層和應用層之間多了一層TLS：

通過TLS層對報文進行了加密，保證資料安全，其實在HTTPS這個層面上，使用連線池對效能有提升，TLS層的優化也是一個非常重要的原因。

HTTPS原理不細講了，反正大致上就是一個證書交換-->服務端加密-->客戶端解密的過程，整個過程中反覆地客戶端+服務端交換資料是一個耗時的過程，且資料的加解密是一個計算密集型的操作消耗CPU資源，因此如果相同的請求能省去加解密這一套就能在HTTPS協議下對整個效能有很大提升了，實際上這種優化是有的，這裡用到了一種會話複用的技術。

TLS的握手由客戶端傳送Client Hello訊息開始，服務端返回Server Hello結束，整個流程中提供了2種不同的會話複用機制，這個地方就簡單看一下，知道有這麼一回事：

  • session id會話複用----對於已建立的TLS會話，使用session id為key（來自第一次請求的Server Hello中的session id），主金鑰為value組成一對鍵值對儲存在服務端和客戶端的本地。當第二次握手時，客戶端如果想複用會話，則發起的Client Hello中帶上session id，服務端收到這個session id檢查本地是否存在，有則允許會話複用，進行後續操作
  • session ticket會話複用----一個session ticket是一個加密的資料blob，其中包含需要重用的TLS連線資訊如session key等，它一般使用ticket key加密，因為ticket key服務端也知道，在初始化握手中服務端傳送一個session ticket到客戶端並存儲到客戶端本地，當會話重用時，客戶端傳送session ticket到服務端，服務端解密成功即可複用會話

session id的方式缺點是比較明顯的，主要原因是負載均衡中，多機之間不同步session，如果兩次請求不落在同一臺機器上就無法找到匹配資訊，另外服務端儲存大量的session id又需要消耗很多資源，而session ticket是比較好解決這個問題的，但是最終使用的是哪種方式還是有瀏覽器決定。關於session ticket，在網上找了一張圖，展示的是客戶端第二次發起請求，攜帶session ticket的過程：

一個session ticket超時時間預設為300s，TLS層的證書交換+非對稱加密作為效能消耗大戶，通過會話複用技術可以大大提升效能。

 

使用連線池的注意點

使用連線池，切記每個任務的執行時間不要太長。

因為HTTP請求也好、資料庫請求也好、hsf請求也好都是有超時時間的，比如連線池中有10個執行緒，併發來了100個請求，一旦任務執行時間非常長，連線都被先來的10個任務佔著，後面90個請求遲遲得不到連線去處理，就會導致這次的請求響應慢甚至超時。

當然每個任務的業務不一樣，但是按照我的經驗，儘量把任務的執行時間控制在50ms最多100ms之內，如果超出的，可以考慮以下三種方案：

  • 優化任務執行邏輯，比如引入快取
  • 適當增大連線池中的連線數量
  • 任務拆分，將任務拆分為若干小任務

 

連線池中的連線數量如何設定

有些朋友可能會問，我知道需要使用連線池，那麼一般連線池數量設定為多少比較合適？有沒有經驗值呢？首先我們需要明確一個點，連線池中的連線數量太多不好、太少也不好：

  • 比如qps=100，因為上游請求速率不可能是恆定不變的100個請求/秒，可能前1秒900個請求，後9秒100個請求，平均下來qps=100，當連線數太多的時候，可能出現的場景是高流量下建立連線--->低流量下釋放部分連線--->高流量下重新建立連線的情況，相當於雖然使用了連線池，但是因為流量不均勻反覆建立連線、釋放連結
  • 執行緒數太少當然也是不好的，任務多而連線少，導致很多工一直在排隊等待前面的執行完才可以拿到連線去處理，降低了處理速度

那針對連線池中的連線數量如何設定的這個問題，答案是沒有固定的，但是可以通過估算得到一個預估值。

首先開發同學對於一個任務每天的呼叫量心中需要有數，假設一天1000W次好了，線上有10臺伺服器，那麼平均到每臺伺服器每天的呼叫量在100W，100W平均到1天的86400秒，每秒的呼叫量1000000 / 86400 ≈ 11.574次，根據介面的一個平均響應時長適當加一點餘量，差不多設定在15~30比較合適，根據線上執行的實際情況再做調整。

&n

相關推薦

最近學習了Http連線池

起因 6.1大促值班發現的一個問題，一個rpc介面在0~2點使用者下單高峰的時候表現rt高（超過1s，實際上針對性優化過的介面rt超過這個值也是有問題的，通常rpc接口裡面即使邏輯複雜，300ms應該也搞定了），可以理解，但是在4~5點的時候介面的tps已經不高了，耗時依然在600ms~700ms之間就不能

HttpClient高併發下效能優化-http連線池

首先,明確兩點: 1.http連線池不是萬能的,過多的長連線會佔用伺服器資源,導致其他服務受阻 2.http連線池只適用於請求是經常訪問同一主機(或同一個介面)的情況下 3.併發數不高的情況下資源利用率低下 那麼,當你的業務符合上面3點,那麼你可以考慮使用http連線池來提高伺服器效能

當 HTTP 連線池遇上 KeepAlive 時

最近在使用netty作為http客戶端通過pool連線tomcat的時候，出現了很多Connection reset by peer 的IOException的異常。便對問題的根源做了細緻的調研。 1. 連接種類 一般連線主要分為長連線，短連線和http的keepalive連線

當 HTTP 連線池遇上 KeepAlive 時 http的keep-alive和tcp的keepalive區別

https://mp.weixin.qq.com/s?__biz=MzUzMTA2NTU2Ng==&mid=2247485891&idx=2&sn=82dd4786e38e23a10fa9210745c99130&chksm=fa497672cd3eff64fb06873ba9

JDBC學習05-DBCP連線池：下載和使用方法

一、DBCP連線池簡介 DBCP（DataBase Connection Pool）資料庫連線池，是java資料庫連線池的一種，由Apache開發，通過資料庫連線池，可以讓程式自動管理資料庫連線的釋放和斷開。 二、DBCP連線池的使用方法 0.下載 使用

spring boot 學習(四)Druid連線池的使用配置

spring boot下Druid連線池的使用配置 Druid介紹 Druid是一個JDBC元件，druid 是阿里開源在 github 上面的資料庫連線池,它包括三部分： * DruidDriver 代理Driver，能夠提供基於Filter－

最近學習了責任鏈模式

前言 來菜鳥這個大家庭10個月了，總得來說比較融入了環境，同時在忙碌的工作中也深感技術積累不夠，在優秀的人身邊工作必須更加花時間

最近學習了HBase

HBase是什麼 最近學習了HBase，正常來說寫這篇文章，應該從DB有什麼缺點，HBase如何彌補DB的缺點開始講會更有體感，但是本文這些暫時不講，只講HBase，把HBase相關原理和使用講清楚，後面有一篇文章會專門講DB與NoSql各自的優缺點以及使用場景。 HBase是谷歌Bigtable的開源版

最近學習了限流與RateLimiter

前言 分散式環境下應對高併發保證服務穩定幾招，按照個人理解，優先順序從高到低分別為快取、限流、降級、熔斷，每招都有它的作用，本文重點就講講限流這部分。 坦白講，其實上面的說法也不準確，因為服務降級、熔斷本身也是限流的一種，因為它們本質上也是阻斷了流量進來，但是本文希望大家可以把限流當做一個單純的名詞來理解

最近學習了JDK SPI

JDK SPI是什麼 最近工作中聽幾個同事說了好幾次SPI這個名詞，雖然和我沒關係，但是心裡默默想還是學習一下，不然下次和我說到SPI，連是什麼都不知道那就尷尬了。 所以SPI是什麼呢？SPI全稱Service Provider Interface，在Java中還是一個比較重要的概念，是Java提供的一套

Go元件學習——手寫連線池並沒有那麼簡單

1、背景 前段時間在看gorm，發現gorm是複用database/sql的連線池。 於是翻了下database/sql的資料庫連線池的程式碼實現，看完程式碼，好像也不是很複雜，但是總覺得理解不夠深刻，於是萌生了自己想寫個連線池的想法。（最後也驗證了，看原始碼的理解確實不夠深刻，一看就會，一做就跪） 2

最近學習了限流相關的演算法

最近測試team在測試過程中反饋部分介面需要做一定的限流措施，剛好我也回顧了下限流相關的演算法。常見限流相關的演算法有四種：計數器演算法, 滑動視窗演算法, 漏桶演算法, 令牌桶演算法 1.計數器演算法(固定視窗)  計數器演算法是使用計數器在週期內累加訪問次數，當達到設定的閾值時就會觸發限流策略。

MyBatis學習-使用Druid連線池將Maybatis整合到spring

[TOC] ## 前言 在[MyBatis學習-連線oracle實現CURD操作](https://www.cnblogs.com/Jack-Blog/p/13179382.html)實現了MyBatis基本配置與CRUD操作。但是每次都是手工建立SqlSessionFactory本篇將通過spring

Go元件學習——database/sql資料庫連線池你用對了嗎

1、案例 case1： maxOpenConns > 1 func fewConns() { db, _ := db.Open("mysql", "root:rootroot@/dqm?charset=utf8&parseTime=True&loc=Local") d

曹工雜談：花了兩天時間，寫了一個netty實現的http客戶端，支援同步轉非同步和連線池（1）--核心邏輯講解

# 背景 先說下寫這個的目的，其實是好奇，dubbo是怎麼實現同步轉非同步的，然後瞭解到，其依賴了請求中攜帶的請求id來完成這個連線複用；然後我又發現，redisson這個redis客戶端，底層也是用的netty，那就比較好奇了：netty是非同步的，上層是同步的，要拿結果的，同時呢，redis協議也不可能

學習經驗分享（最近聽了一節Java公開課）

要花 總結 tomcat8.0 避免 一個 地方 廣度 公開課 很好 最近聽了一節Java公開課，講的Tomcat8.0的，老師分享的學習方法很好， 時間和精力要用對地方 1.學習一個知識的廣度和深度，先學主要的主流的，不要學了很多不該學，沒必要學的東西 2.要花時間總結

資料庫連線池學習筆記（一）：原理介紹+常用連線池介紹

什麼是連線池 資料庫連線池負責分配、管理和釋放資料庫連線，它允許應用程式重複使用一個現有的資料庫連線，而不是再重新建立一個。 為什麼要使用連線池  資料庫連線是一種關鍵的有限的昂貴的資源，這一點在多使用者的網頁應用程式中體現得尤為突出。  一個數據庫連線物件均對應

事務 與 資料庫連線池【c3p0】 與 DBUtiles學習筆記

1.事務 開啟事務：start transaction; 回滾事務：rollback; 提交事務: commit; 關閉自動提交事務：setAutoCommit(false); 1.1事務的特性ACID【面試】 1.原子性【A】：事務包含的邏輯不可分割 一致性【C】：事務執行前後，資料完

java執行緒池和資料庫連線池[從學習到工作(二)]

背景：前段時間工作需要開發一個socket服務端，在接受到客戶端發過來的報文資訊後解析報文呼叫資料庫程式完成資料檔案的生成再拼湊結果報文反饋給客戶端。由於客戶數比較多，所以用執行緒池和資料庫連線池。        一.執行緒池   

python 學習筆記（十）： 資料庫連線池

#!/usr/bin/python # -*- coding: utf-8 -*- from __future__ import print_function import Queue import pymysql import logging LOG =