大家好，我是冰河~~

最近有很多小伙伴，也不乏身边的一些同事问我：哎，架构师为什么要写这么多文档啊？有啥用呢？不能跟开发一样多写写代码吗？天天写文档，又感觉自己的文档写不好，有什么写文档的技巧吗？

今天也正好看到一篇文章，就给大家统一回复下这个问题。

软件设计文档就是架构师的主要工作成果，它需要阐释工作过程中的各种诉求，描绘软件的完整蓝图，而软件设计文档的主要组成部分就是软件模型。

软件设计过程可以拆分成 需求分析、概要设计和详细设计 三个阶段。

在需求分析阶段，主要是通过用例图来描述系统的功能与使用场景；对于关键的业务流程，可以通过活动图描述；如果在需求阶段就提出要和现有的某些子系统整合，那么可以通过时序图描述新系统和原来的子系统的调用关系；可以通过简化的类图进行领域模型抽象，并描述核心领域对象之间的关系；如果某些对象内部会有复杂的状态变化，比如用户、订单这些，可以用状态图进行描述。

在概要设计阶段，通过部署图描述系统最终的物理蓝图；通过组件图以及组件时序图设计软件主要模块及其关系；还可以通过组件活动图描述组件间的流程逻辑。

在详细设计阶段，主要输出的就是类图和类的时序图，指导最终的代码开发，如果某个类方法内部有比较复杂的逻辑，那么可以将这个方法的逻辑用活动图进行描述。

我们在每个设计阶段使用几种UML模型对领域或者系统进行建模，然后将这些模型配上必要的文字说明写入到文档中，就可以构成一篇软件设计文档了。

由于时间关系，今天就跟大家聊到这里，后续给大家分享系统写架构文档的方法论。

好了，今天就到这儿吧，我是冰河，我们下期见~~

需求背景

接到重点业务需求要分轮次展示数据，预估最高承接 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 被打起来的原因就是出现了大量数据计算，在高并发请求前，任何一个环节都可能产生性能问题

作者：京东零售 闫创

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

昨天晚上八点过，下了地铁，走到出租屋的楼下，原本热闹的小区，也变得冷冷清清的，来到我经常吃肉沫粉的小店门口，小雨缠绵，透过那层破旧的透明胶纸，看到老板和老板娘在收拾行李。

我轻轻撩开胶纸，问老板还有吃的吗，他笑着说：兄弟，刚好还有最后一份，你来得正巧，卖给你后我们就该回家了。

可以看出他们心中是很开心的，两个孩子也在不停叨唠：回家了，回家了。

老板做好粉给我端来，可能是最后一份，料加得特别足，我吃了一半就饱了，然后擦了擦嘴，给老板说了声新年快乐，老板和老板娘笑眯眯回了我一句：兄弟，新年快乐，明年见！

于是我就上楼了，往日上楼都有不少人在等电梯，今日五个电梯门都停在一楼，大家都回去过年了吧，再过两天，这个城市可能会更加冷清。

回到出租屋后，坐在桌子前，回想很多事情，我觉得可以动笔了！

一.“不想回家过年”的人

下班后，打了个滴滴去20公里以外的地方办点事，一上车和师傅就开始聊了起来，师傅问我还不回家过年吗？

我对他说：还有好几天呢，除夕再回去。

我反问他：只有几天过年了，为啥还不回去过年呢？

他说道：平时跑车都没啥生意，过年生意好一点，多跑几天，和你一样也是除夕当天才回去。

他说好几天没遇到我这么大的单了，60块钱，平时都是10块，8块的，一天也就能跑两百块钱左右，最近一天能跑500左右。

我们在车上一直聊，聊他的年轻时进厂打工过年回家的时光，他14岁时就去浙江进厂，每年回家过年也就能带几千块钱过年，有一年从义乌坐了三天的大巴车回来，路上堵车，事故，经历“九九八十一难”才到家。

