努力干活就能赚多点钱

职场中最大的谎言可能是“工作越忙就能赚到更多的钱”。虽然在某些情况下这是真实的，但很多时候这只是一种误解。长时间超负荷工作可能会导致身体和心理健康问题，甚至影响到家庭生活和人际关系。此外，很多公司并不愿意在工作强度过高的员工身上支付额外的报酬，而是更倾向于平衡员工的工作与生活，提高员工的幸福感和满意度。因此，新进职场人士应该认识到，在职场中坚持适度的工作量、良好的工作习惯和优秀的职业素养才是取得成功的重要因素。

我都是为你好

“我都是为你好”可能是一种常见的谎言，在不同情境下被使用。在某些情况下，这可能真诚地表达出对他人的关心和照顾，但在其他情况下，这也可能成为掩盖自己私人动机或者行为错误的借口。因此，在职场和日常生活中，我们需要学会审视这句话所蕴含的背后意图，并判断其是否真实可信。同时，我们也应该秉持着开放、坦诚、尊重和理解的态度，与他人进行良好的沟通和相处，以建立健康、和谐的人际关系。

他做得比你好，向他好好学习

“他做得比你好，向他好好学习”是一句非常有益的建议，可以让人们从成功的经验中汲取营养，不断提高自己的能力和水平。在职场中，人们面对不同的工作任务和挑战，而且每个人的工作方式、思维模式和经验都不同，因此，我们应该善于借鉴他人的优点和长处，吸取别人的经验和教训，不断完善自己的职业素养和技能。然而，这并不意味着要完全依赖和模仿别人，而是应该在合适的时机，根据自身实际情况和需要，加以改进和创新，开拓自己的专业视野和发展空间。

在职场中，有些人可能会通过拍马屁、拉关系等不正当手段来获取自己的利益或者提高自己的地位。然而，这种做法可能会导致负面后果和损失，例如破坏工作团队的合作氛围、损害自己的职业形象和信誉等。因此，我们应该始终保持清醒和冷静的头脑，不受拍马屁等诱惑，专注于自己的工作和职责，努力提高自己的专业水平和职业素养。同时，我们也应该与他人建立良好的人际关系，以合理、公正、透明的方式展示自己的才华和成果，赢得别人的尊重和信任，并在适当的时刻借助他人的力量来实现共同的目标。

公司不怎么赚钱，理解一下，行情好了加工资

如果公司在过去设定了一些目标和承诺，但无法兑现或者没有达到预期的结果，那么这就是一种失信行为。画饼充当推销手段，可能会对员工、客户和利益相关方造成误导和不良影响，并破坏公司的商誉和形象。因此，公司应该根据市场实际情况和自身能力水平，制定合理、可行的计划和策略，避免过于浮夸和虚幻的承诺，注重落实和执行，加强与员工、客户和社会各方的沟通和互动，建立坦诚、透明的企业文化和价值观念。同时，员工也应该保持客观、谨慎、理性的态度，不盲目追求高回报或者虚假宣传，始终以个人职业道德和职责为先，为公司和自

大家好，我是冰河~~

今天发现Mysql的主从数据库没有同步

先上Master库：

mysql>show processlist;

查看下进程是否Sleep太多。发现很正常。

show master status;

也正常。

mysql> show master status;

+-------------------+----------+--------------+-------------------------------+

| File              | Position | Binlog_Do_DB | Binlog_Ignore_DB              |

+-------------------+----------+--------------+-------------------------------+

| mysqld-bin.000001 |     3260 |              | mysql,test,information_schema |

+-------------------+----------+--------------+-------------------------------+

1 row in set (0.00 sec)

再到Slave上查看

mysql> show slave status\G                                                

 

Slave_IO_Running: Yes

Slave_SQL_Running: No

可见是Slave不同步

解决方案

下面介绍两种解决方法

方法一：忽略错误后，继续同步

该方法适用于主从库数据相差不大，或者要求数据可以不完全统一的情况，数据要求不严格的情况

解决：

stop slave;

 

#表示跳过一步错误，后面的数字可变

set global sql_slave_skip_counter =1;

start slave;

之后再用mysql> show slave status\G 查看

mysql> show slave status\G

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

ok，现在主从同步状态正常了。。。

方式二：重新做主从，完全同步

该方法适用于主从库数据相差较大，或者要求数据完全统一的情况

解决步骤如下：

1.先进入主库，进行锁表，防止数据写入

使用命令：

mysql> flush tables with read lock;

注意：该处是锁定为只读状态，语句不区分大小写

2.进行数据备份

#把数据备份到mysql.bak.sql文件

mysqldump -uroot -p -hlocalhost > mysql.bak.sql

这里注意一点：数据库备份一定要定期进行，可以用shell脚本或者python脚本，都比较方便，确保数据万无一失。

3.查看master 状态

mysql> show master status;

+-------------------+----------+--------------+-------------------------------+

| File              | Position | Binlog_Do_DB | Binlog_Ignore_DB              |

+-------------------+----------+--------------+-------------------------------+

| mysqld-bin.000001 |     3260 |              | mysql,test,information_schema |

+-------------------+----------+--------------+-------------------------------+

1 row in set (0.00 sec)

4.把mysql备份文件传到从库机器，进行数据恢复

scp mysql.bak.sql root@192.168.128.101:/tmp/

5.停止从库的状态

mysql> stop slave;

6.然后到从库执行mysql命令，导入数据备份

mysql> source /tmp/mysql.bak.sql

7.设置从库同步，注意该处的同步点，就是主库show master status信息里的| File| Position两项

change master to master_host = '192.168.128.100', master_user = 'rsync',  master_port=3306, master_password='', master_log_file =  'mysqld-bin.000001', master_log_pos=3260;

8.重新开启从同步

mysql> start slave;

9.查看同步状态

mysql> show slave status\G  



Slave_IO_Running: Yes

Slave_SQL_Running: Yes

10.回到主库并执行如下命令解除表锁定。

UNLOCK TABLES;

好了，今天就到这儿吧，小伙伴们点赞、收藏、评论，一键三连走起呀，我是冰河，我们下期见~

背景

某项目中有一个收费业务，生成订单，订单状态为待支付。在移动端上打开该功能时可查看到待支付的订单，然后用户可以对待支付的订单进行支付。但偶尔出现客户反馈支付后订单还是待支付的状态，导致用户无法继续使用接下来的功能，导致用户的体验行特别差。重新梳理一遍，排查该问题。

涉及服务：

• server1 主服务业务，提供所有业务的服务；


• m-server：提供移动端 H5 视图和部分业务功能，部分功能业务都直接请求 server1；

总体架构

总体流程：

• 用户打开移动端应用时，由 m-server 提供页面视图；


• 移动端相关业务数据由 server1 提供，即用户请求时，会到 m- server 再由其转发到 server1 服务上；


• 相关支付业务由 m-server 服务与微信支付交互，支付完成后再由 m-server 与 server1 交互，同步订单的状态；

详细支付时序图：

支付流程的时序图，可以参考微信的官网：pay.weixin.qq.com/wiki/doc/ap…

支付流程：

• 用户点击支付时，向 m-server 发起支付，然后生成订单


• 向微信支付发起生成预付单


• 点击微信支付的支付，此时会与微信支付进行验证支付授权权限


• 微信返回支付授权，然后用户输入密码，确认支付，向微信支付服务提交授权


• 微信支付返回支付结果给用户，并发微信消息提醒，同时会向 m-server 异步通知支付结果


• m-server 接收到支付结果将同步给 server ，然后server 变更订单状态结果


• m-server 显示最后结果给用户，如支付成功的订单详情

订单状态同步设计：

订单状态流程：

• server1 生成订单并记录到 db 中


• m-server 从 server 中获取到订单的列表


• m-server 接收到微信支付成功时，就会告知 server 支付成功，然后由 server 将订单状态修改为已支付

问题分析

已支付成功了，但订单状态却还是未支付成功？

首先，订单的状态由待支付到支付成功，必须是由微信支付服务异步通知 m-server 支付成功，然后再由 m-server 通知 server1 去修改订单状态。

所以，无论 m-server 还是 server1 服务在支付期间发生抖动都可能导致支付成功的信息成功通知给 server1 ，从而导致订单状态修改失败。还有一种可能性，微信支付服务可能没有异步通知。毕竟是第三方发起通知，所以也可能发生未通知情况。

优化方案

为了保证订单状态最终结果状态一致性，需要增加服务高可用，且可以支持自动重新发送订单状态变更的请求，及时重发重试。

详细设计

• m-server 确认支付时也将订单信息进行存储，状态为待支付


• m-server 接收到微信支付成功通知后，就转发告知server1 服务


• server1 修改订单状态进行响应，m-server 接收到响应进行删除或者修改订单状态(可按需进行)，m-server 这里订单信息没有用了就也可以删除


• 同时开启一个异步轮询 m-server 存储的订单信息，对于订单状态是待支付的，进行重发重试。这个过程需要先和微信支付服务确认确实是已支付，然后再将信息重新发送 server1，告知将订单状态调整为已支付

// 定时轮询订单信息状态

func notifyAuto() {

    // 异步定时监控订单状态的变化

    var changeOrder = func() {

        result := orderService.getUnPayOrder(0) // 获取当前未支付状态的订单

        if len(result) > 0 {

            for v := range result {

                status := wechat.getOrderStatus(v.orderId)

                if status == 1 { // 订单在微信上时已支付的，需重新调用server 修改订单状态

                    orderService.sendOrderFinish(v.orderId)

                }

            }

        }

    }



    go func() {

        time.AfterFunc(time.Minute*10, changeOrder)

    }()

}

复制代码
作者：小雄Ya
来源：juejin.cn/post/7138609603356901413
>

