Algorithm

组合：https://leetcode-cn.com/problems/combinations/

组合：指 从 n 个不同元素中取出 m 个不同元素 (1=<m<=n) , 并不关心 m 个元素的排序问题

和排列区别：组合是不考虑 每个元素出现顺序的

对于所有 m 取值的组合的全集合（因为 1=<m<=n），我们可以叫作全组合（All Combination）

例如对于集合{1, 2, 3}而言，全组合就是{空集, {1}, {2}, {3}, {1, 2}, {1,3} {2, 3}, {1, 2, 3}}。

• n 个元素里取出 m 个的组合，可能性数量就是 n 个里取 m 个的排列数量，除以 m 个全排列的数量，也就是 (n! / (n-m)!) / m!。

• 对于全组合而言，可能性为 2^n 种。例如，当 n=3 的时候，全组合包括了 8 种情况

class Solution {    List<List<Integer>>  result=new ArrayList();    public List<List<Integer>> combine(int n, int k) {         if (k <= 0 || n < k) {            return result;        }        combineHelper(n,k,1,new ArrayList<>());        return result;    }
    private void combineHelper(int n,int k,int beginIndex,List<Integer> curResult){
        if(curResult.size() == k){            result.add(new ArrayList<>(curResult));            return;        }         // curIndex指的是 每次选择的位置，用这个位置不断缩小 下一层 所选择的范围        for(int i=beginIndex;i<=n;i++){
            curResult.add(i);            combineHelper(n,k,i+1,curResult);            curResult.remove(curResult.size()-1);
        }
    }
}

Review

今天看的英文文章是 耗子叔在专栏里推荐的分布式系统扩展性的文章https://aosabook.org/en/v2/distsys.html

大概的分布式架构是怎么来解决系统扩展性问题的粗略方法

。

构建和运营可扩展的网站或应用程序究竟意味着什么？

从基本层面来看，它只是通过互联网连接用户与远程资源，使其可扩展的部分在于这些资源或对这些资源的访问被分布在多个服务器上。

与生活中的大多数事情一样，在构建网络服务时提前规划可以在长期内提供帮助。了解大型网站背后的一些考虑因素和权衡可以在创建较小网站时做出更明智的决策。以下是影响大规模网络系统设计的一些关键原则：

• 可用性：网站的正常运行时间对许多公司的声誉和功能至关重要。对于一些较大的在线零售网站，即使短短几分钟不可用，也可能导致数千万美元的营收损失，因此，将系统设计成始终可用且对故障具有弹性既是基本的业务要求，也是技术要求。分布式系统中的高可用性需要仔细考虑关键组件的冗余、部分系统故障时的快速恢复以及出现问题时的渐进降级。

• 性能：对大多数网站而言，网站性能已成为重要的考虑因素。网站的速度影响使用情况和用户满意度，还直接关系到搜索引擎排名，而这直接与收入和用户保留率相关。因此，创建一个针对快速响应和低延迟进行优化的系统至关重要。

• 可靠性：系统需要具有可靠性，即对数据的请求将始终返回相同的数据。如果数据发生更改或更新，那么相同的请求应返回新数据。用户需要知道，如果将某些内容写入系统或存储，它将持续存在，并可依赖于将来检索。 数据的一致性

• 可扩展性：对于任何大型分布式系统来说，规模只是需要考虑的尺度的一方面。同样重要的是增加容量以处理更大负载的工作，通常称为系统的可扩展性。可扩展性可以涉及系统的许多不同参数：它可以处理多少额外的流量，如何轻松地增加存储容量，甚至可以处理多少更多的交易。

• 可管理性（可维护性）：设计一个易于操作的系统是另一个重要的考虑因素。系统的可管理性等同于运营的可扩展性：维护和更新。需要考虑可管理性的因素包括在出现问题时诊断和理解问题的难易程度、进行更新或修改的便捷性以及系统的操作简易程度（即，它是否经常无故障或异常地运行）。

