通过淘宝weex，微信，美团kmm，天猫Waft 等不同项目来了解目前各家公司在跨平台方向上有哪些不同的项目，用了什么不同技术实现方式，然后在对比常用的react native ，flutter 和WebAssembly具体在技术上的区别在哪里。

客户端渲染执行逻辑

android

层次的底部是 Linux，它提供基本的系统功能，如进程管理，内存管理，设备管理，如：相机，键盘，显示器等内核处理的事情。体系结构第三个部分叫做Java虚拟机，是一种专门设计和优化的 Android Dalvik 虚拟机。应用程序框架层使用Java类形式的应用程序提供了许多的更高级别的服务。允许应用程序开发人员在其应用程序中使用这些服务。应用在最上层，即所有的 Android 应用程序。一般我们编写的应用程序只被安装在这层。应用的例子如：浏览器，游戏等。

绘制流程

1. 
   

   创建视图

   
   

ui生成就是把代码中产生的view和在xml文件配置的view，经过measure，layout，dewa 形成一个完整的view树，并调用系统方法进行绘制。Measure 用深度优先原则递归得到所有视图（View）的宽、高；Layout 用深度优先原则递归得到所有视图（View）的位置；到这里就得到view的在窗口中的布局。Draw 目前 Android 支持了两种绘制方式：软件绘制（CPU）和硬件加速（GPU），会通过系统方法把要绘制的view 合成到不同的缓冲区上

最初的ui配置

构建成内存中的view tree

2.视图布局

3.图层合成

SurfaceFlinger 把缓存 区数据渲染到屏幕，由于是两个不同的进程，所以使用 Android 的匿名共享内存 SharedClient 缓存需要显示的数据来达到目的。 SurfaceFlinger 把缓存区数据渲染到屏幕（流程如下图所示），主要是驱动层的事情，这 里不做太多解释。

4. 系统绘制

绘制过程首先是 CPU 准备数据，通过 Driver 层把数据交给 CPU 渲 染，其中 CPU 主要负责 Measure、Layout、Record、Execute 的数据计算工作，GPU 负责 Rasterization（栅格化）、渲染。由于图形 API 不允许 CPU 直接与 GPU 通信，而是通过中间 的一个图形驱动层（Graphics Driver）来连接这两部分。图形驱动维护了一个队列，CPU 把 display list 添加到队列中，GPU 从这个队列取出数据进行绘制，最终才在显示屏上显示出来。

ios：

架构

1. Core OS layer

• 核心操作系统层包括内存管理、文件系统、电源管理以及一些其他的操作系统任务，直接和硬件设备进行交互

2. Core Services layer

• 核心服务层，我们可以通过它来访问iOS的一些服务。包含: 定位，网络，数据 sql

3. Media layer

• 顾名思义，媒体层可以在应用程序中使用各种媒体文件，进行音频与视频的录制，图形的绘制，以及制作基础的动画效果。

4. Cocoa Touch layer

• 本质上来说它负责用户在iOS设备上的触摸交互操作


• 包括以下这些组件： Multi-Touch Events Core Motion Camera View Hierarchy Localization Alerts Web Views Image Picker Multi-Touch Controls.

ios 的视图树

ios的 绘制流程：

显示逻辑

• CoreAnimation提交会话，包括自己和子树（view hierarchy）的layout状态等；


• RenderServer解析提交的子树状态，生成绘制指令；


• GPU执行绘制指令；


• 显示渲染后的数据；

提交流程

1、布局（Layout）

调用layoutSubviews方法； 调用addSubview:方法；

2、显示（Display）

通过drawRect绘制视图； 绘制string（字符串）；

每个UIView都有CALayer，同时图层有一个像素存储空间，存放视图；调用-setNeedsDisplay的时候，仅会设置图层为dirty。 当一个视图第一次或者某部分需要更新的时候iOS系统总是会去请求drawRect:方法。

以下是触发视图更新的一些操作：

• 移动或删除视图


• 通过将视图的hidden属性设置为NO


• 滚动消失的视图再次需要出现在屏幕上


• 视图显式调用setNeedsDisplay或setNeedsDisplayInRect:方法

视图系统都会自动触发重新绘制。对于自定义视图，就必须重写drawRect:方法去执行所有绘制。视图第一次展示的时候，iOS系统会传递正方形区域来表示这个视图绘制的区域。

在调用drawRect:方法之后，视图就会把自己标记为已更新，然后等待下一次视图更新被触发。

3、准备提交（Prepare）

解码图片； 图片格式转换；

4、提交（Commit）

打包layers并发送到渲染server；

递归提交子树的layers；

web ：

web内容准备阶段

web 通常需要将所需要的html，css，js都下载下来，并进行解析执行后才进行渲染，然后是绘制过程，先来看下前期工作

一个渲染流程会划分很多子阶段，整个处理过程叫渲染流水线，流水线可分为如下几个子阶段：构建DOM树、样式计算、布局阶段、分层、绘制、分块、光栅化和合成。每个阶段都经过输入内容 -->处理过程-->输出内容三个部分。

1. 渲染进程将HTML内容转换为能够读懂的DOM树结构

2. 渲染引擎将CSS样式表转化为浏览器可以理解的styleSheets（生存CSSDOM树），计算出DOM节点的样式

styleSheets格式

3. 创建布局树（LayoutTree），并计算元素的布局信息。

我们有DOM树和DOM树中元素的样式，那么接下来就需要计算出DOM树中可见元素的几何位置，我们把这个计算过程叫做布局。根据元素的可见信息构建出布局树。

4. 对布局树进行分层，并生成分层树(LayerTree)。

5. 为每个图层生成绘制列表，并将其提交到合成线程。

6. 合成线程将图层分成图块，并在光栅化线程池中将图块转换成位图。

合成线程会按照视口附近的图块来优先生成位图，实际生成位图的操作是由栅格化来执行的。所谓栅格化，是指将图块转换为位图。

7. 合成线程发送绘制图块命令DrawQuad给浏览器进程。浏览器进程根据DrawQuad消息生成页面，并显示到显示器上

web 在android 中的绘制

WebView实际上是一个ViewGroup，并将后端的具体实现抽象为WebViewProvider，而WebViewChromium正是一个提供基于Chromium的具体实现类。

再回到WebView的情况。当WebView部件发生内容更新时，例如页面加载完毕，CSS动画，或者是滚动、缩放操作导致页面内容更新，同样会在WebView触发invalidate方法，随后在视图系统的统筹安排下，WebView.onDraw方法会被调用，最后实际上调用了AwContents.onDraw方法，它会请求对应的native端对象执行OnDraw方法，将页面的内容更新绘制到WebView对应的Canvas上去。

draw()先得到一块Buffer,这块Buffer是由SurfaceFlinger负责管理的。

然后调用view的draw(canvas)当view draw完后，调用surface.java的unlockAndPostCanvas().

将包含有当前view内容的Buffer传给SurfaceFlinger,SurfaceFlinger将所有的Buffer混合后传给FrameBuffer.至此和native原有的view 渲染就是一样的了。

成熟的框架的底层原理：

react ：

RN 的 Android Bridge 和 IOS Bridge 是两端通信的桥梁, 是由一个转译的桥梁实现的不同语言的通信, 得以实现单靠 JS 就调用移动端原生 APi

架构

• RN 的核心驱动力就来自 JS Engine, 我们所有的 JS 代码都会通过 JS Engine 来编译执行, 包括 React 的 JSX 也离不开 JS Engine, JavaScript Core 是其中一种 JS 引擎, 还有 Google 的 V8 引擎, Mozilla 的 SpiderMonkey 引擎。


• RN 是用类 XML 语言来表示结构, 用 StyleSheet 来规划样式, 但是 UI 控件调用的是 RN 里自己的两端实现控件(android 和 IOS)

• JavaScript 在 RN 的作用就是给原生组件发送指令来完成 UI 渲染, 所以 JavaScript Core 是 RN 中的核心部分

• RN 是不用 JS 引擎的 UI 渲染控件的, 但是会用到 JS 引擎的 DOM 操作管理能力来管理所有 UI 节点, 每次在写完 UI 组件代码后会交给 yoga 去做布局排版, 然后调用原生组件绘制


• bridge 负责js 和native的通讯，以android为例：Java层与Js层的bridge分别存有相同一份模块配置表，Java与Js互相通信时，通过bridge里的配置表将所调用模块方法转为{moduleID,methodID,args}的形式传递给处理层，处理层通过bridge的模块配置表找到对应的方法执行，如果有callback，则回传给调用层

通讯机制

Java -> Js： Java通过注册表调用到CatalystInstance实例，通过jni，调用到 javascriptCore，传递给调用BatchedBridge.js，根据参数｛moduleID,methodID｝require相应Js模块执行。

Js -> Java： JS不主动传递数据调用Java。在需要调用调Java模块方法时，会把参数｛moduleID,methodID｝等数据存在MessageQueue中，等待Java的事件触发，再把MessageQueue中的｛moduleID,methodID｝返回给Java，再根据模块注册表找到相应模块处理。

事件循环

JS 开发者只需要开发各个组件对象，监听组件事件， 然后利用framework接口调用render方法渲染组件。

而实际上，JS 也是单线程事件循环，不管是 API调用， virtural DOM同步， 还是系统事件监听， 都是异步事件，采用Observer（观察者）模式监听JAVA层事件， JAVA层会把JS 关心的事件通过bridge直接使用javascriptCore的接口执行固定的脚本， 比如"requrire (test_module).test_methode(test_args)"。此时，UI main thread相当于work thread, 把系统事件或者用户事件往JS层抛，同时，JS 层也不断调用模块API或者UI组件 ， 驱动JAVA层完成实际的View渲染。JS开发者只需要监听JS层framework定义的事件即可

react 的渲染流程

首先回顾一下当前Bridge的运行过程。当我们写了类似下面的React源码。

<View style={{ backgroundColor: 'pink', width: 200, height: 200}}/>

JS thread会先对其序列化,形成下面一条消息

UIManager.createView([343,"RCTView",31,{"backgroundColor":-16181,"width":200,"height":200}])

通过Bridge发到ShadowThread。Shadow Tread接收到这条信息后，先反序列化，形成Shadow tree，然后传给Yoga，形成原生布局信息。接着又通过Bridge传给UI thread。UI thread 拿到消息后，同样先反序列化，然后根据所给布局信息，进行绘制。

从上面过程可以看到三个线程的交互都是要通过Bridge，因此瓶颈也就在此。

首次渲染流程

1. Native 打开 RN 页面


2. JS 线程运行，Virtual DOM Tree 被创建


3. JS 线程异步通知 Shadow Thread 有节点变更


4. Shadow Thread 创建 Shadow Tree


5. Shadow Thread 计算布局，异步通知 Main Thread 创建 Views


6. Main Thread 处理 View 的创建，展示给用户

react native 新架构

• JSI：JSI是Javascript Interface的缩写，一个用C++写成的轻量级框架，它作用就是通过JSI，JS对象可以直接获得C++对象(Host Objects)引用，并调用对应方法。

另外JSI与React无关，可以用在任何JS 引擎（V8,Hermes)。有了JSI，JS和Native就可以直接通信了,调用过程如下：JS->JSI->C++->ObjectC/Java

• Fabric 是 UI Manager 的新名称, 将负责 Native UI 渲染, 和当前 Bridge 不同的是, 可以通过 JSI 导出自己的 Native 函数, 在 JS 层可以直接使用这些函数引用, 反过来 Native 可以直接调用 JS 层, 从而实现同步调用, 这带来更好的数据传输和性能提升

对比

flutter：

生产环境中 Dart 通过 AOT 编译成对应平台的指令，同时 Flutter 基于跨平台的 Skia 图形库自建了渲染引擎，最大程度地保证了跨平台渲染的一致性

• embedder： 可以称为嵌入器，这是和底层的操作系统进行交互的部分。因为flutter最终要将程序打包到对应的平台中，对于Android平台使用的是Java和C++，对于iOS和macOS平台，使用的是Objective-C/Objective-C++。

• engine：Flutter engine基本上使用C++写的。engine的存在是为了支持Dart Framework的运行。它提供了Flutter的核心API，包括作图、文件操作、网络IO、dar运行时环境等核心功能。Flutter Engine线程的创建和管理是由embedder负责的。