回来过年打了几天的麻将，几千块钱全部输完后，给家里要了几百块钱后，又灰溜溜地出门进厂了。这样的日子反反复复了六七年，一分钱都没存到。

后面觉得这样不行，于是家里给他说了个媳妇，还是卖了一块土地，才勉强把彩礼凑齐了。

成家后有了孩子，压力大了，于是就在家乡的县城干工地，一干就是十几年，直到35岁的时候，存了十几万块钱，2019年在县城首付买了一套房子。

没过多久，疫情就来了，他说没活干，收入彻底断了，但是房贷没有断，于是刷信用卡，借钱来还房贷，后面疫情稍微放开后，就想办法搞了一个二手车来跑，那会跑十几二十公里都很难拉到一个人，一天勉强能跑八九十块钱，勉强能够一家人吃饭，但是房贷还是要想其它的办法。

他说为啥不敢提前回去过年，就是因为还要还房贷，所以不敢松一口气。

聊了大概一个小时，一路堵车，我到站了，下车后他递了一支烟给我，说道：兄弟，很久没有和别人聊这么久了，新年快乐。

我也对他说了一句新年快乐。

我给了一个好评，并且打赏了十块钱。

是啊，我何尝不是很久没有和别人聊这么久了呢，我们都在自己该走的路上马不停蹄奔跑，一切还不是为了生活！

没有谁不想提前回家过年，没有谁不想回家看看父母，没有谁不想回家去感受热乎乎的饭菜！

可是回到了家，生活又该怎么继续继续呢？

二.想回家过年却回不了的人

上个月从广州回来，广州南站已经是人山人海了，那会朋友说抢回广西的票已经很难抢了，都不知道还能不能回去过年。

这两天和在广东打工的朋友聊了下，他说根本抢不到票，不知道还能不能回家。

我打开了手机购票软件，全是暂无余票，建议抢票，抢到票的人是幸运的，但是抢不到票的人，此刻心中又是何种感受。

因为只有火车，高铁，大巴是中国大部分人能消费得起的，大部分根本不舍得买一张机票。

和滴滴师傅聊天时，他说他的哥哥和嫂子现在还在义乌进厂，由于抢不到火车票和高铁票，他们看了看机票，需要1400元，两个人就需要差不多3000多，这已经顶得上他们一个人一个月的工资了。

所以想了想还是不回了，打了几千块钱给家里的老人和孩子，让他们自己过年了。

可能下一次见到家中的老父母和孩子又是下一年了，不知道下次回家的时候，孩子看他们的眼神是不是会有一丝陌生，老人的眼神是不是又多了几分期待。

还记得在我小时候，父母在外省打工，过年的时候，他们背着很大的牛仔背包，里面有被子，衣服，只要能带回来的东西都带回来了，那时候父母还算年轻，但是回到家的时候我却感觉有点陌生。

因为长时间不见他们，当见到他们的时候，虽然心里很高兴，但是却一时表现不出来，反而会流下泪水。

我在农村看了太多这样的场景，爸爸妈妈在外打工，过年回来过年，孩子在门前呆呆坐着，叫了他几声都没答应，最后大哭了起来。

是啊，有谁能在几年时间里没见到自己的爸爸妈妈，当见到的时候能不大哭呢？

不过这就是中国大部分农村的实际情况，父母因为要赚钱回来修房子，供孩子上学，所以很多父母过年不舍得花费太多路费回来。

除了交通工具和回家路费的限制，还有很多因为工作不能回家过年的人，他们很想回来，但是却不能回来，他们有工人，有白领，有交警，有驻守边疆的战士......

此刻，不管你过年在厂区里面加班，在写字楼工作，在路上指挥车辆，还是在祖国的边疆驻守。

我都对你们表示尊敬，祝你们新年快乐！

三.不敢回家过年的人

总有人有家不敢回。

可能网上的过年文案都是阖家欢乐，大团圆，但是在社会的深处，总有很多人不敢回家，或者不好意思回家。

