├── accountcmd.go 
├── chaincmd.go 
├── config.go 
├── consolecmd.go 
├── dbcmd.go 
├── misccmd.go 
├── snapshot.go 
├── usage.go 🔫
└── version_check.go 🔫

《深入学习 Go-Ethereum : 013. CMD 模块 - Geth - snapshot.go》中罗列了 snapshot 子命令集主要源码，接下来描述下关于 usage.go&version_check.go 中的代码功能。

⬇️ usage.go

usage 主要定义了众多flag相关信息,并对帮助信息进行打印。其中使用helper.go中相关方法和结构体完成主要功能。

👇定义了命令的名称和使用说明

⬇️ version_check.go

主要功能是进行 geth 对应版本的漏洞检查，使用命令 geth version_check （命令定义在 misccmd.go ）,如果不传入参数，默认请求的校验地址是version_check_url。

👇JSON数据如图，包含了name、uid、CVE编号等等信息。

👇核心代码结构

使用效果如图：

截止到此， geth 中相关的主要代码已经了解大概，后续穿插了解记录关于 cmd 模块中其他命令的主要代码。后续规划了解 geth 的业务核心代码 (列表如下👇）：

1. 基础组件（密码学、数据序列化/反序列化、数据存储）：

   1. 🔖 rlp - 以太坊序列化-递归线性前缀(Recursive Linear Prefix)模块

   2. 🔖 trie - 改进的默克尔+前缀树 MPT(Merkle Patricia Tries)

   3. ❇️ ethdb - 以太坊堆数据库的操作代码,包含了levelDB和内存数据库

   4. ❇️ common - 公用工具,如:debug、数学相关、bit工具等

   5. ❇️ internal - 项目内部使用工具代码,如构建、debug、调用服务API、测试指南、测试日志、web3js扩展等

2. 网络层（p2p、rpc）：

   1. 🔖 p2p - 点对点网络协议相关实现

   2. 🔖 rpc - 以太坊RPC服务

3. 业务层（账户体系、交易、共识机制、gas、evm等）：

   1. 🔖 accounts - 以太坊的钱包、地址、账号系统,不同于 Bitcoin 的 UTXO 模式

   2. 🔖consensus - 共识机制,实现不同的以太坊共识机制引擎

   3. ❇️ core - 系统核心的数据结构和基础模块,如 虚拟机 、状态模块、批量数据的布隆过滤器 、RawDB、汇编模块

   4. ❇️ eth - 以太坊协议的核心模块,包含了节点发现、全节点数据下载、eth配置、数据获取(base header、交易、区块)、协议(广播、点对点等)、gas模块

   5. 🔖miner - 提供以太坊的区块创建和挖矿

❇️ : 穿插在其他模块了解、分析代码。

🔖 ：主入口，顺序为 rlp → trie → accounts → consensus → miner → p2p → rpc

├── accountcmd.go 
├── chaincmd.go 
├── config.go 
├── consolecmd.go 
├── dbcmd.go 
├── misccmd.go 
├── snapshot.go 🔫
├── usage.go
└── version_check.go

《深入学习 Go-Ethereum : 012. CMD 模块 - Geth - misccmd.go》中罗列了 misccmd 主要源码，接下来描述下关于 snapshot.go 中的代码功能（基于2022-07-25的认知稀里糊涂的记录）。

⬇️ snapshot.go

snapshot 是一系列子命令的集合。其中包含了：

1. 等同于 geth dump 功能的 geth snapshot dump 方法

2. 基于快照的历史状态数据清理 prune-state

3. 基于快照数据重新进行hash计算，用于验证 verify-state

4. 检查是否存在 “dangling” 数据 check-dangling-storage

5. 用给定的root hash进行遍历校验 traverse-state (快速遍历)

6. 用给定的root hash进行遍历校验 traverse-rawstate （遍历每一个节点）

⬇️ pruneState方法：

描述：geth snapshot prune-state <state-root> will prune historical state data with the help of the state snapshot. All trie nodes and contract codes that do not belong to the specified version state will be deleted from the database. After pruning, only two version states are available: genesis and the specific one.

(对历史状态数据进行清理，不满足指定版本状态所有trie结构节点数据和合约代码将会被清除，只有两个版本数据有效：创世区块和唯一指定的数据)。

关键方法调用 core.state.prune.pruner.go 中的 Prune() 方法。后续对其中代码详细分析。（数据检索使用到了 Bloom Filter ）

⬇️ verifyState方法：

描述：geth snapshot verify-state <state-root> will traverse the whole accounts and storages set based on the specified snapshot and recalculate the root hash of state for verification. In other words, this command does the snapshot to trie conversion.

（此方法对指定的快照中账户和存储集合进行遍历，然后重新计算状态数据根哈希值，以用于校验。换句话说，这个命令将快照转换成 Trie 「字典树」格式）。

⬇️ checkDanglingStorage方法：

描述：geth snapshot check-dangling-storage <state-root> traverses the snap storage data, and verifies that all snapshot storage data has a corresponding account.

（此方法遍历快照中的存储数据，并校验所有存储数据都有与之对应的账户）

⬇️ traverseState方法：

描述：geth snapshot traverse-state <state-root> will traverse the whole state from the given state root and will abort if any referenced trie node or contract code is missing. This command can be used for state integrity verification. The default checking target is the HEAD state. It's also usable without snapshot enabled.

(此防范会遍历整个状态数据，当出现Trie节点或者合约代码丢失。此命令可以用于状态数据的完整验证。默认的检查是 「区块头」 状态数据)

⬇️ traverseRawState方法：

和traverseState方法的主要区别，1.方法获取数据的二进制原始数据，差别如下图⬇️

LeafBlob returns the content of the leaf，返回类型 []byte 。2.会检查所有Tire节点。

⬇️ dump方法：

描述：This command is semantically equivalent to 'geth dump', but uses the snapshots as the backend data source, making this command a lot faster. The argument is interpreted as block number or hash. If none is provided, the latest block is used.

（此方法基于快照进行数据dump，速度会比 geth dump 快）。

├── accountcmd.go 
├── chaincmd.go 
├── config.go 
├── consolecmd.go 
├── dbcmd.go 
├── misccmd.go 🔫
├── snapshot.go
├── usage.go
└── version_check.go

《深入学习 Go-Ethereum : 011. CMD 模块 - Geth - dbcmd.go》中罗列了 dbcmd 主要源码，接下来描述下关于 misccmd.go 中的代码功能。

⬇️ misccmd.go

misccmd 是多种功能的混合代码。 其中包括查看版本、版本检查、授权查看、生成缓存(测试使用)、生成DAG（有向环形图）。

⬇️ makecache 方法：

用来创建ethash共识校验使用的缓存数据。

⬇️ makedag 方法：

// makedag generates an ethash mining DAG into the provided folder.

Ethash 是 PoW 系统，它需要一个大约 1GB 的数据集，它就是 DAG，在硬盘中存储它。

⬇️ version/license 方法：

获取 geth 的版本信息和授权信息。

使用效果如下:

├── accountcmd.go 
├── chaincmd.go 
├── config.go 
├── consolecmd.go 
├── dbcmd.go 🔫
├── misccmd.go
├── snapshot.go
├── usage.go
└── version_check.go

《深入学习 Go-Ethereum : 010. CMD 模块 - Geth - consolecmd.go》中罗列了 consolecmd 主要源码，接下来描述下关于 dbcmd.go 中的代码功能。

dbcmd 会依赖 go-ethereum 项目源码中

"github.com/ethereum/go-ethereum/cmd/utils"、 "github.com/ethereum/go-ethereum/common"、 "github.com/ethereum/go-ethereum/common/hexutil"、 "github.com/ethereum/go-ethereum/console/prompt"、 "github.com/ethereum/go-ethereum/core/rawdb"、 "github.com/ethereum/go-ethereum/core/state/snapshot"、 "github.com/ethereum/go-ethereum/core/types"、 "github.com/ethereum/go-ethereum/ethdb"、 "github.com/ethereum/go-ethereum/log"、 "github.com/ethereum/go-ethereum/trie" 相关组件。

⬇️ dbcmd.go

dbcmd 主要功能是操作levelDB(一个本地的 Key-Value 数据库)，代码主要包含了 db 命令和 13 个子命令及实现相应功能的函数。

geth db --help 查看子命令列表及简介

⬇️ removeDB 方法：

查看 db 统计信息

删除数据库中数据 geth removedb

再次查看数据库，不存在数据库文件

代码主逻辑⬇️：

提醒用户确认并删除数据文件⬇️

⬇️ inspect 方法：

主要作用是检查当前数据库中的数据分布，代码如下图⬇️，主要逻辑处理 rawdb.InspectDatabase() 。

对比参数查询结果：左侧是有前缀参数、右侧无参数（全数据库） 。

⬇️ dbStats 方法：

主要作用查询数据库存储状态,其中最重要的代码逻辑是

1. db.Stat() →

2. ethdb/leveldb/leveldb.go 代码中的 db.db.GetProperty() →

3. leveldb/db.go 代码中的 GetProperty()，获取levelDB的统计数据

⬇️ dbCompact 方法：

Compact 主要作用「压缩」数据，对指定范围 start ，limit 两个参数范围内的数据进行处理，本质上是对 删除的 数据和不再使用的版本数据 进行重排序。（⚠️：此方法会花费较长时间。同时对数据进行加锁）

1. db.Compact() →

2. ethdb/leveldb/leveldb.go 代码中的 db.db.CompactRange() →

3. leveldb/db_write.go 代码中的 CompactRange()，进行数据压缩处理

⬇️ dbGet、dbDelete、dbPut 方法：

主要是使用 levelDB 的 db.go 进行操作。

⬇️ dbDumpTrie 方法：

指定根节点进行数据导出操作。

⬇️ freezerInspect 方法：

导出”冷数据“，指定导出的数据类型，开始数据 index，和结束数据 index。

数据类型参数范围是[bodies diffs hashes headers receipts]

通过下面命令进行 “凉凉“ 数据进行 dump 操作。

⬇️ importLDBdata 方法：

导入指定文件(以RLP格式进行快照)数据到 eth.Database ,如果是 gz 文件会通过 gzip 进行文件操作。

// ImportLDBData imports a batch of snapshot data into the database 可以查看 utils.ImportLDBData() 具体实现

⬇️ exportChaindata 方法：

与 import 对应的方法就是数据的导出。导出需要指定数据是preimage还是snapshot，此外需要指定导出文件名及文件后缀名，如果是gz格式，程序会使用gzip进行文件压缩。

调用ExportChaindata()进行数据文件生成

⬇️ showMetaData 方法：

显示levelDB相关元数据信息，比如数据库版本、头信息、快照信息等

⬇️ freezerMigrate 方法：

迁移”冷数据“，到指定表中「receipts」

以上是dbcmd中代码的主要功能。底层依赖ethdb进行操作KV数据库leveldb。

⬇️以下是 cmd/geth 包中其他代码的介绍：

├── accountcmd.go 
├── chaincmd.go 
├── config.go 
├── consolecmd.go 🔫
├── dbcmd.go
├── misccmd.go
├── snapshot.go
├── usage.go
└── version_check.go

⬇️ consolecmd.go

consolecmd 主要功能是创建一个可以交互的Javascript环境（本地节点、远程节点、临时执行js文件的节点），代码主要包含了 3 个子命令 js 、 attach、console 及实现相应功能的4个函数。

⬇️ localConsole 方法：

1.创建环境，准备全节点。

2.通过stack.Attach 创建rpc客户端（通过ipc通信。

3.根据参数获取配置信息后，创建console对象，生成js交互环境。并开启goroutine等待statck信息。

⬇️ remoteConsole 方法：

1.解析参数,判断是 RPC 还是 IPC，如果是IPC ，判断是什么网络（主网、Ropsten、Rinkeby等）。

2.调用 dialRPC 方法，创建 endpoint 的 RPC 客户端。

3.根据参数获取配置信息后，创建console对象，生成js交互环境。并开启goroutine等待statck信息。

⬇️ dialRPC 方法：

如果参数为空，默认开启 IPC 连接，否则创建 RPC 客户端

⬇️ ephemeralConsole 方法：

1.创建一个全节点服务。

2.goroutine 异步等待。

3.遍历参数中的js文件，执行完毕后，关闭console。

⬇️以下是 cmd/geth 包中其他代码的介绍：

├── accountcmd.go 
├── chaincmd.go 
├── config.go 🔫
├── consolecmd.go
├── dbcmd.go
├── misccmd.go
├── snapshot.go
├── usage.go
└── version_check.go

⬇️ config.go

config 代码主要包含了 1 个子命令（dumpconfig） 及configFileFlag相关描述。

其中比较重要的代码为dumpconfig及configFileFlag声明，此外定义了两个结构体：gethConfig（主要包含了eth、node、ethstat、metrics）和ethstatsConfig（toml文件路径）。

其他的方法介绍如下：

⬇️ dumpConfig 方法：

dumpConfig 方法的主要作用是对节点配置信息的导出。（导出文件格式 TOML）

使用方法 geth dumpconfig filename 。

⬇️ loadConfig 方法：

根据指定文件路径（一般都是从别的环境中dump出相应的配置信息），进行配置信息的导入。文件格式内容使用TOML进行配置。

查看调用关系，此方法被 config.go 和 accountcmd.go 使用。

配置文件部分信息示例：

[Eth]
NetworkId = 1
SyncMode = "snap"
EthDiscoveryURLs = ["enrtree://AKA3AM6LPBYEUDMVNU3BSVQJ5AD45Y7YPOHJLEF6W26QOE4VTUDPE@all.mainnet.ethdisco.net"]
SnapDiscoveryURLs = ["enrtree://AKA3AM6LPBYEUDMVNU3BSVQJ5AD45Y7YPOHJLEF6W26QOE4VTUDPE@all.mainnet.ethdisco.net"]
......

⬇️ makeConfigNode 方法：

此方法的主要功能是加载geth配置信息并创建一个区块节点实例 。

⬇️ makeFullNode 方法📍：

在geth启动时被调用，根据上下文参数，创建相应的配置信息，并启动eth后端服务。

以上是 config.go 代码中比较重要的方法及功能介绍。

⬇️以下是 cmd/geth 包中其他代码的介绍：

├── accountcmd.go 
├── chaincmd.go 🔫
├── config.go
├── consolecmd.go
├── dbcmd.go
├── misccmd.go
├── snapshot.go
├── usage.go
└── version_check.go

⬇️ chaincmd.go

chaincmd 代码主要包含了7个子命令（init、dump、dumpgenesis、export-preimages、import-preimages、export、import） 及对应的实现方法

⬇️ 子命令声明

⬇️ initGenesis 方法：

在使用 geth init 命令时需要提供 genesis.json 文件（也可以不使用init命令，各种配置项以参数方式进行启动），作为创世区块的基本配置。配置信息可以查看 私有网络 相关介绍。

⚠️ 备注：只有当 network*、chainID、创世区块配置 * 都相同时，才是同一条链。

Every blockchain starts with the genesis block. When you run Geth with default settings for the first time, it commits the main net genesis to the database. For a private network, you usually want a different genesis block.

在一个节点启动的时候，做为默认数据，会使用主网的创世块。如果是一个私有网络，通常需要一个不同的创世块信息。

关于配置项 ，json 中配置项对应了 core/genesis.go 代码中的 Genesis 结构体。

*示例1： Genesis.json（*with an empty chain configuration ）:

{
  "alloc"      : {},
  "coinbase"   : "0x0000000000000000000000000000000000000000",
  "difficulty" : "0x20000",
  "extraData"  : "",
  "gasLimit"   : "0x2fefd8",
  "nonce"      : "0x0000000000001338",
  "mixhash"    : "0x0000000000000000000000000000000000000000000000000000000000000000",
  "parentHash" : "0x0000000000000000000000000000000000000000000000000000000000000000",
  "timestamp"  : "0x00",
   "config"     : {}
}

配置项解释如下：

alloc 初始化区块链，给预定用户进行资产分配（单位时 WEI ）。

difficulty 挖矿的难度，能决定酸楚nonce的难度。

nonce 挖矿的一次性数字随机数。

coinbase 出块的奖励，一般在启动服务作为挖矿节点的时候，会设置当前节点挖矿奖励的目标地址是自己。

timestamp 时间戳，规定创世区块开始的时间。

parentHash 父区块的 hash 。

gasLimit 当前区块的 gas 上限。

mixhash pow机制中， 出块权获取后，给别的矿工进行验证的摘要信息。

extraData 额外的信息。

示例2： Genesis.json（ with specific chain configurations ）:

{
  "config": {
    "chainId": 15,
    "homesteadBlock": 0,
    "eip150Block": 0,
    "eip155Block": 0,
    "eip158Block": 0,
    "byzantiumBlock": 0,
    "constantinopleBlock": 0,
    "petersburgBlock": 0,
    ...
    ...指定区块的高度
    "ethash": {}
  },
  "difficulty": "1",
  "gasLimit": "8000000",
  "alloc": {
    "7df9a875a174b3bc565e6424a0050ebc1b2d1d82": {
      "balance": "300000"
    },
    "f41c74c9ae680c1aa78f42e5647a62f353b7bdde": {
      "balance": "400000"
    }
  }
}

配置项解释如下：

chainId 区块链的Id，默主网Id是 1 。

***Block 区块高度，根据硬分叉等升级需求，指定区块高度（相关信息可以点击查看源码）。

⬇️ 主网创世块区块信息如图

⬇️ dumpgenesis 方法：

此方法主要功能是导出创世块的数据信息，默认打印在控制台。执行 geth dumpgenesis 效果⬇️

⬇️ 代码截图

调用 utils.MakeGenesis() 方法， 最终执行 core.Genesis 的 DefaultGenesisBlock() 方法

⬇️ exportChain 方法：

此方法功能是将当前区块链数据导出成文件（使用 gzip 进行文件输出），执行 append 模式。具体导出代码可查看 ExportChain 和 ExportAppendChain

⬇️ importChain 方法：

导入指定文，创建 Blockchain对象。其中主要的方法逻辑是 创建 node 对象、创建 chain 对象、判断参数数量执行 ImportChain

⬇️ exportPreimages 方法：

以RLP方式编码，导出preimage数据。

⬇️ importPreimages 方法：

导入指定文件的 preimage 数据，使用 rawdb 的WritePreimages方法进行数据库数据操作。

⬇️以下是 cmd/geth包中其他代码的介绍：

├── accountcmd.go 🔫
├── chaincmd.go
├── config.go
├── consolecmd.go
├── dbcmd.go
├── misccmd.go
├── snapshot.go
├── usage.go
└── version_check.go

⬇️accountcmd.go

accountcmd.go 包含了 account 和 wallet 两个子命令。

两个命令分别是 wallet（预售钱包） 和 account 的管理功能。

例如：列出当前节点中创建或者导入的账号

⬇️ geth account list

⬇️ geth account new

geth wallet import ：用来导入 presale（预售） 账户钱包

account 相关源码

⬆️ accountList 方法，主要是获取当前节点可管理账号信息列表（包含了本地创建、导入的账号）。

代码逻辑是通过 ctx 上下文获取 Node 对象的stack实例，然后获取账户管理器，查询节点的所有钱包信息。然后进行遍历，打印 Account 的地址和 keystore 存储 url 地址。

⬆️ accountCreate 方法，根据用户输入的密码，创建一个账号，控制台打印创建用户对应的公开地址 和 keystore 文件存储路径。具体代码可查看 StoreKey 函数。

⬆️ accountUpdate 方法，输入参数是账号地址，可以对账号的格式进行更新，也可以对账号进行解锁（修改账号的密码，使用 unlockAccount 方法）。

⬆️ unlockAccount 方法， 对指定账号进行解锁。调用 keystore 的 unlock 方法。如果解锁失败，则进行模糊地址（可能存在一个地址对应了多个 keystore 文件）恢复。

⬆️ ambiguousAddrRecovery 方法，修复单一账户对应多个keystore 文件问题。🤔️ 什么情况会出现此现象❓

⬆️ accountImport 方法， keystore.go 使用 ImportECDSA 导入账号信息，这里操作导入的参数是私钥数据所在的文件路径

例如 7b2905d895b6a0e5ba976cff63bb80ac1600c8811f59f74e29919c46e6053dbe 存储在 /Users/zhangyu/z.txt（MacOS） 文件中，使用 geth account import /Users/zhangyu/z.txt 即可。输入密码后，账号导入成功 🎉

其中最为重要的就是 geth 命令。它是使用以太坊客户端的主要命令。它还包含了很多子命令。在命令行中，可以使用 geth --help ⬇️查看相关帮助手册。

⬆️如上图是 geth 的子命令信息，使用频次比较高的例如 account、console、db、dump、init、wallet 等

程序入口 cmd/geth/main.go⬇️

geth 的命令行使用 "gopkg.in/urfave/cli.v1" 库做为基础， 代码中执行 app.Run 启动geth。

在初始化函数中，指定了 geth 函数。程序的核心入口 ⬇️

// geth is the main entry point into the system if no special subcommand is ran.
// It creates a default node based on the command line arguments and runs it in
// blocking mode, waiting for it to be shut down.
func geth(ctx *cli.Context) error {
    if args := ctx.Args(); len(args) > 0 {
        return fmt.Errorf("invalid command: %q", args[0])
    }
    prepare(ctx)
    stack, backend := makeFullNode(ctx)
    defer stack.Close()
    startNode(ctx, stack, backend, false)
    stack.Wait()
    return nil
}

1. 程序先判断上下文参数是否存在异常参数，如果存在异常参数，直接打印错误信息，并终止程序。

2. 预处理 prepare 方法，主要内容是 创建缓存 和 启动度量服务（启动 InfluxDB 时序数据库进行记录）。

3. 创建全节点。// makeFullNode loads geth configuration and creates the Ethereum backend.

4. 启动节点。

5. 阻塞方式运行程序，等待关闭或者异常错误终止程序。

makeFullNode ⬇️

https://github.com/HugePages/go-ethereum/blob/26ff2c1e0ed8eae9e83ddec6c777bfec9afef906/cmd/geth/config.go#L121

⬆️此方法的主要功能是 设置系统级别参数 和 启动 ethereum network 后台服务，方法内部关注makeConfigNode() 和 utils.RegisterEthService()

⬆️创建配置节点主要是获取 eth 的配置信息、节点的默认配置信息、度量服务的默认配置星系。然后将这些配置信息进行处理，创建 node 对象 stack, err := node.New(&cfg.Node)

⬆️RegisterEthService 是将一个 Ethereum 客户端添加到 stack 中， 如果启动时轻节点服务，此方法两个返回值中第二个是 les.Ethereum。如果同步模式是轻客户端模式，则启动轻量级客户端，否则启动全节点客户端，核心方法是 eth.New

startNode ⬇️

// startNode boots up the system node and all registered protocols, after which it unlocks any requested accounts, and starts the RPC/IPC interfaces and the miner.

此方法主要功能包含 启动系统节点和所有注册的协议、解锁用户、启动 RPC/IPC 接口服务、启动矿工挖矿服务。

1. 添加对象内存大小计算功能，使用 memsize 类库进行处理

2. utils启动节点

3. 解锁请求账户（意图还不了解，//TODO

4. 订阅钱包事件

5. 绑定本地客户端和geth节点的交互

6. 创建客户端

7. 开启协程进行「事件」处理

以上就是默认 geth 启动的代码流程了。

参考链接：

https://www.cnblogs.com/wanghui-garcia/p/10252260.html

https://knarfeh.com/2018/03/10/go-ethereum%20%E6%BA%90%E7%A0%81%E7%AC%94%E8%AE%B0%EF%BC%88cmd%20%E6%A8%A1%E5%9D%97-geth%20%E5%91%BD%E4%BB%A4%EF%BC%89/

结构图:

区块 ( Block )

Block区块头 ( Header )

区块体 ( Body )

拓展区块信息 ( ExtBlock )

底层基础:

• P2P 网络

• 密码学

• 中间件 : KV 、时序数据库

核心功能组件:

• 账号体系、钱包、地址

• 区块、交易、状态、事件

• 经济机制 : Miner、Gas

• EVM

生态:

• 智能合约 : Solidity、Rust

• 开发工具 : Remix

• 基础设施 : 去中心化存储、预言机等

Further reading …

https://ethereum.stackexchange.com/questions/268/ethereum-block-architecture/757

https://eth.wiki/en/fundamentals/design-rationale

https://book.douban.com/subject/30199891/

https://preethikasireddy.medium.com/how-does-ethereum-work-anyway-22d1df506369

https://bit.ly/3N6ALsD

具体文本文件可以访问 包说明.txt

其中（个人此时认为，后续跟进补充）比较重要的几个包,清单如下:

Ethereum 的主流版本 Geth ,代码托管在 Github 中. 具体的访问地址如下:

https://github.com/ethereum/go-ethereum

此项目也是ethereum账号下star最多的开源项目.

安装Golang

因为此项目的开发语言是 Golang,所以电脑需要安装 Golang 环境.我的电脑系统是 MacOS,使用常用的软件包管理工具 brew 进行安装.

(如果不了解可以访问 https://brew.sh 进行相关工具的了解,其他操作系统可自行 Google )

安装完成后,可以使用 go version 进行测试,会显示对应的版本号,效果如下:

以上完成了第一步, Golang 环境的安装.

下载源码和编译

接下来我们进行代码的下载和编译.访问官方代码库,点击代码按钮,即可看到三种 clone 代码方式. 推荐使用 ssh 进行代码 clone.

在命令行中切换工作路径(存放代码的路径),输入 git clone https://github.com/ethereum/go-ethereum.git 回车,等待代码检出到本地.效果如下:

下载完成后,执行 make 命令进行代码编译,效果如下图

./build/bin/geth 启动程序

以上,是安装Geth的步骤及编译运行程序的记录.

1. 下载Golang

2. Checkout Geth 源码

3. make

4. ./geth

Further reading …

https://geth.ethereum.org/docs/install-and-build/installing-geth#install-on-macos-via-homebrew

https://ethereum.org/zh/developers/tutorials/run-light-node-geth/

在 Ethereum (以太坊网络)中,存在很多的客户端,其中 Geth 是运行节点数最多的客户端版本.

官方介绍:

Geth is the Golang implementation of the Ethereum protocol. It is fast, open-source software that is actively maintained.

Geth是基于Golang实现的以太坊网络协议.它是运行快速、代码开源(下载地址)的软件,并由以太坊基金会积极维护地

从图中可以看出Geth是以太坊网络协议中,占比最高的客户端,高达90%.

(此外也推荐学习了解基于Rust语言开发的openethereum)

阅读参考

查询地址:

https://etherscan.io/nodetracker

代码下载地址:

https://github.com/ethereum/go-ethereum

官方面向开发者的学习文档:

https://ethereum.org/zh/developers/

问题背景描述

之前的研发平台在后期维护中主要是支持 MySQL 数据库，对 Oracle 兼容性慢慢缺失。近期一个项目使用的是 Oracle 数据库，两位开发小哥就开始针对 Oracle 数据库，做兼容开发有问题修复。

在其中一个服务系统系统管理做兼容改造开始时，系统切换到oracle数据库方言后，系统启动失败。异常信息如下:

[ERROR] 2019-07-18 11:01:17.246 [main] SpringApplication - Application startup failed
org.apache.ibatis.binding.BindingException: Invalid bound statement (not found): dao.IDataTypeDao.selectDataTypeList
    at org.apache.ibatis.binding.MapperMethod$SqlCommand.<init>(MapperMethod.java:225) ~[mybatis-3.4.4.jar:3.4.4]
    at org.apache.ibatis.binding.MapperMethod.<init>(MapperMethod.java:48) ~[mybatis-3.4.4.jar:3.4.4]
    at org.apache.ibatis.binding.MapperProxy.cachedMapperMethod(MapperProxy.java:65) ~[mybatis-3.4.4.jar:3.4.4]
    at org.apache.ibatis.binding.MapperProxy.invoke(MapperProxy.java:58) ~[mybatis-3.4.4.jar:3.4.4]
    at com.sun.proxy.$Proxy161.selectDataTypeList(Unknown Source) ~[?:?]
......
org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:167) ~[spring-context-4.3.9.RELEASE.jar:4.3.9.RELEASE]
    at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:139) ~[spring-context-4.3.9.RELEASE.jar:4.3.9.RELEASE]
    at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:393) ~[spring-context-4.3.9.RELEASE.jar:4.3.9.RELEASE]
    at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:347) ~[spring-context-4.3.9.RELEASE.jar:4.3.9.RELEASE]
    at org.springframework.boot.context.event.EventPublishingRunListener.finished(EventPublishingRunListener.java:101) ~[spring-boot-1.5.4.RELEASE.jar:1.5.4.RELEASE]
    at org.springframework.boot.SpringApplicationRunListeners.callFinishedListener(SpringApplicationRunListeners.java:79) ~[spring-boot-1.5.4.RELEASE.jar:1.5.4.RELEASE]
    at org.springframework.boot.SpringApplicationRunListeners.finished(SpringApplicationRunListeners.java:72) ~[spring-boot-1.5.4.RELEASE.jar:1.5.4.RELEASE]
    at org.springframework.boot.SpringApplication.run(SpringApplication.java:305) ~[spring-boot-1.5.4.RELEASE.jar:1.5.4.RELEASE]
    at sys.SysApplication.main(SysApplication.java:66) ~[classes/:?]

