碎碎念

前几天突然想起来整理备忘录，突然发现了一篇22年写的规划，快三年了，自己啥也没做，要说有成长吧，应该也有。这一年以来一直持续的在看书学习，也算坚持下来了，看了不少关于历史、演讲的书籍，尤其是历史书对我的影响比较大，一个历史人物的一生也就在潦潦草草几页纸，也感叹人生的短暂。还记得初中那会，我还是历史课代表（印象中是，我记得我每次都要给班级同学发卷子），现在已经忘记了那些历史知识。
今年刚好是毕业的第十个年头，在互联网干了十年，赶上了互联网的尾巴，没吃肉喝了点汤，薪水一直还可以，就是没有大的发展，还是一如既往的一线牛马。再过个年周岁都37了，也算个大龄程序员了，心智还像个小孩子，做事上还是斤斤计较、吹毛求疵，看着新来的大学生，自己是真的老了，不是心理老，是身体老，啥运动也搞不动了，脸上的皱纹也多了，连衣服都买一堆一样的。

回顾自己的前半生，也算是个命运多舛的人。

我出生在一个贫困县小镇双职工家庭，父亲是一个教师，母亲是一个工人，看起来比身边很多同事都强上不少，不过随着工人下岗潮的到来，母亲再就没有了收入，连下岗的赔付款都没有，从此生活上也非常拮据了。还记得小时候因为没有冰箱，吃到的肉都是用盐浸过的，这样才能放的住，所以肉的味道也和新买来的不一样，不过我的父母还是努力给我最好的生活，他们吃小米让我吃大米。父亲是一个情绪极其不稳定的人，尝尝和母亲吵架，因为我的学习吵架，在整个童年记忆里，我只记得我很小时候他经常带我去公园玩，我很开心，但到了上学期间只记得吵架，不停的吵架。也因为父亲的性格，和亲戚关系都很差，不过现在想想这只是一部分原因，还是因为我们家太穷了，在别人眼里你没有任何价值，事办不了，玩也玩不到一起，索性就不要联系了，那时候的自卑感就越发明显，我发现我和其他人不同，别人轻易可以有的，我都没有，全班同学都有补课，我也没有，我是班级里最另类那个。

我小学时候学习并不好，好的时候10多名，不好的时候40多名，好在数学不错，上了初中，我的记忆力开始发挥特长，我在全班可以稳定在前5名，甚至我还记得考过全校的第十名，那可能是我在中学时最高光的时刻，那会在胡同里我都是当做别人家的孩子，不过在我父亲眼里，我就是比不上他们单位某某的孩子。到了高中，我开始去网吧打游戏，把自己的饭钱和零花钱省下来，去打游戏，去逃避现实，我不再想学习，还记得当年考试前我去翻物理书，记得清清楚楚的f=ma，不过那时候成绩也没有太差，全年级100名左右，努力点上个一本，差点上个二本。果然不出所料，分数线刚好低了几分，二本录取了。后面我决定复习，现在想想也不知道为什么自己会这么决定，可能还是不甘心吧，那会初中成绩差不多的至少都考上了一本，复习那会成绩还不错，不过那时候我就发现了我的心理素质越来越差，也导致了最终发挥失常，报考的院校全部滑档，最后被一所省内二本录取了，那时候我也死心了，就这样去上学吧。可能我骨子里还是那个不服输的性格，军训了一周左右，我每天基本睡不着，室友有喝酒的、抽烟的、打牌的，和这些人做同学是我一辈子都没想过的，我就给家里打了一通电话，我要回去复读，但父亲是不同意的，他觉得不能再复读了，后面是母亲和叔叔来接的我，我自己去学校找的老师，老师给我安排到了他的班级，我也是那年考上了985（最后走了提前批，比录取分高了50分，虽然有些后悔）。

虽然看起来我个子不高，也很瘦弱，但从小胡同里的孩子王，带着大家踢球，球机还不错，在学校也能交到一些朋友，从那时候开始我就是开始有了自己的主意，敢和高年级的踢球甚至打架，敢和老师对着干，但做所有的事都会有自己的原则和理由。还记得高中那会，班主任因为收礼，就要把我从第一排移动到倒数第二排，美其名曰是照顾近视眼的同学，我当时就发火了，谁爱换谁换，我就不换，从那时候起可能也注定我的学习老师不在管，不过他那个人也没管过谁，就知道收礼。现在想起来，我的初中班主任，是个特别好的人，她和年轻也很漂亮，大家都非常喜欢她，她也喜欢学习成绩好的同学，所以就这样我在初中时候的成绩是越来越好，同样高中复习班的老师也非常好。可能还是家庭的原因，我的自卑感一直很强，毕业后再也没和老师联系过。

读研也算是一个幸运，本该保研的却因为自己英语太差，没过6级错过了。找工作受挫，开始临时考研，连资料都是同学给的（他不考了），学了三个月过了分数线，虽然找了老师但最后并没有录取我，那时候还是很自卑，觉得还是自己太差了。不过女朋友的一句话改变了我的一生，他让我去碰碰运气，肯定有专业没录取完，刚到那计算机的老师就问你是本校的么，是的话就你了，就这样我被计算机专业录取了，因祸得福。也算一段神奇的经历了，所有人都觉得我不可能考上研究生，就学了3个月，但我真的考上了，我是通过背书的方式，我连为啥需要这个公式来解这个题可能都清楚，但是我记下来了（父亲的遗传，也算一种天赋吧）。

读研期间，我意外的被某公司挑选去实习，又意外的被淘汰（理由居然是我们校招的名额给了清北的，所以没坑了）。索性回到学校，那时候秋招都过去了很多公司，常见的大厂都结束了招聘，我赶在尾巴上拿到了一个还算幸运的几个offer，最后选择去了北京（因为薪水高）。

工作后，我先后跳槽了5次，中间有长有短，最长的4年半左右，最短的1个月，我算是一个有主见的人，当发现周围环境对自己不利的时候，就会主动求变，去找新的机会，那会跳槽是一个很常见的事，不过太多就不好了，也导致了我职业中期的困难重重，虽然我是985本硕毕业，但履历上看起来并不好，大小公司穿插起来，怎么看也不是怎么靠谱，也从而在每家公司都做的一般。虽然每个公司的同事们都比较认可我，做事踏实，有想法，不过在老板眼里，这些都不是啥优势，我的性格和自卑感让我的职业发展遇到了瓶颈，不知道如何和老板相处，更不懂如何向上管理，做的再多也没用，老黄牛一样的工作方式也只能是公司里的老黄牛。目前在这家公司已经工作了四年多的时间，经历了两次晋升答辩均已失败告终，虽然自己有些不甘，但也不太在意这些，岁数大了跳槽也难了，在国内这个市场经验和能力不重要，重要的是年纪，也挺奇怪的，小年轻的刚毕业拿着十年工作经验的人50%左右的薪水，却缺干着20%的工作，老板说新人是未来，老人学不动了，也干不动了，可能这也是国内独有的景色，什么行业最后都能和打螺丝一样。

失败的投资

几年前就有换房的想法，这个房子隔音差楼上楼下的出租噪音让我很难入睡，多个夜晚都是凌晨四五点才入睡。不过家里人根本不理解我，我也理解不了我自己，为啥加班加点的工作，到最后连一个像样的房子都住不上。老婆说，是为了孩子的教育，当时买房的时候没考虑过，就是阴差阳错买了个学区房，现在搬走她觉得可惜，所以坚持留着这套自住，给孩子上学用。这样导致了我们的本金有限，想置换更好的房子就要背负上更多得的房贷。我的内心是更倾向于买一个更好的房子，然后出租这套用来换贷款，可后面被我老婆否决了，她觉得压力太大，只能买能承受住的，也就造成了难以接受的结果。最终我们购入了一套郊区新房，距离7~9公里左右，随着房价一直在下降，现在是后悔莫及，我的性格是有缺陷的，对于这种失败的买房经历，内心真的放不下，时常懊悔自己的选择，其实当时自己也观察了很多二手和附近的新房，我更倾向于购买这些，但最终还是妥协了，也导致了这次失败的经历，不仅在金钱上损失50W左右，也导致我的置换计划搁置至少4年左右，一步错步步错，当时很多同事都劝我买一套附近的新房，我们却因为价格选择郊区房，住不上，出租还亏，当时脑子是真坏掉了，居然选了这么一个最多的选项。这两天听到儿子同学家，就在附近低首付买入了一套我理想中的房子，真的是懊悔不已，这种房子再想买入，可能又要额外加100万，加上亏损的50万，这房子让我以后高攀不起了（例外要加150万才能买得到，一步错步步错）。

从最开始24年初的后悔，到现在已经有一年了，亏钱还是小事，最重要的亏损是时间啊，我的一生也才有几个这样的时间。从买车到买房，几个选择都是错的，我都是在将就别人，妥协自己的选择，最后都是后悔，大家都后悔。我自己算是一个理想的人，但在做决定的时候会犹犹豫豫，容易被他人误导，也导致这些遗憾。有些时候这些事让我更加自卑，我认为我可能就是这种命，每次选择都是错的。今天突然发现，这件事已经恶心我有一年的时间了，那破房子还要延期交房，之前说25年中，现在说要26年中，唉，隔壁的新房都要入住了，这样可能就是命吧，我有时候真想第二天就不要醒来，我一点痛苦也没有，我也不亏欠谁多少，可能只有我儿子吧。

生活

生活上，除了懊悔错误的购房经历，再也没有什么值得写的了，孩子三岁了上了幼儿园，虽然我是想多和他玩会，但我还是沉不下心来，也不想在他身上投入更多的精力，我也不知道我为什么是这样的父亲，我满脑子里都是房子、工作、赚钱，我不想在孩子身上浪费时间，我只想换一个一个生活环境，有一个自己的安静的书房，可以做自己喜欢做的事，买一辆自己喜欢的汽车，出去兜风，可现实上我什么都做不到，我就像是一个赚钱的机器，每天早上10点半到公司，每周2~3天要早上八点起来送下孩子去幼儿园，抓紧地铁上的时间学习半小时（看书），然后工作到中午吃完，再抓紧时间看书学习，下午一直工作到晚饭，吃饭遛弯，然后在干活一直早晚上十点半左右下班，基本到家都是11点左右了，这时候孩子睡了，我才感觉这时候才是我自己，我开始熬夜，看手机，学习，一直到临晨2点才开始入睡，每天我都能挤出来不到3个小时的时间给自己，可能代价就是透支生命吧，我现在每天都感觉身上没劲，不过只有那三个小时我才是开心的，因为周末我还要带孩子，我没有自己的时间，也没有权利买自己喜欢的东西，除了一个PS4，我好像没有给自己买过任何东西，我那么爱玩游戏的一个人，居然连一个台式机都没有，家里只有一台可以学习工作的mac，今天写下来这么多字，我突然意识到我真的是一个机器，一个只会服务于他人的机器，只会赚钱，没朋友，没生活，没盼头，所以说，有的人活着但是已经死了，我感觉我现在就是这种状态，我努力上班工作学习，但是什么都改变不了。

成长

这一年，看了很多书，也学了很多的道理，认知上有了很大的提高，也不在和老黄年一样的干活，更多的思考和落地，去探索更多的可能性。不过也受限于自己的职位，真的能落地的不多，不过也算是有一些成就。上半年还在未答辩没有通过而失落，不过经过第二次失败已经放下了执念，我能做的事就那么多，就那么十几分钟怎么就决定了一个人行不行呢，都是人情罢了。

建连的坑

线上环境的p95的数据的性能很差，通过trace链路分析出『均是由于数据库的sql执行的RT较长导致』，这样就比较奇怪了，同样的sql为什么会这么不稳定；
尤其在服务发布或流量徒增的过程中，问题现象更加明显；通过DBA的分析得出结论『数据库在有突增的新建连接时会影响sql的执行』，。

针对线上集群，单个数据库端口连接数非常多，每次业务有新的发布会创建比较多的连接，首先会导致『新建连接比较慢』，其次会导致『新建连接过程中会影响已有链接的RT』

建连慢

建连慢的主要原因在于tcp的建连队列大小，如果设置的队列过小会导致丢弃部分建连的请求，导致服务不可用；
https://stackoverflow.com/questions/36594400/what-is-backlog-in-tcp-connections

调整内核配置参数，解决单端口连接过多的问题：

• tcp_max_sync_backlog 2048->8192
• somaxconn 128->2048

建连RT影响

建连登录认证也是一个sql，正常都会进入sql队列，与正常的sql在一个队列中，所以会影响正常的sql执行;
https://dev.mysql.com/doc/refman/8.0/en/thread-pool-tuning.html