远在深圳的朋友，和我聊天说不敢回家过年了，钱是钱没赚到，女朋友是女朋友没找到，回去面对逐渐变老的父母，心中不忍。

这几年赚钱是真的特别难，朋友在深圳搞销售，因为销售很不稳定，并且是个苦活，他一个月也就能赚几千块钱，除了花销，还要还债，就留不下几个钱。

后面觉得送外卖可能能多赚一点，但是送了不久，和别人电车又撞了，还受了伤，于是只能放弃，直接去找了一个工厂进。

我们大多数人总是看到大城市的繁华，以为都能赚到钱。但是大城市里面，大部分人都是拿着最微薄的工资，干着最累的活，最后还存不了几个钱。

可能你觉得在几十层的写字楼里面工作的白领都是年薪几十几百万，但是实际情况是，大多数都是几千块，每天通勤都是按小时来计算，加班后回到出租屋已经累趴，一趟就睡。

但是一年下来却赚不了几个钱，在亲人朋友的眼中以为你在大城市混得不错，但是苦只有自己知道。

所以带着这种压力和心理负担，很多人不敢回家。

还有一些怕回去被催婚，被相亲，被攀比，所以索性直接留在打工的地方过年，因为觉得自己不甘随便找个人结婚，不想去和谁比这比那，索性选择一个人留下来。

也许大年三十你看到了漫天的烟花，饭桌上丰盛的菜肴，但是总有人在没人看到的地方吃着泡面，烟花爆开的一瞬间，他的眼泪刚好掉下。

我经历过这样的日子，我曾看到别人团圆而自己孤身一人而落泪，也曾看到万家灯火而自己在黑暗中哭泣。

四.无家可回的人

总有人想过年，但是却没有家回的人。

在我还是学生的时候，有一个朋友过年不知道去哪里过，他常年都在外面打工，过年的时候回来，我们在一起喝酒，一起聊天，但是到最后，每个人都回家了，他独自一个人去酒店了。

他父母在他小的时候就离婚了，并且父母都对他不管不顾，在他十几岁的时候就独自出门打工了，他已经没啥亲人了，所以回到家乡只是来找一个曾经的感觉。

还记得前两年，除夕的前一天我们在一起玩耍，我叫他和我去我家一起过年，他拒绝了，后面被另外的两个朋友硬拉着去他们家过年。

当时他的眼睛里面充满泪花，我从他的眼神里面看到了别人没有的坚强。

是呀，可能在我们的世界里，过年是个再寻常不过的日子了，但是在他的世界里，过年却是一件无法奢求的事情。

像我朋友这样情况的人还是比较多的。

不过我的朋友，请你相信，你失去的终究会翻倍给你偿还，你得到的会加倍给你馈赠。

---------------

行笔到此，心中百感交集。

过年是中国人独有的传统，在这个日子里面，是团圆，是喜庆，是期待……

按理这个日子应该用华丽的辞藻和温馨的言语来写。

但是在自己经历了很多事，看到了很多现实场景的时候，我无法动笔去写空洞的句子。

最后给“不想回家过年”，想回家过年却回不了，不敢回家过年，无家可回，无年可过的朋友们说一句，也给我自己说一句。

这个世界总有一盏灯会为你亮着，总有一个眼神，为你等待着。

新年快乐！

一、 概述

众所周知，用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

一、前言

前段时间什么比较火？当然是木鱼了，木鱼一敲，烦恼全消~在这个节奏越来越快的社会上，算是一个不错的解压利器!

我们也紧跟时事，推出了  我要敲木鱼（各大市场均可以下载哦~）

咳咳，扯远了，说回正题

我们在后台收到大量反馈，说是希望添加桌面组件敲木鱼功能。好嘛，用户的话就是圣旨，那必须要安排上，正好我也练练手。

老规矩，先来看下我实现的效果

这个功能看着很简单对吧，却也花了我一天半的时间。主要用来实现敲击动画了！！

二、代码实现

1、新建小组件

 2、修改界面样式