如上错误信息中 org.apache.ibatis.binding.BindingException: Invalid bound statement (not found)，但是在代码中结构如下 :

在 IDEA 中代码导航，是可以找到相应的代码关联关系，难道是因为编译构建出来的 class 文件和 mapper 文件路径出现问题，导致 mapper 文件解析不到出现方法和 mapper中的配置没有关联。

接下来查看相应配置文件读取的 mybatis mapper 文件路径和 build out 文件，如下图：

根据上面逻辑梳理和图片证明，文件配置路径和编译后的环境信息是吻合的，但是项目运行时是没有解析到 mapper 文件。以上，确定了配置没有问题，只能 debug 代码排查原因。

1.正向debug方法查询逻辑，寻找缺失信息

2. 根据正向 debug，发现 Configuration 中并没有 mapperRegistry。反向推断，准备 debug 解析 mapper 文件相关代码，创建 Configuration的代码过程

通过代码搜索，查找到，获取配置文件代码如下图：

3.添加条件断点，当 path 中包含 oracle 中，断点生效

4.如下动图是具体 debug 记录

5.最终获取的 URL 路径如下图，是一个 JDK 自带 jar 包

6. 查看路径 jar 包中文件，其中确实包含了 oracle 文件夹，导致ClassLoader 加载到了这个 jar 对应的路径

