摘要：Kafka中的位移是個極其重要的概念，因為數據一致性、準確性是一個很重要的語義，我們都不希望消息重複消費或者丟失。而位移就是控制消費進度的大佬。本文就詳細聊聊kafka消費位移的那些事，包括：

概念剖析

kafka的兩種位移

關於位移（Offset），其實在kafka的世界里有兩種位移：

• 分區位移：生產者向分區寫入消息，每條消息在分區中的位置信息由一個叫offset的數據來表徵。假設一個生產者向一個空分區寫入了 10 條消息，那麼這 10 條消息的位移依次是 0、1、…、9；

• 消費位移：消費者需要記錄消費進度，即消費到了哪個分區的哪個位置上，這是消費者位移（Consumer Offset）。

注意，這和上面所說的消息在分區上的位移完全不是一個概念。上面的“位移”表徵的是分區內的消息位置，它是不變的，即一旦消息被成功寫入到一個分區上，它的位移值就是固定的了。而消費者位移則不同，它可能是隨時變化的，畢竟它是消費者消費進度的指示器。

消費位移

消費位移，記錄的是 Consumer 要消費的下一條消息的位移，切記，是下一條消息的位移！ 而不是目前最新消費消息的位移

假設一個分區中有 10 條消息，位移分別是 0 到 9。某個 Consumer 應用已消費了 5 條消息，這就說明該 Consumer 消費了位移為 0 到 4 的 5 條消息，此時 Consumer 的位移是 5，指向了下一條消息的位移。

至於為什麼要有消費位移，很好理解，當 Consumer 發生故障重啟之後，就能夠從 Kafka 中讀取之前提交的位移值，然後從相應的位移處繼續消費，從而避免整個消費過程重來一遍。就好像書籤一樣，需要書籤你才可以快速找到你上次讀書的位置。

那麼了解了位移是什麼以及它的重要性，我們自然而然會有一個疑問，kafka是怎麼記錄、怎麼保存、怎麼管理位移的呢？

位移的提交

Consumer 需要上報自己的位移數據，這個彙報過程被稱為位移提交。因為 Consumer 能夠同時消費多個分區的數據，所以位移的提交實際上是在分區粒度上進行的，即Consumer 需要為分配給它的每個分區提交各自的位移數據。

鑒於位移提交甚至是位移管理對 Consumer 端的巨大影響，KafkaConsumer API提供了多種提交位移的方法，每一種都有各自的用途，這些都是本文將要談到的方案。

void commitSync(Duration timeout);
void commitSync(Map<TopicPartition, OffsetAndMetadata> offsets);
void commitSync(final Map<TopicPartition, OffsetAndMetadata> offsets, final Duration timeout);
void commitAsync();
void commitAsync(OffsetCommitCallback callback);
void commitAsync(Map<TopicPartition, OffsetAndMetadata> offsets, OffsetCommitCallback callback);

先粗略的總結一下。位移提交分為自動提交和手動提交；而手動提交又分為同步提交和異步提交。

自動提交

當消費配置enable.auto.commit=true的時候代表自動提交位移。

自動提交位移是發生在什麼時候呢？auto.commit.interval.ms默認值是50000ms。即kafka每隔5s會幫你自動提交一次位移。自動位移提交的動作是在 poll（）方法的邏輯里完成的，在每次真正向服務端發起拉取請求之前會檢查是否可以進行位移提交，如果可以，那麼就會提交上一次輪詢的位移。假如消費數據量特別大，可以設置的短一點。

越簡單的東西功能越不足，自動提交位移省事的同時肯定會帶來一些問題。自動提交帶來重複消費和消息丟失的問題：

• 重複消費： 在默認情況下，Consumer 每 5 秒自動提交一次位移。現在，我們假設提交位移之後的 3 秒發生了 Rebalance 操作。在 Rebalance 之後，所有 Consumer 從上一次提交的位移處繼續消費，但該位移已經是 3 秒前的位移數據了，故在 Rebalance 發生前 3 秒消費的所有數據都要重新再消費一次。雖然你能夠通過減少 auto.commit.interval.ms 的值來提高提交頻率，但這麼做只能縮小重複消費的時間窗口，不可能完全消除它。這是自動提交機制的一個缺陷。

• 消息丟失： 假設拉取了100條消息，正在處理第50條消息的時候，到達了自動提交窗口期，自動提交線程將拉取到的每個分區的最大消息位移進行提交，如果此時消費服務掛掉，消息並未處理結束，但卻提交了最大位移，下次重啟就從100條那消費，即發生了50-100條的消息丟失。

手動提交

當消費配置enable.auto.commit=false的時候代表手動提交位移。用戶必須在適當的時機（一般是處理完業務邏輯后），手動的調用相關api方法提交位移。比如在下面的案例中，我需要確認我的業務邏輯返回true之後再手動提交位移

 while (true) {
     try {
         ConsumerRecords<String, String> consumerRecords = consumer.poll(Duration.ofMinutes(KafkaConfig.pollTimeoutOfMinutes));
         if (!consumerRecords.isEmpty()) {
             for (ConsumerRecord<String, String> record : consumerRecords) {
                 KafkaMessage kafkaMessage = JSON.parseObject(record.value(), KafkaMessage.class);
                 // 處理業務
                 boolean handleResult = handle(kafkaMessage);
                 if (handleResult) {
                     log.info(" handle success, kafkaMessage={}" ,kafkaMessage);
                 } else {
                     log.info(" handle failed, kafkaMessage={}" ,kafkaMessage);
                 }
             }
             // 手動提交offset
             consumer.commitSync(Duration.ofMinutes(KafkaConfig.pollTimeoutOfMinutes));
        
         } 
     } catch (Exception e) {
         log.info("kafka consume error." ,e);
     }
 }

手動提交明顯能解決消息丟失的問題，因為你是處理完業務邏輯后再提交的，假如此時消費服務掛掉，消息並未處理結束，那麼重啟的時候還會重新消費。

但是對於業務層面的失敗導致消息未消費成功，是無法處理的。因為業務層的邏輯千變萬化、比如格式不正確，你叫Kafka消費端程序怎麼去處理？應該要業務層面自己處理，記錄失敗日誌做好監控等。

但是手動提交不能解決消息重複的問題，也很好理解，假如消費0-100條消息，50條時掛了，重啟後由於沒有提交這一批消息的offset，是會從0開始重新消費。至於如何避免重複消費的問題，在這篇文章有說。

手動提交又分為異步提交和同步提交。

同步提交

上面案例代碼使用的是commitSync() ，顧名思義，是同步提交位移的方法。同步提交位移Consumer 程序會處於阻塞狀態，等待 Broker 返回提交結果。同步模式下提交失敗的時候一直嘗試提交，直到遇到無法重試的情況下才會結束。在任何系統中，因為程序而非資源限制而導致的阻塞都可能是系統的瓶頸，會影響整個應用程序的 TPS。當然，你可以選擇拉長提交間隔，但這樣做的後果是 Consumer 的提交頻率下降，在下次 Consumer 重啟回來后，會有更多的消息被重新消費。因此，為了解決這些不足，kafka還提供了異步提交方法。

異步提交

異步提交會立即返回，不會阻塞，因此不會影響 Consumer 應用的 TPS。由於它是異步的，Kafka 提供了回調函數，供你實現提交之後的邏輯，比如記錄日誌或處理異常等。下面這段代碼展示了調用 commitAsync() 的方法

 consumer.commitAsync((offsets, exception) -> {
 if (exception != null)
     handleException(exception);
 });