• thread_pool_stall_limit：线程池中无可用线程时设置建新线程的等待时间，单位为毫秒，默认是500；
• thread_pool_idle_timeout：设置空闲线程销毁前的等待时间，单位为秒，默认是60；

通过减小timmer检测间隔并提高连接池的超时时间，调整线程的创建和回收策略来优化RT的问题：

• thread_pool_stall_limit 500ms->10ms
• thread_pool_idle_timeout 60s->600s

由于以上配置会由于减少线程的回收和增加线程的创建频率均会对占用一定的服务器资源和性能，因此在评估这些参数的时候可以逐渐增加或减少该值，并在当前数据库负载的情况下找到一个合理的值；

建接数量

mysql的默认建连数据是xxx，实际可以按照数据库的性能做一定的调整；
数据库的连接会占用服务器的cpu和内存，所以谨慎的限制数据库client和server的连接数是非常重要的；
根据经验，32核64G内存的数据库可以配置到万级别的数据库连接数量，同时会有上千台的服务器与单分片的数据库保持着连接没，例如，1000台服务器，没台服务的连接池配置为50，则整体5W的连接数；

数据库连接数较多情况下，可能会导致那个数据库夯住：

• 故障切换时由于大量的请求同时打到DB，连接数会有翻倍的可能，导致连接数超过数据库上限；
• 故障切换时会导致业务访问DB的重试，可能导致连接数超过数据库上限；
• 当服务已有连接数过多的时候，业务如果同时发布但并未销毁原有容器，则可能创建最多翻倍的连接，并且会申请最多翻倍的数据库临时内存；

mysql线程池

参考文档：https://dbaplus.cn/news-11-1989-1.html

mysql线程池采用分组管理，连接按照分组算法分配到不同的分组，此后相同请求会在次分组内调度线程执行；此外线程池使用Timer线程定期检查分组运行的情况，并为阻塞的group分配线程。

group分组

• 工作线程：用于处理请求和任务；
• 监听线程：用于接收请求并加入任务队列；
• 任务队列：用于存放待执行的IO任务，分为高优先级队列和低优先级队列（高优先级队列的任务会优先被处理）；

timer线程

timer线程会定期扫描各个group检查是否被阻塞，当发现group内有任务堆积，就会给group创建新的worker进行处理；

工作流程

• 客户端优先会向server发起请求，根据threadid%thread_pool_size确定路由的分组；
• 监听线程在收到请求后，会按照队列情况分别处理：
  • 队列无请求，则转换为工作线程立即处理；
  • 队列有请求，则将任务加入任务队列中，排队等待被处理；
• 工作线程从队列中获取等待被处理的任务，依次进行处理，如果队列为空，则会在等待配置的超时时间后销毁；
• timmer线程会定期检查group是否阻塞，如果存在任务阻塞会创建新的工作线程；

配置参数

thread_handling

• one-thread-per-connection（默认，一个连接一个线程）
• pool-of-threads（线程池）

thread_pool_size

• 线程池的分组数量，默认为cpu数量；

thread_pool_oversubscribe

• 分组内的最大线程数，监听不再其内；

thread_pool_high_prio_mode

• transactions：启动事务的语句放到高优先级队列；
• statements：所有的语句都会放到高优先级队列，不会使用优先级队列；
• none：不使用高优先级队列；

thread_pool_high_prio_tickets

• 控制每个连接最多被放入高优先级队列中的次数，默认为4294967295；
• 仅在transactions模式下生效，如果超过阈值，则直接放入低优先级队列；

thread_pool_idle_timeout

• 工作线程最大空闲时间，默认为60秒，超过限制后会退出；

thread_pool_max_threads

• 限制线程池最大的线程数，超过该限制后将无法再创建更多的线程，默认为100000；

thread_pool_stall_limit

• timer线程的检测group是否异常的时间间隔，默认为500ms；

现状

职责不清：前后端没有明显的业务边界，业务逻辑耦合严重；

职责不清会让需求拆解和分析造成困扰，也会造成逻辑的前后端的高度耦合，提高后期的维护成本。

由于页面的任何改动都需要前后端的支持，整体改动的开发联调工作量以及排期冲突问题都难以接受。

页面性能：前后端交互逻辑由于年久失修，存在大量的无效请求和重复请求；

由于页面存在大量的无效业务逻辑和资源请求，导致页面渲染性能较差，影响用户体验；

后端的无效资源请求对服务器和数据库都会造成不必要的压力，属于资源的浪费；

目标

O1：开发提效

从根本上解决前后端耦合的问题，前端仅关注组件化通用能力的建设，业务逻辑全部内聚在后端；

页面的动态渲染功能实现配置化、定制化，用于满足不同改动量的需求；

O2：体验优化

后端接口调用链路优化，提高资源利用率，减少无效请求和无效的处理逻辑；

页面资源依赖优化，从整体页面的视角来分析解决页面渲染性能的问题；

落地

考虑到页面逻辑比较复杂，需要人肉来分析识别有效的业务逻辑，因此拆分两个阶段来完成目标：

阶段1：梳理前端的业务逻辑，优化无效的资源请求，业务逻辑内聚在后端

阶段2：页面组件化schema设计，实现组件spi扩展、资源自动装配等能力

阶段1

阶段1主要解决了页面渲染层面业务逻辑的耦合问题，初步实现了前后端分离的目标。

• 前后端业务逻辑梳理汇总
• 页面抽象和页面组件化拆分
• 后端资源加载内聚统一

业务逻辑的梳理是关键，为了避免逻辑的遗漏，通过开发和测试的不同视角来分析和对比业务逻辑：

• 开发：从代码层面，阅读前后端的代码逻辑并梳理出一套页面业务逻辑；
• 测试：从功能层面，覆盖页面的所有case用例输出一套页面的测试case;

为了实现页面的自动降级和分段加载，需要对页面整体做一次组件化抽象，拆分思路如下：

• 按职责拆分：以功能属性来拆分组件，组件功能内聚（职责单一）；
• 按顺序加载：以功能的优先级来分组组件，分段来加载不同组件，实现页面加载的体验优化；

基于上下文的思想实现页面依赖资源的统一管理，避免资源的重复加载造成的性能问题；

1
2
3
4
5
6
7
8
9
10

public class Context {

    private AResource aResource;
    private AResource bResource;
    private AResource cResource;
    
    public Context(AResource aResource, ...) {
        ....
    }
}

阶段2

阶段2主要解决组件的扩展能力以及资源管理的进一步优化。

• 组件的通用化设计
• 基于SPI的扩展能力
• 写时复制的资源管理

组件的通用化设计不仅包含展示层面的组件设计，也包含表单、联动的设计模式。

组件的抽象定义是为了解决组件的复用性，通过定义通用的展示、表单组件，实现自定义的页面组件渲染能力。

为了提高页面的扩展能力，对于通用组建提供基于SPI的扩展点，业务上可以很快的实现组件的重载和扩展，同时对不同的业务实现业务的隔离。

在第一阶段，虽然把资源管理独立出来，但对于不同场景下的资源加载并没有单独优化，因此考虑从资源管理上入手，利用写时复制的思想来解决资源惰性加载的能力，并通过线程cache的手段避免资源的频繁加载，最终实现一个无需使用者关心的资源中心。

Schema加载

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

// Schema解析起接口定义，通过实现ISchemaParser接口来注册加载新的组件
public interface ISchemaParser {
    // Schema枚举
    SchemaEnum getSchemaEnum();
    // Schema结构
    SchemaStructure get();
}

// Schema配置
@Component
public class SchemaParserConfiguration implements InitializingBean {

    @Autowired
    private List<ISchemaParser> schemaParsers; // 利用Spring自动注入
    
    private Map<SchemaEnum, ISchemaParser> mapping = new HashMap<>();
    
    public SchemaStructure getBySchemaEnum(SchemaEnum schemaEnum) {
        if (mapping.containsKey(schemaEnum)) {
            return mapping.get(schemaEnum).get();
        }
        return null;
    }
    
    // 利用InitializingBean初始化映射mapping
    @Override
    public void afterPropertiesSet() throws Exception {
        if (CollectionUtils.isEmpty(schemaParsers)) {
            return;
        }
        for (ISchemaParser schemaParser : schemaParsers) {
            mapping.put(schemaParser.getSchemaEnum(), schemaParser);
        }
    }
}

schema转换

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

// Schema转换接口定义，通过实现ISchemaTransfer来实现转换器的注册
public interface ISchemaTransfer<T extends IView, R, C extends BaseContext> {
    ViewTypeE viewType();
    R transfer(T t, C context);
}

// Schema转换配置
@Component
public class SchemaConfiguration implements InitializingBean {

    @Autowired
    private List<ISchemaTransfer> schemaTransfers;
    private Map<ViewTypeE, ISchemaTransfer> mapping = new HashMap<>();

    public ISchemaTransfer getByType(ViewTypeE viewTypeE) {
        return mapping.getOrDefault(viewTypeE, null);
    }

    @Override
    public void afterPropertiesSet() throws Exception {
        if (schemaTransfers != null) {
            for (ISchemaTransfer schemaTransfer : schemaTransfers) {
                mapping.put(schemaTransfer.viewType(), schemaTransfer);
            }
        }
    }
}

资源上下文管理

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

public class Context {

    private Map<String, Object> req; // 存储入参
    
    private IAContextA aContext; // 绑定资源，通过外部Spring注入后作为初始化参数引入
    private IBContext bContext;
    ...
    
    // 初始化资源
    public static Context init(SpingBean springBean) {
        IAContext aContext = new DefaultAContext();
        aContext.setSpringBean(springBean);
    
        Context context = new Context();
        context.setAContext(aContex);
        return context;
    }
}

public class IAContext {
    Resp method(Req req);
}

public class DefaultAContext {

    private SpingBean springBean;
    ...
    
    public Resp method(Req req) {
        // 线程级别的缓存，避免资源重复调用
        return threadCached(cachedPrefix, uniqueKey, () -> a.method(req));
    }

}

基于spi的模块化设计

1、定义展示类型，由于区分不同场景下使用的模块信息；

1
2
3

public interface IView {
    ViewTypeE viewType();
}

2、定义组件spi，以预下单为例，抽象出标题、价格、数量、规格等能力，并指定页面类型为预下单；

1
2
3
4
5
6
7
8
9
10

public interface IPreOrderView<C extends BaseContext> extends IView, ICustomMatch {
    @Override
    default ViewTypeE viewType() {
        return ViewTypeE.PRE_ORDER_PAGE;
    }
    String getTitle(C context);
    String getTotalPrice(C context);
    String getTotalCount(C context);
    String getGoodsSpecification(C context);
}

3、实现spi，主要是利用资源上下文来获取相关资源，渲染模块信息；

1
2
3
4
5
6
7
8

@DefaultView
public class DefaultPreOrderView implements IPreOrderView<SingleOrderContext> {
    @Override
    public <T extends BaseContext> boolean matched(IView view, T context) {
        return true;
    }
    ...
}

4、为了实现扩展性，按照默认+扩展的设计思路，优先定义了两种实现策略；

1
2
3
4
5
6
7
8
9
10
11
12
13

// 默认实现
@Component
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
public @interface DefaultView {
}

// 扩展实现，可增加优先级控制
@Component
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
public @interface ExtensionView {
}

5、基于构造器的思想，利用资源上线来构件通用的组件，

1
2
3

public interface IViewBuilder<T extends IView, C extends ViewContext> {
    List<T> build(C context);
}

页面定义，利用多个spi来组装一个完整的页面结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64

// 使用构造器来构造页面
public interface IViewBuilder {
    <C extends BaseContext> List<IView> build(C context);
}

// 抽象构造器提供了组件扫描、注册、识别的功能
public abstract class AbstractViewBuilder<T extends IView> implements IViewBuilder, ApplicationContextAware, InitializingBean {

    private MatcherConfiguration matcherConfiguration = new MatcherConfiguration(); // 匹配器
    private ApplicationContext applicationContext; 
    private List<Class<? extends T>> definitions;
    private Map<Class<? extends T>, List<T>> defaultImplements = new HashMap<>();
    private Map<Class<? extends T>, List<T>> extensionImplements = new HashMap<>();


    protected abstract Class<T> getViewType();

    protected abstract List<Class<? extends T>> getScanDefinitions();

    @Override
    public <C extends BaseContext> List<IView> build(C context) {
        return matcherConfiguration.doFilter(definitions, defaultImplements, extensionImplements, context);
    }