• Flutter framework： 这一层是用户编程的接口，我们的应用程序需要和Flutter framework进行交互，最终构建出一个应用程序。

Flutter framework主要是使用dart语言来编写的。framework从下到上，我们有最基础的foundational包，和构建在其上的 animation, painting和 gestures 。

再上面就是rendering层，rendering为我们提供了动态构建可渲染对象树的方法,通过这些方法，我们可以对布局进行处理。接着是widgets layer,它是rendering层中对象的组合，表示一个小挂件。

Widgets 理解

Widgets是Flutter中用户界面的基础。你在flutter界面中能够观察到的用户界面，都是Widgets。大的Widgets又是由一个个的小的Widgets组成，这样就构成了Widgets的层次依赖结构,在这种层次结构中，子Widgets可以共享父Widgets的上下文环境。在Flutter中一切皆可为Widget。

举例，这个Containerks 控件里的child，color，Text 都是Widget。

  color: Colors.blue,

  child: Row(

    children: [

      Image.network('http://www.flydean.com/1.png'),

      const Text('A'),

    ],

  ),

);

Widgets表示的是不可变的用户UI界面结构。虽然结构是不能够变化的，但是Widgets里面的状态是可以动态变化的。根据Widgets中是否包含状态，Widgets可以分为stateful和stateless widget,对应的类是StatefulWidget和StatelessWidget。

渲染和绘制

渲染就是将上面我们提到的widgets转换成用户肉眼可以感知的像素的过程。Flutter代码会直接被编译成使用 Skia 进行渲染的原生代码,从而提升渲染效率。

代码首先会形成widgets树如下，这些widget在build的过程中，会被转换为 element tree，其中ComponentElement是其他Element的容器，而RenderObjectElement是真正参与layout和渲染的element。。一个element和一个widget对应。然后根据elementrtree 中需要渲染的元素形成RenderTree ，flutter仅会重新渲染需要被重新绘制的element，每次widget变化时element会比较前后两个widget，只有当某一个位置的Widget和新Widget不一致，才会重新创建Element和widget。 最后还会一个layer tree，表示绘制的图层。

四棵树有各自的功能

Flutter绘制流程

• Animate，触发动画更新下一帧的值


• Build，触发构建或刷新 Widget Tree、Element Tree、RenderObject Tree


• Layout，触发布局操作，确定布局大小和位置信息


• CompositeBits，更新需要合成的 Layer 层标记


• Paint，触发 RenderObject Tree 的绘制操作，构建 Layer Tree


• Composite，触发 Layer Tree 发送到 Engine，生成 Engine LayerTree

在 UIThread 构建出四棵树，并在 Engine 生成 Scene，最后提交给 RasterThread，对 LayerTree 做光栅化合成上屏。

Flutter 渲染流程

• 
  

  UIThread

  
  

  UIThread 是 Platform 创建的子线程，DartVM Root Isolate 所有的 dart 代码都运行在该线程。阻塞 UIThread 会直接导致 Flutter 应用卡顿掉帧。

  
  


• 
  

  RasterThread

  
  

  RasterThread 原本叫做 GPUThread，也是 Platform 创建的子线程，但其实它是运行在 CPU 用于处理数据提交给 GPU，所以 Flutter 团队将其名字改为 Raster，表明它的作用是光栅化。

  
  

  C++ Engine 中的光栅化和合成过程运行在该线程。

  
  


• 
  

  C++ Engine 触发 Platform 注册 VSync 垂直信号回调，通过 Platform -> C++ Engine -> Dart Framework 触发整个绘制流程

  
  


• 
  

  Dart Framework 构建出四棵树，Widget Tree、Element Tree、RenderObject Tree、Layer Tree，布局、记录绘制区域及绘制指令信息生成 flutter::LayerTree，并保存在 Scene 对象用以光栅化，这个过程运行在 UIThread

  
  


• 
  

  通过 Flutter 自建引擎 Skia 进行光栅化和合成操作， 将 flutter::LayerTree 转换为 GPU 指令，并发送给 GPU 完成光栅化合成上屏显示操作，这个过程执行在 RasterThread

  
  

整个调度过程是生产者消费者模型，UIThread 负责生产 flutter::Layer Tree，RasterThread 负责消费 flutter::Layer Tree。

flutter 线程模型

Mobile平台上面每一个Engine实例启动的时候会为UI，GPU，IO Runner各自创建一个新的线程。所有Engine实例共享同一个Platform Runner和线程。

• 
  

  Platform Task Runner

  
  

  Flutter Engine的主Task Runner，可以理解为是主线程，一个Flutter应用启动的时候会创建一个Engine实例，Engine创建的时候会创建一个线程供Platform Runner使用。改线程不仅仅处理与Engine交互，它还处理来自平台的消息。

  
  


• 
  

  UI Task Runner Thread（Dart Runner）

  
  

  UI Task Runner被Flutter Engine用于执行Dart root isolate代码，Root isolate运行应用的main code。负责触发构建或刷新 Widget Tree、Element Tree、RenderObject Tree，生成最终的Layer Tree。

  
  

  Root Isolate还是处理来自Native Plugins的消息响应，Timers，Microtasks和异步IO（isolate是有自己的内存和单线程控制的运行实体，isolate之间的内存在逻辑上是隔离的）。

  
  


• 
  

  GPU Task Runner

  
  

  GPU Task Runner中的模块负责将Layer Tree提供的信息转化为实际的GPU指令，执行设备GPU相关的skia调用，转换相应平台的绘制方式，比如OpenGL, vulkan, metal等。GPU Task Runner同时也负责配置管理每一帧绘制所需要的GPU资源

  
  


• 
  

  IO Task Runne

  
  

IO Runner的主要功能是从图片存储（比如磁盘）中读取压缩的图片格式，将图片数据进行处理为GPU Runner的渲染做好准备

Dart 是单线程的，但是采用了Event Loop 机制，也就是不断循环等待消息到来并处理。在 Dart 中，实际上有两个队列，一个事件队列（Event Queue），另一个则是微任务队列（Microtask Queue）。在每一次事件循环中，Dart 总是先去第一个微任务队列中查询是否有可执行的任务，如果没有，才会处理后续的事件队列的流程。

isolate机制尽管 Dart 是基于单线程模型的，但为了进一步利用多核 CPU，将 CPU 密集型运算进行隔离，Dart 也提供了多线程机制，即 Isolate。每个 Isolate 都有自己的 Event Loop 与 Queue，Isolate 之间不共享任何资源，只能依靠消息机制通信，因此也就没有资源抢占问题。Isolate 通过发送管道（SendPort）实现消息通信机制。我们可以在启动并发 Isolate 时将主 Isolate 的发送管道作为参数传给它，这样并发 Isolate 就可以在任务执行完毕后利用这个发送管道给我们发消息。

如果需要在启动一个 Isolate 执行某项任务，Isolate 执行完毕后，发送消息告知我们。如果 Isolate 执行任务时，同时需要依赖主 Isolate 给它发送参数，执行完毕后再发送执行结果给主 Isolate这样的双向通信，让并发 Isolate 也回传一个发送管道即可。

weex：

架构：

1. 将weex源码生成JS Bundle,由template、style 和 script等标签组织好的内容，通过转换器转换成JS Bundle


2. 服务端部署JS Bundle ,将JS Bundle部署在服务器，当接收到终端（Web端、iOS端或Android端）的JS Bundle请求，将JS Bundle下发给终端


3. WEEX SDK初始化,初始化 JS 引擎，准备好 JS 执行环境


4. 构建渲染指令树,Weex 里都使用 DOM API 把 Virtual DOM 转换成真实的Element 树，而是使用 JS Framework 里定义的一套 Weex DOM API 将操作转化成渲染指令发给客户端，形成客户端的真实控件


5. 页面的 js 代码是运行在 js 线程上的，然而原生组件的绘制、事件的捕获都发生在 UI 线程。在这两个线程之间的通信用的是 callNative 和 callJS 这两个底层接口。callNative 是由客户端向 JS 执行环境中注入的接口，提供给 JS Framework 调用。callJS 是由 JS Framework 实现的，并且也注入到了执行环境中，提供给客户端调用。

渲染过程

Weex 里页面的渲染过程和浏览器的渲染过程类似，整体可以分为【创建前端组件】-> 【构建 Virtual DOM】->【生成“真实” DOM】->【发送渲染指令】->【绘制原生 UI】这五个步骤。前两个步骤发生在前端框架中，第三和第四个步骤在 JS Framework 中处理，最后一步是由原生渲染引擎实现的。 页面渲染的大致流程如下

各家项目的实现方式：

淘宝新⼀代⾃绘渲染引擎 的架构与实践

Weex 技术发展历程

Weex 2.0 简版架构

最上层的前端生态还是没变的，应该还是以vue的响应式编程为主。

2.0多了js和c++的直接调用，减少js引擎和布局引擎的通讯开销。

Weex 2.0 重写了渲染层的实现，不再依赖系统 UI，改成依赖统一的图形库 Skia 自绘渲染，和 Flutter 原理很像，我们也直接复用了 Flutter Engine 的部分代码。底层把 Weex 对接过的各种原生能力、三方扩展模块都原样接入。对于上层链路，理论上讲业务 JS 代码、Vue/Rax、JS Framework 都是不需要修改的。在 JS 引擎层面也做了一些优化，安卓上把 JavaScriptCore 换成了 QuickJS，用 bytecode 加速二次打开性能，并且结合 Weex js bundle 的特点做针对性的优化。

字节码编译原理

渲染原理

渲染引擎通用的渲染管线可以简化为【执行脚本】-->【构建节点】-->【布局/绘制】--> 【合成/光栅化】--【上屏】这几个步骤。Weex 里的节点构建逻辑主要在 JS 线程里执行，提交一颗静态节点树到 UI 线程，UI 线程计算布局和绘制属性，生成 Layer Stack 提交到 GPU 线程。

天猫：WAFT：基于WebAssembly和Skia 的AIoT应用开发框架

整体方案

为什么选择WebAssemy？

支持 AOT 模式，拔高了性能上限；活跃的开源社区，降低项目推进的风险；支持多语言，拓宽开发者群体。

WebAssembly（又名wasm）是一种高效的，低级别的编程语言。 它让我们能够使用JavaScript以外的语言（例如C，C ++，Rust或其他）编写程序，然后将其编译成WebAssembly，进而生成一个加载和执行速度非常快的Web应用程序

WebAssembly是基于堆栈的虚拟机的二进制指令格式，它被设计为编程语言的可移植编译目标。目前很多语言都已经将 WebAssembly 作为它的编译目标了。

waft 开发方式

可以看到是采用类前端的开发方式，限定一部分css能力。最后编译为WebAssembly，打包成wasm bundle。 在进行aot 编译城不同架构下的机器码。

运行流程

可以看到bundle 加载过程中，会执行UI区域的不同的生命周期函数。然后在渲染过程则是从virtual dom tree 转化到widget tree，然后直接通过skia 渲染库直接进行渲染。

Waft 第二阶段成果-跨平台

美团KMM在餐饮SaaS中的探索与实践

KMP：Kotlin Multiplatform projects 使用一份kotlin 代码在不同平台上运行

KMM：Kotlin MultiplatformMobile 一个用于跨平台移动应用程序的 SDK。使用 KMM，可以构建多平台移动应用程序并在 Android 和 iOS 应用程序之间共享核心层和业务逻辑等方面。开发人员可以使用单一代码库并通过共享数据层和业务逻辑来实现功能。其实就是把一份逻辑代码编译为多个平台的产物编译中间产物，在不同平台的边缘后端下转为不同的变异后端产物，在不同平台下运行。

IR 全称是 intermediate representation，表示编译过程中的中间信息，由编译器前端对源码分析后得到，随后会输入到后端进一步编译为机器码

IR 可以有一系列的表现方式，由高层表示逐渐下降(lowering)到低层

我们所讨论的 Kotlin IR 是抽象语法树结构（AST），是比较高层的 IR 表示类型。

