《源码》专题

一 . 导读 core 模块定义了事务的类型、状态，通用的行为，client 和 server 通信时的协议和消息模型，还有异常处理方式，编译、压缩类型方式，配置信息名称，环境context等，还基于 netty 封装了 rpc ，供客户端和服务端使用。 按包顺序来分析一下 core 模块主要功能类： codec：定义了一个 codec 的工厂类，提供了一个方法，根据序列化类型来找对应的处理类。还

一 .导读 spring 模块分析中讲到，Seata 的 spring 模块会对涉及到分布式业务的 bean 进行处理。项目启动时，当 GlobalTransactionalScanner 扫描到 TCC 服务的 reference 时（即tcc事务参与方），会对其进行动态代理，即给 bean 织入 TCC 模式下的 MethodInterceptor 的实现类。tcc 事务发起方依然使用 @Gl

一 . 导读 根据大佬定义的分类，配置可以有三种：环境配置、描述配置、扩展配置。 环境配置：像一些组件启动时的参数等，通常是离散的简单值，多是 key-value 型数据。 描述配置：与业务逻辑相关，比如：事务发起方和参与方，通常会嵌到业务的生命周期管理中。描述配置信息较多，甚至有层次关系。 扩展配置：产品需要发现第三方实现，对配置的聚合要求比较高，比如：各种配置中心和注册中心，通常做法是在 ja

本文记录了对 MOSN 的源码研究，研究 MOSN 是如何做到平滑重启的。 本文的内容基于 MOSN v0.8.1。 我们先将被重启的 MOSN 进程称为 旧 MOSN，将重启并接管流量的进程成为 新 MOSN。 机制 MOSN 没有使用重新读取 config 文件的方法来实现 reconfig，而是通过 unix socket 作为进程间通信，并将旧进程的监听 fd 通过 socket 传过去，

概述 Plugin 机制是 MOSN 提供的一种方式，可以让 MOSN 和一个独立的进程进行交互，这个进程可以用任何语言开发，只要满足 gRPC 的 proto 定义。 为什么我们支持这个功能，跟我们遇到的一些业务场景有关： 比如 log 打印，在 io 卡顿的时候会影响 Go Runtime 的调度，导致请求延迟。我们需要把 log 独立成进程做隔离。 我们会有一些异构语言的扩展，比如 stre

本文的目的是分析 MOSN 源码中的Log系统。 本文的内容基于 MOSN v0.10.0。 概述 MOSN 日志系统分为日志和Metric两大部分，其中日志主要包括errorlog和accesslog，Metrics主要包括console数据和prometheus数据 日志 errorlog errorlog 主要是用来记录MOSN运行时候的日志信息，配置结构: type ServerConfi

本文的内容基于 MOSN v0.10.0。 在连接管理中我们主要介绍 MOSN 实现连接池的功能，连接池是上下游 MOSN 之间进行长连接复用以提高转发效率与降低时延的关键，MOSN 连接池提供基于 HTTP1, HTTP2, SOFARPC, XProtocol 协议的连接池。 而“健康检查”是一种实时检测上游服务器是否正确提供服务的机制，一般分为“主动健康检查”和“被动健康检查”。主动健康检查

本镜像为 Ruby China 官方镜像，源为 cache.ruby-lang.org 用于改善国内 Ruby 安装的速度，同时这个镜像是实时更新的，在全国有 150 个 CDN 节点加速。 https://cache.ruby-china.com 特点 直接基于 CDN 对 Ruby 官方的文件进行镜像，并长久存储在国内； 简单的架构，无手工或定时更新之类的繁琐事情，能确保服务 99.9% 的稳

有了之前的《简述 Laravel Model Events 的使用》https://mp.weixin.qq.com/s/XrhDq1S5RC9UdeULVVksoA，大致了解了 Event 的使用。 今天我们就来扒一扒 Event 的源码。 开始之前，需要说下两个 EventServiceProvider 的区别： App\Providers\EventServiceProvider Illum

1 前言 详细分析源代码之前，如果能对其代码文件的基本结构有个大概的认识和分类，对于代码的分析将是大有裨益的。本节内容不多，我想并不是说它不重要！ 2 源代码组织结构 Libevent的源代码虽然都在一层文件夹下面，但是其代码分类还是相当清晰的，主要可分为头文件、内部使用的头文件、辅助功能函数、日志、libevent框架、对系统I/O多路复用机制的封装、信号管理、定时事件管理、缓冲区管理、基本数据

Memcached源码分析共8篇文章，前7篇文章主要分析每个模块的c源代码。这一篇文章主要是将之前的流程串起来，总结和回顾。同时通过这篇文章可以全局去看Memcached的结构。 一、Memcache的网络模型 Memcached主要是基于Libevent 网络事件库进行开发的。 Memcached的网络模型分为两部分：主线程和工作线程。主线程主要用来接收客户端的连接信息；工作线程主要用来接管客户

主要内容：一、基本介绍,二、Buffer Pool,三、Change Buffer,四、ADaptive Hash Index,五、Log Buffer,六、总结一、基本介绍 在前面基本把InnoDB引擎的相关内存数据结构分析说明完成了。那么，一个重要的问题来了，这些内存的数据结构有什么作用，用在哪儿？其实就是一个从设计到应用的问题。在学习源码的过程中，往往会有这么一种现象，就是单纯的学习一些源码的应用，或者说一些使用的技巧。稍微用心的可能看一个这些模块间是如何设计的，有什么可借鉴之处。 其实，

主要内容：一、说明,二、Buffer Pool,三、Change Buffer,四、ADaptive Hash Index,五、Log Buffer,六、总结一、说明 本来是想在前面的一篇分析中把源码和内容同时过一遍，可突然发现，那可能是非常大的一章。所以就把源码独立了出来，在此章节中对相关四类内存数据结构进行分析，在代码分析过程中，可以和前面的说明以及早先的日志分析一并进行对比，会有更大的收获。 二、Buffer Pool 按照老规矩，先看数据结构的定义相关代码： 此数据结构体的定义前面的说明

Kafka的源码 阅读起来，思路很清晰，命名也是很规范。 看完以后我们总结一下KafkaProducer这儿哪些地方值得我们学习： （1）Kafka的网络部分的设计绝对是一个亮点，Kafka自己基于NIO封装了一套自己的网络框架，支持一个客户端与多个Broker建立连接。 （2）处理拆包和粘包的的思路和代码，绝对是教科书级别的，可以把代码复制粘贴下来直接用到自己的线上的项目去。 （3）Record

今天在研究Java中Integer.parseInt的源码时，对于int multmin = limit / radix;这一句代码不太理解，请教一下为什么通过 result < multmin可以判断是否越界？ 参考资料：https://www.jianshu.com/p/da80a793dd57