真正的大师永远怀着一颗学徒的心

引言

对于一个软件平台来说，软件平台代码的好坏直接影响平台整体的质量与稳定性。同时也会影响着写代码同学的创作激情。想象一下如果你从git上面clone下来的的工程代码乱七八糟，代码晦涩难懂，难以快速入手，有种想推到重写的冲动，那么程序猿在这个工程中写好代码的初始热情都没了。相反，如果clone下的代码结构清晰，代码优雅易懂，那么你在写代码的时候都不好意思写烂代码。这其中的差别相信工作过的同学都深有体会，那么我们看了那么多代码之后，到底什么样的代码才是好代码呢？它们有没有一些共同的特征或者原则？本文通过阐述优雅代码的设计原则来和大家聊聊怎么写好代码。

代码设计原则

好代码是设计出来的，也是重构出来的，更是不断迭代出来的。在我们接到需求，经过概要设计过后就要着手进行编码了。但是在实际编码之前，我们还需要进行领域分层设计以及代码结构设计。那么怎么样才能设计出来比较优雅的代码结构呢？有一些大神们总结出来的优雅代码的设计原则，我们分别来看下。

SRP

所谓SRP（Single Responsibility Principle）原则就是职责单一原则，从字面意思上面好像很好理解，一看就知道什么意思。但是看的会不一定就代表我们就会用，有的时候我们以为我们自己会了，但是在实际应用的时候又会遇到这样或者那样的问题。原因就是实际我们没有把问题想透，没有进行深度思考，知识还只是知识，并没有转化为我们的能力。就比如这里所说的职责单一原则指的是谁的单一职责，是类还是模块还是域呢？域可能包含多个模块，模块也可以包含多个类，这些都是问题。

为了方便进行说明，这里以类来进行职责单一设计原则的说明。对于一个类来说，如果它只负责完成一个职责或者功能，那么我们可以说这个类时符合单一职责原则。请大家回想一下，其实我们在实际的编码过程中，已经有意无意的在使用单一职责设计原则了。因为实际它是符合我们人思考问题的方式的。为什么这么说呢？想想我们在整理衣柜的时候，为了方便拿衣服我们会把夏天的衣服放在一个柜子中，冬天的衣服放在一个柜子。这样季节变化的时候，我们只要到对应的柜子直接拿衣服就可以了。否则如果冬天和夏天的衣服都放在一个柜子中，我们找衣服的时候可就费劲了。放到软件代码设计中，我们也需要采用这样的分类思维。在进行类设计的时候，要设计粒度小、功能单一的类，而不是大而全的类。

举个栗子，在学生管理系统中，如果一个类中既有学生信息的操作比如创建或者删除动作，又有关于课程的创建以及修改动作，那么我们可以认为这个类时不满足单一职责的设计原则的，因为它将两个不同业务域的业务混杂在了一起，所以我们需要进行拆分，将这个大而全的类拆分为学生以及课程两个业务域，这样粒度更细，更加内聚。

笔者根据自身的经验，总结了需要考虑进行单一职责拆分的几个场，希望对大家判断是否需要进行拆分有个简单的判断的标准： 1、不同的业务域需要进行拆分，就像上面的例子，另外如果与其他类的依赖过多，也需要考虑是不是应该进行拆分； 2、如果我们在类中编写代码的时候发现私有方法具有一定的通用性，比如判断ip是不是合法，解析xml等，那我们可以考虑将这些方法抽出来形成公共的工具类，这样其他类也可以方便的进行使用。 另外单一职责的设计思想不止在代码设计中使用，我们在进行微服务拆分的时候也会一定程度的遵循这个原则。

OCP

OCP（Open Closed Principle）即对修改关闭，对扩展开放原则，个人觉得这是设计原则中最难的原则。不仅理解起来有一定的门槛，在实际编码过程中也是不容易做到的。 首先我们得先搞清楚这里的所说的修改以及扩展的区别在什么地方，说实话一开始看到这个原则的时候，我总觉得修改和开放说的不是一个意思嘛？想来想去都觉得有点迷糊。后来在不断的项目实践中，对这个设计原则的理解逐渐加深了。

设计原则中所说的修改指的是对原有代码的修改，而扩展指的是在原有代码基础上的能力的扩展，并不修改原先已有的代码。这是修改与扩展的最大的区别，一个需要修改原来的代码逻辑，另一个不修改。因此才叫对修改关闭但是对扩展开放。弄清楚修改和扩展的区别之后，我们再想一想为什么要对修改关闭，而要对扩展开放呢？ 我们都知道软件平台都是不断进行更新迭代的，因此我们需要不断在原先的代码中进行开发。那么就会涉及到一个问题如果我们的代码设计的不好，扩展性不强，那么每次进行功能迭代的时候都会修改原先已有的代码，有修改就有可能引入bug，造成系统平台的不稳定。因此我们为了平台的稳定性，需要对修改关闭。但是我们要添加新的功能怎么办呢？那就是通过扩展的方式来进行，因此需要实现对扩展开放。

这里我们以一个例子来进行说明，否则可能还是有点抽象。在一个监控平台中，我们需要对服务所占用CPU、内存等运行信息进行监控，第一版代码如下。

public class Alarm {
    private AlarmRule alarmRule;
    private AlarmNotify alarmNotify;
    
    public Alarm(AlarmRule alarmRule, AlarmNotify alarmNotify) {
        this.alarmRule = alarmRule;
        this.alarmNotify = alarmNotify;
    }
    
    public void checkServiceStatus(String serviecName, int cpu, int memory) {
        if(cpu > alarmRule.getRule(ServiceConstant.Status).getCpuThreshold) {
            alarmNotify.notify(serviecName +  alarmRule.getRule(ServiceConstant.Status).getDescription)
        }
        
         if(memory > alarmRule.getRule(ServiceConstant.Status).getMemoryThreshold) {
            alarmNotify.notify(serviecName +  alarmRule.getRule(ServiceConstant.Status).getDescription)
        } 
    
    }

}

代码逻辑很简单，就是根据对应的告警规则中的阈值判断是否达到触发告警通知的条件。如果此时来了个需求，需要增加判断的条件，就是根据服务对应的状态，判断需不需要进行告警通知。我们来先看下比较low的修改方法。我们在checkServiceStatus方法中增加了服务状态的参数，同事在方法中增加了判断状态的逻辑。

public class Alarm {
    private AlarmRule alarmRule;
    private AlarmNotify alarmNotify;
    
    public Alarm(AlarmRule alarmRule, AlarmNotify alarmNotify) {
        this.alarmRule = alarmRule;
        this.alarmNotify = alarmNotify;
    }
    
    public void checkServiceStatus(String serviecName, int cpu, int memory， int status) {
        if(cpu > alarmRule.getRule(ServiceConstant.Status).getCpuThreshold) {
            alarmNotify.notify(serviecName +  alarmRule.getRule(ServiceConstant.Status).getDescription)
        }
        
         if(memory > alarmRule.getRule(ServiceConstant.Status).getMemoryThreshold) {
            alarmNotify.notify(serviecName +  alarmRule.getRule(ServiceConstant.Status).getDescription)
        } 
        
         if(status == alarmRule.getRule(ServiceConstant.Status).getStatusThreshold) {
            alarmNotify.notify(serviecName +  alarmRule.getRule(ServiceConstant.Status).getDescription)
        } 
    
    }

}

很显然这种修改方法非常的不友好，为什么这么说呢？首先修改了方法参数，那么调用该方法的地方可能也需要修改，另外如果改方法有单元测试方法的话，单元测试用例必定也需要修改，在原有测试过的代码中添加新的逻辑，也增加了bug引入的风险。因此这种修改的方式我们需要进行避免。那么怎么修改才能够体现对修改关闭以及对扩展开放呢？ 首先我们可以先将关于服务状态的属性抽象为一个ServiceStatus 实体，在对应的检查方法中以ServiceStatus 为入参，这样以后如果还有服务状态的属性增加的话，只需要在ServiceStatus 中添加即可，并不需要修改方法中的参数以及调用方法的地方，同样单元测试的方法也不用修改。

@Data
public class ServiceStatus {
    String serviecName;
    int cpu;
    int memory;
    int status;

}

另外在检测方法中，我们怎么修改才能体现可扩展呢？而不是在检测方法中添加处理逻辑。一个比较好的实现方式就是通过抽象检测方法，具体的实现在各个实现类中。这样即使新增检测逻辑，只需要扩展检测实现方法就可，不需要在修改原先代码的逻辑，实现代码的可扩展。

LSP

LSP（Liskov Substitution Principle）里氏替换原则，这个设计原则我觉得相较于前面的两个设计原则来说要简单些。它的内容为子类对象（object of subtype/derived class）能够替换程序（program）中父类对象（object of base/parent class）出现的任何地方，并且保证原来程序的逻辑行为（behavior）不变及正确性不被破坏。

里式替换原则是用来指导，继承关系中子类该如何设计的一个原则。理解里式替换原则，最核心的就是理解“design by contract，按照协议来设计”这几个字。父类定义了函数的“约定”（或者叫协议），那子类可以改变函数的内部实现逻辑，但不能改变函数原有的“约定”。这里的约定包括：函数声明要实现的功能；对输入、输出、异常的约定；甚至包括注释中所罗列的任何特殊说明。

我们怎么判断有没有违背LSP呢？我觉得有两个关键点可以作为判断的依据，一个是子类有没有改变父类申明需要实现的业务功能，另一个是否违反父类关于输入、输出以及异常抛出的规定。

ISP

ISP（Interface Segregation Principle）接口隔离原则，简单理解就是只给调用方需要的接口，它不需要的就不要硬塞给他了。这里我们举个栗子，以下是关于产品的接口，其中包含了创建产品、删除产品、根据ID获取产品以及更新产品的接口。如果此时我们需要对外提供一个根据产品的类别获取产品的接口，我们应该怎么办？很多同学会说，这还不简单，我们直接在这个接口里面添加根据类别查询产品的接口就OK了啊。大家想想这个方案有没有什么问题。

public interface ProductService { 
    boolean createProduct(Product product); 
    boolean deleteProductById(long id); 
    Product getProductById(long id); 
    int updateProductInfo(Product product);
}