有了完备的 IR，就可以利用不同的 后端，编出不同的目标代码，比如 JVM 的字节码，或者运行在 iOS 的机器码，这样就达到了跨端的目的

对比

总结

当前存在4种多端方案：

1. Web 容器方案


2. 泛 Web 容器方案


3. 自绘引擎方案


4. 开放式跨端框架

引用文章：

zhuanlan.zhihu.com/p/20259704​​

zhuanlan.zhihu.com/p/281238593​​

zhuanlan.zhihu.com/p/388681402​​

juejin.cn/post/708412…​​

guoshuyu.cn/home/wx/Flu…​​

oldbird.run/flutter/u11…​​

w4lle.com/2020/11/09/…​​

blog.51cto.com/jdsjlzx/568…​​

http://www.devio.org/2021/01/10/…​​

gityuan.com/flutter/​​

gityuan.com/2019/06/15/…​​

zhuanlan.zhihu.com/p/78758247​​

http://www.finclip.com/news/f/5

035…​​

Redis 的数据 全部存储 在 内存 中，如果 突然宕机，数据就会全部丢失，因此必须有一套机制来保证 Redis 的数据不会因为故障而丢失，这种机制就是 Redis 的 持久化机制，它会将内存中的数据库状态 保存到磁盘 中。

Redis 中的两种持久化方式： RDB（Redis DataBase）和 AOF（Append Of File）

1. RDB（Redis DataBase）

在指定的 时间间隔内 将内存中的数据集 快照 写入磁盘，也就是行话讲的快照（Snapshot），它恢复时是将快照文件直接读到内存里

1.1 原理

不使用Fork存在的问题

• 
  

  Redis 是一个 单线程 的程序，这意味着，我们不仅仅要响应用户的请求，还需要进行内存快照。而后者要求 Redis 必须进行 IO 操作，这会严重拖累服务器的性能。

  
  


• 
  

  在 持久化的同时，内存数据结构 还可能在 变化，比如一个大型的 hash 字典正在持久化，结果一个请求过来把它删除了，可是这才刚持久化结束。

  
  

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到 一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。 整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是 最后一次持久化后的数据可能丢失。

1.2 fork 函数

根据操作系统多进程 COW(Copy On Write) 机制，Redis 在持久化时会调用 glibc 的函数 fork 产生一个子进程，简单理解也就是基于当前进程 复制 了一个进程，主进程和子进程会共享内存里面的代码块和数据段。

• Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程


• 在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，Linux中引入了“写时复制技术”


• 一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。

1.3 RDB流程图

1.4 RDB相关配置

1.4.1 配置文件

• RDB文件默认在redis主目录下的 dump.rdb中

• 快照默认的保持策略

1. 先前的快照是在3600秒（1小时）前创建的，并且现在已经至少有 1 次新写入，则将创建一个新的快照；


2. 先前的快照是在300秒（5分钟）前创建的，并且现在已经至少有 100 次新写入，则将创建一个新的快照；


3. 先前的快照是在60秒（1分钟）前创建的，并且现在已经至少有 10000 次新写入，则将创建一个新的快照；

1.4.2 相关指令

save ：save时只管保存，其它不管，全部阻塞。手动保存。不建议。

bgsave： Redis 会在后台异步进行快照操作， 快照同时还可以响应客户端请求。

lastsave：获取最后一次成功执行快照的时间

1.5 RDB如何备份

1. config get dir  查询rdb文件的目录


2. 关闭Redis


3. 将备份文件 dump.rdb 移动到 redis 安装目录并启动 redis 服务即可，备份数据会直接加载。

2. AOF（Append Of File）

RDB快照不是很持久。如果运行 Redis 的计算机停止运行，电源线出现故障或者您 kill -9 的实例意外发生，则写入 Redis 的最新数据将丢失。

2.1 原理

AOF（Append Of File） 是以 日志 的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来( 读操作不记录 ) ， 只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

2.2 AOF流程图

1. 客户端的请求写命令会被append追加到AOF缓冲区内；


2. AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；


3. AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；


4. Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；

2.3 AOF相关配置

2.3.1 AOF启动配置

配置文件默认关闭AOF，将配置文件设置为 appendonly yes 启动AOF。

AOF和RDB同时开启，系统默认取AOF的数据（数据不会存在丢失）

2.3.2 AOF 同步fsync频率设置

• appendfsync always始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好


• appendfsync everysec每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。


• appendfsync noredis不主动进行同步，把同步时机交给操作系统。

借助 glibc 提供的 fsync(int fd) 函数来讲指定的文件内容 强制从内核缓存刷到磁盘。但  "强制开车"  仍然是一个很消耗资源的一个过程，需要  "节制" ！通常来说，生产环境的服务器，Redis 每隔 1s 左右执行一次 fsync 操作就可以了。

Redis 同样也提供了另外两种策略，一个是 永不 fsync，来让操作系统来决定合适同步磁盘，很不安全，另一个是 来一个指令就 fsync 一次，非常慢。但是在生产环境基本不会使用，了解一下即可。

2.3.3 查看appendonly.aof文件

最后一条del non_existing_key没有追加到appendonly.aof文件中，因为它没有对数据实际造成修改

2.4 AOF如何备份

修改默认的appendonly no，改为yes

2.4.1 正常恢复

1. config get dir  查询rdb文件的目录


2. 关闭Redis


3. 将备份文件 appendonly.aof 移动到 redis 安装目录并启动 redis 服务即可，备份数据会直接加载。

2.4.2 异常恢复

1. 如遇到AOF文件损坏，通过/usr/local/bin/redis-check-aof--fix appendonly.aof进行恢复备份被写坏的AOF文件。


2. 恢复：重启redis，备份数据会直接加载。

2.5 Rewrite重写

Redis 在长期运行的过程中，AOF 的日志会越变越长。如果实例宕机重启，重放整个 AOF 日志会非常耗时，导致长时间 Redis 无法对外提供服务。所以需要对 AOF 日志 "瘦身" 。
Redis 提供了 bgrewriteaof 指令用于对 AOF 日志进行瘦身。其 原理 就是 开辟 (fork) 一个子进程 对内存进行 遍历 转换成一系列 Redis 的操作指令，序列化到一个新的 AOF 日志文件 中。序列化完毕后再将操作期间发生的 增量 AOF 日志 追加到这个新的 AOF 日志文件中，追加完毕后就立即替代旧的 AOF 日志文件了，瘦身工作就完成了。

2.5.1 配置文件

• no-appendfsync-on-rewrite=yes：不写入aof文件只写入缓存，用户请求不会阻塞，但是在这段时间如果宕机会丢失这段时间的缓存数据。（降低数据安全性，提高性能）


• no-appendfsync-on-rewrite=no：还是会把数据往磁盘里刷，但是遇到重写操作，可能会发生阻塞。（数据安全，但是性能降低）

• auto-aof-rewrite-percentage：设置重写的基准值，文件达到100%时开始重写（文件是原来重写后文件的2倍时触发）


• auto-aof-rewrite-min-size：设置重写的基准值，最小文件64MB。达到这个值开始重写。

例如：文件达到70MB开始重写，降到50MB，下次什么时候开始重写？100MB

系统载入时或者上次重写完毕时，Redis会记录此时AOF大小，设为base_size,

如果Redis的AOF当前大小>= base_size +base_size*100% (默认)且当前大小>=64mb(默认)的情况下，Redis会对AOF进行重写。

2.5.2 Rewrit流程图

1. bgrewriteaof触发重写，判断是否当前有bgsave或bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行。


2. 主进程fork出子进程执行重写操作，保证主进程不会阻塞。


3. 子进程遍历redis内存中数据到临时文件，客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。


4. 子进程写完新的AOF文件后，向主进程发信号，父进程更新统计信息。2).主进程把aof_rewrite_buf中的数据写入到新的AOF文件。


5. 使用新的AOF文件覆盖旧的AOF文件，完成AOF重写。

3. 总结

3.1 Redis 4.0 混合持久化

重启 Redis 时，我们很少使用 rdb 来恢复内存状态，因为会丢失大量数据。我们通常使用 AOF 日志重放，但是重放 AOF 日志性能相对 rdb 来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很长的时间。

Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化。将 rdb 文件的内容和增量的 AOF 日志文件存在一起。这里的 AOF 日志不再是全量的日志，而是 自持久化开始到持久化结束 的这段时间发生的增量 AOF 日志，通常这部分 AOF 日志很小，于是在 Redis 重启的时候，可以先加载 rdb 的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重启效率因此大幅得到提升。

3.2 官方建议

• 官方推荐两个都启用。


• 如果对数据不敏感，可以选单独用RDB。


• 不建议单独用 AOF，因为可能会出现Bug。


• 如果只是做纯内存缓存，可以都
  
  作者：芒猿君
  来源：juejin.cn/post/7249382407245037623
  不用。

背景

我们编写的Web项目部署之后，经常会因为需要进行配置变更或功能迭代而重启服务，单纯的kill -9 pid的方式会强制关闭进程，这样就会导致服务端当前正在处理的请求失败，那有没有更优雅的方式来实现关机或重启呢？

优雅停机

在项目正常运行的过程中，如果直接不加限制的重启可能会发生一下问题

1. 项目重启（关闭）时，调用方可能会请求到已经停掉的项目，导致拒绝连接错误（503），调用方服务会缓存一些服务列表导致，服务列表依然还有已经关闭的项目实例信息


2. 项目本身存在一部分任务需要处理，强行关闭导致这部分数据丢失，比如内存队列、线程队列、MQ 关闭导致重复消费

为了解决上面出现的问题，提供以下解决方案：

1. 关于问题 1 采用将需要重启的项目实例，提前 40s 从 nacos 上剔除，然后再重启对应的项目，保证有 40s 的时间可以用来服务发现刷新实例信息，防止调用方将请求发送到该项目


2. 使用 Spring Boot 提供的优雅停机选项，再次预留一部分时间


3. 使用 shutdonwhook 完成自定的关闭操作

一、主动将服务剔除

该方案主要考虑因为服务下线的瞬间，如果 Nacos 服务剔除不及时，导致仍有部分请求转发到该服务的情况

在项目增加一个接口，同时在准备关停项目前执行 stop 方法，先主动剔除这个服务，shell 改动如下：

run.sh

function stop()  

{  

    echo "Stop service please waiting...."  

    echo "deregister."  

    curl -X POST "127.0.0.1:${SERVER_PORT}/discovery/deregister"  

    echo ""  

    echo "deregister [${PROJECT}] then sleep 40 seconds."  

    # 这里 sleep 40 秒，因为 Nacos 默认的拉取新实例的时间为 30s, 如果调用方不修改的化，这里应该最短为 30s

    # 考虑到已经接收的请求还需要一定的时间进行处理，这里预留 10s, 如果 10s 还没处理完预留的请求，调用方肯定也超时了  

    # 所以这里是 30 + 10 = 40sleep 40  

    kill -s SIGTERM ${PID} 

    if [ $? -eq 0 ];then  

        echo "Stop service done."

    else  

        echo "Stop service  failed!"  

    fi

}

在项目中增加 /discovery/deregister 接口

Spring Boot MVC 版本

import lombok.extern.slf4j.Slf4j;  

import org.springframework.beans.factory.annotation.Autowired;  

import org.springframework.cloud.client.serviceregistry.Registration;  

import org.springframework.cloud.client.serviceregistry.ServiceRegistry;  

import org.springframework.context.annotation.Lazy;  

import org.springframework.web.bind.annotation.PostMapping;  

import org.springframework.web.bind.annotation.RequestMapping;  

import org.springframework.web.bind.annotation.RestController;  

  

@SuppressWarnings("SpringJavaAutowiredFieldsWarningInspection")  

@RestController  

@RequestMapping("discovery")  

@Slf4j  

public class DeregisterInstanceController {  

  

	@Autowired

	@Lazy  

	private ServiceRegistry serviceRegistry;  

  

	@Autowired  

	@Lazy  

	private Registration registration;  

  

	

	@PostMapping("deregister")  

	public ResultVO<String> deregister() {  

		log.info("deregister serviceName:{}, ip:{}, port:{}",  

		registration.getServiceId(),  

		registration.getHost(),  

		registration.getPort());  

		try {  

			serviceRegistry.deregister(registration);  

		} catch (Exception e) {  

			log.error("deregister from nacos error", e);  

			return ResultVO.failure(e.getMessage());  

		}  

            return ResultVO.success();  

	}

}