简言

在项目中，我使用了错误的除法，除零没有抛出错误，程序运行正常，但是数据异常。组长说要把我输送社会，老板说还可以挽留一下，我们来复盘一下这次错误。

先让我们来试一试

public class TestDouble {   

 public static void main(String[] args) {   

      System.out.println(1.0 / 0);   

 }

}

你认为的我认为的它应该会抛出 ArithmeticException 异常

但是它现在输出了 Infinity

为什么呢？

Double 数据类型支持无穷大

还有其他类型支持吗？

有，还有 Float

下面我们来查看 Double 源码，可以看到

/** 

  * 一个常数，保持类型的正无穷大 

 */

public static final double POSITIVE_INFINITY = 1.0 / 0.0;

/**

 * 一个常数，保持类型的负无穷大 

*/

public static final double NEGATIVE_INFINITY = -1.0 / 0.0;

/** 

  * 一个常数,非数值类型 

*/

public static final double NaN = 0.0d / 0.0;

下面来试验下 0.0/0 与 -1.0/0

Double 正无穷 = 1.0 / 0;

Double 负无穷 = -1.0 / 0;

System.out.println("正无穷:" + 正无穷);

System.out.println("负无穷:" + 负无穷);

Double 非数值 = 0.0 / 0;

System.out.println("非数值 0.0/0 ->" + 非数值);

输出：

正无穷:Infinity

负无穷:-Infinity

非数值 0.0/0 ->NaN

对无穷大进行运算

下面来测试对 Float 类型与 Doubloe 类型无穷大进行运算

public static void testFloatInfinity() {

     Float infFloat = Float.POSITIVE_INFINITY;     

     Double infDouble = Double.POSITIVE_INFINITY;     

     System.out.println("infFloat + 5 = " + (infFloat + 5));     

     System.out.println("infFloat - infDouble = " + (infFloat - infDouble));     

     System.out.println("infFloat * -1 = " + (infFloat * -1));

}

输出:

infFloat + 5 = InfinityinfFloat - infDouble = NaNinfFloat * -1 = -Infinity

可以注意到 1,3 行运算符合我们的预计结果

ps: Infinity- Infinity 的结果不是数字类型

对这些值进行判断

public static void checkFloatInfinity() {   

 Double 正无穷 = 1.0 / 0;    

 Double 负无穷 = -1.0 / 0;    

 Double 非数值 = 0.0 / 0;    

 System.out.println("判断正无穷: " + Double.isInfinite(正无穷));    

 System.out.println("判断负无穷: " + (Double.NEGATIVE_INFINITY == 负无穷));    

 System.out.println("判断非数值(==): " + (Double.NaN == 非数值));    

 System.out.println("判断非数值(isNaN):  " + Double.isNaN(非数值));

}

输出:

判断正无穷: true

判断负无穷: true

判断非数值(==): false

判断非数值(isNaN):  true

ps: 判断 NaN 不要使用 ==

作者：程序员鱼丸
来源：juejin.cn/post/7135621128818524174

因为工作的原因，我和一些外国前端开发有些交流。他们对于国内环境不了解，有时候会问出一些有趣的问题，大概是这些问题的启发，让我反复在思考一些更为深入的问题。

今天聊三个事情：

• 小程序


• 微前端


• 模块加载

小程序

每个行业都有一把银座，当坐上那把银座时，做什么便都是对的。

“我们为什么需要小程序？”

第一次被问到这个问题，是因为一个法国的同事。他被派去做一个移动端业务，刚好那个业务是采用小程序在做。于是一个法国小哥就在被痛苦的中文文档和黑盒逻辑中来回折磨着 🤦。

于是，当我们在有一次交流中，他问出了我这个问题：我们为什么需要小程序？

说实话，我试图解释了 19 年国内的现状，以及微信小程序推出时候所带来的便利和体验等等。总之，在我看来并不够深刻的见解。

即便到现在为止，每次当我使用小程序的时候，依旧会复现这个问题。在 ChatGPT 11 月份出来的时候，我也问了它这个很有国内特色的问题：

看起来它回答的还算不错，至少我想如果它来糊弄那些老外，应该会比我做的更好些。

但如果扪心自问，单从技术上来讲。以上这些事情，一定是有其他方案能解决的。

所以从某种程度上来看，这更像是一场截胡的商业案例：

应用市场

全世界的互联网人都知道应用市场是非常有价值的事情，可以说操作系统最值钱的部分就在于他们构建了自己的应用市场。

只要应用在这里注册发行，雁过拔毛，这家公司就是互联网世界里的统治阶级，规则的制定者。

反之则需要受制于人，APP 做的再大，也只是应用市场里的一个应用，做的好与坏还得让应用商店的评判。

另外，不得不承认的是，一个庞大如苹果谷歌这样的公司，他们的应用商店对于普通国内开发者来说，确实是有门槛的。

在国内海量的 APP 需求来临之前，能否提供一个更低成本的解决方案，来消化这些公司的投资？

毕竟不是所有的小企业都需要 APP，其实他们大部分需求 Web 就可以解决，但是 Web 没牌面啊，做 Web 还得砸搜索的钱才有流量。(某度搜索又做成那样...)

那做操作系统？太不容易，那么多人都溺死在水里了，这水太深。

那有没有一种办法可以既能构建生态，又有 APP 的心智，还能给入驻企业提供流量？

于是，在 19 年夏天，深圳滨海大厦下的软件展业基地里，每天都在轮番播放着，做 XX小程序，拥抱下一个风口...

全新体验心智

小程序用起来挺方便的。

你有没有想过，这些美妙感觉的具体都来自哪些？以及这些真的是 Web 技术本身无法提供的吗？

1. 靠谱感，每个小程序都有约束和规范，于是你可以将他们整整齐齐的陈放在你的列表里，仿佛你已经拥有了这一个个精心雕琢的作品，相对于一条条记不住的网页地址和鱼龙混杂的网页内容来说，这让你觉得小程序更加的有分量和靠谱。


2. 安全感，沉浸式的头部，没有一闪而过的加载条，这一切无打扰的设计，都让你觉得这是一个在你本地的 APP，而不是随时可能丢失网页。你不会因为网速白屏而感到焦虑，尽管网络差的时候，你的 KFC 依旧下不了单 😂


3. 沉浸感，我不知道是否打开网页时顶部黑黑的状态栏是故意留下的，还是不小心的... 这些限制都让用户非常强烈的意识到这是一个网页而不是 APP，而小程序中虽然上面也存在一个空间的空白，但是却可以被更加沉浸的主题色和氛围图替代。网页这个需求做不了？我不信。

H5	小程序

4. 顺滑感，得益于 Native 的容器实现，小程序在所有的视图切换时，都可以表现出于原生应用一样的顺滑感。其实这个问题才是在很多 Hybrid 应用中，主要想借助客户端来处理和解决的问题。类似容器预开、容器切换等技术是可以解决相关问题的，只是还没有一个标准。

我这里没有提性能，说实话我不认为性能在小程序中是有优势的（Native 调用除外，如地图等，不是一个讨论范畴）。作为普通用户，我们感受到的只是离线加载下带来的顺滑而已。

而上述提到的许多优势，这对于一个高品质的 Web 应用来说是可以做得到的，但注意这里是高品质的 Web 应用。而这种“高品质”在小程序这里，只是入驻门槛而已。

心智，这个词，听起来很黑话，但却很恰当。当小程序通过长期这样的筛选，所沉淀出来一批这样品质的应用时。就会让每个用户即便在还没打开一个新的小程序之前，也有不错体验的心理预期。这就是心智，一种感觉跟 Web 不一样，跟 APP 有点像的心智。

打造心智，这件事情好像就是国内互联网企业最擅长做的事情，总是能从一些细微的差别中开辟一条独立的领域，然后不断强化灌输本来就不大的差异，等流量起来再去捞钱变现。

我总是感觉现在的互利网充斥着如何赚钱的想法，好像永远赚不够。“赚钱”这个事情，在这些公司眼里就是圈人圈地抢资源，看看谁先占得先机，别人有的我也得有，这好像是最重要的事情。

很少有企业在思考如何创造些没有的市场，创造些真正对技术发展有贡献，对社会发展有推动作用的事情。所以在国内互联网圈也充斥着一种奇怪的价值观，有技术的不一定比赚过钱的受待见。

管你是 PHP 还是 GO，管你是在做游戏还是直播带货，只要赚到钱就是高人。并且端的是理所应当、理直气壮，有些老板甚至把拍摄满屋子的程序员为自己打工作为一种乐趣。什么情怀、什么优雅、什么愿景，人生就俩字：搞钱。

不是故意高雅，赚钱这件事情本身不寒碜，只是在已经赚到盆满钵满、一家独大的时候还在只是想着赚更多的钱，好像赚钱的目的就是为了赚钱一样，这就有点不合适。企业到一定程度是要有社会责任的，龙头企业每一个决定和举措，都有会影响接下来的几年里这个行业的价值观走向。

当然也不是完全没有好格局的企业，我非常珍惜每一个值得尊重的中国企业，来自一个蔚来车主。

小程序在商业上固然是成功的，但吃的红利可以说还是来自 网页 到 应用 的心智变革。将本来流向 APP 的红利，截在了小程序生态里。

但对于技术生态的发展却是带来了无数条新的岔路，小程序的玩法就决定了它必须生长在某个巨型应用里面，不论是用户数据获取、还是 API 的调用，其实都是取决于应用容器的标准规范。

不同公司和应用之间则必然会产生差异，并且这种差异是墒增式的差异，只会随着时间的推移越变越大。如果每个企业都只关注到自己业务的增长，无外部约束的话，企业必然会根据自己的业务发展和政策需要，选择成本较低的调整 API，甚至会故意制造一些壁垒来增加这种差异。

