Monaspace 是有 GitHub 开源的代码字体，包含 5 种变形字体的等宽代码字体家族，颜值 Up，很难不喜欢。

来看一下这 5 种字体分别是：

1️⃣ Radon 手写风格字体

2️⃣ Krypton 机械风格字体

3️⃣ Xenon 衬线风格字体

4️⃣ Argon 人文风格字体

5️⃣ Neon 现代风格字体

👉 项目地址：github.com/githubnext/…

下载方式

MacOS

使用 brew 安装：

brew tap homebrew/cask-fonts

brew install font-monaspace

Windows

下载该文件：github.com/githubnext/…

拖到 C:\Windows\Fonts 中，点击安装

下载好后，如果是 VSCode 文件，可以在设置中找到 font-family，改为：'Monaspace Radon', monospace

数据库所有表被删除了

这个程序员把我们的数据库表都删除了，然后新建了一个数据库redme_to_recover数据库

里面还有一张表，表里是让你支付，然后给你数据下载地址。

通过查看Docker里部署的PostgreSQL执行日志是没有操作记录的

根据数据库的日志确定，1月24号13点数据库被重启了。

25号的日志非常少，错误信息都是客户端连接失败，无法从客户端接收数据。（25号系统还是正常的）

26号02时的日志就显示tdd表没了（这时候应该是所有表都没了）。

中间没有删除表的操作日志，跟大佬请教了一下，确定应该是有人登录了我们的Linux系统。然后从Linux系统层面直接删除的表资源数据，没有通过PGSQL操作，没有删除操作记录。

我对黑客攻击的数据库进行了修改密码，然后发现密码失效了，无论输入什么密码，都能正常登录数据库。

我是怎么恢复的

1、将原来的PG数据库镜像删除，重新修改了端口号和数据库密码然后启动数据库容器。

docker ps -a 列出所有的Docker容器，包括正在运行和已经停止的容器。

docker rm [容器id/容器名称] 删除PostgreSQL容器。

docker run 启动一个新的容器。

2、将Linux账户登录密码修改。

3、修改端口号和数据库配置密码后，重新打包我们的数据处理程序。

4、修改Nacos里配置的接口服务程序的数据库连接配置。

5、将表结构恢复，系统表和业务表结构，系统表包括账户角色等信息（幸亏我们同事有备份）

6、丢失了历史业务数据

需求背景

接到重点业务需求要分轮次展示数据，预估最高承接 9w 的 QPS，作为后端工程师下意识的就是把接口写好，分级缓存、机器扩容、线程拉满等等一系列连招准备，再因为数据更新频次两只手都数得过来，我们采取了最稳妥的处理方式，直接生成静态文件拿 CDN 抗量

架构流程大致如下所示：

数据更新后会重新生成新一轮次的文件，刷新 CDN 的时候会触发大量回源请求，应用服务器极端情况得 hold 住这 9w 的 QPS

第一次压测

双机房一共 40 台 4C 的机器，25KB 数据文件，5w 的 QPS 直接把 CPU 打到 90%

这明显不符合业务需求啊，咋办？先无脑加机器试试呗

就在这时测试同学反馈压测的数据不对，最后一轮文件最大会有 125KB，雪上加霜

于是乎文件替换，机器数量整体翻一倍扩到 80 台，服务端 CPU 依然是瓶颈，QPS 加不上去了

到底是哪里在消耗 CPU 资源呢，整体架构已经简单到不能再简单了

这时候我们注意到为了节省网络带宽 nginx 开启了 gzip 压缩，是不是这小子搞的鬼

server

{

      listen 80;

      

      gzip on;

      gzip_disable "msie6";

      gzip_vary on;

      gzip_proxied any;

      gzip_comp_level 6;

      gzip_buffers 16 8k;

      gzip_http_version 1.1;

      gzip_types text/plain application/css text/css application/xml text/javascript application/javascript application/x-javascript;



......

}

第二次压测

为了验证这个猜想，我们把 nginx 中的 gzip 压缩率从 6 调成 2，以减少 CPU 的计算量

gzip_comp_level 2;

这轮压下来 CPU 还是很快被打满，但 QPS 勉强能达到 9w，坐实了确实是 gzip 在耗 CPU

nginx 作为家喻户晓的 web 服务器，以高性能高并发著称，区区一个静态数据文件就把应用服务器压的这么高，一定是哪里不对

第三次压测

明确了 gzip 在耗 CPU 之后我们潜下心来查阅了相关资料，发现了一丝进展

html/css/js 等静态文件通常包含大量空格、标签等重复字符，重复出现的部分使用「距离加长度」表达可以减少字符数，进而大幅降低带宽，这就是 gzip 无损压缩的基本原理

作为一种端到端的压缩技术，gzip 约定文件在服务端压缩完成，传输中保持不变，直到抵达客户端。这不妥妥的理论依据嘛～

nginx 中的 gzip 压缩分为动态压缩和静态压缩两种

•动态压缩

服务器给客户端返回响应时，消耗自身的资源进行实时压缩，保证客户端拿到 gzip 格式的文件

这个模块是默认编译的，详情可以查看 nginx.org/en/docs/htt…

•静态压缩

直接将预先压缩过的 .gz 文件返回给客户端，不再实时压缩文件，如果找不到 .gz 文件，会使用对应的原始文件

这个模块需要单独编译，详情可以查看 nginx.org/en/docs/htt…

如果开启了 gzip_static always，而且客户端不支持 gzip，还可以在服务端加装 gunzip 来帮助客户端解压，这里我们就不需要了

查了一下 jdos 自带的 nginx 已经编译了 ngx_http_gzip_static_module，省去了重新编译的麻烦事

接下来通过 GZIPOutputStream 在本地额外生成一个 .gz 的文件，nginx 配置上静态压缩再来一次

gzip_static on;

面对 9w 的QPS，40 台机器只用了 7% 的 CPU 使用率完美扛下

为了探底继续加压，应用服务器 CPU 增长缓慢，直到网络流出速率被拉到了 89MB/s，担心影响宿主机其他容器停止压力，此时 QPS 已经来到 27w

qps 5w->27w 提升 5 倍，CPU 90%->7% 降低 10 倍，整体性能翻了 50 倍不止，这回舒服了～

写在最后

经过一连串的分析实践，似乎静态压缩存在“压倒性”优势，那什么场景适合动态压缩，什么场景适合静态压缩呢？一番探讨后得出以下结论

纯静态不会变化的文件适合静态压缩，提前使用gzip压缩好避免CPU和带宽的浪费。动态压缩适合API接口返回给前端数据这种动态的场景，数据会发生变化，这时候就需要nginx根据返回内容动态压缩，以节省服务器带宽

作为一名后端工程师，nginx 是我们的老相识了，抬头不见低头见。日常工作中配一配转发规则，查一查 header 设置，基本都是把 nginx 作为反向代理使用。这次是直接访问静态资源，调整过程的一系列优化加深了我们对 gzip 的动态压缩和静态压缩的基本认识，这在 NG 老炮儿眼里显得微不足道，但对于我们来说却是一次难得的技能拓展机会

在之前的职业生涯里，我们一直聚焦于业务架构设计与开发，对性能的优化似乎已经形成思维惯性。面对大数据量长事务请求，减少循环变批量，增大并发，增加缓存，实在不行走异步任务解决，一般瓶颈都出现在 I/O 层面，毕竟磁盘慢嘛，减少与数据库的交互次数往往就有效果，其他大概率不是问题。这回有点儿不一样，CPU 被打起来的原因就是出现了大量数据计算，在高并发请求前，任何一个环节都可能产生性能问题

作者：京东零售 闫创

来源：京东云开发者社区 转载请注明来源

一、 概述

众所周知，用kotlin委托属性去封装KV存储库，可以优化数据的访问。

封装方法有多种，各有优劣。

通过反复实践，笔者摸索出一套比较好用的方案，借此文做个简单的分享。

代码已上传Github: github.com/BillyWei01/…

项目中是基于SharePreferences封装的，但这套方案也适用于其他类型的KV存储框架。

二、 封装方法

此方案封装了两类委托：

2.1 委托实现

基础类型：BasicDelegate.kt

扩展key的基础类型： ExtDelegate.kt

这里举例一下基础类型中的Boolean类型的委托实现：

class BooleanProperty(private val key: String, private val defValue: Boolean) :

    ReadWriteProperty<KVData, Boolean> {

    override fun getValue(thisRef: KVData, property: KProperty<*>): Boolean {

        return thisRef.kv.getBoolean(key, defValue)

    }



    override fun setValue(thisRef: KVData, property: KProperty<*>, value: Boolean) {

        thisRef.kv.putBoolean(key, value)

    }

}



class NullableBooleanProperty(private val key: String) :

    ReadWriteProperty<KVData, Boolean?> {

    override fun getValue(thisRef: KVData, property: KProperty<*>): Boolean? {

        return thisRef.kv.getBoolean(key)

    }



    override fun setValue(thisRef: KVData, property: KProperty<*>, value: Boolean?) {

        thisRef.kv.putBoolean(key, value)

    }

}

经典的 ReadWriteProperty 实现:

分别重写 getValue 和 setValue 方法，方法中调用KV存储的读写API。

由于kotlin区分了可空类型和非空类型，方案中也分别封装了可空和非空两种委托。

2.2 基类定义

实现了委托之后，我们将各种委托API封装到一个基类中：KVData

abstract class KVData {

    // 存储接口

    abstract val kv: KVStore



    // 基础类型

    protected fun boolean(key: String, defValue: Boolean = false) = BooleanProperty(key, defValue)

