ARTS挑战week1

最新推荐文章于 2024-10-02 22:44:04 发布

王老师的技术小白

最新推荐文章于 2024-10-02 22:44:04 发布

阅读量239

点赞数

分类专栏： ARTS

本文链接：https://blog.csdn.net/weixin_39594476/article/details/95868153

版权

ARTS 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

Algorithm

题目：给定一个整数数组 nums 和一个目标值 target，请你在该数组中找出和为目标值的那两个整数，并返回他们的数组下标。
你可以假设每种输入只会对应一个答案。但是，你不能重复利用这个数组中同样的元素。

代码（Java实现）：
方法一（暴力破解）：

class Solution {
    public int[] twoSum(int[] nums, int target) {
        for(int i = 0; i < nums.length; i++)
        {
            for(int j = i + 1; j < nums.length; j++)
            {
                if ((nums[i] + nums[j]) == target)
                {
                    return new int[]{i, j};
                }
            }
        }
        return null;
    }
}

在这里插入图片描述
方法二（Hash映射）：

class Solution {
    public int[] twoSum(int[] nums, int target) {
        HashMap<Integer, Integer> map = new HashMap<Integer, Integer>();
        for(int i = 0; i < nums.length; i++)
        {
            map.put(nums[i], i);
        }
        int key;
        for(int j = 0; j < nums.length; j++)
        {
            int value = target - nums[j];
            
            if ((map.containsKey(value)) && (map.get(value) != j))
            {
                return new int[]{j, map.get(value)};
            }
        }
        return null;
    }
}

在这里插入图片描述

Review

Apache Kafka: Ten Best Practices to Optimize Your Deployment

（一）

Here are ten specific tips to help keep your Kafka deployment optimized and more easily managed:

Set log configuration parameters to keep logs manageable
Know Kafka’s (low) hardware requirements
Leverage Apache ZooKeeper to its fullest
Set up replication and redundancy the right way
Take care with topic configurations
Use parallel processing
Configure and isolate Kafka with security in mind
Avoid outages by raising the Ulimit
Maintain a low network latency
Utilize effective monitoring and alerts
Let’s look at each of these best practices in detail.

Set log configuration parameters to keep logs manageable

Kafka gives users plenty of options for log configuration and, while the default settings are reasonable, customizing log behavior to match your particular requirements will ensure that they don’t grow into a management challenge over the long term. This includes setting up your log retention policy, cleanups, compaction, and compression activities.

Log behavior can be controlled using the log.segment.bytes, log.segment.ms, and log.cleanup.policy (or the topic-level equivalent) parameters. If in your use case you don’t require past logs, you can have Kafka delete log files of a certain file size or after a set length of time by setting cleanup.policy to “delete.” You can also set it to “compact” to hold onto logs when required. It’s important to understand that running log cleanup consumes CPU and RAM resources; when using Kafka as a commit log for any length of time, be sure to balance the frequency of compactions with the need to maintain performance.

Compaction is a process by which Kafka ensures retention of at least the last known value for each message key (within the log of data for a single topic partition). The compaction operation works on each key in a topic to retain its last value, cleaning up all other duplicates.
在这里插入图片描述
Image 1 - The Kafka commit log compaction process (source)
翻译：
Kakfa给用户大量的日志配置选项并且默认设置也是合理的，使日志行为匹配你的特殊的需求将会确保它们在很长一段时间内不会进入到管理挑战。这包括了建立你的日志保留策略、清除、压缩和压缩活动。

日志行为可以使用参数控制使用日志块（可以以byte、ms为单位）和日志清除策略（或者是相同的主题的等级）。如果你使用的时候不需要过去的日志，你可以删除确定大小的日志文件或者进行定时清理。当你需要日志时，你可以设置Kafka的日志行为“compact”保留日志。重要的是要了解运行日志清理会消耗CPU和RAM资源; 当使用Kafka作为提交日志任何时间长度时，一定要平衡压缩的频率和维持性能的需要。

压缩是一个过程，kafka确认保留至少最新被知道的每一个消息的key（在一个单独的主题分区的日志数据中）。这个压缩行为工作在每一个主题的key上确保是最新的值，清除所有其他的副本。

Tips

Git Flow工作流程
通常来说，Git Flow工作流程会有Master、Develop、Feature、Hotfix、Release这五种分支类型。
Master、Develop分支：这两种分支均为主分支，其中Master分支为线上分支，Develop分支为开发分支，若有新的需求要开发则可以从Master分支上拉一个分支下来。

Feature分支：每一个新的功能都应该创建一个独立的分支，从develop分支中派生出来。当功能完成后，要合并（merged）回develop分支，合并后它的生命周期就结束。新功能分支不会与master分支有直接的交汇

Realease分支：一旦开发的功能已经满足发布条件（或预定发布日期接近），应该合并所有满足发布条件的新功能分支到develop分支中，然后，开出一个发布分支（Release），开始准备一个发布版本。在这个分支上，不能再添加新的功能，只有bug修复和该版本为导向的任务。一旦到了发布日期，Release就要合并回master发布，并且，打出版本标签。另外，还需要合并回develop分支。

Hotfix分支：这是直接从线上拉下来的一种分支，应对线上紧急Bug。

命名约定：
-主分支名称：master
-主开发分支名称：develop
-标签（tag）名称：v*.RELEASE，其中”“ 为版本号，“RELEASE”大写，如：v1.0.0.RELEASE
-新功能开发分支名称：feature-or feature/，其中“” 为新功能简述，如：feature-item-activity-list
-发布分支名称：release-or release/，其中为版本号，“release”小写，如：release-1.0.0
-master的bug修复分支名称：hotfix-or hotfix/，其中为bug简述，如：hotfix/item-update-bug

工作流程：
项目负责人从本地Master分支拉出一个Develop分支，并且推送到远端，其余开发人员从远端拉下Develop分支进行开发。当有一个新需求进来时，拉一个feature分支进行公用，开发完毕后合并回Develop分支并拉出一个Release分支进行测试，最后将Release分支合并会Master分支和Develop分支；当线上有紧急bug需要修复时则拉一个Hotfix分支下来，修改测试合并回master分支和develop分支上。

前后端分离：
附上其他大佬的链接：https://blog.csdn.net/u012954380/article/details/83141167

MySQL一周知识点总结：

一条mysql语句如何运行：
首先会进行数据库链接 =》进行查询缓存操作（可关闭）=》命中则返回，否则进行语法分析 =》优化器进行语句优化 =》执行语句 =》返回结果
日志系统：
redo log（固定大小，会重复写）：mysql进行更新操作时，并不会每次直接写入磁盘，而是会先更新内存，然后再将多次更新一次更改，redo log将会记录这些操作，保证crash save。
binlog：相当于备份
数据库提交流程：两阶段提交；原因：保证数据的一致性
隔离级别：
读未提交、读已提交（Oracle）、可重复读（Mysql默认）、串行化

Vue源码解读：