Spring Cloud Gateway

通过使用 GatewayFilter 方式来处理

package com.br.zeus.gateway.filter;  

  

import static org.springframework.cloud.gateway.support.ServerWebExchangeUtils.isAlreadyRouted;  

  

import com.alibaba.fastjson.JSON;  

import com.br.zeus.gateway.entity.RulesResult;  

import lombok.extern.slf4j.Slf4j;  

import org.springframework.beans.factory.annotation.Autowired;  

import org.springframework.cloud.client.serviceregistry.Registration;  

import org.springframework.cloud.client.serviceregistry.ServiceRegistry;  

import org.springframework.cloud.gateway.filter.GatewayFilter;  

import org.springframework.cloud.gateway.filter.GatewayFilterChain;  

import org.springframework.context.annotation.Lazy;  

import org.springframework.core.Ordered;  

import org.springframework.core.io.buffer.DataBuffer;  

import org.springframework.http.HttpStatus;  

import org.springframework.http.MediaType;  

import org.springframework.http.server.reactive.ServerHttpResponse;  

import org.springframework.stereotype.Component;  

import org.springframework.web.server.ServerWebExchange;  

import reactor.core.publisher.Mono;  

  

@SuppressWarnings("SpringJavaAutowiredFieldsWarningInspection")  

@Component  

@Slf4j  

public class DeregisterInstanceGatewayFilter implements GatewayFilter, Ordered {  

  

	@Autowired  

	@Lazy  

	private ServiceRegistry serviceRegistry;  

  

	@Autowired  

	@Lazy  

	private Registration registration;  

  

	public DeregisterInstanceGatewayFilter() {  

		log.info("DeregisterInstanceGatewayFilter 启用");  

	}  

  

	@Override  

	public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {  

		if (isAlreadyRouted(exchange)) {  

			return chain.filter(exchange);  

		}  

  

		log.info("deregister serviceName:{}, ip:{}, port:{}",  

		registration.getServiceId(),  

		registration.getHost(),  

		registration.getPort());  

  

		RulesResult result = new RulesResult();  

		try {  

			serviceRegistry.deregister(registration);  

			result.setSuccess(true);  

		} catch (Exception e) {  

			log.error("deregister from nacos error", e);  

			result.setSuccess(false);  

			result.setMessage(e.getMessage());  

		}  

		  

		ServerHttpResponse response = exchange.getResponse();  

		response.getHeaders().setContentType(MediaType.APPLICATION_JSON_UTF8);  

		DataBuffer bodyDataBuffer = response.bufferFactory().wrap(JSON.toJSONBytes(result));  

		response.setStatusCode(HttpStatus.OK);  

		return response.writeWith(Mono.just(bodyDataBuffer));  

	}  

  

	@Override  

	public int getOrder() {  

		return 0;  

	}  

}

在路由配置时，增加接口和过滤器的关系

.route("DeregisterInstance", r -> r.path("/discovery/deregister")  

	.filters(f -> f.filter(deregisterInstanceGatewayFilter))  

	.uri("https://example.com"))

二、Spring Boot 自带的优雅停机方案

要求 Spring Boot 的版本大于等于 2.3

在配置文件中增加如下配置：

application.yaml

server:  

	shutdown: graceful

spring:

  lifecycle:

    timeout-per-shutdown-phase: 10s

当使用 server.shutdown=graceful 启用时，在 web 容器关闭时，web 服务器将不再接收新请求，并将等待活动请求完成的缓冲期。使用 timeout-per-shutdown-phase 配置最长等待时间，超过该时间后关闭

三、使用 ShutdownHook

public class MyShutdownHook {

    public static void main(String[] args) {

        // 创建一个新线程作为ShutdownHook

        Thread shutdownHook = new Thread(() -> {

            System.out.println("ShutdownHook is running...");

            // 执行清理操作或其他必要的任务

	        // 1. 关闭 MQ

	        // 2. 关闭线程池

	        // 3. 保存一些数据

        });



        // 注册ShutdownHook

        Runtime.getRuntime().addShutdownHook(shutdownHook);



        // 其他程序逻辑

        System.out.println("Main program is running...");



        // 模拟程序执行

        try {

            Thread.sleep(5000); // 假设程序运行5秒钟

        } catch (InterruptedException e) {

            e.printStackTrace();

        }



        // 当程序退出时，ShutdownHook将被触发执行

    }

}
作者：双鬼带单
来源：juejin.cn/post/7249286832168566840

35岁是一个让程序员感到焦虑的年龄。这个年纪往往意味着成熟和稳定，但在技术领域，35岁可能意味着过时和被淘汰。在这篇文章中，我将探讨35岁程序员的思考，以及如何应对这种感受，这里我不想贩卖焦虑，只是对现实的一些思考。

当我在20多岁研究生刚刚毕业的时候，恰逢互联网蓬勃发展，到处都是机会，那时候年轻气盛，我充满了能量和热情。我渴望学习新的技术和承担具有挑战性的项目。我花费了无数的时间编码、测试和调试，常常为了追求事业目标而牺牲了个人生活。

慢慢的当我接近30岁的时候，我开始意识到我的优先事项正在转变。我在职业生涯中取得了很多成就，但我也想专注于我的个人生活和关系。我想旅行、和亲人朋友共度时光，并追求曾经被工作忽视的爱好。

现在，35岁的我发现自己处于一个独特的位置。我在自己的领域中获得了丰富的经验，受到同事和同行的尊重。然而，我也感到一种不安和渴望尝试新事物的愿望。这时候我很少在代码上花费时间，而是更多的时间花到了项目管理上，一切似乎很好，但是疫情这几年，行业了很大的影响，公司的运营也变得步履维艰，在安静的会常常想到未来的的规划。

一、焦虑情绪的来源

35岁程序员的焦虑情绪源于其所处的行业环境。技术不断发展，新的编程语言、框架、工具层出不穷，要跟上这些变化需要付出大量的时间和精力。此外，随着年龄的增长，身体和心理健康也会面临各种问题。这些因素加在一起，让35岁程序员感到无从下手，不知道该如何面对未来。

二、面对焦虑情绪的方法

1学习新技能

学习新技能是应对技术革新的必经之路。与其等待公司提供培训或者等待机会，35岁程序员应该主动寻找新技术，并投入时间和精力去学习。通过参加课程、阅读文献，甚至是找到一位 mentor，35岁程序员可以更快地适应新技术，保持竞争力。

2关注行业动态

35岁程序员要时刻关注技术行业的最新动态。阅读技术博客、参加社区活动，以及了解公司的发展方向和战略规划，这些都是成为行业领跑者所必须的。通过增强对行业趋势的了解，35岁程序员可以更好地做出决策，同时也可以通过分享经验获得他人的认可和支持。

3 与年轻人合作

与年轻的程序员合作可以带来许多好处。他们可能拥有更新的知识和技能，并且乐于探索新事物。35岁的程序员应该通过与年轻人合作，学习他们的思考方式和方法论。这样不仅可以加速学习新技能，还可以提高自己的领导能力。

每周我都会组织公司内部的技术交流活动，并积极号召大家发表文章，通过这些技术分享，我发现每个人擅长的东西不同，交流下来大家的收获都很大。

4重新审视个人价值观

在35岁之后，程序员可能会重新审视自己的职业生涯和个人发展方向。当面临焦虑情绪时，建议去回顾一下自己的愿景和目标。这有助于确定下一步的工作方向和计划。此外，35岁程序员也应该考虑个人的非技术技能，例如领导力、沟通能力和团队合作精神，这些技能对长期职业成功至关重要。

5 敞开心扉学会沟通

 程序员给大家的一个刻板印象就是不爱沟通，刻板木讷，大家都是干活的好手，但是一道人际关系处理上就显得有些不够灵活，保持竞争力的一个很关键的点也在于多沟通，多社交，让自己显得更有价值，有一句老话说的好：多一个朋友，多一条路。沟通需要技巧，交朋友更是，这也是我们需要学习的。

三、总结

35岁是程序员生涯中的一个重要节点，同时也是一个充满挑战和机会的时期。如何应对焦虑情绪，保持竞争力并保持个人发展的连续性，这需要程序员深入思考自己的职业规划和发展方向。

通过学习新技能、关注行业动态、与年轻人合作以及审视个人价值观，35岁程序员可以在未来的职业生涯中不断成长和发展。

归根到底，无论如何生活的好与坏都在于我们对待生活的态度，幸福是一种感受，相由心生，无论你处于何种生活状态，

都希望大家向阳而生。

今天又学习了一个装X概念——句柄，看字面意思，感觉跟某种器具有关，但实际上，这个词可不是用来打造家居用品的。

相信不少人跟我一样，第一眼看到这个词，脑海里只有一个大大的问号。不过，没关系，我们可以一起学习，毕竟，装X路上永远没有止境。

1、官方一点儿的定义

在计算机科学中，句柄（Handle）是一种引用或标识对象的方式，它可以用来访问或操作底层系统资源。

不同的操作系统可能会有不同的实现和用途，下面我将以不同的操作系统为例来解释句柄的意义。

1. Windows操作系统

在 Windows 中，句柄是一种整数值，用于标识和访问系统对象或资源，如窗口、文件、设备等。

句柄充当了对象的唯一标识符，通过句柄可以对对象进行操作和管理。

示例代码（C++）：

HWND hWnd = CreateWindow(L"Button", L"Click Me", WS_VISIBLE | WS_CHILD, 10, 10, 100, 30, hWndParent, NULL, hInstance, NULL);

if (hWnd != NULL) {

    // 使用句柄操作窗口对象

    ShowWindow(hWnd, SW_SHOW);

    UpdateWindow(hWnd);

    // ...

}

在上述代码中，通过 CreateWindow 函数创建一个按钮窗口，并将返回的句柄存储在 hWnd 变量中。然后，可以使用 hWnd 句柄来显示窗口、更新窗口等操作。

2. Linux操作系统

在 Linux 中，句柄通常称为文件描述符（File Descriptor），它是一个非负整数，用于标识打开的文件、设备、管道等。

Linux将所有的I/O操作都抽象为文件，并使用文件描述符来引用和操作这些文件。

示例代码（C）：

int fd = open("file.txt", O_RDONLY);

if (fd != -1) {

    // 使用文件描述符读取文件内容

    char buffer[1024];

    ssize_t bytesRead = read(fd, buffer, sizeof(buffer));

    // ...

    close(fd);

}

上述代码中，通过 open 函数打开文件 file.txt，并将返回的文件描述符存储在 fd 变量中。然后，可以使用 fd 文件描述符来进行文件读取等操作。

3. macOS操作系统

在 macOS 中，句柄也称为文件描述符（File Descriptor），类似于 Linux 操作系统的文件描述符。它是一个整数，用于标识和访问打开的文件、设备等。

示例代码（Objective-C）：

int fileDescriptor = open("/path/to/file.txt", O_RDONLY);

if (fileDescriptor != -1) {

    // 使用文件描述符读取文件内容

    char buffer[1024];

    ssize_t bytesRead = read(fileDescriptor, buffer, sizeof(buffer));

    // ...

    close(fileDescriptor);

}

在上述代码中，通过 open 函数打开文件 /path/to/file.txt，并将返回的文件描述符存储在 fileDescriptor 变量中。然后，可以使用 fileDescriptor 文件描述符来进行文件读取等操作。

总结起来，句柄（Handle）是一种在操作系统中用于标识、访问和操作系统资源的方式。

不同的操作系统有不同的实现和命名，如 Windows 中的句柄、Linux 和 macOS 中的文件描述符。句柄提供了一种抽象层，使得程序可以使用标识符来引用和操作底层资源，从而实现对系统资源的管理和控制。

2、通俗易懂的理解

可以把句柄理解为一个中间媒介，通过这个中间媒介可控制、操作某样东西。

举个例子。door handle 是指门把手，通过门把手可以去控制门，但 door handle 并非 door 本身，只是一个中间媒介。

又比如 knife handle 是刀柄，通过刀柄可以使用刀。