但是異步提交會有一個問題，那就是它沒有重試機制，不過一般情況下，針對偶爾出現的提交失敗，不進行重試不會有太大問題，因為如果提交失敗是因為臨時問題導致的，那麼後續的提交總會有成功的。所以消息也是不會丟失和重複消費的。
但如果這是發生在關閉消費者或再均衡前的最後一次提交，就要確保能夠提交成功。因此，組合使用commitAsync()和commitSync()是最佳的方式。

try {
    while (true) {
        ConsumerRecords<String, String> consumerRecords = consumer.poll(Duration.ofMinutes(KafkaConfig.pollTimeoutOfMinutes));
        if (!consumerRecords.isEmpty()) {
             for (ConsumerRecord<String, String> record : consumerRecords) {
                KafkaMessage kafkaMessage = JSON.parseObject(record.value(), KafkaMessage.class);
                boolean handleResult = handle(kafkaMessage);             
             }
             //異步提交位移               
             consumer.commitAsync((offsets, exception) -> {
             if (exception != null)
                 handleException(exception);
             });
           
        }
    }
} catch (Exception e) {
    System.out.println("kafka consumer error:" + e.toString());
} finally {
    try {
        //最後同步提交位移
        consumer.commitSync();
    } finally {
        consumer.close();
    }
}

讓位移提交更加靈活和可控

如果細心的閱讀了上面所有demo的代碼，那麼你會發現這樣幾個問題：

1、所有的提交，都是提交 poll 方法返回的所有消息的位移，poll 方法一次返回1000 條消息，則一次性地將這 1000 條消息的位移一併提交。可這樣一旦中間出現問題，位移沒有提交，下次會重新消費已經處理成功的數據。所以我想做到細粒度控制，比如每次提交100條，該怎麼辦？

答：可以通過commitSync(Map<TopicPartition, OffsetAndMetadata>) 和 commitAsync(Map<TopicPartition, OffsetAndMetadata>)對位移進行精確控制。

2、poll和commit方法對於普通的開發人員而言是一個黑盒，無法精確地掌控其消費的具體位置。我都不知道這次的提交，是針對哪個partition，提交上去的offset是多少。

答：可以通過record.topic()獲取topic信息, record.partition()獲取分區信息,record.offset() + 1獲取消費位移，記住消費位移是指示下一條消費的位移，所以要加一。

3、我想自己管理offset怎麼辦？一方面更加保險，一方面下次重啟之後可以精準的從數據庫讀取最後的offset就不存在丟失和重複消費了。
答：可以將消費位移保存在數據庫中。消費端程序使用comsumer.seek方法指定從某個位移開始消費。

綜合以上幾個可優化點，並結合全文，可以給出一個比較完美且完整的demo：聯合異步提交和同步提交，對處理過程中所有的異常都進行了處理。細粒度的控制了消費位移的提交，並且保守的將消費位移記錄到了數據庫中，重新啟動消費端程序的時候會從數據庫讀取位移。這也是我們消費端程序位移提交的最佳實踐方案。你只要繼承這個抽象類，實現你具體的業務邏輯就可以了。

public abstract class PrefectCosumer {
    private Map<TopicPartition, OffsetAndMetadata> offsets = new HashMap<>();
    int count = 0;
    public final void consume() {
        Properties properties = PropertiesConfig.getConsumerProperties();
        properties.put("group.id", getGroupId());
        Consumer<String, String> consumer = new KafkaConsumer<>(properties);
        consumer.subscribe(getTopics());
        consumer.poll(0);
        // 把offset記錄到數據庫中 從指定的offset處消費 
        consumer.partitionsFor(getTopics()).stream().map(info ->
        new TopicPartition(getTopics(), info.partition()))
        .forEach(tp -> {
               consumer.seek(tp, JdbcUtils.queryOffset().get(tp.partition()));   
         });
        try {
            while (true) {
                ConsumerRecords<String, String> consumerRecords = consumer.poll(Duration.ofMinutes(KafkaConfig.pollTimeoutOfMinutes));
                if (!consumerRecords.isEmpty()) {
                    for (ConsumerRecord<String, String> record : consumerRecords) {

                        KafkaMessage kafkaMessage = JSON.parseObject(record.value(), KafkaMessage.class);
                        boolean handleResult = handle(kafkaMessage);
                        if (handleResult) {
                            //注意：提交的是下一條消息的位移。所以OffsetAndMetadata 對象時，必須使用當前消息位移加 1。
                            offsets.put(new TopicPartition(record.topic(), record.partition()),
                                    new OffsetAndMetadata(record.offset() + 1));

                            // 細粒度控制提交 每10條提交一次offset
                            if (count % 10 == 0) {
                                // 異步提交offset
                                consumer.commitAsync(offsets, (offsets, exception) -> {
                                    if (exception != null) {
                                        handleException(exception);
                                    }
                                    // 將消費位移再記錄一份到數據庫中
                                    offsets.forEach((k, v) -> {
                                        String s = "insert into kafka_offset(`topic`,`group_id`,`partition_id`,`offset`) values" +
                                                " ('" + k.topic() + "','" + getGroupId() + "'," + k.partition() + "," + v.offset() + ")" +
                                                " on duplicate key update offset=values(offset);";
                                        JdbcUtils.insertTable(s);
                                    });


                                });
                            }
                            count++;
                        } else {         
                            System.out.println("消費消息失敗 kafkaMessage={}" + getTopics() + getGroupId() + kafkaMessage.toString());                         
                        }
                    }


                }
            }
        } catch (Exception e) {
            System.out.println("kafka consumer error:" + e.toString());
        } finally {
            try {
                // 最後一次提交 使用同步提交offset
                consumer.commitSync();
            } finally {
                consumer.close();
            }


        }
    }


    /**
     * 具體的業務邏輯
     *
     * @param kafkaMessage
     * @return
     */
    public abstract boolean handle(KafkaMessage kafkaMessage);

    public abstract List<String> getTopics();

    public abstract String getGroupId();

    void handleException(Exception e) {
        //異常處理
    }
}

控制位移提交的N種方式

剛剛我們說自己控制位移，使用seek方法可以指定offset消費。那到底怎麼控制位移？怎麼重設消費組位移？seek是什麼？現在就來仔細說說。

並不是所有的消息隊列都可以重設消費者組位移達到重新消費的目的。比如傳統的RabbitMq，它們處理消息是一次性的，即一旦消息被成功消費，就會被刪除。而Kafka消費消息是可以重演的，因為它是基於日誌結構（log-based）的消息引擎，消費者在消費消息時，僅僅是從磁盤文件上讀取數據而已，所以消費者不會刪除消息數據。同時，由於位移數據是由消費者控制的，因此它能夠很容易地修改位移的值，實現重複消費歷史數據的功能。

了解如何重設位移是很重要的。假設這麼一個場景，我已經消費了1000條消息后，我發現處理邏輯錯了，所以我需要重新消費一下，可是位移已經提交了，我到底該怎麼重新消費這1000條呢？？假設我想從某個時間點開始消費，我又該如何處理呢？

首先說個誤區：auto.offset.reset=earliest/latest這個參數大家都很熟悉，但是初學者很容易誤會它。大部分朋友都覺得在任何情況下把這兩個值設置為earliest或者latest ，消費者就可以從最早或者最新的offset開始消費,但實際上並不是那麼回事,他們生效都有一個前提條件,那就是對於同一個groupid的消費者,如果這個topic某個分區有已經提交的offset,那麼無論是把auto.offset.reset=earliest還是latest,都將失效,消費者會從已經提交的offset開始消費。因此這個參數並不能解決用戶想重設消費位移的需求。

