再谈 MySQL InnoDB 可重复读级别下的锁

InnoDB 是 MySQL 默认的数据库存储引擎, 由于其良好的性能和对事务的支持, InnoDB 也是大多数业务场景下开发者的首选. 可重复读(Repeatable Read)作为 InnoDB 默认的事务隔离级别, InnoDB 研发团队对其进行了大量的设计和优化. 当理解了 InnoDB 在可重复读级别下的事务隔离机制后, 再理解数据库在其他隔离级别下的表现也就容易多了. 作为开发者, 只有当理解了这些设计背后的思想, 才不会在遇到问题时手忙脚乱. InnoDB RR 隔离级别的实现原理 事务的隔离级别是当存在多个事务同时操作相同数据时, 对事务之间相互影响的要求标准. 可重复读的事务隔离级别要求: 在事务A开启事务之后, 事务B对数据的修改就不再对A可见了. InnoDB 采用了多版本并发控制(Multi-Version Concurrency Control)和两段锁协议(2-Phase-Lock)相结合的技术方案实现了 可重复读 的并发事务管理. 在可重复读的隔离级别下, InnoDB 会在每个事务提交时记录下当前事务的版本号, 并将此变更的记录与变更数据的历史版本相关联. 某事务对数据进行查询时只能查到数据版本 <= 当前事务版本的数据状态. 在事务执行期间, 当事务 A…

深入理解比特币(四) 区块和网络

