layout: post
title: ARTS-2020一月第二周
subtitle: 一月第二周ARTS
date: 2020-01-12
author: Mayday
header-img: img/post-bg-hacker.jpg
catalog: true
tags:
- ARTS計劃

一肩豁、Algorithm

本周算法完成如下：

1.1 題目來源【Leetcode[1071】

1.2 題目描述

• 字符串的最大公因子

對于字符串 S 和 T昔馋，只有在 S = T + ... + T（T 與自身連接 1 次或多次）時，我們才認(rèn)定 “T 能除盡 S”叉瘩。

返回字符串 X，要求滿足 X 能除盡 str1 且 X 能除盡 str2络它。

示例 1：

輸入：str1 = "ABCABC", str2 = "ABC"
輸出："ABC"

示例 2：

輸入：str1 = "ABABAB", str2 = "ABAB"
輸出："AB"

示例 3：

輸入：str1 = "LEET", str2 = "CODE"
輸出：""

 

提示：

    1 <= str1.length <= 1000
    1 <= str2.length <= 1000
    str1[i] 和 str2[i] 為大寫英文字母

來源：力扣（LeetCode）
鏈接：https://leetcode-cn.com/problems/greatest-common-divisor-of-strings
著作權(quán)歸領(lǐng)扣網(wǎng)絡(luò)所有诉瓦。商業(yè)轉(zhuǎn)載請聯(lián)系官方授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處殿怜。

1.3 解題過程

package cn.mayday.algorithms.day20200113;

/**
 * 字符串的最大公因子
 * <p>
 * 題目總結(jié)：
 * 1、考查內(nèi)容為 輾轉(zhuǎn)相除大法
 * 2. 理解題目中除盡的含義
 * <p>
 * 解題思路中總結(jié):
 * 1曙砂、根據(jù)題目头谜，如果存在最大公約數(shù)，那么str1+str2 = str2+str1
 * 2鸠澈、根據(jù)輾轉(zhuǎn)相除法求得兩個字符串長度的最大公約數(shù)
 * 3柱告、截取字符串
 *
 * @author Mayday05
 * @date 2020/1/13 14:14
 */
public class Leetcode1071GcdOfStrings {

    public static void main(String[] args) {
        Leetcode1071GcdOfStrings object = new Leetcode1071GcdOfStrings();
        // test1
        System.out.println(object.gcdOfStrings("ABCABC","ABC"));
        // test2
        System.out.println(object.gcdOfStrings("ABABAB","ABAB"));
        // test3
        System.out.println(object.gcdOfStrings("LEET","CODE"));

    }

    public String gcdOfStrings(String str1, String str2) {
        if (str1 == null || str2 == null) {
            return null;
        }
        if (!(str1 + str2).equals(str2 + str1)) {
            return "";
        }
        return str1.substring(0, gcd(str1.length(), str2.length()));
    }

    /**
     * 使用“輾轉(zhuǎn)相除法”計算兩個字符串長度的最大公約數(shù)
     * <p>
     * 歐幾里德算法又稱輾轉(zhuǎn)相除法砖织，是指用于計算兩個正整數(shù)a，b的最大公約數(shù)末荐。
     * 應(yīng)用領(lǐng)域有數(shù)學(xué)和計算機(jī)兩個方面侧纯。計算公式gcd(a,b) = gcd(b,a mod b)。
     *
     * @param length1
     * @param length2
     * @return
     */
    private int gcd(int length1, int length2) {
        if (length1 == 0) {
            return length2;
        }
        if (length2 == 0) {
            return length1;
        }
        return gcd(length2, length1 % length2);
    }
}

1.4 題目總結(jié)

這道題考核對最大公約數(shù)的理解甲脏，歸根到底為輾轉(zhuǎn)相除大法

解題思路中總結(jié):

  1眶熬、根據(jù)題目，如果存在最大公約數(shù)块请，那么str1+str2 = str2+str1
  2娜氏、根據(jù)輾轉(zhuǎn)相除法求得兩個字符串長度的最大公約數(shù)
  3、截取字符串

  使用“輾轉(zhuǎn)相除法”計算兩個字符串長度的最大公約數(shù)
  <p>
  歐幾里德算法又稱輾轉(zhuǎn)相除法墩新，是指用于計算兩個正整數(shù)a贸弥，b的最大公約數(shù)。
  應(yīng)用領(lǐng)域有數(shù)學(xué)和計算機(jī)兩個方面海渊。計算公式gcd(a,b) = gcd(b,a mod b)绵疲。

二、Review

2.1 文章內(nèi)容

翻譯源 Spring Boot Actuator: Health check, Auditing, Metrics gathering and Monitoring

閱讀相關(guān)官方文檔臣疑，學(xué)習(xí)SpringBoot-Actuator的使用盔憨。

三、Tip

生產(chǎn)系統(tǒng)中讯沈，往往需要對系統(tǒng)實際運行的情況（例如cpu郁岩、io、disk缺狠、db问慎、業(yè)務(wù)功能等指標(biāo)）進(jìn)行監(jiān)控運維。在SpringBoot項目中Actuator模塊提供了眾多HTTP接口端點（Endpoint）挤茄，來提供應(yīng)用程序運行時的內(nèi)部狀態(tài)信息如叼。

Actuator模塊提供了一個監(jiān)控和管理生產(chǎn)環(huán)境的模塊，可以使用http驮樊、jmx薇正、ssh、telnet等來管理和監(jiān)控應(yīng)用囚衔。包括應(yīng)用的審計（Auditing）、健康（health）狀態(tài)信息雕沿、數(shù)據(jù)采集（metrics gathering）統(tǒng)計等監(jiān)控運維的功能练湿。同時，提供了可以擴(kuò)展 Actuator端點（Endpoint）自定義監(jiān)控指標(biāo)审轮。這些指標(biāo)都是以JSON接口數(shù)據(jù)的方式呈現(xiàn)肥哎。

SpringBoot的Actuator模塊實現(xiàn)了應(yīng)用的監(jiān)控與管理辽俗，本周學(xué)習(xí)梳理了SpringBoot的Actuator模塊使用。

詳細(xì)總結(jié)內(nèi)容移步個人總結(jié)博文SpringBoot之Actuator篡诽。

Endpoints列表如下：

3.1 附 官方學(xué)習(xí)文檔

1杈女、Spring Boot Actuator: Production-ready Features 見 https://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-features.html#production-ready-endpoints

Spring Boot Actuator: Production-ready Features 見 https://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-features.html#production-ready-endpoints

2朱浴、Micrometer: Spring Boot 2’s new application metrics collector

3.2 附：用戶案例地址

1、github地址actuator-demo

四达椰、Share

4.1 share內(nèi)容

本周分享內(nèi)容為關(guān)于常用消息中間件面對消息堆積的處理能力理解翰蠢。詳細(xì)分享見個人總結(jié)博客文章《精進(jìn)消息中間件原理系列(一)：之消息堆積》。

部分總結(jié)如下：

4.2 延伸一：為什么說RabbitMQ啰劲，對消息堆積的支持并不好梁沧？

而RabbitMQ在介紹優(yōu)缺點時，消息堆積作為缺點之一：

RabbitMQ 對消息堆積的支持并不好蝇裤，在它的設(shè)計理念里面廷支，消息隊列是一個管道，大量的消息積壓是一種不正常的情況栓辜，應(yīng)當(dāng)盡量去避免酥泞。當(dāng)大量消息積壓的時候，會導(dǎo)致 RabbitMQ 的性能急劇下降

4.2.1 從存儲模型來理解

關(guān)于消息隊列對于消息堆積的堆積能力啃憎，還需要從消息隊列的存儲模型來分析：

• 1芝囤、 RabbitMQ：內(nèi)存、磁盤都保存辛萍，消息保存到內(nèi)存中悯姊，通過鏡像隊列保證HA，通過磁盤存儲保證持久化贩毕。但由于內(nèi)存隊列中需要保存所有完整的消息本地悯许，因此當(dāng)消息堆積太多時，會使得內(nèi)存空間不可用辉阶，嚴(yán)重可能內(nèi)存溢出先壕，服務(wù)宕機(jī)。

? -----即 內(nèi)存谆甜、磁盤垃僚，支持少量堆積

• 2、 RocketMQ：消息持久化保存到磁盤中规辱，且消費隊列本身不保存消息本地谆棺，保存消息磁盤索引，通過FileChannel的MMAP機(jī)制實現(xiàn)內(nèi)存映射罕袋，處理消息時能達(dá)到基本和內(nèi)存相同的效率改淑。設(shè)置同步復(fù)制和同步刷盤即可保存消息不丟失碍岔。

? -----即 磁盤+內(nèi)存映射技術(shù)，支持大量堆積朵夏“玻【磁盤空間還是足夠富裕的】

• 3、 Kafka：同RocketMQ仰猖。

附：RocketMQ存儲模型圖如下：

img

image.png

4.3 如何預(yù)防消息堆積

在消息的收發(fā)兩端捏肢，我們的業(yè)務(wù)代碼怎么和消息隊列配合，達(dá)到一個最佳的性能亮元。

4.3.1猛计、發(fā)送端性能優(yōu)化

從消息堆積若干原因來看，消息堆積的原因主要在消費端處理上爆捞，本身生產(chǎn)者端應(yīng)該遵循的原則應(yīng)該是盡可能快的將消息發(fā)送到Broker中去奉瘤，因此發(fā)送端除了業(yè)務(wù)處理時批量發(fā)送暫無好的手段優(yōu)化，而且并不是所有的業(yè)務(wù)處理都支持批量發(fā)送和批量接收處理煮甥。

發(fā)送端業(yè)務(wù)代碼的處理性能盗温，實際上和消息隊列的關(guān)系不大，因為一般發(fā)送端都是先執(zhí)行自己的業(yè)務(wù)邏輯成肘，最后再發(fā)送消息卖局。如果說，你的代碼發(fā)送消息的性能上不去双霍，你需要優(yōu)先檢查一下砚偶，是不是發(fā)消息之前的業(yè)務(wù)邏輯耗時太多導(dǎo)致的。

• 批量發(fā)送是發(fā)送端預(yù)防消息堆積的方式之一洒闸。

4.3.2染坯、消費端性能優(yōu)化

在設(shè)計系統(tǒng)的時候，一定要保證消費端的消費性能要高于生產(chǎn)端的發(fā)送性能丘逸，這樣的系統(tǒng)才能健康的持續(xù)運行单鹿。

• 方式1 增加單個消費者處理能力

  增加單個消費者的處理能力這塊沒有絕對的辦法，只能盡可能的優(yōu)化消息處理業(yè)務(wù)邏輯的能力深纲，減少不必要的非業(yè)務(wù)相關(guān)處理時間消耗仲锄；如果消息處理業(yè)務(wù)已經(jīng)優(yōu)化到無法再優(yōu)化了，那只能通過方式2水平擴(kuò)展消費者個數(shù)來優(yōu)化湃鹊。

• 注意：部分同學(xué)采用在業(yè)務(wù)處理OnMessage時儒喊，先將消息保存到內(nèi)存隊列中，再開啟線程池并發(fā)處理內(nèi)存隊列緩存消息這種方式（即通過內(nèi)存隊列增加一個異步環(huán)節(jié)）-----這種方式存在丟消息的風(fēng)險涛舍，如果消費節(jié)點宕機(jī)澄惊，內(nèi)存隊列中的消息直接丟失。慎用這種方式富雅。

• 方式2 水平擴(kuò)容消費者個數(shù)

消費端的性能優(yōu)化除了優(yōu)化消費業(yè)務(wù)邏輯以外掸驱，也可以通過水平擴(kuò)容，增加消費端的并發(fā)數(shù)來提升總體的消費性能没佑。

注意：水平擴(kuò)容是應(yīng)保證 擴(kuò)容后消費者個數(shù)<=分區(qū)或者隊列個數(shù)

反過來毕贼，即如果擴(kuò)容后消費者個數(shù)超過分區(qū)或者隊列個數(shù)后，再擴(kuò)容已經(jīng)沒有意義蛤奢。---因為單個消費隊列同一時間內(nèi)只能被一個消費者消費鬼癣，再多的消費者也沒有用。

此時啤贩，需要在Broker中同步增加分區(qū)或者隊列個數(shù)待秃，擴(kuò)容消費者才有意義。

補充：Kafka中叫分區(qū)Partition痹屹，RocketMQ和RabbitMQ中叫隊列Queue

4.4 消息已經(jīng)堆積章郁，如何快速處理

如果消息已經(jīng)堆積了，線上如何快速處理志衍。對于系統(tǒng)發(fā)生消息積壓的情況暖庄，需要先解決積壓，再分析原因楼肪，畢竟保證系統(tǒng)的可用性是首先要解決的問題培廓。

快速解決積壓的方法就是通過水平擴(kuò)容增加 Consumer 的實例數(shù)量，以及其他方式如下春叫。

• 1肩钠、消費端擴(kuò)容；--通用方式
• 2暂殖、服務(wù)降級价匠；--快速失敗，不一定適用所有業(yè)務(wù)場景
• 3央星、異常監(jiān)控霞怀。--屬于運維層面措施

---至此結(jié)束。