主要会生成3个关键文件（文件名根据你设置的来）

①、APPWidget  类，继承于 AppWidgetProvider，本质是一个 BroadCastReceiver

②、layout/widget.xml ，小组件布局文件

③、xml/widget_info.xml ，小组件信息说明文件

同时会在 AndroidManifest中注册好

类似如下代码：

     <receiver

            android:name=".receiver.MuyuAppWidgetBig"

            android:exported="false">

            <intent-filter>

                <action android:name="android.appwidget.action.APPWIDGET_UPDATE" />

                <action android:name="com.fyspring.bluetooth.receiver.action_appwidget_muyu_knock" />

            </intent-filter>



            <meta-data

                android:name="android.appwidget.provider"

                android:resource="@xml/app_widget_info_big" />

        </receiver>

3、添加敲木鱼逻辑代码

通过 APPWidget 的模板代码我们知道，内部通过 RemoteViews 来进行更新View，而我们都知道 RemoteViews 是无法通过 findViewById 来转成对应的 view，更无法对其添加 Animator。那么我们该怎么办来给桌面木鱼组件添加一个 缩放动画呢？

给你三秒时间考虑下，这里我可花了一天时间来研究....

通过 layoutAnimation ！！！

layoutAnimation 是在 ViewGr0up 创建之后，显示时作用的，作用时间是：ViewGr0up 的首次创建显示，之后再有改变就不行了。

虽然 RemoteViews 不能执行 findViewById，但它提供了两个关键方法： remoteViews.removeAllViews  和  remoteViews.addView 。如果我们在点击时，向组件布局中添加一个带有 layoutAnimation 的布局，不是就可以间接播放动画了么？

关键代码：

private fun doAnimation(context: Context?, remoteViews: RemoteViews?) {

        remoteViews?.removeAllViews(R.id.muyu_rl)

        val remoteViews2 = RemoteViews(context?.packageName, R.layout.anim_layout)

        remoteViews2.setImageViewResource(R.id.widget_muyu_iv, R.mipmap.ic_muyu)

        remoteViews?.addView(R.id.muyu_rl, remoteViews2)

    }

小组件布局：

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"

    style="@style/Widget.BlueToothDemo.AppWidget.Container"

    android:layout_width="wrap_content"

    android:layout_height="wrap_content"

    android:background="@drawable/shape_round_bg"

    android:theme="@style/Theme.BlueToothDemo.AppWidgetContainer">



    <LinearLayout

        android:layout_width="140dp"

        android:layout_height="140dp"

        android:gravity="center_horizontal"

        android:orientation="vertical">



        <TextView

            android:id="@+id/appwidget_text"

            android:layout_width="wrap_content"

            android:layout_height="wrap_content"

            android:layout_centerHorizontal="true"

            android:contentDescription="测试桌面木鱼"

            android:text="已敲0次"

            android:textColor="@color/white"

            android:textSize="18sp"

            android:textStyle="bold" />



        <RelativeLayout

            android:id="@+id/muyu_rl"

            android:layout_width="match_parent"

            android:layout_height="match_parent">



            <ImageView

                android:id="@+id/widget_muyu_iv"

                android:layout_width="match_parent"

                android:layout_height="match_parent"

                android:layout_centerHorizontal="true"

                android:layout_margin="15dp"

                android:src="@mipmap/ic_muyu" />



        </RelativeLayout>

    </LinearLayout>

</RelativeLayout>

添加替换的动画布局(anim_layout.xml)，注意两边的木鱼ImgView 的 ID保持一致，因为要统一设置点击事件！！

<?xml version="1.0" encoding="utf-8"?>

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"

    android:layout_width="wrap_content"

    android:layout_height="wrap_content"

    android:layoutAnimation="@anim/muyu_anim">



    <ImageView

        android:id="@+id/widget_muyu_iv"

        android:layout_width="match_parent"

        android:layout_height="match_parent"

        android:src="@mipmap/ic_muyu2" />

