当 前，城市数字孪生已经发展成为支撑智慧城市的重要技术手段。

全文共计3026字，预计阅读时间8分钟

来源| 全国信标委智慧城市标准工作组

编辑 | 蒲蒲

城市数字孪生通过在数字空间对城市物理空间和社会空间进行全要素表达、全过程呈现、全周期可溯，实现城市全面感知、虚实交互、智能决策、精准控制，推动城市智能化、智慧化发展。

当前，城市数字孪生已经发 展成为支撑智慧城市的重要技术手段。 为做好城市数字孪生标准化工作整体规划，有序推动相关标准制定与应用实施工作，全国信标 委智慧城市标准工作组组建了城市数字孪生专题组，并联合相关单位编制了《城市数字孪生标准化白皮书（2022版）》。

白皮书在系统研究城市数字孪生内涵、典型特征、相关方等基础上，构建了城市数字孪生技术参考架构，梳理了城市数字孪生关键技术和典型应用场景，总结了城市数字孪生发展现状、发展趋势、面临的问题与挑战及国际国内标准化现状。在此基础上，白皮书探索形成了“城市数字孪生标准体系总体框架（1.0版）”，并提出了拟研制标准建议和标准化工作建议。白皮书构建了城市数字孪生标准化路线图，为后续相关标准研制、应用实施指明了方向。

城市数字孪生典型特征

全面感知：城市数字孪生以全面感知为前提。城市是一个复杂巨系统，时刻处于发展变化中，必须时刻掌握物理城市的全局发展与精细变化，实现孪生环境下的数字城市与物理城市同步运行。

精准映射是构建数字世界并建立数字世界与物理世界紧密关系的过程。

智能推演是城市数字孪生具备智慧能力的体现，是实现对物理城市进行科学预测、指导与优化的关键。

动态可视：指通过将感知的多源数据进行数字化建模和可视化渲染，城市数字孪生提供了全要素、全范围、全精度真实的渲染效果，实现全空间信息和城市实时运行

虚实互动：指物理空间与数字空间的互操作和双向互动，借助物联网、图形/图像、AR/VR、人机交互等领域技术的协同和融合，实现城市级虚实空间融合、控制与反馈等能力。态势的动态展示。

协同演进是城市数字孪生具有高阶智慧能力的体现。城市数字孪生过程中，物理城市与数字城市在城市运行、数据、技术、机制等方面存在长期协同关系，长期相互反馈、相互影响。

多维度构建参考架构，立体刻画城市数字孪生内涵

白皮书对“城市数字孪生”概念进行了系统地梳理和分析，创新性地从概念、技术、相关方等不同视角构建了城市数字孪生参考架构。

白皮书认为，城市数字孪生是利用数字孪生技术，以数字化方式创建城市物理实体的虚拟映射，借助历史数据、实时数据、空间数据以及算法模型等，仿真、预测、交互、控制城市物理实体全生命周期过程的技术手段，可以实现城市物理空间和社会空间中物理实体对象以及关系、活动等在数字空间的多维映射和连接。

从概念视角，城市数字孪生以城市物理空间、社会空间以及数字空间在时间维度和空间维度更加精准的映射、更加紧密的联接和更加多维的联动，实现三元空间的协同演进和共生共智，满足“人”在城市生活、生产、生态的各类需求，服务“以人为本”的智慧城市建设初心。

图1 城市数字孪生概念模型

从技术视角，需对物理空间以及社会空间中的物理实体对象、事件对象以及关系对象进行数字空间的虚拟表达以及映射，通过信息基础设施的转化传输以及处理形成数据资源，在通用服务能力的支撑下进一步融合数字孪生技术形成能够对外提供的数字孪生服务，并通过交互服务实现与上层应用场景的融合。同时，需提供立体化安全管理以及全生命周期的运营管理，保障数字空间各类资产以及服务的安全高效运行。

图2 城市数字孪生技术参考架构

从相关方视角，城市数字孪生由城市数字孪生咨询服务提供方、建设技术提供方、运营服务方三方多类主体联动构建。

图3 城市数字孪生相关方

梳理发展现状，总结城市数字孪生趋势与问题

白皮书梳理了城市数字孪生国家及地方相关政策，分析了产业生态发展现状。同时，提出了城市数字孪生发展的总体发展趋势及面临的主要问题和挑战。

图4 城市数字孪生产业生态

随着各地城市数字孪生探索与落地，智慧城市建设也将进入新的发展阶段。随供需双发力，城市数字孪生的技术创新、产业发展、标准规范等将快速发展，呈现物理城市和数字城市并行共生的新发展格局。

• 城市数字孪生将成为智慧城市建设技术底座。城市数字孪生将成为智慧城市发展新阶段的核心底座，为城市构建虚实共生的数字基础设施能力。
• 城市数字孪生将在智慧城市中迎来深度应用。城市数字孪生相关产业快速发展，市场规模不断扩大，以城市大脑、城运中心、城市信息模型、城市数字孪生运营管理为主的相关领域市场迅速升温。
• 城市数字孪生将形成跨行业协作生态共融。数据融合、技术融合和业务融合推动城市数字孪生产业链上下游的多元主体在竞争中发展出共生关系，生态共融正成为行业共识。

城市数字孪生从概念培育逐步走向建设实施，各项支撑技术日渐成熟，但仍面临着供应链安全性不足、数据支撑不足、应用深度不足、产业联动不足和标准支撑不足等问题与挑战。

构建标准体系，以标准化助力高质量发展

当前，城市数字孪生标准化处于起步阶段，亟需开展标准体系顶层设计。白皮书探索构建了“城市数字孪生标准体系总体框架（1.0版）”，将城市数字孪生标准划分为“01总体”“02数据”“03技术与平台”“04安全”“05运维/运营”“06应用”六大类。

图5 城市数字孪生标准体系总体框架（1.0版）

图6 城市数字孪生标准体系结构

为充分发挥标准基础性、引领性作用，助力城市数字孪生相关产业高质量发展，白皮书建议城市数字孪生标准化工作主要从四方面开展。

• 完善工作机制，强化统筹与协同。城市数字孪生涉及技术、应用、相关方众多，是复杂的系统工程，其标准化工作开展需统筹布局、协同各方。
• 研制重点标准，完善标准体系建设。以“规划引领、需求牵引”为原则，推动重点标准研制工作，不断完善城市数字孪生标准体系。
• 挖掘优秀案例，发挥示范引领作用。建立城市数字孪生典型案例与标准的良性互动机制，充分发挥先进性、代表性案例的引领与示范作用。
• 强化国际交流，推动国际标准制定。城市数字孪生承载了一系列关键技术和核心产业，要借助国际标准带动我国产品和方案走出去。

下一步，全国信标委智慧城市标准工作组将以此白皮书为基础，与各界共同推动城市数字孪生技术、理论、标准研究与制定工作，凝共识、聚合力，助力城市数字孪生产业生态培育，推动“以人为本”的智慧城市向智能化、智慧化迈进。

具体内容如下

来源：全国信标委智慧城市标准工作组    

收起阅读 »

本文介绍策略模式的具体应用以及Map+函数式接口如何 “更完美” 的解决 if-else的问题。

需求

最近写了一个服务：根据优惠券的类型resourceType和编码resourceId来 查询 发放方式grantType和领取规则

实现方式：

1. 根据优惠券类型resourceType -> 确定查询哪个数据表

2. 根据编码resourceId -> 到对应的数据表里边查询优惠券的派发方式grantType和领取规则

优惠券有多种类型，分别对应了不同的数据库表：

• 红包 —— 红包发放规则表

• 购物券 —— 购物券表