本文是 深入理解比特币系列 中的第四篇 区块和网络. 本篇文章主要包含以下内容: 网络中的节点 交易的广播与确认 区块链和挖矿 简易支付验证(SPV) 网络中的节点 比特币网络是一个由多个比特币节点共同组成的 P2P 网络. 在 P2P 网络中不存在中心化的服务端, 每个节点使用服务的同时也对网络中的其他节点提供服务. 比特币节点由以下几个功能模块组成: 路由, 区块链数据库, 挖矿, 钱包服务. 一个比特币节点根据目的不同, 可能包含这些功能模块中的一部分或者全部. 例如, 一些节点保存了完整的区块链数据, 这样的节点就可以被称为 全节点. 全节点能够独立地校验任何交易的有效性, 而不需外部服务的帮助. 而另一些节点只保存了区块链的一部分数据(区块头), 它们通过一种名为 简易支付验证(SPV)的方式来完成交易验证, 这样的节点被称为 SPV节点 或 轻节点. 当有新节点加入比特币网络后, 它必须和网络中的其他节点建立连接, 并根据需要从连接到的节点同步区块数据. 目前, 运行一个比特币全节点需要保存的区块链数据已经超过了 260G. 正是因为运行全节点所要保存的数据量太大了, 一般人很难在个人设备上维护一个全节点, 所以就有了轻节点(…

深入理解比特币(三) 交易

本文是深入理解比特币系列中的第三篇, 交易. 交易是比特币系统中的核心部分, 所谓交易是指资产从一个所有者转移到另一个所有者的过程.本篇文章主要包含以下内容: 熟悉比特币交易的数据结构 理解比特币钱包余额和 UTXO 模型 了解比特币编程语言 学习利用 P2SH(Pay-to-Script Hash) 构造复杂交易 数据结构 一笔比特币交易由如下几个组成部分: Version Inputs Outputs Locktime Version(版本号) 和大多数版本号的作用一样, 比特币交易的版本号是为了标识处理该笔交易所需要的支持的特性. 比特币系统也是一个持续迭代的软件, 有时我们需要为交易设置不同的版本号以便交易中的新特性能被更好地支持. 目前比特币系统中大多数交易的版本号为 2. 版本号位于序列化交易数据最开始的位置, 占 4 个字节. Inputs(输入) 和 Outputs(输出) 在比特币的设计里, 比特币钱包(私钥)所拥有的余额不是以一个单独数字的形式存在的. 比特币世界中的余额与现实世界中现金的模式类似, 在一次交易中: 每一个输入就像是我们此前从别人那里收到的钱 每一个输出就像是我们这次要交给其他人的钱 每笔交易可以包含多笔输入(一次使用之前收到多张现金)和多笔输出(一次交给其他人多张现金)…

深入理解比特币(二) 钱包和地址

本文是深入理解比特币系列中的第二篇, 钱包和地址. 钱包是比特币世界里最重要的概念之一, 这里要说的钱包并不是指具体的某种软件或硬件产品, 而是其更本质的定义: 私钥即钱包. 比特币之所以被被称作加密货币是因为它的实现是建立在椭圆曲线密码学的基础之上的. 在比特币的世界里, 资产以一种被称作 UTXO (unspent transaction outputs) 的数据形式存在. 比特币 UTXO 对网络里的所有用户都是可见的, 谁能够提供一个凭证(在密码学中这样的凭证一般被称为"见证" Witness)使 UTXO 中预先设定花费条件成立, 谁就拥有了这笔资产的所有权. 而私钥正是能提供这个凭证的关键所在. 掌握了某个私钥也就意味拥有了与该私钥对应的所有资产. 关于椭圆曲线密码学的知识可以参考我翻译的 椭圆曲线密码学: 入门 系列文章, 文章的原作者是来自爱尔兰亚马逊的软件工程师, 这几篇文章也是我读过的关于介绍椭圆曲线密码学最好的入门文章, 有兴趣的朋友可以前往阅读, 相信也会让你受益匪浅. 私钥,公钥和地址 在椭圆曲线密码学中, 私钥 e 是一个随机数, 而对应的公钥是私钥和椭圆曲线上的特定生成点 G 相乘得到的另一个点 P. 即: $$ P = eG…

深入理解比特币(一) 简史

第一次听说比特币还是在 2012 年, 那年我读大三, 距离中本聪发表《比特币: 对等网络电子现金系统》论文仅有 3 年多的时间. 那时的我不会想到, 在几年之后我自己会进入到加密货币这个行业, 从而使我有机会能够更加深入地思考比特币到底是什么. 本系列文章由以下四篇构成: 深入理解比特币(一) 简史 深入理解比特币(二) 钱包和地址 深入理解比特币(三) 交易 深入理解比特币(四) 区块和网络 这些内容里包含了我对比特币的理解与思考. 当然, 作为一个技术人, 更多的内容还是关于对比特币技术细节的解读. 希望读者在读完本系列文章后, 能透过技术对比特币甚至是整个加密货币行业有更多的感悟. 货币 要了解什么是比特币, 我们必须先思考什么是货币? 人类使用货币的历史产生于物物交换的时代. 在原始社会, 人们使用以物易物的方式交换自己所需要的物资, 比如一头羊换一把石斧. 以物易物模式最大的问题在于要达成交易必须满足双重偶然性, 即"我想要的东西刚好你有, 而你想要的东西刚好我有", 如此严苛的条件使交易极难达成. 经过长年的自然淘汰, 在绝大多数社会里, 作为货币使用的物品逐渐被金属所取代. 使用金属货币的好处是它的制造需要人工,…

[译] 椭圆曲线密码学: 安全强度及对比RSA

本文翻译自爱尔兰AWS工程师 ANDREA CORBELLINI 关于椭圆曲线密码学四篇博客中的最后一篇, 原文采用 CC-BY 4.0 协议 进行授权 原文链接 : https://andrea.corbellini.name/2015/06/08/elliptic-curve-cryptography-breaking-security-and-a-comparison-with-rsa/ 原作者: ANDREA CORBELLINI 译者: chxj1992 本文是 ECC:入门 系列文章的第四篇也是最后一篇. 在上一篇文章中我们学习了两种算法: ECDH 和 ECDSA, 并且了解到了椭圆曲线上的离散对数难题在保证算法安全性上扮演的重要角色. 但是如果你还没忘的话, 我们并没有对离散对数难题的复杂性在数学上的证明: 我们相信它是"困难的", 但是我们还不能肯定. 在本文的第一个部分中, 我们将试着去了解在今天的技术条件下要解决它到底有多"难". 然后在第二个部分里, 我们将尝试解答以下问题: 既然已经有了 RSA 为什么我们需要椭圆曲线加密.…

[译] 椭圆曲线密码学: ECDH 和 ECDSA

本文翻译自爱尔兰AWS工程师 ANDREA CORBELLINI 关于椭圆曲线密码学四篇博客中的第三篇, 原文采用 CC-BY 4.0 协议 进行授权 原文链接 : https://andrea.corbellini.name/2015/05/30/elliptic-curve-cryptography-ecdh-and-ecdsa/ 原作者: ANDREA CORBELLINI 译者: chxj1992 这篇文章是 ECC:入门 系列文章的第三篇. 在之前的文章中, 我们了解了什么是椭圆曲线以及定义了群律以便对椭圆曲线上的点进行一些数学计算.然后我们将椭圆曲线限定在了以一个质数为模的整数有限域上. 在此限制下, 我们看到了椭圆曲线上的点可以生成出循环子群并且我们还介绍了 基点, 阶 和 余子式 的概念. 最后我们知道, 有限域上的标量乘法计算是一个"容易"的问题, 而离散对数问题却是非常"困难"的. 现在我们将会看到以上这些东西将如何融入密码学中.…

[译] 椭圆曲线密码学: 有限域和离散对数

本文翻译自爱尔兰AWS工程师 ANDREA CORBELLINI 关于椭圆曲线密码学四篇博客中的第二篇, 原文采用 CC-BY 4.0 协议 进行授权 原文链接 : https://andrea.corbellini.name/2015/05/23/elliptic-curve-cryptography-finite-fields-and-discrete-logarithms/ 原作者: ANDREA CORBELLINI 译者: chxj1992 这篇文章是椭圆曲线密码学:入门系列文章的第二篇. 在前一篇文章中, 我们知道了如何在实数域上的椭圆曲线上定义一个群. 具体来说, 我们定义了点加的规则: 找到位于一条直线上的三个点, 三点之和为零($P + Q + R = 0$). 我们推导了求解点加的几何方法与代数方法. 我们还介绍了标量乘法($nP = P + P + \cdots + P$) 并且我们找到了一种用于计算标量乘法的"简单"算法: 倍加法. 现在我们将要把椭圆曲线限制在有限域而非所有实数的集合上,…

[译] 椭圆曲线密码学: 入门

本文翻译自爱尔兰AWS工程师 ANDREA CORBELLINI 关于椭圆曲线密码学四篇博客中的第一篇, 原文采用 CC-BY 4.0 协议 进行授权 原文链接 : https://andrea.corbellini.name/2015/05/17/elliptic-curve-cryptography-a-gentle-introduction/ 原作者: ANDREA CORBELLINI 译者: chxj1992 如果你们知道什么是椭圆曲线密码学, 那你们应该也听说过 ECC, ECD或者ECDSA. ECC是椭圆曲线密码学(Elliptic Curve Cryptography)的首字母缩写, 而另外两个都是基于ECC实现的算法. 如今, 我们在 TLS, PGP 和 SSH 里都能找到椭圆曲线密码学的身影, 这三种技术可以说是现代互联网和数字世界的基础, 更别提ECC在比特币和其他各种加密货币中发挥的巨大作用了. 在ECC开始流行以前, 绝大多数公钥加密算法都基于 RSA, DSA 和 DH 实现.…

FastJSON IntegerSerializer 潜在DOS攻击风险问题

背景 近日, 慢雾安全平台的白帽子给公司项目提交了一个安全漏洞: 向某个参数类型为Integer的POST接口提交如 1.00...00 (小数点后约100万个0), 服务端程序处理该请求消耗了约90秒的时间, 耗费了大量的计算资源, 对于服务端程序来说, 这是不可接受的, 攻击者可以利用该漏洞对服务器发起DOS攻击 分析 根据白帽子提供的细心我在测试环境对该问题进行了复现并通过JProfiler分析了请求链路, 结果如下 : 可见, 绝大部分的计算资源用在了将数据解析为BigDecimal. 可是为什么参数类型明明是Integer却被解析成了BigDecimal ? 我结合FastJSON源码做了进一步的分析, 发现FastJSON在解析Integer过程中会先判断数据的格式, 如果数据格式是小数, FastJSON会先将数据解析为BigDecimal , 再通过类型转换把BigDecimal转成Integer, 而正是这样的设计导致了这次的问题. 对比同类库Jackson和GSON, 在将相同数据转换成Integer时并没有以上问题. 我认为这可能是FastJSON在设计时考虑不周的一个点 解决方案 a. 在运维层面, 根据接口实际需要对请求参数大小进行限制, 除数据上传等提交数据较大的接口之外外, 将入参数据大小限制在 10K 内 b. 编写自定义Integer解析器替代默认的Integer解析器, 在将格式为小数的数据解析为Integer时, 用Double替代BigDecimal以规避潜在的安全(DOS)风险, 相关代码如下 c. 在涉及到解析用户提交的数据时, 谨慎使用BigDecimal类型, 当确实需要准确精度保证时, 可以考虑先将小数数据转换为String类型, 在校验数据长度后再将数据转为BigDecimal 这次的问题也给我带来了一些的思考:…