    protected fun int(key: String, defValue: Int = 0) = IntProperty(key, defValue)

    protected fun float(key: String, defValue: Float = 0f) = FloatProperty(key, defValue)

    protected fun long(key: String, defValue: Long = 0L) = LongProperty(key, defValue)

    protected fun double(key: String, defValue: Double = 0.0) = DoubleProperty(key, defValue)

    protected fun string(key: String, defValue: String = "") = StringProperty(key, defValue)

    protected fun stringSet(key: String, defValue: Set<String> = emptySet()) = StringSetProperty(key, defValue)

    protected fun <T> obj(key: String, encoder: ObjectEncoder<T>, defValue: T) = ObjectProperty(key, encoder, defValue)



    // 可空的基础类型

    protected fun nullableBoolean(key: String) = NullableBooleanProperty(key)

    protected fun nullableInt(key: String) = NullableIntProperty(key)

    protected fun nullableFloat(key: String) = NullableFloatProperty(key)

    protected fun nullableLong(key: String) = NullableLongProperty(key)

    protected fun nullableDouble(key: String) = NullableDoubleProperty(key)

    protected fun nullableString(key: String) = NullableStringProperty(key)

    protected fun nullableStringSet(key: String) = NullableStringSetProperty(key)

    protected fun <T> nullableObj(key: String, encoder: NullableObjectEncoder<T>) = NullableObjectProperty(key, encoder)



    // 扩展key的基础类型

    protected fun extBoolean(key: String, defValue: Boolean = false) = ExtBooleanProperty(key, defValue)

    protected fun extInt(key: String, defValue: Int = 0) = ExtIntProperty(key, defValue)

    protected fun extFloat(key: String, defValue: Float = 0f) = ExtFloatProperty(key, defValue)

    protected fun extLong(key: String, defValue: Long = 0L) = ExtLongProperty(key, defValue)

    protected fun extDouble(key: String, defValue: Double = 0.0) = ExtDoubleProperty(key, defValue)

    protected fun extString(key: String, defValue: String = "") = ExtStringProperty(key, defValue)

    protected fun extStringSet(key: String, defValue: Set<String> = emptySet()) = ExtStringSetProperty(key, defValue)

    protected fun <T> extObj(key: String, encoder: ObjectEncoder<T>, defValue: T) = ExtObjectProperty(key, encoder, defValue)



    // 扩展key的可空的基础类型

    protected fun extNullableBoolean(key: String) = ExtNullableBooleanProperty(key)

    protected fun extNullableInt(key: String) = ExtNullableIntProperty(key)

    protected fun extNullableFloat(key: String) = ExtNullableFloatProperty(key)

    protected fun extNullableLong(key: String) = ExtNullableLongProperty(key)

    protected fun extNullableDouble(key: String) = ExtNullableDoubleProperty(key)

    protected fun extNullableString(key: String) = ExtNullableStringProperty(key)

    protected fun extNullableStringSet(key: String) = ExtNullableStringSetProperty(key)

    protected fun <T> extNullableObj(key: String, encoder: NullableObjectEncoder<T>) = ExtNullableObjectProperty(key, encoder)

    

    // CombineKV 

    protected fun combineKV(key: String) = CombineKVProperty(key)

}

使用时，继承KVData，然后实现kv, 返回一个KVStore的实现类即可。

举例，如果用SharedPreferences实现KVStore，可如下实现：

class SpKV(name: String): KVStore {

    private val sp: SharedPreferences =

        AppContext.context.getSharedPreferences(name, Context.MODE_PRIVATE)

    private val editor: SharedPreferences.Editor = sp.edit()



    override fun putBoolean(key: String, value: Boolean?) {

        if (value == null) {

            editor.remove(key).apply()

        } else {

            editor.putBoolean(key, value).apply()

        }

    }



    override fun getBoolean(key: String): Boolean? {

        return if (sp.contains(key)) sp.getBoolean(key, false) else null

    }



    // ...... 其他类型 

}

更多实现可参考： SpKV

三、 使用方法

object LocalSetting : KVData("local_setting") {

    override val kv: KVStore by lazy {

        SpKV(name)

    }

    // 是否开启开发者入口

    var enableDeveloper by boolean("enable_developer")



    // 用户ID

    var userId by long("user_id")



    // id -> name 的映射。

    val idToName by extNullableString("id_to_name")



    // 收藏

    val favorites by extStringSet("favorites")



    var gender by obj("gender", Gender.CONVERTER, Gender.UNKNOWN)

}

定义委托属性的方法很简单：

• 和定义变量类似，需要声明变量名和类型；


• 和变量声明不同，需要传入key。


• 如果要定义自定义类型，需要传入转换器（实现字符串和对象类型的转换），以及默认值。

基本类型的读写，和变量的读写一样。

例如：

fun test1(){

    // 写入

    LocalSetting.userId = 10001L

    LocalSetting.gender = Gender.FEMALE



    // 读取

    val uid = LocalSetting.userId

    val gender = LocalSetting.gender

}

读写扩展key的基本类型，则和Map的语法类似:

fun test2() {

    if (LocalSetting.idToName[1] == null || LocalSetting.idToName[2] == null) {

        Log.d("TAG", "Put values to idToName")

        LocalSetting.idToName[1] = "Jonn"

        LocalSetting.idToName[2] = "Mary"

    } else {

        Log.d("TAG", "There are values in idToName")

    }

    Log.d("TAG", "idToName values: " +

                "1 -> ${LocalSetting.idToName[1]}, " +

                "2 -> ${LocalSetting.idToName[2]}"

    )

}

扩展key的基本类型，extKey是Any类型，也就是说，以上代码的[]，可以传入任意类型的参数。

四、数据隔离

4.1 用户隔离

不同环境（开发环境/测试环境），不同用户，最好数据实例是分开的，相互不干扰。

比方说有 uid='001' 和 uid='002' 两个用户的数据，如果需要隔离两者的数据，有多种方法，例如：

基于此分析，我们定义两种类型的基类：

• GlobalKV: 全局数据，切换环境和用户，不影响GlobalKV所访问的数据实例。


• UserKV: 用户数据，需要同时区分 “服务器环境“ 和 ”用户ID“。

open class GlobalKV(name: String) : KVData() {

    override val kv: KVStore by lazy {

        SpKV(name)

    }

}

abstract class UserKV(

    private val name: String,

    private val userId: Long

) : KVData() {

    override val kv: SpKV by lazy {

        // 拼接UID作为文件名

        val fileName = "${name}_${userId}_${AppContext.env.tag}"

        if (AppContext.debug) {

            SpKV(fileName)

        } else {

            // 如果是release包，可以对文件名做个md5，以便匿藏uid等信息

            SpKV(Utils.getMD5(fileName.toByteArray()))

        }

    }

}

UserKV实例：

/**

 * 用户信息

 */

class UserInfo(uid: Long) : UserKV("user_info", uid) {

    companion object {

        private val map = ArrayMap<Long, UserInfo>()

        

        // 返回当前用户的实例

        fun get(): UserInfo {

            return get(AppContext.uid)

        }



        // 根据uid返回对应的实例

        @Synchronized

        fun get(uid: Long): UserInfo {

            return map.getOrPut(uid) {

                UserInfo(uid)

            }

        }

    }

    

    var gender by intEnum("gender", Gender.CONVERTER)

    var isVip by boolean("is_vip")

    

    // ... 其他变量

}

UserKV的实例不能是单例（不同的uid对应不同的实例）。

因此，可以定义companion对象，用来缓存实例，以及提供获取实例的API。

保存和读取方法如下：

先调用get()方法获取，然后其他用法就和前面描述的用法一样了。

UserInfo.get().gender = Gender.FEMALE



val gender = UserInfo.get().gender

4.2 环境隔离

有一类数据，需要区分环境，但是和用户无关。

这种情况，可以用UserKV, 然后uid传0（或者其他的uid用不到的数值）。

/**

 * 远程设置

 */

object RemoteSetting : UserKV("remote_setting", 0L) {

    // 某项功能的AB测试分组

    val fun1ABTestGr0up by int("fun1_ab_test_group")

    

    // 服务端下发的配置项

    val setting by combineKV("setting")

}

五、小结

通过属性委托封装KV存储的API，可使原来“类名 + 操作 + key”的方式，变更为“类名 + 属性”的方式，从而简化KV存储的使用。
另外，这套方案也提到了保存不同用户数据到不同实例的演示。

方案内容不多，但其中包含一些比较实用的技巧，希望对各位读者有所帮助。

一、概述

后缀表达式（也称为逆波兰表达式）是一种数学表达式的表示方法，其中操作符位于操作数的后面。这种表示法消除了括号，并且在计算机科学和计算中非常有用，因为它更容易计算和解析。

与中缀表达式（通常我们使用的数学表达式，例如"a * (b + c)"）不同，后缀表达式的运算符放在操作数之后，例如：“a b c + *”。后缀表达式的计算方法是从左到右遍历表达式，遇到操作数时将其压入栈，遇到操作符时从栈中弹出所需数量的操作数进行计算，然后将结果重新压入栈。这个过程一直持续到整个表达式处理完毕，最终栈中只剩下一个结果，即表达式的计算结果。

后缀表达式具有以下优点：

转换中缀表达式为后缀表达式需要使用算法，通常是栈数据结构。

二、后缀表达式的运算顺序

后缀表达式的运算顺序是从左到右遍历表达式，遇到操作数时将其压入栈，遇到操作符时从栈中弹出所需数量的操作数进行计算，然后将计算结果重新压入栈。这个过程一直持续到整个表达式处理完毕，最终栈中只剩下一个结果，即表达式的计算结果。