• QQ会员

• 外卖会员

实际的优惠券远不止这些，这个需求是要我们写一个业务分派的逻辑

第一个能想到的思路就是if-else或者switch case：

switch(resourceType){

case "红包": 
查询红包的派发方式 
break;
case "购物券": 
查询购物券的派发方式
break;
case "QQ会员" :
break;
case "外卖会员" :
break;
......
default : logger.info("查找不到该优惠券类型resourceType以及对应的派发方式");
break;
}

如果要这么写的话， 一个方法的代码可就太长了，影响了可读性。（别看着上面case里面只有一句话，但实际情况是有很多行的）

而且由于 整个 if-else的代码有很多行，也不方便修改，可维护性低。

策略模式

策略模式是把 if语句里面的逻辑抽出来写成一个类，如果要修改某个逻辑的话，仅修改一个具体的实现类的逻辑即可，可维护性会好不少。

以下是策略模式的具体结构(详细可看这篇博客： 策略模式.)：

策略模式在业务逻辑分派的时候还是if-else，只是说比第一种思路的if-else 更好维护一点。。。

switch(resourceType){

case "红包": 
String grantType=new Context(new RedPaper()).ContextInterface();
break;
case "购物券": 
String grantType=new Context(new Shopping()).ContextInterface();
break;

......
default : logger.info("查找不到该优惠券类型resourceType以及对应的派发方式");
break;

但缺点也明显：

• 如果 if-else的判断情况很多，那么对应的具体策略实现类也会很多，上边的具体的策略实现类还只是2个，查询红包发放方式写在类RedPaper里边，购物券写在另一个类Shopping里边；那资源类型多个QQ会员和外卖会员，不就得再多写两个类？有点麻烦了

• 没法俯视整个分派的业务逻辑

Map+函数式接口

用上了Java8的新特性lambda表达式

• 判断条件放在key中

• 对应的业务逻辑放在value中

这样子写的好处是非常直观，能直接看到判断条件对应的业务逻辑

需求： 根据优惠券(资源)类型resourceType和编码resourceId查询派发方式grantType

上代码：

@Service
public class QueryGrantTypeService {

   @Autowired
   private GrantTypeSerive grantTypeSerive;
   private Map<String, Function<String,String>> grantTypeMap=new HashMap<>();

   /**
    * 初始化业务分派逻辑,代替了if-else部分
    * key: 优惠券类型
    * value: lambda表达式,最终会获得该优惠券的发放方式
    */
   @PostConstruct
   public void dispatcherInit(){

       grantTypeMap.put("红包",resourceId->grantTypeSerive.redPaper(resourceId));
       grantTypeMap.put("购物券",resourceId->grantTypeSerive.shopping(resourceId));
       grantTypeMap.put("qq会员",resourceId->grantTypeSerive.QQVip(resourceId));
  }

   public String getResult(String resourceType){
  
    
    
       //Controller根据 优惠券类型resourceType、编码resourceId 去查询 发放方式grantType
       Function<String,String> result=getGrantTypeMap.get(resourceType);
       if(result!=null){

      //传入resourceId 执行这段表达式获得String型的grantType
           return result.apply(resourceId);
      }
       return "查询不到该优惠券的发放方式";
  }
}

如果单个 if 语句块的业务逻辑有很多行的话，我们可以把这些 业务操作抽出来，写成一个单独的Service，即：

//具体的逻辑操作

@Service
public class GrantTypeSerive {

   public String redPaper(String resourceId){

       //红包的发放方式
       return "每周末9点发放";
  }
   public String shopping(String resourceId){

       //购物券的发放方式
       return "每周三9点发放";
  }
   public String QQVip(String resourceId){

       //qq会员的发放方式
       return "每周一0点开始秒杀";
  }
}

入参String resourceId是用来查数据库的，这里简化了，传参之后不做处理。

用http调用的结果：

@RestController
public class GrantTypeController {

   @Autowired
   private QueryGrantTypeService queryGrantTypeService;

   @PostMapping("/grantType")
   public String test(String resourceName){

       return queryGrantTypeService.getResult(resourceName);
  }
}

用Map+函数式接口也有弊端：
你的队友得会lambda表达式才行啊，他不会让他自己百度去

最后捋一捋本文讲了什么：

1. 策略模式通过接口、实现类、逻辑分派来完成，把 if语句块的逻辑抽出来写成一个类，更好维护。

2. Map+函数式接口通过Map.get(key)来代替 if-else的业务分派，能够避免策略模式带来的类增多、难以俯视整个业务逻辑的问题。

   ————————————————
   作者：zhongh Jim
   来源：https://blog.csdn.net/qq_44384533/article/details/109197926

收起阅读 »

名词解释

在DDD兴起的原因以及与微服务的关系中曾举了一个研究桃树的例子，如果要研究桃树，将桃树根据器官分成根、茎、叶、花、果实、种子，这每一种器官都可以认为是一个研究领域,而领域又有更加具体的细分,分成子域、核心域、通用域、支撑域等，下面回顾桃树这个例子

看上面这张图 ，如果研究桃树是我们的业务，那么如何更加快速有效的研究桃树呢？ 根据回忆，初中课本是这样研究的:

第一步: 确定研究的对象，即研究领域 ，这里是一棵桃树。

第二步: 根据研究对象的某些维度，对其进行进一步的拆分，例如拆分成器官，而器官又可以分成营养器官，生殖器官，其中营养器官包括根、茎、叶,生殖器官包括花、果实、种子,那么这些就是我们要研究的子域。

第三步: 现在就可以最子域进行划分了，找出核心域,通用域,支撑域,至于为什么要这么划分，后面再解释，当我们找到核心域之后，再各个子域进行深一步的划分，划分成组织，例如分成保护组织,营养组织,疏导组织，这就儿也可以理解成将领域继续划分为子域的过程。

第四步:对组织进行进一步的划分，可以分成细胞，例如根毛细胞、导管细胞等等

我们有没有必要继续拆分细胞呢？这个取决于我们研究的业务，例如在之前光学显微镜时，研究到细胞也就截止了，具体到其他业务，也是研究到某一步就不需要继续拆分，而这最小层次的领域，通常就是我们所说的实体，聚合、聚合根、实体以及值对象等内容会在后面深入了解。

下面归纳一下上面提到的几个名词的概念 :

领域： 往往就是业务的某一个部分 ， 例如电商的销售部分、物流部分、供应链部分等， 这些对于电商来说就是各个领域(模块)，领域主要作用就是用来驱动范围， DDD 会将问题范围限定在特定的边界内，在这个边界内建立领域模型，进而用代码实现该领域模型，解决相应的业务问题。简言之，DDD 的领域就是这个边界内要解决的业务问题域。

子域：相对的一个概念， 我们可以将领域进行进一步的划分 ， 这时候就是子域， 甚至可以对子域继续划分形成 子子域(依旧叫子域)，就好比当我们研究植物时，如果研究的对象是桃树，那么果实根茎叶是领域，可是如果不仅仅要研究果实，还要研究组织甚至细胞，那么研究的就是果实的子域、组织的子域。

核心域：所有领域中最关键的部分 ， 什么意思呢， 就是最核心的部分， 对于业务来说， 核心域是企业根本竞争力， 也是创造利润里最关键的部分 ， 例如电商里面那么多领域， 最重要的是什么？ 就是销售系统， 无论你是2B还是2C， 还是PDD ，这些核心模块就是核心域。

通用域:除了核心域之外， 还需要自己做的一些领域， 例如鉴权、日志等， 特点是可能被多个领域公用的部分。

支撑域:系统中业务分析阶段最不重点关注的领域， 也就是非核心域非通用域的领域， 例如电商里面的支付、物流，仅仅是为了支撑业务的运转而存在， 甚至可以去购买别人的服务， 这类的领域就是支撑域。

需要注意的是，这些名词在实际的微服务设计和开发过程中不一定用得上，但是可以帮助理解DDD的核心设计思想以及理念，而这些思想和理念在实际的IT战略设计业务建模和微服务设计上都是可以借鉴的。

为什么要划分核心域、通用域、支撑域 ？

通过上面可以知道，决定产品和公司核心竞争力的子域是核心域，它是业务成功的主要因素和公司的核心竞争力。没有太多个性化的诉求，同时被多个子域使用的通用功能子域是通用域。还有一种功能子域是必需的，但既不包含决定产品和公司核心竞争力的功能，也不包含通用功能的子域，它就是支撑域。

这三类子域相较之下，核心域是最重要的，我们下面讲目的的时候还会以核心域为例详细介绍。通用域和支撑域如果对应到企业系统，举例来说的话，通用域则是你需要用到的通用系统，比如认证、权限等等，这类应用很容易买到，没有企业特点限制，不需要做太多的定制化。而支撑域则具有企业特性，但不具有通用性，例如数据代码类的数据字典等系统。

那么为什么要划分出这些新的名词呢？ 先想一个问题,对于桃树而言，根、茎、叶、花、果实、种子六个领域哪一个是核心域？

是不是有不同的理解？ 有人说是种子，有人说是根，有人说是叶子，也有人说是茎等等，为什么会有这种情况呢？

因为每个人站的角度不一样，你如果是果农，那么果实就是核心域，你的大部分操作应该都是围绕提高果实产量进行，如果你是景区管理员，那么芳菲四月桃花盛开才是你重点关注，如果比是林场工作人员，那么树干才应该是你重点关注的领域，看到没，对于同一个领域划分的子域，每个人都有不同的理解，那么要通过讨论确定核心域，确保大家认同一致，对于实际业务开发来说，参与的人员众多，有业务方面的，有架构师，有后端开发人员，营销市场等等，势必要最开始就确定我们的核心域，除了统一大家的认识之外还有什么好处呢？

对于一个企业来说，预算以及时间是有限的，也就意味着时间以及精力甚至金钱要尽可能多的花在核心的的地方。就好比电商，电商企业那么多，每一家核心域都有所差别，造成的市场结果也千差万别,那么公司战略重点和商业模式应该找到核心域，且重点关注核心域。

总的来说，核心域、支撑域和通用域的主要目标是：通过领域划分，区分不同子域在公司内的不同功能
属性和重要性，从而公司可对不同子域采取不同的资源投入和建设策略，其关注度也会不一样。

作者：等不到的口琴
来源：https://www.cnblogs.com/Courage129/p/14853600.html

收起阅读 »

如何保证外网开放接口的安全性。

• 使用加签名方式，防止数据篡改

• 信息加密与密钥管理

• 搭建OAuth2.0认证授权

• 使用令牌方式

• 搭建网关实现黑名单和白名单

一、令牌方式搭建搭建API开放平台

方案设计：

1.第三方机构申请一个appId,通过appId去获取accessToken,每次请求获取accessToken都要把老的accessToken删掉

2.第三方机构请求数据需要加上accessToken参数，每次业务处理中心执行业务前，先去dba持久层查看accessToken是否存在(可以把accessToken放到redis中，这样有个过期时间的效果)，存在就说明这个机构是合法，无需要登录就可以请求业务数据。不存在说明这个机构是非法的，不返回业务数据。

3.好处：无状态设计，每次请求保证都是在我们持久层保存的机构的请求，如果有人盗用我们accessToken，可以重新申请一个新的taken.

二、基于OAuth2.0协议方式

原理

第三方授权，原理和1的令牌方式一样

1.假设我是服务提供者A，我有开发接口，外部机构B请求A的接口必须申请自己的appid(B机构id)

2.当B要调用A接口查某个用户信息的时候，需要对应用户授权，告诉A，我愿同意把我的信息告诉B，A生产一个授权token给B。

3.B使用token获取某个用户的信息。

联合微信登录总体处理流程

1. 用户同意授权，获取code

2. 通过code换取网页授权access_token

3. 通过access_token获取用户openId

4. 通过openId获取用户信息

三、信息加密与密钥管理

• 单向散列加密

• 对称加密

• 非对称加密

• 安全密钥管理

1.单向散列加密

散列是信息的提炼，通常其长度要比信息小得多，且为一个固定长度。加密性强的散列一定是不可逆的，这就意味着通过散列结果，无法推出任何部分的原始信息。任何输入信息的变化，哪怕仅一位，都将导致散列结果的明显变化，这称之为雪崩效应。

散列还应该是防冲突的，即找不出具有相同散列结果的两条信息。具有这些特性的散列结果就可以用于验证信息是否被修改。

单向散列函数一般用于产生消息摘要，密钥加密等，常见的有：

• MD5（Message Digest Algorithm 5）：是RSA数据安全公司开发的一种单向散列算法，非可逆，相同的明文产生相同的密文。

• SHA（Secure Hash Algorithm）：可以对任意长度的数据运算生成一个160位的数值；

SHA-1与MD5的比较

因为二者均由MD4导出，SHA-1和MD5彼此很相似。相应的，他们的强度和其他特性也是相似，但还有以下几点不同：

• 对强行供给的安全性：最显著和最重要的区别是SHA-1摘要比MD5摘要长32 位。使用强行技术，产生任何一个报文使其摘要等于给定报摘要的难度对MD5是2128数量级的操作，而对SHA-1则是2160数量级的操作。这样，SHA-1对强行攻击有更大的强度。

• 对密码分析的安全性：由于MD5的设计，易受密码分析的攻击，SHA-1显得不易受这样的攻击。

• 速度：在相同的硬件上，SHA-1的运行速度比MD5慢。

1、特征：雪崩效应、定长输出和不可逆。

2、作用是：确保数据的完整性。

3、加密算法：md5（标准密钥长度128位）、sha1（标准密钥长度160位）、md4、CRC-32

4、加密工具：md5sum、sha1sum、openssl dgst。

5、计算某个文件的hash值，例如：md5sum/shalsum FileName,openssl dgst –md5/-sha

2.对称加密

秘钥：加密解密使用同一个密钥、数据的机密性双向保证、加密效率高、适合加密于大数据大文件、加密强度不高(相对于非对称加密)

对称加密优缺点

• 优点：与公钥加密相比运算速度快。

• 缺点：不能作为身份验证，密钥发放困难

DES是一种对称加密算法,加密和解密过程中，密钥长度都必须是8的倍数

public class DES {
 public DES() {
 }
 
 // 测试
 public static void main(String args[]) throws Exception {
  // 待加密内容
  String str = "123456";
  // 密码，长度要是8的倍数 密钥随意定
  String password = "12345678";
  byte[] encrypt = encrypt(str.getBytes(), password);
  System.out.println("加密前:" +str);
  System.out.println("加密后:" + new String(encrypt));
  // 解密
  byte[] decrypt = decrypt(encrypt, password);
  System.out.println("解密后:" + new String(decrypt));
 }
 
 /**
  * 加密
  * 
  * @param datasource
  *            byte[]
  * @param password
  *            String
  * @return byte[]
  */
 public static byte[] encrypt(byte[] datasource, String password) {
  try {
   SecureRandom random = new SecureRandom();
   DESKeySpec desKey = new DESKeySpec(password.getBytes());
   // 创建一个密匙工厂，然后用它把DESKeySpec转换成
   SecretKeyFactory keyFactory = SecretKeyFactory.getInstance("DES");
   SecretKey securekey = keyFactory.generateSecret(desKey);
   // Cipher对象实际完成加密操作
   Cipher cipher = Cipher.getInstance("DES");
   // 用密匙初始化Cipher对象,ENCRYPT_MODE用于将 Cipher 初始化为加密模式的常量
   cipher.init(Cipher.ENCRYPT_MODE, securekey, random);
   // 现在，获取数据并加密
   // 正式执行加密操作
   return cipher.doFinal(datasource); // 按单部分操作加密或解密数据，或者结束一个多部分操作
  } catch (Throwable e) {
   e.printStackTrace();
  }
  return null;
 }
 
 /**
  * 解密
  * 
  * @param src
  *            byte[]
  * @param password
  *            String
  * @return byte[]
  * @throws Exception
  */
 public static byte[] decrypt(byte[] src, String password) throws Exception {
  // DES算法要求有一个可信任的随机数源
  SecureRandom random = new SecureRandom();
  // 创建一个DESKeySpec对象
  DESKeySpec desKey = new DESKeySpec(password.getBytes());
  // 创建一个密匙工厂
  SecretKeyFactory keyFactory = SecretKeyFactory.getInstance("DES");// 返回实现指定转换的
                   // Cipher
                   // 对象
  // 将DESKeySpec对象转换成SecretKey对象
  SecretKey securekey = keyFactory.generateSecret(desKey);
  // Cipher对象实际完成解密操作
  Cipher cipher = Cipher.getInstance("DES");
  // 用密匙初始化Cipher对象
  cipher.init(Cipher.DECRYPT_MODE, securekey, random);
  // 真正开始解密操作
  return cipher.doFinal(src);
 }
}
 
输出
 
加密前:123456
加密后:>p.72|
解密后:123456

3.非对称加密

非对称加密算法需要两个密钥：公开密钥（publickey:简称公钥）和私有密钥（privatekey:简称私钥）。

公钥与私钥是一对

• 公钥对数据进行加密，只有用对应的私钥才能解密

• 私钥对数据进行加密，只有用对应的公钥才能解密

过程：

• 甲方生成一对密钥，并将公钥公开，乙方使用该甲方的公钥对机密信息进行加密后再发送给甲方；

• 甲方用自己私钥对加密后的信息进行解密。

• 甲方想要回复乙方时，使用乙方的公钥对数据进行加密

• 乙方使用自己的私钥来进行解密。

• 甲方只能用其私钥解密由其公钥加密后的任何信息。

特点：

• 算法强度复杂

• 保密性比较好

• 加密解密速度没有对称加密解密的速度快。

• 对称密码体制中只有一种密钥，并且是非公开的，如果要解密就得让对方知道密钥。所以保证其安全性就是保证密钥的安全，而非对称密钥体制有两种密钥，其中一个是公开的，这样就可以不需要像对称密码那样传输对方的密钥了。这样安全性就大了很多

• 适用于：金融，支付领域

RSA加密是一种非对称加密

import javax.crypto.Cipher;
import java.security.*;
import java.security.interfaces.RSAPrivateKey;
import java.security.interfaces.RSAPublicKey;
import java.security.spec.PKCS8EncodedKeySpec;
import java.security.spec.X509EncodedKeySpec;
import java.security.KeyFactory;
import java.security.KeyPair;
import java.security.KeyPairGenerator;
import java.security.PrivateKey;
import java.security.PublicKey;
import org.apache.commons.codec.binary.Base64;
 
 
/**
 * RSA加解密工具类
 *
 * 
 */
public class RSAUtil {
 
 public static String publicKey; // 公钥
 public static String privateKey; // 私钥
 
 /**
  * 生成公钥和私钥
  */
 public static void generateKey() {
  // 1.初始化秘钥
  KeyPairGenerator keyPairGenerator;
  try {
   keyPairGenerator = KeyPairGenerator.getInstance("RSA");
   SecureRandom sr = new SecureRandom(); // 随机数生成器
   keyPairGenerator.initialize(512, sr); // 设置512位长的秘钥
   KeyPair keyPair = keyPairGenerator.generateKeyPair(); // 开始创建
   RSAPublicKey rsaPublicKey = (RSAPublicKey) keyPair.getPublic();
   RSAPrivateKey rsaPrivateKey = (RSAPrivateKey) keyPair.getPrivate();
   // 进行转码
   publicKey = Base64.encodeBase64String(rsaPublicKey.getEncoded());
   // 进行转码
   privateKey = Base64.encodeBase64String(rsaPrivateKey.getEncoded());
  } catch (NoSuchAlgorithmException e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
  }
 }
 
 /**
  * 私钥匙加密或解密
  * 
  * @param content
  * @param privateKeyStr
  * @return
  */
 public static String encryptByprivateKey(String content, String privateKeyStr, int opmode) {
  // 私钥要用PKCS8进行处理
  PKCS8EncodedKeySpec pkcs8EncodedKeySpec = new PKCS8EncodedKeySpec(Base64.decodeBase64(privateKeyStr));
  KeyFactory keyFactory;
  PrivateKey privateKey;
  Cipher cipher;
  byte[] result;
  String text = null;
  try {
   keyFactory = KeyFactory.getInstance("RSA");
   // 还原Key对象
   privateKey = keyFactory.generatePrivate(pkcs8EncodedKeySpec);
   cipher = Cipher.getInstance("RSA");
   cipher.init(opmode, privateKey);
   if (opmode == Cipher.ENCRYPT_MODE) { // 加密
    result = cipher.doFinal(content.getBytes());
    text = Base64.encodeBase64String(result);
   } else if (opmode == Cipher.DECRYPT_MODE) { // 解密
    result = cipher.doFinal(Base64.decodeBase64(content));
    text = new String(result, "UTF-8");
   }
 
  } catch (Exception e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
  }
  return text;
 }
 
 /**
  * 公钥匙加密或解密
  * 
  * @param content
  * @param privateKeyStr
  * @return
  */
 public static String encryptByPublicKey(String content, String publicKeyStr, int opmode) {
  // 公钥要用X509进行处理
  X509EncodedKeySpec x509EncodedKeySpec = new X509EncodedKeySpec(Base64.decodeBase64(publicKeyStr));
  KeyFactory keyFactory;
  PublicKey publicKey;
  Cipher cipher;
  byte[] result;
  String text = null;
  try {
   keyFactory = KeyFactory.getInstance("RSA");
   // 还原Key对象
   publicKey = keyFactory.generatePublic(x509EncodedKeySpec);
   cipher = Cipher.getInstance("RSA");
   cipher.init(opmode, publicKey);
   if (opmode == Cipher.ENCRYPT_MODE) { // 加密
    result = cipher.doFinal(content.getBytes());
    text = Base64.encodeBase64String(result);
   } else if (opmode == Cipher.DECRYPT_MODE) { // 解密
    result = cipher.doFinal(Base64.decodeBase64(content));
    text = new String(result, "UTF-8");
   }
  } catch (Exception e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
  }
  return text;
 }
 
 // 测试方法
 public static void main(String[] args) {
  /**
   * 注意： 私钥加密必须公钥解密 公钥加密必须私钥解密
   *  // 正常在开发中的时候,后端开发人员生成好密钥对，服务器端保存私钥 客户端保存公钥
   */
  System.out.println("-------------生成两对秘钥，分别发送方和接收方保管-------------");
  RSAUtil.generateKey();
  System.out.println("公钥:" + RSAUtil.publicKey);
  System.out.println("私钥:" + RSAUtil.privateKey);
 
  System.out.println("-------------私钥加密公钥解密-------------");
   String textsr = "11111111";
   // 私钥加密
   String cipherText = RSAUtil.encryptByprivateKey(textsr,
   RSAUtil.privateKey, Cipher.ENCRYPT_MODE);
   System.out.println("私钥加密后：" + cipherText);
   // 公钥解密
   String text = RSAUtil.encryptByPublicKey(cipherText,
   RSAUtil.publicKey, Cipher.DECRYPT_MODE);
   System.out.println("公钥解密后：" + text);
 
  System.out.println("-------------公钥加密私钥解密-------------");
  // 公钥加密
  String textsr2 = "222222";
 
  String cipherText2 = RSAUtil.encryptByPublicKey(textsr2, RSAUtil.publicKey, Cipher.ENCRYPT_MODE);
  System.out.println("公钥加密后：" + cipherText2);
  // 私钥解密
  String text2 = RSAUtil.encryptByprivateKey(cipherText2, RSAUtil.privateKey, Cipher.DECRYPT_MODE);
  System.out.print("私钥解密后：" + text2 );
 }
 
}

四、使用加签名方式，防止数据篡改

客户端：请求的数据分为2部分（业务参数，签名参数），签名参数=md5（业务参数）

服务端：验证md5(业务参数)是否与签名参数相同
————————————————
作者：单身贵族男
来源：https://blog.csdn.net/zhou920786312/article/details/95536556

收起阅读 »

约翰·冯·诺依曼是20世纪最有影响力的人物之一。从原子弹，到计算机、再到量子力学、气候变化，你可能很难出对我们今天的世界和生活影响更大的科学家了。

在20世纪的天才中，有几个杰出的人物：爱因斯坦、图灵、霍金，毫无疑问，冯·诺依曼也属于他们中的一个，尽管许多人不知道他是谁。 约翰·冯·诺依曼是20世纪最有影响力的人物之一。他可能比过去150年中任何一位伟大的思想更直接地影响了你的生活，他的研究涉及从量子力学到气候科学的一切。 冯·诺依曼最大的贡献是现代计算机，他采用了图灵奠定的卓越理论框架，并实际提出了为几乎所有数字计算机提供动力的架构：冯·诺依曼架构。 更有争议的是，冯·诺依曼在二战期间对曼哈顿计划做出了重大贡献，包括完善原子弹本身的设计和对其功能至关重要的机制。 与曼哈顿计划的其他一些老兵不同，冯·诺依曼从未对自己在该计划中的角色表示遗憾，甚至在冷战期间推动了「同归于尽」的政策。 至少可以说，约翰·冯·诺依曼是一个复杂的人物，但他在20世纪几乎无人能及，可以说他对现代世界的责任比他同时代的任何人都大。

神童降世

约翰·冯·诺依曼于1903年12月28日出生在匈牙利首都布达佩斯。 冯·诺依曼的父亲是银行家，母亲是奥匈贵族的女儿，他的父母富有且受人尊敬。

1913年，奥匈帝国皇帝弗朗茨·约瑟夫授予冯·诺依曼的父亲贵族地位，并给了这个家族一个世袭的头衔「马吉塔」，即现在的罗马尼亚马吉塔。 这个头衔纯粹是尊称，因为这个家庭与这个地方没有任何联系，但这是冯·诺依曼一生都会坚持的。 年轻的冯·诺依曼在同龄人中，被认为是真正的神童，尤其是在数学方面。人们认为他有摄影一般的记忆力，这帮助他从很小的时候就吸收了大量的知识。 冯·诺伊曼11岁时与表妹 Katalin Alcsuti在一起 六岁时，他就开始在头脑中进行两个八位数的除法，八岁时，他已经掌握了微积分。 他的父亲认为，他所有的孩子都需要说除母语匈牙利语以外的欧洲主要语言，所以冯·诺依曼学习了英语、法语、意大利语和德语。 小时候，他对历史也有很深的兴趣，并阅读了德国历史学家威廉·昂肯的整部46卷专著《通史》。

德国历史学家威廉·昂肯 在老师的鼓励下，冯·诺依曼在学习上取得了优异的成绩，但他的父亲不相信数学家的职业会带来经济上的利益。 相反，冯·诺依曼和他的父亲达成共识，同意冯·诺依曼从事化学工程，他17岁去柏林学习，后来在苏黎世学习。 化学似乎是冯·诺依曼少数几个不感兴趣的领域之一，尽管他确实获得了苏黎世化学工程文凭，同时还获得了数学博士学位。

职业生涯早期

约翰·冯·诺依曼很早就发表了论文，从20岁开始，他写了一篇定义序数的论文，这仍然是我们今天使用的定义。 他写了关于集合论的博士论文，并在一生中对该领域做出了若干贡献。
到1927年，冯·诺依曼已经发表了12篇著名的数学论文。到1929年，他已经出版了32部作品，以大约一个月一篇学术论文的速度写出了很多重要的工作。 1928年，他成为柏林大学的一名私 人教师，也是柏林大学历史上获得该职位最年轻的人。 这个职位使他能够在大学里讲课，直到1929年他成为汉堡大学的一名私人教师。 冯·诺依曼在父亲于1929年去世后，皈依了天主教。1930年元旦，约翰·冯·诺依曼与布达佩斯大学经济学学生玛丽埃塔·科维西结婚，并于1935年与她生下了他唯一的孩子玛丽娜。 虽然冯·诺依曼似乎注定要在德国科学院从事一个有前途的职业，但在1929年10月，他获得了新泽西州普林斯顿大学的一个职位，他最终接受了这个职位，并于1930年与妻子一起前往美国。

移民美国

到1933年，约翰·冯·诺依曼成为新成立的普林斯顿高等研究院最初的六名数学教授之一，他也将在这个岗位上度过余生。 当他搬到新泽西时，像他之前的许多美国移民一样，冯·诺依曼将他的匈牙利名字英语化了（由玛吉塔伊·诺依曼·亚诺斯变成约翰·冯·诺依曼，使用德国式的世袭尊称）。 1937年，他和妻子离婚，第二年冯·诺依曼再婚，这次是和克拉拉·丹，他在第二次世界大战前最后一次访问匈牙利时，在布达佩斯第一次见到了克拉拉·丹。 1937年，冯·诺依曼成为美国公民，1939年，他的母亲、兄弟姐妹和姻亲也都移民到了美国（他的父亲早些时候去世了）。

战争年代与「曼哈顿计划」

约翰·冯·诺依曼对历史最重要的贡献之一是他在第二次世界大战期间对曼哈顿计划的研究。 一如既往，冯·诺依曼不能让数学挑战得不到解决，更困难的问题之一是如何模拟爆炸的影响。 冯·诺依曼在20世纪30年代投身于这些问题的研究，并成为该领域的专家。如果他有特长的话，那应该是研究聚能装药（Shaped Charges，用于爆破）领域的数学问题，聚能装药是用来控制和引导爆炸能量的。 这使他与美国军方，特别是美国海军进行了相当多的定期磋商。当曼哈顿计划在20世纪40年代初开始工作时，冯·诺依曼因其专业知识而被招募。 1943年，冯·诺依曼对曼哈顿计划产生了最重大、最持久的影响。 曼哈顿计划成员 当时，设计原子弹的洛斯阿拉莫斯实验室发现，钚-239（该项目使用的裂变材料之一）与实验室的工作炸弹设计不兼容。 实验室的物理学家塞斯·尼德迈尔一直在研究一种独立的内爆型炸弹设计，这种设计很有希望，但许多人认为它不可行。

核弹内爆机制的动画 要引爆核爆炸，需要在炸弹的反应物中引发失控的裂变链式反应。链式反应的速度是指数级的，因此控制爆炸足够长的时间，使足够的裂变材料进行所需的反应，是一项重大挑战。 内爆型炸弹需要更复杂的控制来产生反应，但它也不需要像洛斯阿拉莫斯开发的枪型炸弹设计那样耗费那么多的材料。 内爆型装置使用一系列受控的常规爆炸来压缩其核心中的裂变反应物。 在这种压力下，裂变材料迅速开始核裂变链式反应，通过内爆的力量保持在原位，并允许更多的裂变材料释放其能量。

控制这些爆炸以产生精确的内爆力来产生期望的反应是一项很大的挑战，而冯·诺依曼以极大的热情接受了它。 他认为，使用较少的球形材料并通过内爆力适当压缩，可以产生更有效的爆炸，尽可能多地使用现有的裂变材料。 他经常是少数几个主张内爆方法的人之一，并最终计算出了一个数学公式，表明如果内爆能以至少95%的精度保持球形的几何形状，该方法就是可以实现的。 冯·诺依曼还计算出，如果爆炸在目标上方一定距离引爆，而不是在击中地面时引爆，爆炸的有效性将会提高。 这大大增加了原子弹的杀伤力，也减少了爆炸产生的尘埃量。 之后，冯·诺依曼被选为科学顾问团队的一员，他们就炸弹的可能目标咨询军方。 冯·诺依曼建议将目标定为日本京都，因为京都作为文化之都，其毁灭可能足以迫使战争迅速结束。 提出这一建议的不止他一个人，但战争部长亨利·史汀生否决了将目标对准京都这个提议，因为那里有许多历史建筑和重要的宗教圣地，所以最后选择了广岛和长崎。 1945年7月16日的三位一体试验中，冯·诺依曼在场，当时第一枚原子武器被引爆。广岛和长崎被炸后，日本投降，第二次世界大战结束。 三位一体试验 与曼哈顿计划中同时代的一些人不同，冯·诺依曼似乎没有任何反思的痛苦、遗憾，甚至对他在原子弹方面的工作也没有一丝怀疑。 事实上，冯·诺依曼是核武器发展和相互保证毁灭（MAD）理论的最有力支持者之一，认为这是防止另一场灾难性世界大战的唯一方法。

核武器的「轻量化」思想

像战后初期的许多美国人一样，冯·诺依曼担心美国在核武器发展方面落后于苏联。 到上世纪40 年代末到50 年代初，用战略轰炸机向敌人投掷更多原子弹的理念，逐渐被新的火箭技术所取代。
冯·诺依曼认为，导弹是核武器的未来，由于他与参与苏联武器研制的德国科学家有过接触，他知道苏联对此问题的看法与他是一样的。 军备竞赛开始了，美苏两国把氢弹越做越小，可以装入洲际弹道导弹的弹头，冯·诺依曼积极为美国效力，努力缩小与苏联的「导弹差距」。 战后，冯·诺依曼在原子能委员会任职，为政府和军方提供核技术开发和战略方面的建议，并被广泛认为是「确保相互毁灭」理论（MAD）的设计者，而 MAD 在冷战期间确实被政府采纳，成为事实上的美国国策。

建造第一台真正的计算机

冯·诺依曼在上世纪30年代初遇到了艾伦·图灵，当时图灵正在普林斯顿攻读博士学位。1937年，图灵发表了具有里程碑意义的论文《论可计算数》，奠定了现代计算的理论基础。
冯·诺依曼很快认识到了图灵这一发现的重要性，并在30年代推动了计算机科学的发展。在普林斯顿大学，他和图灵围绕人工智能的思想曾进行了长时间的讨论。 作为一名数学家，冯·诺依曼从更抽象的角度研究计算机科学，另一个原因也是因为在30年代时，并没有真正可以工作的计算机。 在二战结束后，这种情况很快就改变了。 冯·诺依曼深入参与了第一台可编程电子计算机「ENIAC」的开发，这台计算机能够识别和决定其他数据操作规则集，而不是最初使用的规则集。是冯诺依曼将 ENIAC 修改为作为存储程序机器运行。 后者让使我们今天理解的现代程序成为可能。冯·诺依曼本人编写了几个在 ENIAC 上运行的首批程序，并用这些程序模拟原子能委员会的部分核武器研究。 毫无疑问，冯·诺依曼对计算机科学领域最持久的贡献是在当今运行的每台计算机中使用的两个基本概念：冯·诺依曼体系架构和存储程序概念。 冯·诺依曼架构涉及构成计算机的物理电子电路的组织方式。按照这种方式构建的计算机被称为「冯·诺依曼机」。该架构由算术和逻辑单元 (ALU)、控制单元和临时存储器寄存器组成，它们共同构成了中央处理器 (CPU)。 CPU 连接到内存单元，该内存单元包含将要由CPU处理和操作的所有数据。CPU还连接到输入和输出设备，以根据需要更改数据，并检索运行程序的结果。 自 1945 年冯诺依曼提出这一架构以来，直到今天，它基本上仍是当今大多数通用计算机的运行方式，几乎没有改变。 另一项重大创新与冯·诺依曼架构有关，即存储程序概念，也就是说，被操作或处理的数据，以及描述如何操纵和处理该数据的程序，都存储在计算机的内存中。 这两项相互交织的创新实现了图灵机的理论框架，实际上将它们变成了可以用来计算工资、火炮轨迹、游戏、互联网等几乎所有一切数据的机器。

对其他领域的杰出贡献

除了数学和计算机科学之外，冯·诺依曼一生都对其他几个领域也做出了重大贡献。
在早期的职业生涯中，冯·诺依曼为新兴的量子力学领域做出了重大贡献。 1932年，他和保罗·狄拉克在《量子力学的数学基础》一书中发表了狄拉克-冯·诺依曼公理，这是该领域的第一个完整的数学框架。在这本书中，他还提出了量子逻辑的形式系统，也是同类体系中的首创。 冯·诺依曼还将博弈论确立为一门严谨的数学学科，这无疑影响了他后来关于MAD理论的地缘政治战略工作。 冯·诺依曼的博弈论中包含这样一个观点，即在广泛的博弈类别中，总是有可能找到一个平衡，任何参与者都不应单方面偏离这个平衡。 在生命科学领域，冯·诺依曼对元胞自动机的自我复制进行了彻底的数学分析，主要是构造函数、正在构建的事物以及构造函数构建所讨论事物所遵循的蓝图之间的关系。该分析描述了一种自我复制的机器，它是在40年代设计的，没有使用计算机。 冯·诺依曼的数学造诣也惠及气候科学。1950年，他编写了第一个气候建模程序，并使用 ENIAC 使用数值数据进行了世界上第一个气象预测。 冯·诺依曼预计，全球变暖是人类活动的结果，他在1955年写道： 「工业燃烧煤和石油释放到大气中的二氧化碳，可能已经充分改变了大气的成分，导致全球普遍变暖约1华氏度。」 冯·诺依曼也被认为是第一个描述「技术奇点」的人。冯·诺依曼的朋友斯坦·乌拉姆 (Stan Ulam) 后来描述了与他的一次对话，这次对话在今天听起来非常有先见之明。 斯坦·乌拉姆、理查德·费曼和冯·诺依曼在一起 乌拉姆回忆说：「有一次谈话集中在不断加速的技术进步和人类生活方式的变化上，这让我们看到了人类历史上一些本质上的奇点。一旦超越了这些奇点，我们所熟知的人类事务就将无法继续下去了。」

冯·诺依曼的去世，和他的光辉遗产

1955 年，冯·诺依曼在看医生时发现他的锁骨上长了一块肉，他被诊断患有癌症，但他并没有充分接受这个事实。 众所周知，冯·诺依曼对即将到来的结局感到恐惧。他的一生好友尤金·维格纳 (Eugene Wigner) 写道：
「当冯·诺依曼意识到自己病入膏肓时，他的逻辑迫使他意识到，自己即将不复存在，因此也不再有思想……亲眼目睹这一过程是令人心碎的，所有的希望都消失了，即将到来的命运尽管难以接受，但已经不可避免。」 冯·诺依曼的病情在1956年持续恶化，最终被送进了华盛顿特区的沃尔特里德陆军医疗中心。为防止泄密，军方对他实施了特殊的安全措施。 冯·诺依曼邀请一位天主教神父在他临终前商量，并接受了他的临终仪式安排。不过这位神父本人表示，冯诺依曼看上去似乎并没有从仪式中得到安慰。 1957年2月8日，冯·诺依曼因癌症逝世，享年53岁，他被安葬在新泽西州的普林斯顿公墓。 关于冯·诺依曼的癌症是否与他在「曼哈顿计划」期间遭受辐射有关，人们一直存在争议，但毫无争议的是，人类过早地失去了当代最伟大的科学巨人之一。 冯·诺依曼的助手 P.R. Halmos 在1973年写道： 「人类的英雄有两种：一种和我们所有人一样，但更加相似，另一种显然具有一些「超人」的特质。 我们都可以跑步，我们中的一些人可以在不到4分钟的时间内跑完一英里。但有些事，我们大多数人一辈子都无法做到。冯·诺依曼的伟大贡献是惠及全人类的。在某些时候，我们或多或少都能清晰地思考，但冯·诺依曼的清晰思维始终比我们大多数人高出好几个数量级。」 冯·诺依曼的才华是毋庸置疑的，尽管他留下的遗产，尤其是核武器方面的贡献，比他的朋友和崇拜者愿意承认的要复杂得多。 无论我们最终如何看待冯·诺依曼和他的成就，我们都可以肯定地说，在未来一代人甚至几代人的时间里，都不太可能出现像他一样，对人类历史产生如此重大影响的人了。

转自：新智元 | David 小咸鱼
原文链接：https://interestingengineering.com/john-von-neumann-human-the-computer-behind-project-manhattan

收起阅读 »

背景

之前的几篇文章都是关于低代码平台的。

这个大的项目以 low code 为核心，囊括了编辑器前端、编辑器后端、C 端 H5、组件库、组件平台、后台管理系统前端、后台管理系统后台、统计服务、自研 CLI 九大系统。

今天就来说一下其中的统计服务：目的主要是为了实现 H5 页面的分渠道统计(其实不仅仅是分渠道统计，核心是想做一个自定义事件统计服务，只是目前有分渠道统计的需求)，查看每个渠道具体的 PV 情况。(具体会在 url 上面体现，会带上页面名称、id、渠道类型等)

先放一下整体流程图吧：

日志收集

常见的日志收集方式有手动埋点和自动埋点，这里我们不关注于如何收集日志，而是如何将收集的日志的发送到服务器。

在常见的埋点方案中，通过图片来发送埋点请求是一种经常被采纳的，它有很多优势：

• 没有跨域

• 体积小

• 能够完成整个 HTTP 请求+响应（尽管不需要响应内容）

• 执行过程无阻塞

这里的方案就是在 nginx 上放一张 1px * 1px 的静态图片，然后通过访问该图片（http://xxxx.png?env=xx&event=xxx）,并将埋点数据放在query参数上，以此将埋点数据落到nginx日志中。

iOS 上会限制 get 请求的 url 长度，但我们这里真实场景发送的数据不会太多，所以目前暂时采用这种方案

这里简单阐述一下为什么图片地址的query key 要这么设计，如果单纯是为了统计渠道和作品，很有可能会把key设计为channel、workId这种，但上面也说到了，我们是想做一个自定义事件统计服务，那么就要考虑字段的可扩展性，字段应更有通用语义。所以参考了很多统计服务的设计，这里采用的字段为：

• env

• event

• key

• value

之后每次访问页面，nginx就会自动记录日志到access_log中。

有了日志，下面我们来看下如何来对其进行拆分。

日志拆分

为何要拆分日志

access.log日志默认不会拆分，会越积累越多，系统磁盘的空间会被消耗得越来越多，将来可能面临着日志写入失败、服务异常的问题。

日志文件内容过多，对于后续的问题排查和分析也会变得很困难。

所以日志的拆分是有必要也是必须的。

如何拆分日志

我们这里拆分日志的核心思路是：将当前的access.log复制一份重命名为新的日志文件，之后清空老的日志文件。

视流量情况（流量越大日志文件积累的越快），按天、小时、分钟来拆分。可以把access.log按天拆分到某个文件夹中。

log_by_day/2021-12-19.log
log_by_day/2021-12-20.log
log_by_day/2021-12-21.log

但上面的复制 -> 清空操作肯定是要自动处理的，这里就需要启动定时任务，在每天固定的时间（我这里是在每天凌晨 00:00）来处理。

定时任务

其实定时任务不仅在日志拆分的时候会用到，在后面的日志分析和日志清除都会用到，这里先简单介绍一下，最终会整合拆分、分析和清除。

linux中内置的cron进程就是来处理定时任务的。在node中我们一般会用node-schedule或cron来处理定时任务。

这里使用的是cron：

/**
    cron 定时规则 https://www.npmjs.com/package/cron
    *    *    *    *    *    *
    ┬    ┬    ┬    ┬    ┬    ┬
    │    │    │    │    │    │
    │    │    │    │    │    └ day of week (0 - 6) (Sun-Sat)
    │    │    │    │    └───── month (1 - 12)
    │    │    │    └────────── day of month (1 - 31)
    │    │    └─────────────── hour (0 - 23)
    │    └──────────────────── minute (0 - 59)
    └───────────────────────── second (0 - 59)
 */

具体使用方式就不展开说明了。

编码

有了上面这些储备，下面我就来写一下这块代码，首先梳理下逻辑：

1️⃣ 读取源文件 access.log

2️⃣ 创建拆分后的文件夹（不存在时需自动创建）

3️⃣ 创建日志文件（天维度，不存在时需自动创建）

4️⃣ 拷贝源日志至新文件

5️⃣ 清空 access.log

/**
 * 拆分日志文件
 *
 * @param {*} accessLogPath
 */
function splitLogFile(accessLogPath) {
  const accessLogFile = path.join(accessLogPath, "access.log");

  const distFolder = path.join(accessLogPath, DIST_FOLDER_NAME);
  fse.ensureDirSync(distFolder);

  const distFile = path.join(distFolder, genYesterdayLogFileName());
  fse.ensureFileSync(distFile);
  fse.outputFileSync(distFile, ""); // 防止重复，先清空

  fse.copySync(accessLogFile, distFile);

  fse.outputFileSync(accessLogFile, "");
}

日志分析

日志分析就是读取上一步拆分好的文件，然后按照一定规则去处理、落库。这里有一个很重要的点要提一下：node在处理大文件或者未知内存文件大小的时候千万不要使用readFile，会突破 V8 内存限制。正是考虑到这种情况，所以这里读取日志文件的方式应该是：createReadStream创建一个可读流交给 readline 逐行读取处理

readline

readline 模块提供了用于从可读流每次一行地读取数据的接口。 可以使用以下方式访问它：

const readline = require("readline");

readline 的使用也非常简单：创建一个接口实例，传入对应的参数：

const readStream = fs.createReadStream(logFile);
const rl = readline.createInterface({
  input: readStream,
});

然后监听对应事件即可：

rl.on("line", (line) => {
  if (!line) return;

  // 获取 url query
  const query = getQueryFromLogLine(line);
  if (_.isEmpty(query)) return;

  // 累加逻辑
  // ...
});
rl.on("close", () => {
  // 逐行读取结束，存入数据库
  const result = eventData.getResult();
  resolve(result);
});

这里用到了line和close事件：

• line事件：每当 input 流接收到行尾输入（\n、\r 或 \r\n）时，则会触发 'line' 事件

• close事件：一般在传输结束时会触发该事件

逐行分析日志结果

了解了readline 的使用，下面让我们来逐行对日志结果进行分析吧。

首先来看下access.log中日志的格式：

我们取其中一行来分析：

127.0.0.1 - - [19/Feb/2021:15:22:06 +0800] "GET /event.png?env=h5&event=pv&key=24&value=2 HTTP/1.1" 200 5233 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 11_0_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.150 Safari/537.36" "-"

我们要拿到的就是url的query部分，也就是我们在h5中自定义的数据。

通过正则匹配即可：

const reg = /GET\s\/event.png\?(.+?)\s/;
const matchResult = line.match(reg);
console.log("matchResult", matchResult);

const queryStr = matchResult[1];
console.log("queryStr", queryStr);

打印结果为：

queryStr可通过node中的querystring.parse()来处理：

const query = querystring.parse(queryStr);



console.log('query', query)

{

  env: 'h5',

  event: 'pv',

  key: '24',

  value: '2'

}

剩下的就是对数据做累加处理了。

但如何去做累加，我们要想一下，最开始也说了是要去做分渠道统计，那么最终的结果应该可以清晰的看到两个数据：

• 所有渠道的数据

• 每个渠道单独的数据

只有这样的数据对于运营才是有价值的，数据的好坏也直接决定了后面在每个渠道投放的力度。

这里我参考了 Google Analytics中的多渠道漏斗的概念，由上到下分维度记录每个维度的数据，这样就可以清晰的知道每个渠道的情况了。

具体实现也不麻烦，我们先来看下刚刚从一条链接中得到的有用数据：

{
  env: 'h5',
  event: 'pv',
  key: '24',
  value: '2'
}

这里的env代表环境，这里统计的都是来源于h5页面，所以env为h5，但是为了扩展，所以设置了这个字段。

event表示事件名称，这里主要是统计访问量，所以为pv。

key是作品 id。

value是渠道 code，目前主要有：1-微信、2-小红书、3-抖音。

再来看下最终统计得到的结果吧：

{
  date: '2021-12-21',
  key: 'h5',
  value: { num: 1276}
}
{
  date: '2021-12-21',
  key: 'h5.pv',
  value: { num: 1000}
}
{
  date: '2021-12-21',
  key: 'h5.pv.12',
  value: { num: 200}
}
{
  date: '2021-12-21',
  key: 'h5.pv.12.1',
  value: { num: 56}
}
{
  date: '2021-12-21',
  key: 'h5.pv.12.2',
  value: { num: 84}
}
{
  date: '2021-12-21',
  key: 'h5.pv.12.3',
  value: { num: 60}
}

这是截取了2021-12-21当天的数据，我给大家分析一波：

1️⃣ h5：当天 h5 页面的自定义事件上报总数为 1276

2️⃣ h5.pv：其中 所有 pv（也就是 h5.pv）为 1000

3️⃣ h5.pv.12：作品 id 为 12 的 pv 一共有 200

4️⃣ h5.pv.12.1：作品 id 为 12 的在微信渠道的 pv 为 56

5️⃣ h5.pv.12.2：作品 id 为 12 的在小红书渠道的 pv 为 84

6️⃣ h5.pv.12.2：作品 id 为 12 的在抖音渠道的 pv 为 60

这样就能清楚的得到某一天某个作品在某条渠道的访问情况了，后续再以这些数据为支撑做成可视化报表，效果就一目了然了。

统计结果入库

目前这部分数据是放在了mongoDB中，关于node中使用mongoDB就不展开说了，不熟悉的可以参考我另外一篇文章Koa2+MongoDB+JWT 实战--Restful API 最佳实践

这里贴下model吧：

/**
 * @description event 数据模型
 */
const mongoose = require("../db/mongoose");

const schema = mongoose.Schema(
  {
    date: Date,
    key: String,
    value: {
      num: Number,
    },
  },
  {
    timestamps: true,
  }
);

const EventModel = mongoose.model("event_analytics_data", schema);

module.exports = EventModel;

日志删除

随着页面的持续访问，日志文件会快速增加，超过一定时间的日志文件存在的价值也不是很大，所以我们要定期清除日志文件。

这个其实比较简单，遍历文件，因为文件名都是以日期命名的(格式：2021-12-14.log)，所以只要判断时间间隔大于 90 天就删除日志文件。

贴一下核心实现：

// 读取日志文件
const fileNames = fse.readdirSync(distFolder);
fileNames.forEach((fileName) => {
  try {
    // fileName 格式 '2021-09-14.log'
    const dateStr = fileName.split(".")[0];
    const d = new Date(dateStr);
    const t = Date.now() - d.getTime();
    if (t / 1000 / 60 / 60 / 24 > 90) {
      // 时间间隔，大于 90 天，则删除日志文件
      const filePath = path.join(distFolder, fileName);
      fse.removeSync(filePath);
    }
  } catch (error) {
    console.error(`日志文件格式错误 ${fileName}`, error);
  }
});

定时任务整合

到这里，日志的拆分、分析和清除都说完了，现在要用cron来对他们做整合了。

首先来创建定时任务：

function schedule(cronTime, onTick) {
  if (!cronTime) return;
  if (typeof onTick !== "function") return;

  // 创建定时任务
  const c = new CronJob(
    cronTime,
    onTick,
    null, // onComplete 何时停止任务
    true, // 初始化之后立刻执行
    "Asia/Shanghai" // 时区
  );

  // 进程结束时，停止定时任务
  process.on("exit", () => c.stop());
}

然后每一阶段都在不同的时间阶段去处理（定时拆分 -> 定时分析 -> 定时删除）

定时拆分

function splitLogFileTiming() {
  const cronTime = "0 0 0 * * *"; // 每天的 00:00:00
  schedule(cronTime, () => splitLogFile(accessLogPath));
  console.log("定时拆分日志文件", cronTime);
}

定时分析并入库

function analysisLogsTiming() {
  const cronTime = "0 0 3 * * *"; // 每天的 3:00:00 ，此时凌晨，访问量较少，服务器资源处于闲置状态
  schedule(cronTime, () => analysisLogsAndWriteDB(accessLogPath));
  console.log("定时分析日志并入库", cronTime);
}

定时删除

function rmLogsTiming() {
  const cronTime = "0 0 4 * * *"; // 每天的 4:00:00 ，此时凌晨，访问量较少，服务器资源处于闲置状态
  schedule(cronTime, () => rmLogs(accessLogPath));
  console.log("定时删除过期日志文件", cronTime);
}

然后在应用入口按序调用即可：

// 定时拆分日志文件
splitLogFileTiming();
// 定时分析日志并入库
analysisLogsTiming();
// 定时删除过期日志文件
rmLogsTiming();

总结

ok，到这里，一个简易的统计服务就完成了。

作者：前端森林
来源：https://segmentfault.com/a/1190000041184489

收起阅读 »

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

引言

对于一个软件平台来说，软件平台代码的好坏直接影响平台整体的质量与稳定性。同时也会影响着写代码同学的创作激情。想象一下如果你从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同步更新了

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

引用请注明出处！

收起阅读 »