    /**
     * 初始化定义实现
     * @throws Exception
     */
    protected synchronized void initSpiImplements() throws Exception {
        definitions = getScanDefinitions();
        ...
        Map<String, T> beans = applicationContext.getBeansOfType(getViewType());
        beans.values().stream().forEach(bean -> {
            for (Class<? extends T> definition : definitions) {
                if (definition.isInstance(bean)) {
                    if (bean.getClass().getAnnotation(DefaultView.class) != null) {
                        register(defaultImplements, bean, definition);
                        log.info("ViewBuilder For {} default {}", getViewType().getSimpleName(), definition.getSimpleName());
                    } else if (bean.getClass().getAnnotation(ExtensionView.class) != null) {
                        register(extensionImplements, bean, definition);
                        log.info("ViewBuilder For {} extension {}", getViewType().getSimpleName(), definition.getSimpleName());
                    } else {
                        log.info("ViewBuilder For {} ignore {}", getViewType().getSimpleName(), definition.getSimpleName());
                    }
                }
            }
        });
    }
    ...
}

// 预下单的页面组装
public class PreOrderViewBuilder extends AbstractViewBuilder {
    private static List<Class<? extends IView>> spiDefinitions = new ArrayList<>();
    static {
        // 指定顺序
        spiDefinitions.add(IPreOrderView.class);
    }
    @Override
    protected List<Class<? extends IView>> getScanDefinitions() {
        return spiDefinitions;
    }
    ...
}

6、为了实现组件的扩展能力，实现了自定义的匹配接口；

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

public interface IMatch {
    <T extends BaseContext> boolean matched(IView view, T context);
}

// 自定义匹配
public interface ICustomMatch<CC extends BaseContext> extends IMatch {
}

// 匹配逻辑
public abstract class AbstractMatcher implements IMatch {
    public abstract <T extends BaseContext> boolean doMatch(IView view, T context);
    @Override
    public <T extends BaseContext> boolean matched(IView view, T context) {
        ...
    }
}

// 匹配器的注册
public class MatcherConfiguration<T extends IView, R extends BaseContext> {
    private static List<IMatch> MATCHERS = new ArrayList<>();
    static {
        MATCHERS.add(new CustomMatcher());
        MATCHERS.add(new StateMatcher());
    }
    ...
}

保障手段

为了降低重构后页面整体的风险，通过组件隔离、页面灰度、整体页面监控等多个手段来解决页面的问题发现和降级问题。

隔离

为了提高整体页面的可用性，通过隔离不同组件的加载和渲染，保证整体页面基本可用的状态。

灰度

灰度策略一般选用用户id作为灰度维度，但针对复杂的页面来说，测试很难充分的覆盖每一种业务场景，因此可以考虑基于场景来灰度，具体可以从最基础的业务场景出发进行灰度，逐渐放量到不同的业务场景。

监控

监控方面，可以从前端监控和后端监控两个方面入手：

前端监控可以覆盖用户的实际使用场景，包含页面的打开成功率、页面打开耗时、组件渲染成功率等。

后端监控可以从系统整体性能和异常发现角度来考虑，包含接口的RT、组件的渲染成功率、组件的渲染异常等角度来发现问题。

多表单联动

简单的form标单很容易通过schema这套协议来实现，但对于复杂表单联动很难通过简单的schema协议来实现；

利用后端来维护整个页面的状态来实现多表单的联动。

目前我们通过后端来维护整个页面的渲染逻辑，也就是包含多个组件的联动关系由后端整体下发，举个例子：

• 页面分表有两个表单项，B表单项会根据A表单项的选择结果来返回；
• 前端第一次请求后端，会返回A所有的可选项目，B表单不会返回；
• 当用户选择好A表单后，会向后端请求一次新的页面信息，此时会下发A所有的可选项目以及A当前的选择，并且会下发B表单的可选项；
• 当用户选择B表单后，等待用户提交表单，此时完成一次表单的提交；

经过上面这个过程，有没有发现什么问题？

页面联动的逻辑前端并不感知，依赖前端的每一次操作都会向后端请求，获取整个页面的最新状态；

由于引入了页面状态，会导致后端代码变得及其复杂，在实践过程中，前端的工作量整体上是有略微的降低，但后端的工作量会明显的提高；

核心问题

什么是流程编排的核心要解决的问题?

流程可编排是流程引擎的核心，是解决服务流程的核心；

流程定义清晰是流程引擎的关键，只有清晰的流程才能保证编排的可维护性；

流程易于扩展是流程引擎的核心竞争力，只有更好的扩展能力才能让流程的编排效率提升；

绕不开的BPM规范

BPM（Business Process Manager、业务流程管理）主要用于管理复杂业务关系以及业务流程。

BPMN（Business Process Modeling Notation）是BPM的一种建模语言，BMPN2.0是最新版本。

工作流引擎以Activiti为代表，使用BPMN2.0标准定义进行编排管理；

功能完善、相对重量级的产品如下：

• https://github.com/kiegroup/jbpm
• https://github.com/Activiti/Activiti
• https://github.com/Netflix/conductor
• https://github.com/flowable/flowable-engine
• https://camunda.com/

功能基本可用，相对轻量级的产品如下：

• https://github.com/alibaba/SmartEngine
• https://github.com/dromara/liteflow

BMPN的可视化

流程编排的可视化是降低编排复杂度的关键，除了传统的XML的编排方式，可视化的编排方式更加易于维护。

这里推荐使用开源的bmpmn-js来实现页面可视化。

https://github.com/bpmn-io/bpmn-js

如果需要对其功能点和扩展方式进行进一步的了解，可以在其使用实例中了解扩展的写法。

https://github.com/bpmn-io/bpmn-js-examples

如何设计组件化流程引擎？

目标: 我们到底要解决什么问题?

传统的工作流引擎常用于企业内部审批流、工作流等方面，注重业务流程的编排和扩展，

而此次要设计的流程引擎是关注代码逻辑流程的编排，

因此，不考虑使用繁琐的Activiti流程，而采用类似liteflow的方式来实现基础的流程编排功能；

流程节点

流程节点是编排的最小单元。

1
2
3
4

/** 节点定义 **/
public interface IFlowNode<C extends IFlowContext> {
    void exec(C context);
}

节点能力

节点能力适用于扩展流程节点的功能，例如节点重试，

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

/** 重试能力 **/
public interface IFlowRetryCapacity {
    int retryTimes();
}

/** 重试节点定义 **/
public interface IFlowRetryNode<C extends IFlowContext> extends IFlowRetryCapacity, IFlowNode<C> {
}

/** 重试定义 **/
public interface IFlowRetry<C extends IFlowContext> {
    void retry(IFlowRetryNode retryNode, C context);
}

/** 重试策略 **/
public abstract class AbstractFlowRetry implements IFlowRetry {

    abstract public void doRetry(IFlowRetryNode retryNode, IFlowContext flowContext);

    @Override
    public void retry(IFlowRetryNode retryNode, IFlowContext flowContext) {
        if (retryNode.retryTimes() <= 0) {
            return;
        }
        log.info("FlowRetry start uniqueKey={} retry={}", flowContext.getUniqueKey(), retryNode.getClass().getSimpleName());
        doRetry(retryNode, flowContext);
    }
}

/** 基于spring的重试策略 **/
public class SpringFlowRetry extends AbstractFlowRetry implements IFlowRetry {

    private ConcurrentHashMap<Integer, RetryTemplate> retryMap = new ConcurrentHashMap<>();

    @Override
    public void doRetry(IFlowRetryNode retryNode, IFlowContext flowContext) {
        if (retryNode.retryTimes() <= 0) {
            return;
        }

        if (!retryMap.contains(retryNode.retryTimes())) {
            synchronized (this) {
                RetryTemplate retryTemplate = RetryTemplate.builder()
                        .maxAttempts(retryNode.retryTimes())
                        .retryOn(Throwable.class)
                        .build();
                retryMap.put(retryNode.retryTimes(), retryTemplate);
            }
        }

        retryMap.get(retryNode.retryTimes()).execute((context) -> {
            log.info("SpringFlowRetry retry uniqueKey={} retryNode={} retryCount={}", flowContext.getUniqueKey(),
                    retryNode.getClass().getSimpleName(), context.getRetryCount());
            retryNode.exec(flowContext);
            return true;
        });
    }

}

流程链

流程链用于存储流程节点，也就是编排的作用。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

public class FlowChain<C extends IFlowContext> {

    // 流程节点的定义
    private List<Class<? extends IFlowNode>> flowNodeDefinition = new ArrayList<>();
    // 用于节点重试
    private IFlowRetry<C> flowRetry = new SpringFlowRetry();

    public FlowChain add(Class<? extends IFlowNode> definition) {
        this.flowNodeDefinition.add(definition);
        return this;
    }

    public boolean isNull() {
        return CollectionUtils.isEmpty(flowNodeDefinition);
    }

    public void forEach(Function<Class<? extends IFlowNode>, List<IFlowNode>> function) {
        if (isNull()) {
            return;
        }
        flowNodeDefinition.forEach(function::apply);
    }

    public List<Class<? extends IFlowNode>> getFlowNodes() {
        return flowNodeDefinition;
    }

    public IFlowRetry<C> getFlowRetry() {
        return flowRetry;
    }
}

流程定义

流程是由流程链以及执行方法组成。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161

/** 流程定义 **/
public interface IFlow<C extends IFlowContext> {
    FlowChain getFlowChain();
    /**
     * 执行流程
     * @param context
     */
    void execute(C context);
}

/** 流程模板 **/
public abstract class AbstractFlowTemplate<C extends IFlowContext> extends AbstractFlowScanner implements IFlow<C> {

    private FlowNodeSelector selector = new FlowNodeSelector(
            getDefaultImplements(),
            getMutexExtensionImplements(),
            getShareExtensionImplements());

    @Override
    public void execute(C context) {
        FlowChain<C> flowChain = getFlowChain();
        if (flowChain == null || flowChain.isNull()) {
            return;
        }
        // 流程链的顺序执行
        for (Object flowNode : flowChain.getFlowNodes()) {
            // 流程的过滤，通过selector来选择当前上下文需要命中的流程节点
            List<IFlowNode> flowNodes = selector.select((Class<? extends IFlowNode>) flowNode, context);
            if (CollectionUtils.isNotEmpty(flowNodes)) {
                flowNodes.forEach(bean -> {
                    // 支持流程节点的重试
                    if (bean instanceof IFlowRetryNode && ((IFlowRetryNode) bean).retryTimes() > 0) {
                        flowChain.getFlowRetry().retry((IFlowRetryNode) bean, context);
                    } else {
                        bean.exec(context);
                    }
                });
            }
        }
    }

    @Override
    protected List<Class<? extends IFlowNode>> getFlowNodes() {
        return getFlowChain() != null ? getFlowChain().getFlowNodes() : null;
    }
}

/** 流程扫描 **/
public abstract class AbstractFlowScanner implements ApplicationContextAware, InitializingBean {

    private ApplicationContext applicationContext;
    private List<Class<? extends IFlowNode>> flowNodes;
    // 默认流程节点
    private Map<Class<? extends IFlowNode> , List<IFlowNode>> defaultImplements = new HashMap<>();
    // 互斥流程节点
    private Map<Class<? extends IFlowNode> , List<IFlowNode>> mutexExtensionImplements = new HashMap<>();
    // 共享流程节点
    private Map<Class<? extends IFlowNode> , List<IFlowNode>> shareExtensionImplements = new HashMap<>();
    // 支持优先级
    private Map<Class<? extends IFlowNode> , PriorityQueue<PriorityFlowNode>> sharePriorityExtensionImplements = new HashMap<>();
    private Comparator<PriorityFlowNode> comparator = (o1, o2) -> o2.priority - o1.priority;

    protected abstract List<Class<? extends IFlowNode>> getFlowNodes();

    public Map<Class<? extends IFlowNode>, List<IFlowNode>> getDefaultImplements() {
        return defaultImplements;
    }

    public Map<Class<? extends IFlowNode>, List<IFlowNode>> getMutexExtensionImplements() {
        return mutexExtensionImplements;
    }

    public Map<Class<? extends IFlowNode>, List<IFlowNode>> getShareExtensionImplements() {
        return shareExtensionImplements;
    }