为了快速解决项目问题，统一将 mapper 文件路径添加 mybatis 前缀，这样 ClassLoader 搜索最终会使用 APPClassLoader 定位到 class/resource 路径下的 mybatis/oracle/*.xml

以上方式是解决了项目问题，仍然遗留一个问题：在 macOS jdk1.8.0_162 版本下 ExtClassLoader 加载到了 jar 文件路径。

测试：

• 1.7版本下会获取到 resource 路径（原因是因为 sa-jdi.jar 中不包含 oracle 路径）

• 1.9版本下会获取到 resource 路径，但是 sa-jdi.jar 中包含 oracle！（疑惑！！！）

• TODO : 了解相应源码查看原因

1.9 之前JDK自带 ClassLoader 分为三种

• Bootstrap ClassLoader 加载 rt.jar

• ExtClassloader 加载 lib/ext 下的 class

• APPClassLoader 加载 -cp 指定的类

1.9 引入了 module 概念。 ClassLoader 也发生了改变

• Bootstrap ClassLoader

• Platform ClassLoader

• AppClassLoader

[参考资料]  深入探讨 Java 类加载器

请按照HikariCP官方推荐进行配置数据库连接池

dataSource.cachePrepStmts=true
dataSource.prepStmtCacheSize=250
dataSource.prepStmtCacheSqlLimit=2048
dataSource.useServerPrepStmts=true
dataSource.useLocalSessionState=true
dataSource.rewriteBatchedStatements=true
dataSource.cacheResultSetMetadata=true
dataSource.cacheServerConfiguration=true
dataSource.elideSetAutoCommits=true
dataSource.maintainTimeStats=false

背景信息介绍:

公司的项目部门使用我们研发中心的框架进行产品开发,再使用动态数据源进行数据库操作的时候出现两种奇怪的现象:

• 相同的 sql 语句「一种写法是 navicat 格式化后的语句(字符较多), 一种写法是单行压缩的语句(字符较短)」,两种语句在正确执行SQL语句 + java逻辑代码进行处理的时候出现异常 两个条件下,执行结果是不同的.

  • 正确期望 : 出现异常,两种写法语句对应的整个事务回滚,数据库无新增数据.

  • 错误现象 :

    • 长语句事务不回滚,不符合预期

    • 短语句事务回滚,符合预期

• 一个mybatis的语句包含多个insert(比如执行三个 insert into tablename values)操作,如果中途的语句出现表名错误、字段名称不存在等原因导致sql执行失败

  • 正确期望 : 出现异常,整个事务回滚,数据库无新增数据.

  • 错误现象 : 事务是不回滚,数据部分插入成功

最小化测试代码请参考:

https://github.com/HugePages/troubles

代码时序图:

现象复现 :

📍 执行不同长度的 sql 语句,当 sql 长度小于2048,事务正常回滚

发起请求 http://127.0.0.1:8080/demo/insert-rollback?type=1&exception=1

http://127.0.0.1:8080/demo/insert-rollback?type=1&exception=1

查看 Wireshark 对应 mysql 协议的监控如图:

此时,代码执行符合预期 : 出现异常, spring 的事务管理正常,执行 rollback 操作,数据库没有新数据插入:

📍 执行不同长度的 sql 语句,当 sql 太长,导致事务不回滚

发起请求 http://127.0.0.1:8080/demo/insert-rollback?type=0&exception=1

查看Wireshark 对应 mysql 协议的监控如图:

通过 debug,事务也是交由 spring 进行管理,也执行了 rollback 操作,但是最终数据还是插入到数据库中:

结合上述的现象,只能怀疑是因为数据库sql长度导致,排查hikari的配置项,修改

spring.datasource.hikari.data-source-properties.useServerPrepStmts=true
spring.datasource.hikari.data-source-properties.prepStmtCacheSize=250
spring.datasource.hikari.data-source-properties.prepStmtCacheSqlLimit=200

修改为 prepStmtCacheSqlLimit=2048,再次重复之前的测试,均进行正常回滚.

原因分析

追踪代码发现 rollback 之前, Statement 已经 close.

因为 serverPrepareStatement 进行缓存,但是超过了 sqllimit 的大小, 就调用了realclose方法,进行 statement 的释放

关键步骤: 发送了 Close() 方法,收到响应,设置 transcationInserver 的 statusFlag 为0

⚠️ 注意,如果执行的 sql 语句存在异常,这个值会在最后抛异常的时候,获取当前事务在服务端状态

最后判断是否执行 rollback 的时候, 直接 return //no-op,不发送 rollback 指令给 mysql server

补充代码执行大致流程 @2022-0117

参考资料如下:

transactions-are-not-getting-rollbacked-with-hikaricp

https://stackoverflow.com/questions/50234214/transactions-are-not-getting-rollbacked-with-hikaricp

HikariCP 的 MySQL-Configuration

https://github.com/brettwooldridge/HikariCP/wiki/MySQL-Configuration

官方 bug 介绍 ( 网页内搜索 「Bug #20212882, Bug #75209」)

https://dev.mysql.com/doc/relnotes/connector-j/5.1/en/news-5-1-40.html

官方文档 (5.3.5 Performance Extensions)

https://dev.mysql.com/doc/connector-j/5.1/en/connector-j-connp-props-performance-extensions.html

sql 监控组件 p6spy

https://github.com/p6spy/p6spy

Connection 和 Transaction

https://docstore.mik.ua/orelly/weblinux2/mysql/ch08_02.htm

扩展阅读:

Mysql Connector/J 源码分析（普通 Connection）

如果 MySQL 事务中发生了网络异常？

总结:

公司的开发框架已经发布4年了, 使用次框架开发的产品、项目近百个从来没有遇到过此类问题.

平时的产品项目都会遵守一些分层、数据库使用规范,所以基本很难触发此问题.这次也是项目的开发在设计分层、接口功能拆分、SQL使用等方案不规范导致,没有严格遵守设计原则和开发规范.

此外,框架研发团队在使用开源组件的时候,尽量减少默认参数配置,把参数配置的能力暴露给框架的使用者,特别是所开发的功能作为团队中最基础的公用服务.