kafka有七種控制消費組消費offset的策略，主要分為位移維度和時間維度，包括：

• 位移維度。這是指根據位移值來重設。也就是說，直接把消費者的位移值重設成我們給定的位移值。包括Earliest/Latest/Current/Specified-Offset/Shift-By-N策略

• 時間維度。我們可以給定一個時間，讓消費者把位移調整成大於該時間的最小位移；也可以給出一段時間間隔，比如 30 分鐘前，然後讓消費者直接將位移調回 30 分鐘之前的位移值。包括DateTime和Duration策略

說完了重設策略，我們就來看一下具體應該如何實現，可以從兩個角度，API方式和命令行方式。

重設位移的方法之API方式

API方式只要記住用seek方法就可以了，包括seek，seekToBeginning 和 seekToEnd。

void seek(TopicPartition partition, long offset);    
void seek(TopicPartition partition, OffsetAndMetadata offsetAndMetadata);    
void seekToBeginning(Collection<TopicPartition> partitions);    
void seekToEnd(Collection<TopicPartition> partitions);    

從方法簽名我們可以看出seekToBeginning和seekToEnd是可以一次性重設n個分區的位移，而seek 只允許重設指定分區的位移，即為每個分區都單獨設置位移，因為不難得出，如果要自定義每個分區的位移值則用seek，如果希望kafka幫你批量重設所有分區位移，比如從最新數據消費或者從最早數據消費，那麼用seekToEnd和seekToBeginning。

Earliest 策略：從最早的數據開始消費

從主題當前最早位移處開始消費，這個最早位移不一定就是 0 ，因為很久遠的消息會被 Kafka 自動刪除，主要取決於你的刪除配置。

代碼如下:

Properties properties = PropertiesConfig.getConsumerProperties();
properties.put("group.id", getGroupId());
Consumer<String, String> consumer = new KafkaConsumer<>(properties);
consumer.subscribe(getTopics());
consumer.poll(0);
consumer.seekToBeginning(
consumer.partitionsFor(getTopics()).stream().map(partitionInfo ->
   new TopicPartition(getTopics(), partitionInfo.partition()))
   .collect(Collectors.toList()));

首先是構造consumer對象，這樣我們可以通過partitionsFor獲取到分區的信息，然後我們就可以構造出TopicPartition集合,傳給seekToBegining方法。需要注意的一個地方是：需要用consumer.poll(0)，而不能用consumer.poll(Duration.ofMillis(0))

在poll(0)中consumer會一直阻塞直到它成功獲取了所需的元數據信息，之後它才會發起fetch請求去獲取數據。而poll(Duration)會把元數據獲取也計入整個超時時間。由於本例中使用的是0，即瞬時超時，因此consumer根本無法在這麼短的時間內連接上coordinator，所以只能趕在超時前返回一個空集合。

Latest策略：從最新的數據開始消費

    consumer.seekToEnd(
        consumer.partitionsFor(getTopics().get(0)).stream().map(partitionInfo ->
            new TopicPartition(getTopics().get(0), partitionInfo.partition()))
              .collect(Collectors.toList()));

Current策略：從當前已經提交的offset處消費

consumer.partitionsFor(getTopics().get(0)).stream().map(info ->
        new TopicPartition(getTopics().get(0), info.partition()))
        .forEach(tp -> {
            long committedOffset = consumer.committed(tp).offset();
            consumer.seek(tp, committedOffset);
        });

**Special-offset策略：從指定的offset處消費 **

該策略使用的方法和current策略一樣，區別在於，current策略是直接從kafka元信息中讀取中已經提交的offset值，而special策略需要用戶自己為每一個分區指定offset值，我們一般是把offset記錄到數據庫中然後可以從數據庫去讀取這個值

    consumer.partitionsFor(getTopics().get(0)).stream().map(info ->
                new TopicPartition(getTopics().get(0), info.partition()))
                .forEach(tp -> {
                    try {
                        consumer.seek(tp, JdbcUtils.queryOffset().get(tp.partition()));
                    } catch (SQLException e) {
                        e.printStackTrace();
                    }
                });

以上演示了用API方式重設位移，演示了四種常見策略的代碼，另外三種沒有演示，一方面是大同小異，另一方面在實際生產中，用API的方式不太可能去做時間維度的重設，而基本都是用命令行方式。

重設位移的方法之命令行方式

命令行方式重設位移是通過 kafka-consumer-groups 腳本。比起 API 的方式，用命令行重設位移要簡單得多。

Earliest 策略指定–to-earliest。

bin/kafka-consumer-groups.sh --bootstrap-server kafka-host:port --group test-group --reset-offsets --all-topics --to-earliest –execute

Latest 策略指定–to-latest。

bin/kafka-consumer-groups.sh --bootstrap-server kafka-host:port --group test-group --reset-offsets --all-topics --to-latest --execute

Current 策略指定–to-current。

bin/kafka-consumer-groups.sh --bootstrap-server kafka-host:port --group test-group --reset-offsets --all-topics --to-current --execute

Specified-Offset 策略指定–to-offset。

bin/kafka-consumer-groups.sh --bootstrap-server kafka-host:port --group test-group --reset-offsets --all-topics --to-offset <offset> --execute

Shift-By-N 策略指定–shift-by N。

bin/kafka-consumer-groups.sh --bootstrap-server kafka-host:port --group test-group --reset-offsets --shift-by <offset_N> --execute

DateTime 策略指定–to-datetime。

DateTime 允許你指定一個時間，然後將位移重置到該時間之後的最早位移處。常見的使用場景是，你想重新消費昨天的數據，那麼你可以使用該策略重設位移到昨天 0 點。

bin/kafka-consumer-groups.sh --bootstrap-server kafka-host:port --group test-group --reset-offsets --to-datetime 2019-06-20T20:00:00.000 --execute

Duration 策略指定–by-duration。
Duration 策略則是指給定相對的時間間隔，然後將位移調整到距離當前給定時間間隔的位移處，具體格式是 PnDTnHnMnS。如果你熟悉 Java 8 引入的 Duration 類的話，你應該不會對這個格式感到陌生。它就是一個符合 ISO-8601 規範的 Duration 格式，以字母 P 開頭，後面由 4 部分組成，即 D、H、M 和 S，分別表示天、小時、分鐘和秒。舉個例子，如果你想將位移調回到 15 分鐘前，那麼你就可以指定 PT0H15M0S。

bin/kafka-consumer-groups.sh --bootstrap-server kafka-host:port --group test-group --reset-offsets --by-duration PT0H30M0S --execute

提交的位移都去哪了？

通過上面那幾部分的內容，我們已經搞懂了位移提交的方方面面，那麼提交的位移它保存在哪裡呢？這就要去位移主題的的世界里一探究竟了。kafka把位移保存在一個叫做__consumer_offsets的內部主題中，叫做位移主題。

注意：老版本的kafka其實是把位移保存在zookeeper中的，但是zookeeper並不適合這種高頻寫的場景。所以新版本已經是改進了這個方案，直接保存到kafka。畢竟kafka本身就適合高頻寫的場景，並且kafka也可以保證高可用性和高持久性。