小程序，应该是 浏览器 与 操作系统 的融合，这本应该是推动这两项技术操刀解决的事情。

微前端

qiankun、wujie、single-spa 是近两年火遍前端的技术方案，同样一个问题：我们为什么需要微前端？

我不确定是否每个在使用这项技术的前端都想清楚了这个问题，但至少在我面试过的候选人中，我很少遇到对自己项目中已经在使用的微前端，有很深的思考和理解的人。

先说下我的看法：

1. 微前端，重在解决项目管理而不在用户体验。


2. 微前端，解决不了该优化和需要规范的问题。


3. 微前端，在挽救没想清楚 MPA 的 SPA 项目。

没有万能银弹

银色子弹（英文：Silver Bullet），或者称“银弹”“银质子弹”，指由纯银质或镀银的子弹。在欧洲民间传说及19世纪以来哥特小说风潮的影响下，银色子弹往往被描绘成具有驱魔功效的武器，是针对狼人、吸血鬼等超自然怪物的特效武器。后来也被比喻为具有极端有效性的解决方法，作为杀手锏、最强杀招、王牌等的代称。

所有技术的发展都是建立在前一项技术的基础之上，但技术依赖的选择过程中一定需要保留第一性原理的意识。

当 React、Vue 兴起，当 打包技术(Webpack) 兴起，当 网页应用(SPA) 兴起，这些杰出的技术突破都在不同场景和领域中给行业提供了新的思路、新的方案。

不知从何时开始，前端除了 div 竟说不出其他的标签(还有说 View 的)，项目中再也不会考虑给一个通用的 class 解决通用样式问题。

不知从何时开始，有没有权限需要等到 API 请求过后才知道，没有权限的话再把页面跳转过去申请。

不知从何时开始，大家的页面都放在了一个项目里，两个这样的巨石应用融合竟然变成了一件困难的事。

上面这些不合理的现状，都是在不同的场景下，不思考适不适合，单一信奉 “一招吃遍天” 下演化出的问题。

B 端应用，是否应该使用 SPA？ 这其实是一个需要思考的问题。

微前端从某种程度上来讲，是认准 SPA 了必须是互联网下一代应用标准的产物，好像有了 SPA 以后，MPA 就变得一文不值。甭管页面是移动端的还是PC的；甭管页面是面对 C 端的还是 B 端的；甭管一个系统是有 20 个页面还是 200 个页面，一律行这套逻辑。

SPA 不是万能银弹，React 不是万能银弹，Tailwind 不是万能银弹。在新技术出现的时候，保持热情也要保持克制。

ps. 我也十分痛恨 React 带来的这种垄断式的生态，一个 React 组件将 HTML 和 Style 都吃进去，让你即使在做一个移动端的纯展示页面时，也需要背上这些称重的负担。

质疑 “墨守成规”，打开视野，深度把玩，理性消费。

分而治之

分治法，一个很基本的工程思维。

在我看来在一个正常商业迭代项目中的主要维护者，最好不要超过 3 个人，注意是主要维护者(Maintainer) 。

你应该让每个项目都有清晰的责任人，而不是某行代码，某个模块。责任人的理解是有归属感，有边界感的那种，不是口头意义上的责任人。(一些公司喜欢搞这种虚头巴脑的事情，什么连坐…)

我想大部分想引入微前端的需求都是类似 如何更好的划分项目边界，同时保留更好的团队协同。

比如 导航菜单 应该是独立收口独立管理的，并且当其更新时，应该同时应用于所有页面中。类似的还有 环境变量、时区、主题、监控及埋点。微前端将这些归纳在主应用中。

而具体的页面内容，则由对应的业务进行开发子应用，最后想办法将路由关系注册进主应用即可。

当然这样纯前端的应用切换，还会出现不同应用之间的全局变量差异、样式污染等问题，需要提供完善的沙箱容器、隔离环境、应用之间通信等一系列问题，这里不展开。

当微前端做到这一部分的时候，我不禁在想，这好像是在用 JavaScript 实现一个浏览器的运行容器。这种本应该浏览器本身该做的事情，难道 JS 可以做的更好？

只是做到更好的项目拆分，组织协同的话，引入后端服务，由后端管控路由表和页面规则，将页面直接做成 MPA，这个方案或许并不比引入微前端成本高多少。

体验差异

从 SPA 再回 MPA，说了半天不又回去了么。

所以不防想想：在 B端 业务中使用 SPA 的优势在哪里？

流畅的用户体验：

这个话题其实涵盖范围很广，对于 SPA 能带来的 “流畅体验”，对于大多数情况下是指：导航菜单不变，内容变化 发生变化，页面切换中间不出现白屏。

但要做到这个点，其实对于 MPA 其实并没有那么困难，你只需要保证你的 FCP 在 500ms 以内就行。

以上的页面切换全部都是 MPA 的多页面切换，我们只是简单做了导航菜单的 拆分 和 SWR，并没有什么特殊的 preload、prefetch 处理，就得到了这样的效果。

因为浏览器本身在页面切换时会在 unload 之前先 hold 当前页面的视图不变，发起一下一个 document 的请求，当页面的视图渲染做到足够快和界面结构稳定就可以得到这样的效果。

这项浏览器的优化手段我找了很久，想找一篇关于它的博文介绍，但确实没找到相关内容，所以 500ms 也是我的一个大致测算，如果你知道相关的内容，可以在评论区补充，不胜感激。

所以从这个角度来看，浏览器本身就在尽最大的努力做这些优化，并且他们的优化会更底层、更有效的。

离线访问 (PWA)

SPA 确实会有更好的 PWA 组织能力，一个完整的 SPA 应用甚至可以只针对编译层做改动就可以支持 PWA 能力。

但如果看微前端下的 SPA 应用，需要支持 PWA 那就同样需要分析各子应用之间的元数据，定制 Service Worker。这种组织关系和定制 SW，对于元数据对于数据是来自前端还是后端，并不在意。

也就是说微前端模式下的 PWA，同样的投入成本，把页面都管理在后端服务中的 MPA 应用也是可以做到相同效果的。

项目协同、代码复用

有人说 SPA 项目下，项目中的组件、代码片段是可以相互之间复用的，在 MPA 下就相对麻烦。

这其实涉及到项目划分的领域，还是要看具体的需求也业务复杂度来定。如果说整个系统就是二三十个页面，这做成 SPA 使用前端接管路由高效简单，无可厚非。

但如果你本身在面对的是一个服务于复杂业务的 B 端系统，比如类似 阿里云、教务系统、ERP 系统或者一些大型内部系统，这种往往需要多团队合作开发。这种时候就需要跟完善的项目划分、组织协同和系统整合的方案。

这个时候 SPA 所体现出的优势在这样的诉求下就会相对较弱，在同等投入的情况下 MPA 的方案反而会有更少的执行成本。

也不是所有项目一开始就会想的那么清楚，或许一开始的时候就是个简单的 SPA 项目，但是随着项目的不断迭代，才变成了一个个复杂的巨石应用，现在如果再拆出来也会有许多迁移成本。引入微前端，则可以...

这大概是许多微前端项目启动的背景介绍，我想说的是：对于屎山，我从来不信奉“四两拨千斤”。

如果没有想好当下的核心问题，就引入新的“银弹”解决问题，只会是屎山雕花。

项目协同，抽象和复用这些本身不是微前端该解决的问题，这是综合因素影响下的历史背景问题。也是需要一个个资深工程师来把控和解决的核心问题，就是需要面对不同的场景给出不同的治理方案。

这个道理跟防沙治沙一样，哪有那么多一蹴而就、立竿见影的好事。

模块加载

模块加载这件事情，从玉伯大佬的成名作 sea.js 开始就是一个非常值得探讨的问题。在当时 jQuery 的时代里，这是一个绝对超前的项目，我也在实际业务中体会过在无编译的环境下 sea.js 的便捷。

实际上，不论是微前端、低代码、会场搭建等热门话题离不开这项技术基础。

import * from * 我们每天都在用，但最终的产物往往是一个自运行的 JS Bundle，这来自于 Webpack、Vite 等编译技术的发展。让我们可以更好的组织项目结构，以构建更复杂的前端应用。

模块的概念用久了，就会自然而然的在遇到浏览器环境中，遇到动态模块加载的需求时，想到这种类似模块加载的能力。

比如在遇到会场千奇百怪的个性化营销需求时，能否将模块的 Props 开放出来，给到非技术人员，以更加灵活的方式让他们去做自由组合。

比如在低代码平台中，让开发者自定义扩展组件，动态的将开发好的组件注册进低代码平台中，以支持更加个性的需求。

在万物皆组件的思想影响下，把一整个完整页面都看做一个组件也不是不可以。于是在一些团队中，甚至提倡所有页面都可以搭建、搭建不了的就做一个大的页面组件。这样及可以减少维护运行时的成本，又可以统一管控和优化，岂不美哉。

当这样大一统的“天才方案”逐渐发展成为标准后，也一定会出现一些特殊场景无法使用，但没关系，这些天才设计者肯定会提供一种更加天才的扩展方案出来。比如插件，比如扩展，比如 IF ELSE。再后来，就会有性能优化了，而优化的 追赶对象 就是用原来那种简单直出的方案。

有没有发现，这好像是在轮回式的做着自己出的数学题，一道接一道，仿佛将 1 + 1的结论重新演化了一遍。

题外话，我曾经自己实现过一套通过 JSON Schema 描述 React 结构的 “库” ，用于一个低代码核心层的渲染。在我的实现过程中，我越发觉得我在做一件把 JSX 翻译成 JS 的事情，但 JSX 或者 HTML 本身不就是一种 DSL 么。为什么一定要把它翻译成 JSON 来传输呢？或者说这样的封装其本身有意义么？这不就是在做 PHP、ASP 直接返回带有数据的 HTML Ajax 一样的事情么。