</RelativeLayout>

动画文件：(muyu_anim.xml)

<?xml version="1.0" encoding="utf-8"?>

<layoutAnimation xmlns:android="http://schemas.android.com/apk/res/android" 

android:animation="@anim/scale_anim"/>

动画文件：（scale_anim.xml）

<?xml version="1.0" encoding="utf-8"?>

<scale xmlns:android="http://schemas.android.com/apk/res/android"

    android:duration="100"

    android:fromXScale="0.9"

    android:fromYScale="0.9"

    android:interpolator="@android:anim/accelerate_interpolator"

    android:pivotX="50%"

    android:pivotY="50%"

    android:toXScale="1"

    android:toYScale="1" />

关键动画代码就是以上这些，如果有问题欢迎私信。希望大家在新的一年里，木鱼一敲，烦恼全消~

欢迎体验下我做的木鱼，记得搜  我要敲木鱼  哦~~

介绍

本文承接《低成本创建数字孪生场景-数据篇》，获取到了数据之后就是愉快的开发环节，我们用到了开源项目CesiumJS做为GIS技术框架。

CesiumJS项目从创建至今已经有12年历史，提供了创建3D地球和2D地图的强大功能，它支持多种地图数据源，可以创建复杂的3D地形和城市模型。CesiumJS的功能强大，但入门难度比较高，需要提前了解很多概念和设计理念，为方便理解本案例仅仅使用其提供的一些基础功能。

需求说明

为了搭建1个简易的山区小乡镇场景，我们首先梳理下需求，把任务分解好。

准备工作

数据分发服务

当前案例涉及的图层数据以文件类为主，为方便多处使用，需要将图层的服务独立部署，这里有两个方案：

安装依赖

以下为本案例的前端工程使用的核心框架版本

代码实现

部署说明

总结

在本文中并没有涉及到服务端数据的接入，数据接入进来后，我们可以利用Cesium在GIS开发领域强大功能，与three.js的webGL开发优势，两者相互融合创建更多数据可视化效果。那么关于Cesium和three.js的融合开发还在初步探索阶段，希望下一次有精彩内容分享给大家。

相关链接

最新版cesium集成threejs

Cesium和Three.js结合的5个方案

Cesium实现更实用的3D描边效果

大家好，我是三友~~

今天来继续探秘系列，扒一扒轻量级的分布式任务调度平台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 来作为主键。

俗话说：士为知己者死，女为悦己者容。作为一名技术人员，什么样的领导值得追随？今天就来一起聊一聊。

1. 有实权

权力意味着什么？哈哈，懂的都懂。纵观现在的互联网大厂，盘根错节，明争暗斗的利益团体一个又一个，所以你追随的领导一定要有实权，跟着有实权的领导，很容易获得优质，能拿结果的资源，晋升也就有了更好故事。大厂里一直流传着这样一句暗语：“代码写得好，不如 PPT做得好，PPT做得好，不如老板舔得好”。

如果你追随的领导形同虚设，在公司就很容易边缘化，在团队合作上也可能没有多大的话语权，试想，跟着这样的领导，前途在哪里？

2. 有能力

尽管**实权**在成败上起着决定性的作用，但是绝大多数的技术人员都比较单纯，不愿意参与那种复杂的权利争斗，而且，技术人，能力才是立足之根本。因此，需要选择有能力的领导，要和强者一起赛跑。有能力的领导可以让你快速的学习，快速的成长，对于未来的职业发展才能做到进可攻，退可守。

有能力主要体现在下面几点：

3. 有担当

作为技术人，在职业生涯中犯错误是在所难免的，比如出现比较大的线上事故，这个时候，领导愿不愿意和组员一起承担责任，就能很好的体现领导有没有担当，值不值得追随。

4. 会分享

特别喜欢《亮剑》中李云龙的角色，尽管他满嘴骂骂咧咧，但是在利益分配上他绝对是王者，为了团队的荣誉他可以和上级叫板，为了团队的利益他可以和其他部队的领导呲牙咧嘴，所以，作为他的下属心甘情愿为他赴死，他带领的队伍战斗力超强。