既然它也是主題，那麼離不開分區和副本這兩個機制。我們並沒有手動創建這個主題並且指定，所以是kafka自動創建的， 分區的數量取決於Broker 端參數 offsets.topic.num.partitions，默認是50個分區，而副本參數取決於offsets.topic.replication.factor，默認是3。

既然也是主題，肯定會有消息，那麼消息格式是什麼呢？參考前面我們手動設計將位移寫入數據庫的方案，我們保存了topic,group_id,partition,offset四個字段。topic,group_id,partition無疑是數據表中的聯合主鍵，而offset是不斷更新的。無疑kafka的位移主題消息也是類似這種設計。key也是那三個字段，而消息體其實很複雜，你可以先簡單理解為就是offset。

既然也是主題，肯定也會有刪除策略，否則消息會無限膨脹。但是位移主題的刪除策略和其他主題刪除策略又不太一樣。我們知道普通主題的刪除是可以通過配置刪除時間或者大小的。而位移主題的刪除，叫做 Compaction。Kafka 使用Compact 策略來刪除位移主題中的過期消息，對於同一個 Key 的兩條消息 M1 和 M2，如果 M1 的發送時間早於 M2，那麼 M1 就是過期消息。Compact 的過程就是掃描日誌的所有消息，剔除那些過期的消息，然後把剩下的消息整理在一起。

Kafka 提供了專門的後台線程定期地巡檢待 Compact 的主題，看看是否存在滿足條件的可刪除數據。這個後台線程叫 Log Cleaner。很多實際生產環境中都出現過位移主題無限膨脹佔用過多磁盤空間的問題，如果你的環境中也有這個問題，我建議你去檢查一下 Log Cleaner 線程的狀態，通常都是這個線程掛掉了導致的。

總結

kafka的位移是個極其重要的概念，控制着消費進度，也即控制着消費的準確性，完整性，為了保證消息不重複和不丟失。我們最好做到以下幾點:

• 手動提交位移。

• 手動提交有異步提交和同步提交兩種方式，既然兩者有利也有弊，那麼我們可以結合起來使用。

• 細粒度的控制消費位移的提交，這樣可以避免重複消費的問題。

• 保守的將消費位移再記錄到了數據庫中，重新啟動消費端程序的時候從數據庫讀取位移。

獲取Kafka全套原創學習資料及思維導圖，關注【胖滾豬學編程】公眾號，回復”kafka”。

本文來源於公眾號：【胖滾豬學編程】。一枚集顏值與才華於一身，不算聰明卻足夠努力的女程序媛。用漫畫形式讓編程so easy and interesting！求關注！

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

※網頁設計最專業,超強功能平台可客製化

vscode配置ruby開發環境

vscode近年來發展迅速，幾乎在3年之間就搶佔了原來vim、sublime text的很多份額，猶記得在2015-2016年的時候，ruby推薦的開發環境基本上都是vim和sublime text，然而，隨着vscode的發展，vscode下ruby的開發體驗已經非常不錯。現在基本上使用win 10 wsl2 + vscode + windows terminal的體驗已經不遜於mac + vim (sublime) + item 2的體驗了

總體步驟

使用win10專業版配置ruby開發環境大致分為以下幾步：

1. 開啟win10 wsl功能
2. 升級wsl2
3. 安裝ubuntu
4. 安裝ruby（rvm）
5. 安裝vscode
6. 安裝vscode wsl擴展
7. 安裝vscode ruby相關擴展

經過以上7步就可以開始愉悅的ruby開發了，再開始之前，可以先看個效果圖。

1. 開啟win10 wsl功能

ruby對Linux和Mac比較友好，在windows下很多第三方庫要配合mingw或msys2才能安裝，不過好在windows 10提供了Linux子系統，在win10 2004版本中wsl也升級到了wsl2，速度更快，功能更完善。

要使用wsl2需要先在控制面板中開啟wsl功能：

• 適用於Linux的Windows子系統
• 虛擬機平台

2. 升級wsl2

目前wsl2還需要安裝一個內核升級包，具體可參考微軟說明：

• wsl2安裝說明
• wsl2 update包

更新包安裝完成后，輸入命令

wsl --set-default-version 2

3. 安裝Ubuntu

在微軟應用商店安裝Ubuntu，當前Ubuntu版本為20.04 LTS

安裝完成以後，配置Ubuntu默認為wsl2

# 查看
wsl --list --verbose

# 設置
wsl --set-version Ubuntu 2

4. 安裝ruby

在Linux下安裝ruby有多種方法，比較主流的方法是RVM，不過為了簡單起見，我直接通過ubuntu的apt工具進行了安裝。

關於RVM的安裝可參考如下網站：

• RVM官網
• RVM實用指南

通過APT安裝，輸入下列命令即可

sudo apt install ruby ruby-dev ri ruby-bundle

安裝完成以後需要配置gem國內鏡像，參考如下網址：

• gem中文鏡像

輸入下列命令

# 設置gem source
gem sources --add https://gems.ruby-china.com/ --remove https://rubygems.org/

# 查看gem source
gem sources -l

# 設置bundle
bundle config mirror.https://rubygems.org https://gems.ruby-china.com

5. 安裝vscode

vscode直接在官網下載安裝即可，這裏我選擇了System Installer

• vscode官網下載頁面

6. 安裝vscode wsl擴展

vscode安裝完成以後，可以在plugin中找到Remote – WSL擴展，點擊安裝即可

7. 安裝vscode ruby相關擴展

直接在plugin中搜索ruby在wsl中安裝下列五個擴展即可

• Peng Lv/Ruby
• Castwide/Ruby Solargraph（Language Server）
• misogi/ruby-rubocop（Lint）
• Simple Ruby ERB
• endwise

其中，ruby solargraph和rubocop除了安裝擴展，還需要通過gem安裝第三方包

sudo gem install rubocop
sudo gem install solargraph

重新加載vscode-wsl就可以愉快的使用ruby language進行開發了

vscode使用

在使用上基本只要require了相應的庫，就solargraph就會對require的庫中涉及的類和模塊進行提示，非常方便。唯一有問題的地方就是require的時候沒有提示，這可能就需要自己記一下庫的名稱，不過相比於原來已經好太多了，應該說在可以接受的範圍內。

1. 如果安裝了新的第三方庫會提示嗎？

如果安裝了sinatra這樣的庫，vscode-ruby如何給出提示呢？只需要Ctrl + Shift + P，選擇solargraph: build new gem documention即可

2. rubocop如何使用？

rubocop是一個Ruby Lint工具，可以進行Ruby代碼風格檢查，並能夠自動修復，只需要Ctrl + Shift + P，選擇Ruby: autocorrect by rubocop即可

3. 常用類型註釋

ruby是動態強類型語言，由於不需要指定函數返回值類型，這導致IDE無法自動推斷一些變量的類型。目前Python、PHP、TypeScript都在不斷的強化類型以方便IDE進行靜態檢查。IDE只有在知道類型的情況下才能準確地進行智能提示。

在ruby 2當中，我們可以通過類型註釋的方式增強IDE推斷能力。常見的類型註釋可參考YARD項目

下面代碼給出了一些示例。

require 'socket'

server = TCPServer.new 2000
loop do
  # 代碼塊參數類型註釋
  # @param {TCPSocket} client
  Thread.start(server.accept) do |client|
    client.puts 'hello !'
    client.puts "Time is #{Time.now}"
    client.close
  end
end

server = TCPServer.new 2000
loop do
  # 變量註釋
  # @type {TCPSocket} client
  client = server.accept