传统的浏览器运行环境下要实现一个模块加载器，无非是在全局挂载一个注册器，通过 Script 插入一段新的 JS，该 JS 通过特殊的头尾协议，将运行时的代码声明成一个函数，注册进事先挂载好的注册器。

但实际的实现场景往往要比这复杂的多，也有一些问题是这种非原生方式无法攻克的问题。比如全局注册器的命名冲突；同模块不同版本的加载冲突；并发加载下的时序问题；多次模块加载的缓存问题 等等等等等...

到最后发现，这些事情好像又是在用 JS 做浏览器该做的事情。然而浏览器果然就做了，<script type="module"></script>，Vite 就主要采用这种模式实现了它 1 年之内让各大知名项目切换到 Vite 的壮举。

“但我们用不了，有兼容性问题。”

哇哦，当我看着大家随意写出的 display: grid 样式定义，不禁再次感叹人们对未知的恐惧。

import.meta 的兼容性是另外一个版本，是需要 iOS12 以上，详情参考：caniuse.com/?search=imp…

试想一下，现在的低代码、会场搭建等等各类场景的模块加载部分，如果都直接采用 ESM 的形式处理，这对于整个前端生态和开发体验来说会有多么大的提升。

模块加载，时至今日，本来就已经不再需要 loader。 正如 seajs 中写的：前端模块化开发那点历史

历史不是过去，历史正在上演。随着 W3C 等规范、以及浏览器的飞速发展，前端的模块化开发会逐步成为基础设施。一切终究都会成为历史，未来会更好。

结语

文章的结尾，我想感叹另外一件事，国人为什么一定要有自己的操作系统？为什么一定需要参与到一些规范的制定中？

因为我们的智慧需要有开花的土壤。如果没有自己掌握核心技术，就是只能在问题出现的时候用另类的方式来解决。最后在一番折腾后，发现更底层的技术只要稍稍一改就可以实现的更好。这就像三体中提到的 “智子” 一样，不断在影响着我们前进的动力和方向。

不论是小程序、微前端还是模块加载。试想一下，如果我们有自己的互联网底蕴，能决定或者影响操作系统和浏览器的底层能力。这些 “怪啖” 要么不会出现，要么就是人类的科技创新。

希望未来技术人不用再追逐 Write Once, Run Everywhere 的事情...

前言

前几天突然接到一个技术需求，想要做一个功能。前端有一个表单，在页面上可以直接写 java 代码，写完后就能保存到数据库，并且这个代码实时生效。这岂非是不用发版就可以随时改代码了吗？而且有bug也不怕，随时改。

适用场景：代码逻辑需要经常变动的业务。

核心思想

• 页面改动 java 代码字符串


• java 代码字符串编译成 class


• 动态加载到 jvm

实现重点

JDK 提供了一个工具包 javax.tools 让使用者可以用简易的 API 进行编译。

这些工具包的使用步骤：

1. 获取一个 javax.tools.JavaCompiler 实例。


2. 基于 Java 文件对象初始化一个编译任务 CompilationTask 实例。


3. 因为JVM 里面的 Class 是基于 ClassLoader 隔离的，所以编译成功之后可以通过自定义的类加载器加载对应的类实例


4. 使用反射 API 进行实例化和后续的调用。

1. 代码编译

这一步需要将 java 文件编译成 class，其实平常的开发过程中，我们的代码编译都是由 IDEA、Maven 等工具完成。

内置的 SimpleJavaFileObject 是面向源码文件的，而我们的是源码字符串，所以需要实现 JavaFileObject 接口自定义一个 JavaFileObject。

public class CharSequenceJavaFileObject extends SimpleJavaFileObject {



    public static final String CLASS_EXTENSION = ".class";



    public static final String JAVA_EXTENSION = ".java";



    private static URI fromClassName(String className) {

        try {

            return new URI(className);

        } catch (URISyntaxException e) {

            throw new IllegalArgumentException(className, e);

        }

    }



    private ByteArrayOutputStream byteCode;

    private final CharSequence sourceCode;



    public CharSequenceJavaFileObject(String className, CharSequence sourceCode) {

        super(fromClassName(className + JAVA_EXTENSION), Kind.SOURCE);

        this.sourceCode = sourceCode;

    }



    public CharSequenceJavaFileObject(String fullClassName, Kind kind) {

        super(fromClassName(fullClassName), kind);

        this.sourceCode = null;

    }



    public CharSequenceJavaFileObject(URI uri, Kind kind) {

        super(uri, kind);

        this.sourceCode = null;

    }



    @Override

    public CharSequence getCharContent(boolean ignoreEncodingErrors) throws IOException {

        return sourceCode;

    }



    @Override

    public InputStream openInputStream() {

        return new ByteArrayInputStream(getByteCode());

    }



    // 注意这个方法是编译结果回调的OutputStream，回调成功后就能通过下面的getByteCode()方法获取目标类编译后的字节码字节数组

    @Override

    public OutputStream openOutputStream() {

        return byteCode = new ByteArrayOutputStream();

    }



    public byte[] getByteCode() {

        return byteCode.toByteArray();

    }

}

如果编译成功之后，直接通过 CharSequenceJavaFileObject#getByteCode()方法即可获取目标类编译后的字节码对应的字节数组（二进制内容）

2. 实现 ClassLoader

因为JVM 里面的 Class 是基于 ClassLoader 隔离的，所以编译成功之后得通过自定义的类加载器加载对应的类实例，否则是加载不了的，因为同一个类只会加载一次。

主要关注 findClass 方法

public class JdkDynamicCompileClassLoader extends ClassLoader {



    public static final String CLASS_EXTENSION = ".class";



    private final static Map<String, JavaFileObject> javaFileObjectMap = new ConcurrentHashMap<>();



    public JdkDynamicCompileClassLoader(ClassLoader parentClassLoader) {

        super(parentClassLoader);

    }





    @Override

    protected Class<?> findClass(String name) throws ClassNotFoundException {

        JavaFileObject javaFileObject = javaFileObjectMap.get(name);

        if (null != javaFileObject) {

            CharSequenceJavaFileObject charSequenceJavaFileObject = (CharSequenceJavaFileObject) javaFileObject;

            byte[] byteCode = charSequenceJavaFileObject.getByteCode();

            return defineClass(name, byteCode, 0, byteCode.length);

        }

        return super.findClass(name);

    }



    @Override

    public InputStream getResourceAsStream(String name) {

        if (name.endsWith(CLASS_EXTENSION)) {

            String qualifiedClassName = name.substring(0, name.length() - CLASS_EXTENSION.length()).replace('/', '.');

            CharSequenceJavaFileObject javaFileObject = (CharSequenceJavaFileObject) javaFileObjectMap.get(qualifiedClassName);

            if (null != javaFileObject && null != javaFileObject.getByteCode()) {

                return new ByteArrayInputStream(javaFileObject.getByteCode());

            }

        }

        return super.getResourceAsStream(name);

    }



    /**

     * 暂时存放编译的源文件对象,key为全类名的别名（非URI模式）,如club.throwable.compile.HelloService

     */

    void addJavaFileObject(String qualifiedClassName, JavaFileObject javaFileObject) {

        javaFileObjectMap.put(qualifiedClassName, javaFileObject);

    }



    Collection<JavaFileObject> listJavaFileObject() {

        return Collections.unmodifiableCollection(javaFileObjectMap.values());

    }

}

3. 封装了上面的 ClassLoader 和 JavaFileObject

public class JdkDynamicCompileJavaFileManager extends ForwardingJavaFileManager<JavaFileManager> {



    private final JdkDynamicCompileClassLoader classLoader;

    private final Map<URI, JavaFileObject> javaFileObjectMap = new ConcurrentHashMap<>();



    public JdkDynamicCompileJavaFileManager(JavaFileManager fileManager, JdkDynamicCompileClassLoader classLoader) {

        super(fileManager);

        this.classLoader = classLoader;

    }



    private static URI fromLocation(Location location, String packageName, String relativeName) {

        try {

            return new URI(location.getName() + '/' + packageName + '/' + relativeName);

        } catch (URISyntaxException e) {

            throw new IllegalArgumentException(e);

        }

    }



    @Override

    public FileObject getFileForInput(Location location, String packageName, String relativeName) throws IOException {

        JavaFileObject javaFileObject = javaFileObjectMap.get(fromLocation(location, packageName, relativeName));

        if (null != javaFileObject) {

            return javaFileObject;

        }

        return super.getFileForInput(location, packageName, relativeName);

    }



    /**

     * 这里是编译器返回的同(源)Java文件对象,替换为CharSequenceJavaFileObject实现

     */

    @Override

    public JavaFileObject getJavaFileForOutput(Location location, String className, JavaFileObject.Kind kind, FileObject sibling) throws IOException {

        JavaFileObject javaFileObject = new CharSequenceJavaFileObject(className, kind);

        classLoader.addJavaFileObject(className, javaFileObject);

        return javaFileObject;

    }



    /**

     * 这里覆盖原来的类加载器

     */

    @Override

    public ClassLoader getClassLoader(Location location) {

        return classLoader;

    }



    @Override

    public String inferBinaryName(Location location, JavaFileObject file) {

        if (file instanceof CharSequenceJavaFileObject) {

            return file.getName();

        }

        return super.inferBinaryName(location, file);

    }



    @Override