public class UserServiceImpl implements UserService { //...}

这个方案看上去没什么问题，但是再往深处想一想，外部系统只需要一个根据产品类别查询商品的功能，，但是实际我们提供的接口中还包含了删除、更新商品的接口。如果这些接口被其他系统误调了可能会导致产品信息的删除或者误更新。因此我们可以将这些第三方调用的接口都隔离出来，这样就不存在误调用以及接口能力被无序扩散的情况了。

public interface ProductService { 
    boolean createProduct(Product product); 
    boolean deleteProductById(long id); 
    Product getProductById(long id); 
    int updateProductInfo(Product product);
}

public interface ThirdSystemProductService{
    List<Product> getProductByType(int type);
}

public class UserServiceImpl implements UserService { //...}

LOD

LOD（Law of Demeter）即迪米特法则，这是我们要介绍的最后一个代码设计法则了，光从名字上面上看，有点不明觉厉的感觉，看不出来到底到底表达个什么意思。我们可以来看下原文是怎么描述这个设计原则的。 Each unit should have only limited knowledge about other units: only units “closely” related to the current unit. Or: Each unit should only talk to its friends; Don’t talk to strangers. 按照我自己的理解，这迪米特设计原则的最核心思想或者说最想达到的目的就是尽最大能力减小代码修改带来的对原有的系统的影响。所以需要实现类、模块或者服务能够实现高内聚、低耦合。不该有直接依赖关系的类之间，不要有依赖；有依赖关系的类之间，尽量只依赖必要的接口。迪米特法则是希望减少类之间的耦合，让类越独立越好。每个类都应该少了解系统的其他部分。一旦发生变化，需要了解这一变化的类就会比较少。打个比方这就像抗战时期的的地下组织一样，相关联的聚合到一起，但是与外部保持尽可能少的联系，也就是低耦合。

总结

本文总结了软件代码设计中的五大原则，按照我自己的理解，这五大原则就是程序猿代码设计的内功，而二十三种设计模式实际就是内功催生出来的编程招式，因此深入理解五大设计原则是我们用好设计模式的基础，也是我们在平时设计代码结构的时候需要遵循的一些常见规范。只有不断的在设计代码-》遵循规范-》编写代码-》重构这个循环中磨砺，我们才能编写出优雅的代码。

作者：慕枫技术笔记
来源：https://juejin.cn/post/7046404022143549447

前几天看了极客时间一个二维码的视频，写的不错，这里总结下

在日常生活中，二维码出现在很多场景，比如超市支付、系统登录、应用下载等等。了解二维码的原理，可以为技术人员在技术选型时提供新的思路。对于非技术人员呢，除了解惑，还可以引导他更好地辨别生活中遇到的各种二维码，防止上当受骗。

二维码，大家再熟悉不过了

购物扫个码，吃饭扫个码，坐公交也扫个码

在扫码的过程中，大家可能会有疑问：这二维码安全吗？会不会泄漏我的个人信息？更深度的用户还会考虑：我的系统是不是也可以搞一个二维码来推广呢？

这时候就需要了解一下二维码背后的技术和逻辑了！

二维码最常用的场景之一就是通过手机端应用扫描PC或者WEB端的二维码，来登录同一个系统。 比如手机微信扫码登录PC端微信，手机淘宝扫码登录PC端淘宝。 那么就让我们来看一下，二维码登录是怎么操作的！

二维码登录的本质

二维码登录本质上也是一种登录认证方式。既然是登录认证，要做的也就两件事情！

1. 告诉系统我是谁

2. 向系统证明我是谁

比如账号密码登录，账号就是告诉系统我是谁， 密码就是向系统证明我是谁; 比如手机验证码登录，手机号就是告诉系统我是谁，验证码就是向系统证明我是谁;

那么扫码登录是怎么做到这两件事情的呢？我们一起来考虑一下

手机端应用扫PC端二维码，手机端确认后，账号就在PC端登录成功了！这里，PC端登录的账号肯定与手机端是同一个账号。不可能手机端登录的是账号A，而扫码登录以后，PC端登录的是账号B。

所以，第一件事情，告诉系统我是谁，是比较清楚的！

通过扫描二维码，把手机端的账号信息传递到PC端，至于是怎么传的，我们后面再说

第二件事情，向系统证明我是谁。扫码登录过程中，用户并没有去输入密码，也没有输入验证码，或者其他什么码。那是怎么证明的呢？

有些同学会想到，是不是扫码过程中，把密码传到了PC端呢？ 但这是不可能的。因为那样太不安全的，客户端也根本不会去存储密码。我们仔细想一下，其实手机端APP它是已经登录过的，就是说手机端是已经通过登录认证。所说只要扫码确认是这个手机且是这个账号操作的，其实就能间接证明我谁。

认识二维码

那么如何做确认呢？我们后面会详细说明，在这之前我们需要先认识一下二维码！ 在认识二维码之前我们先看一下一维码！

所谓一维码，也就是条形码，超市里的条形码--这个相信大家都非常熟悉，条形码实际上就是一串数字，它上面存储了商品的序列号。

二维码其实与条形码类似，只不过它存储的不一定是数字，还可以是任何的字符串，你可以认为，它就是字符串的另外一种表现形式，

在搜索引擎中搜索二维码，你可以找到很多在线生成二维码的工具网站，这些网站可以提供字符串与二维码之间相互转换的功能，比如 草料二维码网站

在左边的输入框就可以输入你的内容，它可以是文本、网址，文件........。然后就可以生成代表它们的二维码

你也可以把二维码上传，进行”解码“，然后就可以解析出二维码代表的含义

系统认证机制

认识了二维码，我们了解一下移动互联网下的系统认证机制。

前面我们说过，为了安全，手机端它是不会存储你的登录密码的。 但是在日常使用过程中，我们应该会注意到，只有在你的应用下载下来后，第一次登录的时候，才需要进行一个账号密码的登录， 那之后呢 即使这个应用进程被杀掉，或者手机重启，都是不需要再次输入账号密码的，它可以自动登录。

其实这背后就是一套基于token的认证机制，我们来看一下这套机制是怎么运行的，

1. 账号密码登录时，客户端会将设备信息一起传递给服务端，

2. 如果账号密码校验通过，服务端会把账号与设备进行一个绑定，存在一个数据结构中，这个数据结构中包含了账号ID，设备ID，设备类型等等

const token = {
  acountid:'账号ID',
  deviceid:'登录的设备ID',
  deviceType:'设备类型，如 iso,android,pc......',
}

然后服务端会生成一个token，用它来映射数据结构，这个token其实就是一串有着特殊意义的字符串，它的意义就在于，通过它可以找到对应的账号与设备信息，

1. 客户端得到这个token后，需要进行一个本地保存，每次访问系统API都携带上token与设备信息。

2. 服务端就可以通过token找到与它绑定的账号与设备信息，然后把绑定的设备信息与客户端每次传来的设备信息进行比较， 如果相同，那么校验通过，返回AP接口响应数据， 如果不同，那就是校验不通过拒绝访问

从前面这个流程，我们可以看到，客户端不会也没必要保存你的密码，相反，它是保存了token。可能有些同学会想，这个token这么重要，万一被别人知道了怎么办。实际上，知道了也没有影响， 因为设备信息是唯一的，只要你的设备信息别人不知道， 别人拿其他设备来访问，验证也是不通过的。

可以说，客户端登录的目的，就是获得属于自己的token。

那么在扫码登录过程中，PC端是怎么获得属于自己的token呢？不可能手机端直接把自己的token给PC端用！token只能属于某个客户端私有，其他人或者是其他客户端是用不了的。在分析这个问题之前，我们有必要先梳理一下，扫描二维码登录的一般步骤是什么样的。这可以帮助我们梳理清楚整个过程，

扫描二维码登录的一般步骤

大概流程

1. 扫码前，手机端应用是已登录状态，PC端显示一个二维码，等待扫描

2. 手机端打开应用，扫描PC端的二维码，扫描后，会提示"已扫描，请在手机端点击确认"

3. 用户在手机端点击确认，确认后PC端登录就成功了

可以看到，二维码在中间有三个状态， 待扫描，已扫描待确认，已确认。 那么可以想象

1. 二维码的背后它一定存在一个唯一性的ID，当二维码生成时，这个ID也一起生成，并且绑定了PC端的设备信息

2. 手机去扫描这个二维码

3. 二维码切换为 已扫描待确认状态， 此时就会将账号信息与这个ID绑定

4. 当手机端确认登录时，它就会生成PC端用于登录的token，并返回给PC端

好了，到这里，基本思路就已经清晰了，接下来我们把整个过程再具体化一下

二维码准备

按二维码不同状态来看， 首先是等待扫描状态，用户打开PC端，切换到二维码登录界面时。

1. PC端向服务端发起请求，告诉服务端，我要生成用户登录的二维码，并且把PC端设备信息也传递给服务端

2. 服务端收到请求后，它生成二维码ID，并将二维码ID与PC端设备信息进行绑定

3. 然后把二维码ID返回给PC端

4. PC端收到二维码ID后，生成二维码(二维码中肯定包含了ID)

5. 为了及时知道二维码的状态，客户端在展现二维码后，PC端不断的轮询服务端，比如每隔一秒就轮询一次，请求服务端告诉当前二维码的状态及相关信息

二维码已经准好了，接下来就是扫描状态

扫描状态切换

1. 用户用手机去扫描PC端的二维码，通过二维码内容取到其中的二维码ID

2. 再调用服务端API将移动端的身份信息与二维码ID一起发送给服务端

3. 服务端接收到后，它可以将身份信息与二维码ID进行绑定，生成临时token。然后返回给手机端

4. 因为PC端一直在轮询二维码状态，所以这时候二维码状态发生了改变，它就可以在界面上把二维码状态更新为已扫描

那么为什么需要返回给手机端一个临时token呢？临时token与token一样，它也是一种身份凭证，不同的地方在于它只能用一次，用过就失效。

在第三步骤中返回临时token，为的就是手机端在下一步操作时，可以用它作为凭证。以此确保扫码，登录两步操作是同一部手机端发出的，

状态确认

最后就是状态的确认了。

1. 手机端在接收到临时token后会弹出确认登录界面，用户点击确认时，手机端携带临时token用来调用服务端的接口，告诉服务端，我已经确认

2. 服务端收到确认后，根据二维码ID绑定的设备信息与账号信息，生成用户PC端登录的token

3. 这时候PC端的轮询接口，它就可以得知二维码的状态已经变成了"已确认"。并且从服务端可以获取到用户登录的token

4. 到这里，登录就成功了，后端PC端就可以用token去访问服务端的资源了

扫码动作的基础流程都讲完了，有些细节还没有深入介绍，

比如二维码的内容是什么？

• 可以是二维码ID

• 可以是包含二维码ID的一个url地址

在扫码确认这一步，用户取消了怎么处理？ 这些细节都留给大家思考

总结

我们从登陆的本质触发，探索二维码扫码登录是如何做到的

1. 告诉系统我是谁

2. 向系统证明我谁

在这个过程中，我们先简单讲了两个前提知识，

• 一个是二维码原理，

• 一个是基于token的认证机制。

然后我们以二维码状态为轴，分析了这背后的逻辑: 通过token认证机制与二维码状态变化来实现扫码登录.

需要指出的是，前面的讲的登录流程，它适用于同一个系统的PC端，WEB端，移动端。

平时我们还有另外一种场景也比较常见，那就是通过第三方应用来扫码登录，比如极客时间/掘金 都可以选择微信/QQ等扫码登录，那么这种通过第三方应用扫码登录又是什么原理呢？

感兴趣的同学可以思考研究一下，欢迎在评论区留下你的见解。

作者：望道同学
来源：https://juejin.cn/post/6940976355097985032

Nginx作为一个轻量级的HTTP服务器，相比Apache优势也是比较明显的,在性能上它占用资源少,能支持更高更多的并发连接,从而达到提高访问效率;在功能上它是一款非常优秀的代理服务器与负载均衡服务器;在安装配置上它安装，配置都比较简单。

但在实际的生产配置环境中，肯定会经常遇到需要修改、或者重新增加Nginx配置的问题，有的时候需求更是多种多样，修修改改经常会出现这样、那样的一些错误，特别的烦索。

基于以上的原因，肯定很多读者伙伴经常会收集一些配置文档、或者电脑里也保存着一些自己日常的常用配置案例，但是终究还是不是很便利。今天，民工哥给大家介绍一款「超级牛掰的神器」，可以在线一键生成Nginx的配置。

网址：https://nginxconfig.io/

NGINX Config 支持 HTTP、HTTPS、PHP、Python、Node.js、WordPress、Drupal、缓存、逆向代理、日志等各种配置选项。在线生成 Web 服务器 Nginx 配置文件。

操作配置也非常简单，你需要做的只需要2步：

• 打开官方网站

• 按需求配置相关参数

系统就会自动生成特定的配置文件。虽然界面是英文的，但是功能的页面做的非常直观，生成的Nginx格式规范。

案例展示

配置域名：mingongge.com 实现用户访问*.mingongge.com 域名时会自动跳转到 mingongge.com 此配置，并且开启http强制跳转到https的配置。

这时，Nginx的配置就会实时自动生成在下面，我把生成的配置复制过来，如下：

/etc/nginx/sites-available/mingongge.com.conf#文件名都给你按规则配置好了
server {
listen 443 ssl http2;

server_name mingongge.com;

# SSL
ssl_certificate /etc/letsencrypt/live/mingongge.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mingongge.com/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/mingongge.com/chain.pem;

# security
include nginxconfig.io/security.conf;

# additional config
include nginxconfig.io/general.conf;
}

# subdomains redirect
server {
listen 443 ssl http2;

server_name *.mingongge.com;

# SSL
ssl_certificate /etc/letsencrypt/live/mingongge.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mingongge.com/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/mingongge.com/chain.pem;

return 301 https://mingongge.com$request_uri;
}

# HTTP redirect
server {
listen 80;

server_name .mingongge.com;

include nginxconfig.io/letsencrypt.conf;

location / {
return 301 https://mingongge.com$request_uri;
}
}

非常的方便与快速。

官方还提供一些Nginx的基础优化配置，如下：

/etc/nginx/nginx.conf
# Generated by nginxconfig.io

user www-data;
pid /run/nginx.pid;
worker_processes auto;
worker_rlimit_nofile 65535;

events {
multi_accept on;
worker_connections 65535;
}

http {
charset utf-8;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
server_tokens off;
log_not_found off;
types_hash_max_size 2048;
client_max_body_size 16M;

# MIME
include mime.types;
default_type application/octet-stream;

# logging
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log warn;

# load configs
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}

还有基于安全的配置，如下：

/etc/nginx/nginxconfig.io/security.conf
# security headers
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "no-referrer-when-downgrade" always;
add_header Content-Security-Policy "default-src * data: 'unsafe-eval' 'unsafe-inline'" always;

# . files
location ~ /\.(?!well-known) {
deny all;
}

都相当于是提供一些基础的模板配置，可以根据自己的实际需求去修改。

有了这个神器在手，再也不用为配置Nginx的各类配置而烦恼了！！

作者：民工哥

来源：https://www.bbsmax.com/A/kjdw09OwzN/

这是一篇聊算法的文章，从一个小面试题开始，扩展到一系列基础算法，包含几个部分：

(1) 题目简介；

(2) 思路一：暴力法；

(3) 思路二：染色法；

(4) 思路三：链表法；

(5) 思路四：并查集法；

除了聊方案，重点分享思考过程。文章较长，可提前收藏。

第一部分：题目简介

问题提出：求微信群覆盖

微信有很多群，现进行如下抽象：

(1) 每个微信群由一个唯一的gid标识；

(2) 微信群内每个用户由一个唯一的uid标识；

(3) 一个用户可以加入多个群；

(4) 群可以抽象成一个由不重复uid组成的集合，例如：

g1{u1, u2, u3}

g2{u1, u4, u5}

可以看到，用户u1加入了g1与g2两个群。

画外音：

gid和uid都是uint64；

集合内没有重复元素；

假设微信有M个群(M为亿级别)，每个群内平均有N个用户(N为十级别).

现在要进行如下操作：

(1) 如果两个微信群中有相同的用户，则将两个微信群合并，并生成一个新微信群；

例如，上面的g1和g2就会合并成新的群：

g3{u1, u2, u3, u4, u5}；

画外音：集合g1中包含u1，集合g2中包含u1，合并后的微信群g3也只包含一个u1。

(2) 不断的进行上述操作，直到剩下所有的微信群都不含相同的用户为止；

将上述操作称：求群的覆盖。

设计算法，求群的覆盖，并说明算法时间与空间复杂度。

画外音：你遇到过类似的面试题吗？

对于一个复杂的问题，思路肯定是“先解决，再优化”，大部分人不是神，很难一步到位。先用一种比较“笨”的方法解决，再看“笨方法”有什么痛点，优化各个痛点，不断升级方案。

第二部分：暴力法

拿到这个问题，很容易想到的思路是：

(1) 先初始化M个集合，用集合来表示微信群gid与用户uid的关系；

(2) 找到哪两个(哪些)集合需要合并；

(3) 接着，进行集合的合并；

(4) 迭代步骤二和步骤三，直至所有集合都没有相同元素，算法结束；

第一步，如何初始化集合？

set这种数据结构，大家用得很多，来表示集合：

(1) 新建M个set来表示M个微信群gid；

(2) 每个set插入N个元素来表示微信群中的用户uid；

set有两种最常见的实现方式，一种是树型set，一种是哈希型set。

假设有集合：

s={7, 2, 0, 14, 4, 12}

树型set的实现如下：

其特点是：

(1) 插入和查找的平均时间复杂度是O(lg(n))；

(2) 能实现有序查找；

(3) 省空间；

哈希型set实现如下：

其特点是：

(1) 插入和查找的平均时间复杂度是O(1)；

(2) 不能实现有序查找；

画外音：求群覆盖，哈希型实现的初始化更快，复杂度是O(M*N)。

第二步，如何判断两个(多个)集合要不要合并？

集合对set(i)和set(j)，判断里面有没有重复元素，如果有，就需要合并，判重的伪代码是：

// 对set(i)和set(j)进行元素判断并合并

(1)    foreach (element in set(i))

(2)    if (element in set(j))

         merge(set(i), set(j));

第一行(1)遍历第一个集合set(i)中的所有元素element；

画外音：这一步的时间复杂度是O(N)。

第二行(2)判断element是否在第二个集合set(j)中；

画外音：如果使用哈希型set，第二行(2)的平均时间复杂度是O(1)。

这一步的时间复杂度至少是O(N)*O(1)=O(N)。

第三步，如何合并集合？

集合对set(i)和set(j)如果需要合并，只要把一个集合中的元素插入到另一个集合中即可：

// 对set(i)和set(j)进行集合合并

merge(set(i), set(j)){

(1)    foreach (element in set(i))

(2)    set(j).insert(element);

}

第一行(1)遍历第一个集合set(i)中的所有元素element；

画外音：这一步的时间复杂度是O(N)。

第二行(2)把element插入到集合set(j)中；

画外音：如果使用哈希型set，第二行(2)的平均时间复杂度是O(1)。

这一步的时间复杂度至少是O(N)*O(1)=O(N)。

第四步：迭代第二步与第三步，直至结束

对于M个集合，暴力针对所有集合对，进行重复元素判断并合并，用两个for循环可以暴力解决：

(1)for(i = 1 to M)

(2)    for(j= i+1 to M)

         //对set(i)和set(j)进行元素判断并合并

         foreach (element in set(i))

         if (element in set(j))