end

# 函數參數和返回值註釋，數組類型
# @param {Array(Integer)} nums
# @param {Integer} target
# @return {Array(Integer)}
def two_sum(nums, target)
  hash_nums = {}
  result = []
  nums.each_with_index do |num, index|
    hash_nums[num] = index
  end

  nums.each_with_index do |num, index|
    another = target - num
    if hash_nums[another] && hash_nums[another] != index
      result.push(index, hash_nums[another])
      break
    end
  end

  result
end

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※南投搬家公司費用需注意的眉眉角角，別等搬了再說!

※教你寫出一流的銷售文案?

概述

Java 里的攔截器是動態攔截 action 調用的對象。

可以在Controller 中的方法執行之前與執行之後，及頁面显示完畢后，執行指定的方法，自定義的攔截器必須實現HandlerInterceptor 接口。

方法介紹

preHandle

在業務處理器處理請求之前被調用

postHandle

在業務處理器處理完請求后

afterCompletion

在 DispatcherServlet 完全處理完請求后被調用

SpringMVC攔截器使用

攔截所有請求

創建一個類實現 HandlerInterceptor 接口

 

 配置文件當中添加攔截器

 

 內部源碼分析

 

 

 

 

攔截指定請求

 

 

配置多個攔截器執行順序

 

 

 

 

 

 

 

第 2 個返回 false

 

 

 

 

 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※想知道最厲害的網頁設計公司"嚨底家"!

※別再煩惱如何寫文案,掌握八大原則!

※產品缺大量曝光嗎?你需要的是一流包裝設計!

Nginx服務器

一：什麼是Nginx？

我們生活的世界中，有的時候需要上網。我們可以瀏覽很多很多的網頁，這些網頁都是由一系列的程序組成，但是我們是否想過，這些程序存儲在什麼地方呢？沒錯，這些程序都是存儲在一種名叫服務器的硬件上，比如我們的電腦也是一種服務器，只不過我們的個人電腦作為服務器的話性能會比較低。我們的網頁程序存儲在服務器硬件上，是否可以隨意存儲呢？不是的，我們需要在服務器硬件的操作系統中搭建一個服務器軟件，那麼這樣，有服務器軟件跟服務器硬件配合，才形成一個完整的服務器。服務器軟件有非常多，比如Apache、tomcat等等都是服務器軟件，而我們今天要學習的Nginx也是一種服務器軟件之一。

Nginx是一種服務器軟件，故而其最主要、最基本的功能當然是可以與服務器硬件結合，讓程序員可以將程序放在Nginx服務器上，將程序發布出去，讓成千上萬的網民可以瀏覽。除此之外，Nginx是一種高性能的HTTP和反向代理服務器，同時也是一個代理郵件服務器。也就是說，我們Nginx上可以發布網站，也可以實現負載均衡的功能，還可以作為郵件服務器實現收發郵件等功能。所謂的負載均衡是指，當同時有N多用戶訪問我們服務器的時候，為了減少服務器壓力，我們需要將用戶分別引入各服務器，分擔服務器的壓力。

Nginx與其他服努器的性能比較

首先說IIS, IIS服務器只能在Windows上運行，Windows服務器性能不如Linux— 類服務器。其次說Tomcat,Tomcat服務器面向的是Java語言，是一種重量級的服 務器，而Nginx是輕量級服務器，Tomcat與Nginx不具備可比性。最後，我們講一 下Apache，Apache優點非常多，比如穩定、幵源、跨平台等等，但是Apache不支 持高併發。Nginx能支持處理百萬級的TCP連接，10萬以上的併發連接，並且是一 個很好的跨平台服務器。

Nginx的主要優點有可以實現高併發、部署簡單、內存消耗少、成本低等等。

Nginx的主要缺點有rewrite功能不夠強大，模塊沒有Apache的多。

本文版權歸微信公眾號”代碼藝術”（ID：onblog）所有，若是轉載請務必保留本段原創聲明，違者必究。若是文章有不足之處，歡迎關注微信公眾號私信與我進行交流！

二：Linux中搭建Nginx服務器

新建壓縮包下載位置（可選）

新建目錄
mkdir /usr/local/nginx_down
切換目錄
cd /usr/local/nginx_down

下載解壓 Nginx

下載
wget http://nginx.org/download/nginx-1.14.0.tar.gz
解壓
tar -zxvf nginx-1.14.0.tar.gz
切換目錄
cd nginx-1.14.0

配置 Nginx

./configure --with-http_ssl_module

1. 這樣會默認安裝nginx在 /usr/local/nginx 目錄，可以使用--prefix=/usr/local/nginx指定安裝位置。

2. 如果需要HTTPS（SSL）的支持，需要指定參數--with-http_ssl_module。

如果提示錯誤，那麼需要其它環境，請參考下面

安裝 make

yum -y install gcc automake autoconf libtool make

安裝 g++

yum -y install gcc gcc-c++

安裝 PCRE庫

yum -y install pcre pcre-devel

安裝 Zlib

yum -y install zlib zlib-devel

安裝 GD library

yum -y install gd-devel

安裝 openssl

yum -y install openssl openssl-devel

-y：跳過所有手動確認輸入

如果./configure安裝成功，只需要再執行兩個命令：

make

make install

查看是否安裝成功

cd /usr/local/nginx

如果安裝成功，則會出現下列目錄：

conf  html  logs  sbin

切換到sbin目錄

cd /sbin

啟動程序

./nginx

追加參數 -c 可以指定配置文件。

常見的錯誤

在Linux操作系統下搭建Nginx服務器，很多時候會出現不同的錯誤，在此，我們對搭建過程中出現的錯誤進行一些總結。主要有這些類型：

防火牆問題，缺少gc++，缺少pcre、zlib等庫。

三：Nginx的反向代理和負載均衡

什麼是反向代理

我們有時候，用自己的計算機A想訪問國外的某個網站B，但是訪問不了，此時，有一台中間服務器C可以訪問國外的網站B，那麼，我們可以用自己的電腦訪問服務器C，通過C來訪問B這個網站。那麼這個時候，服務器C稱為代理服務器，這種訪問方式叫做正向代理。正向代理有一個特點，就是我們明確知道要訪問哪個網站。再如，當我們有一個服務器集中，並且服務器集群中的每台服務器的內容一樣的時候，同樣我們要直接從個人電腦訪問到服務器集中的服務器的時候無法訪問，且此時第三方服務器能訪問集群，這個時候，我捫通過第三方服務器訪問服務器集群的內容，但是此吋我們並不知道是哪一台服務器提供的內容，此時的代理方式稱為反向代理。

正向代理

反向代理

什麼是負載均衡

當一台服務器的單位時間內的訪問量越大的時候，服務器的壓力會越大。當一台服務器壓力大得超過自身的承受能力的時候，服務器會崩潰。為了避免服務器崩潰，讓用戶有更好地體驗，我們通常通過負載均衡的方式來分擔服務器的壓力。那麼什麼是負載均衡呢？是這樣，我們可以建立很多很多個服務器，這些服務器組成一個服務器集群，然後，當用戶訪問我們網站的時候，先訪問一个中間服務器，再讓這个中間服務器在服務器集群中選擇一個壓力較小的服務器，然後將該訪問請求引入該選擇的服務器。這樣，用戶的每次訪問，都會保證服務器集群中的每個服務器的壓力趨於平衡，分擔了服務器壓力，避免了服務器崩潰的情況。

基於反向代理的原理實現負載均衡