    public Iterable<JavaFileObject> list(Location location, String packageName, Set<JavaFileObject.Kind> kinds, boolean recurse) throws IOException {

        Iterable<JavaFileObject> superResult = super.list(location, packageName, kinds, recurse);

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

        // 这里要区分编译的Location以及编译的Kind

        if (location == StandardLocation.CLASS_PATH && kinds.contains(JavaFileObject.Kind.CLASS)) {

            // .class文件以及classPath下

            for (JavaFileObject file : javaFileObjectMap.values()) {

                if (file.getKind() == JavaFileObject.Kind.CLASS && file.getName().startsWith(packageName)) {

                    result.add(file);

                }

            }

            // 这里需要额外添加类加载器加载的所有Java文件对象

            result.addAll(classLoader.listJavaFileObject());

        } else if (location == StandardLocation.SOURCE_PATH && kinds.contains(JavaFileObject.Kind.SOURCE)) {

            // .java文件以及编译路径下

            for (JavaFileObject file : javaFileObjectMap.values()) {

                if (file.getKind() == JavaFileObject.Kind.SOURCE && file.getName().startsWith(packageName)) {

                    result.add(file);

                }

            }

        }

        for (JavaFileObject javaFileObject : superResult) {

            result.add(javaFileObject);

        }

        return result;

    }



    /**

     * 自定义方法,用于添加和缓存待编译的源文件对象

     */

    public void addJavaFileObject(Location location, String packageName, String relativeName, JavaFileObject javaFileObject) {

        javaFileObjectMap.put(fromLocation(location, packageName, relativeName), javaFileObject);

    }

}

4. 使用 JavaCompiler 编译并反射生成实例对象

public final class JdkCompiler {



    static DiagnosticCollector<JavaFileObject> DIAGNOSTIC_COLLECTOR = new DiagnosticCollector<>();



    @SuppressWarnings("unchecked")

    public static <T> T compile(String packageName,

                                String className,

                                String sourceCode) throws Exception {

        // 获取系统编译器实例

        JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();

        // 设置编译参数

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

        options.add("-source");

        options.add("1.8");

        options.add("-target");

        options.add("1.8");

        // 获取标准的Java文件管理器实例

        StandardJavaFileManager manager = compiler.getStandardFileManager(DIAGNOSTIC_COLLECTOR, null, null);

        // 初始化自定义类加载器

        JdkDynamicCompileClassLoader classLoader = new JdkDynamicCompileClassLoader(Thread.currentThread().getContextClassLoader());



        // 初始化自定义Java文件管理器实例

        JdkDynamicCompileJavaFileManager fileManager = new JdkDynamicCompileJavaFileManager(manager, classLoader);

        String qualifiedName = packageName + "." + className;

        // 构建Java源文件实例

        CharSequenceJavaFileObject javaFileObject = new CharSequenceJavaFileObject(className, sourceCode);

        // 添加Java源文件实例到自定义Java文件管理器实例中

        fileManager.addJavaFileObject(

                StandardLocation.SOURCE_PATH,

                packageName,

                className + CharSequenceJavaFileObject.JAVA_EXTENSION,

                javaFileObject

        );

        // 初始化一个编译任务实例

        JavaCompiler.CompilationTask compilationTask = compiler.getTask(

                null,

                fileManager,

                DIAGNOSTIC_COLLECTOR,

                options,

                null,

                Collections.singletonList(javaFileObject)

        );

        Boolean result = compilationTask.call();

        System.out.println(String.format("编译[%s]结果:%s", qualifiedName, result));

        Class<?> klass = classLoader.loadClass(qualifiedName);

        return (T) klass.getDeclaredConstructor().newInstance();

    }

}

完成上面工具的搭建之后。我们可以接入数据库的操作了。数据库层面省略，只展示 service 层

service 层：

public class JavaService {



    public Object saveAndGetObject(String packageName,String className,String javaContent) throws Exception {

        Object object = JdkCompiler.compile(packageName, className, javaContent);

        return object;

    }



}

测试：

public class TestService {



    public static void main(String[] args) throws Exception {

        test();

    }



    static String content="package cn.mmc;\n" +

            "\n" +

            "public class SayHello {\n" +

            "    \n" +

            "    public void say(){\n" +

            "        System.out.println(\"11111111111\");\n" +

            "    }\n" +

            "}";



    static String content2="package cn.mmc;\n" +

            "\n" +

            "public class SayHello {\n" +

            "    \n" +

            "    public void say(){\n" +

            "        System.out.println(\"22222222222222\");\n" +

            "    }\n" +

            "}";



    public static void test() throws Exception {

        JavaService javaService = new JavaService();

        Object sayHello = javaService.saveAndGetObject("cn.mmc", "SayHello", content);

        sayHello.getClass().getMethod("say").invoke(sayHello);



        Object sayHello2 = javaService.saveAndGetObject("cn.mmc", "SayHello", content2);

        sayHello2.getClass().getMethod("say").invoke(sayHello2);

    }

}

我们在启动应用时，更换了代码文件内存，然后直接反射调用对象的方法。执行结果：

可以看到，新的代码已经生效！！！

注意，直接开放修改代码虽然方便，但是一定要做好安全防护

作者：女友在高考
来源：juejin.cn/post/7134155429147312141

说起来加班，别管什么80后，90后，00后，内心肯定都是非常抵制的，朝九晚六，平衡工作生活，想必是大多数人的梦想。

为什么突然想写一篇这样的文章，这两天确实有几件事情触动了我。

1.同事猝死

曾任职的一家公司，一名同事于4月1日猝死。以前总是看网上那些猝死的案例，感慨加班猝死，不曾想这件事生生的发生在自己身边，这名同事是一名销售，具体猝死缘由（前）公司并没有多谈，但我想一定是和熬夜加班息息相关。

这家公司的加班文化，我深有体会，去年11月初，各个项目组长在工作群先后通知强制要求加班，并不给你机会以及理由请假，反正加班给出的理由就是冲刺冲刺。

当时有同事用dingding和其他同事讨论加班的各种不情愿，聊天记录居然被公司扒出来并认为其散播负面言论，邮件全体对其进行警告，我大为震惊，当然这名同事后来也进入了裁员名单。

警告信发出之后越来越多的同事周末有一天不能来公司办公，其实他们在家根本也没闲着，这时候大老板急了，又发了这样的一封邮件。

（我看到这封邮件的时候，心里的想法就是作为公司的领头人，这格局不是一般的小,仅代表个人意见）

显然这封邮件是给那些不坚持10 10 7的人看的，对于那些不加班的人等待着的自然是优化。就这样还是有些同事继续坚持着10 10 7，在元旦之前大家终于把所有项目全部成功交付，本以为等待着大家的是老板分享喜悦的成果，结果等来的却是3/2的裁员，后来大家想明白了，就是催促着大家感觉把项目做完，裁掉你们。其中有位同事，前一天通宵加完班，第二天就被裁了，那时候整个办公室一片哗然。

2.持续加班住进icu

朋友的同事，据说刚刚升为一名奶爸，每天十点前不曾下班，大家问他为何这么拼，给出的理由是我刚刚生了娃，买了房子，工作一点不敢懈怠，怕惹得领导不高兴随时让我滚蛋。

是啊,谁想加班，谁愿意加班天天守着个破电脑，可是生活让我们不得不加班，不得不向一些不合理的规定屈服。

3.中国电科龙哥

这两天龙哥火遍了各个社交网络，龙哥痛批强制加班员工事情为什么能火，为什么传播速度这么快，我猜测是龙哥一人之言说出了很多打工人的心声，引起网友一片共鸣。

不过央视网的这文字怕是惹得大家一顿p喽。

职场人偶尔加下班，没有任何问题，毕竟工作中肯定会遇到一些紧急事件需要及时处理，作为公司员工，加班赶下进度也是应该的，可是长期被自愿加班就不合时宜了，毕竟身体是革命的本钱，一旦因为长期加班，出现问题就得不偿失了，所以加班文化不可取，尤其是超

如果你接触过公司的面试工作，一定见过很多来自大公司的渣渣。这些人的薪资和职位，比你高出很多，但能力却非常一般。

如果能力属实，我们大可直接把这些大公司的员工打包接收，也免了乱七八糟的面试工作。但可惜的是，水货的概率通常都比较大，新的公司也并不相信他们的能力。尤其是这两年互联网炸了锅，猪飞的日子不再，这种情况就更加多了起来。

反过来说也一样成立，就像是xjjdog在青岛混了这么多年，一旦再杀回北上广，也一样是落的下乘的评价。

除了自身的努力之外，你在上家公司混的差，还与你在组织架构中所处于的位置和组织架构本身有关。

一般公司会有两种组织架构方式：垂直化划分和层级化划分。

1. 垂直划分

垂直划分，多以业务线为模型进行划分。各条业务线共用公司行政资源，相互之间关联不大。

各业务线之间，内部拥有自治权。

如上图所示，公司共有四个业务线。

• 
  

  业务线A，有前端和后端开发。因为成员能力比较强，所以没有测试运维等职位；

  
  


• 
  

  业务线B倡导全栈技能，开发后台前端一体化；

  
  


• 
  

  业务线C的管理能力比较强，仅靠少量自有研发，加上大量的外包，能够完成一次性工作。

  
  


• 
  

  业务线D是传统的互联网方式，专人专岗，缺什么招什么，不提倡内部转岗

  
  

运行模式

1. 
   

   业务线A缺人，缺项目，与业务线BCD无任何关系，不允许借调

   
   


2. 
   

   业务线发展良好，会扩大规模；其他业务线同学想要加入需要经过复杂的流程，相当于重新找工作

   
   


3. 
   

   业务线发展萎靡，会缩减人员，甚至会整体砍掉。优秀者会被打散吸收进其他业务线

   
   

好处

1. 
   

   业务线之间存在竞争关系，团队成员有明确的奋斗目标和危机意识

   
   