跟 door handle 类似，我们可以用 file handle 去操作 file, 但 file handle 并非 file 本身。这个 file handle 就被翻译成文件句柄，同理还有各种资源句柄。

3、为什么要发明句柄？

句柄的引入主要是为了解决以下几个问题：

1. 
   

   资源标识：操作系统中存在各种类型的资源，如窗口、文件、设备等。为了标识和引用这些资源，需要一种统一的方式。句柄提供了一个唯一的标识符，可以用于识别特定类型的资源。

   
   


2. 
   

   封装和抽象：句柄将底层资源的具体实现进行了封装和抽象，提供了一种更高层次的接口供应用程序使用。这样，应用程序不需要了解资源的内部细节和底层实现，只需要通过句柄进行操作。

   
   


3. 
   

   安全性和隔离：句柄可以充当一种权限验证的机制，通过句柄来访问资源可以进行权限检查，从而保证了资源的安全性。此外，句柄还可以实现资源的隔离，不同句柄之间的资源操作互不影响。

   
   


4. 
   

   跨平台和兼容性：不同的操作系统和平台有各自的资源管理方式和实现，句柄提供了一种统一的方式来操作不同平台上的资源。这样，应用程序可以在不同的操作系统上运行，并使用相同的句柄接口来访问资源。

   
   

总之，句柄提供了一种统一、封装、安全和跨平台的解决方案，使得应用程序可以更方便地操作和管理底层系统资源。

好了，看完以上内容你也许会感叹：句柄？这不就是个把手吗！但是，别小瞧这个

把手，它可是万能的！

用户周期

对于我们各个平台来说（掘金也是），我们用户都会有一个生命周期：引入期--成长期--成熟期--休眠期--流失期。

而一般获客就在引入期，在这个时候我们会通过推广的手段进行拉新；升值期则发生在成长期和成熟期，在两个阶段，我们会通过各种裂变营销（比如红包、券、积分、满减等手段）去实现用户的转化；那到了休眠期和流失期，平台则会通过精准营销去实现用户的留存。

详细的表格可以看下面：

运营手法

讲完了用户周期，我们再来说一下运营手法（让大家做一只明白的羊）。目前比较主流的运营手法包括红包、优惠券、返现、积分、裂变营销、砍价、秒杀......

拼xx新人红包：

饿了X红包：

拼xx砍价

其他我们就不列举了，大家生活中肯定有很多体会。在不同的行业，我们被“安排”的方式是不一样的。我们拿3个行业来举例子：

潜在风险

那从企业的角度出发，在这些环节当中，有可能会出现如下的一些常见风险：客户端风险、账号安全风险、营销活动风险、交易支付风险、爬虫风险。我们一一来过一下这些风险：

1.客户端风险：

2.账户安全风险

3.营销活动风险

4.交易支付风险

5.爬虫风险

黑灰产风险

1.简单介绍

目前我们网络黑灰产的从业人数已经超过1000万（和今年毕业的大学生人数有的一比了），其产业造成的损失每年也已经超过千亿。如今数据泄露已经成为社会问题，也引起了各大企业的重视。并且有个点（可能会被喷），部分的黑灰产的安全攻防人员专业度已经超过我们很多安全技术人员了。毕竟只有千年做贼的，没有千年防贼的。

那在我们的AI技术加持之下，我们后续的黑灰产发展必将和产业链会进一步深度融合，同时目前有一个很显著的特征是：黑灰产正在尝试将自己的攻击行为隐藏在其他用户的行为之。

另外，目前受攻击比较多的行业会包括说电商、出行、政务、直播、广告、游戏、社交等，而分布的场景则是我们前面说的爬虫攻击、薅羊毛、账户风险、交易支付等等。

2.欺诈流程

我们来讲一下黑灰产一般的攻击手段，也就是欺诈的一个流程：

第一步：账号准备。这一步会包括说图里的社工、注册机这些比较常用和典型的，也有其他一些方式。

第二步：情报收集。这一步包括流程的体验以及工具的准备。

第三步：伺机而发。等待活动开始，直接上去薅羊毛

第四步：利益套现。他们会代理或者海鲜市场等等，进行套现。代理的话，游戏行业会用的更多，而海鲜市场，类似于电商的优惠券之类的，会用的比较多。

欺诈工具

目前主流的欺诈工具有如下几种：

1.模拟器：这个主要是针对弱防护的场景

2.设备牧场：现在是应该发展到了第三代全托管牧场。一般可以去做设备识别，针对环境监测和真机检测。

3.接码平台：这个大家应该很熟悉。我们公司做的是安全验证码，而来注册的一部分客户则来找的是接码平台。

4.打码平台：这个其实和接码平台是类似的，不过接码平台针对的是短信验证码，而打码平台针对的是滑动验证码、图片验证码等等。

举个例子：某宝KFC代下单服务泛滥

这块我就不介绍更多了，生怕有人学坏哈哈

防护措施

因为企业目前对这一块都比较重视，所以随之而来的安全产品目前也发展到了一定的阶段。总的来说，目前一般会采取如下的防御体系：

基本是3个平台+3个场景+2个服务

产品一般会组合使用（单个场景针对使用也是可以的），会包括：设备指纹+无感验证+端加固+安全SDK
平台：实施决策平台+智能建模平台+关联网络平台
场景：基本上针对的场景就是我前面说的那些营销场景

方案优势

那通过上面这一套方案，我们可以做到：

事前： 需要在事前事中事后多点进行布控，各环节分别进行防控。

事中： 事中的防控可以将更多的黑名单数据反馈到事前环节的判断。

事前： 事后的分析与建模可以将模型能力赋予事中的风险防控，同时也可以积累大量的黑样本供事前风险防控来使用。

基于标准数据接口进行的模块化组合设计，基于成熟的技术架构和技术优势，可定制、可扩展、可集成、跨平台，在个性化需求的处理方面，有着很好的优势。产品各个模块之间既可相互组合又可自定义配置，灵活的产品配置方式和架构设计思想，可结合不同的业务场景及系统状况进行相应的风险防控方案配置。

结语

在现在AI诈骗频发的时代，其实更受冲击的是金融银行的业务安全，因为我们账号汇款目前用的比较多的是人脸识别，那通过AI换脸，黑灰产完全可以实现相应的技术替换。虽然说这个是用户自己的信息泄露导致的安全问题，但是在问责上，肯定银行也会或多或少受到影响，所以最好是能够有一个合适的风控系统去进行相应的处理。

等端午结束之后吧，有空写一篇关于AI诈骗横行的当下，金融银行要如何应对。<

/p>

以上。

文章已同步至【个人博客】，欢迎访问【我的主页】😃

文章地址：blog.fanjunyang.zone/archives/do…

前言

今天有一个妹纸向我提出了一个问题

是时候"出手"了，本着助人为乐的精神，这个忙必须帮（没办法，我就喜欢帮助别人）

现在我们在下载一些比如：Bilibili，YouTube等第三方视频的时候，还是比较困难的，需要找各种下载器和网站，而且还不一定能下载，一些免费好用的下载网站还不好找。
所以我们可以自己动手搭一个下载站点，来下载各大平台上的视频。

搭建的站点(大家轻点薅)：dl.junyang.space/

站点的地址会随着时间更新，如果上面的地址不能访问的话，大家可以去我的 博客 ，我会把站点入口放在【顶部菜单栏】->【百宝箱】里面)

相关链接&环境配置

最好用国外的服务器，如果用国内的服务器，是下载不了YouTube等需要魔法网站的视频的

docker、docker-compose安装：blog.fanjunyang.zone/archives/de…
Nginx Proxy Manager安装使用：blog.fanjunyang.zone/archives/ng…

使用的GitHub的开源项目：github.com/Rudloff/all…

使用的Docker镜像：hub.docker.com/r/dnomd343/…

搭建方式

创建相关目录

mkdir -p /root/docker_data/alltube

cd /root/docker_data/alltube

创建yml文件

version: '3.3'

services:

    alltube:

        restart: always

        container_name: alltube

        environment:

            # 自己网站的title

            - 'TITLE=My Alltube Site'

            - CONVERT=ON

            - STREAM=ON

            - REMUX=ON

        ports:

            # 左侧端口号换成你服务器上未使用的端口号

            - '24488:80'

        image: dnomd343/alltube

运行yml文件

进入/root/docker_data/alltube文件夹下面，运行命令：docker-compose up -d

或者在任意文件夹下面，运行命令：docker-compose -f /root/docker_data/alltube/docker-compose.yml up -d

访问使用

可以直接使用【IP + PORT】的方式访问（需要放通对应端口号的防火墙或安全组）

最好配置反向代理，用域名访问，可以参考：blog.fanjunyang.zone/archives/ng…

她对我说

当我把下载链接发给她时，她说：你真是个好人，正好我让我男朋友也用一下。

我不能忍，然后我默默的把站点删除、下线，眼里留下了悔恨的泪水。

注意事项&问题

• 目前解析不出来B站的视频封面（YouTube可以正常解析），不过不影响下载


• 因为B站音视频是分开的，所以需要下载两次（一次视频、一次音频），然后整合一下就好了


• 因国内版权限制的原因，部分资源无法解析是正常现象


• 下载的时候可以选择视频格式

腾小云导读

PC Web 端、手机 H5 端、小程序端、App 安卓端、App iOS 端......在多端时代，一个应用往往需要支持多端。若每个端都独立开发一套系统来支持，将消耗巨大的人力和经费！腾讯视频团队想到一个“偷懒”的方法——能不能只开发一套基础系统，通过兼容不同平台的特性，来快速编译出不同平台的应用呢？本篇特邀腾讯视频团队为你分享快速编译出支持多端的应用、一套代码行走天下的“偷懒”历程。欢迎阅读。

目录

1 背景

2 设计思路

3 具体实现

4 总结

01、 背景

腾讯视频搜索在多个端都存在：安卓 App 端搜索、iOS App 端搜索、H5 端搜索、小程序端搜索、PC Web 端、PC 客户端搜索。每个端，除了个别模块的样式有细微差异之外，其他都一样，如下面的图片所示。

按照以前的现状，安卓 App 端搜索一套代码、iOS App 端搜索一套代码、手机 H5 端一套代码、小程序端搜索一套代码、PC 客户端一套代码、PC Web 端一套代码......每套代码都是独立开发，独立维护，成本非常高。并且，后端的搜索接口以前也是分散在多个不同的协议中，有的平台是 jce 协议的接口，有的是 PB 协议的接口，也是五花八门。

随着业务增长的需求，我们已经没有足够的时间来维护各自一套独立的系统，我们打算进行升级改革！治理的办法就是：收敛！把后端不同平台的接口都归一到同一个接口中，通过平台号来区分；前端也将不同平台的代码，收敛归一成一套代码，通过条件编译来兼容适配不同平台的差异性，不同的平台，在蓝盾流水线中配置不同的参数来上线，从而达到多合一的效果。

总体来说，我们团队就实现一个“多端合一的万能模板”的想法达成一致。并且，我们希望使用 hippy-vue 技术栈。

理由有以下：

Hippy 是公司级别的中台框架，有专门的团队在进行问题的修复和功能的迭代开发，并且广泛应用到了很多公司级的应用中，暂时不会出现“荒芜丢弃”的局面； Hippy 是为了抹平 iOS、Android 双端差异，提供接近 Web 的开发体验而生，在上层支持了 React 和 Vue 两套界面框架，前端开发人员可以通过它，将前端代码转换为终端的原生指令，进行原生终端 App 开发； Hippy 在底层进行了大量的优化，使利用 Hippy 框架开发的终端 App 应用，在启动速度，可复用列表组件、渲染效率、动画速度、网络通信等方面都提供了业内顶尖的性能表现，值得信赖； Hippy 在上层支持 Vue 技术栈，正好我们团队目前所有的前端项目也都统一为 Vue 技术栈，开发人员上手毫无违和感。

02、设计思路

系统的架构图如下所示：

通用模版为了简化开发、提高开发效率，在模版中集成了大量现有组件和工具包，具体可以分为以下三层：

• 第三方工具层

