JPA 的 id 生成策略
JPA 有一个@GeneratedValue注解,有一个strategy attribute,如 @GeneratedValue(strategy = GenerationType.IDENTITY)。 常见的可选策略主要有IDENTITY和SEQUENCE。 GenerationType.IDENTITY 要求底层有一个 integer 或者 bigint 类型的自增列( auto-incremented column)。自增列的赋值必须在插入操作之后发生,因为这个原因,Hibernate 无法进行各种优化(特别是 JDBC 的 batch 处理,一次 flush 操作会产生很多条insert 语句,分别执行)。如果事务回滚,自增列的值就会被丢弃。数据库在这个自增操作上有个高度优化的轻量级锁机制,性能非常棒。 MySQL 支持这种 id 生成策略, 使用 MySQL 应该尽量使用这个策略,即使它无法优化。 JPA 用它生成 id,会一条一条地插入新的 entity。 GenerationType.SEQUENCE 数据库有一个所谓的 sequence 对象,可以通过 selec...
Convention over Configuration over Programming
什么是 Convention over Configuration over Programming 在软件工程中,有一条重要的设计哲学层级: Convention over Configuration over Programming 约定优于配置,配置优于编程。 这条原则的核心思想是:能用约定解决的问题,就不要引入配置;能用配置解决的问题,就不要写代码。 它反映了软件设计中对复杂度管理的追求——越是高层次的抽象,使用成本越低,出错概率也越小。 三个层次的含义 Programming(编程) 编程是最灵活但成本最高的方式。开发者需要编写具体的代码逻辑来实现功能。每一行代码都是潜在的 bug 来源,都需要测试、维护和 review。编程适合处理那些真正需要定制化逻辑的场景。 Configuration(配置) 配置是介于约定和编程之间的中间层。通过外部化的配置文件(如 XML、YAML、properties 等),开发者可以在不修改代码的情况下改变程序行为。配置降低了修改成本,但引入了配置管理的复杂度——配置项越多,理解和维护系统的难度就越大。 Convention(约定) ...
重拾TCP/IP协议簇
TCP/IP 协议簇是互联网的基石,是每个工程师都应该掌握的知识。这篇文章将系统地回顾 TCP/IP 协议簇的核心内容。 OSI 模型与 TCP/IP 模型 OSI 模型将网络通信分为七层,而 TCP/IP 模型则将其简化为四层。虽然 OSI 模型是理论标准,但实际应用中 TCP/IP 模型更为广泛。 OSI 七层模型与 TCP/IP 四层模型对应关系 OSI 模型从上到下依次为: 应用层(Application Layer) 表示层(Presentation Layer) 会话层(Session Layer) 传输层(Transport Layer) 网络层(Network Layer) 数据链路层(Data Link Layer) 物理层(Physical Layer) TCP/IP 模型对应的四层为: 应用层(Application Layer) 传输层(Transport Layer) 网际层(Internet Layer) 网络接口层(Network Interface Layer) 各层功能说明 OSI 层级 TCP/IP 层级 主要功能 典型协议 ...
Hyperledger Fabric 完整知识图谱(2017-2018 旧文整合)
本文整合了 2017 年 10 月到 2018 年 4 月间一系列 Hyperledger Fabric 学习笔记,包括网络启动、配置文件、MSP 与身份治理、容器内部结构、链码示例、Cello 与 Composer 周边工具、以及文档拾遗。内容覆盖 Fabric v1.0 ~ v1.1 时代的实践,时间戳与"截至日前(2017.10.27)"这类标注一并保留,便于追溯具体版本背景。 一、概述 Hyperledger Fabric 可以说是 Hyperledger 的拳头项目。虽然同为 Apache 的顶级项目,但大部分其他 Hyperledger 项目都以 Fabric 为基础。它是顶级项目中的顶级项目,可以认为是 0 级项目。 Fabric 的核心组件构成一个联盟链网络: peer:保存账本(ledger)、运行链码(chaincode),分背书节点(endorser)、提交节点(commiter)、锚节点(anchor)、leader 节点等角色 orderer:负责对事务排序、打包成区块。orderer 可被视作跨 channel 的 channel...
一个滚动重启的状态保存问题
很多时候滚动重启,都会导致状态丢失。比较好的设计方法是把服务本身设计成无状态的,然后在上游的服务上做好 failover,然后增加 standby server,让 sticky 数据 transmit 到 standby 机器上,让 request 失败以后可以自己由上游重传到 standby server。然后就可以滚动重启了。 这大部分场景下还要考虑幂等的问题。 这就看得出热配置热替换的重要性了。在大多数情况下,除了发布新的 feature 升级以外,都应该尽量用热配置来避免重启。
重读 Martin Fowler 的微服务论文原文
背景 Martin Fowler 和 James Lewis 于 2014 年发表的 “Microservices: a definition of this new architectural term” 是微服务架构领域最具影响力的文章之一。这篇文章并非提出微服务的概念(Netflix、Amazon 等公司早已在实践),而是对这一架构风格进行了系统性的定义和特征总结。 文章的核心论点是:微服务架构是一种将应用程序构建为 一组小型服务 的方法,每个服务运行在自己的进程中,通过轻量级机制(通常是 HTTP RESTful API)进行通信。 微服务也是面向服务的(Service-Oriented),但与传统 SOA 有本质区别。传统 SOA 倾向于将集成复杂度集中在 ESB(Enterprise Service Bus)中,试图用一个庞然大物来隐藏分布式系统的复杂性;而微服务则主张将智能放在端点(endpoint),保持通信管道的简单。 以下是对原文九个核心特征的重读和展开。 组件化(Componentization)与服务(Services) Fowler 在文中区分了两种组件...
X.509证书问题
X.509证书里有一段属性主题,大概是这样: 12 C=US, ST=Maryland, L=Pasadena, O=Brent Baccala, OU=FreeSoft,CN=www.freesoft.org/emailAddress=baccala@freesoft.org 这些 attribute 的含义是: country (countryName, C), organization (organizationName, O), organizational unit (organizationalUnitName, OU), distinguished name qualifier (dnQualifier), state or province name (stateOrProvinceName, ST), common name (commonName, CN) and serial number (serialNumber). locality (locality, L), title (title), surname (surName, SN), given...
精通比特币读书笔记
第一章 介绍 传统货币的防止双花,必须在一个中心化(centralized)的清算所(clearing house)里清算。比特币则用全局选举的机制达到共识,来清算双花问题。本质上来讲,就是把一个固定的中心化的清算过程,用选举的方式转化为无数个去中心化的局部清算过程。这就弥补了在比特币之前出现的数字货币的缺点。 clearing 在比特币网络里就被称作 mining 。 钱包是保存地址和管理密钥的地方。不要害怕公开自己的钱包地址。 全节点可以获取全部的交易信息,也因此可以验证交易,发出交易。硬件钱包是运转在专有硬件上的节点(树莓派?),冷钱包就是纸一类的东西。离线钱包是非常安全的。 第二章 比特币原理 比特币最多可以分割到一亿分之一的大小。 Transaction就像是复式记账法账簿上的行,即每行都有输入和输出。 简单来说,每一笔交易包含一个或多个“输入”,输入是针对一个比特币账号的提款(而不是债务)。 这笔交易的另一面,有一个或多个“输出”,被当成信用点数记入到比特币账户中。这些输入和输出的总额(负债和信用)不需要相等。相反,当输出累加略少于输入量时,两者的差额就代表了一笔隐含...
重放攻击问题
比特币靠不同的地址前缀可以规避重放攻击问题。 以太坊可以靠 EIP155 钱包来规避重放攻击问题。 何为重放攻击问题? 一个区块链有若干个测试网络。如果一套公私钥可以在不同的网络上通用,则可以恶意地把在测试网络中出现的 transaction 播放到主网上。如果在测试网络上有人从账户 A 转了一笔钱到账户 B,而账户 B 是一个傻瓜测试账户,私钥是由类似123456之类的种子生成的话。那么只要账户 A 在主网中的余额大于这笔钱,心怀恶意者就能把主网中 A 的钱财转走,从主网中的账户 B 里把钱取出来。即使心怀恶意者没有 B 的取款方法,也能让账户 A 蒙受资金损失。 所以不要跨网使用相同的公私钥对。
UTXO 与 account balance 模型
UTXO 简介 UTXO 的全称的 unspent transaction output,就是没有被人用过的可用资金。 这个模型是比特币首创的,被其他货币所模仿。以太坊天然的模型不是 UTXO 而是 account balance。 UTXO 必须配平,UTXO 的输入者必须上一个 UTXO 的输出者: 这就把一个一个账户型数据库,转成了链式的交易数据库,交易要靠 merge 整个数据库的相关节点。 UTXO 的好处是: 更加好的隐私模型 更加强的并发范型(因为不会触发间隙锁了吗?) ZCash 的 UTXO ZCash 也一样有 UTXO,但它的 UTXO 是加密过的,而且每个矿工那里还有一个专门的 UTXO 作废数据库。具体情况见《不是程序员也能看懂的ZCash零知识证明》。 ##以太坊中的 account 模型## 以太坊没有使用 UTXO 模型,而使用 account balance 模型,他们把 account balance 模型称为 world state。account balance 模型比 UTXO 模型更加容易实现智能合约,...