2. 
   

   一条业务线管理和产品上的失败，不会影响公司整体运营

   
   


3. 
   

   可以比较容易的形成单向汇报的结构，避免成本巨大且有偏差的多重管理

   
   


4. 
   

   便于复制成功的业务线，或者找准公司的发展重点

   
   

坏处

1. 
   

   对业务线主要分管领导的要求非常高

   
   


2. 
   

   多项技术和产品重复建设，容易造成人员膨胀，成本浪费

   
   


3. 
   

   部门之间隔阂加大，共建、合作困难，与产品化相逆

   
   


4. 
   

   业务线容易过度自治，脱离掌控

   
   


5. 
   

   太激进，大量过渡事宜需要处理

   
   

修订

为了解决上面存在的问题，通常会有一个协调和监管部门，每个业务线，还需要有响应的协调人进行对接。以以往的观察来看，效果并不会太好。因为这样的协调，多陷于人情沟通，不好设计流程规范约束这些参与人的行为。

在公司未摸清发展方向之前，并不推荐此方式的改革。它的本意是通过竞争增加部门的进取心，通过充分授权和自治发挥骨干领导者的作用。但在未有成功案例之前，它的结果变成了：寄希望于拆分成多个小业务线，来解决原大业务线存在的问题。所以依然是处于不太确定的尝试行为。

2. 水平划分

水平划分方式，适合公司有确定的产品，并能够形成持续迭代的团队。

它的主要思想，是要打破“不会做饭的项目经理不是好程序员”的思维，形成专人专业专岗的制度。

这种方式经历了非常多的互联网公司实践，可以说是最节约研发成本，能动性最高的组织方式。主要是因为：

• 
  

  研发各司其职，做好自己的本职工作可以避免任务切换、沟通成本，达到整体最优

  
  


• 
  

  个人单向汇报，组织层级化，小组扁平化。“替领导负责，就是替公司负责”

  
  


• 
  

  任何职位有明确的JD，可替换性高，包括小组领导

  
  

这种方式最大的问题就是，对团队成员的要求都很高。主动性与专业技能都有要求，需要经过严格的面试筛选。

坏处

• 
  

  是否适合项目类公司，存疑

  
  


• 
  

  存在较多技术保障部门，公共需求 下沉容易造成任务积压

  
  


• 
  

  需要对其他部门进行整合，才能发挥更大的价值

  
  

分析

如上图，大体会分为三层。

• 
  

  技术保障，保障公司的底层技术支撑，问题处理和疑难问题解决。小组多但人少，职责分明

  
  


• 
  

  基础业务，公司的旗舰业务团队，需求变更小但任何改动都非常困难。团队人数适中

  
  


• 
  

  项目演化，纯项目，可以是一锤子买卖，也可以是服务升级，属于朝令夕改类需求的聚居地。人数最多

  
  

可以看到项目演化层，多是脏活，有些甚至是尝试性的项目-----这是合理的。

1. 
   

   技术保障和基础业务的技术能力要求高，业务稳定，适合长期在公司发展，发展属性偏技术的人群，流动性小，招聘困难

   
   


2. 
   

   项目演化层，业务多变，项目奖金或者其他回报波动大，人员流动性高，招聘容易

   
   

成功的孵化项目，会蜕变成产品，或者基础业务，并入基础业务分组。

从这种划分可以看出，一个人在公司的命运和发展，在招聘入职的时候就已经确定了。应聘人员可以根据公司的需求进行判断，提前预知自己的倾向。

互联网公司大多数将项目演化层的人员当作炮灰，因为他们招聘容易，团队组件迅速，但也有很多可能获得高额回报，这也是很多人看中的。

3.组合

组合一下垂直划分和层级划分，可以是下面这种效果。

采用层级+垂直方式进行架构。即：首选层级模式，然后在项目演化层采用垂直模式，也叫做业务线，拥有有限的自治权。

为每一个业务线配备一个与下层产品化或者技术保障对接的人员。

绩效方面，上层的需求为下层的实现打分。基础业务和技术保障，为绿色的协调人员打分。他们的利益是一致的。

End

大公司出来的并不一定是精英，小公司出来的也并不一定是渣渣。这取决于他在公司的位置和所从事的内容。核心部门会得到更多的利益，而边缘的尝试性部门只能吃一些残羹剩饭。退去公司的光环，加上平庸的项目经历，竞争力自然就打上一个折扣。

以上，仅限IT行业哦。赵家人不在此列。

问题

最近公司项目上遇到了扫码枪因搜狗/微软/百度/QQ等输入法在中文状态下，使用扫码枪扫码会丢失字符的问题

思考

这种情况是由于扫码枪的硬件设备，在输入的时候，是模拟用户键盘的按键来实现的字符输入的，所以会触发输入法的中文模式，并且也会触发输入法的自动联想。那我们可以针对这个来想解决方案。

方案一

首先想到的第一种方案是，监听keydown的键盘事件，创建一个字符串数组，将每一个输入的字符进行比对，然后拼接字符串，并回填到输入框中，下面是代码：

function onKeydownEvent(e) {

  this.code = this.code || ''

  const shiftKey = e.shiftKey

  const keyCode = e.code

  const key = e.key

  const arr = ['Q', 'W', 'E', 'R', 'T', 'Y', 'U', 'I', 'O', 'P', 'A', 'S', 'D', 'F', 'G', 'H', 'J', 'K', 'L', 'Z', 'X', 'C', 'V', 'B', 'N', 'M', '1', '2', '3', '4', '5', '6', '7', '8', '9', '0', '-']

  this.nextTime = new Date().getTime()

  const timeSpace = this.nextTime - this.lastTime

  if (key === 'Process') { // 中文手动输入

    if (this.lastTime !== 0 && timeSpace <= 30) {

      for (const a of arr) {

        if (keyCode === 'Key' + a) {

          if (shiftKey) {

            this.code += a

          } else {

            this.code += a.toLowerCase()

          }

          this.lastTime = this.nextTime

        } else if (keyCode === 'Digit' + a) {

          this.code += String(a)

          this.lastTime = this.nextTime

        }

      }

      if (keyCode === 'Enter' && timeSpace <= 30) {

        if (String(this.code)) {

          // TODO

          dosomething....

        }

        this.code = ''

        this.nextTime = 0

        this.lastTime = 0

      }

    }

  } else {

    if (arr.includes(key.toUpperCase())) {

      if (this.lastTime === 0 && timeSpace === this.nextTime) {

        this.code = key

      } else if (this.lastTime !== 0 && timeSpace <= 30) {

        // 30ms以内来区分是扫码枪输入，正常手动输入时少于30ms的

        this.code += key

      }

      this.lastTime = this.nextTime

    } else if (arr.includes(key)) {

      if (this.lastTime === 0 && timeSpace === this.nextTime) {

        this.code = key

      } else if (this.lastTime !== 0 && timeSpace <= 30) {

        this.code += String(key)

      }

      this.lastTime = this.nextTime

    } else if (keyCode === 'Enter' && timeSpace <= 30) {

      if (String(this.code)) {

        // TODO

        dosomething()

      }

      this.code = ''

      this.nextTime = 0

      this.lastTime = 0

    } else {

      this.lastTime = this.nextTime

    }

  }

}

这种方案能解决部分问题，但是在不同的扫码枪设备，以及不同输入法的情况下，还是会出现丢失问题

方案二

使用input[type=password]来兼容不同输入的中文模式，让其只能输入英文，从而解决丢失问题

这种方案网上也有不少的参考

# 解决中文状态下扫描枪扫描错误

# input type=password 取消密码提示框

使用password密码框确实能解决不同输入法的问题，并且Focus到输入框，输入法会被强制切换为英文模式

添加autocomplete="off" 或 autocomplete="new-password"属性

官方文档：
# 如何关闭表单自动填充

但是在Chromium内核的浏览器，不支持autocomplete="off"，并且还是会出现这种自动补全提示：

上面的属性并没有解决浏览器会出现密码补全框，并且在输入字符后，浏览器还会在右上角弹窗提示是否保存：

先解决密码补全框，这里我想到了一个属性readonly，input原生属性。input[type=password]在readonly
时，是不会有密码补全的提示，并且也不会弹窗提示密码保存。

那好，我们就可以在输入前以及输入完成后，将input[type=password]立即设置成readonly

但是需要考虑下面几种情况：

• 获取焦点/失去焦点时


• 当前输入框已focus时，再次鼠标点击输入框


• 扫码枪输出完成最后，输入Enter键时，如果清空输入框，这时候也会显示自动补全


• 清空输入框时


• 切换离开页面时

这几种情况都需要处理，将输入框变成readonly

我用vue+element-ui实现了一份，贴上代码：

<template>

  <div class="scanner-input">

    <input class="input-password" :name="$attrs.name || 'one-time-code'" type="password" autocomplete="off" aria-autocomplete="inline" :value="$attrs.value" readonly @input="onPasswordInput">

    <!-- <el-input ref="scannerInput" v-bind="$attrs" v-on="$listeners" @input="onInput"> -->

    <el-input ref="scannerInput" :class="{ 'input-text': true, 'input-text-focus': isFocus }" v-bind="$attrs" v-on="$listeners">

      <template v-for="(_, name) in $slots" v-slot:[name]>

        <slot :name="name"></slot>

      </template>

      <!-- <slot slot="suffix" name="suffix"></slot> -->

    </el-input>

  </div>

</template>



<script>