在通用工具库中，模版包装并提供了很多常用方法，比如 cookie 的设置和 cookie 的获取方法；DOM 的操作方法；Cache 的设置，Cache 的获取，Cache 的过期时间等。在第三方接入库中，模版已经接好了 Aegis 监控，Tab 实验的实验值获取，大同上报等；在打包编译库中，模版提供了通用的 Hippy App 打包安卓脚本和 IOS 脚本、H5 的打包脚本、小程序地打包脚本、一套代码，运行不同的打包命令，执行不同的编译打包脚本，就可以生成不同平台对应的发布包。编译打包在后续还会详细讲解。

• 数据管理层

在这层中，模版集成了跟数据处理相关的模块。

在 Store 层，由于该模块是基于 Vue2 实现的（Vue3 会在下一个版本中提供），模版已经集成好了 Vuex、State、Getters、Mutations、Actions 等，并且都有实例代码（该模版是基于 Vue2 实现的，Vue3 会在下一个版本中提供）；

在 Model 层，模版提供了一套将 PB 文件转化为 TS 类文件的方法，方便快速接入后端PB协议接口请求；同时，还包装了接口通用请求方法，以及全局的统一错误处理上报方法；在数据配置中，模版提供了全局的常量配置文件，应用的版本配置文件（版本的配置对 Hippy App 的应用非常实用），以及 UI 样式的配置（正常模式样式还是暗黑模式样式，宽屏，窄屏等）。

• UI 层

为了提高开发速度，提高开发效率，模版提供了示例页面代码。同时，根据脚手架来选择是否需要路由，来动态添加应用的路由；以及常用的基础组件库。这些组件库中的组件，是从众多 Hippy 应用中提取出来，实用又高效。

03、具体实现

本文将从 Hippy App 端实现，Hippy H5 端的实现和 Hippy 微信小程序端端实现来分别展开介绍。

下图是 Hippy App 端实现逻辑。

App 端的入口文件为 main-native.ts。在里面，声明了一个 App 实例，指定 phone 下的一些属性设置，比如状态栏、背景色等等。同时，需要用到的 native 组件，都需要在 main-native 中进行声明绑定，才可以在页面中使用。

例如：下图示例中注册声明了两个 native 组件，LottieView 和 VideoView，在页面中就可以直接使用这两个 native 组件。

Vue.registerElement('LottieView');

Vue.registerElement('VideoView', {

  component: {

    name: 'VideoView',

    processEventData(event: any, nativeEventName: string, nativeEventParams: any) {

      // To do something for the native component event

      return event;

    },

  },});

main-native 中还有一个重要的方法：app.$start() 方法。

该方法为 Hippy 引擎初始化完成后回调到 Hippy 前端的方法；Hippy 端跟 App 方法进行通信，通过 jsbridge 来进行，模版中已经封装好了具体方法；Hippy 请求后端接口，通过 fetch 协议，也有具体的协议方法封装；Hippy 在 App 内部的跳转，是通过伪协议跳转来实现的。

Hippy App 应用的部署分为以下三种情况：

• 本地调试

本地调试是通过 Hippy + Chrome Devtools 来完成，通过 WS 通道转发消息，具体流程如下图。

• 部署测试环境

模版中引入了环境变量参数，同时在代码模版中做了大量环境变量的兼容逻辑，比如测试环境用测试环境的接口，正式环境用正式环境的接口；测试环境用测试环境的 CDN，静态文件上传到测试环境，测试环境部署测试环境的离线包等；测试环境的调试我们是通过离线包的方式来实现的，有专门的测试环境流水线接入使用，只需要稍微做少许调整即可，有需要的可以私聊。

• 部署正式环境

正式环境流程会做这样几件事情：正式环境接口、正式环境的 CDN、正式环境的日志上、部署正式环境的离线包平台、图片的特殊处理。因为 App 端是采用离线包的形式，如果所有本地图片都打包到离线包中，会导致离线包包体积很大，会影响到 App 的整体体积大小和离线包的下载速度。模版中做了针对图片的特殊脚本处理：引入了图片编译大小变量：STATIC_SIZE_LIMIT。当大于该限制条件的图片都一律上传到 CDN，如果想保留的，则需要增加特殊声明：inline。

具体流程如下图所示：

Hippy H5 的实现流程如下图所示。

Hippy H5 的实现跟 App 的实现流程类似，但是差异如下：

App 的入口文件为 main-native.ts，h5 的入口文件为 main.ts 文件。H5 的入口文件中，没有关于 iphone 的设置，跟 Web 的设置一样；H5 的路由用 vue-router，页面中的路由跳转都是 H5 超链接，不是伪协议；H5 的本地调试很简单，跟 Vue Web 一样，都是在本地起 http-server 来测试；测试环境的部署和正式环境的部署都是采用的服务器来部署，不是离线包。

这里重点讨论一下大同上报的实现。大同上报在 App 端的上报参数声明跟 H5 端的上报参数声明不一致，如何统一这些差异？模版中的解决方案是：封装自定义标签 Directive。

具体实现如下：在 Directive 标签中兼容 App 和 H5 的不一致。

/**

* @example

*

* <element v-report="elementReportInfo" />

* <element v-report="{ eid, ...extra }" />

* <page v-report="{ pgid, ...extra }" />

* <page v-report.page="assertPageReport" />

*/



Vue.directive('report', {

  bind(el) {

    el.addEventListener('layout', throttledForceReport);

  },

  unbind(el) {

    el.removeEventListener('layout', throttledForceReport);

  },

  inserted: setReport,

  update: setReport,

} as DirectiveOptions);

很多人可能会问，Hippy App 跟 Hippy H5 有很多不同的地方，如果写两套代码，会不会导致代码的体积变得很大？答案是一定的，为了解决以上问题，该万能模版提供了条件编译。引入环境变量：isNative。然后，根据该条件，进行条件编译，不同的平台，生成不同平台的代码，避免了生成大量冗余代码。

Hippy 微信小程序的实现流程如下图所示：

小程序的实现是基于 Taro Vue 框架。该框架跟 Hippy Vue 框架天然兼容，但是也有一些小程序的特殊地方：

小程序的入口文件约定为 app.ts，创建 app 实例是在 app.ts 中来完成；小程序的主页面文件为 app.vue，在其中定义小程序的状态栏，标题栏，页面等；小程序的全局配置在 app.config.ts 中；小程序的构建脚本在 script 中的 index.js。小程序的代码是基于 Hippy Vue 的代码通过 Taro 自动构建转化而成，很多配置都是自动生成的，只需要在开发的时候，遵循约定的命名规范即可。

为了一套代码能够同时支持 App，H5 和微信小程序，需要遵循一些约定的规范，否则在从 Hippy Vue 转化为 Taro Vue 的时候会遇到一些问题：

文件夹命名规范：全部小写加“-”， 例如：node-redis, agent-base 等，不要用大驼峰等；文件的命名规范：跟文件夹命名规范一致，全部小写加“-”，例如：eslint-recomment.js；属性的命名：也采用小写加“-”， 例如：data-url。

04、总结

目前该模版已经在腾讯视频的搜索场景落地，并且上线应用，但是，还是有一些需要共同打磨的地方：

Vue3 的支持：目前我们是基于 Hippy Vue2 来实现的。随着 Vue3 的广泛应用，后续我们需要升级到 Vue3。

组件丰富：通用组件的种类还不是特别丰富，只是基于我们腾讯视频搜索场景进行的封装，后续可以补充更多更丰富的组件。

迭代升级：通用组件目前还是通过源代码的方式存放在代码模版中，不利于后续组件的升级迭代。计划后续会把组件给迁移到我们的应用组件库平台 Athena，该平台我们会后续发专文介绍，大家敬请期待。

以上是本次分享全部内容，如果觉得文章还不错的话欢迎分享~

-End-

原创作者｜熊才刚

技术责编｜陈恕胜

你有什么开发提效小技巧？欢迎在腾讯云开发者公众号评论区中分享你的经验和看法。我们将选取1则最有意义的分享，送出腾讯云开发者-文化衫1件（见下图）。6月21日中午12点开奖。

面试经历

（后来别人跟我说这种写法nacos里也常见）

记录一次面试经历

2023.06.01

美团海笔的，本来以为笔的情况也不咋好 看到牛客网上一堆ak说没面试机会的

结果也不知怎地到了一面

（略过自我介绍和项目介绍~）

面试官：会写单例吗，写个单例看看

我：

// 饿汉式

public class SingleObject {

   private static SingleObject instance = new SingleObject();

 

   //让构造函数为 private

   private SingleObject(){}



   public static SingleObject getInstance(){

      return instance;

   }

}

面试官：嗯 你这个单例在没有引用的时候就创建了对象？优化一下

我：应该是懒汉模式！

public class Singleton {  

    private static Singleton instance;  

    private Singleton (){}  

  

    public static Singleton getInstance() {  

        // 多了一个判断是否为null的过程

        if (instance == null) {  

            instance = new Singleton();  

        }  

        return instance;  

    }  

}

面试官：你这个线程不安全啊 再优化一下？

我：那就加个锁吧

public class Singleton {  

    private static Singleton instance;  

    private Singleton (){}  

    public static synchronized Singleton getInstance() {  

        if (instance == null) {  

            instance = new Singleton();  

        }  

        return instance;  

    }  

}

面试官：这种写法 多线程来了的话会阻塞在一起 能否再优化？

我：。。。 不会了

面试官：回去看看双检锁单例

···

之后问了数据库事务

1. 读未提交（read uncommitted）


2. 读已提交（read committed）


3. 可重复读（repeatable read）


4. 序列化（serializable）以及默认是哪个（repeatable read） 、

数据库的范式了解吗 等等

不出意外：

还是非常可惜的 这次机会 再加油吧

单例模式整理

学习自菜鸟教程

1.饿汉式

懒加载 no
多线程安全 yes
缺点：没有实现懒加载，即还未调用就创建了对象

public class Singleton {  

    private static Singleton instance = new Singleton();  

    private Singleton (){}  

    public static Singleton getInstance() {  

    return instance;  

    }  

}

2.懒汉式（线程不安全）

懒加载 yes
多线程安全 no

public class Singleton {  

    private static Singleton instance;  

    private Singleton (){}  

  

    public static Singleton getInstance() {  

        if (instance == null) {  

            instance = new Singleton();  

        }  

        return instance;  

    }  

}

3.懒汉式（线程安全）

懒加载 yes
多线程安全 yes
缺点：和面试官说的那样，多线程访问会阻塞

public class Singleton {  

    private static Singleton instance;  

    private Singleton (){}  

  

    public static Singleton getInstance() {  

        if (instance == null) {  

            instance = new Singleton();  

        }  

        return instance;  

    }  

}

4.双检锁/双重校验锁（DCL，即 double-checked locking）

public class Singleton {  

    private volatile static Singleton singleton;  

    private Singleton (){}  

    public static Singleton getSingleton() {  

    if (singleton == null) {  

        synchronized (Singleton.class) {  

            if (singleton == null) {  

                singleton = new Singleton();  

            }  

        }  

    }  

    return singleton;  

    }  

}

这段代码是一个单例模式的实现，使用了双重检查锁定的方式来保证线程安全和性能。双重检查锁定是指在加锁前后都进行了一次判空的操作，以避免不必要的加锁操作。

而为了保证双重检查锁定的正确性，需要使用volatile关键字来修饰singleton变量，以禁止指令重排序优化。（JUC的知识串起来了！）如果没有volatile关键字修饰，可能会出现一个线程A执行了new Singleton()但是还没来得及赋值给singleton，而此时另一个线程B进入了第一个if判断，判断singleton不为null，于是直接返回了一个未初始化的实例，导致程序出错。

使用volatile关键字可以确保多线程环境下的可见性和有序性，即一个线程修改了singleton变量的值，其他线程能够立即看到最新值，并且编译器不会对其进行指令重排序优化。这样就能够保证双重检查锁定的正确性。

学到了 ！！！

后来别人提醒：

（牛逼。。）

5.登记式/静态内部类

public class Singleton {  

    private static class SingletonHolder {  

    private static final Singleton INSTANCE = new Singleton();  

    }  

    private Singleton (){}  

    public static final Singleton getInstance() {  

        return SingletonHolder.INSTANCE;  

    }  

}