四：Nginx負載均衡的實現

Nginx 是一款可以通過反向代理實現負載均衡的服務器，使用 Nginx 服務實現負載均衡的時候，用戶的訪問首先會訪問到 Nginx 服務器，然後 Nginx 服務器再從服務器集群表中選擇壓力較小的服務器，然後將該訪問請求引向該服務器。若服務器集群中的某個服務器崩潰，那麼從待選服務器列表中將該服務器刪除，也就是說一個服務器假如崩潰了，那麼 Nginx 就肯定不會將訪問請求引入該服務器了。那麼下面，我們通過實例來講解一下 Nginx 負載均衡的實現。

負載均衡配置文件

默認配置文件nginx.conf 很重要，我們一般是新建一個配置文件，在啟動時指定加載。

[root@hostname conf]# ls  //查看目錄
fastcgi.conf            koi-win             scgi_params
fastcgi.conf.default    mime.types          scgi_params.default
fastcgi_params          mime.types.default  uwsgi_params
fastcgi_params.default  nginx.conf          uwsgi_params.default
koi-utf                 nginx.conf.default  win-utf
[root@hostname conf]# touch fzjh.conf  //新建負載均衡配置文件

編輯fzjh.conf配置文件

vi fzjh.conf

worker_processes  1;#工作進程的個數，一般與計算機的cpu核數一致  
  
events {  
    worker_connections  1024;#單個進程最大連接數（最大連接數=連接數*進程數） 併發 
}  
  
http {  
    include       mime.types; #文件擴展名與文件類型映射表  
    default_type  application/octet-stream;#默認文件類型  
  
    sendfile        on;#開啟高效文件傳輸模式，sendfile指令指定nginx是否調用sendfile函數來輸出文件，對於普通應用設為 on，如果用來進行下載等應用磁盤IO重負載應用，可設置為off，以平衡磁盤與網絡I/O處理速度，降低系統的負載。注意：如果圖片显示不正常把這個改成off。  
      
    keepalive_timeout  65; #長連接超時時間，單位是秒  
  
    gzip  on;#啟用Gizp壓縮  
      
    #服務器的集群  
    upstream  myproject {  #服務器集群名字   
        server    220.181.111.188:80  weight=1;#服務器配置   weight是權重的意思，權重越大，分配的概率越大。  
        server    42.121.252.58:80  weight=2;  
    }     
  
    #當前的Nginx的配置  
    server {  
        listen       80;  #監聽80端口，可以改成其他端口  
        server_name  localhost; ##############   當前服務的域名  
  
        location / {  ##配置路徑/下實現負載均衡
            proxy_pass http://myproject;  ##對應哪個服務器集群
            proxy_redirect default;  
        }  
          
        error_page   500 502 503 504  /50x.html;  
        location = /50x.html {  
           root   html;  #根目錄
        }  
    }  
}  

我們在nginx目錄下執行命令，啟動負載均衡

./sbin/nginx -c ./conf/fzjh.conf

然後嘗試訪問你的服務器，多訪問幾次，你會發現它會訪問2次csdn網站，1次百度。說明我們的負載均衡已經部署完畢。

如何重啟Nginx

【本文版權歸微信公眾號”代碼藝術”（ID：onblog）所有，若是轉載請務必保留本段原創聲明，違者必究。若是文章有不足之處，歡迎關注微信公眾號私信與我進行交流！】

./sbin/nginx -s reload

如何關閉Nginx服務器

1.查看nginx進程號

ps -ef|grep nginx

2.kill掉進程即可 (1709是第二列的進程號)

kill 1709

或者

killall -9 nginx

五：HTTP Upstream 模塊

HTTP Upstream 模塊

Upstream 模塊是 Nginx 服務器的一個重要模塊。 Upstream 模塊實現在輪詢和客戶端 iP 之間實現後端的負載均衡。常用的指令有 ip_hash指令、 server 指令和 upstream 指令等，下面我們分別來講一下。

Http Upstream模塊- ip_hash指令

在負載均衡系統中,假如用戶在某台服務器上登錄,那麼如果該用戶第二次請求的時候,因為我們是負載均衡系統,每次請求都會重新定位到服務器集群中的一個服務器,那麼此時如果將已經登錄服務器A的用戶再定位到其他服務器,顯然不妥。故而,我們可以採用 ip_hash指令解決這個問題,如果客戶端請求已經訪問了服務器A並登錄,那麼第二次請求的時候,會將該請求通過哈希算法自動定位到該後端服務器中。下面我們通過實例講解。

實例

此時不應該使用weight權重。

