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存储模型图如下:
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、异常监控。--属于运维层面措施
---至此结束。