2020-01-12-ARTS-一月第二周


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 次或多次)时,我们才认定 “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;

/**
 * 字符串的最大公因子
 * 

* 题目总结: * 1、考查内容为 辗转相除大法 * 2. 理解题目中除尽的含义 *

* 解题思路中总结: * 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())); } /** * 使用“辗转相除法”计算两个字符串长度的最大公约数 *

* 欧几里德算法又称辗转相除法,是指用于计算两个正整数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、截取字符串
  使用“辗转相除法”计算两个字符串长度的最大公约数
  

欧几里德算法又称辗转相除法,是指用于计算两个正整数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列表如下:

Endpoint ID Description
auditevents 显示应用暴露的审计事件 (比如认证进入、订单失败)
info 显示应用的基本信息
health 显示应用的健康状态
metrics 显示应用多样的度量信息
loggers 显示和修改配置的loggers
logfile 返回log file中的内容(如果logging.file或者logging.path被设置)
httptrace 显示HTTP足迹,最近100个HTTP request/repsponse
env 显示当前的环境特性
flyway 显示数据库迁移路径的详细信息
liquidbase 显示Liquibase 数据库迁移的纤细信息
shutdown 让你逐步关闭应用
mappings 显示所有的@RequestMapping路径
scheduledtasks 显示应用中的调度任务
threaddump 执行一个线程dump
heapdump 返回一个GZip压缩的JVM堆dump

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存储模型图如下:

img

image.png

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、异常监控。--属于运维层面措施

---至此结束。

你可能感兴趣的:(2020-01-12-ARTS-一月第二周)