tp {  
   ....
  upstream  myproject {    
      ip_hash; #實現會話跟蹤
      server 140.205.140.234;
      server 61.135.169.125;

  }     
 ....

Http Upstream 模塊一 upstream 指令及相關變量

upstream 指令主要是用於設置一組可以在 proxy_pass 和 fastcgi_pass 指令中使用代理服務器，默認負載均衡方式為輪詢。

六：其他負載均衡實現方式

負載均衡的實現方法除了可以使用 Nginx服務器實現外,還可以通過很多種方法來實現。負載均衡的核心就是建立一個服務器集群,然後用戶首先訪問到第三方代理服務器,然後由代理服務器選擇一個集群中的服務器,然後將請求引入選定的服務器。那麼代理服務器可以使用多種方式來充當,故而實現負載均衡的方式也是多種。總的來說,負載均衡實現的方式分為軟件實現和硬件實現兩種,如果中間的代理機構是硬件,那麼就是通過硬件設備來實現負載均衡的方式,如果中間的代理機構為軟件,就是軟件實現負載均衡的方式。而其中,軟件又可以是服務器軟件、系統軟件以及應用軟件等充當。

負載均衡實現方式小結

下面我們簡單總結一下負載均衡不同實現方式的優缺點:

假如使用硬件的方式實現負載均衡,那麼中間的轉發機構就是硬件,這個時候運行的效率非常高,但是對應的成本也非常高。如果我們採用軟件的方式來實現負載均衡,那麼中間的轉發機構就是軟件,這個時候,運行效率不如硬件,但是成本相對來說低得多。而使用Nginx服務器實現負載均衡,那麼就是通過軟件的方式來實現負載均衡,並且 Nginx本身支持高併發等。故而使用 Nginx服務器實現負載均衡,能大大節約企業的成本,並且由於 Nginx是服務器軟件,其執行效率也是非常高。

七：location匹配順序

1. “=”前綴指令匹配，如果匹配成功，則停止其他匹配
2. 普通字符串指令匹配，順序是從長到短，匹配成功的location如果使用^~，則停止其他匹配（正則匹配）
3. 正則表達式指令匹配，按照配置文件里的順序，成功就停止其他匹配
4. 如果第三步中有匹配成功，則使用該結果，否則使用第二步結果

注意點

1. 匹配的順序是先匹配普通字符串，然後再匹配正則表達式。另外普通字符串匹配順序是根據配置中字符長度從長到短，也就是說使用普通字符串配置的location順序是無關緊要的，反正最後nginx會根據配置的長短來進行匹配，但是需要注意的是正則表達式按照配置文件里的順序測試。找到第一個比配的正則表達式將停止搜索。
2. 一般情況下，匹配成功了普通字符串location后還會進行正則表達式location匹配。有兩種方法改變這種行為，其一就是使用“=”前綴，這時執行的是嚴格匹配，並且匹配成功后立即停止其他匹配，同時處理這個請求；另外一種就是使用“^~”前綴，如果把這個前綴用於一個常規字符串那麼告訴nginx 如果路徑匹配那麼不測試正則表達式。

匹配模式及順序

　　location = /uri 　　　=開頭表示精確匹配，只有完全匹配上才能生效。

　　location ^~ /uri 　　^~ 開頭對URL路徑進行前綴匹配，並且在正則之前。

　　location ~ pattern 　~開頭表示區分大小寫的正則匹配。

　　location ~* pattern 　~*開頭表示不區分大小寫的正則匹配。

　　location /uri 　　　　不帶任何修飾符，也表示前綴匹配，但是在正則匹配之後。

　　location / 　　　　　通用匹配，任何未匹配到其它location的請求都會匹配到，相當於switch中的default。

八：配置HTTPS

1.獲取證書

獲得SSL證書文件 1_www.domain.com_bundle.crt 和私鑰文件 2_www.domain.com.key

2.證書安裝

將域名 www.domain.com 的證書文件1_www.domain.com_bundle.crt 、私鑰文件2_www.domain.com.key保存到同一個目錄，例如/usr/local/nginx/conf目錄下。

3.配置conf

打開nginx.conf文件，找到nginx.conf的下段配置內容：

# HTTPS server
#
#server {
#    listen       443 ssl;
#    server_name  localhost;

#    ssl_certificate      cert.pem;
#    ssl_certificate_key  cert.key;

#    ssl_session_cache    shared:SSL:1m;
#    ssl_session_timeout  5m;

#    ssl_ciphers  HIGH:!aNULL:!MD5;
#    ssl_prefer_server_ciphers  on;

#    location / {
#        root   html;
#        index  index.html index.htm;
#    }
#}

打開註釋，修改server_name為綁定證書的域名（如：www.domain.com），修改ssl_certificate 為 1_www.domain.com_bundle.crt，修改 ssl_certificate_key 為 2_www.domain.com.key 即可。

4.HTTP自動跳轉HTTPS

對於用戶不知道網站可以進行https訪問的情況下，讓服務器自動把http的請求重定向到https。 在服務器這邊的話配置的話，可以在頁面里加js腳本，也可以在後端程序里寫重定向，當然也可以在web服務器來實現跳轉。

Nginx是支持rewrite的（只要在編譯的時候沒有去掉pcre） 在http的server里增加rewrite ^(.*) https://$host$1 permanent; 這樣就可以實現80進來的請求，重定向為https了。

還是在此配置文件中，加入下面一句：

server {
        listen       80;
        server_name  localhost;
        
		rewrite ^(.*) https://$host$1 permanent;
		...

版權聲明

本文版權歸微信公眾號”代碼藝術”（ID：onblog）所有，若是轉載請務必保留本段原創聲明，違者必究。若是文章有不足之處，歡迎關注微信公眾號私信與我進行交流！

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※別再煩惱如何寫文案,掌握八大原則!

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※超省錢租車方案

※教你寫出一流的銷售文案?

※網頁設計最專業,超強功能平台可客製化

一、歸併排序

歸併排序是建立在歸併操作上的一種有效的排序算法。該算法是採用分治法（Divide and Conquer）的一個非常典型的應用。將已有序的子序列合併，得到完全有序的序列；即先使每個子序列有序，再使子序列段間有序。若將兩個有序表合併成一個有序表，稱為2-路歸併。

• 所謂“分”，指的是將一個亂序數列不斷進行二分，得到許多短的序列。

• 所謂“治”，指的是將這些短序列進行兩兩合併，然後將合併的結果作為新的序列，再與其他序列進行合併，最終得到一個新的序列。

歸併排序算法描述

 

• 把長度為n的輸入序列分成兩個長度為n/2的子序列；

• 對這兩個子序列分別採用歸併排序；

• 將兩個排序好的子序列合併成一個最終的排序序列。

 

歸併排序動圖演示

 

動畫演示圖2

 

 

歸併排序代碼實現

def merge_sort(alist):
    """歸併排序"""
    n = len(alist)
    #遞歸結束條件
    # 剩一個或沒有直接返回，不用排序
    if n <= 1:
        return alist
    # 拆分
    mid = n//2
​
    # left 採用歸併排序后形成的有序的新的列表
    left_li = merge_sort(alist[:mid])
​
    # right 採用歸併排序后形成的有序的新的列表
    right_li = merge_sort(alist[mid:])
​
    # 將兩個有序的子序列合併為一個新的整體
    # merge(left, right)
    left_pointer, right_pointer = 0, 0
    result = []
​
    while left_pointer < len(left_li) and right_pointer < len(right_li):
        if left_li[left_pointer] <=  right_li[right_pointer]:
            result.append(left_li[left_pointer])
            left_pointer += 1
        else:
            result.append(right_li[right_pointer])
            right_pointer += 1
    
    #將兩個列表按順序融合為一個列表result
    result += left_li[left_pointer:]
    result += right_li[right_pointer:]
    return result
​

　　

​

歸併排序過程分析

示例 針對 arrli = [6,5,3,1,8,7,2,4]進行歸併排序

1、拆分數組

假設數組一共有 n 個元素，我們遞歸對數組進行折半拆分即n//2，直到每組只有一個元素為止。

 

2、合併數組

算法會從最小數組開始有序合併，這樣合併出來的數組一直是有序的，所以合併兩個有序數組是歸併算法的核心，這裏用兩個簡單數組示例：

步驟1：新建一個空數組存放合併結果，用left_pointer和right_pointer兩個輔助指針記錄兩個數組當前操作位置；

 

步驟2：從左到右逐一比較兩個小數組中的元素，較小的元素先放入新數組，指針移位，直到left_pointer和right_pointer指針超出尾部；

 

步驟3：新建一個空數組存放合併結果，用l和r兩個輔助指針記錄兩個數組當前操作位置；

 

步驟4：從左到右逐一比較兩個小數組中的元素，較小的元素先放入新數組，指針移位，直到l或r指針超出尾部；

 

繼續比較寫入較小的元素到新數組

繼續比較寫入較小的元素到新數組

 

指針尚未移到尾部的數組，說明還有剩餘元素，將剩餘元素合併到新數組尾部。

 

步驟5：新建一個空數組存放合併結果，用l和r兩個輔助指針記錄兩個數組當前操作位置；

 

步驟6：從左到右逐一比較兩個小數組中的元素，較小的元素先放入新數組，指針移位，直到l或r指針超出尾部；

 

將較小的元素寫入到新數組

繼續比較寫入較小的元素到新數組

繼續比較寫入較小的元素到新數組

繼續比較寫入較小的元素到新數組

 

步驟7：右邊的指針尚未移到尾部的數組，說明還有剩餘元素，將剩餘元素合併到新數組尾部。

 

完成歸併排序，返回排好序的新數組

 

 

歸併排序複雜度

 

• 時間複雜度：O(nlogn)

歸併排序把數組一層層折半分組，長度為 n 的數組，折半層數就是 logn，每一層進行操作的運算量是 n，得出時間複雜度 O(nlogn)。

• 空間複雜度：O(n)

每次歸併操作需要創建額外的新數組，佔用空間為 n，但這部分額外空間會隨着方法的結束而釋放，所以只需要算單次歸併操作開闢的空間即可，得出空間複雜度 O(n)。

• 穩定性：穩定

從算法中從左到右逐一比較，較小的先放入新數組，所以兩個值相同的元素，排序后依然保持原先後順序。

 

 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※別再煩惱如何寫文案,掌握八大原則!

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※超省錢租車方案

※教你寫出一流的銷售文案?

※網頁設計最專業,超強功能平台可客製化

雖然中國政府在 2018 年中旬推出 531 新政，讓該國投資去年太陽能總投資下降 53%，重挫當地太陽能投資與建設發展，但該國政府目前已推出無補貼再生能源計畫，或許有望重振中國太陽能市場，彭博能源財經（BNEF）推測 2019 年中國太陽能新增裝置量仍可達到 34-44GW。

中國過去一直以來對當地太陽能產業發展相當優待，提供優渥的補貼金額與固定電價價格以鼓勵太陽能等再生能源發展，大量企業開始投資太陽能產業，形成一股靠補貼攀升的太陽能熱潮，造成產能過剩與補貼缺口過大，據統計，截至 2017 年底，再生能源補貼缺口已達 1,000 億人民幣（約新台幣 4,600 億元）。

因此中國政府在 2018 年中無預警推出新政策，大幅限制電廠建設與補助，為中國高速發展的太陽能產業踩下煞車踏板，未來也將採取嚴控指標方式，並積極鼓勵低價補貼或是無補貼專案。

無補貼專案優惠多

就好比中國在去年 8 月推出首項無補貼太陽能示範專案規劃，每省限定 300-500MW，並在 10 月開始申請、預計在 2019 年 3 月前後開工拚年底前併網發電。日前該政府也為了促進再生能源無補貼發展公布 12 項全新計畫，像是要做好風電、光電發電量檢測，不能在電力供過於求等預警紅色地區推行專案，廠商也要保證將來可以全額併網發電與不浪費。

中國此次將「無補貼專案」定義為無國家補貼、先導計畫不限規模、不佔用補貼指標的計畫，因此在政策方面也有釋出許多善意，要求地方政府對無補貼太陽能與風電在土地利用、成本上給予支持之餘，政府也會為綠色證書市場化交易指出明燈，未來無補貼或是低價補貼專案可以透過中國綠色電力證書交易獲益，與此同時也要求電力公司讓無補貼專案優先發電和全額收購電量，並鼓勵金融機構支持無補貼專案。

另外中國政府也將執行固定電價（FIT）政策，無補貼、低價補貼風電與太陽能專案可簽定 20 年以上的購電合約，提高電價的長期穩定性，也不要會求參與跨區電力市場化交易。

中國國家發改委表示，這些專案獲得核准後就能在 2020 年底前開始施工，但沒有在限定時間完工的專案將會被取消，為其他無補貼專案挪出空間。並明確指出，從現在到 2020 年底前獲準的專案都可採用這項政策，政府則會在 2020 年後依據技術與成本擬定新的政策。

只不過中國目前也有不少地方無法規劃無補貼專案，對此中國政府也表示，推動低價專案並非立即取消所有補貼，若無法達到無補貼或低價補貼仍可採競爭性配置專案政策，並希望這些專案可透過競爭降低電價以減少政府補貼。

BNEF 分析師 Jonathan Luan 表示，這些政策代表著未來中國將朝無補貼再生能源邁進，並有機會促成全新的太陽能專案，公司則對中國的太陽能市場樂觀看待，預測 2019 年新增裝置量可達 34-44GW。

（合作媒體：。首圖來源： CC BY 2.0）

延伸閱讀：

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!

※教你寫出一流的銷售文案?

※超省錢租車方案

2018 年可說是太陽能產業近年來波動最大的一年，歷經美國 201、301 條款，中國 531 新政，印度防衛性關稅，歐盟 MIP 結束等變動，從最上游的供應鏈到最下游的系統端都呈現極不穩定的狀態。由 EnergyTrend 所盤整的 2019 年五大趨勢來看，市況將會好轉，且產業也將在持續的變動中逐漸成熟。

趨勢一：2018 年低谷不低，2019 需求再創新高

中國的「531 新政」雖對市場造成衝擊，但因海外市場的需求走強，加上中國市場所受衝擊輕於預期，使 2018 年出現「低谷不低」的現象，預期全年新增併網量可達到 103GW（實際出貨量約95GW），年增4.9%。

展望 2019 年，在政策鼓勵與供應鏈價格持續下降的推波助瀾下，全球需求預計將繼續正成長，其中又以歐洲的成長幅度最大，最多可超過五成。2019 年預期新增併網量將來到 111.3GW，出現 7.7% 的成長，再次創下歷史新高。

趨勢二：市場持續分散，2019 年 GW 級市場增至 15 個

全球市場規模自 2018 年起預計會持穩在 100-120GW 之間，各年度需求量變化幅度將低於 10%。而根據 EnergyTrend 的最新需求報告統計，GW 級市場從 2016  年的 6  個成長到 2019 年將有 15 個，可見市場持續分散化的趨勢。

2016-2020 年 GW 級市場

中國、美國將持續穩居全球前二大市場，印度則從 2017 年起成為第三大需求國，日本次之。東南亞、北非、中東、拉丁美洲等新興市場自 2018 年崛起，如中東地區 2018 年全年需求預計將較 2017 年增加近 100%，2019  年還將增加 50% 左右。全球市場規模自 2019 年起將趨於穩定，印度最有可能出現較大幅度的需求成長。

2016-2023 年全球市場需求趨勢

趨勢三：供應鏈上游更為集中，單晶將逆轉市佔

雖然供應鏈整體在 2018 年陷於供過於求、低利潤的困境，但技術和成本優勢較強、全球布局較廣的一線大廠仍保有強勁的營運動能，既有的擴產計畫多能持續進行，使供應鏈廠家有持續集中化的現象。根據 EnergyTrend  的供給資料庫，中國前五大多晶矽廠的新產能預計在 2Q19 陸續開出，屆時前五大廠的產能將佔全球近 70%，且現金成本更具競爭力。在矽晶圓環節，則將呈現隆基與中環雙龍頭主宰市場的現象，單晶供應鏈也將因而變得更具主導性，有機會拉升全年單晶佔比來到 6 成，2017 年底展開的單多晶之戰逐漸落幕。

趨勢四：雙面產品產能倍增，P-PERC 效率還有成長空間

雙面電池技術已十分成熟，且可在幾乎不增加額外成本的前提下創造額外的發電收益，因此產能比例持續上升，預計 2019 年雙面電池的總產能將接近 40GW，且以雙面單晶 PERC 電池產能增加最多。另一方面，單晶 PERC 電池的量產效率仍有成長空間。據 EnergyTrend 調查，單晶 PERC 電池的平均量產效率在 2019 年上半年即可站上 22%，且還可導入更多技術，在 2019 年底效率可望上看 23%。而單晶 PERC 的強勢也壓縮了次世代 N 型技術的發展空間，2019 年 N 型產能預期僅會有小幅增加。

雙面電池產能成長趨勢（Unit: GW）

趨勢五：均化度電成本成為模組價格降價指標

供應鏈價格持續下探，使太陽能逐步朝擺脫補貼、平價上網的方向邁進；而無補貼系統的普及程度及其實際的均化度電成本（LCOE）將成為未來供應鏈的價格指標。

太陽能產業在 2018 年面臨強大考驗，但同時也進入產業盤整階段，預期長期發展將趨於穩定化與健康化，供應鏈的價格將以整體系統的度電成本為依歸。儲能系統與智慧電網技術的投入，將成為太陽能產業進一步市場化的關鍵。

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

※網頁設計最專業,超強功能平台可客製化