• 成本：成本是一个重要因素。这显然包括硬件和软件成本，但还需要考虑部署和维护系统所需的其他方面。需要考虑的因素包括构建系统所需的开发人员时间、运行系统所需的操作工作量，甚至所需的培训量。成本是总体拥有成本。

每个原则都为设计分布式 Web 架构的决策提供了基础。然而，它们之间也可能存在矛盾，因此实现一个目标可能会以另一个目标为代价。一个基本的例子是：选择通过简单地添加更多服务器来处理容量（可扩展性）可能会以可管理性（您必须运行额外的服务器）和成本（服务器的价格）为代价。

在设计任何类型的 Web 应用程序时，重要的是考虑这些关键原则，即使是要承认设计可能会牺牲其中一个或多个原则。

Tip

最近看了依赖包加载顺序，并做了几个总结

涉及的名词

• 依赖版本：指 dependencies 中直接依赖所指定的版本号

• 管理版本：指 dependencyManagement 中管理的版本好

• 本级：指当前工程

• 上级：指 parent 依赖的 jar

• 下级：指本级引用的 jar

当存在一个包有多个相同的版本时候，哪个依赖版本在工程最终生效

基于两个原则，首先依赖分为直接依赖和本地依赖

直接依赖指的是本工程内的 pom 文件中直接引入的依赖，也称为本地依赖

间接依赖指的是 pom 文件引入的依赖包 中 的依赖：也称为传递依赖

整体原则是

直接依赖优先级> 间接依赖

具体一点：本地依赖>本级版本管理>上级管理版本>下级依赖版本

在直接依赖中

1. 同 POM 文件中 ，后加载的优先级>先加载，会覆盖

2. pom 中直接依赖的版本>父 pom 中的管理版本，除非不指定版本号会用父 pom 中管理的版本号

间接依赖中

1. 遵循最短路径原则：层级越少的，优先级越高。如果路径相同，先加载>后加载的

一般在工程目录通过命令行工具执行 mvn dependency:tree 查看依赖树。或者在工程 IDEA 中安装 Maven Helper 插件

依赖范围 Scope

依赖范围一共包括如下几种，分别代表的是 jar 包在什么环节要被引入。

• compile 这个是默认的依赖范围，代表从编译阶段就需要被引入。

• provided 这个代表该依赖在运行时runtime是由 jdk 或者容器来提供，无需引入。因此provided的包只有在本地编译和测试环节才会被引入，运行时不会被引入。比如我们常见的 servlet-api 的包，就会申明为 provided 阶段。

• runtime 运行时依赖，代表这个包在编译的时候是不需要的，只有在运行时以及测试时才需要被依赖。

• test 代表这个包在生产环境是不需要的，只有在执行 test 时才需要。

Share

今天看了连岳的一片公众号文章，讲人生变强的唯一节奏，觉得有所收获,共勉之

世界上绝大数工作，都是日常平庸的，不需要特别高的智商，一般人哪怕天资愚笨，经过努力训练，也可以胜任并做出一定成就。

世界上绝大多数的人，都并非特别聪明，甚至或多或少 某种程度有点愚、有点柔。

别怕自己笨，要行动，多重复几次，就不笨了。聪明人做一次，我做百次、千次总是可以的

正所谓 人一能之，己百之。人十能之，己千之。果能此道矣，虽愚必明，虽柔必强。《中庸》

孔子都认为自己是普通资质，我们也要勇敢承认 ，笨并不可怕、弱也不可怕

怕的是懒。不敢行动、懒于行动，勤能补拙。 懒是绝路，一次不做就毫无希望，只能变得更笨和更弱

对于我们愚笨或者柔弱者来说，得先承认自己的笨拙和柔弱并勇于面对它。而我们往往要装的聪明又强大，还会刻意懒惰，显得自己一出手就能有所成就、成事。 这样又多了一层伪，真是可笑又没救。

所以我们最好的办法，就是预设自己并不聪明，天天都做点事，百次千次的做那些正确的事情，这是好的人生节奏