         merge(set(i), set(j));

递归调用，两个for循环，复杂度是O(M*M)。

综上，如果这么解决群覆盖的问题，时间复杂度至少是：

O(M*N) // 集合初始化的过程

+

O(M*M) // 两重for循环递归

*

O(N) // 判重

*

O(N) // 合并

画外音：实际复杂度要高于这个，随着集合的合并，集合元素会越来越多，判重和合并的成本会越来越高。

第三部分：染色法

总的来说，暴力法效率非常低，集合都是一个一个合并的，同一个元素在合并的过程中要遍历很多次。很容易想到一个优化点，能不能一次合并多个集合？

暴力法中，判断两个集合set和set是否需要合并，思路是：遍历set中的所有element，看在set中是否存在，如果存在，说明存在交集，则需要合并。

哪些集合能够一次性合并？

当某些集合中包含同一个元素时，可以一次性合并。

怎么一次性发现，哪些集合包含同一个元素，并合并去重呢？

回顾一下工作中的类似需求：

M个文件，每个文件包含N个用户名，或者N个手机号，如何合并去重？

最常见的玩法是：

cat file_1 file_2 … file_M | sort | uniq > result

这里的思路是什么？

(1) 把M*N个用户名/手机号输出；

(2) sort排序，排序之后相同的元素会相邻；

(3) uniq去重，相邻元素如果相同只保留一个；

“排序之后相同的元素会相邻”，就是一次性找出所有可合并集合的关键，这是染色法的核心。

举一个栗子：

假设有6个微信群，每个微信群有若干个用户：

s1={1,0,5} s2={3,1} s3={2,9}

s4={4,6} s5={4,7} s6={1,8}

假设使用树形set来表示集合。

首先，给同一个集合中的所有元素染上相同的颜色，表示来自同一个集合。

然后，对所有的元素进行排序，会发现：

(1) 相同的元素一定相邻，并且一定来自不同的集合；

(2) 同一个颜色的元素被打散了；

这些相邻且相同的元素，来自哪一个集合，这些集合就是需要合并的，如上图：

(1) 粉色的1来自集合s1，紫色的1来自集合s2，黄色的1来自集合s6，所以s1s2s6需要合并；

(2) 蓝色的4来自集合s4，青色的4来自集合s5，所以s4s5需要合并；

不用像暴力法遍历所有的集合对，而是一个排序动作，就能找到所有需要合并的集合。

画外音：暴力法一次处理2个集合，染色法一次可以合并N个集合。

集合合并的过程，可以想象为，相同相邻元素所在集合，染成第一个元素的颜色：

(1) 紫色和黄色，染成粉色；

(2) 青色，染成蓝色；

最终，剩余三种颜色，也就是三个集合：

s1={0,1,3,5,8}

s3={2,9}

s4={4,6,7}

神奇不神奇！！！

染色法有意思么？但仍有两个遗留问题：

(1) 粉色1，紫色1，黄色1，三个元素如何找到这三个元素所在的集合s1s2s6呢？

(2) s1s2s6三个集合如何快速合并？

画外音：假设总元素个数n=M*N，如果使用树形set，合并的复杂度为O(n*lg(n))，即O(M*N*lg(M*N))。

我们继续往下看。

第四部分：链表法

染色法遗留了两个问题：

步骤(2)中，如何通过元素快速定位集合？

步骤(3)中，如何快速合并集合？

我们继续聊聊这两个问题的优化思路。

问题一：如何由元素快速定位集合？

普通的集合，只能由集合根(root)定位元素，不能由元素逆向定位root，如何支持元素逆向定位root呢？

很容易想到，每个节点增加一个父指针即可。

更具体的：

element{

         int data;

         element* left;

         element* right;

}

升级为：

element{

         element* parent;    // 指向父节点

         int data;

         element* left;

         element* right;

}

如上图：所有节点的parent都指向它的上级，而只有root->parent=NULL。

对于任意一个元素，找root的过程为：

element* X_find_set_root(element* x){

         element* temp=x;

         while(temp->parent != NULL){

                   temp= temp->parent;

         }

         return temp;

}

很容易发现，由元素找集合根的时间复杂度是树的高度，即O(lg(n))。

有没有更快的方法呢？

进一步思考，为什么每个节点要指向父节点，直接指向根节点是不是也可以。

更具体的：

element{

         int data;

         element* left;

         element* right;

}

升级为：

element{

         element* root;         // 指向集合根

         int data;

         element* left;

         element* right;

}

如上图：所有节点的parent都指向集合的根。

对于任意一个元素，找root的过程为：

element* X_find_set_root(element* x){

         return x->root;

}

很容易发现，升级后，由元素找集合根的时间复杂度是O(1)。

画外音：不能更快了吧。

另外，这种方式，能在O(1)的时间内，判断两个元素是否在同一个集合内：

bool in_the_same_set(element* a, element* b){

         return (a->root == b->root);

}

甚为方便。

画外音：两个元素的根相同，就在同一个集合内。

问题二：如何快速进行集合合并？ 

暴力法中提到过，集合合并的伪代码为：

merge(set(i), set(j)){

         foreach(element in set(i))

                   set(j).insert(element);

}

把一个集合中的元素插入到另一个集合中即可。

假设set(i)的元素个数为n1，set(j)的元素个数为n2，其时间复杂度为O(n1*lg(n2))。

在“微信群覆盖”这个业务场景下，随着集合的不断合并，集合高度越来越高，合并会越来越慢，有没有更快的集合合并方式呢？

仔细回顾一下：

(1) 树形set的优点是，支持有序查找，省空间；

(2) 哈希型set的优点是，快速插入与查找；

而“微信群覆盖”场景对集合的频繁操作是：

(1) 由元素找集合根；

(2) 集合合并；

那么，为什么要用树形结构或者哈希型结构来表示集合呢？

画外音：优点完全没有利用上嘛。

让我们来看看，这个场景中，如果用链表来表示集合会怎么样，合并会不会更快？

s1={7,3,1,4}

s2={1,6}

如上图，分别用链表来表示这两个集合。可以看到，为了满足“快速由元素定位集合根”的需求，每个元素仍然会指向根。

s1和s2如果要合并，需要做两件事：

(1) 集合1的尾巴，链向集合2的头(蓝线1)；

(2) 集合2的所有元素，指向集合1的根(蓝线2,3)；

合并完的效果是：

变成了一个更大的集合。

假设set(1)的元素个数为n1，set(2)的元素个数为n2，整个合并的过程的时间复杂度是O(n2)。

画外音：时间耗在set(2)中的元素变化。

咦，我们发现：

(1) 将短的链表，接到长的链表上；

(2) 将长的链表，接到短的链表上；

所使用的时间是不一样的。

为了让时间更快，一律使用更快的方式：“元素少的链表”主动接入到“元素多的链表”的尾巴后面。这样，改变的元素个数能更少一些，这个优化被称作“加权合并”。

对于M个微信群，平均每个微信群N个用户的场景，用链表的方式表示集合，按照“加权合并”的方式合并集合，最坏的情况下，时间复杂度是O(M*N)。

画外音：假设所有的集合都要合并，共M次，每次都要改变N个元素的根指向，故为O(M*N)。

于是，对于“M个群，每个群N个用户，微信群求覆盖”问题，使用“染色法”加上“链表法”，核心思路三步骤：

(1) 全部元素全局排序；

(2) 全局排序后，不同集合中的相同元素，一定是相邻的，通过相同相邻的元素，一次性找到所有需要合并的集合；

(3) 合并这些集合，算法完成；

其中：

步骤(1)，全局排序，时间复杂度O(M*N)；

步骤(2)，染色思路，能够迅猛定位哪些集合需要合并，每个元素增加一个属性指向集合根，实现O(1)级别的元素定位集合；

步骤(3)，使用链表表示集合，使用加权合并的方式来合并集合，合并的时间复杂度也是O(M*N)；

总时间复杂度是：

O(M*N)    //排序

+

O(1)        //由元素找到需要合并的集合

*

O(M*N)    //集合合并

神奇不神奇！！！

神奇不止一种，还有其他方法吗？我们接着往下看。

第五部分：并查集法

分离集合(disjoint set)是一种经典的数据结构，它有三类操作：

Make-set(a)：生成一个只有一个元素a的集合；

Union(X, Y)：合并两个集合X和Y；

Find-set(a)：查找元素a所在集合，即通过元素找集合；

这种数据结构特别适合用来解决这类集合合并与查找的问题，又称为并查集。

能不能利用并查集来解决求“微信群覆盖”问题呢？

一、并查集的链表实现

链表法里基本聊过，为了保证知识的系统性，这里再稍微回顾一下。

如上图，并查集可以用链表来实现。

链表实现的并查集，Find-set(a)的时间复杂度是多少？

集合里的每个元素，都指向“集合的句柄”，这样可以使得“查找元素a所在集合S”，即Find-set(a)操作在O(1)的时间内完成。

链表实现的并查集，Union(X, Y)的时间复杂度是多少？

假设有集合：

S1={7,3,1,4}

S2={1,6}

合并S1和S2两个集合，需要做两件事情：

(1) 第一个集合的尾元素，链向第二个集合的头元素(蓝线1)；

(2) 第二个集合的所有元素，指向第一个集合的句柄(蓝线2,3)；

合并完的效果是：

变成了一个更大的集合S1。

集合合并时，将短的链表，往长的链表上接，这样变动的元素更少，这个优化叫做“加权合并”。

画外音：实现的过程中，集合句柄要存储元素个数，头元素，尾元素等属性，以方便上述操作进行。

假设每个集合的平均元素个数是n，Union(X, Y)操作的时间复杂度是O(n)。

能不能Find-set(a)与Union(X, Y)都在O(1)的时间内完成呢？

可以，这就引发了并查集的第二种实现方法。

二、并查集的有根树实现

什么是有根树，和普通的树有什么不同？

常用的set，就是用普通的二叉树实现的，其元素的数据结构是：

element{

         int data;

         element* left;

         element* right;

}

通过左指针与右指针，父亲节点指向儿子节点。

而有根树，其元素的数据结构是：

element{

         int data;

         element* parent;

}

通过儿子节点，指向父亲节点。

假设有集合：

S1={7,3,1,4}

S2={1,6}

通过如果通过有根树表示，可能是这样的：

所有的元素，都通过parent指针指向集合句柄，所有元素的Find-set(a)的时间复杂度也是O(1)。

画外音：假设集合的首个元素，代表集合句柄。

有根树实现的并查集，Union(X, Y)的过程如何？时间复杂度是多少？

通过有根树实现并查集，集合合并时，直接将一个集合句柄，指向另一个集合即可。

如上图所示，S2的句柄，指向S1的句柄，集合合并完成：S2消亡，S1变为了更大的集合。

容易知道，集合合并的时间复杂度为O(1)。

会发现，集合合并之后，有根树的高度变高了，与“加权合并”的优化思路类似，总是把节点数少的有根树，指向节点数多的有根树（更确切的说，是高度矮的树，指向高度高的树），这个优化叫做“按秩合并”。

新的问题来了，集合合并之后，不是所有元素的Find-set(a)操作都是O(1)了，怎么办？

如图S1与S2合并后的新S1，首次“通过元素6来找新S1的句柄”，不能在O(1)的时间内完成了，需要两次操作。

但为了让未来“通过元素6来找新S1的句柄”的操作能够在O(1)的时间内完成，在首次进行Find-set(“6”)时，就要将元素6“寻根”路径上的所有元素，都指向集合句柄，如下图。

某个元素如果不直接指向集合句柄，首次Find-set(a)操作的过程中，会将该路径上的所有元素都直接指向句柄，这个优化叫做“路径压缩”。

画外音：路径上的元素第二次执行Find-set(a)时，时间复杂度就是O(1)了。

实施“路径压缩”优化之后，Find-set的平均时间复杂度仍是O(1)。

稍微总结一下。

通过链表实现并查集：

(1) Find-set的时间复杂度，是O(1)常数时间；

(2) Union的时间复杂度，是集合平均元素个数，即线性时间；

画外音：别忘了“加权合并”优化。

通过有根树实现并查集：

(1) Union的时间复杂度，是O(1)常数时间；

(2) Find-set的时间复杂度，通过“按秩合并”与“路径压缩”优化后，平均时间复杂度也是O(1)；

即，使用并查集，非常适合解决“微信群覆盖”问题。

知其然，知其所以然，思路往往比结果更重要。

算法，其实还是挺有意思的。

作者：58沈剑
来源：https://mp.weixin.qq.com/s/2MNL4vDpXQR94KGts4JUhA

首先借用有心人士的一张相当直观清晰的图来划分各种协议：开源许可证GPL、BSD、MIT、Mozilla、Apache和LGPL的区别



以下是上述协议的简单介绍：
BSD开源协议
BSD开源协议是一个给于使用者很大自由的协议。基本上使用者可以”为所欲为”,可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。

但”为所欲为”的前提当你发布使用了BSD协议的代码，或则以BSD协议代码为基础做二次开发自己的产品时，需要满足三个条件：

    如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。
    如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
    不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。

BSD 代码鼓励代码共享，但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。而很多的公司企业在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。

Apache Licence 2.0
Apache Licence是著名的非盈利开源组织Apache采用的协议。该协议和BSD类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布（作为开源或商业软件）。需要满足的条件也和BSD类似：