export default {

  name: 'WispathScannerInput',

  data() {

    return {

      isFocus: false

    }

  },

  beforeDestroy() {

    this.$el.firstElementChild.setAttribute('readonly', true)

    this.$el.firstElementChild.removeEventListener('focus', this.onPasswordFocus)

    this.$el.firstElementChild.removeEventListener('blur', this.onPasswordBlur)

    this.$el.firstElementChild.removeEventListener('blur', this.onPasswordClick)

    this.$el.firstElementChild.removeEventListener('mousedown', this.onPasswordMouseDown)

    this.$el.firstElementChild.removeEventListener('keydown', this.oPasswordKeyDown)

  },

  mounted() {

    this.$el.firstElementChild.addEventListener('focus', this.onPasswordFocus)

    this.$el.firstElementChild.addEventListener('blur', this.onPasswordBlur)

    this.$el.firstElementChild.addEventListener('click', this.onPasswordClick)

    this.$el.firstElementChild.addEventListener('mousedown', this.onPasswordMouseDown)

    this.$el.firstElementChild.addEventListener('keydown', this.oPasswordKeyDown)



    const entries = Object.entries(this.$refs.scannerInput)

    // 解决ref问题

    for (const [key, value] of entries) {

      if (typeof value === 'function') {

        this[key] = value

      }

    }

    this['focus'] = this.$el.firstElementChild.focus.bind(this.$el.firstElementChild)

  },

  methods: {

    onPasswordInput(ev) {

      this.$emit('input', ev.target.value)

      if (ev.target.value === '') {

        this.$el.firstElementChild.setAttribute('readonly', true)

        setTimeout(() => {

          this.$el.firstElementChild.removeAttribute('readonly')

        })

      }

    },

    onPasswordFocus(ev) {

      this.isFocus = true

      setTimeout(() => {

        this.$el.firstElementChild.removeAttribute('readonly')

      })

    },

    onPasswordBlur() {

      this.isFocus = false

      this.$el.firstElementChild.setAttribute('readonly', true)

    },

    // 鼠标点击输入框一瞬间，禁用输入框

    onPasswordMouseDown() {

      this.$el.firstElementChild.setAttribute('readonly', true)

    },

    oPasswordKeyDown(ev) {

      // 判断enter键

      if (ev.key === 'Enter') {

        this.$el.firstElementChild.setAttribute('readonly', true)

        setTimeout(() => {

          this.$el.firstElementChild.removeAttribute('readonly')

        })

      }

    },

    // 点击之后，延迟200ms后放开readonly，让输入框可以输入

    onPasswordClick() {

      if (this.isFocus) {

        this.$el.firstElementChild.setAttribute('readonly', true)

        setTimeout(() => {

          this.$el.firstElementChild.removeAttribute('readonly')

        }, 200)

      }

    },

    onInput(_value) {

      this.$emit('input', _value)

    },

    getList(value) {

      this.$emit('input', value)

    }

    // onChange(_value) {

    //   this.$emit('change', _value)

    // }

  }

}

</script>



<style lang="scss" scoped>

.scanner-input {

  position: relative;

  height: 36px;

  width: 100%;

  display: inline-block;

  .input-password {

    width: 100%;

    height: 100%;

    border: none;

    outline: none;

    padding: 0 16px;

    font-size: 14px;

    letter-spacing: 3px;

    background: transparent;

    color: transparent;

    // caret-color: #484848;

  }

  .input-text {

    font-size: 14px;

    width: 100%;

    height: 100%;

    position: absolute;

    top: 0;

    left: 0;

    pointer-events: none;

    background-color: transparent;

    ::v-deep .el-input__inner {

      // background-color: transparent;

      padding: 0 16px;

      width: 100%;

      height: 100%;

    }

  }



  .input-text-focus {

    ::v-deep .el-input__inner {

      outline: none;

      border-color: #1c7af4;

    }

  }

}

</style>

至此，可以保证input[type=password]不会再有密码补全提示，并且也不会再切换页面时，会弹出密码保存弹窗。
但是有一个缺点，就是无法完美显示光标。如果用户手动输入和删除，使用起来会有一定的影响。

我想到过可以使用模拟光标，暂时不知道可行性。有哪位同学知道怎么解决的话，可以私信我，非常感谢

这是一篇由 Seata 的官网上一篇叫做“关于新版雪花算法的答疑”的文章引发的思考。

seata.io/zh-cn/blog/…

还是有点意思的，结合自己的理解和代码，加上画几张图来拆解一下 Seata 里面的“改良版雪花算法”。

虽然是在 Seata 里面看到的，但是本篇文章的内容和 Seata 框架没有太多关系，反而和数据库的基础知识有关。

所以，即使你不了解 Seata 框架，也不影响你阅读。

当你理解了这个类的工作原理之后，你完全可以把这个只有 100 多行的类搬运到你的项目里面，然后就变成你的了。

dddd（懂的都懂）！

先说问题

雪花算法的使用场景：

如果你的项目中涉及到需要一个全局唯一的流水号，比如订单号、流水号之类的，又或者在分库分表的情况下，需要一个全局唯一的主键 ID 的时候，就需要一个算法能生成出这样“全局唯一”的数据。

一般来说，我们除了“全局唯一”这个基本属性之外，还会要求生成出来的 ID 具有“递增趋势”，这样的好处是能减少 MySQL 数据页分裂的情况，从而减少数据库的 IO 压力，提升服务的性能。

此外，在当前的市场环境下，不管你是啥服务，张口就是高并发，我们也会要求这个算法必须得是“高性能”的。

雪花算法，就是一个能生产全局唯一的、递增趋势的、高性能的分布式 ID 生成算法。

关于雪花算法的解析，网上相关的文章比雪花还多，这个玩意，应该是“面试八股文”中重点考察模块，分布式领域中的高频考题之一，如果是你的盲区的话，可自行去了解一下。

比如一个经典的面试题就是：

雪花算法最大的缺点是什么？

背过题的小伙伴应该能立马答出来：时钟敏感。

因为在雪花算法中，由于要生成单调递增的 ID，因此它利用了时间的单调递增性，所以是强依赖于系统时间的。

如果系统时间出现了回拨，那么生成的 ID 就可能会重复。

而“时间回拨”这个现象，是有可能出现的，不管是人为的还是非人为的。

当你回答出这个问题之后，面试官一般会问一句：

那如果真的出现了这种情况，应该怎么办呢？

很简单，正常来说只要不是不是有人手贱或者出于泄愤的目的进行干扰，系统的时间漂移是一个在毫秒级别的极短的时间。

所以可以在获取 ID 的时候，记录一下当前的时间戳。然后在下一次过来获取的时候，对比一下当前时间戳和上次记录的时间戳，如果发现当前时间戳小于上次记录的时间戳，所以出现了时钟回拨现象，对外抛出异常，本次 ID 获取失败。

理论上当前时间戳会很快的追赶上上次记录的时间戳。

但是，你可能也注意到了，“对外抛出异常，本次 ID 获取失败”，意味着这段时间内你的服务对外是不可使用的。

比如，你的订单号中的某个部分是由这个 ID 组成的，此时由于 ID 生成不了，你的订单号就生成不了，从而导致下单失败。

再比如，在 Seata 里面，如果是使用数据库作为 TC 集群的存储工具，那么这段时间内该 TC 就是处于不可用状态。

你可以简单的理解为：基础组件的错误导致服务不可用。

再看代码

基于前面说的问题，Seata 才提出了“改良版雪花算法”。

seata.io/zh-cn/blog/…

在介绍改良版之前，我们先把 Seata 的源码拉下来，瞅一眼。

在源码中，有一个叫做 IdWorker 的类：

io.seata.common.util.IdWorker

再来看一下它的提交记录：

2020 年 5 月 4 日第一次提交，从提交时的信息可以看出来，这是把分布式 ID 的生成策略修改为 snowflake，即雪花算法。

同时我们也能在代码中找到前面提到的“对外抛出异常，本次 ID 获取失败”相关代码，即 nextId  方法，它的比较方式就是用当前时间戳和上次获取到的时间戳做对比：

io.seata.common.util.IdWorker#nextId

这个类的最后一次提交是 2020 年 12 月 15 日：

这一次提交对于 IdWorker 这个类进行了大刀阔斧的改进，可以看到变化的部分非常的多：

我们重点关注刚刚提到的 nextId 方法：

整个方法从代码行数上来看都可以直观的看到变化，至少没有看到抛出异常了。

这段代码到底是怎么起作用的呢？

首先，我们得理解 Seata 的改良思路，搞明白思路了，再说代码就好理解一点。

在前面提到的文章中 Seata 也说明了它的核心思路：

原版的雪花算法 64 位 ID 是分配这样的：

可以看到，时间戳是在最前面的，因为雪花算法利用了时间的单调递增的特性。

所以，如果前面的时间戳一旦出现“回退”的情况，即打破了“时间的单调递增”这个前提条件，也就打破了它的底层设计。

它能怎么办？

它只能给你抛出异常，开始摆烂了。

可以看到节点 ID 长度为二进制的 10 位，也就是说最多可以服务于 1024 台机器，所以你看 Seata 最开始提交的版本里面，有一个在 1024 里面随机的动作。

因为算法规定了，节点 ID 最多就是 2 的 10 次方，所以这里的 1024 这个值就是这样来的：

包括后面有大佬觉得用这个随机算法一点都不优雅，就把这部分改成了基于 IP 去获取：

看起来有点复杂，但是我们仔细去分析最后一行：

return ((ipAddressByteArray[ipAddressByteArray.length - 2] & 0B11) << Byte.SIZE) + (ipAddressByteArray[ipAddressByteArray.length - 1] & 0xFF);

变量 & 0B11 运算之后的最大值就是 0B11 即 3。

Byte.SIZE = 8。

所以，3 << 8，对应二进制 1100000000，对应十进制 768。

变量 & 0xFF 运算之后的最大值就是 0xFF 即 255。

768+255=1023，取值范围都还是在 [0,1023] 之间。