这段代码是一个单例模式的实现，使用了静态内部类的方式来保证线程安全和性能。静态内部类是指在外部类中定义一个静态的内部类，该内部类可以访问外部类的所有静态成员和方法，但是外部类不能访问内部类的成员和方法。

在这个单例模式的实现中，SingletonHolder就是一个静态内部类，它里面定义了一个静态的、final的、类型为Singleton的变量INSTANCE。由于静态内部类只有在被调用时才会被加载，因此INSTANCE对象也只有在getInstance()方法被调用时才会被初始化，从而实现了懒加载的效果。

由于静态内部类的加载是线程安全的，因此不需要加锁就可以保证线程安全。同时，由于INSTANCE是静态final类型的，因此保证了它只会被实例化一次，并且在多线程环境下也能正确地被发布和共享。

这种方式相对于双重检查锁定来说更加简单和安全，因此在实际开发中也比较常用。

6. 枚举

public enum Singleton {  

    INSTANCE;  

    public void whateverMethod() {  

    }  

}

这段代码是使用枚举类型实现单例模式的一种方式。在Java中，枚举类型是天然的单例，因为枚举类型的每个枚举值都是唯一的，且在类加载时就已经被初始化。

在这个示例代码中，Singleton是一个枚举类型，其中只定义了一个枚举值INSTANCE。由于INSTANCE是一个枚举值，因此它在类加载时就已经被初始化，并且保证全局唯一。在使用时，可以通过Singleton.INSTANCE来获取该单例对象。

需要注意的是，虽然枚举类型天然的单例特性可以保证线程安全和反序列化安全，但是如果需要延迟初始化或者有其他特殊需求，仍然需要使用其他方式来实现单例模式。

7. 容器式单例

Java中可以使用容器来实现单例模式，比如使用Spring框架中的Bean容器。下面是一个使用Spring框架实现单例的示例代码：

1. 定义一个单例类，比如MySingleton：

public class MySingleton {

    private static MySingleton instance;

    private MySingleton() {}

    public static MySingleton getInstance() {

        if (instance == null) {

            instance = new MySingleton();

        }

        return instance;

    }

    public void doSomething() {

        // do something

    }

}

2. 在Spring的配置文件中定义该类的Bean：

<bean id="mySingleton" class="com.example.MySingleton" scope="singleton"/>

3. 在Java代码中获取该Bean：

ApplicationContext context = new ClassPathXmlApplicationContext("spring-config.xml");

MySingleton mySingleton = (MySingleton) context.getBean("mySingleton");

mySingleton.doSomething();

在上面的代码中，我们在Spring的配置文件中定义了一个名为mySingleton的Bean，它的类是com.example.MySingleton，作用域为singleton（即单例）。然后在Java代码中，我们通过ApplicationContext获取该Bean，并调用它的doSomething()方法。

使用Spring框架可以方便地管理单例对象，同时也可以很容易地实现依赖注入和控制反转等功能。

总结完成 继续加油！！！

你好，我是悟空。

最近生产环境遇到一个问题：

现象：创建工单、订单等地方，全都创建数据失败。

初步排查：报错信息为duplicate key，意思是保存数据的时候，报主键 id 重复，而这些 id 都是由雪花算法生成的，按道理来说，雪花算法是生成分布式唯一 ID，不应该生成重复的 ID。

大家可以先猜猜是什么原因。

有的同学可能对雪花算法不熟悉，这里做个简单的说明。

一、雪花算法

snowflake（雪花算法）：Twitter 开源的分布式 id 生成算法，64 位的 long 型的 id，分为 4 部分：

• 1 bit：不用，统一为 0


• 41 bits：毫秒时间戳，可以表示 69 年的时间。


• 10 bits：5 bits 代表机房 id，5 个 bits 代表机器 id。最多代表 32 个机房，每个机房最多代表 32 台机器。


• 12 bits：同一毫秒内的 id，最多 4096 个不同 id，自增模式

优点：

• 毫秒数在高位，自增序列在低位，整个ID都是趋势递增的。


• 不依赖数据库等第三方系统，以服务的方式部署，稳定性更高，生成ID的性能也是非常高的。


• 可以根据自身业务特性分配bit位，非常灵活。

缺点：

• 强依赖机器时钟，如果机器上时钟回拨（可以搜索 2017 年闰秒 7:59:60），会导致发号重复或者服务会处于不可用状态。

看了上面的关于雪花算法的简短介绍，想必大家能猜出个一二了。

雪花算法和时间是强关联的，其中有 41 位是当前时间的时间戳，

二、排查

2.1 雪花算法有什么问题？

既然是雪花算法的问题，那我们就来看下雪花算法出了什么问题：

（1）What：雪花算法生成了重复的 ID，这些 ID 是什么样的？

（2）Why：雪花算法为什么生成了重复的 key

第一个问题，我们可以通过报错信息发现，这个重复的 ID 是 -1，这个就很奇怪了。一般雪花算法生成的唯一 ID 如下所示，我分别用二进制和十进制来表示：

十进制表示：2097167233578045440



二进制表示：0001 1101 0001 1010 1010 0010 0111 1100 1101 1000 0000 0010 0001 0000 0000 0000

找到项目中使用雪花算法的工具类，生成 ID 的时候有个判断逻辑：

当当前时间小于上次的生成时间就会返回 -1，所以问题就出在这个逻辑上面。(有的雪花算法是直接抛异常)

if (timestamp < this.lastTimestamp) {

   return -1;

}

由于每次 timestamp 都是小于 lastTimeStamp，所以每次都返回了 -1，这也解释了为什么生成了重复的 key。

2.2 时钟回拨或跳跃

那么问题就聚焦在为什么当前时间还会小于上次的生成时间。

下面有种场景可能发生这种情况：

首先假定当前的北京时间是 9:00:00。另外上次生成 ID 的时候，服务器获取的时间 lastTimestamp=10:00:00，而现在服务器获取的当前时间 timestamp=09:00:00，这就相当于服务器之前是获取了一个未来时间，现在突然跳跃到当前时间。

而这种场景我们称之为时钟回拨或时钟跳跃。

时钟回拨：服务器时钟可能会因为各种原因发生不准，而网络中会提供 NTP 服务来做时间校准，因此在做校准的时候，服务器时钟就会发生时钟的跳跃或者回拨问题。

2.3 时钟同步

那么服务器为什么会发生时钟回拨或跳跃呢？

我们猜测是不是服务器上的时钟不同步后，又自动进行同步了，前后时间不一致。

首先我们的每台服务器上都安装了 ntpdate 软件，作为 NTP 客户端，会每隔 10 分钟向 NTP 时间服务器同步一次时间。

如下图所示，服务器 1 和 服务器 2 部署了应用服务，每隔 10 分钟向时间服务器同步一次时间，来保证服务器 1 和服务器 2 的时间和时间服务器的时间一致。

每隔 10 分钟同步的设置：

*/10 * * * * /usr/sbin/ntpdate <ip>

另外时间服务器会向 NTP Pool同步时间，NTP Pool 正在为世界各地成百上千万的系统提供服务。 它是绝大多数主流Linux发行版和许多网络设备的默认“时间服务器”。（参考ntppool.org）

那问题就是 NTP 同步出了问题？？

2.4 时钟不同步

我们到服务器上查看了下时间，确实和时钟服务器不同步，早了几分钟。

当我们执行 NTP 同步的命令后，时钟又同步了，也就是说时间回拨了。

ntpdate  <时钟服务器 IP>

在产生事故之前，我们重启过服务器 1。我们推测服务器重启后，服务器因网络问题没有正常同步。而在下一次定时同步操作到来之前的这个时间段，我们的后端服务已经出现了因 ID 重复导致的大量异常问题。

这个 NTP 时钟回拨的偶发现象并不常见，但时钟回拨确实会带了很多问题，比如润秒 问题也会带来 1s 时间的回拨。

闰秒就是通过给“世界标准时间”加（或减）1秒，让它更接近“太阳时”。例如，两者相差超过0.9秒时，就在23点59分59秒与00点00分00秒之间，插入一个原本不存在的“23点59分60秒”，来将时间调慢一秒钟。

为了预防这种情况的发生，网上也有一些开源解决方案。

三、解决方案

（1）方式一：使用美团 Leaf方案，基于雪花算法。

（2）方式二：使用百度 UidGenerator，基于雪花算法

（3）方式三：用 Redis 生成自增的分布式 ID。弊端是 ID 容易被猜到，有安全风险。

3.1 美团的 Leaf 方案

美团的开源项目 Leaf 的方案：采用依赖 ZooKeeper 的数据存储。如果时钟回拨的时间超过最大容忍的毫秒数阈值，则程序报错；如果在可容忍的范围内，Leaf 会等待时钟同步到最后一次主键生成的时间后再继续工作。

重点就是需要等待时钟同步！

3.2 百度 UidGenerator 方案

百度UidGenerator方案不在每次获取 ID 时都实时计算分布式 ID，而是利用 RingBuffer 数据结构，通过缓存的方式预生成一批唯一 ID 列表，然后通过 incrementAndGet() 方法获取下一次的时间，从而脱离了对服务器时间的依赖，也就不会有时钟回拨的问题。

重点就是预生成一批 ID！

Github地址：

https://github.com/baidu/uid-generator

四、总结

本篇通过一次偶发的生产事故，引出了雪花算法的原理、雪花算法的不足、对应的开源解决方案。

雪花算法强依赖服务器的时钟，如果时钟产生了回拨，就会造成很多问题。

我们的系统虽然做了 NTP 时钟同步，但也不是 100% 可靠，而且润秒这种场景也是出现过很多次。鉴于此，美团和百度也有对应的解决方案。

最后，我们的生产环境也是第一次遇到因 NTP 导致的时钟回拨，而且系统中用到雪花算法的地方并不多，所以目前并没有采取以上的替换方案。

https://github.com/Jackson0714/PassJava-Platform/blob/master/passjava-common/src/main/java/com/jackson0714/passjava/common/utils/SnowflakeUtilV2.java

参考资料：

time.geekbang.org/dailylesson…

blog.csdn.net/liangcsdn11…

http://www.jianshu.com/p/2911

10ca6…

随着区块链技术的不断发展，人们对于区块链的应用也越来越广泛。在这个过程中，平行链技术应运而生。那么，什么是平行链呢？

1. 平行链的定义和概念

平行链是一种特定的应用程序数据结构，它是全局一致的，由 Polkadot 中继链的验证节点进行验证] 。它允许交易在专用的 Layer1 区块链生态系统中并行分布和处理，从而显著提高了吞吐量和可扩展性

平行链技术来自于波卡项目。Polkadot 是一个可伸缩的异构多链系统，其本身不提供任何内在的功能应用，主要是连接各个区块链协议，并维护协议通讯有效安全，并保存这些通讯信息。平行链可以作为公共或私有网络运行，可以用于企业或组织运行，可以作为平台运行，让其他人在他们的基础上构建应用程序或作为公共利益平行链，来造福整个 Polkadot 生态系统，以及各种各样的其他模型 。

简单来说，平行链是一种依赖于波卡中继链提供安全性并与其他中继链通信的自主运行的原生区块链。它是一种简单、易扩展的区块链，它的安全性由“主链”提供。

2. 平行链与主链的关系

平行链是一种独立的区块链，它与主链（mainchain）通过双向桥接相连。它允许代币或其他数字资产在主链和平行链之间进行转移。每个平行链都是一个独立的区块链网络，拥有自己的代币、协议、共识机制和安全性

双向桥（two-way bridge）是一种连接两个区块链的技术，它允许资产在两个区块链之间进行转移。有单向（unidirectional）桥和双向（bidirectional）桥两种类型。单向桥意味着用户只能将资产桥接到一个目标区块链，但不能返回其原生区块链。双向桥允许资产在两个方向上进行桥接

平行链和主链保持既独立又连结的关系，在主链之下，它可以拥有自己的超级节点、状态机和原始交易数据。主链可以给平行链做跨链操作，从而形成链条生态系统。

3. 平行链的优势