反观职场，领导能不能主动满足下属的诉求，愿不愿意主动为下属争取利益，能不能为下属指定合理的成长计划，都能充分体现出领导愿不愿意和组员一起分享。

5. 有野心

“一个不想当将军的士兵不是一个好士兵”，“一个不想当大领导的领导不是一个没有野心领导”，如果一个在权利，业务，能力上都是野心勃勃的领导，不能证明他一定很好，但是一定不会很差。如果你跟的领导对于团队扩展和业务发展都没有很大的欲望，在公司内部不会去抢资源，拿结果，甚至出现得过且过，甘于平庸，那么，跟随这样的领导，你也只能平庸。

6. 奖罚分明

对于领导，团队管理是他最重要的职责，因此，如何能管好团队？如何激发组员的斗志？这就要求领导一定赏罚分明，团队一定要有清晰的赏罚制度，不要搞平均主义，有竞争才能让组员有动力，为团队创造更多的价值。

如何选择领导呢？

本文总结了值得追随的领导可能具备的 6个特质，但是很多小伙伴会问：我在跳槽前根本不知道自己的领导是谁，他的能力如何？我该如何选择领导？这里也总结几个意见，希望能帮到你：

金无足赤，人无完人，或许你的领导无法同时具备上述 6个特质，但是，只要拥有3～4个，我个人觉得该领导从一定意义上就已经很优秀。而且，日常工作和领导相处的时候，我们需要多换位思考，领导的哪些做法让你不爽，哪些做法让你心悦诚服，如果有一天你也当了领导，你该如何服众。就算不做领导，换位思考，也可以让自己在团队中更好地沟通，成长。

最后，把猿哥的座右铭送给你： 投资自己才是最大的财富。 由于水平有限，如果文章存在缺点和错误，欢迎批评指正。

• 原文标题：The “Real” Repository Pattern in Android


• 原文地址：proandroiddev.com/the-real-re…


• 原文发表日期：2019.9.5


• 作者：Denis Brandi


• 翻译：tommwq


• 翻译日期：2024.1.3

Figure 1: 仓库模式

多年来我见过很多仓库模式的实现，我想其中大部分是错误而无益的。

下面是我所见最多的5个错误（一些甚至出现在Android官方文档中）：

那么要如何把仓库模式做对呢？

1. 你需要领域模型

这是仓库模式的关键点，我想开发者难以正确实现仓库模式的原因在于他们不理解领域是什么。

引用Martin Fowler的话，领域模型是：

领域中同时包含行为和数据的对象模型。

领域模型基本上表示企业范围的业务规则。

对于不熟悉领域驱动设计构建块或分层架构（六边形架构，洋葱架构，干净架构等）的人来说，有三种领域模型：

对于简单领域，这些模型看起来与数据库和网络模型（DTO）很像，不过它们也有很多差异：

• 领域模型包含数据和过程，其结构最适于应用程序。


• DTO是表示JSON/XML格式请求/应答或数据库表的对象模型，其结构最适于远程通信。

Listing 1: 领域模型示例

// Entity

data class Product( 

    val id: String,

    val name: String,

    val price: Price,

    val isFavourite: Boolean

) {

    // Value object

    data class Price( 

        val nowPrice: Double,

        val wasPrice: Double

    ) {

        companion object {

            val EMPTY = Price(0.0, 0.0)

        }

    }

}

Listing 2: 网络DTO示例

// Network DTO

data class NetworkProduct(

    @SerializedName("id")

    val id: String?,

    @SerializedName("name")

    val name: String?,

    @SerializedName("nowPrice")

    val nowPrice: Double?,

    @SerializedName("wasPrice")

    val wasPrice: Double?

)

Listing 3: 数据库DTO示例

// Database DTO

@Entity(tableName = "Product")

