Motan 框架支持的远程调用协议有 Motan、restful、grpc，这里只以 Motan 和 restful 协议实现为例。
一、Motan RPC 协议实现
Motan RPC 协议基于 NIO 框架 Netty 实现，采用 Hessian2 作为序列化机制。
Motan RPC 思维导图–特定协议实现部分
回复
作者归档：coderbee
Motan RPC 思维导图–通用逻辑部分
Motan RPC 框架分析
一、框架简介
Motan 是新浪微博开源的一套高性能、易于使用的分布式远程服务调用(RPC)框架。
Motan 的核心模块交互关系如下：
二、核心模块介绍
2.0 SPI 机制
SPI 机制支持 JDK 的 ServiceProvider 机制并进行了扩展，接口的实现放在 META-INF/services/ 目录下以接口的完全类名命名的文件里，每个实现的完全类名占一行。
每个实现类可以加上注解 @SpiMeta(name="implName") 来指定实现名称，ExtensionLoader 可以通过接口类型和命名从多个实现中找到指定实现。
8皇后问题
一、问题
一个 8×8 的棋盘，希望往里放 8 个棋子，每个棋所在的行、列、对角线上都不能有其他棋子。找出所有满足要求的布局。
二、分析与解
首先画出下面这样一个棋盘：
行、列的下标都是从 0 开始。
逐行摆放棋子，比如当前要摆放第 R 行的棋子时，认为 0 至 R-1 行的棋子是符合要求的，那么对于第 R 行，尝试把棋子摆放到第 C 列，检测是否满足要求，如果满足则继续下一行摆放下一行，不满足则则尝试放至 C+1 列。如果摆放到了第 8 行，则认为得到了一个解。
检测算法：从上图可以看出，只需要检查三种场景，对于位置(row, col)：
- 左下对角线；该对角线上的点符合
col >= 0 && (row--, col--)。 - 垂直列；(row–, col)， 行 渐减，列不变。
- 右下对角线。该对角线上的点符合
col < 8 && (row--, col++)。
SpringBoot druid 踩坑笔记
这是一个同事碰到的案例。
现象
SpringBoot 应用卡死、无反应。
处理过程
1、 导出线程栈，发现 Tomcat 处理线程都阻塞在获取连接上，从栈上看连接池使用的是 druid。
2、 对照 druid 源码，发现线程一直被阻塞是因为没有设置获取连接的超时时间。而从配置来看是有设置的。被阻塞的线程栈如下：
"http-nio-8006-exec-200" #7057 daemon prio=5 os_prio=0 tid=0x00007fc82c0a3800 nid=0x1b99 waiting on condition [0x00007fc7c9a57000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000c2923bd8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at com.alibaba.druid.pool.DruidDataSource.takeLast(DruidDataSource.java:1444)
at com.alibaba.druid.pool.DruidDataSource.getConnectionInternal(DruidDataSource.java:1088)
at com.alibaba.druid.pool.DruidDataSource.getConnectionDirect(DruidDataSource.java:953)
at com.alibaba.druid.filter.FilterChainImpl.dataSource_connect(FilterChainImpl.java:4544)
at com.alibaba.druid.filter.stat.StatFilter.dataSource_getConnection(StatFilter.java:661)
at com.alibaba.druid.filter.FilterChainImpl.dataSource_connect(FilterChainImpl.java:4540)
at com.alibaba.druid.pool.DruidDataSource.getConnection(DruidDataSource.java:931)
at com.alibaba.druid.pool.DruidDataSource.getConnection(DruidDataSource.java:923)
at com.alibaba.druid.pool.DruidDataSource.getConnection(DruidDataSource.java:100)
3、 通过内存 dump 发现，druid 连接池除 连接串、用户名、密码等几个属性之外的属性都是默认值。
此时连接池里总共有8个连接，都是空闲的，却没有线程能获取到连接，都在阻塞、没有被唤醒。网上查了下，应该是 druid 的bug。
《MySQL 实战45讲》–笔记–锁
锁
根据加锁的范围，MySQL 里面的锁大致可以分成全局锁、表级锁和行锁三类。
全局锁
全局锁是对整个数据库实例加锁。MySQL 提供的一个加全局锁的命令： Flush tables with read lock (FTWRL)，让整个库处于只读状态。
全局锁的典型使用场景是做全库逻辑备份。
逻辑备份工具 mysqldump 使用参数 -single-transaction 的时候在导数据之前就会启动一个事务，来确保拿到一致性视图。
一致性读的前提是引擎要支持这个隔离级别的事务。
set global readonly=true 也可以让全库进入只读状态。但存在两个风险： readonly 的值可能被用来做其他逻辑，比如判等一个库是主库还是备库；设置 readonly 之后，如果客户端发生异常，则数据库会一直保持 readonly 状态。
在 slave 上，如果用户有超级权限的话，全库只读 readonly=true 是失效的。
FTWRL 执行完后如果客户端异常断开，MySQL 会自动释放这个全局锁，整个库回到可以正常更新的状态。
《MySQL 实战45讲》–笔记–order by 实现
用 explain 命令查看执行计划的时候，Extra 列的值含有 “using filesort” 表示需要排序，可能是在内存里排序、也可能是磁盘文件排序。MySQL 给每个线程分配一块内存用于排序，称为 sort_buffer ，可以通过参数 sort_buffer_size 调整这个内存的大小。
如果要排序的数据都能放进 sort_buffer 则直接在内存里排序，否则需要借助磁盘临时文件进行辅助排序。
由于 InnoDB 是索引组织表，聚簇索引就是主键索引，下面的描述就用 rowid 替代主键值。
走索引全字段排序
- 初始化 sort_buffer，确定要放入 sort_buffer 的目标字段；
- 根据选择的索引查找满足条件的 rowid；
- 通过rowid到聚簇索引树获取整行数据，取目标字段放入sort_buffer；
- 从选择的索引取下一个记录的rowid；
- 重复步骤 3、4直到不满足条件；
- 对 sort_buffer 中的数据按照排序列进行排序。
- 遍历排序结果，把目标数据返回给客户端。
InnoDB Sorted Index Build
Sorted Index Build
InnoDB 在创建或重建索引时采用 批量加载而不是一次插入一个索引记录的方式。这种索引创建方法也称为 Sorted Index Build ，该方式不支持空间索引。
索引创建有三个阶段：
-
第一阶段，扫描聚簇索引，生成索引条目并添加到排序缓存(sort buffer)。当排序缓存满了后，条目被排序、写入临时的中间文件。这个过程也称为 run 。
-
第二阶段，一个或多个 run 写入临时中间文件，对文件里的所有条目执行合并排序。
-
在第三阶段，排序后的条目被插入到 B+tree 上。
Sorted Index build 采用自底向上方式来构建索引，采用这种方式，在 B+Tree 的每一层，持有对最右叶子页的引用。位于B+Tree需要的深度的最右叶子页被分配，条目按它们排序后的顺序插入。一旦叶子页满了，一个节点指针追加到父页上，同层叶子页被分配用于接下来的插入。这个过程持续至所有条目插入完成，这可能导致插入一直到顶层。
白话解读：最底层的最右叶子页插入索引记录，如果当前最右叶子页满了，生成一个新的最右叶子页作为接下来的插入位置，在新旧最右叶子页之间建立指针链接，然后把指向旧最右叶子页的指针追加到上一层的最右叶子页，触发上一层的最右叶子页插入，逻辑跟前面是一样的，这是个递归的过程，直至根页。这是一个自底向上、递归构建的过程。
最终生成的索引结构如下图（图片来自MySQL内核解析：Innodb页面存储结构-1）：
为后续插入保留空间
可以使用 innodb_fill_factor 配置选项来指定在 B+Tree 页空间保留的空闲百分比，用于后续在这些位置插入索引条目。
这个设置应用于索引树的叶子和非叶子页。不适用于外部页如用于 TEXT/CLOB 条目的。
这个配置是一个提示而非强制约束。
Consul 与 K8S 滚动部署
不停机发布讨论
近期公司的运维同事对一些系统尝试利用 K8S 的滚动发布机制不停机发布系统，应用和系统的状况是：POD 里的应用实例是注册在 Consul 上，Consul 的健康检查间隔是 10 秒；它们配置的 K8S 滚动发布机制直接把跑应用的 POD 终止了。
这样出现了：应用实例被终止后到 Consul 下次健康检查之前，Consul 认为应用实例是还存活的，把请求分发给了已经被停止的实例，这些请求当然是失败的。有的系统因为下游不支持重试，之前出现应用重试导致出现异常数据，就把 Ribbon、Feign、Hystrix 等的重试机制禁用了。而没有了重试机制请求就直接失败了，这样用户就会感知到系统发布。
大家开会讨论怎么才能让系统发布不会影响请求响应：
-
另一个部门的同事说他们就是所有接口都支持重试，所以允许对服务的某个实例请求失败可以重试到另一个实例，这样基本不会影响请求处理。让所有接口支持重试是需要上下游系统协调的，而且需要比较长的时间来实现。还有个问题是，不是所有接口都能重试的，举个行业特定的例子：信贷审批一般都会去查借款人的人行征信报告，多查一次可能导致借款人几个月都没法借款，设想一个报告查询的请求发出去了、在响应还没落地之前，应用实例就被终止了，这肯定是没法接受的。所以应用实例需要在被终止之前得到一个机会—-可以优雅停机的机会，它需要一个停机的通知。对于前面的问题，就是 K8S 要在停机前通知到 POD 里的实例，等通知返回后再终止 POD。
-
这就带来这个小插曲，我提出 K8S 在停止 POD 之前给 POD 里的应用发个通知的时候，运维同事说 Consul 和 K8S 是不同的系统，没法做到，他们说的非常肯定。。。
K8S POD 生命周期管理
对于一个问题，自己解决不了 跟 问题无解 是有区别。
在网上搜索一番后找到了 POD 生命周期钩子
MySQL InnoDB 二级索引的排序
排序问题
最近看了极客时间上 《MySQL实战45讲》，纠正了一直以来对 InnoDB 二级索引的一个理解不到位，正好把相关内容总结下。PS：本文的所有测试基于 MySQL 8.0.13 。
先把问题抛出来，下面的 SQL 所创建的表，有两个查询语句，哪个索引是非必须的？
CREATE TABLE `geek` (
`a` int(11) NOT NULL,
`b` int(11) NOT NULL,
`c` int(11) NOT NULL,
`d` int(11) NOT NULL,
PRIMARY KEY (`a`,`b`),
KEY `c` (`c`),
KEY `ca` (`c`,`a`),
KEY `cb` (`c`,`b`)
) ENGINE=InnoDB;
select * from geek where c=N order by a limit 1;
select * from geek where c=N order by b limit 1;
作者给的答案是索引 c 和 ca 的数据模型是一样的，因此 ca 是多余的。为啥？？
我们知道，二级索引里存放的不是行的位置，而是主键的值，也知道索引是有序的。
如果 c 与 ca 的数据模型一样，那么就要求二级索引的叶子节点不仅是按索引列排序、而且还按关联的主键值进行排序。
我以前的理解是 二级索引只按索引列进行排序，主键值是不排序的。
问了专栏作者，得到的答复是：索引 c 就是按照 cab 这样排序，（二级索引)）有保证主键算进去、还是有序的。（PS：非原话，前后问了三次得到）。
本着 先问是不是，再问为什么 的思路，进行一番探究。