平行链不仅可以利用系统的共识保证安全，还可以共享原有的生态。它们执行的计算本质上是独立，但又连结在一起。平行链之间有明确的隔离分界线，可以立即执行所有交易，而不用担心和其他链产生冲突。

使用平行链的原因是它能够显著提高吞吐量和可扩展性，并且能够支持多种不同的应用场景。

平行链可以用来运行区块链应用程序，如去中心化应用程序（dapps），并将计算负载从主链上移除，从而帮助扩展区块链。它们还可以与其他扩展解决方案结合使用。尽管平行链看起来是一个有前途的解决方案，但它们增加了区块链设计的复杂性，并且需要大量的努力和投资进行初始设置。由于平行链是独立的区块链，它们的安全性可能会受到损害，因为它们不受主链的保护。另一方面，如果一个平行链被攻击，它不会影响主链，因此它们可以用来试验新的协议和对主链的改进

4. 平行 链的关键特征

平行 链具有许多关键特征。例如，它们可以多条并行处理交易，效率可提升十倍。此外，由于只需要下载平行 链相关的数据，因此相对效率更高，速度更快。这些平行 链开枝散叶，可以打造自己独有的生态系。

5. 平行链的应用实例

目前市场上已经出现了许多基于平行 链技术开发 的项目。例如 Crust Network 是一个激励去中心化云服务 的应用型公 链。其通过对平行 链技术 的应用 ，既完整地保存了项目 的自主发展空间 ，也可更好地拓展项目功能 ，为用户提供更好地使用体验。

6. 平行链的经济政策

针对目前公 链技术自主权较弱 的问题 ，Polkadot 平 行 链 上 的社 区根据自己 的意志治理他们 的网络 ，不受波卡网络管理 的限制 ，拥有绝对 的自主权 。通过分片协议连接 的区块 链网络 ，可较好地实现拓展定制 。而基于 Polkadot 技术应用开发 的 Crust Network 是一个激励去中心化云服务 的应用型公 链。其通过对平行 链技术 的应用 ，既完整地保存了项目 的自主发展空间 ，也可更好地拓展项目功能 ，为用户提供更好地使用体验。from刘金，转载请

注明原文链接。感谢！

在实践中，很多团队对于DevOps 流水线没有很透彻的理解，要不就创建一大堆流水线，要不就一个流水线通吃。实际上，流水线的设计和写代码一样，需要基于“业务场景”进行一定的设计编排，特别是很多通过“开源工具”搭建的流水线，更需要如此（商业的一体化平台大部分已经把设计思想融入自己产品里了）。

• 流水线的设计与分支策略有关


• 流水线的设计与研发活动有关

清晰的代码结构，标准的环境配置，原子化的流水线任务编排，再加上团队的协作纪律，和持续优化的动作，才是真正的践行CI/CD实践

流水线设计原则

1. 确定好变量

• 哪些是构建/部署需要变化的，比如构建参数，代码地址，分支名称，安装版本，部署机器IP等，控制变化的，保证任务的可复制性，不要写很多hardcode进去

2. 流水线变量/命名的规范化

• 标准化的命名，有助于快速复制；有意义的流水线命名，有助于团队新成员快速了解

3. 一次构建，多次部署

• 一次构建，多次部署（多套环境配置+多套构建版本标签）；杜绝相同代码重复打包


• 相似技术栈/产品形态具备共性，通过以上原则可以抽取复用脚本，良好的设计有助于后续的可维护性！

4. 步骤标准化/原子化

• 比如docker build/push, helm build/deploy, Maven构建等动作标准化，避免重复性写各种脚本逻辑


• 根据业务场景组装，例如. 提测场景，每日构建场景，回归测试场景

5. 快速失败

• 尽可能把不稳定的，耗时短的步骤 放在流水线的最前面，如果把一个稳定的步骤放在前面，并且耗时几十分钟，后面的某个步骤挂了，反馈周期就会变长

从零开始设计流水线

流水线分步骤实施, 从 “点” 到 “线” 结合业务需要串起来，适合自己团队协作开发节奏的流水线才是最好的。

1. 对价值流进行建模并创建简单的可工作流程


2. 将 构建 和 部署 流程自动化


3. 将 单元测试和 代码分析 自动化


4. 将 验收测试 自动化


5. 将 发布 自动化

流水线的分层

由于产品本身的形态不同，负责研发的团队人员组成不同，代码的版本管理分支策略不同，使用的部署流水线形式也会各不相同，所以基于实际业务场景设计流水线是团队工程实践成熟的重要标志。

• 🔗 DevOps流水线设计的最佳实践

1. 提交构建流水线（个人级）

适用场景：每名研发工程师都创建了自己专属的流水线（一般对应个人的开发分支），用于个人在未推送代码到团队仓库之前的快速质量反馈。
注意：个人流水线并不会部署到 团队共同拥有的环境中，而是仅覆盖个人开发环节。如图所示，虚线步骤非必选

2. 集成验收流水线（团队级）

适用场景：每个团队都根据代码仓库（master/release/trunk）分支，创建产品专属的流水线，部署到 团队共同拥有的环境中e.g. dev）。
注意：如图所示，虚线步骤非必选，根据情况可通过 启动参数true/flase 跳过执行，自动化测试仅限于保证基本功能的用例。

3. 部署测试流水线（团队级）

适用场景：每个团队的测试工程师都需要专门针对提测版本的自动化部署/测试流水线，部署到团队共同拥有的环境中（e.g. test）.
注意：如图所示，该条流水线的起点不是代码，而是提测的特定版本安装包；虚线步骤非必选，根据情况可通过 启动参数true/flase 跳过执行 或 裁剪。

4. 多组件集成流水线

适用场景：如果一个产品由多个组件构建而成，每个组件均有独自的代码仓库，并且每个组件由一个单独的团队负责开发与维护，那么，整个产品 的部署流水线的设计通常如下图所示。 集成部署流水线的集成打包阶段将自动从企业软件包库中获取每个组件最近成功的软件包，对其进行产品集成打包

5. 单功能流水线

适用场景：适用于和代码变更无关的场景，不存在上面步骤复杂的编排 (也可通过上述流水线的 启动参数进行条件控制，跳过一些步骤)

• 针对某个环境的漏洞扫描


• 针对某个已部署环境的自动化测试


• 定时清理任务


• ...

6. 全功能（持续交付）流水线

适用场景：需求、代码构建、测试、部署环境内嵌自动化能力，每次提交都触发完整流水线，中间通过人工审批层次卡点，从dev环境,test环境,stage环境一直到 prod环境。 常适用于快速发布的 PASS/SASS服务，对团队各项能力和流程制度要求较高，支持快速发布（策略）和快速回滚（策略）

流水线运转全景图

团队研发工程师每人每天都会提交一次。因此，流水线每天都会启动多次。当然并不是每次提交的变更都会走到最后的“上传发布” 。 也不是每次提交都会走到UAT 部署，因为开发人员并不是完成一个功能需求后才提交代码，而是只要做完一个开发任务，就可以提交。每个功能可能由 多个开发任务组成，研发工程师需要确保即使提交了功能尚未开发完成的代码，也不会影响已开发完成的那些功能。
制品经过一个个质量卡点，经历各种门禁验证，最终交付给客户 可以工作的软件

接口耗时2000多秒！我人麻了！

• 前几天早上，有个push服务不断报警，报了很多次，每次都得运维同学重启服务来维持，因为这个是我负责的，所以我顿时紧张了起来，匆忙来到公司，早饭也不吃了，赶紧排查！

1、 现象与排查步骤：

下面是下午时候几次告警的截图：

• 来看下图。。。。接口超时 2000多秒。。。。我的心碎了！！！人也麻了！！！脑瓜子嗡嗡的。。。

• 

• 另外还总是报pod不健康、不可用 这些比较严重的警告！

• 

我的第一反应是调用方有群发操作，然后看了下接口的qps 貌似也不高呀！也就 9req/s，
之后我去 grafana 监控平台 观察jvm信息发现，线程数量一直往上涨，而且线程状态是 WAITING 的也是一直涨。

如下是某一个pod的监控：

为了观察到底是哪个线程状态一直在涨，我们点进去看下详情：

上图可以看到 该pod的线程状态图 6种线程状态全列出来了， 分别用不同颜色的线代表。而最高那个同时也是14点以后不断递增那个是蓝线 代表的是 WAITING 状态下的线程数量。

通过上图现象，我大概知道了，肯定有线程是一直在wait ，无限wait下去，后来我找运维同学 dump了线程文件，分析一波，来看看到底是哪个地方使线程进入了wait ！！！

如下 是dump下来的线程文件，可以看到搜索出427个WAITING ， 这也基本和 grafana 监控中状态是WAITTING的线程数量一致

重点来了（这个 WAITING 状态的堆栈信息，还都是从 IOSPushStrategy#pushMsgWithIOS 这个方法的某个地方出来的（151行出来的）），于是我们找到代码来看看，是哪个小鬼在作怪？

而类 PushNotificationFuture 继承了 CompletableFuture，他自己又没有get方法，所以本质上 就是调用的 CompletableFuture的 get 方法。

ps：提一嘴，我们这里的场景是 等待ios push服务器的结果，不知道啥情况，今天（指发生故障的那天）ios push服务器(域名： api.push.apple.com )一直没返回，所以就导致一直等待下去了。。

看到这， 我 豁然开朗 && 真相大白 了，原来是在使用 CompletableFuture 的 get时候，没设置超时时间，这样的话会导致一直在等结果。。。（但代码不是我写的，因为我知道 CompletableFuture 的get不设置参数会一直等下去 ，我只是维护，后期也没怎么修改这块的逻辑，哎 ，说多了都是泪呀！）

好一个 CompletableFuture#get();

(真是 死等啊。。。一点不含糊的等待下去，等的天荒地老海枯石烂也要等下去~~~ )

到此，问题的原因找到了。

2、 修复问题

解决办法很简单，给CompletableFuture的get操作 加上超时时间即可，如下代码即可修复：

在修复后，截止到今天（6月8号）没有这种报警情况了，而且线程数和WAITING线程都比较稳定，都在正常范围内，如下截图（一共4个pod）：

至此问题解决了~~~ 终于可以睡个好觉啦！

3、 复盘总结

3.1、 代码浅析

既然此次的罪魁祸首是 CompletableFuture的get方法 那么我们就浅析一下 ：

1. 首先看下 get(); 方法
   
   

上边可以看到
不带参数的get方法： if(deadLine==0) 成立 ，也就是最终调用了LockSupport的park(this);方法，而这个方法最终调了unsafe的这个方法-> unsafe.park(false, 0L); 其中第二个参数就是等待多长时间后，unpark即唤醒被挂起的线程，而0 则代表无限期等待。

2. 再来看下 get(long timeOut,TimeUnit unit);方法
   
   我们可以看到
   带参数的get方法： if(deadLine==0) 不成立，走的else逻辑 也就是最终调用了LockSupport的parkNanos(this,nanos);方法，而这个方法最终调了unsafe的这个方法-> unsafe.park(false, nanos); 其中第二个参数就是你调用get时，传入的tiimeOut参数（只不过底层转成纳秒了）
   
   我们跑了下程序，发现超过指定时间后，get(long timeOut,TimeUnit unit); 方法抛出 TimeoutException异常，而至于超时后我们开发者怎么处理，就在于具体情况了。
   

   Exception in thread "main" java.util.concurrent.TimeoutException
   
           at java.base/java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1886)
   
           at java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2021)
   
   

   
   

而在 我的另一篇文章 万字长文分析synchroized 这篇文章中，我们其实深入过openjdk的源码，见识过park和unpark操作，我们截个图回忆一下：

3.2、最后总结：

1.在调用外部接口时。一定要注意设置超时时间，防止三方服务出问题后影响自身服务。

2.以后无论看到什么类型的Future，都要谨慎，因为这玩意说的是异步，但是调用get方法时，他本质上是同步等待，所以必须给他设置个超时时间，否则他啥时候能返回结果，就得看天意了！

3.凡是和第三方对接的东西，都要做最坏的打算，快速失败的方式很有必要。

4.遇到天大的问题，都尽可能保持冷静，不要乱了阵脚！

作者：蝎子莱莱爱打怪
来源：juejin.cn/post/7242237897993814075

strong>