后缀表达式的运算顺序是非常直观的，它遵循从左到右的顺序。当计算后缀表达式时，按照以下规则：

三、常规表达式转化为后缀表达式

• 创建两个栈，一个用于操作符（操作符栈），另一个用于输出后缀表达式（输出栈）。


• 从左到右遍历中缀表达式的每个元素。


• 如果是操作数，将其添加到输出栈。


• 如果是操作符：


• 如果操作符栈为空，直接将该操作符推入操作符栈。
  
  否则，比较该操作符与操作符栈栈顶的操作符的优先级。如果当前操作符的优先级较高，将其推入操作符栈。
  
  如果当前操作符的优先级较低或相等，从操作符栈中弹出并添加到输出栈，然后重复比较直到可以推入操作符栈。
  
  如果遇到左括号"(“，直接推入操作符栈。
  
  如果遇到右括号”)“，将操作符栈中的操作符弹出并添加到输出栈，直到遇到匹配的左括号”("。
  
  最后，将操作符栈中的剩余操作符全部弹出并添加到输出栈。
  
  完成遍历后，输出栈中的内容就是中缀表达式转化为后缀表达式的结果。

四、代码实现

/**

     * 定义操作符的优先级

     */

    private  Map<String, Integer> opList =

            Map.of("(",3,")",3,"*",2,"/",2,"+",1,"-",1);



    public List<String> getPostExp(List<String> source) {



        // 数字栈

        Stack<String> dataStack = new Stack<>();

        // 操作数栈

        Stack<String> opStack = new Stack<>();

        // 操作数集合

        for (int i = 0; i < source.size(); i++) {

            String d = source.get(i).trim();

            // 操作符的操作

            if (opList.containsKey(d)) {

                operHandler(d,opStack,dataStack);

            } else {

                // 操作数直接入栈

                dataStack.push(d);

            }

        }

        // 操作数栈中的数据，到压入到栈中

        while (!opStack.isEmpty()) {

            dataStack.push(opStack.pop());

        }

        List<String> result = new ArrayList<>();

        while (!dataStack.isEmpty()) {

            String pop = dataStack.pop();

            result.add(pop);

        }

        // 对数组进行翻转

        return CollUtil.reverse(result);

    }



    /**

     * 对操作数栈的操作

     * @param d，当前操作符

     * @param opStack 操作数栈

     */

    private void operHandler(String d, Stack<String> opStack,Stack<String> dataStack) {

        // 操作数栈为空

        if (opStack.isEmpty()) {

            opStack.push(d);

            return;

        }

        // 如果遇到左括号"(“，直接推入操作符栈。

        if (d.equals("(")) {

            opStack.push(d);

            return;

        }

        // 如果遇到右括号”)“，将操作符栈中的操作符弹出并添加到输出栈，直到遇到匹配的左括号”("。

        if (d.equals(")")) {

            while (!opStack.isEmpty()) {

                String pop = opStack.pop();

                // 不是左括号

                if (!pop.equals("(")) {

                    dataStack.push(pop);

                } else {

                    return;

                }

            }

        }

        // 操作数栈不为空

        while (!opStack.isEmpty()) {

            // 获取栈顶元素和优先级

            String peek = opStack.peek();

            Integer v = opList.get(peek);

            // 获取当前元素优先级

            Integer c = opList.get(d);

            // 如果当前操作符的优先级较低或相等，且不为（），从操作符栈中弹出并添加到输出栈，然后重复比较直到可以推入操作符栈

            if (c < v && v != 3) {

                // 出栈

                opStack.pop();

                // 压入结果集栈

                dataStack.push(peek);

            } else {

                // 操作符与操作符栈栈顶的操作符的优先级。如果当前操作符的优先级较高，将其推入操作符栈。

                opStack.push(d);

                break;

            }

        }

    }

测试代码如下：

PostfixExpre postfixExpre = new PostfixExpre();



List<String> postExp = postfixExpre.getPostExp(

        Arrays.asList("9", "+", "(" , "3", "-", "1", ")", "*", "3", "+", "10", "/", "2"));



System.out.println(postExp);

输出如下：

[9, 3, 1, -, 3, *, 10, 2, /, +, +]

五、求后缀表示值

使用栈来实现

    /****

     * 计算后缀表达式的值

     * @param source

     * @return

     */

    public double calcPostfixExpe(List<String> source) {



        Stack<String> data = new Stack<>();

        for (int i = 0; i < source.size(); i++) {

            String s = source.get(i);

            // 如果是操作数

            if (opList.containsKey(s)) {

                String d2 = data.pop();

                String d1 = data.pop();

                Double i1 = Double.valueOf(d1);

                Double i2 = Double.valueOf(d2);

                Double result = null;

                switch (s) {

                    case "+":

                        result = i1 + i2;break;

                    case "-":

                        result = i1 - i2;break;

                    case "*":

                        result = i1 * i2;break;

                    case "/":

                        result = i1 / i2;break;

                }

                data.push(String.valueOf(result));

            } else {

                // 如果是操作数，进栈操作

                data.push(s);

            }

        }

        // 获取结果

        String pop = data.pop();

        return Double.valueOf(pop);

    }

测试

PostfixExpre postfixExpre = new PostfixExpre();



List<String> postExp = postfixExpre.getPostExp(

        Arrays.asList("9", "+", "(" , "3", "-", "1", ")", "*", "3", "+", "10", "/", "2"));



System.out.println(postExp);



double v = postfixExpre.calcPostfixExpe(postExp);



System.out.println(v);

结果如下：

[9, 3, 1, -, 3, *, 10, 2, /, +, +]

20.0

大家好，我是三友~~

今天来继续探秘系列，扒一扒轻量级的分布式任务调度平台Xxl-Job背后的架构原理

公众号：三友的java日记

核心概念

这里还是老样子，为了保证文章的完整性和连贯性，方便那些没有使用过的小伙伴更加容易接受文章的内容，快速讲一讲Xxl-Job中的概念和使用

如果你已经使用过了，可直接跳过本节和下一节，快进到后面原理部分讲解

1、调度中心

调度中心是一个单独的Web服务，主要是用来触发定时任务的执行

它提供了一些页面操作，我们可以很方便地去管理这些定时任务的触发逻辑

调度中心依赖数据库，所以数据都是存在数据库中的

调度中心也支持集群模式，但是它们所依赖的数据库必须是同一个

所以同一个集群中的调度中心实例之间是没有任何通信的，数据都是通过数据库共享的

2、执行器

执行器是用来执行具体的任务逻辑的

执行器你可以理解为就是平时开发的服务，一个服务实例对应一个执行器实例

每个执行器有自己的名字，为了方便，你可以将执行器的名字设置成服务名

3、任务

任务什么意思就不用多说了

一个执行器中也是可以有多个任务的

总的来说，调用中心是用来控制定时任务的触发逻辑，而执行器是具体执行任务的，这是一种任务和触发逻辑分离的设计思想，这种方式的好处就是使任务更加灵活，可以随时被调用，还可以被不同的调度规则触发。

来个Demo

1、搭建调度中心

调度中心搭建很简单，先下载源码

github.com/xuxueli/xxl…

然后改一下数据库连接信息，执行一下在项目源码中的/doc/db下的sql文件

启动可以打成一个jar包，或者本地启动就是可以的

启动完成之后，访问下面这个地址就可以访问到控制台页面了

http://localhost:8080/xxl-job-admin/toLogin

用户名密码默认是 admin/123456

2、执行器和任务添加

添加一个名为sanyou-xxljob-demo执行器

任务添加

执行器选择我们刚刚添加的，指定任务名称为TestJob，corn表达式的意思是每秒执行一次

创建完之后需要启动一下任务，默认是关闭状态，也就不会执行

创建执行器和任务其实就是CRUD，并没有复杂的业务逻辑

按照如上配置的整个Demo的意思就是

每隔1s，执行一次sanyou-xxljob-demo这个执行器中的TestJob任务

3、创建执行器和任务

引入依赖

<dependencies>

    <dependency>

        <groupId>org.springframework.boot</groupId>

        <artifactId>spring-boot-starter-web</artifactId>

        <version>2.2.5.RELEASE</version>

    </dependency>

    <dependency>

        <groupId>com.xuxueli</groupId>

        <artifactId>xxl-job-core</artifactId>

        <version>2.4.0</version>

    </dependency>

</dependencies>

配置XxlJobSpringExecutor这个Bean

@Configuration

public class XxlJobConfiguration {



    @Bean

    public XxlJobSpringExecutor xxlJobExecutor() {

        XxlJobSpringExecutor xxlJobSpringExecutor = new XxlJobSpringExecutor();

        //设置调用中心的连接地址

        xxlJobSpringExecutor.setAdminAddresses("http://localhost:8080/xxl-job-admin");

        //设置执行器的名称

        xxlJobSpringExecutor.setAppname("sanyou-xxljob-demo");

        //设置一个端口，后面会讲作用

        xxlJobSpringExecutor.setPort(9999);

        //这个token是保证访问安全的，默认是这个，当然可以自定义，

        // 但需要保证调度中心配置的xxl.job.accessToken属性跟这个token是一样的

        xxlJobSpringExecutor.setAccessToken("default_token");

        //任务执行日志存放的目录

        xxlJobSpringExecutor.setLogPath("./");

        return xxlJobSpringExecutor;

    }



}

XxlJobSpringExecutor这个类的作用，后面会着重讲

通过@XxlJob指定一个名为TestJob的任务，这个任务名需要跟前面页面配置的对应上

@Component

public class TestJob {



    private static final Logger logger = LoggerFactory.getLogger(TestJob.class);



    @XxlJob("TestJob")

    public void testJob() {

        logger.info("TestJob任务执行了。。。");

    }



}

所以如果顺利的话，每隔1s钟就会打印一句TestJob任务执行了。。。

启动项目，注意修改一下端口，因为调用中心默认也是8080，本地起会端口冲突

最终执行结果如下，符合预期

讲完概念和使用部分，接下来就来好好讲一讲Xxl-Job核心的实现原理

从执行器启动说起

前面Demo中使用到了一个很重要的一个类

XxlJobSpringExecutor

这个类就是整个执行器启动的入口

这个类实现了SmartInitializingSingleton接口

所以经过Bean的生命周期，一定会调用afterSingletonsInstantiated这个方法的实现

这个方法干了很多初始化的事，这里我挑三个重要的讲，其余的等到具体的功能的时候再提

1、初始化JobHandler

JobHandler是个什么？

所谓的JobHandler其实就是一个定时任务的封装

一个定时任务会对应一个JobHandler对象

当执行器执行任务的时候，就会调用JobHandler的execute方法

JobHandler有三种实现：

• MethodJobHandler


• GlueJobHandler


• ScriptJobHandler

MethodJobHandler是通过反射来调用方法执行任务

所以MethodJobHandler的任务的实现就是一个方法，刚好我们demo中的例子任务其实就是一个方法

所以Demo中的任务最终被封装成一个MethodJobHandler

GlueJobHandler比较有意思，它支持动态修改任务执行的代码

当你在创建任务的时候，需要指定运行模式为GLUE(Java)

之后需要在操作按钮点击GLUE IDE编写Java代码

代码必须得实现IJobHandler接口，之后任务执行的时候就会执行execute方法的实现

如果你需要修改任务的逻辑，只需要重新编辑即可，不需要重启服务

ScriptJobHandler，通过名字也可以看出，是专门处理一些脚本的

运行模式除了BEAN和GLUE(Java)之外，其余都是脚本模式

而本节的主旨，所谓的初始化JobHandler就是指，执行器启动的时候会去Spring容器中找到加了@XxlJob注解的Bean

解析注解，然后封装成一个MethodJobHandler对象，最终存到XxlJobSpringExecutor成员变量的一个本地的Map缓存中

缓存key就是任务的名字

至于GlueJobHandler和ScriptJobHandler都是任务触发时才会创建

除了上面这几种，你也自己实现JobHandler，手动注册到JobHandler的缓存中，也是可以通过调度中心触发的

2、创建一个Http服务器

除了初始化JobHandler之外，执行器还会创建一个Http服务器

这个服务器端口号就是通过XxlJobSpringExecutor配置的端口，demo中就是设置的是9999，底层是基于Netty实现的

这个Http服务端会接收来自调度中心的请求

当执行器接收到调度中心的请求时，会把请求交给ExecutorBizImpl来处理

这个类非常重要，所有调度中心的请求都是这里处理的

ExecutorBizImpl实现了ExecutorBiz接口

当你翻源码的时候会发现，ExecutorBiz还有一个ExecutorBizClient实现

ExecutorBizClient的实现就是发送http请求，所以这个实现类是在调度中心使用的，用来访问执行器提供的http接口

3、注册到调度中心

当执行器启动的时候，会启动一个注册线程，这个线程会往调度中心注册当前执行器的信息，包括两部分数据

• 执行器的名字，也就是设置的appname


• 执行器所在机器的ip和端口，这样调度中心就可以访问到这个执行器提供的Http接口

前面提到每个服务实例都会对应一个执行器实例，所以调用中心会保存每个执行器实例的地址

这里你可以把调度中心的功能类比成注册中心

任务触发原理

弄明白执行器启动时干了哪些事，接下来讲一讲Xxl-Job最最核心的功能，那就是任务触发的原理

任务触发原理我会分下面5个小点来讲解

• 任务如何触发？


• 快慢线程池的异步触发任务优化


• 如何选择执行器实例？


• 执行器如何去执行任务？


• 任务执行结果的回调

1、任务如何触发？

调度中心在启动的时候，会开启一个线程，这个线程的作用就是来计算任务触发时机，这里我把这个线程称为调度线程

这个调度线程会去查询xxl_job_info这张表

这张表存了任务的一些基本信息和任务下一次执行的时间

调度线程会去查询下一次执行的时间 <= 当前时间 + 5s的任务

这个5s是XxlJob写死的，被称为预读时间，提前读出来，保证任务能准时触发

举个例子，假设当前时间是2023-11-29 08:00:10，这里的查询就会查出下一次任务执行时间在2023-11-29 08:00:15之前执行的任务

查询到任务之后，调度线程会去将这些任务根据执行时间划分为三个部分：

• 当前时间已经超过任务下一次执行时间5s以上，也就是需要在2023-11-29 08:00:05（不包括05s）之前的执行的任务


• 当前时间已经超过任务下一次执行时间，但是但不足5s，也就是在2023-11-29 08:00:05和2023-11-29 08:00:10（不包括10s）之间执行的任务


• 还未到触发时间，但是一定是5s内就会触发执行的

对于第一部分的已经超过5s以上时间的任务，会根据任务配置的调度过期策略来选择要不要执行

调度过期策略就两种，就是字面意思

• 直接忽略这个已经过期的任务


• 立马执行一次这个过期的任务

对于第二部分的超时时间在5s以内的任务，就直接立马执行一次，之后如果判断任务下一次执行时间就在5s内，会直接放到一个时间轮里面，等待下一次触发执行

对于第三部分任务，由于还没到执行时间，所以不会立马执行，也是直接放到时间轮里面，等待触发执行

当这批任务处理完成之后，不论是前面是什么情况，调度线程都会去重新计算每个任务的下一次触发时间，然后更新xxl_job_info这张表的下一次执行时间

到此，一次调度的计算就算完成了

之后调度线程还会继续重复上面的步骤，查任务，调度任务，更新任务下次执行时间，一直死循环下去，这就实现了任务到了执行时间就会触发的功能

这里在任务触发的时候还有一个很有意思的细节

由于调度中心可以是集群的形式，每个调度中心实例都有调度线程，那么如何保证任务在同一时间只会被其中的一个调度中心触发一次？

我猜你第一时间肯定想到分布式锁，但是怎么加呢？

XxlJob实现就比较有意思了，它是基于八股文中常说的通过数据库来实现的分布式锁的

在调度之前，调度线程会尝试执行下面这句sql

就是这个sql

select * from xxl_job_lock where lock_name = 'schedule_lock' for update

一旦执行成功，说明当前调度中心成功抢到了锁，接下来就可以执行调度任务了

当调度任务执行完之后再去关闭连接，从而释放锁

由于每次执行之前都需要去获取锁，这样就保证在调度中心集群中，同时只有一个调度中心执行调度任务

最后画一张图来总结一下这一小节

2、快慢线程池的异步触发任务优化

当任务达到了触发条件，并不是由调度线程直接去触发执行器的任务执行

调度线程会将这个触发的任务交给线程池去执行

所以上图中的最后一部分触发任务执行其实是线程池异步去执行的

那么，为什么要使用线程池异步呢？

主要是因为触发任务，需要通过Http接口调用具体的执行器实例去触发任务

这一过程必然会耗费时间，如果调度线程去做，就会耽误调度的效率

所以就通过异步线程去做，调度线程只负责判断任务是否需要执行

并且，Xxl-Job为了进一步优化任务的触发，将这个触发任务执行的线程池划分成快线程池和慢线程池两个线程池

在调用执行器的Http接口触发任务执行的时候，Xxl-Job会去记录每个任务的触发所耗费的时间

注意并不是任务执行时间，只是整个Http请求耗时时间，这是因为执行器执行任务是异步执行的，所以整个时间不包括任务执行时间，这个后面会详细说

当任务一次触发的时间超过500ms，那么这个任务的慢次数就会加1

如果这个任务一分钟内触发的慢次数超过10次，接下来就会将触发任务交给慢线程池去执行

所以快慢线程池就是避免那种频繁触发并且每次触发时间还很长的任务阻塞其它任务的触发的情况发生

3、如何选择执行器实例？

上一节说到，当任务需要触发的时候，调度中心会向执行器发送Http请求，执行器去执行具体的任务

那么问题来了

由于一个执行器会有很多实例，那么应该向哪个实例请求？

这其实就跟任务配置时设置的路由策略有关了

从图上可以看出xxljob支持多种路由策略

除了分片广播，其余的具体的算法实现都是通过ExecutorRouter的实现类来实现的

这里简单讲一讲各种算法的原理，有兴趣的小伙伴可以去看看内部的实现细节

第一个、最后一个、轮询、随机都很简单，没什么好说的

一致性Hash讲起来比较复杂，你可以先看看这篇文章，再去查看Xxl-Job的代码实现

zhuanlan.zhihu.com/p/470368641

最不经常使用（LFU：Least Frequently Used）：Xxl-Job内部会有一个缓存，统计每个任务每个地址的使用次数，每次都选择使用次数最少的地址，这个缓存每隔24小时重置一次

最近最久未使用（LRU：Least Recently Used）：将地址存到LinkedHashMap中，它利用LinkedHashMap可以根据元素访问（get/put）顺序来给元素排序的特性，快速找到最近最久未使用（未访问）的节点

故障转移：调度中心都会去请求每个执行器，只要能接收到响应，说明执行器正常，那么任务就会交给这个执行器去执行

忙碌转移：调度中心也会去请求每个执行器，判断执行器是不是正在执行当前需要执行的任务（任务执行时间过长，导致上一次任务还没执行完，下一次又触发了），如果在执行，说明忙碌，不能用，否则就可以用

分片广播：XxlJob给每个执行器分配一个编号，从0开始递增，然后向所有执行器触发任务，告诉每个执行器自己的编号和总共执行器的数据

我们可以通过XxlJobHelper#getShardIndex获取到编号，XxlJobHelper#getShardTotal获取到执行器的总数据量

分片广播就是将任务量分散到各个执行器，每个执行器只执行一部分任务，加快任务的处理

举个例子，比如你现在需要处理30w条数据，有3个执行器，此时使用分片广播，那么此时可将任务分成3分，每份10w条数据，执行器根据自己的编号选择对应的那份10w数据处理

当选择好了具体的执行器实例之后，调用中心就会携带一些触发的参数，发送Http请求，触发任务

4、执行器如何去执行任务？

相信你一定记得我前面在说执行器启动是会创建一个Http服务器的时候提到这么一句

当执行器接收到调度中心的请求时，会把请求交给ExecutorBizImpl来处理

所以前面提到的故障转移和忙碌转移请求执行器进行判断，最终执行器也是交给ExecutorBizImpl处理的

执行器处理触发请求是这个ExecutorBizImpl的run方法实现的

当执行器接收到请求，在正常情况下，执行器会去为这个任务创建一个单独的线程，这个线程被称为JobThread

每个任务在触发的时候都有单独的线程去执行，保证不同的任务执行互不影响

之后任务并不是直接交给线程处理的，而是直接放到一个内存队列中，线程直接从队列中获取任务

这里我相信你一定有个疑惑

为什么不直接处理，而是交给队列，从队列中获取任务呢？

那就得讲讲不正常的情况了

如果调度中心选择的执行器实例正在处理定时任务，那么此时该怎么处理呢？**

这时就跟阻塞处理策略有关了

阻塞处理策略总共有三种：

• 单机串行


• 丢弃后续调度


• 覆盖之前调度

单机串行的实现就是将任务放到队列中，由于队列是先进先出的，所以就实现串行，这也是为什么放在队列的原因

丢弃调度的实现就是执行器什么事都不用干就可以了，自然而然任务就丢了

覆盖之前调度的实现就很暴力了，他是直接重新创建一个JobThread来执行任务，并且尝试打断之前的正在处理任务的JobThread，丢弃之前队列中的任务

打断是通过Thread#interrupt方法实现的，所以正在处理的任务还是有可能继续运行，并不是说一打断正在运行的任务就终止了

这里需要注意的一点就是，阻塞处理策略是对于单个执行器上的任务来生效的，不同执行器实例上的同一个任务是互不影响的

比如说，有一个任务有两个执行器A和B，路由策略是轮询

任务第一次触发的时候选择了执行器实例A，由于任务执行时间长，任务第二次触发的时候，执行器的路由到了B，此时A的任务还在执行，但是B感知不到A的任务在执行，所以此时B就直接执行了任务

所以此时你配置的什么阻塞处理策略就没什么用了

如果业务中需要保证定时任务同一时间只有一个能运行，需要把任务路由到同一个执行器上，比如路由策略就选择第一个

5、任务执行结果的回调

当任务处理完成之后，执行器会将任务执行的结果发送给调度中心

如上图所示，这整个过程也是异步化的

• JobThread会将任务执行的结果发送到一个内存队列中


• 执行器启动的时候会开启一个处发送任务执行结果的线程：TriggerCallbackThread


• 这个线程会不停地从队列中获取所有的执行结果，将执行结果批量发送给调度中心


• 调用中心接收到请求时，会根据执行的结果修改这次任务的执行状态和进行一些后续的事，比如失败了是否需要重试，是否有子任务需要触发等等

到此，一次任务的就算真正处理完成了

最后

最后我从官网捞了一张Xxl-Job架构图

奈何作者不更新呐，导致这个图稍微有点老了，有点跟现有的架构对不上

比如说图中的自研RPC（xxl-rpc）部分已经替换成了Http协议，这主要是拥抱生态，方便跨语言接入

但是不要紧，大体还是符合现在的整个的架构

从架构图中也可以看出来，本文除了日志部分的内容没有提到，其它的整个核心逻辑基本上都讲到了

而日志部分其实是个辅助的作用，让你更方便查看任务的运行情况，对任务的触发逻辑是没有影响的，所以就没讲了

所以从本文的讲解再到官方架构图，你会发现整个Xxl-Job不论是使用还是实现都是比较简单的，非常的轻量级

说点什么

好了，到这又又成功讲完了一款框架或者说是中间件的核心架构原理，不知道你有没有什么一点收获

如果你觉得有点收获，欢迎点赞、在看、收藏、转发分享给其他需要的人

你的支持就是我更新文章最大的动力，非常地感谢！

其实这篇文章我在十一月上旬的时候我就打算写了

但是由于十一月上旬之后我遇到一系列烦心事，导致我实在是没有精力去写

现在到月底了，虽然烦心事只增不少，但是我还是想了想，觉得不能再拖了，最后也是连续肝了几个晚上，才算真正完成

所以如果你发现文章有什么不足和问题，也欢迎批评指正

好了，本文就讲到这里了，让我们下期再见，拜拜！

学习改变命运，技术铸就辉煌。

大家好，我是銘，全栈开发程序员。

UUID 是什么

我们先来了解一下 UUID 是什么？UUID 是指Universally Unique Identifier，翻译为中文是通用唯一识别码，UUID 的目的是让分布式系统中的所有元素都能有唯一的识别信息。如此一来，每个人都可以创建不与其它人冲突的 UUID，就不需考虑数据库创建时的名称重复问题。

UUID 的十六个八位字节被表示为 32个十六进制数字，以连字号分隔的五组来显示，形式为 8-4-4-4-12，总共有 36个字符（即三十二个英数字母和四个连字号）。例如：

123e4567-e89b-12d3-a456-426655440000

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

能否用 UUID 做主键

先说答案 ， 能，但是性能会比使用自增主键差一些，那原因是什么，我们具体分析：

我们平时建表的时候，一般都像下面这样，不会去使用 UUID，使用AUTO INCREMENT直接把主键 id 设置成自增，每次 +1

CREATE TABLE `user`(

`id` int NOT NULL AUTO INCREMENT COMMENT '主键',

`name` char(10) NOT NULL DEFAULT '' COMMENT '名字',

 PRIMARY KEY (`id`)

 )ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

那为什么把主键设置成自增呢， 我们在数据库保存数据的时候，就类似与下面的表格一样，这每一行数据，都是**保存在一个 16K 大小的页里 **。

每次都去遍历所有的行性能会不好，于是为了加速搜索，我们可以根据主键 id，从小到大排列这些行数据，将这些数据页用双向链表的形式组织起来，再将这些页里的部分信息提取出来放到一个新的 16kb 的数据页里，再加入层级的概念。于是，一个个数据页就被组织起来了，成为了一棵 B+ 树索引。

当我们在建表 sql 里面声明 AUTO INCREMENT 的时候，myqsl 的 innodb 引擎，就会为主键 id 生成一个主键索引，里面就是通过 B+ 树的形式来维护这套索引。

那么现在，我们需要关注两个点，

所以，由于数据页大小固定了 16k ，当我们需要插入一条数据的时候，数据页就会慢慢的被放满，当超过 16k 的时候，这个数据页就可能会进行分裂。

针对 B+ 树的叶子节点，如果主键是自增的，那么它产生的 id 每次都比前次要大，所以每次都会将数据家在 B+ 树的尾部，B+ 树的叶子节点本质是双向链表，查找它的首部和尾部，时间复杂度 O(1)，如果此时最末尾的数据也满了，那创建个新的页就好。

如果bb，上次 id=12111111，这次 id=343435455，那么为了让新加入数据后 B+ 树的叶子节点海涅那个保持有序，那么就需要旺叶子节点的中间找，查找的时间复杂度是 O(lgn)，如果这个页满了，那就需要进行页分裂，并且页分裂的操作是需要加悲观锁的。

所以，我们一般都建议把主键设置成自增，这样可以提高效率，提高性能。

那什么情况下不设置主键自增

mysql分库分表下的id

在分库分表的情况下，插入的 id 都是专门的 id 服务生成的，如果要严格按照自增的话，那么一般就会通过 redis 来生成，按批次去获得，比如一次性获取几百个，用完了再去获取，但是如果 redis 服务挂了，功能就完全没法用了，那有么有不依赖与第三方组件的方法呢？

有， 雪花算法

使用时间戳+机器码+流水号，一个字段实现了时间顺序、机器编码、创建时间。去中心化，方便排序，随便多表多库复制，并可抽取出生成时间，雪花ID主要是用在数据库集群上，去中心化，ID不会冲突又能相对排序。

总结

一般情况下，我们不推荐使用 UUID 来作为数据库的主键，只有分库分表的时候，才建议使用 UUID 来作为主键。

起因

事情的起因是我调用了同事的一个函数，这个函数返回了一个map[string]string结构体的变量optionMap(请忽略为什么要返回map结构体，后面有机会再讲)，这个函数主要是查DB取获取当前系统的space_id和pkey，返回的内容基本上如下

 // 返回

 optionMap = map[string]string{

     "space_id":"xxx",

     "pkey": "xxxx",

 }

然后我修改了这个变量，添加了

optionMap["is_base"] = 1

然后我就return出我当前的函数了，然后在同一个请求内，但是当我再一次请求同事的函数时，返回给我的却是

 optionMap = map[string]string{

     "space_id":"xxx",

     "pkey": "xxxx",

     "is_base": 1,

 }

what! 怎么后面再次请求同事的的函数总是会多一个参数呢！！！！

经过

看了同事写的函数我才发现，原来他在内部使用了gin上下文去做了一个缓存，大概的代码意思减少重复space基础信息的查询，存入上下文中做缓存，提高代码效率，这里我写了一个示例大家可以看下

// 同事的代码

func BadReturnMap(ctx *gin.Context, key string) map[string]interface{} {

	m := make(map[string]interface{})

	// 查询缓存

	value, ok := ctx.Get(key)

	if ok {

		bm, ok := value.(map[string]interface{})

		if ok {

			return bm

		}

	}

	// io查询后存入变量

	m["a"] = 1

	// 保存缓存

	fmt.Println("set cache: ")

	fmt.Println(m) // map[a:1]

	ctx.Set(key, m)

	return m

}



// 我的使用

func TestBadReturnMap() {

	fmt.Println("bad return map start")

	ctx := &gin.Context{}

	key := "cached:map_key"

	mapOpt := BadReturnMap(ctx, key)

	fmt.Printf("%p\n", mapOpt) // 0xc0003a6750 指向地址

	mapOpt["b"] = 1

	value, ok := ctx.Get(key)

	fmt.Printf("%p\n", mapOpt) // 0xc0003a6750 指向地址

	if ok {

		fmt.Println("get cache: ")

		fmt.Println(value.(map[string]interface{})) // map[a:1 def:1]

	} else {

		fmt.Println("unknown")

	}

	fmt.Println("bad return map end")

}

打印结果是

bad return map start

set cache: 

map[a:1]

0xc0003a6750

0xc0003a6750

get cache: 

map[a:1 b:1]

bad return map end

解释

在Go语言中，map是引用类型，当将一个map赋值给另一个变量时，实际上是将它们指向同一个底层的map对象。因此，当你修改其中一个变量的map时，另一个变量也会受到影响。

当你将函数内m变量赋值给外部函数内的变量时，它们实际上指向同一个map对象。所以当你在外部函数内修改mapOpt的值时，原始的缓存也会被修改。

如图所示

如何修改

当然修改方式有很多种，我这里列举了一种就是序列化存储到缓存然后反序列化取，如果你有更好的方式可下方留言

func ReturnMap(ctx *gin.Context, key string) map[string]interface{} {

	m := make(map[string]interface{})

	value, ok := ctx.Get(key)

	if ok {

		bytes := value.([]byte)

		err := json.Unmarshal(bytes, &m)

		if err != nil {

			panic(err)

		}

		return m

	}

	// io查询后存入变量

	m["a"] = 1

	jsonBytes, err := json.Marshal(m)

	if err != nil {

		panic(err)

	}

	fmt.Println("set cache: ")

	fmt.Println(m)

	ctx.Set(key, jsonBytes)



	return m

}



func TestReturnMap() {

	fmt.Println("return map start")

	ctx := &gin.Context{}

	key := "cached:map_key"

	mapOpt := ReturnMap(ctx, key)

	fmt.Printf("%p\n", mapOpt)



	mapOpt["b"] = 1

	fmt.Printf("%p\n", mapOpt)



	value, ok := ctx.Get(key)

	if ok {

		m := make(map[string]interface{})

		bytes := value.([]byte)

		err := json.Unmarshal(bytes, &m)

		if err != nil {

			panic(err)

		}

		fmt.Println("get cache: ")

		fmt.Println(m)

	} else {

		fmt.Println("unknown")

	}

	fmt.Println("return map end")

}

打印的结果为：

return map start

set cache: 

map[a:1]

0xc0003a6870

0xc0003a6870

get cache: 

map[a:1]

return map end

知识点

大家好，我是大澈！

本文约1200+字，整篇阅读大约需要2分钟。

感谢关注微信公众号：“程序员大澈”，免费领取"面试礼包"一份，然后免费加入问答群，从此让解决问题的你不再孤单！

1. 需求分析

前阵子，和问答群里一个前端朋友，随便唠了唠。期间他问了我一个问题，让我印象深刻。

他问的是，限制同一账号只能在一处设备上登录，是如何实现的？并且，他还把这个功能称为“单点登录”。

我说这不叫“单点登录”，这是“单设备登录”。

于是，当时对此概念区分不清的他，和我在语言上开始了深度纠缠。

所以在后面我就想，这个功能问题有必要整理一下，分享给现在还不清楚两者概念的朋友们。

2. 功能实现

先聊聊“单点登录”和“单设备登录”区别，再说说实现“单设备登录”的步骤。

2.1 单点登录和单设备登录的区别

“单点登录”和“单设备登录”是两个完全不同的概念。

单设备登录指：在某个给定的时间，同一用户只能在一台设备上进行登录，如果在其他设备上尝试登录，先前的会话将被中断或注销。

单点登录（简称SSO）指：允许用户使用一组凭据（如用户名和密码）登录到一个系统，然后可以在多个相关系统中，无需重新登录即可访问受保护的资源。

关于“单点登录”的实现，这里简单说一下。一般有两种方式：若后端处理，部署一个认证中心，这是标准做法；若前端处理，可以用LocalStorage做跨域缓存。

2.2 单设备登录的实现

要实现单设备登录，一般来说，有两种方式：使用数据库记录登录状态 和 使用令牌验证机制 。

使用令牌验证机制 的实现步骤如下：

• 用户登录时生成token，将账号作为key，token作为value，并设置过期时间存入redis中。

• 当用户访问应用时，在拦截器中解析token，获取账号，然后用账号去redis中获取相应的value。

• 如果获取到的value的token与当前用户携带的token一致，则允许访问；如果不一致，则提示前端重复登录，让前端清除token，并跳转到登录页面。

• 当用户在另一台设备登录时，其token也会存入redis中，这样就刷新了token的值和redis的过期时间。

使用数据库记录登录状态 的实现步骤如下：

• 在用户登录时，记录用户的账号信息、登录设备的唯一标识符（如设备ID或IP地址）以及登录时间等信息到数据库中的一个登录表。

• 每次用户的登录请求都会查询数据库中的登录表，检查是否存在该用户的登录记录。如果存在记录，则比对登录设备的标识符和当前设备的标识符是否相同。

• 如果当前设备与登录设备不匹配，拒绝登录并提示用户在其他设备上已登录。若匹配，则更新登录时间。

• 当用户主动退出登录或超过一定时间没有操作时，清除该用户的登录记录。

部署Java项目有很多种方式，传统的方式是直接在物理机或虚拟机上部署应用，但为什么现在容器化部署变得越来越流行，
个人觉得原因有以下几个：

1、 环境一致性：使用Docker可以确保开发、测试和生产环境的一致性，避免出现“在我机器上能跑”的问题。

2、 快速部署：Docker镜像一旦构建完成，可以快速部署到任何支持Docker的宿主机上。

3、 易于扩展：结合编排工具如 Kubernetes，可以轻松管理服务的伸缩和负载均衡。

4、 资源隔离：容器化可以提供更好的资源使用隔离和限制，提高系统的稳定性。

5、 更轻便地微服务化：容器很适合微服务架构，每个服务可以单独打包、部署和扩展。

至于是否要在Docker里部署，这取决于项目和团队的具体需求。

如果你的团队追求快速迭代、想要环境一致性，或者计划实现微服务架构，那么使用Docker是一个很好的选择。

但如果项目比较小，或者团队对容器技术不熟，想使用容器化部署应用，可能会增加学习和维护的成本，那就需要权衡利弊了。

如果你决定使用Docker来部署Java项目，大概的步骤是这样的：

1、 编写Dockerfile：这是一个文本文件，包含了从基础镜像获取、复制应用文件、设置环境变量到运行应用的所有命令。

2、 构建镜像：使用docker build命令根据Dockerfile构建成一个可运行的镜像。

3、 运行容器：使用docker run命令从镜像启动一个或多个容器实例。

4、 （可选）使用Docker Compose或Kubernetes等工具部署和管理容器。

部署在Docker里的Java项目，通常都会需要一个精心编写的Dockerfile和一些配置管理，确保应用可以无障碍地在容器中运行。

下面简单演示一个如何使用Docker来部署一个简单的Spring Boot Java项目。

首先，我们需要安装Docker，你可以从Docker官网下载合适的版本安装，安装完后可以通过运行docker --version来检查是否安装成功。

Docker 安装步骤在在这里就不详细说明了，可以参考这篇文章：CentOS Docker 安装

项目部署步骤：

步骤1：编写Dockerfile

Dockerfile是一个文本文件，它包含了一系列的指令和参数，用于定义如何构建你的Docker镜像。
以下是一个典型的Dockerfile示例，用于部署一个Spring Boot应用：

# 使用官方提供的Java运行环境作为基础镜像，根据自己的需求，选择合适的JDK版本，这里以 1.8 为例

FROM openjdk:8-jdk-alpine



# 配置环境变量

ENV APP_FILE myapp.jar

ENV APP_HOME /usr/app



# 在容器内创建一个目录作为工作目录

WORKDIR $APP_HOME



# 将构建好的jar包复制到容器内的工作目录下

COPY target/*.jar $APP_FILE



# 暴露容器内部的端口给外部使用

EXPOSE 8080



# 启动Java应用

ENTRYPOINT ["java","-jar","${APP_FILE}"]

注释解释：

• FROM openjdk:8-jdk-alpine：这告诉Docker使用一个轻量级的Java 8 JDK版本作为基础镜像。


• ENV：设置环境变量，这里设置了应用的jar包名称和存放路径。


• WORKDIR：设定工作目录，之后的COPY等命令都会在这个目录下执行。


• COPY：将本地的jar文件复制到镜像中。


• EXPOSE：将容器的8080端口暴露出去，以便外部可以访问容器内的应用。


• ENTRYPOINT：容器启动时执行的命令，这里是运行Java应用的命令。

步骤2：构建镜像

在Dockerfile所在的目录运行下面的命令来构建你的镜像：

docker build -t my-java-app .

这里的-t标记用于给新创建的镜像设置一个名称，.是上下文路径，指向Dockerfile所在的当前目录。

步骤3：运行容器

构建好镜像后，你可以使用下面的命令来运行容器：

docker run -d -p 8080:8080 --name my-running-app my-java-app

这里的-d标记意味着在后台运行容器，-p标记用于将容器的8080端口映射到宿主机的8080端口，--name用于给容器设置名字。

到这里，如果一切顺利，你的Spring Boot应用就会在Docker容器中启动，
并且宿主机的8080端口会转发到容器内部的同一端口上，你可以通过访问http://xxxx:8080来查看应用是否在运行。

步骤4：使用Docker Compose或Kubernetes等工具部署和管理容器

接下来我们来讲讲如何使用Docker Compose来管理和部署容器。
Docker Compose是一个用于定义和运行多容器Docker应用的工具。使用Compose，你可以通过一个YAML文件来配置你的应用的服务，然后只需要一个简单的命令即可创建和启动所有的服务。

就拿上面的例子来说，我们来创建一个docker-compose.yml 文件来运行Spring Boot应用。

先确保你已经安装了Docker Compose，然后创建以下内容的docker-compose.yml文件：

version: '3'

services:

  my-java-app:

    build: .

    ports:

      - "8080:8080"

    environment:

      SPRING_PROFILES_ACTIVE: "prod"

    volumes:

      - "app-logs:/var/log/my-java-app"



volumes:

  app-logs:

注释解释：

• version：指定了我们使用的Compose文件版本。


• services：定义了我们需要运行的服务。
  
  
  
  • my-java-app：这是我们服务的名称。
  
  
  • build: .：告诉Compose在当前目录下查找Dockerfile来构建镜像。
  
  
  • ports：将容器端口映射到主机端口。
  
  
  • environment：设置环境变量，这里我们假设应用使用Spring Profiles，定义了prod作为激活的配置文件。
  
  
  • volumes：定义了数据卷，这里我们将宿主机的一个卷挂载到容器中，用于存储日志等数据。
  
  
  
  

创建好docker-compose.yml文件后，只需要运行以下命令即可：

docker-compose up -d

这条命令会根据你的docker-compose.yml文件启动所有定义的服务。 -d 参数表明要在后台运行服务。

如果你需要停止并移除所有服务，可以使用：

docker-compose down

使用Docker Compose的好处是，你可以在一个文件中定义整个应用的服务以及它们之间的依赖，然后一键启动或停止所有服务，非常适合本地开发和测试。

至于Kubernetes，它是一个开源的容器编排系统，用于自动部署、扩展和管理容器化应用。

Kubernetes的学习曲线相对陡峭，适合用于更复杂的生产环境。如果你想要进一步了解Kubernetes：

推荐几个 Kubernetes 学习的文章

• 01、Kubernetes学习-从零搭建K8S


• 02、Kubernetes学习-了解k8s的基本组件与概念


• 03、Kubernetes学习-Pod 的实现原理


• 04、Kubernetes学习-Kubernetes Service 的实现原理


• 05、Kubernetes学习-Kubernetes Volume详解


• 06、Kubernetes学习-Kubernetes Namespace 详解


• 07、Kubernetes学习-Kubernetes Deployment 的实现原理


• 08、Kubernetes学习-Kubernetes StatefulSet 实现原理


• ......

总结

总的来说，容器化是Java项目部署的一种高效、现代化方式，适合于追求快速迭代和微服务架构的团队。
对于不熟悉容器技术的团队或者个人开发者而言，需要考虑学习和维护的成本，合适自己的才是最好的，也不必追求别人用什么你就用什么，得不偿失。

在现代网络应用的开发和维护中，502 Bad Gateway错误是一个常见而令人头疼的问题。这种错误通常意味着代理服务器或网关在尝试访问上游服务器时未能获取有效的响应。本文将深入探讨502故障的原因、可能的解决方案，并提供基于实际案例的客观凭证。

1. 原因深入解析

a. 上游服务器问题

502错误的最常见原因之一是上游服务器出现问题。这可能包括服务器崩溃、过载、应用程序错误或者数据库连接故障。具体而言，通过观察服务器的系统日志、应用程序日志以及数据库连接状态，可以深入分析问题的根本原因。

b. 网络问题

网络中断、代理服务器配置错误或者防火墙问题都可能导致502错误。使用网络诊断工具，如traceroute或ping，可以检查服务器之间的连接是否畅通。同时，审查代理服务器和防火墙的配置，确保网络通信正常。

c. 超时问题

502错误还可能是由于上游服务器响应时间超过了网关或代理服务器的超时设置而引起的。深入了解请求的性能特征和服务器响应时间，调整超时设置可以是一项有效的解决方案。

2. 解决方案的客观凭证

a. 上游服务器状态监控

使用监控工具，例如Prometheus、New Relic或Datadog，对上游服务器进行状态监控。通过设置警报规则，可以及时发现服务器性能下降或者异常情况。

b. 网络连接分析

借助Wireshark等网络分析工具，捕获和分析服务器之间的网络通信数据包。这有助于定位网络中断、数据包丢失或防火墙阻塞等问题。

c. 超时设置调整

通过监控工具收集请求的响应时间数据，识别潜在的性能瓶颈。根据实际情况，逐步调整代理服务器的超时设置，以确保其适应上游服务器的响应时间。

3. 实例代码分析

循环引用问题

gc_enabled 是否开启gc

gc_active 垃圾回收算法是否运行

gc_full 垃圾缓冲区是否满了，在debug模式下有用

buf 垃圾缓冲区，php7默认大小为10000个节点位置，第0个位置保留，既不会使用

roots： 指向缓冲区中最新加入的可能是垃圾的元素

unused 指向缓冲区中没有使用的位置，在没有启动垃圾回收算法前，指向空

first_unused 指向缓冲区第一个为未使用的位置。新的元素插入缓冲区后，指向会向后移动一位

last_unused 指向缓冲区最后一个位置

to_free 带释放的列表

next_to_free 下一个待释放的列表

gc_runs 记录gc算法运行的次数，当缓冲区满了，才会运行gc算法

collected 记录gc算法回收的垃圾数

Nginx配置

location / {

    proxy_pass http://backend_server;



    proxy_connect_timeout 5s;

    proxy_read_timeout 30s;

    proxy_send_timeout 12s;



    # 其他代理配置项...

}

上述Nginx配置中，通过设置proxy_connect_timeout、proxy_read_timeout和proxy_send_timeout，可以调整代理服务器的超时设置，从而适应上游服务器的响应时间。

PHP代码

try {

    // 执行与上游服务器交互的操作

    // ...



    // 如果一切正常，输出响应

    echo "Success!";

} catch (Exception $e) {

    // 捕获异常并处理

    header("HTTP/1.1 502 Bad Gateway");

    echo "502 Bad Gateway: " . $e->getMessage();

}

在PHP代码中，通过捕获异常并返回502错误响应，实现了对异常情况的处理，提高了系统的健壮性。

4. 结语

502 Bad Gateway错误是一个综合性的问题，需要从多个角度进行深入分析。通过监控、网络分析和超时设置调整等手段，可以提高对502故障的解决效率。在实际应用中，结合客观的凭证和系统实时监控，开发者和运维人员能够更加迅速、准确地定位问题，确保网络应用的稳定性和可用性。通过以上深度透析和实际案例的代码分析，我们希望读者能够更好地理解502错误，并在面对此类问题时能够快速而有效地解决。

1 需求背景

随着转转业务规模和复杂度不断提高，业务服务增加，服务之间依赖关系也逐渐复杂。在开发和测试中遇到如下问题：

• 参数构造：转转接口测试平台可以很方便调用SCF（转转RPC框架），但是接口的参数很多是复杂model，手动构造参数成本不小，希望能够录制稳定测试环境流量，从流量中抽取接口参数，方便使用者选择参数进行接口测试。


• 压测流量构造：转转是二手电商平台，有许多促销活动的压测需求，人工构造压测流量既不能模拟真实访问，又成本高昂。所以有录制线上流量的需求，然后压测平台通过策略二次加工形成压测case。


• 自动化回归测试：业务迭代速度很快，每次迭代会不会影响原有逻辑？希望有一个平台能够提供筛选保存case，自动化回归，case通过率报告通知等能力。

这些问题每个互联网公司都会遇到，如何才能优雅解决这些问题呢？首先定义一下优雅：不增加业务成本，业务基本无感，对业务性能影响要足够小。阿里开源的jvm-sandbox-repeater（简称Repeater）正是为解决这些问题而生，能够做到业务无感，但是性能问题需要特别定制处理。本文重点介绍：

• Repeater流量录制和回放业务无感实现原理（第2、3章节）


• 线上服务流量录制时，如何减少对正常业务的性能影响（第4章节）

希望能够揭秘Repeater如何做到业务无感的流量录制和回放，进而让使用流量录制的同学对Repeater内部做了哪些工作以及对性能有哪些影响做到心中有数，最后介绍在流量录制时，为了保证对线上服务的性能影响相对可控，我们做了哪些工作，让大家会用敢用。

2 流量录制和回放概念

2.1 流量录制

对于Java调用，一次流量录制包括一次入口调用(entranceInvocation)（eg：HTTP/Dubbo/Java）和若干次子调用(subInvocations)。流量的录制过程就是把入口调用和子调用绑定成一次完整的记录。

    /**

     * 获取商品价格，先从redis中获取，如果redis中没有，再用rpc调用获取，

     * @param productId

     * @return

     */

    public Integer getProductPrice(Long productId){ //入口调用



        //1.redis获取价格

        Integer price = redis.get(productId); //redis远程子调用

        if(Objects.isNull(price)){

            //2.远程调用获取价格

            price =  daoRpc.getProductCount(productId); //rpc远程子调用

            redis.set(productId, price); //redis远程子调用

        }

        //3.价格策略处理

        price = process(price); //本地子调用

        return price;



    }



    private Integer process(Long price){

        //价格策略远程调用

        return logicRpc.process(productId); //rpc远程子调用

    }

以获取产品价格方法为例，流量录制的内容简单来说是入口调用（getProductPrice）的入参和返回值，远程子调用（redis.get,daoRpc.getProductCount,redis.set,logicRpc.process）的入参和返回值，用于流量回放。注意并不会录制本地子调用（process）。

下图是转转流量回放平台录制好的单个流量的线上效果，帮助理解流量录制概念。

2.2 流量回放

流量回放，获取录制流量的入口调用入参，再次发起调用，并且对于子调用，直接使用流量录制时记录的入参和返回值，根据入参（简单来说）匹配子调用后，直接返回录制的数据。这样就还原了流量录制时的环境，如果回放后返回值和录制时返回值不一致，那么本条回放case标记为失败。
还以getProductPrice为例，假设录制时入口调用参数productId=1，返回值为1；redis.get子调用参数productId=1，返回值为1。那么回放时，redis.get不会访问redis，而是直接返回1。假设该函数有逻辑更新，回放返回值是2，与录制时返回值1不相等，那么次此流量回放标记为失败。

下图是转转流量回放平台的流量回放的线上效果，帮助理解流量回放概念

明白流量录制和回放概念后，下面看看业务无感实现流量录制和回放的实现原理。

3 Repeater实现原理

• Repeater Console模块
  
  
  
  • 流量录制和回放的配置管理
  
  
  • 心跳管理
  
  
  • 录制和回放调用入口
  
  
  
  


• Repeater agent plugin模块：Repeater核心功能是流量录制和回放，其实现核心是agent插件，开源框架已经实现redis、mybatis、http、okhttp、dubbo、mq、guava cache等插件。由于录制和回放逻辑是以字节码增强的方式在程序运行时织入，所以无需业务编码。换句话说，agent技术是业务无感的关键。

下面我们就进入无感的关键环节，介绍Repeater如何织入流量录制和回放逻辑代码，以及梳理流量录制和回放的核心代码。

3.1 流量录制和回放逻辑如何织入

用一句话来说，Repeater本身并没有实现代码织入功能，它依赖另一个阿里开源项目JVM-Sandbox。详细来讲，Repeater的核心逻辑录制协议基于JVM-Sandbox的BEFORE、RETRUN、THROW事件机制进行录制流程控制。本质上来说，JVM-Sandbox实现了java agent级别的spring aop功能，是一个通用增强框架。JVM-Sandbox的基于字节码增强的事件机制原理见下图：

上图以add方法为例，揭示JVM-Sandbox增强前后的代码变化，方便大家理解。下面的代码是对图中增强代码相关重点的注释

public int add(int a, int b) {

        try {

            Object[] params = new Object[]{a, b};

            //BEFORE事件

            Spy.Ret retOnBefore = Spy.onBefore(10001,

                    "com.taobao.test.Test", "add", this, params);

            //BEFORE结果可以直接返回结果或者抛出异常，是实现mock（阻断真实远程调用）的关键

            if (retOnBefore.state == I_RETURN) return (int) retOnBefore.object;

            if (retOnBefore.state == I_THROWS) throws(Throwable) retOnBefore.object;

            a = params[0];

            b = params[1];

            int r = a + b;

            //RETRUN事件

            Spy.Ret retOnReturn = Spy.onReturn(10001, r);

            if (retOnReturn.state == I RETURN)return (int) retOnReturn.object;

            if (retOnReturn.state == I_THROWS) throws(Throwable) retOnReturn.object;

            return r;

        } catch (Throwable cause) {

            //THROW事件

            Spy.Ret retOnIhrows = Spy.onThrows(10001, cause);

            if (retOnThrows.state == I RETURN)return (int) retOnThrows.object;

            if (retOnThrows.state == I THROWS) throws(Throwable) retOnThrows.object;

        throws cause;

        }

    }

由上可知，Repeater是利用jvm agent字节码增强技术为目标方法织入BEFORE、RETRUN、THROW逻辑。

3.2 流量录制和回放的核心代码

既然Repeater利用JVM-Sandbox aop框架编写流量录制和回放逻辑，那么让我们看看它的核心代码doBefore。先来一张流程图。

再重点介绍doBefore和doMock的核心代码，它们是实现录制和回放的关键，注意阅读注释。为了方便理解，我对开源代码做了大量删减，只保留核心逻辑。

    /**

     * 处理before事件

     * 流量录制时记录函数元信息和参数，缓存录制数据

     * 流量回放时，调用回放逻辑，直接返回录制时的数据，后面会对processor.doMock进行展开讲解

     * @param event before事件

     */

protected void doBefore(BeforeEvent event) throws ProcessControlException {

        // 回放流量；如果是入口则放弃；子调用则进行mock

        if (RepeatCache.isRepeatFlow(Tracer.getTraceId())) {

            processor.doMock(event, entrance, invokeType);

            return;

        }

        //非回放流量，进行流量录制，主要元信息、参数、返回值

        Invocation invocation = initInvocation(event);

        //记录是否为入口流量

        invocation.setEntrance(entrance);

        //记录参数

        invocation.setRequest(processor.assembleRequest(event));   

        //记录返回值

        invocation.setResponse(processor.assembleResponse(event));



    }

    

     @Override

    public void doMock(BeforeEvent event, Boolean entrance, InvokeType type) throws ProcessControlException {

    

      try {

          

          //通过录制数据构建mock请求 

          final MockRequest request = MockRequest.builder().build();

          //执行mock动作

          final MockResponse mr = StrategyProvider.instance().provide(context.getMeta().getStrategyType()).execute(request);

          //根据mock结果，阻断真实远程调用

          switch (mr.action) {

              case SKIP_IMMEDIATELY:

                  break;

              case THROWS_IMMEDIATELY:

                  //直接抛出异常，映射到JVM-Sandbox的事件机制原理的add函数

                  //也就是代码走到if (retOnBefore.state == I_THROWS) throws(Throwable) retOnBefore.object;

                  //而不再执行后面的代码(JVM-Sandbox框架机制，调用如下代码会触发阻断真实调用)

                  ProcessControlException.throwThrowsImmediately(mr.throwable);

                  break;

              case RETURN_IMMEDIATELY:

              //直接返回录制结果，映射到JVM-Sandbox的事件机制原理的add函数,同理,也不再执行后面的代码(阻断真实调用)

                  ProcessControlException.throwReturnImmediately(assembleMockResponse(event, mr.invocation));

                  break;

              default:

                  ProcessControlException.throwThrowsImmediately(new RepeatException("invalid action"));

                  break;

          }

      } catch (ProcessControlException pce) {

          throw pce;

      } catch (Throwable throwable) {

          ProcessControlException.throwThrowsImmediately(new RepeatException("unexpected code snippet here.", throwable));

      }

    }

通过上面的2、3章节介绍了Repeater流量录制和回放业务无感的实现原理，下面说一下应用过程中需要哪些改造点。

4 Repeater落地实践

4.1 改造点

• Rpeater开源管理后台仅仅是个Demo，需要重新设计和实现。


• SCF（转转RPC框架）插件扩展，支持SCF应用的流量录制和回放。


• DB由MySQL改造为ES，Repeater原生使用MySQL作为流量录制和回放的数据库，仅用于Demo演示，性能和容量无法满足实际需求。


• Docker环境下频繁更换ip时不中断录制。


• 回放结果Diff支持字段过滤。


• 大批量回放。


• 线上环境录制。

4.2 线上环境录制

流量录制很大一部分应用场景在线下，但是线上也有录制场景。从流量录制的原理可知，由于要记录入口调用和各种远程子调用，开启流量录制后，对于该请求占用内存资源会大大增加，并且会增加耗cpu的序列化操作（用于上报流量录制结果）。既然流量录制是一个天然的耗内存和性能操作，对于线上服务的录制除了保持敬畏之心之外，还有设计一种机制减少录制时对线上服务的性能影响。下面开始介绍如果做到录制时减少对线上服务性能的影响。

线上录制减少性能影响的方案：

• 从流程上，线上录制需要申请。


• 从技术上，与发布系统联动，为录制服务增加专门的节点进行录制，并且设置权重为正常节点的1/10，正常节点不会挂载流量录制代码。


• 从回滚上，如果线上录制节点遇到问题，可以从发布系统直接删除录制节点。
  
  

  

5 总结

本文旨在介绍Repeater流量录制和回放的实现原理，以及在落地过程中改造点，希望达到让大家懂原理、会使用、敢使用的目的。

前言

• 最近防御性编程比较火，不信邪的我在开发中我进行了尝试，然后我写下了如下的代码：

    public static void main(String[] args) {

        // do something

        if ("满足条件A") {

            // 查询权限

            if ("是否具备权限A" && "是否具备权限B") {

                // 查询配置

                if ("配置是否开启"){

                    // do something

                }

            }

        }

        // do something

    }