    private synchronized void initFlowNodeImplements() {
        flowNodes = getFlowNodes();
        if (CollectionUtils.isEmpty(flowNodes)) {
            return;
        }
        Map<String, IFlowNode> beans = applicationContext.getBeansOfType(IFlowNode.class);
        if (MapUtils.isEmpty(beans)) {
            return;
        }
        beans.values().stream().forEach(bean -> {
            for (Class<? extends IFlowNode> flowNode : flowNodes) {
                if (flowNode.isInstance(bean)) {
                    if (bean.getClass().getAnnotation(DefaultFlowNode.class) != null) {
                        registerFlowNode(defaultImplements, bean, flowNode);
                        log.info("AbstractFlowBuilder register default={}", bean.getClass().getSimpleName());
                    } else if (bean.getClass().getAnnotation(ExtensionFlowNode.class) != null) {
                        ExtensionFlowNode extensionFlowNode = bean.getClass().getAnnotation(ExtensionFlowNode.class);
//                        registerFlowNode(FlowExtensionType.MUTEX.equals(extensionFlowNode.type())
//                                ? mutexExtensionImplements : shareExtensionImplements, bean, flowNode);
                        if (FlowExtensionType.MUTEX.equals(extensionFlowNode.type())) {
                            registerFlowNode(mutexExtensionImplements, bean, flowNode);
                        } else {
                            registerPriorityFlowNode(bean, flowNode, extensionFlowNode.priority());
                        }
                        log.info("AbstractFlowBuilder register extension={}", bean.getClass().getSimpleName());
                    } else {
                        log.info("AbstractFlowBuilder register ignore {}", bean.getClass().getSimpleName());
                    }
                }
            }
        });

        refreshShareExtensionImplements();
    }

    private void refreshShareExtensionImplements() {
        // priority 转 list
        for (Class<? extends IFlowNode> flowNode : sharePriorityExtensionImplements.keySet()) {
            PriorityQueue<PriorityFlowNode> priorityQueue = sharePriorityExtensionImplements.get(flowNode);
            if (priorityQueue != null) {
                List<IFlowNode> list = new ArrayList<>();
                while (!priorityQueue.isEmpty()) {
                    list.add(priorityQueue.poll().getFlowNode());
                }
                shareExtensionImplements.put(flowNode, list);
            }
        }
    }

    private void registerFlowNode(Map<Class<? extends IFlowNode> , List<IFlowNode>> store, IFlowNode bean, Class<? extends IFlowNode> definition) {
        if (!store.containsKey(definition)) {
            store.put(definition, new ArrayList<>());
        }
        store.get(definition).add(bean);
    }

    private void registerPriorityFlowNode(IFlowNode bean, Class<? extends IFlowNode> definition, int priority) {
        if (!sharePriorityExtensionImplements.containsKey(definition)) {
            sharePriorityExtensionImplements.put(definition, new PriorityQueue<>(comparator));
        }
        sharePriorityExtensionImplements.get(definition).add(new PriorityFlowNode(bean, priority));
    }

    @Override
    public void afterPropertiesSet() throws Exception {
        initFlowNodeImplements();
    }

    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        this.applicationContext = applicationContext;
    }

    @Data
    private static class PriorityFlowNode {
        private IFlowNode flowNode;
        private int priority = 1;

        public PriorityFlowNode(IFlowNode flowNode, int priority) {
            this.flowNode = flowNode;
            this.priority = priority;
        }
    }

}

流程扩展

在流程定义中，应该可以发现流程节点会分为默认节点和扩展节点，其中扩展节点又可以分为互斥节点和共享节点；

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

/** 扩展类型 **/
ffpublic enum FlowExtensionType {
    MUTEX, // 互斥、不同的扩展会相互隔离
    SHARE, // 共享、不同的扩展会相互叠加，通过指定不同的优先级来控制先后的覆盖顺序
}

/** 默认节点 **/
@Component
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
public @interface DefaultFlowNode {
}

/** 扩展节点 **/
@Component
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
public @interface ExtensionFlowNode {
    FlowExtensionType type() default FlowExtensionType.SHARE;
    int priority() default 1; // 值越大优先级越高
}

/** 扩展匹配 **/
public interface IMatcher<C extends IFlowContext> {
    boolean match(C context);
}

待完善的功能点

• 流程分叉（流程编排过程中存在if-else的问题）
• 流程持久化
• 流程重试
• xml编排
• bpmn可视化编排

Kafka Replication

Kafka Replication

Kafka通过数据写入的多个副本来实现数据的持久化与高可用。

为了保证消息的成功投递，可以把消息投递的整个生命周期分为三部分：

① 生产消息：消息从Producer传递到Broker；

② 存储消息：消息写入到Broker的磁盘；

③ 消费消息：消息从Broker传递到Comsumer。

存储消息是数据持久化范畴，而如何保证消息不丢是多副本设计的初衷。

设计目标

考虑到Kafka不同场景的应用，设计目标包括：

① 可配置的持久化策略：高吞吐量/低时延，低吞吐量/高时延（通过调整备份副本的个数）；

② 自动的副本备份策略：自动调整备份，自动化的集群扩容能力。

强一致需要保证数据写入多个备份，从而导致写入时延的增加；弱一致不需要保证备份写入，会导致数据存在软状态，从而获得更好的性能。

解决问题

多副本场景下，存在两个关键问题：

① 副本分片策略：副本该如何保存与分配到不同的Broker；

② 消息广播策略：消息该如何广播到所有的副本。

Data Replication

多副本的数据复制可以分为同步复制与异步复制。

无论那种复制策略都需要考虑以下问题：

① 如何实现数据广播；

② 如何权衡数据复制的份数；

③ 副本宕机的异常处理；

④ 副本宕机恢复数据的一致性如何保证。

常见的复制策略分为两种：主备复制与选举复制。

Primary-Backup Replication

主备复制的场景下，主节点在写入数据完成后会阻塞等待所有从节点的写入完成。

在从节点写入的过程中，如果发生故障（宕机、断网、超时）就需要主节点来协调管理可用的从节点列表。

对于故障恢复后的从节点，需要从主节点拉取最新的数据才能重新加入集群。

如果副本数量为N，则主备策略最多可以容忍N-1个节点异常。

Quorum-Based Replication

选举复制的场景下，主节点在写入数据完成后会阻塞等待多数从节点的写入完成。

选举的特点在于不需要等待所有从节点的写入。

考虑到集群数量是预设的，由于半数以上的写入策略，从而最大的异常容忍度是可知的。

如果副本数量为2N+1，则选举策略最多可以容忍N个节点异常。

那么，两种策略如何权衡？

主要从时延性能、可用性两方面考虑，

① 选举复制只需要写入大部分节点就可返回，因此选举复制的时延低；

② 主备复制可以容忍更多数量的异常节点；

③ 选举复制至少最多容忍半数的异常节点。

考虑到，副本数量会直接影响到磁盘的有效使用率，Kafka选择主备来尽量减少磁盘空间的浪费。

Synchronous Replication

Kafka使用主备作为同步复制策略。

主节点维护一个同步副本的列表（In-Sync Replicas（ISR）），用于记录与主节点保持同步的从节点。

为了维护多个副本的可用性，Kafka使用Zookeeper来保存Leader节点与ISR。

数据存储分为两部分：本地日志与偏移量。

其中，LEO（The Log End Offset）记录当前日志的最新偏移量，HW（High Watermark）记录最后一次Commited的偏移量。

LEO是用来标记日志同步的进度，而HW是用来标记Commited的进度。

Writes

Client通过Zookeeper获取目标分区最新的Leader节点。

1
2
3

       Zookeeper
      /
Client ----> Broker-Partition(Leader) ----> Broker-Partition (Follower)

副本之间的通信采用Socket直连的方式来提高性能。

主节点在接收到数据后会优先写入本地磁盘（日志），然后同步写入多个副本。

主节点（Partition）的写入是有序的，但不同主节点之间写入的顺序是无序的。

消息的写入判断条件是ISR列表中所有从节点均写入完成。

为了提高副本的写入效率，仅保证消息写入到副本节点的内存（不保证持久化到磁盘）。

通过提供可配置化的Flush策略来提供不同的应用场景：同步刷盘与异步刷盘。

Reads

读操作仅从Leader主节点读取数据，而主节点是根据Zookeeper来获取的。

Failure Scenarios

Follower Failure

从节点异常情况下，会被主节点从ISR列表中移除，直到从节点恢复。

从节点的恢复不仅需要机器恢复正常，也需要数据恢复到同步状态。

因此，ISR列表是Kafka实现主备自动切换的关键。

Leader Failure

主节点异常的三种场景：

① 未写入本地日志（无影响）；

② 写入本地日志，未写入从节点；

③ 写入本地日志，写入部分从节点；

由于第①种场景中没有持有化数据，因此不会存在主从切换数据不一致的问题。

为了实现主从切换后数据的一致性，被选举为Leader的节点一定拥有最新的数据，

Kafka的主备切换主节点的选举策略如下：

① Zookeeper中注册ISR信息，用来保证元数据的一致性；

② 基于Zookeeper的临时节点来选举主节点，用来保证Leader的唯一性；

③ 利用Zookeeper的Watcher功能实现自动的选举功能；

④ Leader需要保证ISR中节点的同步进度，即时移除超时等异常的从节点。

Asynchronous Replication

异步复制是数据写入主节点后直接返回给Client，通过异步的方式同步数据到从节点。

因此，异步复制不能保证数据的持久化，当发生主从切换时可能造成数据的不一致（重复消息、丢消息）。

Kafka: a Distributed Messaging System for Log Processing

Kafka是一个高吞吐量、低延时、可伸缩的分布式消息系统。

Other System

传统的消息系统一般作为消息总线，用于处理异步的数据流。

然而，这种消息总线的处理方式并不适合当下的日志处理的场景，究其原因在于：

① 传统的消息系统关注于消息投递，大量的日志会导致系统的过载。

在分布式场景下，消息投递的保证是通过Sync + ACK的方式来实现的。

因此，在传统消息系统中，消息投递过程是同步的，无法支持大量日志流的场景。

② 传统的消息系统大多都不是以吞吐量为作为首要目标，使用TCP作为消息投递的通信方式。

TCP是可靠的通信协议，并不适用于高吞吐量为目标的消息通信方式。

③ 传统的消息系统缺少分布式的支持。

对于海量的日志消息，单机必然无法满足，多机的环境下的分区存储是不可避免的。

④ 传统的消息系统是建立在消息即时消费的假设之上，从而缺少对于大量消息持久化存储的能力。

对于海量的日志消息，消息的消费不一定是即时的，从而可能导致大量的消息堆积，

这也就是第③点的问题，如何通过分区来支持海量消息的堆积问题。

近几年海量日志处理的场景下产生一些日志聚合工具。

Scribe是Facebook用于收集日志数据的中间件，它基于Socket来收集日志数据，并通过日志聚合定期写入HDFS。

也就是说，Scribe是用于解决日志写入HDFS性能不足的一种手段。

Flume是Cloudera开发的日志聚合中间件，支持pipes与sinks的灵活扩展以及分布式的支持。

HedWig是Yahoo开发的一个分布式的发布订阅系统，主要用于记录消息的消费记录。

Architecture

Kafka引入了Broker用于消息的存储。

为了实现海量数据的存储，Kafka集群一般包含多个Broker。

为了实现负载均衡，每一个Topic会被分为多个Partition，每一个Broker会存储一个或多个Partion。

Partition

Partition实际上是一个逻辑日志，它由于含多个Segment（物理日志）组成，每个Segment的大小约为1GB。

每当一个生产者发布一条消息到某个Partition时，该条消息会追到到该Partition的最后一个Segment日志中。

为了实现高性能，Kafka先内存缓存消息再flush磁盘，刷盘策略有：

① 内存缓存到指定数量的消息后自动flush磁盘；

② 固定时间阈值自动flush磁盘。

在Kafka中，消息没有分配一个唯一固定的消息ID，而是采用一个基于日志的逻辑的偏移量来定位消息。

偏移量的使用可以避免磁盘的随机查找，通过偏移量可以准确的确定消息的位置。

对于消息的顺序写入，消息的定位不仅仅要记录消息的偏移量（Offset），还要记录消息的长度（Length）。

偏移量（Offset）虽然是不连续的（记录消息的起始位置），但可以保证单调递增。

Kafka使用在内存维护了一个Offset的内存索引，记录了每个Segment内第一个消息的偏移量。

高效传输

为了实现高效的数据传输，Kafka的设计如下，

① 消息的批量发送与拉取主要用于减少请求次数；

② 直接使用PageCache来避免的内存缓存；

③ 没有使用内存，因此避免了不必要的GC；

④ 使用sendfile减少内存拷贝。

无状态的Broker

Broker是无状态的，其仅仅作为消息的存储，并不会保留任何Consumer的消费情况。

Broker的无状态特性可以降低消息系统的复杂性。

由于Broker的无状态，无法感知消息消费的情况，也就无法即时清除，因此一般采用定期清除策略来清除历史消息。

此外，基于Broker的无状态，Consumer可以实现消费的回退以及重试。

Distributed Coordination

路由

消息投递到Partition的路由策略有：

① 随机选择：基于Random的随机选择；

② 哈希路由：基于PartitionKey的路由策略；

并行

Kafka使用Partition作为最小的并行处理单元。