然后你再看现在最新的算法里面，官方的老哥们认为获取 IP 的方式不够好：

所以又把这个地方从使用 IP 地址改成了获取 Mac 地址。

最后一行是这样的：

return ((mac[4] & 0B11) << 8) | (mac[5] & 0xFF);

那么理论上的最大值就是 768 | 255 ，算出来还是 1023。

所以不管你怎么玩出花儿来，这个地方搞出来的数的取值范围就只能是 [0,1023] 之间。

别问，问就是规定里面说了，算法里面只给节点 ID 留了 10 位长度。

最后，就是这个 12 位长度的序列号了：

这个玩意没啥说的，就是一个单纯的、递增的序列号而已。

既然 Seata 号称是改良版，那么具体体现在什么地方呢？

简单到你无法想象：

是的，仅仅是把时间戳和节点 ID 换个位置就搞定了。

然后每个节点的时间戳是在 IdWorker 初始化的时候就设置完成了，具体体现到代码上是这样的：

io.seata.common.util.IdWorker#initTimestampAndSequence

在获取 ID 的过程中，只有在初始化的时候获取过一次系统时间，之后和它就再也没有关系了。

所以，Seata 的分布式 ID 生成器，不再依赖于时间。

然后，你再想想另外一个问题：

由于序列号只有 12 位，它的取值范围就是 [0,4095]。如果我们序列号就是生成到了 4096 导致溢出了，怎么办呢？

很简单，序列号重新归 0，溢出的这一位加到时间戳上，让时间戳 +1。

那你再进一步想想，如果让时间戳 +1 了，那么岂不是会导致一种“超前消费”的情况出现，导致时间戳和系统时间不一致了？

朋友，慌啥啊，不一致就不一致呗，反正我们现在也不依赖于系统时间了。

然后，你想想，如果出现“超前消费”，意味着什么？

意味着在当前这个毫秒下，4096 个序列号不够用了。

4096/ms，约 400w/s。

你啥场景啊，怎么牛逼？

（哦，原来是面试场景啊，那懂了~）

另外，官网还抛出了另外一个问题：这样持续不断的"超前消费"会不会使得生成器内的时间戳大大超前于系统的时间戳，从而在重启时造成 ID 重复？

你想想，理论上确实是有可能的。假设我时间戳都“超前消费”到一个月以后了。

那么在这期间，你服务发生重启时我会重新获取一次系统时间戳，导致出现“时间回溯”的情况。

理论上确实有可能。

但是实际上...

看看官方的回复：

别问，问就是不可能，就算出现了，最先崩的也不是我这个地方。

说了这么多其实就记住住这个图，就完事了：

那么问题又来了：

改良版的算法是单调递增的吗？

在单节点里面，它肯定是单调递增的，但是如果是多个节点呢？

在多个节点的情况下，单独看某个节点的 ID 是单调递增的，但是多个节点下并不是全局单调递增。

因为节点 ID 在时间戳之前，所以节点 ID 大的，生成的 ID 一定大于节点 ID 小的，不管时间上谁先谁后。

这一点我们也可以通过代码验证一下，代码的意思是三个节点，每个节点各自生成 5 个 ID：

从输出来看，一眼望去，生成的 ID 似乎是乱序的，至少在全局的角度下，肯定不是单调递增的：

但是我们把输出按照节点 ID 进行排序，就变成了这样，单节点内严格按照单调递增，没毛病：

而在原版的雪花算法中，时间戳在高位，并且始终以系统时钟为准，每次生成的时候都会严格和系统时间进行对比，确保没有发生时间回溯，这样可以保证早生成的 ID 一定小于晚生成的 ID ，只有当 2 个节点恰好在同一时间戳生成 ID 时，2 个 ID 的大小才由节点 ID 决定。

这样看来，Seata 的改进算法是不是错的？

先别急，继续往下看。

分析一波

分析之前，先抛出官方的回答：

先来一个八股文热身：

请问为什么不建议使用 UUID 作为数据库的主键 ID ？

就是为了避免触发 MySQL 的页分裂从而影响服务性能。

比如当前主键索引的情况是这样的：

如果来了一个  433，那么直接追加在当前最后一个记录 432 之后即可。

但是如果我们要插入一个 20 怎么办呢？

那么数据页 10 里面已经放满了数据，所以会触发页分裂，变成这样：

进而导致上层数据页的分裂，最终变成这样的一个东西：

上面的我们可以看出页分裂伴随着数据移动，所以我们应该尽量避免。

理想的情况下，应该是把一页数据塞满之后，再新建另外一个数据页，这样 B+ tree 的最底层的双向链表永远是尾部增长，不会出现上面画图的那种情况：在中间的某个节点发生分裂。

那么 Seata 的改良版的雪花算法在不具备“全局的单调递增性”的情况下，是怎么达到减少数据库的页分裂的目的的呢？

我们还是假设有三个节点，我用 A，B，C 代替，在数值上 A < B < C，采用的是改良版的雪花算法，在初始化的情况下是这样的。

假设此时，A 节点申请了一个流水号，那么基于前面的分析，它一定是排在 A-seq1 之后，B-seq1 之前的。

但是这个时候数据页里面的数据满了，怎么办？

分裂呗：

又来了 A-seq3 怎么办？

问题不大，还放的下：

好，这个时候数据页 7 满了，但是又来了 A-seq4，怎么办？

只有继续分裂了：

看到这个分裂的时候，你有没有嗦出一丝味道，是不是有点意思了？

因为在节点 A 上生成的任何 ID 都一定小于在节点 B 上生成的任何 ID，节点 B 和节点 C 同理。

在这个范围内，所有的 ID 都是单调递增的：

而这样的范围最多有多少个？

是不是有多少个节点，就有多少个？

那么最多有多少个节点？

2 的 10 次方，1024 个节点。

所以官方的文章中有这样的一句话：

新版算法从全局角度来看，ID 是无序的，但对于每一个 workerId，它生成的 ID 都是严格单调递增的，又因为 workerId 是有限的，所以最多可划分出 1024 个子序列，每个子序列都是单调递增的。

经过前面的分析，每个子序列总是单调递增的，所以每个子序列在有限次的分裂之后，最终都会达到稳态。

或者用一个数学上的说法：该算法是收敛的。

再或者，放个图看看：

我想说作者画的时候尽力了，至于你看懂看不懂的，就看天意了。

页分裂

前面写的所有内容，你都能在官网上前面提到的两个文章中找到对应的部分。

但是关于页分裂部分，官方并没有进行详细说明。本来也是这样的，人家只是给你说自己的算法，没有必要延伸的太远。

“刚才说到了页分裂”，以面试官的嘴脸怎么可能放过你，“展开讲讲？”

链接已放，自行展开：

mysql.taobao.org/monthly/202…

还是先搞个图：

问，在上面的这个 B+ tree 中，如果我要插入 9，应该怎么办？

因为数据页中已经没有位置了，所以肯定要触发页分裂。

会变成这样：

这种页分裂方式叫做插入点（insert point）分裂。

其实在 InnoDB 中最常用的是另外一种分裂方式，中间点（mid point）分裂。

如果采用中间点（mid point）分裂，上面的图就会变成这样：

即把将原数据页面中的 50% 数据移动到新页面，这种才是普遍的分裂方法。

这种分裂方法使两个数据页的空闲率都是 50%，如果之后的数据在这两个数据页上的插入是随机的话，那么就可以很好地利用空闲空间。

但是，如果后续数据插入不是随机，而是递增的呢？

比如我插入 10 和 11。

插入 10 之后是这样的：

插入 11 的时候又要分页了，采用中间点（mid point）分裂就变成了这样：

你看，如果是在递增的情况下，采用中间点（mid point）分裂，数据页 8 和 20 的空间利用率只有 50%。

因为数据的填充和分裂的永远是右侧页面，左侧页面的利用率只有 50%。

所以，插入点（insert point）分裂是为了优化中间点（mid point）分裂的问题而产生的。

InnoDB 在每个数据页上专门有一个叫做 PAGE_LAST_INSERT 的字段，记录了上次插入位置，用来判断当前插入是是否是递增或者是递减的。

如果是递减的，数据页则会向左分裂，然后移动上一页的部分数据过去。

如果判定为递增插入，就在当前点进行插入点分裂。

比如还是这个图：

上次插入的是记录 8，本次插入 9，判断为递增插入，所以采用插入点分裂，所以才有了上面这个图片。

好，那么问题就来了，请听题：

假设出现了这种情况，阁下又该如何应对？

在上面这个图的情况下，我要插入 10 和 9：

当插入 10 的时候，按 InnoDB 遍历 B+ tree 的方法会定位到记录 8，此时这个页面的 PAGE_LAST_INSERT 还是 8。所以会被判断为递增插入，在插入点分裂：

同理插入 9 也是这样的：

最终导致 9、10、11 都独自占据一个 page，空间利用率极低。

问题的根本原因在于每次都定位到记录 8（end of page），并且都判定为递增模式。

哦豁，你说这怎么办？

答案就藏在这一节开始的时候放的链接中：

前面所画的图都是在没有并发的情况下展开的。

但是在这个部分里面，牵扯到了更为复杂的并发操作，同时也侧面解释了为什么 InnoDB 在同一时刻只能有有一个结构调整（SMO）进行。

这里面学问就大了去了，有兴趣的可以去了解一下 InnoDB 在 B+ tree 并发控制上的限制，然后再看看 Polar index 的破局之道。

反正我是学不动了。

哦，对了。前面说了这么多，还只是聊了页分裂的情况。

有分裂，就肯定有合并。

那么什么时候会触发页合并呢？

页合并会对我们前面探讨的 Seata 的改良版雪花算法带来什么影响呢？

别问了，别问了，学不动了，学不动了。