摘要：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）所有，若是轉載請務必保留本段原創聲明，違者必究。若是文章有不足之處，歡迎關注微信公眾號私信與我進行交流！

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

【其他文章推薦】

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

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

※超省錢租車方案

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

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

（一）drf基礎

全稱：django-rest framework

接口：什麼是接口、restful接口規範（協議）

CBV（基於FBV的基礎上形成）、CBV生命周期源碼—-基於restful規範下的CBV接口

請求生命周期：請求組件、解析組件、響應組件

序列化組件（序列化、反序列化簡單來說就是對象轉為字符串、字符串轉為對象，目的是為傳輸數據（傳給別的語言或者存儲））

三大認證（重中之重）：認證（用戶是否合法）、權限（管理員、普通用戶）、頻率（次數過多限制）

其他組件（過濾、篩選、排序、分頁、路由）

1.接口

概念：聯繫兩個物質的媒介，完成信息的交互。在web程序中，聯繫前台頁面與後台數據庫的媒介。

web接口組成：

url：長得像返回數據的url鏈接。如api.baidu.map/search

（www.baidu.com不叫接口，叫url鏈接，訪問只能拿到主頁。api.baidu.map/search是接口，返回的是json數據）

請求參數：前台按照指定的key提供數據給後台。（必須是給定的，這樣後台才能以此提取數據再到數據庫查詢返回）

響應數據：後台與數據庫交互后，將數據反饋給前台。

因此，接口就是帶着請求參數訪問能夠得到響應數據的url鏈接。

接口 = url + 請求參數 + 響應數據

2.restful接口規範

接口規範：不同後台語言，使用同樣的接口返回同樣的數據。

如何寫接口：要寫url和響應數據。如果將請求參數也加上，就是在寫接口文檔。

兩大部分：

（1）url

1）用api關鍵字標識接口url。方式1：api.baidu.com；方式2:www.baudu.com/api

2）接口數據安全性決定優先選用https協議。

3）如果一個接口有多版本存在，需要在url中標識體現。如下的v1和v2

api.baidu.com/v1/….  api.baidu.com/v2/….

4）操作中的數據稱為資源，在url中資源一般採用複數形式，一個接口可以概括對該資源的多種操作方式。（一個url對應一個類，類裏面可以有多個請求方法）

可以對操作隱藏，並且復用性更強（寫動作了，只能適用這一個動作，不寫其他動作都可以用）如api.baidu.com/books    api.baidu.com/books/(pk)

5）請求方式有多種，用一個url處理如何讓保證不混亂——通過不同的請求方式標識不同操作資源的方式

/books      get     獲取所有

/books post   增加一個（多個）

/books/(pk) delete 刪除一個

/books/(pk)  put 整體更新一個  #改一個用戶

/books/(pk)  patch 局部更新一個 #改一個用戶的密碼

6）資源往往涉及數據的各種操作方式：篩選、排序、限制

api.baidu.com/books/?search=寶馬&ordering=-price&limit=3

（2）響應數據

1）http請求的響應會有響應狀態碼，接口用來返回操作的資源數據，也有自己操作數據結果的資源狀態碼（status 0代表操作資源成功，1代表操作失敗，2代表操作成功，但沒匹配結果）

注：資源狀態碼和http狀態碼不一樣，為前後台的約定

2）資源狀態碼的文字提示。

status ok “賬號有誤或者密碼有誤”

3）資源本身

results

注:刪除資源成功不做任何數據返回（只返回空字符串，連狀態碼、狀態信息都不返回）

4）不能直接返回的資源（子資源、圖片、視頻等資源），返回該資源的url鏈接。

https://api.baidu.com/v1/books?limit=3
get|post|delete|put|patch   
{
　　“status” : 0,
　　“msg” : “ok”,
　　“results”: [
{
　　“title”: “三國”,
　　“price”: 78,
　　“img”: “https://.....”   
　　　　}
　　]
}

3.django流程

（1）項目準備：

from django.http import JsonResponse
from django.views import View

class Book(View):

    def get(self, request, *args, **kwargs):
        return JsonResponse('get ok', safe=False)

    def post(self, request, *args, **kwargs):
        return JsonResponse('get ok', safe=False)   #safe默認為true，要返回字典。不是字典否則拋異常。

from django.conf.urls import url
from . import views    #注意在應用中導入視圖都是.   從當前應用中導入

urlpatterns = [
    url(r'^books/', views.Book.as_view()),
]

from django.db import models

class Book(models.Model):

    title = models.CharField(max_length=64)
    price = models.DecimalField(max_digits=5, decimal_places=2) #整數、小數位

    class Meta:    #嵌套類（給上級類添加功能或指定標準）
        
       db_table = 'book'    #自定義數據庫表名
        verbose_name = "book"   #給模型起個可讀的名字，默認是複數
        verbose_name_plural = verbose_name   #取消上面的複數

    def __str__(self):      #显示的內容
        return '<<%s>>' % self.title    

from django.contrib import admin
port models

admin.site.register(models.Book)

 （2）CBV的請求生命周期

請求如何到CBV下的get和post

a.請求過來，項目文件中路由分發給應用api的路由

b.應用分發路由走as_view函數。

views.Book.as_view()  保存一系列數據（request、args、**kwargs等）給Book對象，然後都給dispatch進行路由分發。

dispatch乾的事：判斷請求方式是否支持，然後返回（通過getattr）支持的這些請求方法（get、post等，在視圖中自定義get、post的返回值）的結果。

c.通過dispatch就執行了CBV下請求方式的結果，返回結果

4.django原生的接口、序列化

  六大基礎接口：獲取一個、獲取所有、增加一個、刪除一個、整體更新一個、局部更新一個

 十大接口：6大基礎、群增、群刪、整體群改、局部群改

JsonResponse返回時，中文會變成unicode，要加json_dumps_params={‘ensure_ascii’:False}選項。但在linux環境下的火狐瀏覽器，加了是亂碼。

filter返回queryset對象，對象里是個列表（表名：對象信息（有自定義str就是自定義的信息））。first取里第一個對象（相當於print(第一個對象)）values展示對應的對象里的值

<QuerySet [<Book: <<三國演義>>>]>                   #直接.filter

<<三國演義>>                                    #.first()

<QuerySet [{‘title’: ‘三國演義‘, ‘price’: Decimal(‘56.00’)}]>  #.values(‘title’,’price’)

{‘title’: ‘三國演義‘, ‘price’: Decimal(‘56.00’)}             #.values.first()  是個字典

 上面序列化的工作很麻煩。drf就是為了方便序列化的。

postman可以完成不同方式的請求：get、post、put等

postman發送數據包有三種方式：form-data、urlencoded、json. 原生django對urlencoded數據提交兼容。

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

【其他文章推薦】

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

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

※回頭車貨運收費標準

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

※超省錢租車方案

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