一个Partition仅能被一个Consumer消费，因此，Partition的数量要多于Consumer的数量。

协作

为了实现多个无状态的Broker之间的协作，引入了Zookeeper。

① Broker的注册与监控；

② 基于Zookeeper的监控来做rebalance；

③ 维护Consumer的消费进度（Offert）。

Broker/Consumer的注册是动态的（存在扩容与缩容的情况），使用ZK的临时节点。

由于Broker是无状态的，因此Consumer的Offset的维护使用ZK的持久化节点。

rebalance

当监听到ZK中Broker/Consumer的注册信息有变化时，对应的Consumer就会发起rebalance。

rebalance是按照group来分组的，每个group维护着自己的Offset。

第一个监听到变化的Consumer会释放所有Partition再进行rebalance。

Partition的占用必然是通过ZK实现的。

Delivery Guarantees

Kafka仅支持至少一次的消息投递。

仅一次的消息投递需要两阶段提交（2PC）的支持，这与高吞吐量的目标不相符。

由于Partition是最小的并行处理单元，消息在Partition内部是有序的，

因此，通过PartitionKey的路由策略可以保证一定的顺序消费。

总结

本文仅是Kafka论文的记录，其内容与目前Kafka版本的实现可能有些不同。

本文还缺少对于Replication的介绍，会在后面的文章中有分析介绍。

对于Broker的无状态特性，Kafka后期并没有完全维持，例如，Consumer的Offset就从Zookeeper中迁移至Broker中。

Kafka作为独立的中间件，需要Zookeeper作为协调者来说有些太重了，因此社区正打算干掉ZK，例如，KIP-500打算把元数据都利用TOPIC来存储。

此外，随着Kafka的应用越来越广泛，消息投递的语义也不仅仅支持至少一次这种场景了，此时就需要考虑CAP理论了。

Skip List

关键词：链表、多级索引、动态结构

跳表是基于链表建立多级索引的动态数据结构。

在链表的基础之上，跳表利用空间换时间的方法，把单链表的时间复杂度从O(n)降低到跳表的O(log(n))。

在跳表索引的构建上，需要维护索引大小平衡性，避免退化为单链表。

Source Code

Redis中ZSET也被称为有序集合（Sorted Set），是通过跳表来实现的。

Redis为什么使用跳表来实现ZSET？

① Redis并不是仅使用跳表来实现；

在数据量比较少时使用ziplist来实现，当数据量比较多的时候才会采用skiplist实现；

② 基于双向链表的跳表很容易实现ZRANGE与ZRERANGE，而红黑树等树形结构就没这么容易；

③ 跳表节点的插入与删除的复杂度更低，而红黑树等平衡树都需要旋转平衡操作。

在高并发场景下跳表性能更加，不过针对Redis来说单线程的数据变更来说红黑树的平衡旋转应该不是瓶颈。

下面将简单介绍下redis跳表的结构、节点插入、节点排序以及范围检索。

zskiplist

ZSET是通过两部分组成：KV字典（dict）与跳表索引（zskiplist）。

1
2
3
4
5

/* ZSET结构体 */
typedef struct zset {
    dict *dict;          // KV字典
    zskiplist *zsl;      // 跳表索引
} zset;

其中，KV字典（dict）是基于哈希的数据存储的基础结构，跳表索引（zskiplist）是基于跳表的数据遍历搜索结构。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

/* 跳表节点 */
typedef struct zskiplistNode {
    sds ele;                          // 具体元素
    double score;                     // 用于排序的分值
    struct zskiplistNode *backward;     // 向后的指针
    /* 节点层次 */ 
    struct zskiplistLevel {
        struct zskiplistNode *forward;  // 向前的指针
        unsigned long span;            // 当前节点与forward节点之间的节点数
    } level[];
} zskiplistNode;

/* 跳表结构体 */
typedef struct zskiplist {
    struct zskiplistNode *header, *tail;  // 跳表的头节点与尾节点
    unsigned long length;               // 跳表的长度
    int level;                         // 跳表的层次数
} zskiplist;

zslGetRank

zslGetRank是跳表中用于获取指定元素排名的功能。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

/* 获取排名 */
unsigned long zslGetRank(zskiplist *zsl, double score, sds ele) {
    zskiplistNode *x;
    unsigned long rank = 0;
    int i;
    /* 从跳表的最高层开始遍历 */
    x = zsl->header;
    for (i = zsl->level-1; i >= 0; i--) {
        /* 找到当前层级中与目标值最接近的位置 */
        while (x->level[i].forward &&
             // 当前层有forward的score小于目标值 或 当前层有forward的ele小于目标值
            (x->level[i].forward->score < score ||
                (x->level[i].forward->score == score &&
                sdscmp(x->level[i].forward->ele,ele) <= 0))) {
            rank += x->level[i].span;
            x = x->level[i].forward;
        }

        /* x might be equal to zsl->header, so test if obj is non-NULL */
        if (x->ele && sdscmp(x->ele,ele) == 0) {
            return rank;
        }
    }
    return 0;
}

zslInsert

zslInsert是跳表的插入逻辑。

插入流程大体如下：

• 位置搜索：从跳表的最高层到最底层开始遍历，记录每层的跳跃节点以及移动位置；
• 构造新节点：随机生成一个level用于构造带插入节点；
• 初始化新增层级：如果level大于原有最大层级，则需要对新增的层级初始化；
• 节点加入到跳跃表：把待插入节点的层级节点加入到跳表层级的每一层，并重新计算span；
• 更新跳表指针：更新节点的backward。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61

/* 插入数据 */
zskiplistNode *zslInsert(zskiplist *zsl, double score, sds ele) {
    zskiplistNode *update[ZSKIPLIST_MAXLEVEL]; // 记录每层插入节点的跳跃位置
    unsigned int rank[ZSKIPLIST_MAXLEVEL];    // 记录到达每层跳跃节点的移动位置
    
    /* 从跳表的最高层开始遍历 */
    x = zsl->header;
    for (i = zsl->level-1; i >= 0; i--) {
        /* 初始化rank，如果是最高层则为0，否则为上一层的值 */
        rank[i] = i == (zsl->level-1) ? 0 : rank[i+1];
        /* 找到当前层级中与目标值最接近的位置 */
        while (x->level[i].forward &&  
                // 当前层有forward的score小于目标值 或 当前层有forward的ele小于目标值
                (x->level[i].forward->score < score ||
                    (x->level[i].forward->score == score 
                    && sdscmp(x->level[i].forward->ele,ele) < 0)))
        {
            rank[i] += x->level[i].span;    // 更新每层的偏移动位置
            x = x->level[i].forward;       // 更新跳跃节点
        }
        update[i] = x;                    // 记录每层的跳跃节点
    }
    
    /* 随机生成层级，并初始化新增所有层级 */
    level = zslRandomLevel();
    if (level > zsl->level) {
        for (i = zsl->level; i < level; i++) {
            /* 初始化移动位置以及跳跃位置 */
            rank[i] = 0;
            update[i] = zsl->header;
            update[i]->level[i].span = zsl->length;
        }
        zsl->level = level; // 重置跳表层级
    }
    
    /* 创建节点，并加入到层级链表 */
    x = zslCreateNode(level,score,ele);
    for (i = 0; i < level; i++) {
        /* 链表插入（利用update记录的每层插入节点） */
        x->level[i].forward = update[i]->level[i].forward;
        update[i]->level[i].forward = x;
        /* span计算（利用rank记录的每层移动位置（从第i层到第0层）） */
        x->level[i].span = update[i]->level[i].span - (rank[0] - rank[i]);
        update[i]->level[i].span = (rank[0] - rank[i]) + 1;
    }

    /* 大于当前层级的span都需要span+1 */
    for (i = level; i < zsl->level; i++) {
        update[i]->level[i].span++;
    }

    /* 更新新增节点的前向指针，如果是链表头节点则忽略，否则更新为0层节点 */
    x->backward = (update[0] == zsl->header) ? NULL : update[0];
    /* 第0层为正向指针，节点本身带有的反向指针 */
    if (x->level[0].forward)
        x->level[0].forward->backward = x;
    else
        zsl->tail = x;
    zsl->length++;
    return x;
}

zrangeGenericCommand

zrangeGenericCommand是跳表的范围查询逻辑。

范围查询的流程大体如下：

• 计算遍历位置以及长度：主要在于start、end、rangelen的边界条件以及内容计算；
• 搜索目标范围的起始节点：利用zslGetElementByRank获取正序或倒序序列的起始位置；
• 以起始节点开始遍历指定范围的节点：基于上一步计算的起始节点开始循环遍历（基于双向链表），需要注意遍历的方向；

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74

/* 范围查询 ZRANGE */
void zrangeGenericCommand(client *c, int reverse) {
    robj *key = c->argv[1]; // KEY
    long start;            // 开始位置
    long end;              // 结束位置
    long rangelen;          // 扫描范围
    ...
    /* start end 赋值 */
    if ((getLongFromObjectOrReply(c, c->argv[2], &start, NULL) != C_OK) ||
        (getLongFromObjectOrReply(c, c->argv[3], &end, NULL) != C_OK)) return;
    
    ...
    llen = zsetLength(zobj); // 跳表长度
    ...
    /* 记录扫描长度 */
    rangelen = (end-start)+1;
    /* ziplist */
    if (zobj->encoding == OBJ_ENCODING_ZIPLIST) {
        ...
    /* skiplist */    
    } else if (zobj->encoding == OBJ_ENCODING_SKIPLIST) {
        zset *zs = zobj->ptr;
        zskiplist *zsl = zs->zsl;
        zskiplistNode *ln;
        sds ele;

        /* 反向 or 正向，利用zslGetElementByRank获取起始节点 */
        if (reverse) {
            /* 默认从跳表尾部开始 */
            ln = zsl->tail;
            if (start > 0)
                /* zslGetElementByRank仅支持正序排序，则反序起始位置为 llen-start（rank以llen结束） */
                ln = zslGetElementByRank(zsl, llen-start);
        } else {
            /* 默认从跳表头部开始 */
            ln = zsl->header->level[0].forward;
            if (start > 0)
                 /* zslGetElementByRank仅支持正序排序，则正序起始位置为 start+1（rank从1开始） */
                ln = zslGetElementByRank(zsl,start+1);
        }
        /* 从起始节点开始，遍历(正向 or 反向)获取所有数据 */
        while(rangelen--) {
            ele = ln->ele;
            addReplyBulkCBuffer(c,ele,sdslen(ele));
            if (withscores)
                addReplyDouble(c,ln->score);
            ln = reverse ? ln->backward : ln->level[0].forward;
        }
    } else {
        serverPanic("Unknown sorted set encoding");
    }
}

/* 获取指定排序的元素 */
zskiplistNode* zslGetElementByRank(zskiplist *zsl, unsigned long rank) {
    zskiplistNode *x;
    unsigned long traversed = 0; // 记录移动次数
    int i;
    /* 从跳表的最高层开始遍历 */
    x = zsl->header;
    for (i = zsl->level-1; i >= 0; i--) {
        /* 如果当前层的移动次数 小于 rank，则继续当前层遍历，否则，进入下一层 */
        while (x->level[i].forward && (traversed + x->level[i].span) <= rank)
        {
            traversed += x->level[i].span;
            x = x->level[i].forward;
        }
        /* 如果遍历到指定排序位置 */
        if (traversed == rank) {
            return x;
        }
    }
    return NULL;
}

Reference

数据结构和算法-跳表的原理及实现
跳表──没听过但很犀利的数据结构

mysql v8.0 innodb locking

Shared and Exclusive Locks

InnoDB实现了两种标准的行锁（row-level locks）：

• 共享锁（shared(S) locks）允许持有该锁的事务读取数据行；

• 排它锁（exclusive(X) locks）允许持有该锁的事务更新或删除数据行。

共享锁被称为共享的原因在于：多个事务可以同时持有共享锁，从而实现数据的并发读取。

【例1】针对同一行数据r行，假设事务T1已持有该行的共享锁，则事务T2的请求加锁结果如下：

• 如果事务T2尝试获取该行的共享锁，则会立即生效，此时，事务T1与事务T2均持有r行的共享锁；
• 如果事务T2尝试获取该行的排它锁，由于锁冲突，导致事务T2进入阻塞等待状态（直到事务T1释放锁）。

【例2】针对同一行数据r行，假设事务T1已经持有该行的排他锁，则事务T2无论请求共享锁还是排它锁都会进入阻塞等待状态（直到事务T1释放锁）。

Intention Locks

InnoDB实现了多粒度的锁（multiple granularity locking），用于支持行锁与表锁的共存。