    需要给代码的用户一份Apache Licence
    如果你修改了代码，需要再被修改的文件中说明。
    在延伸的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。
    如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache Licence。你可以在Notice中增加自己的许可，但不可以表现为对Apache Licence构成更改。

Apache Licence也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。
GPL

我们很熟悉的Linux就是采用了GPL。GPL协议和BSD, Apache Licence等鼓励代码重用的许可很不一样。GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用，但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。这也就是为什么我们能用免费的各种linux，包括商业公司的linux和linux上各种各样的由个人，组织，以及商业软件公司开发的免费软件了。

GPL协议的主要内容是只要在一个软件中使用(”使用”指类库引用，修改后的代码或者衍生代码)GPL 协议的产品，则该软件产品必须也采用GPL协议，既必须也是开源和免费。这就是所谓的”传染性”。GPL协议的产品作为一个单独的产品使用没有任何问题，还可以享受免费的优势。

由于GPL严格要求使用了GPL类库的软件产品必须使用GPL协议，对于使用GPL协议的开源代码，商业软件或者对代码有保密要求的部门就不适合集成/采用作为类库和二次开发的基础。

其它细节如再发布的时候需要伴随GPL协议等和BSD/Apache等类似。

LGPL
LGPL是GPL的一个为主要为类库使用设计的开源协议。和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同。LGPL 允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。

但是如果修改LGPL协议的代码或者衍生，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用，但不适合希望以LGPL协议代码为基础，通过修改和衍生的方式做二次开发的商业软件采用。

GPL/LGPL都保障原作者的知识产权，避免有人利用开源代码复制并开发类似的产品

MIT
MIT是和BSD一样宽范的许可协议,作者只想保留版权,而无任何其他了限制.也就是说,你必须在你的发行版里包含原许可协议的声明,无论你是以二进制发布的还是以源代码发布的.

MPL
MPL是The Mozilla Public License的简写，是1998年初Netscape的 Mozilla小组为其开源软件项目设计的软件许可证。MPL许可证出现的最重要原因就是，Netscape公司认为GPL许可证没有很好地平衡开发者对源代码的需求和他们利用源代码获得的利益。同著名的GPL许可证和BSD许可证相比，MPL在许多权利与义务的约定方面与它们相同（因为都是符合OSIA 认定的开源软件许可证）。但是，相比而言MPL还有以下几个显著的不同之处:

◆ MPL虽然要求对于经MPL许可证发布的源代码的修改也要以MPL许可证的方式再许可出来，以保证其他人可以在MPL的条款下共享源代码。但是，在MPL 许可证中对“发布”的定义是“以源代码方式发布的文件”，这就意味着MPL允许一个企业在自己已有的源代码库上加一个接口，除了接口程序的源代码以MPL 许可证的形式对外许可外，源代码库中的源代码就可以不用MPL许可证的方式强制对外许可。这些，就为借鉴别人的源代码用做自己商业软件开发的行为留了一个豁口。
◆ MPL许可证第三条第7款中允许被许可人将经过MPL许可证获得的源代码同自己其他类型的代码混合得到自己的软件程序。
◆ 对软件专利的态度，MPL许可证不像GPL许可证那样明确表示反对软件专利，但是却明确要求源代码的提供者不能提供已经受专利保护的源代码（除非他本人是专利权人，并书面向公众免费许可这些源代码），也不能在将这些源代码以开放源代码许可证形式许可后再去申请与这些源代码有关的专利。
◆ 对源代码的定义
而在MPL（1.1版本）许可证中，对源代码的定义是:“源代码指的是对作品进行修改最优先择取的形式，它包括:所有模块的所有源程序，加上有关的接口的定义，加上控制可执行作品的安装和编译的‘原本’（原文为‘Script’），或者不是与初始源代码显著不同的源代码就是被源代码贡献者选择的从公共领域可以得到的程序代码。”
◆ MPL许可证第3条有专门的一款是关于对源代码修改进行描述的规定，就是要求所有再发布者都得有一个专门的文件就对源代码程序修改的时间和修改的方式有描述。

作者：微wx笑
翻译：https://blog.csdn.net/testcs_dn/article/details/38496107
原文：http://www.mozilla.org/MPL/MPL-1.1.html

「我删我自己的开源项目代码，需要经过别人允许吗？」

几天前，开源库「faker.js」和「colors.js」的用户打开电脑，发现自己的应用程序正在输出乱码数据，那一刻，他们惊呆了。

更令人震惊的是，开发者们发现，造成这一混乱局面的就是「faker.js」和「colors.js」的作者 Marak Squires 本人。

一夜之间，Marak Squires 主动删除了「faker.js」和「colors.js」项目仓库的所有代码，让正在使用这两个开源项目的数千位开发者直接崩溃。

「faker.js」和「colors.js」

faker.js 在 npm 上的每周下载量接近 250 万，color.js 每周的下载量约为 2240 万，本次删库的影响是极其严重的，使用这两个项目开发的工具包括 AWS CDK 等。

如果在构建和测试应用时，真实的数据量远远不够，那么 Faker 类工具将帮助开发者生成伪数据。faker.js 就是可为多个领域生成伪数据的 Node.js 库，包括地址、商业、公司、日期、财务、图像、随机数、名称等。

faker.js 支持生成英文、中文等多语种信息，包含丰富的 API，此前版本通常一个月迭代更新一次。faker.js 不仅可以使用在服务器端的 JavaScript，还可以应用在浏览器端的 JavaScript。

现在，faker.js 项目的所有 commit 信息都被改为「endgame」，在 README 中，作者写下这样一句话：「What really happened with Aaron Swartz?」

Swartz 是一位杰出的开发人员，帮助建立了 Creative Commons、RSS 和 Reddit。2011 年，Swartz 被指控从学术数据库 JSTOR 中窃取文件，目的是免费访问这些文件。Swartz 在 2013 年自杀，Squires 提到 Swartz 可能意指围绕这一死亡疑云。

Marak Squires 向 colors.js 提交了恶意代码，添加了一个「a new American flag module」，然后将其发布到了 GitHub 和 npm。

随后他在 GitHub 和 npm 发布了 faker.js 6.6.6，这两个动作引发了同样的破坏性事件。破坏后的版本导致应用程序无限输出奇怪的字母和符号，从三行写着「LIBERTY LIBERTY LIBERTY」的文本开始，后面跟着一系列非 ASCII 字符：

目前，color.js 已经更新了一个可以使用的版本。faker.js 项目尚未恢复，开发者只能通过降级到此前的 5.5.3 版本来解决问题。

为了解决问题，Squires 在 GitHub 上还发布了更新以解决「zalgo 问题」，该问题是指损坏文件产生的故障文本。

「我们注意到在 v1.4.44-liberty-2 版本的 colors 中有一个 zalgo 错误，」Squires 以一种讽刺的语气写道。「我们现在正在努力解决这个问题，很快就会有解决方案。」

在将更新推送到 faker.js 两天后，Squires 发了一条推文，表示自己存储了数百个项目的 GitHub 账户已经被封。Squires 在 1 月 4 日发布了 faker.js 的最新 commit，在 1 月 6 日被封，直到 1 月 7 日推送了 colors.js 的「liberty」版本。然而，从 faker.js 和 colors.js 的更新日志来看，他的账户似乎被解封过。目前尚不清楚 Squires 的帐户是否再次被封。

至此，故事并没有就此结束。Squires 2020 年 11 月发在 GitHub 上的一篇帖子被挖出来，在帖子中他写道自己不再想做免费的工作了。「恕我直言，我不想再用我的免费工作来支持财富 500 强（和其他小型公司），以此为契机，向我发送一份六位数的年度合同，或者 fork 项目并让其他人参与其中。」

Squires 的大胆举动引起了人们对开源开发者的道德和财务困境的关注，这可能是 Marak Squires 行动的目标。大量网站、软件和应用程序依赖开源开发人员来创建基本工具和组件，而所有这些都是免费的，无偿开发人员经常不知疲倦地工作，努力修复其开源软件中的安全问题。

开发者们怎么看

软件工程师 Sergio Gómez 表示：「从 GitHub 删除自己的代码违反了他们的服务条款？WTF？这是绑架。我们需要开始分散托管免费软件源代码。」

「不知道发生了什么，但我将我所有的项目都托管在 GitLab 私有 instance 上，永远不要相信任何互联网服务提供商。」

有网友认为 faker.js 团队的反应有些夸张了，并说道：「没有人会用一个只生成一些虚假数据的包赚大钱。faker.js 的确为开发者生成伪数据节省了一些时间，但我们也可以让实习生编写类似程序来生成数据。这对企业来说并没有那么重要。」

甚至有人认为 Marak 这么做是一种冲动行为，不够理性，并和他之前「卖掉房子购买 NFT」的传闻联系起来，认为 Marak 需要学会控制自己的情绪：

这种说法很快带偏部分网友的看法，有人原本同情开源项目被「白嫖」，但现在已转向认为 Marak 是恶意删库，并指出：「停止维护他的项目或完全删除都是他的权利，但故意提交有害代码是不对的。」

当然，也有人为开源软件（FOSS）开发者的待遇鸣不平：「希望有相关的基金会位 FOSS 开发人员提供资金支持」，而软件的可靠性和稳定性也是至关重要的

有人表示：一些大公司确实不尊重开源项目的版权，滥用开源项目对于 FOSS 开发者来说是绝对不公平的。但 Marak 对 faker.js 的做法并不可取，不是正面例子，存在 Marak 的个人负面原因。

对此，你有什么看法？

作者：机器之心Pro

来源：https://www.163.com/dy/article/GTC8PE5M0511AQHO.html

1.崩溃的一天

12月20号，算得上西安崩溃的一天。

12月19号新增病例21个，20号新增病例42个，并且有部分病例已经在社区内传播.

西安防疫压力巨大，各单位公司要求，需48小时核酸检测报告上班。

在这样严峻的情况下，作为防控最核心的系统：西安一码通竟然崩溃了，并且崩溃得是那么的彻底。

足足瘫痪超过 15 个多小时！

整整一天的时间呀，多少上班族被堵在地铁口，多少旅客被冻在半路上，进退不能...

到了下午，新闻甚至提示：

为了减轻系统压力，建议广大市民非必要不展码、亮码，在出现系统卡顿时，请耐心等待，尽量避免反复刷新，也感谢广大市民朋友们的理解配合。

这是解决问题的方法吗？

如果真的需要限流来防止系统崩溃，用技术手段来限流是不是会更简单一些，甚至前面加一个 nginx 就能解决的问题。

今天，我们就试着分析一下这个业务、以及对应的技术问题。

2.产品分析

西安一码通其它业务我们暂且不分析，那并不是重点，并且当天也没有完全崩溃，崩溃的仅有扫码功能。

其实这是一个非常典型的大量查询、少数更新的业务，闭着眼睛分析一下，可以说， 90% 以上的流量都是查询。

我们先来看看第一版的产品形态，扫码之后展示个人部分姓名和身份政信息，同时下面展示绿、黄、红码。

这是西安一码通最开始的样子，业务流程仅仅只需要一个请求，甚至一个查询的 SQL 就可以搞定。

到了后来，这个界面做了2次比较大的改版。

第一次改版新增了疫苗接种信息，加了一个边框；第二次改版新增了核酸检测信息，在最下方展示核酸检测时间、结果。

整个页面增加了2个查询业务，如果系统背后使用的是关系数据库，可能会多增加至少2个查询SQL。

基本上就是这样的一个需求，据统计西安有1300万人口，按照最大10%的市民同时扫码（我怀疑不会有这么多），也就是百万的并发量。

这样一个并发量的业务，在互联网公司很常见，甚至比这个复杂的场景也多了去了。

那怎么就崩了呢？

3.技术分析

在当天晚上的官方回复中，我们看到有这样一句话：

12月20日早7:40分左右，西安“一码通”用户访问量激增，每秒访问量达到以往峰值的10倍以上，造成网络拥塞，致使包括“一码通”在内的部分应用系统无法正常使用。“

一码通”后台监控第一时间报警，各24小时驻场通信、网络、政务云、安全和运维团队立即开展排查，平台应用系统和数据库运行正常，判断问题出现在网络接口侧。

根据上面的信息，数据库和平台系统都正常，是网络出现了问题。

我之前在文章《一次dns缓存引发的惨案》画过一张访问示意图，用这个图来和大家分析一下，网络出现问题的情况。

一般用户的请求，会先从域名开始，经过DNS服务器解析后拿到外网IP地址，经过外网IP访问防火墙和负载之后打到服务器，最后服务器响应后将结果返回到浏览器。

如果真的是网络出现问题，一般最常见的问题就是 DNS 解析错误，或者外网的宽带被打满了。

DNS解析错误一定不是本次的问题，不然可能不只是这一个功能出错了；外网的宽带被打满，直接增加带宽就行，不至于一天都没搞定。

如果真的是网络侧出现问题，一般也不需要改动业务，但实际上系统恢复的时候，大家都发现界面回到文章开头提到了第一个版本了。

也就是说系统“回滚”了。

界面少了接种信息和核酸检测信息的内容，并且在一码通的首页位置，新增加了一个核酸查询的页面。

所以，仅仅是网络接口侧出现问题吗？我这里有一点点的疑问。

4.个人分析

根据我以往的经验，这是一个很典型的系统过载现象，也就是说短期内请求量超过服务器响应。

说人话就是，外部请求量超过了系统的最大处理能力。

当然了，系统最大处理能力和系统架构息息相关，同样的服务器不同的架构，系统负载量差异极大。

应对这样的问题，解决起来无非有两个方案，一个是限流，另外一个就是扩容了。

限流就是把用户挡在外面，先处理能处理的请求；扩容就是加服务器、增加数据库承载能力。

上面提到官方让大家没事别刷一码通，也算是人工限流的一种方式；不过在技术体系上基本上不会这样做。

技术上的限流方案有很多，但最简单的就是前面挂一个 Nginx 配置一下就能用；复杂一点就是接入层自己写算法。

当然了限流不能真正的解决问题，只是负责把一部分请求挡在外面；真正解决问题还是需要扩容，满足所有用户。

但实际上，根据解决问题的处理和产品回滚的情况来看，一码通并没有第一时间做扩容，而是选择了回滚。

这说明，在系统架构设计上，没有充分考虑扩容的情况，所以并不能支持第一时间选择这个方案。

5.理想的方案？

上面说那么多也仅仅是个人推测，实际上可能他们会面临更多现实问题，比如工期紧张、老板控制预算等等...

话说回来，如果你是负责一码通公司的架构师，你会怎么设计整个技术方案呢？欢迎大家留言，这里说说我的想法。

第一步，读写分离、缓存。

至少把系统分为2大块，满足日常使用的读业务单独抽取出来，用于承接外部的最大流量。

单独抽出一个子系统负责业务的更新，比如接种信息的更新、核酸信息的变化、或者根据业务定时变更码的颜色。

同时针对用户大量的单查询，上缓存系统，优先读取缓存系统的信息，防止压垮后面的数据库。

第二步，分库分表、服务拆分。

其实用户和用户之间的单个查询是没有关系的，完全可以根据用户的属性做分库分表。

比如就用用户ID取模分64个表，甚至可以分成64个子系统来查询，在接口最前端将流量分发掉，减轻单个表或者服务压力。

上面分析没有及时扩容，可能就是没有做服务拆分，如果都是单个的业务子服务的话，遇到过载的问题很容易做扩容。

当然，如果条件合适的话，上微服务架构就更好了，有一套解决方案来处理类似的问题。

第三步，大数据系统、容灾。

如果在一个页面中展示很多信息，还有一个技术方案，就是通过异步的数据清洗，整合到 nosql 的一张大表中。

用户扫描查询等相关业务，直接走 nosql 数据库即可。

这样处理的好处是，哪怕更新业务完全挂了，也不会影响用户扫码查询，因为两套系统、数据库都是完全分开的。

使用异地双机房等形式部署服务，同时做好整体的容灾、备灾方案，避免出现极端情况，比如机房光缆挖断等。

还有很多细节上的优化，这里就不一一说明了，这里也只是我的一些想法，欢迎大家留言补充。

6.最后

不管怎么分析，这肯定是人祸而不是天灾。

系统在没有经过严格测试之下，就直接投入到生产，在强度稍微大一点的环境中就崩溃了。

比西安大的城市很多，比西安现在疫情还要严重的情况，其它城市也遇到过，怎么没有出现类似的问题？

西安做为一个科技大省，出现这样的问题真的不应该，特别是我看了这个小程序背后使用的域名地址之后。

有一种无力吐槽的感觉，虽然说这和程序使用没有关系，但是从细节真的可以看出一个技术团队的实力。

希望这次能够吸取教训，避免再次出现类似的问题！

作者：纯洁的微笑
出处：https://www.cnblogs.com/ityouknow/p/15719395.html

使用git bisect二分法定位问题的基本步骤：

1. git bisect start [最近的出错的commitid] [较远的正确的commitid]

2. 测试相应的功能

3. git bisect good 标记正确

4. 直到出现问题则 标记错误 git bisect bad

5. 提示的commitid就是导致问题的那次提交

问题描述

我们以Vue DevUI组件库的一个bug举例子🌰

5d14c34b这一次commit，执行yarn build报错，报错信息如下：

✓ building client + server bundles...
✖ rendering pages...
build error:
 ReferenceError: document is not defined

我可以确定的是上一次发版本（d577ce4）是可以build成功的。

git bisect 简介

git bisect命令使用二分搜索算法来查找提交历史中的哪一次提交引入了错误。它几乎能让你闭着眼睛快速定位任何源码导致的问题，非常实用。

你只需要告诉这个命令一个包含该bug的坏commit ID和一个引入该bug之前的好commit ID，这个命令会用二分法在这两个提交之间选择一个中间的commit ID，切换到那个commit ID的代码，然后询问你这是好的commit ID还是坏的commit ID，你告诉它是好还是坏，然后它会不断缩小范围，直到找到那次引入bug的凶手commit ID。

这样我们就只需要分析那一次提交的代码，就能快速定位和解决这个bug（具体定位的时间取决于该次提交的代码量和你的经验），所以我们提交代码时一定要养成小批量提交的习惯，每次只提交一个小的独立功能，这样出问题了，定位起来会非常快。

接下来我就以Vue DevUI之前出现过的一个bug为例，详细介绍下如何使用git bisect这把利器。

定位过程

git bisect start 5d14c34b d577ce4
or
git bisect start HEAD d577ce4

其中5d14c34b这次是最近出现的有bug的提交，d577ce4这个是上一次发版本没问题的提交。

执行完启动bisect之后，马上就切到中间的一次提交啦，以下是打印结果：

kagol:vue-devui kagol$ git bisect start 5d14c34b d577ce4
Bisecting: 11 revisions left to test after this (roughly 4 steps)
[1cfafaaa58e03850e0c9ddc4246ae40d18b03d71] fix: read-tip icon样式泄露 (#54)

可以看到已经切到以下提交：

[1cfafaaa] fix: read-tip icon样式泄露 (#54)

执行命令：

yarn build

构建成功，所以标记下good：

git bisect good
kagol:vue-devui kagol$ git bisect good
Bisecting: 5 revisions left to test after this (roughly 3 steps)
[c0c4cc1a25c5c6967b85100ee8ac636d90eff4b0] feat(drawer): add service model (#27)

标记万good，马上又通过二分法，切到了一次新的提交：

[c0c4cc1a] feat(drawer): add service model (#27)

再次执行build命令：

yarn build

build失败了，出现了我们最早遇到的报错：

✓ building client + server bundles...

✖ rendering pages...

build error:

 ReferenceError: document is not defined

标记下bad，再一次切到中间的提交：

kagol:vue-devui kagol$ git bisect bad

Bisecting: 2 revisions left to test after this (roughly 2 steps)

[86634fd8efd2b808811835e7cb7ca80bc2904795] feat: add scss preprocessor in docs && fix:(Toast)  single lifeMode bug in Toast 

以此类推，不断地验证、标记、验证、标记...最终会提示我们那一次提交导致了这次的bug，提交者、提交时间、提交message等信息。

kagol:vue-devui kagol$ git bisect good

c0c4cc1a25c5c6967b85100ee8ac636d90eff4b0 is the first bad commit

commit c0c4cc1a25c5c6967b85100ee8ac636d90eff4b0

Author: nif <lnzhangsong@163.com>

Date:   Sun Dec 26 21:37:05 2021 +0800



    feat(drawer): add service model (#27)

    

    * feat(drawer): add service model

    

    * docs(drawer): add service model demo

    

    * fix(drawer): remove 'console.log()'



 packages/devui-vue/devui/drawer/index.ts           |  7 +++--

 .../devui-vue/devui/drawer/src/drawer-service.ts   | 33 ++++++++++++++++++++++

 packages/devui-vue/devui/drawer/src/drawer.tsx     |  3 ++

 packages/devui-vue/docs/components/drawer/index.md | 29 +++++++++++++++++++

 4 files changed, 69 insertions(+), 3 deletions(-)

 create mode 100644 packages/devui-vue/devui/drawer/src/drawer-service.ts

最终定位到出问题的commit：

c0c4cc1a is the first bad commit

github.com/DevCloudFE/…

整个定位过程几乎是机械的操作，不需要了解项目源码，不需要了解最近谁提交了什么内容，只需要无脑地：验证、标记、验证、标记，最后git会告诉我们那一次提交出错。

这么香的工具，赶紧来试试吧！

问题分析

直到哪个commit出问题了，定位起来范围就小了很多。

如果平时提交代码又能很好地遵循小颗粒提交的话，bug呼之欲出。

这里必须表扬下我们DevUI的田主（Contributor）们，他们都养成了小颗粒提交的习惯，这次导致bug的提交c0c4cc1a，只提交了4个文件，涉及70多行代码。

我们在其中搜索下document关键字，发现了两处，都在drawer-service.ts整个文件中：

一处是12行的：

static $body: HTMLElement | null = document.body

另一处是17行的：

this.$div = document.createElement('div')

最终发现罪魁祸首就是12行的代码！

破案！

作者：DevUI团队
来源：https://juejin.cn/post/7046409685561245733

为了保障生产数据的安全性，我们往往需要对数据库做备份，而通过MySQL主备配置，则是一种MySQL数据库备份的好的实现方案。本文将一步步带你搭建MySQL主备环境。

MySQL主备搭建

现有两台虚拟机，192.168.56.11（主）和192.168.56.12（备）

1 MySQL安装

离线安装解压版MySQL

1 上传压缩包

• 以root用户上传mysql-5.7.29-linux-glibc2.12-x86_64.tar.gz到/root/Downloads/下

2 解压

• cd /root/Downloads

• tar -zxvf mysql-5.7.29-linux-glibc2.12-x86_64.tar.gz

• mv mysql-5.7.29-linux-glibc2.12-x86_64 mysql5.7

• mkdir /usr/database

• mv mysql5.7 /usr/database

3 创建系统用户组和用户

• groupadd mysql

• useradd -r -g mysql mysql

• id mysql

4 创建mysql data目录

• cd /usr/database/mysql5.7

• mkdir data

4 设置data目录权限

• chown -R mysql:mysql /usr/database/mysql5.7/

• ll /usr/database

5 修改my.cnf文件

删除并重新创建/etc/my.cnf：

rm -rf /etc/my.cnf
vim /etc/my.cnf
[client]
port = 3306
socket = /tmp/mysql.sock

[mysqld]
init-connect='SET NAMES utf8'
basedir=/usr/database/mysql5.7      #根据自己的安装目录填写 
datadir=/usr/database/mysql5.7/data #根据自己的mysql数据目录填写
socket=/tmp/mysql.sock
max_connections=200                 # 允许最大连接数
character-set-server=utf8           # 服务端使用的字符集默认为8比特编码的latin1字符集
default-storage-engine=INNODB       # 创建新表时将使用的默认存储引擎

最大连接数

• max_connections<=16384

• 管理员(SUPER)登录的连接，不计其中

• mysql会为每个连接提供连接缓冲区，连接越多内存开销越大

• 查询：show variables like '%_connections'; ，show status like '%_connections';

• max_used_connections / max_connections * 100% （理想值≈ 85%）

• 数值过小会经常出现ERROR 1040: Too many connections错误

• 修改方法：

• 永久：在配置文件my.cnf中设置max_connections的值

• 临时：以root登录mysql：set GLOBAL max_connections=xxx;->flush privileges;

mysql存储引擎

• InnoDB：5.5及之后版本的默认引擎

• 支持事务

• 聚集索引，文件存放在主键索引的叶子节点上，必须要有主键。通过主键索引效率很高，但是辅助索引需要两次查询，先查询到主键，然后再通过主键查询到数据。因此，主键不应该过大，因为主键太大，其他索引也都会很大。

• 不支持全文类型索引

• 支持外键

• 不保存表的具体行数，执行 select count(*) from table 时需要全表扫描。

• 最小锁粒度是行锁

• 适用场景：支持事物、较多写操作、系统崩溃后相对易恢复

• MyISAM：5.5版本之前的默认引擎

• 不支持事务

• 非聚集索引，数据文件是分离的，索引保存的是数据文件的指针，主键索引和辅助索引是独立的。

• 保存了整个表的行数，执行select count(*) 时只需要读出该变量即可，速度很快；

• 支持全文类型索引

• 不支持外键

• 最小锁粒度是表锁，一个更新语句会锁住整张表，导致其他查询和更新都被阻塞，因此并发访问受限

• 表以文件形式保存，跨平台使用较方便

• 适用场景：非事物型、读操作、小型应用

6 mysql初始化

• /usr/database/mysql5.7/bin/mysqld --initialize-insecure --user=mysql --basedir=/usr/database/mysql5.7 --datadir=/usr/database/mysql5.7/data

#注意：mysqld --initialize-insecure初始化后的mysql是没有密码的

• chown -R root:root /usr/database/mysql5.7/ #把安装目录的目录的权限所有者改为root

• chown -R mysql:mysql /usr/database/mysql5.7/data/ #把data目录的权限所有者改为mysql

7 启动mysql

/usr/database/mysql5.7/bin/mysqld_safe --user=mysql &

8 修改root密码

• cd /usr/database/mysql5.7/bin

• ./mysql -u root -p # 默认没有密码，直接回车就行

• use mysql;

• update user set authentication_string=password('``rootpasswd``') where user='root';

• flush privileges;

• exit;

9 登录测试

• /usr/database/mysql5.7/bin/mysql mysql -u root -p

• (输入密码)

• show databases;

• exit;

10 启动设置

• cp /usr/database/mysql5.7/support-files/mysql.server /etc/init.d/mysql

• chkconfig --add mysql # 添加服务

• chkconfig --list # 查看服务列表

• chkconfig --level 345 mysql on # 设置开机启动

11 测试服务命令是否可用

• systemctl status mysql

• systemctl start mysql

• systemctl stop mysql

12 设置远程访问

• 登录数据库：mysql -uroot -p[password]

• use mysql;

• select host,user from user;

• update user set host='%' where user='root';

• flush privileges;

• 如果还是无法访问，检查防火墙

13 创建新用户

• 创建用户app：create user 'app'@'%' identified by 'password';

• 用户赋权(具有数据库appdb的所有权限，并可远程不限ip访问)：grant all on appdb.* to 'app'@'%';

• flush privilegesl;

14 其他问题

• -bash: mysql: command not found

• 临时方案，重新登录后失效：alias mysql=/usr/database/mysql5.7/bin/mysql

• 永久方案，将命令路径添加到PATH中：

• vim /etc/profile

• PATH="$PATH:/usr/database/mysql5.7/bin"

• source /etc/profile

2 主备配置

1 生产环境为什么需要MySQL集群

• 高可用性，在主节点失效时自动切换，不需要技术人员紧急处理

• 高吞吐，可以多个节点同时提供读取数据服务，降低主节点负载，实现高吞吐

• 可扩展性强，支持在线扩容

• 无影响备份，在备节点进行备份操作不会对业务产生影响

MySQL集群的缺点：

• 架构复杂，在部署、管理方面对技术人员要求高

• 备节点拉取主节点日志时会对主节点服务器性能有一定影响

• 如果配置了半同步复制，会对事物提交有一定影响

2 修改my.cnf

• 主备服务器均创建日志文件路径：mkdir /data/mysql_log

• 修改master下的/etc/my.cnf:

[client]
port = 3306
default-character-set=utf8mb4
socket = /usr/database/mysql5.7/mysql.sock

[mysqld]
basedir = /usr/database/mysql5.7
datadir = /usr/database/mysql5.7/data
tmpdir = /tmp
socket = /tmp/mysql.sock
# pid-file = /data/mysql_db/mysql_seg_3306/mysql.pid
skip-external-locking = 1
skip-name-resolve = 1
port = 3306
server-id = 113306

default-storage-engine = InnoDB
character-set-server = utf8mb4
default_password_lifetime=0

#### log ####
log_timestamps=system
log_bin = /data/mysql_log/mysql-bin
log_bin_index = /data/mysql_log/mysql-bin.index
binlog_format = row
relay_log_recovery=ON
relay_log=/data/mysql_log/mysql-relay-bin
relay_log_index=/data/mysql_log/mysql-relay-bin.index
log_error = /data/mysql_log/mysql-error.log

#### replication ####
replicate_wild_ignore_table = information_schema.%,performance_schema.%,sys.%

#### semi sync replication settings #####
plugin_dir=/usr/database/mysql5.7/lib/plugin
plugin_load = "rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so"
loose_rpl_semi_sync_master_enabled = 1
loose_rpl_semi_sync_slave_enabled = 1
loose_rpl_semi_sync_master_timeout = 5000

• 修改slave下的/etc/my.cnf:

[client]
port = 3306
default-character-set=utf8mb4
socket = /usr/database/mysql5.7/mysql.sock

[mysqld]
basedir = /usr/database/mysql5.7
datadir = /usr/database/mysql5.7/data
tmpdir = /tmp
socket = /tmp/mysql.sock
# pid-file = /data/mysql_db/mysql_seg_3306/mysql.pid
skip-external-locking = 1
skip-name-resolve = 1
port = 3306
server-id = 123306
read-only=1

default-storage-engine = InnoDB
character-set-server = utf8mb4
default_password_lifetime=0

#### log ####
log_timestamps=system
log_bin = /data/mysql_log/mysql-bin
log_bin_index = /data/mysql_log/mysql-bin.index
binlog_format = row
relay_log_recovery=ON
relay_log=/data/mysql_log/mysql-relay-bin
relay_log_index=/data/mysql_log/mysql-relay-bin.index
log_error = /data/mysql_log/mysql-error.log

#### replication ####
replicate_wild_ignore_table = information_schema.%,performance_schema.%,sys.%

#### semi sync replication settings #####
plugin_dir=/usr/database/mysql5.7/lib/plugin
plugin_load = "rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so"
loose_rpl_semi_sync_master_enabled = 1
loose_rpl_semi_sync_slave_enabled = 1
loose_rpl_semi_sync_master_timeout = 5000

• utf8：最大unicode字符是0xffff，仅支持Unicode 中的基本多文种平面(BMP)，任何不在基本多文本平面的 Unicode字符，都无法使用 Mysql 的 utf8 字符集存储。

• utf8mb4（most bytes 4）专门用来兼容四字节的unicode，是utf8的超集，包含很多不常用的汉字、Emoji表情，以及任何新增的 Unicode 字符等等

• server-id

3 master上创建同步用户

• mysql -uroot -proot

• use mysql;

• create user 'repl'@'%' identified by 'repl';

• grant replication slave on . to 'repl'@'%';

• flush privileges;

4 备份master数据库

/usr/database/mysql5.7/bin/mysqldump -S /tmp/mysql.sock -F --opt -R --single-transaction --master-data=2 --default-character-set=utf8 -A > mysql_backup_full.sql

上述命令报错，1045，增加登录信息：

/usr/database/mysql5.7/bin/mysqldump -uroot -proot -S /tmp/mysql.sock -F --opt -R --single-transaction --master-data=2 --default-character-set=utf8 -A > mysql_backup_full.sql

导出指定数据库（仅表结构）：

/usr/database/mysql5.7/bin/mysqldump -uroot -proot -S /tmp/mysql.sock -F --opt -R --single-transaction --master-data=2 --default-character-set=utf8 -d testdb1 testdb2 > mysql_backup_test.sql

导出指定数据库（表结构+数据）：

**/usr/database/mysql5.7/bin/mysqldump -uroot -proot -S /tmp/mysql.sock -F --opt -R --single-transaction --master-data=2 --default-character-set=utf8 testdb1 testdb2 > mysql_backup_testdatas.sql**

5 slave上恢复master数据库

master推送sql：rsync -avzP mysql_backup_test.sql 192.168.56.12:/root/Downloads/

slave导入sql：/usr/database/mysql5.7/bin/mysqldump -S /tmp/mysql.sock < mysql_backup_test.sql

上述命令不成功，需先创建数据库，改为下述操作：

**mysql -uroot -proot**
**use test;**
**source /root/Downloads/**``**mysql_backup_test.sql**

6 开启同步

• mysql命令行中查看master status中的File和Position参数：show master status;

• 查看进程：show processlist\G

• slave的mysql命令行执行：

mysql> CHANGE MASTER TO
    -> MASTER_HOST='192.168.41.83',
    -> MASTER_PORT=3306,
    -> MASTER_USER='repl',
    -> MASTER_PASSWORD='repl',
    -> MASTER_LOG_FILE='mysql-bin.000004',
    -> MASTER_LOG_POS=154;
mysql> start slave;
mysql> show slave status\G

状态中注意这几项：

Slave_IO_Running：取 Master 日志的线程, Yes 为正在运行

Slave_SQL_Running：从日志恢复数据的线程, Yes 为正在运行

Seconds_Behind_Master：当前数据库相对于主库的数据延迟， 这个值是根据二进制日志的时间戳计算得到的(秒)

7 同步测试

master数据库插入一条数据，可用看到slave同步更新了

主备有了，要是能够故障自动切换就完美了，这正是下一篇内容。

引用请注明出处！

90% 的程序员直接或者间接的使用过动态代理，无论是日志框架或 Spring 框架，它们都包含了动态代理的实现代码。动态代理是程序在运行期间动态构建代理对象和动态调用代理方法的一种机制。

今天的面试题是：如何实现动态代理？JDK Proxy 和 CGLib 有什么区别？

典型回答

动态代理的常用实现方式是反射。反射机制 是指程序在运行期间可以访问、检测和修改其本身状态或行为的一种能力，使用反射我们可以调用任意一个类对象，以及类对象中包含的属性及方法。

但动态代理不止有反射一种实现方式，例如，动态代理可以通过 CGLib 来实现，而 CGLib 是基于 ASM（一个 Java 字节码操作框架）而非反射实现的。简单来说，动态代理是一种行为方式，而反射或 ASM 只是它的一种实现手段而已。

JDK Proxy 和 CGLib 的区别主要体现在以下几个方面：

• JDK Proxy 是 Java 语言自带的功能，无需通过加载第三方类实现；

• Java 对 JDK Proxy 提供了稳定的支持，并且会持续的升级和更新 JDK Proxy，例如 Java 8 版本中的 JDK Proxy 性能相比于之前版本提升了很多；

• JDK Proxy 是通过拦截器加反射的方式实现的；

• JDK Proxy 只能代理继承接口的类；

• JDK Proxy 实现和调用起来比较简单；

• CGLib 是第三方提供的工具，基于 ASM 实现的，性能比较高；

• CGLib 无需通过接口来实现，它是通过实现子类的方式来完成调用的。

考点分析

此面试题考察的是你对反射、动态代理及 CGLib 的了解，很多人经常会把反射和动态代理划为等号，但从严格意义上来说，这种想法是不正确的，真正能搞懂它们之间的关系，也体现了你扎实 Java 的基本功。和这个问题相关的知识点，还有以下几个：

• 你对 JDK Proxy 和 CGLib 的掌握程度。

• Lombok 是通过反射实现的吗？

• 动态代理和静态代理有什么区别？

• 动态代理的使用场景有哪些？

• Spring 中的动态代理是通过什么方式实现的？

知识扩展

1.JDK Proxy 和 CGLib 的使用及代码分析

JDK Proxy 动态代理实现

JDK Proxy 动态代理的实现无需引用第三方类，只需要实现 InvocationHandler 接口，重写 invoke() 方法即可，整个实现代码如下所示：

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;

/**
 * JDK Proxy 相关示例
 */
public class ProxyExample {
    static interface Car {
        void running();
    }

    static class Bus implements Car {
        @Override
        public void running() {
            System.out.println("The bus is running.");
        }
    }

    static class Taxi implements Car {
        @Override
        public void running() {
            System.out.println("The taxi is running.");
        }
    }

    /**
     * JDK Proxy
     */
    static class JDKProxy implements InvocationHandler {
        private Object target; // 代理对象

        // 获取到代理对象
        public Object getInstance(Object target) {
            this.target = target;
            // 取得代理对象
            return Proxy.newProxyInstance(target.getClass().getClassLoader(),
                    target.getClass().getInterfaces(), this);
        }

        /**
         * 执行代理方法
         * @param proxy  代理对象
         * @param method 代理方法
         * @param args   方法的参数
         * @return
         * @throws InvocationTargetException
         * @throws IllegalAccessException
         */
        @Override
        public Object invoke(Object proxy, Method method, Object[] args)
                throws InvocationTargetException, IllegalAccessException {
            System.out.println("动态代理之前的业务处理.");
            Object result = method.invoke(target, args); // 执行调用方法（此方法执行前后，可以进行相关业务处理）
            return result;
        }
    }

    public static void main(String[] args) {
        // 执行 JDK Proxy
        JDKProxy jdkProxy = new JDKProxy();
        Car carInstance = (Car) jdkProxy.getInstance(new Taxi());
        carInstance.running();
}

以上程序的执行结果是：

动态代理之前的业务处理.
The taxi is running.

可以看出 JDK Proxy 实现动态代理的核心是实现 Invocation 接口，我们查看 Invocation 的源码，会发现里面其实只有一个 invoke() 方法，源码如下：

public interface InvocationHandler {
  public Object invoke(Object proxy, Method method, Object[] args)
          throws Throwable;
}

这是因为在动态代理中有一个重要的角色也就是代理器，它用于统一管理被代理的对象，显然 InvocationHandler 就是这个代理器，而 invoke() 方法则是触发代理的执行方法，我们通过实现 Invocation 接口来拥有动态代理的能力。

CGLib 的实现

在使用 CGLib 之前，我们要先在项目中引入 CGLib 框架，在 pom.xml 中添加如下配置：

<!-- https://mvnrepository.com/artifact/cglib/cglib -->
<dependency>
    <groupId>cglib</groupId>
    <artifactId>cglib</artifactId>
    <version>3.3.0</version>
</dependency>

CGLib 实现代码如下：

package com.lagou.interview;

import net.sf.cglib.proxy.Enhancer;
import net.sf.cglib.proxy.MethodInterceptor;
import net.sf.cglib.proxy.MethodProxy;

import java.lang.reflect.Method;

public class CGLibExample {

    static class Car {
        public void running() {
            System.out.println("The car is running.");
        }
    }

    /**
     * CGLib 代理类
     */
    static class CGLibProxy implements MethodInterceptor {
        private Object target; // 代理对象

        public Object getInstance(Object target) {
            this.target = target;
            Enhancer enhancer = new Enhancer();
            // 设置父类为实例类
            enhancer.setSuperclass(this.target.getClass());
            // 回调方法
            enhancer.setCallback(this);
            // 创建代理对象
            return enhancer.create();
        }

        @Override
        public Object intercept(Object o, Method method,
                                Object[] objects, MethodProxy methodProxy) throws Throwable {
            System.out.println("方法调用前业务处理.");
            Object result = methodProxy.invokeSuper(o, objects); // 执行方法调用
            return result;
        }
    }

    // 执行 CGLib 的方法调用
    public static void main(String[] args) {
        // 创建 CGLib 代理类
        CGLibProxy proxy = new CGLibProxy();
        // 初始化代理对象
        Car car = (Car) proxy.getInstance(new Car());
        // 执行方法
        car.running();
}

以上程序的执行结果是：

方法调用前业务处理.
The car is running.

可以看出 CGLib 和 JDK Proxy 的实现代码比较类似，都是通过实现代理器的接口，再调用某一个方法完成动态代理的，唯一不同的是，CGLib 在初始化被代理类时，是通过 Enhancer 对象把代理对象设置为被代理类的子类来实现动态代理的。因此被代理类不能被关键字 final 修饰，如果被 final 修饰，再使用 Enhancer 设置父类时会报错，动态代理的构建会失败。

2.Lombok 原理分析

在开始讲 Lombok 的原理之前，我们先来简单地介绍一下 Lombok，它属于 Java 的一个热门工具类，使用它可以有效的解决代码工程中那些繁琐又重复的代码，如 Setter、Getter、toString、equals 和 hashCode 等等，向这种方法都可以使用 Lombok 注解来完成。

例如，我们使用比较多的 Setter 和 Getter 方法，在没有使用 Lombok 之前，代码是这样的：

public class Person {
    private Integer id;
    private String name;
    public Integer getId() {
        return id;
    }
    public void setId(Integer id) {
        this.id = id;
    }
    public String getName() {
        return name;
    }
    public void setName(String name) {
        this.name = name;
    }
}

在使用 Lombok 之后，代码是这样的：

@Data
public class Person {
    private Integer id;
    private String name;
}

可以看出 Lombok 让代码简单和优雅了很多。

小贴士：如果在项目中使用了 Lombok 的 Getter 和 Setter 注解，那么想要在编码阶段成功调用对象的 set 或 get 方法，我们需要在 IDE 中安装 Lombok 插件才行，比如 Idea 的插件如下图所示：

接下来讲讲 Lombok 的原理。

Lombok 的实现和反射没有任何关系，前面我们说了反射是程序在运行期的一种自省（introspect）能力，而 Lombok 的实现是在编译期就完成了，为什么这么说呢？

回到我们刚才 Setter/Getter 的方法，当我们打开 Person 的编译类就会发现，使用了 Lombok 的 @Data 注解后的源码竟然是这样的：

可以看出 Lombok 是在编译期就为我们生成了对应的字节码。

其实 Lombok 是基于 Java 1.6 实现的 JSR 269: Pluggable Annotation Processing API 来实现的，也就是通过编译期自定义注解处理器来实现的，它的执行步骤如下：

从流程图中可以看出，在编译期阶段，当 Java 源码被抽象成语法树（AST）之后，Lombok 会根据自己的注解处理器动态修改 AST，增加新的代码（节点），在这一切执行之后就生成了最终的字节码（.class）文件，这就是 Lombok 的执行原理。

3.动态代理知识点扩充

当面试官问动态代理的时候，经常会问到它和静态代理的区别？静态代理其实就是事先写好代理类，可以手工编写也可以使用工具生成，但它的缺点是每个业务类都要对应一个代理类，特别不灵活也不方便，于是就有了动态代理。

动态代理的常见使用场景有 RPC 框架的封装、AOP（面向切面编程）的实现、JDBC 的连接等。

Spring 框架中同时使用了两种动态代理 JDK Proxy 和 CGLib，当 Bean 实现了接口时，Spring 就会使用 JDK Proxy，在没有实现接口时就会使用 CGLib，我们也可以在配置中指定强制使用 CGLib，只需要在 Spring 配置中添加 <aop:aspectj-autoproxy proxy-target-/> 即可。

小结

今天我们介绍了 JDK Proxy 和 CGLib 的区别，JDK Proxy 是 Java 语言内置的动态代理，必须要通过实现接口的方式来代理相关的类，而 CGLib 是第三方提供的基于 ASM 的高效动态代理类，它通过实现被代理类的子类来实现动态代理的功能，因此被代理的类不能使用 final 修饰。

除了 JDK Proxy 和 CGLib 之外，我们还讲了 Java 中常用的工具类 Lombok 的实现原理，它其实和反射是没有任何关系的；最后讲了动态代理的使用场景以及 Spring 中动态代理的实现方式，希望本文可以帮助到你。

作者：Java面试真题解析
来源：https://mp.weixin.qq.com/s/UIMeWRerV9FhtEotV8CF9w

一、内存区域划分

Java程序执行时在逻辑上按照功能划分为不同的区域，其中包括方法区、堆区、Java虚拟机栈、本地方法栈、程序计数器、执行引擎、本地库接口、本地方法库几个部分，各个区域宏观结构如下，各部分详细功能及作用暂不展开论述。

JVM内存自动管理是Java语言的一大优良特性，也是Java语言在软件市场长青的一大优势，有了JVM的自动内存管理，程序员不再为令人抓狂的内存泄漏担忧，但深入理解Java虚拟机内存区域依然至关重要，JVM内存自动管理并非永远万无一失，不当的使用也会造成OOM等内存异常，本文尝试列举Java内存溢出相关的常见异常并提供使用建议。

二、栈溢出

• 方法调用深度过大

我们知道Java虚拟机栈及本地方法栈中存放的是方法调用所需的栈帧，栈帧是一种包括局部变量表、操作数栈、动态链接和方法返回地址的数据结构，每一次方法的调用和返回对应着压栈及出栈操作。Java虚拟机栈及本地方法栈由每个Java执行线程独享，当方法嵌套过深直至超过栈的最大空间时，当再次执行压栈操作，将抛出StackOverflowError异常。为演示栈溢出，假设存在如下代码：

/**
* 最大栈深度
*/
public class MaxInvokeDeep {
   private static int count = 0;

   /**
    * 无终止条件的递归调用，每次调用将进行压栈操作，超过栈最大空间后，将抛出stackOverFlow异常
    */
   public static void increment() {
       count++;
       increment();
   }

   public static void main(String[] args) {
       try {
           increment();
       } catch (Throwable e) {
           System.out.println("invokeDeep:" + count);
           e.printStackTrace();
       }
   }
}

对于示例中的increment()方法，每次方法调用将深度+1，通过不断的栈帧压栈操作，当栈中空间无法再进行扩展时，程序将抛出StackOverflowError异常。Java虚拟机栈的空间大小可以通过JVM参数调整，我们先设置栈空间大小为512K（-Xss512k），程序执行结果如下：(方法调用5355次后触发栈溢出) 我们再将栈空间缩小至256k(-Xss256k)，程序执行结果如下：(方法调用2079次时将触发栈溢出)： 由此可见，Java虚拟机栈的空间是有限的，当我们进行程序设计时，应尽量避免使用递归调用。生产环境抛出StackOverflowError异常时，可以排查系统中是否存在调用深度过大的方法。方法的不断嵌套调用，不但会占用更多的内存空间，也会影响程序的执行效率。当我们进行程序设计时需要充分考虑并设置合理的栈空间大小，一般情况下虚拟机默认配置即满足大部分应用场景。

• 局部变量表过大

局部变量表用于存放Java方法中的局部变量，我们需要合理的设置局部变量，避免过多的冗余变量产生，否则可能会导致栈溢出，沿用刚刚的实例代码，我们定义一个创建大量局部变量的重载方法，则在栈空间不变的情况下(-Xss512k),创建大量局部变量的方法将降低栈调用深度，更容易触发StackOverflowError异常，通过分别执行increment及其重载方法，其中代码及执行结果如下：

package org.learn.jvm.basic;

/**
 * 最大栈深度
 */
public class MaxInvokeDeep {
    private static int count = 0;

    /**
     * 无终止条件的递归调用，每次调用将进行压栈操作，超过栈最大空间后，将抛出stackOverFlow异常
     */
    public static void increment() {
        count++;
        increment();
    }

    /**
     * 创建大量局部变量，导致局部变量表过大，影响栈调用深度
     *
     * @param a
     * @param b
     * @param c
     */
    public static void increment(long a, long b, long c) {
        long d = 1, e = 2, f = 3, g = 4, h = 5, i = 6,
                j = 7, k = 8, l = 9, m = 10;
        count++;
        increment(a, b, c);
    }

    public static void main(String[] args) {
        try {
            //increment();
            increment(1, 2, 3);
        } catch (Throwable e) {
            System.out.println("invokeDeep:" + count);
            e.printStackTrace();
        }
    }
}

执行increment()时，最大栈深度为5355（栈空间大小-Xss512k）

执行increment(1,2,3)时，最大栈深度为1487（栈空间大小-Xss512k）

通过对比我们知道，创建大量的局部变量将使得局部变量表膨胀从而引发StackOverflowError异常，程序设计时应当尽量避免同一个方法中包含大量局部变量，实在无法避免可以考虑方法的重构及拆分。

三、OOM

对于Java程序员而言，OOM算是比较常见的生产环境异常，OOM往往容易引发线上事故，因此有必要梳理常见可能导致OOM的场景，并尽量规避保障服务的稳定性。

• 创建大量的类

方法区主要的职责是用于存放类型相关信息，如类名、接口名、父类、访问修饰符、字段描述、方法描述等，Java8以后方法区从永久区移到了Metaspace，若系统中创建过多的类时，可能会引发OOM。Java开发中经常会利用字节码增强技术，通过创建代理类从而实现系统功能，以我们熟知的Spring框架为例，经常通过Cglib运行时创建代理类实现类的动态性，通过设置虚拟机参数，-XX:MaxMetaspaceSize=10M，则示例程序运行一段时间时间后，将触发Full GC并最终抛出OOM异常，因此日常开发过程中要特别留意，系统中创建的类的数量是否合理，以免产生OOM。实例代码如下：

/**
 * 大量创建类导致方法区OOM
 */
public class JavaMethodAreaOOM {
    /**
     * VM Args: -XX:MaxMetaspaceSize=10M（设置Metaspace空间为10MB）
     *
     * @param args
     */
    public static void main(String[] args) {
        while (true) {
            Enhancer enhancer = new Enhancer();
            enhancer.setSuperclass(OOMObject.class);
            enhancer.setUseCache(false);
            enhancer.setCallback(new MethodInterceptor() {
                @Override
                public Object intercept(Object obj, Method method,
                                        Object[] args, MethodProxy proxy) throws Throwable {
                    return proxy.invokeSuper(obj, args);
                }
            });
            Object object = enhancer.create();
            System.out.println("hashcode:" + object.hashCode());
        }
    }

    /**
     * 对象
     */
    static class OOMObject {

    }
}

设置虚拟机参数：-Xms1M -Xmx1M -verbose:gc -XX:+PrintGCDetails 限定元数据区为10M，则虚拟机Full GC之后，将引发OOM异常，程序执行结果如下：

• 创建大对象

Java堆内存空间非常宝贵，若系统中存在数组、复杂嵌套对象等大对象，将会引发FullGc并最终引发OOM异常，因此程序设计时需要合理设置类结构，避免产生过大的对象，示例代码如下：

/**
 * 堆内存溢出
 */
public class HeapOOM {
    /**
     *
     */
    static class InnerClass {
        private int value;
        private byte[] bytes = new byte[1024];
    }

    /**
     * VM Args: -Xms1M -Xmx1M -verbose:gc -XX:+PrintGCDetails
     *
     * @param args
     */
    public static void main(String[] args) {
        List<InnerClass> innerClassList = new ArrayList<>();
        while (true) {
            innerClassList.add(new InnerClass());
        }
    }
}

设置虚拟机参数：-Xms1M -Xmx1M -verbose:gc -XX:+PrintGCDetails 限定最大堆内存空间为10M，则虚拟机Full GC之后，将引发OOM异常，程序执行结果如下。

• 常量池溢出

Java8开始，常量池从永久区移至堆区，当系统中存在大量常量并超过常量池最大容量时，将引发OOM异常。String类的intern()方法内部逻辑是:若常量池中存在字符串常量，则直接返回字符串引用，否则创建常量将其加入常量池中并返回常量池引用。通过每次创建不同的字符串，常量池将因为无法容纳新创建的字符串常量而最终引发OOM，示例代码如下：

/**
 * VM Args: -Xms1M -Xmx1M -verbose:gc -XX:+PrintGCDetails
 *
 * @param args
 */
public static void main(String[] args) {
    Set<String> set = new HashSet<>();
    int i = 0;
    while (true) {
        set.add(String.valueOf(i++).intern());
    }
}

设置虚拟机参数：-Xms1M -Xmx1M -verbose:gc -XX:+PrintGCDetails 限定最大堆内存空间为10M，则虚拟机Full GC之后，将引发OOM异常，程序执行结果如下。

• 直接内存溢出

直接内存是因NIO技术而引入的独立于堆区的一块内存空间，对于读写频繁的场景，通过直接操作直接内存可以获得更高的执行效率，但其内存空间受制于操作系统本地内存大小，超过最大限制后，也将抛出OOM 异常，以下代码通过UnSafe类，直接操作内存，程序执行一段时间后，将引发OOM异常。

public class DirectMemoryOOM {
    private static final int _1MB = 1024 * 1024;

    /**
     * VM Args:-Xmx20M -XX:MaxDirectMemorySize=10M
     * @param args
     * @throws IllegalAccessException
     */
    public static void main(String[] args) throws IllegalAccessException {
        Field field = Unsafe.class.getDeclaredFields()[0];
        field.setAccessible(true);
        Unsafe unsafe = (Unsafe) field.get(null);
        while (true) {
            unsafe.allocateMemory(_1MB*1024);
        }
    }
}

设置虚拟机参数：-Xmx20M -XX:MaxDirectMemorySize=10M 限定最大直接内存空间为10M，程序最终执行结果如下：

四、总结

本文通过实际的案例列举了常见的OOM异常，由此我们可以得知，程序设计过程中应当合理的设置栈区、堆区、直接内存的大小，从实际情况出发，合理设计数据结构，从而避免引发OOM故障，此外通过分析引发OOM的原因也有利于我们针对深入理解JVM并对现有系统进行系统调优。

作者：洞幺幺洞
来源：https://juejin.cn/post/7043442191619850277

本文从异步、解耦、削峰填谷等核心应用场景，以及消息中间件常用协议、推拉模式对比来解答此问题。

什么是消息中间件

作为一种典型的消息代理组件（Message Broker），是企业级应用系统中常用的消息中间件，主要应用于分布式系统或组件之间的消息通讯，提供具有可靠、异步和事务等特性的消息通信服务。应用消息代理组件可以降低系统间耦合度，提高系统的吞吐量、可扩展性和高可用性。

分布式消息服务主要涉及五个核心角色，消息发布者（Publisher）、可靠消息组件（MsgBroker）、消息订阅者（Subscriber）、消息类型（Message Type）和订阅关系（Binding），具体描述如下：

1. 消息发布者，指发送消息的应用系统，一个应用系统可以发送一种或者多种消息类型，发布者发送消息到可靠消息组件 (MsgBroker)。

2. 可靠消息组件，即 MsgBroker，负责接收发布者发送的消息，根据消息类型和订阅关系将消息分发投递到一个或多个消息订阅者。整个过程涉及消息类型校验、消息持久化存储、订阅关系匹配、消息投递和消息恢复等核心功能。

3. 消息订阅者，指订阅消息的应用系统，一个应用系统可以订阅一种或者多种消息类型，消息订阅者收到的消息来自可靠消息组件 (MsgBroker)。

4. 消息类型：一种消息类型由 TOPIC 和 EVENTCODE 唯一标识。

5. 订阅关系，用来描述一种消息类型被订阅者订阅，订阅关系也被称为 Binding。

核心功能特色

可为不同应用系统间提供可靠的消息通信，降低系统间耦合度并提高整体架构的可扩展性和可用性。

可为不同应用系统间提供异步消息通信，提高系统吞吐量和性能。

发布者系统、消息代理组件以及订阅者系统均支持集群水平扩展，可依据业务消息量动态部署计算节点。

支持事务型消息，保证消息与本地数据库事务的一致性。

远程调用RPC和消息MQ区别

谈到消息队列，有必要看下RPC和MQ的本质区别，从两者的定义和定位来看，RPC（Remote Procedure Call）远程过程调用，主要解决远程通信间的问题，不需要了解底层网络的通信机制；消息队列（MQ）是一种能实现生产者到消费者单向通信的通信模型。核心区别在于RPC是双向直接网络通讯，MQ是单向引入中间载体的网络通讯。单纯去看队列，队列是一种特殊的线性表，特殊之处在于它只允许在表的前端（front）进行删除操作，而在表的后端（rear）进行插入操作，和栈一样，队列是一种操作受限制的线性表。进行插入操作的端称为队尾，进行删除操作的端称为队头。在队列前面增加限定词“消息”，意味着通过消息驱动来进行整体的架构实现。RPC和MQ本质上是网络通讯的两种不同的实现机制，RPC同步等待结果对比于MQ在异步、解耦、削峰填谷等上的特征显著差异主要有以下几点差异：

1. 在架构上，RPC和MQ的差异点是，Message有一个中间结点Message Queue，可以把消息存储起来。

2. 同步调用：对于要立即等待返回处理结果的场景，RPC是首选。

3. MQ的使用，一方面是基于性能的考虑，比如服务端不能快速的响应客户端（或客户端也不要求实时响应），需要在队列里缓存；另外一方面，它更侧重数据的传输，因此方式更加多样化，除了点对点外，还有订阅发布等功能。

4. 随着业务增长，有的处理端调用下游服务太多或者处理量会成为瓶颈，会进行同步调用改造为异步调用，这个时候可以考虑使用MQ。

核心应用场景

针对MQ的核心场景，我们从异步、解耦、削峰填谷等特性进行分析，区别于传统的RPC调用。尤其在引入中间节点的情况下，通过空间（拥有存储能力）换时间（RPC同步等待响应）的思想，增加更多的可能性和能力。

异步通信

针对不需要立即处理消息，尤其那种非常耗时的操作，通过消息队列提供了异步处理机制，通过额外的消费线程接管这部分进行异步操作处理。

解耦

在应用和应用之间，提供了异构系统之间的消息通讯的机制，通过消息中间件解决多个系统或异构系统之间除了RPC之外另一种单向通讯的机制。

扩展性

因为消息队列解耦了主流程的处理过程，只要另外增加处理过程即可，不需要改变代码、不需要调整参数，便于分布式扩容。

分布式事务一致性

在2个应用系统之间的数据状态同步，需要考虑数据状态的最终一致性的场景下，利用消息队列所提供的事务消息来实现系统间的数据状态一致性。

削峰填谷

在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量无法提前预知；如果为了能处理这类瞬间峰值访问提前准备应用资源无疑是比较大的浪费。使用消息队列在突发事件下的防脉冲能力提供了一种保障，能够接管前台的大脉冲请求，然后异步慢速消费。

可恢复性

系统的一部分组件失效时，不会影响到整个系统。消息队列降低了应用间的耦合度，所以即使一个处理消息的应用挂掉，加入队列中的消息仍然可以在系统恢复后被处理。

顺序保证

在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来进行处理。

大量堆积

通过消息堆积能力处理数据迁移场景，针对旧数据进行全量迁移的同时开启增量消息堆积，待全量迁移完毕，再开启增量，保证数据最终一致性且不丢失。

数据流处理

分布式系统产生的海量数据流，如：业务日志、监控数据、用户行为等，针对这些数据流进行实时或批量采集汇总，然后导入到大数据实时计算引擎，通过消息队列解决异构系统的数据对接能力。

业界消息中间件对比

详细的对比可以参考：blog.csdn.net/wangzhipeng…

消息中间件常用协议

AMQP协议

AMQP即Advanced Message Queuing Protocol,提供统一消息服务的高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同开发语言等条件的限制。

优点：可靠、通用

MQTT协议

MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是IBM开发的一个即时通讯协议，成为物联网的重要组成部分。该协议支持所有平台，几乎可以把所有联网物品和外部连接起来，被用来当做传感器和致动器（比如通过Twitter让房屋联网）的通信协议。

优点：格式简洁、占用带宽小、移动端通信、PUSH、嵌入式系统

STOMP协议

STOMP（Streaming Text Orientated Message Protocol）是流文本定向消息协议，是一种为MOM(Message Oriented Middleware，面向消息的中间件)设计的简单文本协议。STOMP提供一个可互操作的连接格式，允许客户端与任意STOMP消息代理（Broker）进行交互。

优点：命令模式（非topic/queue模式）

XMPP协议

XMPP（可扩展消息处理现场协议，Extensible Messaging and Presence Protocol）是基于可扩展标记语言（XML）的协议，多用于即时消息（IM）以及在线现场探测。适用于服务器之间的准即时操作。核心是基于XML流传输，这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息，即使其操作系统和浏览器不同。

优点：通用公开、兼容性强、可扩展、安全性高，但XML编码格式占用带宽大

基于TCP/IP自定义的协议

有些特殊框架（如：redis、kafka、rocketMQ等）根据自身需要未严格遵循MQ规范，而是基于TCP/IP自行封装了一套二进制编解码协议，通过网络socket接口进行传输，实现了MQ的标准规范相关功能。

消息中间件推和拉模式对比

Push推模式：服务端除了负责消息存储、处理请求，还需要保存推送状态、保存订阅关系、消费者负载均衡；推模式的实时性更好；如果push能力大于消费能力，可能导致消费者崩溃或大量消息丢失

Push模式的主要优点是：

1. 对用户要求低，方便用户获取需要的信息

2. 及时性好，服务器端即时地向客户端推送更行的动态信息

Push模式的主要缺点是：

1. 推送的信息可能并不能满足客户端的个性化需求

2. Push消息大于消费者消费速率额，需要有协调QoS机制做到消费端反馈

Pull拉模式：客户端除了消费消息，还要保存消息偏移量offset，以及异常情况下的消息暂存和recover；不能及时获取消息，数据量大时容易引起broker消息堆积。

Pull拉模式的主要优点是：

1. 针对性强，能满足客户端的个性化需求

2. 客户端按需获取，服务器端只是被动接收查询，对客户端的查询请求做出响应

Pull拉模式主要的缺点是：

1. 实时较差，针对于服务器端实时更新的信息，客户端难以获取实时信息

2. 对于客户端用户的要求较高，需要维护位点

相关资料

建议学习以下的技术文档，了解更多详细的技术细节和实现原理，加深对消息中间件的理解和应用，同时可以下载开源的源代码，本地调试相应的代码，加深对技术原理的理解和概念的掌握，以及在实际生产中更多的掌握不同的消息队列应用的场景下，高效和正确地使用消息中间件。

RocketMQ资料： github.com/apache/rock…

Kafka资料： kafka.apache.org/documentati…

阿里云RocketMQ文档： help.aliyun.com/document_de…

作者：阿里巴巴淘系技术
来源：https://juejin.cn/post/7025955365812437028

有网友提问：各种机器学习算法的应用场景分别是什么（比如朴素贝叶斯、决策树、K 近邻、SVM、逻辑回归最大熵模型）？

这些在一般工作中分别用到的频率多大？一般用途是什么？需要注意什么？

根据问题，核心关键词是基础算法和应用场景，比较担忧的点是这些基础算法能否学有所用？毕竟，上述算法是大家一上来就接触的，书架上可能还放着几本充满情怀的《数据挖掘导论》《模式分类》等经典书籍，但又对在深度学习时代基础算法是否有立足之地抱有担忧。

网上已经有很多内容解答了经典算法的基本思路和理论上的应用场景，这些场景更像是模型的适用范围，这与工业界算法实际落地中的场景其实有很大区别。

从工业界的角度看，业务价值才是衡量算法优劣的金钥匙，而业务场景往往包含业务目标、约束条件和实现成本。如果我们只看目标，那么前沿的算法往往占据主导，可如果我们需兼顾算法运行复杂度、快速迭代试错、各种强加的业务限制等，经典算法往往更好用，因而就占据了一席之地。

针对这个问题，淘系技术算法工程师感知同学写出本文详细解答。

在实际业务价值中，算法模型的影响面大致是10%

在工业界，算法从想法到落地，你不是一个人在战斗。我以推荐算法为例，假设我们现在接到的任务是支持某频道页feeds流的推荐。我们首先应该意识到对业务来说，模型的影响面大致是10%，其他几个重要影响因子是产品设计（40%）、数据（30%）、领域知识的表示和建模（20%）。

这意味着，你把普通的LR模型升级成深度模型，即使提升20%，可能对业务的贡献大致只有2%。当然，2%也不少，只是这个折扣打的让人脑壳疼。

当然，上面的比例划分并不是一成不变的，在阿里推荐算法元年也就是2015年起，个性化推荐往往对标运营规则，你要是不提升个20%都不好意思跟人打招呼。那么一个算法工程师的日常除了接需求，就是做优化：业务给我输入日志、特征和优化目标，剩下的事情就交给我吭哧吭哧。

可随着一年年的水涨船高，大家所用模型自然也越来越复杂，从LR->FTRL->WDL->DeepFM->MMOE，大家也都沿着前辈们躺过的路径一步步走下去。这时候你要是问谁还在用LR或是普通的决策树，那确实会得到一个尴尬的笑容。

但渐渐的，大家也意识到了，模型优化终究是一个边际收益递减的事情。当我们把业务方屏蔽在外面而只在一个密闭空间中优化，天花板就已经注定。于是渐渐的，淘系的推荐慢慢进入第二阶段，算法和业务共建阶段。业务需求和算法优化虽然还是分开走，但已经开始有融合的地方。

集团对算法工程师的要求也在改变：一个高大上的深度模型，如果不能说清楚业务价值，或带来特别明显提升，那么只能认为是自嗨式的闭门造车。这时，一个优秀的算法工程师，需要熟悉业务，通过和业务反复交流中，能够弄清楚业务痛点。

注意，业务方甚至可能当局者迷，会提出既要又要还要的需求给你，而你需要真正聚焦到那个最值得做的问题上。然后，才是对问题的算法描述。做到这一步你会发现，并不是你来定哪个模型牛逼，而是跟着问题走来选择模型。这个模型的第一版极大可能是一个经典算法，因为，你要尽快跑通链路，快速验证你的这个idea是有效的。后面的模型迭代提升，只是时间问题。

经典算法在淘系的应用场景示例：TF-IDF、K近邻、朴素贝叶斯、逻辑回归等

因而现阶段，在淘系的大多数场景中，并不是算法来驱动业务，而是配合业务一起来完成增长。一个只懂技术的算法工程师，最多只能拿到那10%的满分。为了让大家有体感，这里再举几个小例子：

比如业务问题是对用户进行人群打标，人群包括钓鱼控、豆蔻少女、耳机发烧友、男神style等。在实操中我们不仅需考虑用户年龄、性别、购买力等属性，还需考虑用户在淘系的长期行为，从而得到一个多分类任务。如果模型所用的的特征是按月访问频次，那么豆蔻少女很可能网罗非常多的用户，因为女装是淘系行为频次最多的类目。

比如，某用户对耳机发烧友和豆蔻少女一个月内都有4次访问，假设耳机发烧友人均访问次数是3.2次，而豆蔻少女是4.8次，那么可知该用户对耳机发烧友的偏好分应更高。因此，模型特征不仅应该使用用户对该人群的绝对行为频次，还需参照大盘的水位给出相对行为频次。

这时，入选吴军老师《数学之美》的TF-IDF算法就派上用场了。通过引入TF-IDF构建特征，可以显著提高人群标签的模型效果，而TF-IDF则是非常基础的文本分类算法。

在淘系推荐场景，提升feeds流的点击率或转化率往往是一个常见场景。可业务总会给你惊喜：比如商品的库存只有一件（阿里拍卖），比如推荐的商品大多是新品（天猫新品），比如通过小样来吸引用户复购正品，这些用户大多是第一次来（天猫U先），或者是在提升效率的同时还需兼顾类目丰富度（很多场景）。

在上述不同业务约束背景，才是我们真实面对的应用场景。面对这种情况首先是定方向，比如在阿里拍卖中的问题可描述为“如何在浅库存约束下进行个性化推荐”。假如你判断这是一个流量调控问题，就需要列出优化目标和约束条件，并调研如何用拉格朗日乘子法求解。重要的是，最终的结果还需要和个性化推荐系统结合。详见：阿里拍卖全链路导购策略首次揭秘。

面对上述应用场景，你需明白你的战略目标是证明浅库存约束下的推荐是一个流量调控问题，并可以快速验证拿到效果。采用一个成熟经典的方法先快速落地实验，后续再逐步迭代是明智的选择。

又比如，K近邻算法似乎能简单到能用一张图或一句话来描述。可它在解决正负样本不均衡问题中就能派上用场。上采样是说通过将少数类（往往是正样本）的数据复制多份，但上采样后存在重复数据集可能会导致过拟合。过拟合的一种原因是在局部范围正负样本比例存在差异，如下图所示：

我们只需对C类局部样本进行上采样，这其中就运用到了K近邻算法。本例中的经典算法虽然只是链路的一部分，甚至只是配角儿，但离了它不行。

朴素贝叶斯虽然简单了点，但贝叶斯理论往后的发展，包括贝叶斯网络、因果图就不那么simple了。比如不论是金融业务中的LR评分卡模型，或是推荐算法精排中的深度模型，交叉特征往往由人工经验配置，这甚至是算法最不自动的一个环节。

使用贝叶斯网络中的structure learning，并结合业务输入的行业知识，构建出贝叶斯概率图，并从中发现相关特征做交叉，会比人工配置带来一定提升，也具有更好的可解释性。这就是把业务领域知识和算法模型结合的一个很好的例子。可如果贝叶斯理论不扎实，很难走到这一步。

不论深度学习怎么火，LR都是大多场景的一个backup。比如在双十一大促投放场景中，如果在0:00~0:30这样的峰值期，所有场景都走深度模型，机器资源肯定不足，这时候就需要做好一个使用LR或FTRL的降级预案。

如何成为业界优秀的算法工程师？

在淘系，算法并不是孤立的存在，算法工程师也不只是一个闭关的剑客。怎么切中业务痛点，快速验证你的idea，怎么进行合适的算法选型，这要求你有很好的算法基本功，以及较广的算法视野。一个模型无论搞的多复杂最终的回答都是业务价值，一个有良好基本功、具备快速学习能力，且善于发掘业务价值的算法工程师，将有很大成长空间。

好吧，假设上面就是我们的职业目标，可怎么实现呢。元(ye)芳(jie)，你怎么看？其实只有一个句话，理论和实践相结合。

理论

对算法基本思路的了解，查查知乎你可能只需要20分钟，可你忘记它可能也只需要2周。这里的理论是你从内而外对这个算法的感悟，比如说到决策树，你脑海里好像就能模拟出它的信息增益计算、特征选择、节点分裂的过程，知道它的优和劣。最终，都是为了在实践中能快速识别出它就是最适合解决当前问题的模型。

基本功弄扎实是一个慢活儿，方法上可以是看经典原著、学习视频分享或是用高级语言实现。重要的是心态，能平心静气，不设预期，保持热情；另外，如果你有个可以分享的兴趣小组，那么恭喜你。因为学习书籍或看paper的过程其实挺枯燥的，但如果有分享的动力你可以走的更远。

实践

都知道实践出真知，可实践往往也很残酷。因为需求和约束多如牛毛，问题需要你来发现，留给你的时间窗口又很短暂。也就是，算法是一个偏确定性、有适用边界、标准化的事情；而业务则是发散的、多目标的、经验驱动的事情。

你首先是需要有双发现的眼睛，找到那个最值得发力的点，这个需要数据分析配合业务经验，剥丝抽茧留下最主要的优化目标、约束条件，尽量的简化问题；其次是有一张能说会道的嘴，要不然业务怎么愿意给你这个时间窗口让你尝试呢；最后是，在赌上你的人设之后，需要尽快在这个窗口期做出效果，在这个压力之下，考验你算法基本功的时候就到了。

结语

最后，让大家猜个谜语：它是一个贪心的家伙，计算复杂度不大，可以动态的做特征选择，不论特征是离散还是连续；它还可以先剪枝或后剪枝避免过拟合；它融合了信息熵的计算，也可以不讲道理的引入随机因子；它可以孤立的存在，也完全可以做集成学习，还可以配合LR一起来解决特征组合的问题；对小样本、正负样本不均、在线数据流的学习也可以支持；所得到则是有很强可解释性的规则。它，就是决策树。

每一个基础算法，都好比是颗带有智慧的种子，这不是普通的锦上添花，而是石破天惊的原创思维。有时不妨傻傻的回到过去的年代，伴着大师原创的步伐走一走，这种原创的智慧对未来长期的算法之路，大有裨益。神经网络从种下到开花，将近50年；贝叶斯也正在开花结果的路上。下一个，将会是谁呢？

作者：阿里巴巴淘系技术
来源：https://juejin.cn/post/7025964095530598436

写在前

问题描述

有N件物品和一个最多能被重量为W 的背包。一个物品只有两个属性：重量和价值。第i件物品的重量是weight[i]，得到的价值是value[i] 。每件物品只能用一次，求解将哪些物品装入背包里物品价值总和最大。

注意：0-1 背包问题无法使用贪心算法来求解，也就是说不能按照先添加性价比最高的物品来达到最优，这是因为这种方式可能造成背包空间的浪费，从而无法达到最优。

基本思路

这里有两个可变量体积和价值，我们定义dp[i][j]表示前i件物品体积不超过j能达到的最大价值，设第 i 件物品体积为 w，价值为 v，根据第 i 件物品是否添加到背包中，可以分两种情况讨论：

• 第 i 件物品没添加到背包，最大价值：dp[i][j] = dp[i - 1][j]。

• 第 i 件物品添加到背包中：dp[i][j] = dp[i - 1][j - w] + v。

第 i 件物品可添加也可以不添加，取决于哪种情况下最大价值更大。因此，0-1 背包的状态转移方程为： dp[i][j] = max(dp[i - 1][j], dp[i - 1][j - w] + v)

代码实现

// W 为背包总重量
// N 为物品数量
// weights 数组存储 N 个物品的重量
// values 数组存储 N 个物品的价值
public int knapsack(int W, int N, int[] weights, int[] values) {
    // dp[i][0]和dp[0][j]没有价值已经初始化0
    int[][] dp = new int[N + 1][W + 1];
    // 从dp[1][1]开始遍历填表
    for (int i = 1; i <= N; ++i) {
        // 第i件物品的重量和价值 
        int w = weights[i - 1], v = values[i - 1];
        for (int j = 1; j <= W; ++j) {
            if (j < w) {
                // 超过当前状态能装下的重量j
                dp[i][j] = dp[i - 1][j];
            } else {
                dp[i][j] = Math.max(dp[i - 1][j], dp[i - 1][j - weights[i]] + values[i]);
            }
        }
    }
    return dp[N][W];
}

dp[i][j]的值只与dp[i-1][0,...,j-1]有关，所以我们可以采用动态规划常用的方法（滚动数组）对空间进行优化（即去掉dp的第一维）。因此，0-1 背包的状态转移方程为： dp[j] = max(dp[j], dp[j - w] + v)

特别注意：为了防止上一层循环的dp[0,...,j-1]被覆盖，循环的时候 j 只能逆向遍历。优化空间复杂度：

ps:滚动数组：即让数组滚动起来，每次都使用固定的几个存储空间，来达到压缩，节省存储空间的作用。

public int knapsack(int W, int N, int[] weights, int[] values) {
    int[] dp = new int[W + 1];
    for (int i = 1; i <= N; i++) {
        int w = weights[i - 1], v = values[i - 1];
        for (int j = W; j >= 1; --j) {
            if (j >= w) {
                dp[j] = Math.max(dp[j], dp[j - w] + v);
            }
        }
    }
    return dp[W];
}

ps：01背包内循环理解：还原成二维的dp就很好理解，一维的dp是二维dp在空间上进行复用的结果。dp[i]=f(dp[i-num])，等式的右边其实是二维dp上一行的数据，应该是只读的，在被读取前不应该被修改。如果正序的话，靠后的元素在读取前右边的dp有可能被修改了，倒序可以避免读取前被修改的问题。

作者：_code_x
来源：https://www.jianshu.com/p/b789ec845641

低代码又火了。

近几年，腾讯、阿里、百度等互联网大厂纷纷入局，国内外低代码平台融资动辄数千万甚至数亿，以及伴随着热度而来的巨大争议……无不说明“低代码”的火爆。

事实上，低代码并非新概念，它可以追溯到上世纪80年代的“第四代编程语言”。2014年，Forrester正式提出低代码的概念。低代码是一种软件开发技术，衍生于软件开发的高级语言，让使用者通过可视化的方式，以更少的编码，更快速地构建和交付应用软件，全方位降低软件的开发成本。与传统软件开发方式相比，低代码开发平台整合了软件开发和部署所需的 IDE（集成开发环境）、服务器和数据库管理工具，覆盖软件开发的全生命周期，我们可以将其理解为 Visual Studio + IIS + SQL Management Studio（.NET 技 术）或 Eclipse + Tomcat + MySQL Workbench（Java 技术）的组合。

编码更少、交付更快、成本更低，还覆盖软件开发全生命周期，怎么看低代码都可以说是不错的软件开发工具。那么，它又为什么引发争议，甚至被其主要用户群体之一——程序员所诟病呢？“低代码开发会取代程序员” 这一观点大行其是，它说得对吗？

为什么低代码引起专业开发者的反感？

技术浪潮引发巨大变革，也带来了无数“取代论”，比如机器翻译是否取代人类翻译、机器人记者是否取代人类记者，以及低代码开发是否取代程序员。

低代码虽然火爆，但程序员对此抱有不同的心态：

• 轻视：低代码技术的诸多优势只是炒作，该技术更适合初学者，解决不了复杂的技术问题；

• 恐惧：担心被低代码取代；

• 抵触：低代码开发平台能够覆盖所有需求吗；大量封装组件使得低代码开发平台更像一个黑盒子，可能导致难以debug、难以修改和迭代升级等技术问题；低代码开发平台配置有大量组件，简单的拖拉拽动作即可完成大量开发工作，程序员不再需要厉害的技术能力。

那么，上述理由真的站得住脚吗？我们一一来看。

低代码的门槛真的低吗？

低代码开发过程常被比作拼积木：像拼搭积木一样，以可视化的方式，通过拖拉拽组件快速开发出数据填报、流程审批等应用程序，满足企业里比较简单的办公需求。

但这并不意味着低代码开发平台只能做到这些。

Gartner在2020年9月发布的《企业级低代码开发平台的关键能力报告》（Critical Capabilities for Enterprise Low-Code Application Platforms）中，列举了低代码的11项关键能力。

图源：http://www.gartner.com/en/document…

这里我们着重来看其中三项关键能力。

• 数据建模和管理：该指标就是通常所讲的 “模型驱动” 。相比于表单驱动，模型驱动能够提供满足数据库设计范式的数据模型设计和管理能力。开发的应用复杂度越高，系统集成的要求越高，这个能力就越关键。

• 流程和业务逻辑：流程应用与业务逻辑开发能力和效率。这个能力有两层，第一层是指使用该低代码开发平台能否开发出复杂的工作流和业务处理逻辑；第二层是开发这些功能时的便利性和易用性程度有多高。

• 接口和集成：编程接口与系统集成能力。为了避免“数据孤岛”现象，企业级应用通常需要与其他系统进行集成，协同增效。此时，内置的集成能力和编程接口就变得至关重要。除非确认可预期的未来中，项目不涉及系统集成和扩展开发，开发者都应该关注这个能力。

这些关键能力表明低代码平台在建模与逻辑方面具备较强的能力，而接口和集成能力可使专业开发人员完成低代码无法实现的部分，通过低代码与专业代码开发的协作实现复杂应用的开发。 在涉及高价值或复杂的核心业务时，专业开发人员需要理解业务需求，厘清业务逻辑。从这个层面上看，低代码开发的门槛并不低。事实也是如此：海比研究在《2021 年中国低代码/无代码市场研究报告》中提到，截至 2020 年底，技术人员在低代码使用者中的比例超 75%，占主体地位。

低代码什么都能做吗？

程序员的工作围绕开发需求展开。在选择开发工具时，程序员通常考虑的首要问题是：这款工具能否覆盖所有需求？如果需求增加或变更，该工具是否支持相关操作？这些问题同样适用于低代码平台的选型。

在实际项目交付过程中，如果我们仅可以满足99%的需求，另外1%的需求满足不了，那么真实用户大概率是不会买单的。因此，在评估低代码产品的时候，我们一定要保证该平台可以支撑所有系统模块类型的开发，同时也要具备足够的扩展性，确保使用纯代码开发出的模块能够与低代码模块进行无缝集成，而这离不开编程接口。

以国内主流低代码开发平台活字格为例。该平台提供开箱即用的开发组件，同时为系统的各个分层均提供编程扩展能力，以满足企业级应用开发对扩展性的高要求。借助分层编程接口，开发者可以用纯代码的方式实现新增功能，无需受限于低代码开发平台的版本和现有功能。

活字格的编程扩展能力

当然，就具体应用领域而言，低代码开发平台也有其擅长和不擅长的地方。目前，低代码开发更多地被应用于2B企业应用开发，而对于用户量特大的头部互联网应用、对算法和复杂数据结构要求较高的应用，低代码平台则不太适合。

低代码开发不可控？

“低代码开发平台是个黑盒子，内部出问题无法排查和解决。开发过程中发现有问题怎么办？迭代升级难以实现怎么办？”很多程序员会有这种疑惑。

但我们需要注意的是，低代码开发平台本质上仍是软件开发工具，用户模型与软件开发周期支持是其关键能力之一。也就是说，成熟的低代码开发平台具备软件开发全生命周期所需的各项功能，从而大大简化开发者的技术栈，进一步提高开发效率。

具体而言，在面对频繁的需求变更、棘手的问题排查时，低代码开发平台引入了版本管理机制，从而更高效地进行代码审查、版本管理与协调，以及软件的迭代升级。至于debug，日志分析无疑是个好办法。例如，活字格把执行过程及细节以日志方式输出，方便程序员高效debug。

对程序员而言，低代码平台是限制还是助力？

“低代码”意味着更少的代码。代码都不怎么写了，程序员又该怎么成长，怎么获得职业成就感呢？

其实不然。

首先，开发 ≠ 写代码。低代码平台可以减少大量重复工作，提升开发效率，把专业开发人员从简单、重复的开发需求中解放出来，把精力投入到更有价值的事情上，比如精进技术、理清业务逻辑。

其次，低代码平台的组件化和拖拽式配置降低了开发门槛，新手程序员能够借助此类平台快速入门，加速升级打怪；有经验的程序员也有机会参与更多项目，甚至带团队，积累更多经验值，实现快速成长。

宁波聚轩就是一个例子。这家公司自2009年起就专注于智能制造、工业4.0、系统方案集成等领域的探索研究。在接触了低代码之后，项目负责人发现开发效率得到极大提升，采用传统方式需要一个月开发量的项目，现在需要半个月甚至更短的时间就可以完成。此外，其实践经验表明，低代码开发的学习成本较低，毕业新生经过一周学习，两周就可做项目，一个月就能熟练开发。

该公司在2021企业级低代码应用大赛中获得了应用创新奖，获奖作品是一套轴承行业数字化智造系统。这套系统主要集成了ERP、MES、WMS和设备机联网系统，覆盖了销售、采购、仓库、计划、生产、财务等全流程功能，且已经在生产现场投入使用。在开发过程中，宁波聚轩的开发团队利用低代码平台成功解决了定制化要求高、多终端需求等难题，及时完成项目交付。

结语

当迷雾散尽，低代码开发平台重新露出高效率开发工具的本色时，你会选择它吗？

作者：SegmentFault思否
来源：https://juejin.cn/post/7023579572096466974

Java虚拟机主要负责自动内存管理、类加载与执行、主要包括执行引擎、垃圾回收器、PC寄存器、方法区、堆区、直接内存、Java虚拟机栈、本地方法栈、及类加载子系统几个部分，其中方法区与Java堆区由所有线程共享、Java虚拟机栈、本地方法栈、PC寄存器线程私有，宏观的结构如下图所示：

JVM结构图

类加载子系统

从文件或网络中加载Class信息，类信息存放于方法区，类的加载包括加载->验证->准备->解析->初始化->使用->卸载几个阶段，详细流程后续文章会介绍。

• 加载

从文件或网络中读取类的二进制数据、将字节流表示的静态存储结构转换为方法区运行时数据结构、并于堆中生成Java对象实例，类加载器既可以使用系统提供的加载器（默认），也可以自定义类加载器。

• 连接

连接分为验证、准备、解析3个阶段，验证阶段确保类加载的正确性、准备阶段为类的静态变量分配内存，并将其初始化为默认值、解析阶段将类中的符号引用转换为直接引用

• 初始化

初始化阶段负责类的初始化，Java中类变量初始化的方式有2种，声明类变量时指定初始值、静态代码块指定初始化，只有类被主动使用时才会触发类的初始化，类的初始化会先初始化父类，然后再初始化子类。

• 使用

类访问方法区内的数据结构的接口，对象是堆区的数据

• 卸载

程序执行了System.exit()、程序正常执行结束、JVM进程异常终止等

运行时数据区域

程序从静态的源代码到编译成为JVM执行引擎可执行的字节码，会经历类的加载过程，并于内存空间开辟逻辑上的运行时数据区域，便于JVM管理，其中各数据区域如下，其中垃圾回收JVM会自动自行管理

栈帧数据结构

Java中方法的执行在虚拟机栈中执行，为每个线程所私有，每次方法的调用和返回对应栈帧的压栈和出栈，其中栈帧中保存着局部变量表、方法返回地址、操作数栈及动态链接信息。

动态链接

Java中方法执行过程中，栈帧保存方法的符号引用，通过动态链接，将解析为符号引用。

内存管理

• 内存划分（逻辑上）

Java内存区域从逻辑上分为堆区和非堆区，Java8以前，非堆区又称为永久区，Java8以后统一为原数据区，堆区按照分代模型分为新生代和老年代，其中新生代分为Eden、so、s1，so和s1是大小相同的2块区域，生产环境可以根据具体的场景调整虚拟机内存分配比例参数，达到性能调优的效果。

堆区是JVM管理的最大内存区域，由所有线程共享，采用分代模型，堆区主要用于存放对象实例，堆可以是物理上不连续的空间，逻辑上连续即可，其中堆内存大小可以通过虚拟机参数-Xmx、-Xms指定，当堆无法继续扩展时，将抛出OOM异常。

• 运行时实例

假设存在如下的SimpleHeap测试类，则SimpleHeap在内存中的堆区、Java栈、方法区对应的映射关系如下图所示：

public class SimpleHeap {
    /**
     * 实例变量
     */
    private int id;

    /**
     * 构造器
     *
     * @param id
     */
    public SimpleHeap(int id) {
        this.id = id;
    }

    /**
     * 实例方法
     */
    private void displayId() {
        System.out.println("id:" + id);
    }

    public static void main(String[]args){
        SimpleHeap heap1=new SimpleHeap(1);
        SimpleHeap heap2=new SimpleHeap(2);
        heap1.displayId();
        heap2.displayId();
    }

}
复制代码

同理，建设存在Person类，则创建对象实例后，内存中堆区、Java方法栈、方法区三者关系如下图：

直接内存

Java NIO库允许Java程序使用直接内存，直接内存是独立于Java堆区的一块内存区域，访问内存的速度优于堆区，出于性能考虑，针对读写频繁的场景，可以直接操作直接内存，它的大小不受Xmx参数的限制，但堆区内存和直接内存总和必须小于系统内存。

PC寄存器

线程私有空间，又称之为程序计数器，任意时刻，Java线程总在执行一个方法，正在执行的方法，我们称之为："当前方法”,如果当前方法不是本地方法，则PC寄存器指向当前正在被执行的指令；若当前方法是本地方法，则PC寄存器的值是undefined。

垃圾回收系统

垃圾回收系统是Java虚拟机中的重要组成部分，其主要对方法区、堆区、直接内存空间进行回收，与C/C++不同，Java中所有对象的空间回收是隐式进行的，其中垃圾回收会根据GC算法自动完成内存管理。

作者：洞幺幺洞
来源：https://juejin.cn/post/7040742081236566029

本周最热的事件莫过于 Log4j 漏洞，攻击者仅需向目标输入一段代码，不需要用户执行任何多余操作即可触发该漏洞，使攻击者可以远程控制用户受害者服务器，90% 以上基于 java 开发的应用平台都会受到影响。通过本文特推项目 2 你也能近距离感受这个漏洞的“魅力”，而特推 1 则是一个漏洞检测工具，能预防类似漏洞的发生。

除了安全相关的 2 个特推项目之外，本周 GitHub 热门项目还有高性能的 Rust 运行时项目，在你不知道用何词时给你参考词的反向词典 WantWords，还有可玩性贼高的终端模拟器 Tabby。

以下内容摘录自微博@HelloGitHub 的 GitHub Trending 及 Hacker News 热帖（简称 HN 热帖），选项标准：新发布 | 实用 | 有趣，根据项目 release 时间分类，发布时间不超过 14 day 的项目会标注 New，无该标志则说明项目 release 超过半月。由于本文篇幅有限，还有部分项目未能在本文展示，望周知 🌝

• 本文目录

  • 1. 本周特推

    • 1.1 JNDI 注入测试工具：JNDI-Injection-Exploit

    • 1.2 Apache Log4j 远程代码执行：CVE-2021-44228-Apache-Log4j-Rce

  • 1. GitHub Trending 周榜

    • 2.1 塞尔达传说·时之笛反编译：oot

    • 2.2 终端模拟器：Tabby

    • 2.3 反向词典：WantWords

    • 2.4 CPU 性能分析和调优：perf-book

    • 2.5 高性能 Rust Runtime：Monoio

  • 1. 往期回顾

1. 本周特推

1.1 JNDI 注入测试工具：JNDI-Injection-Exploit

本周 star 增长数： 200+

JNDI-Injection-Exploit 并非是一个新项目，它是一个可用于 Fastjson、Jackson 等相关漏洞的验证的工具，作为 JNDI 注入利用工具，它能生成 JNDI 链接并启动后端相关服务进而检测系统。

GitHub 地址→github.com/welk1n/JNDI…

1.2 Apache Log4j 远程代码执行：CVE-2021-44228-Apache-Log4j-Rce

本周 star 增长数： 1,500+

New CVE-2021-44228-Apache-Log4j-Rce 是 Apache Log4j 远程代码执行，受影响的版本 < 2.15.0。项目开源 1 天便标星 1.5k+ 可见本次 Log4j 漏洞受关注程度。

GitHub 地址→github.com/tangxiaofen…

2. GitHub Trending 周榜

2.1 塞尔达传说·时之笛反编译：oot

本周 star 增长数：900+

oot 是一个反编译游戏塞尔达传说·时之笛的项目，目前项目处于半成品状态，会有较大的代码变更，项目从 scratch 中重新构建代码，并用游戏中发现的信息以及静态、动态分析。如果你想通过这个项目了解反编译知识，建议先保存好个人的塞尔代资产。

GitHub 地址→github.com/zeldaret/oo…

2.2 终端模拟器：Tabby

本周 star 增长数：1,800+

Tabby（曾叫 Terminus）是一个可配置、自定义程度高的终端模拟器、SSH 和串行客户端，适用于 Windows、macOS 和 Linux。它是一种替代 Windows 标准终端 conhost、PowerShell ISE、PuTTY、macOS terminal 的存在，但它不是新的 shell 也不是 MinGW 和 Cygwin 的替代品。此外，它并非一个轻量级工具，如果你注重内存，可以考虑 Conemu 或 Alacritty。

GitHub 地址→github.com/Eugeny/tabb…

2.3 反向词典：WantWords

本周 star 增长数：1,000+

WantWords 是清华大学计算机系自然语言处理实验室（THUNLP）开源的反向字词查询工具，反向词典并非是查询反义词的词典，而是基于目前网络词官广泛使用导致部分场景下，我们表达某个意思未能找到精准的用词，所以它可以让你通过想要表达的意思来找寻符合语境的词汇。你可以在线体验反向词典：wantwords.thunlp.org/ 。下图分别为项目 workflow 以及查询结果。

GitHub 地址→github.com/thunlp/Want…

2.4 CPU 性能分析和调优：perf-book

本周 star 增长数：1,300+

perf-book 是书籍《现代 CPU 的性能分析和调优》开源版本，你可以通过 python.exe export_book.py && pdflatex book.tex && bibtex book && pdflatex book.tex && pdflatex book.tex 命令导出 pdf。

GitHub 地址→github.com/dendibakh/p…

2.5 高性能 Rust Runtime：Monoio

本周 star 增长数：1,250+

New Monoio 是字节开源基于 io-uring 的 thread-per-core 模型高性能 Rust Runtime，旨在为高性能网络中间件等场景提供必要的运行时。详细项目背景可以阅读团队的文章Monoio：基于 io-uring 的高性能 Rust Runtime。

GitHub 地址→github.com/bytedance/m…

3. 往期回顾

• 年底巩固下 CS 知识「GitHub 热点速览 v.21.49」

• 图片处理看这篇就完了「GitHub 热点速览 v.21.48」

以上为 2021 年第 50 个工作周的 GitHub Trending 🎉如果你 Pick 其他好玩、实用的 GitHub 项目，记得来 HelloGitHub issue 区和我们分享下哟 🌝

最后，记得你在本文留言区留下你想看的主题 Repo（限公众号），例如：AI 换头。👀 和之前的送书活动类似，留言点赞 Top5 的小伙伴(棒），小鱼干会努力去找 Repo 的^^

作者：HelloGitHub
来源：https://juejin.cn/post/7040980646423953439

需求

分布式应⽤进⾏逻辑处理时经常会遇到并发问题。

互斥访问某个网络上的资源，需要有一个存在于网络上的锁服务器，负责锁的申请与回收。Redis 可以充当锁服务器的角色。首先，Redis 是单进程单线程的工作模式，所有前来申请锁资源的请求都被排队处理，能保证锁资源的同步访问。

适用原因：

• Redis 可以被多个客户端共享访问，是·共享存储系统，可以用来保存分布 式锁

• Redis 的读写性能高，可以应对高并发的锁操作场景。

实现

在分布式场景下，锁变量需要由一个共享存储系统来维护，这样，多个客户端可以通过访问共享存储系统来访问锁变量。

简单实现

模仿单机上的锁，使用锁变量即可在Redis上实现分布式锁。

我们可以在 Redis 服务器设置一个键值对，用以表示一把互斥锁，当申请锁的时候，要求申请方设置（SET）这个键值对，当释放锁的时候，要求释放方删除（DEL）这个键值对。

但最基本需要保证加锁解锁操作的原子性。同时为了保证锁在异常情况下能被释放，必须设置超时时间。

Redis 2.8 版本中作者加⼊了 set 指令的扩展参数，使得 setnx 和 expire 指令可以⼀起执⾏

加锁原子操作

加锁包含了三个操作（读取锁变量、判断锁变量值以及把锁变量值设置为 1），而这 三个操作在执行时需要保证原子性。

首先是 SETNX 命令，它用于设置键值对的值。具体来说，就是这个命令在执行时会判断键 值对是否存在，如果不存在，就设置键值对的值，如果存在，就不做任何设置。

超时问题

Redis 的分布式锁不能解决超时问题，如果在加锁和释放锁之间的逻 辑执⾏的太长，超出了锁的超时限制，就无法保证互斥。

解决方案

最简单的就是避免Redis 分布式锁⽤于较⻓时间的任务。如果真的偶尔出现了，数据出现的⼩波错乱可能需要⼈⼯介⼊解决。

判断拥有者

为了防止锁变量被拥有者之外的客户端进程删除，需要能区分来自不同客户端的锁操作

set 指令的 value 参数设置为⼀个 随机数，释放锁时先匹配随机数是否⼀致，然后再删除 key，这是为 了确保当前线程占有的锁不会被其它线程释放，除⾮这个锁是过期了被服务器⾃动释放的。

Redis 给 SET 命令提供 了类似的选项 NX，用来实现“不存在即设置”。如果使用了 NX 选项，SET 命令只有在键 值对不存在时，才会进行设置，否则不做赋值操作。此外，SET 命令在执行时还可以带上 EX 或 PX 选项，用来设置键值对的过期时间。

可重入问题

可重⼊性是指线程在持有锁的情况下再次请求加锁，如果⼀个锁⽀持 同⼀个线程的多次加锁，那么这个锁就是可重⼊的。Redis 分布式锁如果要⽀持 可重⼊，需要对客户端的 set ⽅法进⾏包装，使⽤线程的 Threadlocal 变量存储当前持有锁的计数。

分布式拓展

单Redis实例并不能满足我们的高可用要求，一旦实例崩溃，就无法对外分布式锁服务。

但在集群环境下，这种只对主Redis实例使用上述方案是有缺陷 的，它不是绝对安全的。

一旦主节点挂掉，但锁变量没有及时同步，就会导致互斥被破坏。

Redlock

为了解决这个问题，Antirez 发明了 Redlock 算法

Redlock 算法的基本思路，是让客户端和多个独立的 Redis 实例依次请求加锁，如果客户 端能够和半数以上的实例成功地完成加锁操作，那么我们就认为，客户端成功地获得分布 式锁了，否则加锁失败。

执行步骤：

• 获取当前时间

• 客户端按顺序依次向 N 个 Redis 实例执行加锁操作

• 一旦客户端完成了和所有 Redis 实例的加锁操作，客户端就要计算整个加锁过 程的总耗时。客户端只有在满足下面的这两个条件时，才能认为是加锁成功

  • 客户端从超过半数（大于等于 N/2+1）的 Redis 实例上成功获取到了锁；

  • 客户端获取锁的总耗时没有超过锁的有效时间。

作者：不是二向箔
来源：https://juejin.cn/post/7038155529566289957

方案：使用微信提供的url link方法 生成短链接 发送给用户 用户点击短链接会跳转到微信提供默认的默认页面 进而打开小程序
场景假设：经理人发布一条运输任务 司机收到短信点击打开小程序接单

实现：

• 经理人发布时点击发布按钮 h5调用服务端接口 传参服务端要跳转的小程序页面 所需要参数

• 服务端拿access_token和前端传的参数 加链接失效时间 调用微信api

api.weixin.qq.com/wxa/generat… 得到链接 如wxaurl.cn/ow7ctZP4n8v 将此链接发送短信给司机

• 司机点击此链接 效果如下图所示：打开小程序 h5写逻辑跳转指定页面
  

自己调postman调微信api post方式 接口： api.weixin.qq.com/wxa/generat…

传参

{ 
        "path": "pages/index/index",\
    "query": "?fromType=4&transportBulkLineId=111&isLinkUrlCome=1&SCANFROMTYPE=143&lineAssignRelId=111",\
      "env_version": "trial",\
      "is_expire": true,\
    "expire_time": "1638855772"\
}

返参

{
      "errcode": 0,
    "errmsg": "ok",
    "url_link": "https://wxaurl.cn/GAxGcil2Bbp"
}