data class DBProduct(

    @PrimaryKey                

    @ColumnInfo(name = "id")                

    val id: String,                

    @ColumnInfo(name = "name")                

    val name: String,

    @ColumnInfo(name = "nowPrice")

    val nowPrice: Double,

    @ColumnInfo(name = "wasPrice")

    val wasPrice: Double

)

如你所见，领域模型不依赖框架，对象字段提倡使用多值属性（正如你看到的Price逻辑分组），并使用空对象模式（域不可为空）。而DTO则与框架（Gson、Room）耦合。

幸好有这样的隔离：

• 应用程序的开发变得更容易，因为不需要检查空值，多值属性也减少了字段数量。


• 数据源变更不会影响高层策略。


• 避免了“上帝模型”，带来更多的关注点分离。


• 糟糕的后端接口不会影响高层策略（想象一下，如果你需要执行两个网络请求，因为后端无法在一个接口中提供所有信息。你会让这个问题影响你的整个代码库吗？）

2. 你需要数据转换器

这是将DTO转换成领域模型，以及进行反向转换的地方。

多数开发者认为这种转换是无趣又无效的，他们喜欢将整个代码库，从数据源到界面，与DTO耦合。

这也许能让第一个版本更快交付，但不在表示层中隐藏业务规则和用例，而是省略领域层并将界面与数据源耦合会产生一些只会在生产环境遇到的故障（比如后端没有发送空字符串，而是发送null，并因此引发NPE）。

以我所见，转换器写起来快，测起来也简单。即使实现过程缺乏趣味，它也能保护我们不会因数据源行为的改变而受到意外影响。

如果你没有时间（或者干脆懒得）进行数据转换，你可以使用对象转换框架，比如如modelmapper.org/ ，来加速开发过程。

我不喜欢在代码中使用框架，为减少样板代码，我建立了一个泛型转换接口，以免为每个转换器建立独立接口：

interface Mapper<I, O> {

    fun map(input: I): O

}

以及一组泛型列表转换器，以免实现特定的“列表到列表”转换：

// Non-nullable to Non-nullable

interface ListMapper<I, O>: Mapper<List<I>, List<O>>



class ListMapperImpl<I, O>(

    private val mapper: Mapper<I, O>

) : ListMapper<I, O> {

    override fun map(input: List<I>): List<O> {

        return input.map { mapper.map(it) }

    }

}





// Nullable to Non-nullable

interface NullableInputListMapper<I, O>: Mapper<List<I>?, List<O>>



class NullableInputListMapperImpl<I, O>(

    private val mapper: Mapper<I, O>

) : NullableInputListMapper<I, O> {

    override fun map(input: List<I>?): List<O> {

        return input?.map { mapper.map(it) }.orEmpty()

    }

}





// Non-nullable to Nullable

interface NullableOutputListMapper<I, O>: Mapper<List<I>, List<O>?>



class NullableOutputListMapperImpl<I, O>(

    private val mapper: Mapper<I, O>

) : NullableOutputListMapper<I, O> {

    override fun map(input: List<I>): List<O>? {

        return if (input.isEmpty()) null else input.map { mapper.map(it) }

    }

}

注：在这篇文章中我展示了如何使用简单的函数式编程，以更少的样板代码实现相同的功能。

3. 你需要为每个数据源建立独立模型

假设在网络和数据库中使用同一个模型：

@Entity(tableName = "Product")

data class ProductDTO(

    @PrimaryKey                

    @ColumnInfo(name = "id")    

    @SerializedName("id")

    val id: String?,

    @ColumnInfo(name = "name")

    @SerializedName("name")

    val name: String?,

    @ColumnInfo(name = "nowPrice")

    @SerializedName("nowPrice")

    val nowPrice: Double?,

    @ColumnInfo(name = "wasPrice")

    @SerializedName("wasPrice")

    val wasPrice: Double?

)

刚开始你可能会认为这比使用两个模型开发起来要快得多，但是你注意到它的风险了吗?