意向锁（Intention Locks）是表锁（table-level locks），用于表示事务稍后需要哪种类型的锁(共享的或排他的)来锁定表中的某一行。

• 意向共享锁（intention shared lock (IS)）表示事务打算对表中的各个行设置共享锁；
• 意向排他锁（intention exclusive lock (IX)）表示事务打算对表中的各个行设置排他锁。

意向锁与行锁的加锁规则

• 如果事务希望获取某行的S锁（row-level locks）之前，必须先获取表上的IS锁（table-level locks）或更强的锁;
• 如果事务希望获取某行的X锁（row-level locks）之前，必须先获取表上的IX锁（table-level locks）。

意向锁与表锁之间的兼容规则

【例】如果事务T1已经持有表的IX锁，则事务T2获取不同表锁的结果如下：

• 如果事务T2尝试获取X锁或S锁，则会造成锁冲突，事务T2进入阻塞等待（直到事务T1释放表的IX锁）；
• 如果事务T2尝试获取IX锁或IS锁，由于兼容规则，事务T2可以正常获取IX锁或IS锁。

注意意向锁与表锁、行锁的兼容规则的不同。

以下为用于测试初始化的SQL语句，

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# 建表
CREATE TABLE `t` (
  `id` int(11) NOT NULL,
  `c` int(11) DEFAULT NULL,
  `d` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `C`(`C`),
  UNIQUE KEY `d` (`d`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

# 初始化
INSERT INTO `test`.`t`(`id`, `c`, `d`) VALUES (0, 0, 0);
INSERT INTO `test`.`t`(`id`, `c`, `d`) VALUES (5, 5, 5);
INSERT INTO `test`.`t`(`id`, `c`, `d`) VALUES (10, 10, 10);

Record Locks

记录锁（record locks）是索引上的一种行锁。

如下面的sql，会对c1=10的行设置记录锁record lock，阻止其他事务对id=0的行进行插入、更新、删除。

1

SELECT * FROM t WHERE id = 0 FOR UPDATE;

Clustered and Secondary Indexes

mysql v8.0 Clustered and Secondary Indexes

InnoDB使用聚簇索引（clustered index）来存储数据，该索引的构建方式如下：

① InnoDB使用表中显示的主键（primary key）来构建聚簇索引；

② 如果没有主键，InnoDB会尝试寻找一个非空（NOT NULL）的唯一索引（UNIQUE INDEX）来构建聚簇索引；

③ 如果表没有主键且没有非空的唯一索引，InnoDB会为表生成一个隐式的ROW-ID的自增字段，构建名为GEN_CLUST_INDEX的聚簇索引。

How the Clustered Index Speeds Up Queries

聚簇索引的特点在于把所有的数据存储在叶子节点，实现了数据与索引的分离。

正常来说，数据占用的空间往往远大于索引，考虑不同索引实现的场景：

【场景1】如果采用BTree来实现，由于BTree的数据与索引是存储在同一个节点上，所以：

• 查询时可以直接从节点上获取数据，不需要遍历整棵树
• 每个节点上存储的索引有限，当遇到深层次遍历时会触发大量的磁盘IO
• 范围查询性能差，需要再次遍历也子节点

【场景2】如果采用B+Tree来实现，由于B+Tree的数据与索引是分离的，所以：

• 查询时需要遍历整棵数才可以到叶子节点获取数据
• 非叶子节点不存储数据从而可以存储更多的索引数据，当遇到深层次遍历时所触发的磁盘IO较少，从而拥有更好的性能
• 范围查询性能好，利用叶子节点的顺序链表来遍历查询

How Secondary Indexes Relate to the Clustered Index

除了聚簇索引，其他搜索都被称为二级索引。

二级索引中不会包含行的所有数据，仅会包括关联行的主键。

也就是说，二级索引的检索过程为：先检索二级索引，找到目标行的主键索引KEY，然后在检索聚簇索引，最终找到目标行的数据。

由于二级索引需要关联聚簇索引的KEY，因此聚簇索引的主键选择上不应该选择过大的数据结构。

有一点疑问：为什么二级索引不采用BTree实现？

如果采用BTree实现的话，指定的目标查询不会遍历到叶子节点，这是BTree的优势。
但是如果需要范围查询的时候，性能就不如B+Tree这种实现了，这应该是采用该索引的原因。

实际上，MySQL InnoDB可以设置两种索引类型：Btree和Hash，如果该索引不会有顺序查询，使用Hash索引更合适。

Gap Locks

间隙锁（gap locks）是对索引记录之间（两个记录之间、第一个记录之前、最后一个记录之后）间隙的锁。

间隙锁的作用在于防止其他事务操作当前间隙内的数据。

【例】下面的SQL会增加一个间隙锁，区间为(10, 20)，因此，其他事务无法在间隙内插入、更新或删除，例如插入15会被阻塞。

1

SELECT * FROM t WHERE c BETWEEN 10 and 20 FOR UPDATE

针对不同的索引类型，会出现不同的加锁情况：

• 对于唯一索引(UNIQUE INDEX)来说，锁定某行时仅需要锁定数据行（不需要间隙锁的）；
• 对于普通索引（INDEX）来说，锁定某行时不仅需要锁定数据行，还要锁定前后间隙；

对于测试数据来说，索引（不同字段之间数据值相同）存在的间隙有：(-∞, 0)、(0, 5)、(5, 10)、(10, +∞)。

不同的事务的间隙锁可以共存（甚至X锁与S锁），例如，在区间(0, 5)上，事务A持有S锁，事务B持有X锁。

在读已提交（READ COMMITTED）的隔离级别下，间隙锁不再用于搜索与索引扫描，仅用于外键约束检查和重复键检查。

Case 1

在初始化测试数据的条件下，考虑c为普通索引，加锁结果如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

# 事务A：加排它锁成功，间隙锁(0,5)与(5,10)、记录锁{5}
# 其中，间隙锁(5,10)是由于临键锁(5,10]降级而来，从5向右遍历发现10这个节点不满足=5，所以去除c=10的记录锁)
select * from t where c=5 for update; # ok

# 事务B：加插入意向锁失败，由于事务A持有间隙锁(0, 5)导致冲突
insert into t values (3, 3, 3); # blocking

# 此时，事务B提示：lock_mode X locks gap before rec insert intention waiting Record lock

# 事务C：加插入意向锁成功失败，由于事务A持有间隙锁(0, 5)（临键锁(5, 10]降级而来）导致冲突
insert into t values (8, 8, 8); # blocking

# 此时，事务C提示：lock_mode X insert intention waiting Record lock

# 事务D：加插入意向锁成功，由于13不在锁定范围之内
insert into t values (13, 13, 13); # ok

# 事务E：加入排他锁失败，由于记录锁{5}的冲突
update t set c=3 where c=5; # blocking

# 此时，事务E提示：lock_mode X waiting Record lock

# 事务F：加入排它锁成功，由于c=10，没有加锁
update t set c=99 where c=10;

c=5是一个普通索引的加锁行为，不仅对当前的行加记录锁，而且会对两侧的间隙加锁（左侧是间隙锁，右侧为临键锁）。

临键锁的退化：

① 在RR级别下，加锁的单位为临键锁；

② 针对二级索引的等值(c=5)的加锁情况，会按照索引顺序继续寻找不同的行，进而退化为间隙锁，例如事务F并没有阻塞。

Case 2

在初始化测试数据的条件下，考虑c为普通索引，加锁结果如下：

1
2
3
4
5
6
7
8
9
10
11
12

# 事务A：加排它锁成功，间隙锁(0, 5)、记录锁{5}、临键锁(5, 10]
# 注意，c between 0 and 5 为非等值查询，因此不存在临键锁的退化
select * from t where c between 0 and 5 for update; # ok

# 事务B：加排它锁失败，由于存在记录锁{5}的冲突
update t set c=3 where c=5;  # blocking

# 事务C：加插入意向锁失败，由于存在临键锁(5, 10]的冲突
insert into t values (7, 7, 7); # blocking

# 事务D：加排它锁失败，由于存在临键锁(5, 10])
update t set c=99 where c=10; # blocking

between类似于一个范围查询，会把范围内的都加锁（无论是行还是间隙）。

注意事务D的语句会被blocking，也证明了非等值语句的情况下，临键锁是不会退化的。

Next-Key Locks

临键锁（next-key locks）是记录锁与间隙锁的一种组合，锁住索引记录以及索引记录之前的间隙（(左开右闭的区间]）。

RR级别下，加锁的最小单元是临键锁（next-key locks），都是按照左开右闭的区间来加锁的。

不过，也存在锁降级的情况：

① 唯一索引下，降级为行锁

② 普通索引下，如果是等值查询的话，第二个临键锁（next-key locks）会退化为间隙锁（gap locks）。

对于测试数据中c索引来说，临键锁（不同字段之间数据值相同）的区间有：(-∞, 0]、(0, 5]、(5, 10]、(10, +∞)。

锁降级：唯一索引上，临键锁会降级为记录锁（不包括左右边缘）。

临键锁仅发生在可重复度（REPEATABLE READ ）的隔离级别，主要解决了幻读（phantom read）。

Case 1

唯一索引上的锁降级情况如下，

1
2
3
4
5
6
7
8
9
10
11

# 事务A：加排他锁成功，记录锁{5}
select * from t where id=5 for update; # ok

# 事务B：加插入意向锁成功
insert into t values (3, 3, 3); # ok

# 事务C：加插入意向锁成功
insert into t values (7, 7, 7); # ok

# 事务D：加排它锁失败，c=5 找到 id=5，由于记录锁导致加锁失败
update t where c=99 where c=5; # blocking

Case 2

在RR隔离级别下，在测试数据初始化的条件下，考虑c为普通索引，锁操作如下，

1
2
3
4
5
6
7
8
9
10
11

# 事务A：加排它锁成功，间隙锁(0,5)与(5,10)、记录锁{5}
# 其中，间隙锁(5,10)是由于临键锁(5,10]降级而来，从5向右遍历发现10这个节点不满足=5，所以去除c=10的记录锁)
select * from t where c=5 for update; # ok

# 事务B：加排他锁失败，由于临间隙锁(5, 10)的冲突
insert into t values (8, 8, 8); # blocking

# 此时，事务B提示：lock_mode X locks gap before rec insert intention waiting

# 事务C：加排他锁失败，不存在锁冲突
insert into t values (13, 13, 13); # ok

c=5为普通索引上的加锁，包括间隙锁(0, 5)、记录锁{5}、间隙锁(5, 10)(等值查询情况下的锁退化)。

Case 3

在RR隔离级别下，在测试数据初始化的条件下，考虑d为唯一索引，锁操作如下，

1
2
3
4
5
6
7
8

# 事务A：加排他锁成功，记录锁{5}
select * from t where d=5 for update; # ok

# 事务B：加插入意向锁成功，无冲突
insert into t values (8, 8, 8); # ok

# 事务C：加插入意向锁成功，无冲突
insert into t values (13, 13, 13); # ok

Case 4

在RR隔离级别下，在测试数据初始化的条件下，考虑c为普通索引，锁操作如下，

1
2
3
4
5
6
7

# 事务A：加排他锁成功，间隙锁(5, 10)，记录锁{10}，临键锁(10, +∞)
select * from t where c > 8 for update; # ok

# 事务B：加插入意向锁失败，由于存在临键锁(10, +∞)冲突
insert into t values (13, 13, 13); # blocking...

# 此时，事务B提示：lock_mode X insert intention waiting Record lock

Case 5

在RR隔离级别下，在测试数据初始化的条件下，考虑d为唯一索引，锁操作如下，

1
2
3
4
5
6
7
8

# 事务A：加排他锁成功，间隙锁(5, 10), 记录锁{10}, 临键锁(10, +∞)
select * from t where d > 8 for update; # ok

# 事务B：加插入意向锁失败，由于存在间隙锁(5, 10)冲突
insert into t values (7, 7, 7); # blocking...

# 事务C：加插入意向锁失败，由于存在临键锁(10, +∞)冲突
insert into t values (13, 13, 13); # blocking...

Insert Intention Locks

插入意图锁（insert intention locks）是一种间隙锁，当执行插入（insert）操作是触发。

【例1】以下SQL会加入插入意向锁，锁住的间隙是(0, 5)，

1

insert into t values(3, 3, 3);

多事务的插入意向锁

考虑到插入意向锁是间隙锁，因此，不同事务的插入意向锁可以共存。

不同事务同时持有相同间隙的插入意向锁的情况下，如果插入的位置不同（值不同），此时各个事务会正常执行插入操作，

否则，如果出现插入到相同位置，该事务会一直等待，直到插入该位置的事务释放锁。

【例2】存在三个事务，分别在初始化的测试数据集上尝试写入数据，具体如下，

1
2
3
4
5
6
7
8
9
10

# 事务A：持有插入意向锁成功，锁定区间(0, 5)，此时会给3增加行锁
insert into t values (3, 3, 3) # ok

# 事务B：持有插入意向锁成功，锁定区间(0, 5)，与事务A插入位置不同，所以无冲突，执行成功
insert into t values (4, 4, 4) # ok

# 事务C：由于事务A已经对于同一位置写入数据，由于3已经被A持有了行锁，因此，当前事务阻塞等待事务A的释放
insert into t values (3, 3, 3) # blocking

# 此时，事务C提示：lock mode S waiting Record lock

上面发现，相同位置数据的数据会提示S锁，插入不应该是X锁么？

对于唯一索引来说，插入前需要先检查是否存在重复数据，此时X锁先会降级为S锁来实现当前读。

AUTO-INC Locks

自增锁（auto-inc locks）是表锁（table-level locks），用于实现自增主键。

由于自增锁属于表锁，性能必然很差，因此，考虑到自增主键使用的场景，自增锁的锁定范围并不是整个事务，而是锁定的insert sql语句级别，

也就说，不同的事务之间，在insert时是交替完成的，虽然是表锁但对事务的并发插入并没有太大的影响。

Phantom Reads

幻读（phantom reads）是由于不同事务之间新增数据导致的前后数量不一致的问题。

幻读是insert引起的，不可重复读是由update或delete引起的。

幻读产生原因在于新增的，不可重复读产生的原因在于更新。

在RR隔离级别下，通过临键锁（next-key locks）解决了幻读。

select for update属于当前读（排它锁），而select属于快照读（无锁）。

select lock in share mode属于共享锁，无法与排它锁共存。

Case 1

即使InnoDB实现了MVCC解决了幻读的情况，但不同事务之间仍然存在先后插入数据的冲突问题。

在测试数据初始化的条件下，观察以下加锁结果：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

# 事务A：快照读，不会加锁
select * from t where id > 2; # ok

# 事务B：加插入意向锁成功，锁定id=3（记录锁）
insert into t values (3, 3, 3); # ok

# 事务A：加插入意向锁失败，由于事务B已经持有id=3的记录锁
insert into t values (3, 3, 3);  # blocking...

# 此时，事务A提示：lock mode S waiting Record lock

# 事务B：提交事务，写入id=3的数据
commit; # ok

# 事务A：由于事务B已经提交事务，返回失败"Duplicate entry '3' for key 'PRIMARY'"

# 事务A：失败后再次执行快照读（前后数据不变，观察不到事务B已经写入数据），虽然提示3已经写入，但还是观察不到
select * from t where id > 2; # ok

Dead Locks

死锁（dead locks）是由于多个事务相互持有互相等待的锁导致的。

Case 1

insert-insert-insert-rollback 三个事务写入的场景下的死锁

在测试数据初始化的条件下，观察以下加锁结果：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# 事务A：加插入意向锁(0,5)，id=3的排他锁（X锁）
insert into t values (3, 3, 3); # ok

# 事务B：加插入意向锁失败，优先获取S锁，查看数据是否存在，进入阻塞等待事务A的释放
insert into t values (3, 3, 3); # blocking...

# 事务C：同上
insert into t values (3, 3, 3); # blocking...

# 事务A：回滚，释放事务A上的锁
rollback; # ok

# 此时，事务B与事务C同时持有S锁，都在等待对方释放S锁进而添加X锁（存在死锁）
# 最终结果：
# 事务C：加插入意向锁(0,5)，id=3的排他锁（X锁）
# 事务B：加锁失败，出现死锁，返回异常：Deadlock found when trying to get lock; try restarting transaction

由于两个事务持有同一个记录的S锁，彼此等待对方释放S锁，进而进入死锁。

Case 2

update-insert 两个事务写入重叠锁区间场景下的死锁

在测试数据初始化的条件下，观察以下加锁结果：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# 事务A：加排他锁成功，间隙锁(0,5)、记录锁{5}、临键锁(5, 10]
select * from t where c=5 for update; # ok

# 事务B：加排他锁成功，间隙锁(5,10)、记录锁{10}、临键锁(10, +∞)
select * from t where c=10 for update; # ok

# 此时，存在锁重叠，区间为(5, 10]

# 事务A：加插入意向锁失败，由于事务B的间隙锁(5,10)冲突
insert into t values (7, 7, 7); # blocking

# 事务B：加插入意向锁失败，由于事务A的临键锁(5, 10]冲突
insert into t values (7, 7, 7); # Deadlock found when trying to get lock; try restarting transaction

# 事务A：加插入意向锁成功，由于事务A出现死锁。

Case 3

S X X

1
2
3
4
5
6
7
8
9
10

# 事务A：id=5 S锁
select * from t where id=5 for share; # ok

# 事务B：id=5 请求 X锁
select * from t where id=5 for update; # blocking

# 事务A：id=5 请求 X锁
select * from t where id=5 for update; # ok

# 事务B：Deadlock found when trying to get lock; try restarting transaction

1
2
3
4
5
6
7
8
9
10

# 事务A：id=5 S锁
select * from t where id=5 for share; # ok

# 事务B：id=5 请求 X锁
delete from t where id=5; # blocking

# 事务A：id=5 请求 X锁
delete from t where id=5; # ok

# 事务B：Deadlock found when trying to get lock; try restarting transaction

临键锁会分为两段加锁：加间隙锁与加记录锁。

1
2
3
4
5
6
7
8
9
10

# 事务A：间隙锁(0, 5)(5, 10)，记录锁{5}
select * from t where c=5 for share; # ok

# 事务B：加间隙锁成功(0,5)(5,10)，加记录锁{5}冲突，等待
update t set c=99 where c=5; # blocking

# 事务A：由于事务B持有间隙锁，因此出现死锁，事务B异常退出
insert into t values (3, 3, 3); #ok

# 事务B：Deadlock found when trying to get lock; try restarting transaction

limit

limit对加锁范围仍然有影响：仅会对扫描到的数据范围进行加锁。

Case 1

针对唯一索引的limit场景如下，

1
2
3
4
5

# 事务A：扫描id>0的数据，由于limit仅为1，则仅会锁住id=5的这条数据
delete from t where id > 0 limit 1; # ok

# 事务B：
delete from t where id > 5 limit 1; # ok

Case 2

针对非唯一索引的limit场景如下，

1
2
3
4
5
6
7
8

# 事务A：扫描c>0的数据，由于limit仅为1，间隙锁(0, 5)，行锁{5} 由于limit1，不会锁住5后面的区间
delete from t where c > 0 limit 1; # ok

# 事务B：由于事务A存在间隙锁(0, 5)，加锁失败
insert into t values (3, 3, 3); # blocking

# 事务C：无锁冲突，加锁成功
delete from t where c > 5 limit 1; # ok

Summary

数据库上的锁都是为了避免数据并发更新导致的问题，这与系统中所使用锁的初衷是一样的。

在InnoDB上，锁都是建立索引的基础之上，这里包括聚簇索引、二级索引等。

对于唯一索引来说，针对每个特定的值的遍历与查询是可以明确目标的，因此，不需要间隙锁，仅使用记录锁就可以了。

对于普通索引来说，针对某个特定的值的遍历与查询是不固定的，可能存在多个相同的值，此时就需要锁定目标值的前后，防止加入相同的值。

间隙锁是可以共存的，即使是冲突的锁，临键锁解决了幻读的问题。

插入意向锁是间隙锁，需要注意插入冲突的判断条件是位置是否相同，即使是相同范围的间隙锁，虽然插入位置不同也不会造成冲突。

对于自增锁来说，虽然是表锁，但锁定的时间仅限于插入SQL语句，不会跟随整个事务，因此，性能并没有那么差。

缓存

缓存是提高系统性能的关键，也必然会带来数据一致性的问题。

常见的缓存大概有以下几种，

客户端（浏览器）缓存

使用用户本地缓存来减少服务端的请求压力，会造成客户端与服务端数据不一致的问题。

客户端缓存可以有效的降低服务端的压力，例如，抢购以及电商大促时常常先把一些静态数据缓存到客户端本地。

cdn缓存

利用分布式的边缘服务器对服务端的数据进行缓存，客户端就近获取数据。

cdn缓存可以理解为利用中间件（分布式缓存）对服务端整体缓存，同样会造成数据不一致的问题。

cdn缓存一般用于静态数据，例如，前端相关的css、js，商品详情页的静态数据。

nginx缓存

nginx缓存一般仅用于服务端的静态数据的缓存，一般常用于前端相关的css/js等。

本地缓存

本地缓存是解决高并发的终极手段，但一定会存在数据不一致的问题。

大量的本地缓存会占用大量的业务内存，合理的设置LRU以及热点数据的评估是使用本地缓存的关键问题。

为了实现高并发，往往会采用数据的最终一致性。

分布式缓存

分布式缓存是目前微服务下最常用的缓存手段。

在一些QPS不高的业务下，并不需要本地缓存，仅仅使用分布式缓存就能实现很好的性能。

由于分布式缓存引入了新的中间件，会增加整个链路的网络IO开销。

常见的分布式缓存有Redis、Memcached。

缓存更新

缓存更新的方式大体可以分为两种：同步更新与异步更新。

由于更新的异步化，写入数据的同时不能保证数据的缓存刷新，因此，很难保证数据的强一致性。

同步更新大多适用于数据强一致性，而异步更新大多适用于数据的最终一致性。

以下几种实例中，均使用Memcached作为分布式缓存，MySQL作为持久化存储。

基于分布式缓存的同步更新

此方案是最基础的分布式缓存方案，关键在于同步的DB写入与缓存刷新。

read

优先读取缓存，如果不存在，则回源到DB，重新加载到缓存。

write

优先写DB，写成功后同步清理缓存。

基于分布式缓存的线程池异步更新

read

同上，优先读取缓存，如果不存在，则回源到DB，重新加载到缓存。

write

仅写DB，但写入成功后会直接返回，触发异步线程来做缓存的更新，存在缓存的不一致问题。

如图所示，与同步更新相比，异步线程不能保证数据更新的时效性，如果线程出现异常会导致长时间的缓存不一致的问题。

此外，如何设置合理的异步线程池也是一个关键问题。

基于分布式缓存的消息异步更新

read

同上，优先读取缓存，如果不存在，则回源到DB，重新加载到缓存。

write

仅写DB，但写入成功后会直接返回，使用mq作为异步操作持久化的媒介，从而解决异步线程池的问题，但仍然无法解决性能上的问题。

如图所示，使用RocketMQ中间件来作为异步化的媒介，通过Consumer来触发缓存的刷新。

基于分布式缓存的binlog异步更新

read

同上，优先读取缓存，如果不存在，则回源到DB，重新加载到缓存。

write

仅写DB，但写入成功后会直接返回，使用binlog来避免对于mq中间件的依赖，订阅binlog日志来实现缓存的生成。

这种方案引入了binlog日志，从复杂度上降低了直接的依赖，但也引入了间接的依赖。

Instagram才用了这种方式来实现高性能的服务，具体可参考Scaling Instagram Infrastructure。

基于本地缓存的binlog异步更新

read

优先读本地缓存，如果不存在，则回源到DB，重新加载到本地缓存。

此方案不需要两次网络IO（分布式缓存的Request与Response），性能上一定是更好的，但一致性很难保证。

write

优先写DB，写入成功并更新本地缓存后会直接返回。

为了解决分布式场景下本地缓存的同步更新，引入了Redis的发布订阅机制。

此方案仅更新了本地缓存，如果可以保证该用户请求均路由到同一机器，是可以解决当前用户可见性问题。

考虑到中间件的可靠性与时延问题，增加了SyncScheduler来实现定时同步机制。

基于分布式缓存的异步持久化

read

仅读取缓存，缓存数据的加载是通过缓存中间件来实现，服务不会直接与DB交互。

write

仅写缓存，缓存需要持久化策略，通过binlog通过到MySQL。

此方案使用分布式缓存作为数据库的前置缓存，通过实现缓存的持久化机制来同步数据到DB。

此方案需要具有缓存中间件定制化开发的能力，缓存异常恢复也是实现高可用服务的关键。

基于本地缓存的分治缓存策略

read

需要路由的支持，实现用户的特定路由，从而达到某个用户的所有操作均打到同一台机器上。

由于每台机器仅接受特定用户的数据，可以通过引入Zookeeper来获取一定的标识来预加载特定的数据。

仅读取本地缓存，通过SyncSheduler模块主动或定时拉取缓存数据。

write

仅写本地缓存，需要同步写入到数据库，从而保证数据的持久化。

此方案是基于路由能力，实现一套特定路由方案的缓存一致性策略。

通过保证用户请求路由的一致性，使用服务内存缓存特定数据，从而利用分布式服务来代替分布式缓存，从而满足数据的一致性。

这种方案没有具体实施过，特定的路由规则必然带来额外的复杂度。

这种方案在大型网站的库存系统中是否有过实现也未可知。

总结

缓存更新是分布式场景下无法避免的问题，大体可以分为同步与异步。

高性能与数据一致性往往不可兼得，强一致性与最终一致性之间如何取舍是架构设计的必经之路。

项目设计之初并不需要复杂的缓存设计，在满足性能的前提下架构的设计越简单越好。

如果DB的性能足以满足当前的需求，就不必引入分布式缓存。

如果分布式缓存的性能足以满足当前的需求，就不必引入本地缓存。

如果同步同步更新的性能满足当前的需求，就不必引入异步更新策略。

如果对数据的实时性要求不高，就没必要一定要同步调用，可以通过各种异步策略来实现。

如果线程池的方式满足当前的需求，就没必要引入为的中间件。

…

总之，缓存设计简单就好。

参考

基于 Canal 的 MySql RabbitMQ Redis/memcached/mongodb 的nosql同步

JVM Thread State

虚拟机中线程状态并不是操作系统真实的线程状态。

Thread.State属于虚拟机状态，与系统线程状态没有任何关系。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72

/**
 * A thread can be in only one state at a given point in time.
 * These states are virtual machine states which do not reflect
 * any operating system thread states.
 *
 * @since   1.5
 * @see #getState
 */
public enum State {
    /**
     * Thread state for a thread which has not yet started.
     */
    NEW,

    /**
     * Thread state for a runnable thread.  A thread in the runnable
     * state is executing in the Java virtual machine but it may
     * be waiting for other resources from the operating system
     * such as processor.
     */
    RUNNABLE,

    /**
     * Thread state for a thread blocked waiting for a monitor lock.
     * A thread in the blocked state is waiting for a monitor lock
     * to enter a synchronized block/method or
     * reenter a synchronized block/method after calling
     * {@link Object#wait() Object.wait}.
     */
    BLOCKED,

    /**
     * Thread state for a waiting thread.
     * A thread is in the waiting state due to calling one of the
     * following methods:
     * <ul>
     *   <li>{@link Object#wait() Object.wait} with no timeout</li>
     *   <li>{@link #join() Thread.join} with no timeout</li>
     *   <li>{@link LockSupport#park() LockSupport.park}</li>
     * </ul>
     *
     * <p>A thread in the waiting state is waiting for another thread to
     * perform a particular action.
     *
     * For example, a thread that has called <tt>Object.wait()</tt>
     * on an object is waiting for another thread to call
     * <tt>Object.notify()</tt> or <tt>Object.notifyAll()</tt> on
     * that object. A thread that has called <tt>Thread.join()</tt>
     * is waiting for a specified thread to terminate.
     */
    WAITING,

    /**
     * Thread state for a waiting thread with a specified waiting time.
     * A thread is in the timed waiting state due to calling one of
     * the following methods with a specified positive waiting time:
     * <ul>
     *   <li>{@link #sleep Thread.sleep}</li>
     *   <li>{@link Object#wait(long) Object.wait} with timeout</li>
     *   <li>{@link #join(long) Thread.join} with timeout</li>
     *   <li>{@link LockSupport#parkNanos LockSupport.parkNanos}</li>
     *   <li>{@link LockSupport#parkUntil LockSupport.parkUntil}</li>
     * </ul>
     */
    TIMED_WAITING,

    /**
     * Thread state for a terminated thread.
     * The thread has completed execution.
     */
    TERMINATED;
}

RUNNABLE状态需要注意一下，包含了就绪等待与运行两种实际的运行情况。

BLOCKED与Monitor Lock有关。

WAITING/TIMED_WAITING也同样是基于Monitor实现。

1
2
3
4
5
6
7
8
9

class ObjectMonitor {
  ...
  volatile markOop   _header;              // 对象头
  void*     volatile _object;              // 关联对象
  void *  volatile _owner;                 // 锁的持有者
  ObjectWaiter * volatile _EntryList ;     // 阻塞线程列表
  ObjectWaiter * volatile _WaitSet;        // 调用wait()等待monitor的线程
  ...
};

Linux Process State

Linux仅有定义Process State，也就是进程状态，具体包含五个状态：

• TASK_RUNNING(运行)
• TASK_INTERRUPTIBLE(中断)
• TASK_UNINTERUPTIBLE(不可中断)
• _TASK_TRACED(跟踪)
• _TASK_STOPPED(停止)

Java Thread yield

Thread.yield用于向调度器提示当前线程自愿让出处理器资源。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

 /**
  * A hint to the scheduler that the current thread is willing to yield
  * its current use of a processor. The scheduler is free to ignore this
  * hint.
  *
  * <p> Yield is a heuristic attempt to improve relative progression
  * between threads that would otherwise over-utilise a CPU. Its use
  * should be combined with detailed profiling and benchmarking to
  * ensure that it actually has the desired effect.
  *
  * <p> It is rarely appropriate to use this method. It may be useful
  * for debugging or testing purposes, where it may help to reproduce
  * bugs due to race conditions. It may also be useful when designing
  * concurrency control constructs such as the ones in the
  * {@link java.util.concurrent.locks} package.
  */
public static native void yield();

Thread.yield不会改变RUNNABLE的线程状态，只是会让出当前处理器进入就绪状态，等待下一次时间分片的分配执行。

openjdk jvm.cpp

1
2
3
4
5
6
7
8
9
10
11

JVM_ENTRY(void, JVM_Yield(JNIEnv *env, jclass threadClass))
  JVMWrapper("JVM_Yield");
  ...
  // When ConvertYieldToSleep is off (default), this matches the classic VM use of yield.
  // Critical for similar threading behaviour
  if (ConvertYieldToSleep) {
    os::sleep(thread, MinSleepInterval, false);
  } else {
    os::yield();
  }
JVM_END

Java Thread join

Thread.join是让当前线程进入BLOCKED状态。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

public final synchronized void join(long millis)
    throws InterruptedException {
    ...
    if (millis == 0) {
        while (isAlive()) {
            wait(0);
        }
    } else {
        # 空转
        while (isAlive()) {
            long delay = millis - now;
            if (delay <= 0) {
                break;
            }
            wait(delay);
            now = System.currentTimeMillis() - base;
        }
    }
}

从源码中可知，Thread.join是利用synchronized的Monitor来实现的线程的阻塞。

Java Thread sleep

Thread.sleep是让当前线程进入TIMED_WAITING状态。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

/**
 * Causes the currently executing thread to sleep (temporarily cease
 * execution) for the specified number of milliseconds, subject to
 * the precision and accuracy of system timers and schedulers. The thread
 * does not lose ownership of any monitors.
 *
 * @param  millis
 *         the length of time to sleep in milliseconds
 *
 * @throws  IllegalArgumentException
 *          if the value of {@code millis} is negative
 *
 * @throws  InterruptedException
 *          if any thread has interrupted the current thread. The
 *          <i>interrupted status</i> of the current thread is
 *          cleared when this exception is thrown.
 */
public static native void sleep(long millis) throws InterruptedException;

下面是JVM中源码实现，

首先，调用thread->osthread()->set_state(SLEEPING)，设置当前线程的状态，

然后，调用os::sleep(thread, millis, true)，触发os::sleep功能。

os::sleep的大概流程：

• 挂起进程（或线程）并修改其运行状态；
• 用os::sleep提供的参数来设置一个定时器；
• 当定时器会触发，内核收到中断后修改进程（或线程）的运行状态（进入就绪队列等待调度）。

openjdk jvm.cpp

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

JVM_ENTRY(void, JVM_Sleep(JNIEnv* env, jclass threadClass, jlong millis))
  JVMWrapper("JVM_Sleep");
  ...
  // Save current thread state and restore it at the end of this block.
  // And set new thread state to SLEEPING.
  JavaThreadSleepState jtss(thread);

  HS_DTRACE_PROBE1(hotspot, thread__sleep__begin, millis);

  if (millis == 0) {
    // When ConvertSleepToYield is on, this matches the classic VM implementation of
    // JVM_Sleep. Critical for similar threading behaviour (Win32)
    // It appears that in certain GUI contexts, it may be beneficial to do a short sleep
    // for SOLARIS
    if (ConvertSleepToYield) {
      os::yield();
    } else {
      ThreadState old_state = thread->osthread()->get_state();
      thread->osthread()->set_state(SLEEPING);
      os::sleep(thread, MinSleepInterval, false);
      thread->osthread()->set_state(old_state);
    }
  } else {
    ThreadState old_state = thread->osthread()->get_state();
    thread->osthread()->set_state(SLEEPING);
    if (os::sleep(thread, millis, true) == OS_INTRPT) {
      // An asynchronous exception (e.g., ThreadDeathException) could have been thrown on
      // us while we were sleeping. We do not overwrite those.
      if (!HAS_PENDING_EXCEPTION) {
        HS_DTRACE_PROBE1(hotspot, thread__sleep__end,1);
        // TODO-FIXME: THROW_MSG returns which means we will not call set_state()
        // to properly restore the thread state.  That's likely wrong.
        THROW_MSG(vmSymbols::java_lang_InterruptedException(), "sleep interrupted");
      }
    }
    thread->osthread()->set_state(old_state);
  }
  HS_DTRACE_PROBE1(hotspot, thread__sleep__end,0);
JVM_END

源码中SLEEPING状态对应着JVMTI状态如下，实际上就是State.TIMED_WAITING状态。

1
2
3
4
5
6
7
8
9
10
11

// Java Thread Status for JVMTI and M&M use.
// This thread status info is saved in threadStatus field of
// java.lang.Thread java class.
enum ThreadStatus {
...
SLEEPING = JVMTI_THREAD_STATE_ALIVE +          // Thread.sleep()
       JVMTI_THREAD_STATE_WAITING +
       JVMTI_THREAD_STATE_WAITING_WITH_TIMEOUT +
       JVMTI_THREAD_STATE_SLEEPING,
...
};

事件模型

Netty是一个基于Java NIO的高性能的通信框架。

Netty是Reactor的一种实现，通过分离Boss线程与Worker线程实现高性能的IO操作。

Selector是事件驱动的核心，是基于select/epoll/kqueue等实现。

BossGroup负责不断循环执行select来获取当前已经就绪的事件。

WorkerGroup负责具体的IO操作(OP_READ/OP_WRITE等)。

注意：BossGroup中线程的数量与绑定的端口有关，如果仅绑定一个端口，线程数为1即可。

ServerBootstrapAcceptor负责ParentGroup到ChildGroup之间Channel的传递.

Channel

Channel是IO操作的媒介，Netty中的Channel与JDK中NIO是一一映射的，

• NioSocketChannel <----> SocketChannel
• NioServerSocketChannel <----> ServerSocketChannel

Channel是NIO通信的基础，selector是需要注册到Channel来能实现事件驱动的绑定。

pipeline

Netty实现了一套pipeline以支持IO流的自定义处理。

如图所示，pipeline保存了用于此Channel的所有Handler，

其中，可以被分为两种：

• ChannelInboundHandler：处理读操作（对应着请求）的处理器
• ChannelOutboundHandler：处理写操作（对应着回复）的处理器

channel.read()是Channel的读操作，调用findContextInbound获取Inbound处理器，

channel.forceFlush()是Channel的写入操作，调用findContextOutbound获取outbound处理器。

在使用过程中，需要注意Inbound/outbound的顺序。

那么，pipeline到底什么用，举个例子：

• 利用ByteToMessageDecoder（ChannelInboundHandler）对读到的数据进行解码，
• 利用MessageToByteEncoder（ChannelOutboundHandler）来对回复的数据进行编码。

selector

NioSocketChannel & NioServerSocketChannel使用SelectorProvider来获取当前平台默认的事件驱动模型。

1

SelectorProvider DEFAULT_SELECTOR_PROVIDER = SelectorProvider.provider()

SelectionKey是selector获取到已就绪的事件，利用processSelectedKey实现读写事件的分发处理。

1
2
3
4
5
6
7
8
9
10
11
12
13

void processSelectedKey(SelectionKey k, AbstractNioChannel ch) {
    ...
    // 如果是写事件
    if ((readyOps & SelectionKey.OP_WRITE) != 0) {
        ch.unsafe().forceFlush();
    }

    // 如果是读事件
    if ((readyOps & (SelectionKey.OP_READ | SelectionKey.OP_ACCEPT)) != 0 || readyOps == 0) {
        unsafe.read();
    }
    ...
}