一、Algorithm

本周算法完成如下：

1.1 题目来源【Leetcode[1071】

1.2 题目描述

• 字符串的最大公因子

对于字符串 S 和 T，只有在 S = T + ... + T（T 与自身连接 1 次或多次）时，我们才认定 “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
著作权归领扣网络所有。商业转载请联系官方授权，非商业转载请注明出处。

1.3 解题过程

package cn.mayday.algorithms.day20200113;

/**
 * 字符串的最大公因子
 * <p>
 * 题目总结：
 * 1、考查内容为 辗转相除大法
 * 2. 理解题目中除尽的含义
 * <p>
 * 解题思路中总结:
 * 1、根据题目，如果存在最大公约数，那么str1+str2 = str2+str1
 * 2、根据辗转相除法求得两个字符串长度的最大公约数
 * 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()));
    }

    /**
     * 使用“辗转相除法”计算两个字符串长度的最大公约数
     * <p>
     * 欧几里德算法又称辗转相除法，是指用于计算两个正整数a，b的最大公约数。
     * 应用领域有数学和计算机两个方面。计算公式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 题目总结

这道题考核对最大公约数的理解，归根到底为辗转相除大法

解题思路中总结:

  1、根据题目，如果存在最大公约数，那么str1+str2 = str2+str1
  2、根据辗转相除法求得两个字符串长度的最大公约数
  3、截取字符串

  使用“辗转相除法”计算两个字符串长度的最大公约数
  <p>
  欧几里德算法又称辗转相除法，是指用于计算两个正整数a，b的最大公约数。
  应用领域有数学和计算机两个方面。计算公式gcd(a,b) = gcd(b,a mod b)。

二、Review

2.1 文章内容

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

阅读相关官方文档，学习SpringBoot-Actuator的使用。

三、Tip

生产系统中，往往需要对系统实际运行的情况（例如cpu、io、disk、db、业务功能等指标）进行监控运维。在SpringBoot项目中Actuator模块提供了众多HTTP接口端点（Endpoint），来提供应用程序运行时的内部状态信息。

Actuator模块提供了一个监控和管理生产环境的模块，可以使用http、jmx、ssh、telnet等来管理和监控应用。包括应用的审计（Auditing）、健康（health）状态信息、数据采集（metrics gathering）统计等监控运维的功能。同时，提供了可以扩展 Actuator端点（Endpoint）自定义监控指标。这些指标都是以JSON接口数据的方式呈现。

SpringBoot的Actuator模块实现了应用的监控与管理，本周学习梳理了SpringBoot的Actuator模块使用。

详细总结内容移步个人总结博文SpringBoot之Actuator。

Endpoints列表如下：

3.1 附 官方学习文档

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内容

本周分享内容为关于常用消息中间件面对消息堆积的处理能力理解。详细分享见个人总结博客文章《精进消息中间件原理系列(一)：之消息堆积》。

部分总结如下：

4.2 延伸一：为什么说RabbitMQ，对消息堆积的支持并不好？

而RabbitMQ在介绍优缺点时，消息堆积作为缺点之一：

RabbitMQ 对消息堆积的支持并不好，在它的设计理念里面，消息队列是一个管道，大量的消息积压是一种不正常的情况，应当尽量去避免。当大量消息积压的时候，会导致 RabbitMQ 的性能急剧下降

4.2.1 从存储模型来理解

关于消息队列对于消息堆积的堆积能力，还需要从消息队列的存储模型来分析：

• 1、 RabbitMQ：内存、磁盘都保存，消息保存到内存中，通过镜像队列保证HA，通过磁盘存储保证持久化。但由于内存队列中需要保存所有完整的消息本地，因此当消息堆积太多时，会使得内存空间不可用，严重可能内存溢出，服务宕机。

​ —–即 内存、磁盘，支持少量堆积

• 2、 RocketMQ：消息持久化保存到磁盘中，且消费队列本身不保存消息本地，保存消息磁盘索引，通过FileChannel的MMAP机制实现内存映射，处理消息时能达到基本和内存相同的效率。设置同步复制和同步刷盘即可保存消息不丢失。

​ —–即 磁盘+内存映射技术，支持大量堆积。【磁盘空间还是足够富裕的】

• 3、 Kafka：同RocketMQ。

  附：RocketMQ存储模型图如下：

4.3 如何预防消息堆积

在消息的收发两端，我们的业务代码怎么和消息队列配合，达到一个最佳的性能。

4.3.1、发送端性能优化

从消息堆积若干原因来看，消息堆积的原因主要在消费端处理上，本身生产者端应该遵循的原则应该是尽可能快的将消息发送到Broker中去，因此发送端除了业务处理时批量发送暂无好的手段优化，而且并不是所有的业务处理都支持批量发送和批量接收处理。

发送端业务代码的处理性能，实际上和消息队列的关系不大，因为一般发送端都是先执行自己的业务逻辑，最后再发送消息。如果说，你的代码发送消息的性能上不去，你需要优先检查一下，是不是发消息之前的业务逻辑耗时太多导致的。

• 批量发送是发送端预防消息堆积的方式之一。

4.3.2、消费端性能优化

在设计系统的时候，一定要保证消费端的消费性能要高于生产端的发送性能，这样的系统才能健康的持续运行。

• 方式1 增加单个消费者处理能力

  增加单个消费者的处理能力这块没有绝对的办法，只能尽可能的优化消息处理业务逻辑的能力，减少不必要的非业务相关处理时间消耗；如果消息处理业务已经优化到无法再优化了，那只能通过方式2水平扩展消费者个数来优化。

• 注意：部分同学采用在业务处理OnMessage时，先将消息保存到内存队列中，再开启线程池并发处理内存队列缓存消息这种方式（即通过内存队列增加一个异步环节）—–这种方式存在丢消息的风险，如果消费节点宕机，内存队列中的消息直接丢失。慎用这种方式。

• 方式2 水平扩容消费者个数

消费端的性能优化除了优化消费业务逻辑以外，也可以通过水平扩容，增加消费端的并发数来提升总体的消费性能。

注意：水平扩容是应保证 扩容后消费者个数<=分区或者队列个数

反过来，即如果扩容后消费者个数超过分区或者队列个数后，再扩容已经没有意义。—因为单个消费队列同一时间内只能被一个消费者消费，再多的消费者也没有用。

此时，需要在Broker中同步增加分区或者队列个数，扩容消费者才有意义。

补充：Kafka中叫分区Partition，RocketMQ和RabbitMQ中叫队列Queue

4.4 消息已经堆积，如何快速处理

如果消息已经堆积了，线上如何快速处理。对于系统发生消息积压的情况，需要先解决积压，再分析原因，毕竟保证系统的可用性是首先要解决的问题。

快速解决积压的方法就是通过水平扩容增加 Consumer 的实例数量，以及其他方式如下。

• 1、消费端扩容；–通用方式
• 2、服务降级；–快速失败，不一定适用所有业务场景
• 3、异常监控。–属于运维层面措施

—至此结束。

• Previous
  精进消息中间件原理系列(一)：之消息堆积
• Next
  秒杀