如果没有，我可以为你列出一些：

• 你可能会缓存不必要的内容。


• 在响应中添加新字段将需要变更数据库（除非添加@Ignore注解）。


• 所有不应当在请求中发送的字段都需要添加@Transient注解。


• 除非使用新字段，否则必须要求网络和数据库中的同名字段使用相同的数据类型（例如你无法解析网络响应中的字符串nowPrice并缓存双精度浮点数nowPrice）。

如你所见，这种方法最终将比独立模型需要更多的维护工作。

4. 你应该只缓存所需内容

如果要显示存储在远程目录中的产品列表，并且对本地保存的愿望清单中的每个产品显示经典的心形图标。

对于这个需求，需要:

• 获取产品列表。


• 检查本地存储，确认产品是否在愿望清单中。

这个领域模型很像前面例子，添加了一个字段表示产品是否在愿望清单中：

// Entity

data class Product( 

    val id: String,

    val name: String,

    val price: Price,

    val isFavourite: Boolean

) {

    // Value object

    data class Price( 

        val nowPrice: Double,

        val wasPrice: Double

    ) {

        companion object {

            val EMPTY = Price(0.0, 0.0)

        }

    }

}

网络模型也和前面的示例类似，数据库模型则不再需要。

对于本地的愿望清单，可以将产品id保存在SharedPreferences中。不要使用数据库把简单的事情复杂化。

最后是仓库代码：

class ProductRepositoryImpl(

    private val productApiService: ProductApiService,

    private val productDataMapper: Mapper<DataProduct, Product>,

    private val productPreferences: ProductPreferences

) : ProductRepository {



    override fun getProducts(): Single<Result<List<Product>>> {

        return productApiService.getProducts().map {

            when(it) {

                is Result.Success -> Result.Success(mapProducts(it.value))

                is Result.Failure -> Result.Failure<List<Product>>(it.throwable)

            }

        }

    }



    private fun mapProducts(networkProductList: List<NetworkProduct>): List<Product> {

        return networkProductList.map { 

            productDataMapper.map(DataProduct(it, productPreferences.isFavourite(it.id)))

        }

    }      

}

其中依赖的类定义如下：

// A wrapper for handling failing requests

sealed class Result<T> {

    data class Success<T>(val value: T) : Result<T>()

    data class Failure<T>(val throwable: Throwable) : Result<T>()

}



// A DataSource for the SharedPreferences

interface ProductPreferences {

    fun isFavourite(id: String?): Boolean

}



// A DataSource for the Remote DB

interface ProductApiService {

    fun getProducts(): Single<Result<List<NetworkProduct>>>

    fun getWishlist(productIds: List<String>): Single<Result<List<NetworkProduct>>>

}



// A cluster of DTOs to be mapped int0 a Product

data class DataProduct(

    val networkProduct: NetworkProduct,

    val isFavourite: Boolean

)

现在，如果只想获取愿望清单中的产品要怎么做呢？实现方式是类似的：

class ProductRepositoryImpl(

    private val productApiService: ProductApiService,

    private val productDataMapper: Mapper<DataProduct, Product>,

    private val productPreferences: ProductPreferences

) : ProductRepository {



    override fun getWishlist(): Single<Result<List<Product>>> {

        return productApiService.getWishlist(productPreferences.getFavourites()).map {

            when (it) {

                is Result.Success -> Result.Success(mapWishlist(it.value))

                is Result.Failure -> Result.Failure<List<Product>>(it.throwable)

            }

        }

    }



    private fun mapWishlist(wishlist: List<NetworkProduct>): List<Product> {

        return wishlist.map {

            productDataMapper.map(DataProduct(it, true))

        }

    }

}

5. 后记

我多次熟练使用这种模式，我想它是一个时间节约神器，尤其在大型项目中。

然而我多次看到开发者使用这种模式仅仅是因为“不得不”，而非他们了解它的真正优势。

希望你觉得这篇文章有趣也有用。