高新技术

"上一篇" 介绍了MetaMask钱包的安装和使用，并成功获取到部分测试以太币(ETH)并向另外一个账户发起了一笔转账，这笔转账称之为"交易"，我们将在本篇来介绍它。 1. 以太坊的账户 首先，在学习交易之前，我们需要了解以太坊的账户体系。 以太坊的账户分为两种：外部账户和合约账户。 外部账户：外部账户一般由钱包创建，具有私钥，通过私钥控制和区块链网络和智能合约的访问； 合约账户：以太坊中智能合约部署后对应着一个合约账户，合约账户拥有智能合约代码，并受其逻辑控制。 简单而言，外部账户就是区块链的用户通过钱包创建的账户，而合约账户由合约代码编写者所有，对应着一个智能合约，由 EVM 执行。 合约账户和外部账户地址没有明显的区别，都是长度 20字节、160 位、转为十六进制(0x开头)后为 40 个字符的一个串，形如 0x829BD824B016326A401D083B33D092293333A830 两者的区别： 启动交易者（首先发起交易的一方）必须是拥有私钥的外部账户，也就是说只有用户可以启动交易；但是智能合约可以通过调用别的智能合约来对交易做出响应，比如，用户A通过智能合约A发起了一笔交易，虽然智能合约A调用智能合约B也可以发起了一笔交易，但是这整个过程中交易的启动者还是用户A的外部账户 外部账户和合约账户都可以发送和接收区块链货币（如以太币），但是交易目标如果是合约账户，则会使得合约账户拥有的智能合约代码在 EVM 中执行，外部账户则不会 合约账户没有私钥，智能合约编写者通过代码逻辑来保证安全性，外部账户拥有私钥，用户需要通过妥善的保管私钥来保证账户的安全性 2. 以太币单位 交易与货币息息相关，以太坊发行的货币为以太币(Ether, ETH，符号 Ξ)，其基本单位为 wei，ETH与wei的关系如下： 1 ETH = 10^18 wei 此外，还有比较常用的 gwei （gigawei）： 1 ETH = 10^9 gwei 1 gwei = 10^9 wei Table 1. 以太币的面额和单位 值(以wei为单位) 指数 通用名称 标准名称 1 1 wei wei 1,000 103 babbage kilowei or femtoether 1,000,000 106 lovelace megawei or picoether 1,000,000,000 109 shannon gigawei or nanoether 1,000,000,000,000 1012 szabo microether or micro 1,000,000,000,000,000 1015 finney milliether or milli 1,000,000,000,000,000,000 1018 ether ether 1,000,000,000,000,000,000,000 1021 grand kiloether 1,000,000,000,000,000,000,000,000 1024 megaether ...

区块链中，与用户直接相关的一个重要组件是钱包。用户通过钱包来访问链上的资金、查看账户地址、转账交易等操作。可以说，没有钱包，用户就不能正常访问链上资金，可见其重要程度。而诸多钱包中，MetaMask是一款可以直接在浏览器中使用的、实现了钱包标准 BIP-39 的钱包，也是大多数使用者选择的入门级钱包。 1. 区块链钱包简介 与普通的实物钱包不同，区块链钱包的核心目的是用来保存用户的公钥和私钥，从而保证访问区块链中账户资金的权限，即：证明钱是你的，而不是存储资金。 Figure 1. 区块链钱包(图片来源网络) 钱包的一个重要的误区是：钱包存储资金。其实，钱包并不会直接存储区块链上的资金。可以将其看做一个银行账户，当你需要取钱时，只需告诉银行要取多少钱，然后银行就可以检查账户的余额是否充足并进行取款，账户只是一个逻辑划分，钱始终是存在银行。同理，区块链钱包也只是在区块链上开了一个账户，钱始终在区块链网络中。 开通银行账户，我们必须设置交易密码，已验证你有访问账户的权限；同样的，区块链钱包中，私钥就相当于账户密码，每产生一笔交易时，都需要通过钱包的私钥来进行签名，已验证你拥有操作账户资金的权限。 但是，与银行账户不同，银行是中心化的资金机构，除了验证账户密码，还有其他手段比如身份证来验证取款人身份，忘记密码还可以重置。但在区去中心化的区块链中，私钥是你唯一的凭证，一旦私钥泄露，那么任何人都可以访问你的账户。 因此，钱包可以看成是一个私钥圈，保存了多组公钥私钥对。现在的钱包大多采用随机串生成助记词，再加密生成种子密钥，最后再以种子密钥为根生成密钥树的方式来生成密钥。这里仅说明钱包的概念，关于钱包的底层原理，后续在详细讨论。 Figure 2. 钱包中的密钥树(图片来源网络) 2. 什么是MetaMask MetaMask 是一款简单易用的区块链钱包，除了 App 版本的钱包，它还提供了基于浏览器的插件，包括 Chrome、Firefox等，而且它内置了 Web3，可以直接与以太坊区块链交互并开发 DApp 网页应用，这也是大多开发者选择它的原因。 3. 安装MetaMask 安装 MetaMask 很简单，以 Chrome 为例，直接从 Google 商店安装即可，前提是需要自带梯子。步骤如下： 1、进入google应用商店，直达地址在 这里，也可以自己搜索MetaMask，第一个小狐狸头像的就是 2、点击 "添加至Chrome"，然后弹出框点击"添加至扩展"即可，然后会下载 Chrome 插件，耐心等待 3、下载完成后，Chrome会自动安装，完成后会进入扩展插件地址 点击开始使用，进入钱包创建页面 4、创建钱包 如果您以前有钱包，并记得助记词，那么可以直接通过助记词导入钱包，没有则点击"创建钱包"按钮新建，下一步点击"我同意"，进入密码设置页面： 设置并牢记自己的密码，以后登录钱包是需要用到，然后点击"创建"按钮后，会出现一个介绍的视频页面，直接点击"下一步" 5、备份助记词 这一步很重要，助记词作为恢复秘钥的唯一手段，需要十分安全地做备份，一般建议手抄写在纸上并保存，其他电子存储方式均存在泄漏风险 什么是助记词？ 按照密钥生成策略分，钱包分为两类：非确定性钱包和确定性钱包，前者的每一个私有都是由不同的随机数生成的，私钥间没有任何关联，备份和恢复非常麻烦；而确定性钱包则是通过一个随机串作为种子密钥来生成各种私钥，只要备份种子密钥就可以恢复出所有的私钥。 但是，由于种子密钥长度长而且毫无规律，非常难以记录和输入，因此人们为这个种子密钥按照一定的算法来为其匹配单词表中的一组顺序固定、数量固定(与种子密钥长度有关)的单词，这样便于备份和恢复，这有点类似密码本，这些单词就成为助记词（mnemonic）。 因此，助记词可以看做种子密钥的别名，其安全性与之等同，必须安全保存。 ...

上一篇 简单介绍了什么是区块链，也介绍了以太坊的产生和基本概念，其中提到： 以太坊 是一个去中心化的、开源的、图灵完备的、有智能合约功能的区块链开放平台。作为开放平台和”世界超级计算机”，以太坊以智能合约为核心为去中心化应用(DApp)建设提供了整套解决方案。这一篇我们将详细介绍什么是以太坊。 1. 为什么要学习以太坊 以太坊是目前最大的区块链开发平台，也是“世界计算机”。以太坊是区块链开发工作的必经之路，原因如下： 以太坊是目前最大的区块链开发平台，拥有庞大的用户群和社区 以太坊发展早，技术相对成熟，资料、文档众多 以太坊生态体系完备，除了智能合约、DApp、DAO、DeFi，还提供了 ENS、Swarm等DApp构建所需技术体系 以太坊减缓了区块链陡峭的学习曲线，以应用入手，使得区块链的开发上手快速、简单 以太坊与 JavaScript 结合紧密，开发者学习难度小 总之，以太坊好比微信开放平台，DApp开发好比基于微信公众号、小程序的开发，我们不用太关注底层的东西，而是使用以太坊和微信已经提供好的功能来开发自己的DApp和微信公众号，只是以太坊是基于去中心化的区块链，而微信则是中心化应用。 2. 以太坊的诞生 上一篇 介绍了什么是区块链，其中提到， Vitalik Buterin (V神)在2013年发表了《以太坊：一个下一代智能合约和去中心化应用平台》，提出了以太坊的基本构想。 V神是比特币的狂热粉丝，他不断思考着如何扩展比特币和其智能合约协议 Mastercoin，并提出了一种可替代 Mastercoin 的专用合约语言的更灵活和脚本的智能合约机制，这只是一个他的初步构想，尽管比特币团队非常感兴趣，但是这种想法过于超前，而且与比特币的开发计划存在冲突，所以并没有得到支持。 V神 2013年12月，V神发表了 以太坊白皮书，勾勒出以太坊背后的思想：一个图灵完备的通用目的的区块链。以太坊白皮书发布后，不断有区块链爱好者向V神提交并反馈自己的想法，帮助其不断完善这个想法。其中，Gavin Wood（Mastering Ethereum的作者之一）在C++语言上对以太坊给与了极大地帮助，后来成为了以太坊的联合创始人和CTO，并编写了 以太坊黄皮书。 Gavin Wood 白皮书与黄皮书 白皮书由V神编写，旨在提出改进比特币背后区块链技术的一种构想，使其成为一种通用的、适用于多个方面而不仅仅是虚拟货币的区块链技术，这仅仅是一种理论，在以太坊的成长过程中得以逐步实现； 黄皮书是由以太坊CTO Gavin Wood 博士编写，旨在定义以太坊的技术规范，详细描述了以太坊背后的技术实现细节，其中包含了大量的数学公式，比如，黄皮书定义了产生每一笔交易包含的通用字段、如何验证交易，以太坊虚拟机规范（EVM）等等。黄皮书着重于以太坊技术规范的制定，包含大量数学公式，专业性很强，比较难懂，这里[1]有一个面向普通大众的浅黄版本。 Figure 1. 白皮书 vs 黄皮书 V神与Gavin Wood一起，不断完善以太坊的协议层和技术体系，逐步实现“可编程的、安全的、通用的区块链”这一目标。2015年7月30日，第一个以太坊区块被成功挖出，以太坊作为“世界计算机”正式运行并对外提供服务。 3. 以太坊发展的四大阶段 以太坊的发展并不是一帆风顺的，以太坊的发展整体上分为四个阶段 [2]，代号分别为：Frontier（边疆）、Homestead（家园）、Metropolis（都会） 和 Serenity（宁静），每一个阶段都以"硬分叉"的方式发布，因此新版本不能与老版本兼容。并且，每一个阶段都在不断完善其新功能和安全性，比如2016年以太坊遭受DAO攻击，而分叉了 "以太坊经典" 和 "以太坊" 这样的相互竞争、并行的以太坊版本。 阶段和硬分叉按照区块高度编号并标注日期，包括： Frontier: 区块高度为0，以太坊的初始阶段，持续时间为2015年7月30日至2016年3月。 Ice Age: 冰河期，区块高度为 200,000，引入指数难度增加的硬分叉，以便在准备就绪时将激励机制过度到Pos（权益证明）。 Homestead：家园，区块高度 1,150,000, 以太坊的第二阶段，发布于2016年3月。 DAO: 区块高度 1192000，以太坊遭受严重的攻击而不得不硬分叉，从而产生了 以太坊经典(Ethereum Classic, ETC) 和 以太坊(ETH) 两个相互竞争的系统 [3]。 Tangerine Whistle：橘子口哨，区块高度 2,463,000，改变某些IO密集操作的燃气计算方法和清除拒绝服务攻击（利用这些操作的低燃气成本）累积状态的硬分叉。 Spurious Dragon：伪龙，区块高度 2,675,000，2016 年 11 月 22 日发生的另一次计划外的硬分叉，包括四项提案，用以解决一些攻击问题： EIP 155: 简单重放攻击保护 EIP 160: 提升EXP操作码的费用 EIP 161: 状态树清理 (不变量保持替代) EIP 170: 调整智能合约的最大字节数限制 ...

区块链是这几年非常火热的一个话题，越来越多的人加入到”区块“大军之中。他们其中一些人，积极投入到挖矿、炒币行列之中，甚至发行自己的数字货币来创收，这部分人社称之为”币圈“；另一部分人，深入探究区块链底层技术，期望不断改进并将区块链技术运用到更多领域中，这部分人社称之为”链圈“。越来越多的人积极群涌入区块链，游弋于“币圈"和"链圈"之间，忙的不亦乐乎。 本文将简单介绍区块链的一些入门知识，并介绍区块链开发所需要具备的基础知识，希望对准备进入区块链的开发者们会有一些帮助。 1. 什么是区块链 区块链（Blockchain）源于 比特币，它其实是对比特币的底层技术的一种扩展和创新。2008年，一位网名“中本聪”的日本大佬发布了一篇名为 《比特币：一种点对点的电子现金系统 的论文（比特币 白皮书），文中总结了之前的数字货币发明，提出了一种完全去中心化的数字货币系统，即比特币。文中并没有提及“区块链”一词，而是使用了“区块”（Block）和“链”（Chain）来描述比特币底层技术，后来人们将区块、链合并在一起，正式提出“区块链”（Blockchian）这一概念。 区块链是一系列技术的组合，包括P2P动态组网、密码学、基于密码学的共享账本、共识机制、智能合约等。简单而言，区块链可以看做一个全球互联的超级账本，链中的每一台计算机通过P2P组网连接并保留了账本的副本，这样，链中的计算机都有一份账本。每一笔交易都需要记录到账本中，当一笔交易产生后，产生这笔交易的计算机将交易信息广播出去，其他链上的计算机就会收到交易信息，它们会进行一系列复杂计算，最终由率先计算完成的计算机将这笔交易信息记录到账本上。具体的计算机制其实是由不同的区块链设计好的，与该区块链的结构相关。比如按照比特币的设计，计算机需要将10分钟内的全部交易打包，再加上一个随机数，然后穷举随机数计算一个256位的哈希值，使得其符合一定的条件，这样就可以获得交易记账权，一旦计算完成并记账，该计算机要快速将计算的区块广播出去，由其他计算机来验证计算的正确性，防止他人篡改。 每产生一笔交易并不是立即就要被区块的各个节点记账，而是按设计要求被打包到一起，比特币设计为每10分钟将所有新交易打包（而以太坊时间更短，大约9秒左右），形成了一个区块（Block），然后将区块广播出去，区块链中的计算机都需要验证区块的正确性，并将其写入自己的账本中，完成记账。区块链则是由一个个相互连接的区块组成的，每一个区块都记录了上一个区块的 HASH 值，第一个区块没有上一个区块的 HASH 值，称之为”创世区块“。计算哈希值竞争记账权的计算机称为“矿工”，计算的过程称为”挖矿“，挖矿成功则获得交易记账权，记录打包好的交易信息并写入最新的区块，称为”出块“，最新出块的矿工可以获得一定的手续费收入。 区块链中的计算机都有账本，那么如果确定各个账本数据的一致性呢？区块链采用”共识机制“来保证大部分诚实计算机的账本一致性，这样就实现了完全去中心化。常用的共识机制有Pow（工作量证明机制，例如挖矿机制）、PoS（权益证明）、DPos（股权授权证明）和分布式一致性算法（如拜占庭容错算法、Paxos、Raft）。 与传统的中心化应用相比，区块链具有如下特点： 去中心化：区块链本质是基于P2P对等网络的分布式系统，链上的每一个节点都存有相同的数据，通过共识机制来决定交易数据的同步，不需要中心化服务器。但是目前，还不能做到完全的去中心化，某些场景还是具备中心化的特征。 高度开放：公有链上的区块链系统通常都是开源的，任何人都可以查询区块链上的数据，智能合约代码高度公开、透明，数据存储与链上所有节点中，不用担心中心化应用的资金安全等一系列问题。 高度可用：区块链应用由区块链上的每一个节点共同维护，任何一个或几个节点宕机不影响整个应用的可用性。 高度安全：区块链技术采用一系列加密措施（如非对称加密、哈希算法、椭圆曲线算法等）来对交易进行加密和签名，保证交易不能被伪造、篡改，然后借助分布式系统中各个节点的共识算法形成强大算力来抵御破坏者的攻击，从而保证链上数据的安全性。 匿名性：区块链上的用户信息都是匿名的，仅对外暴露钱包公钥和地址，就可以完成交易，完全不需要用户的真实身份信息。 2. 什么是以太坊 比特币作为一种虚拟数字货币，为金融领域开创了一种全新的去中心化货币系统。比特币的狂热粉们一直在探索，比特币技术能否使用到其他非金融领域呢？ 以太坊 的出现，为区块链技术迎来了崭新的时代。 2013年，比特币的忠实拥护者 Vitalik Buterin （人称V神）提出了一种构想：区块链不应该仅用于金融领域，而是应该开放出来形成一个开放平台，供人们开发更多的去中心化应用，为此他提出了以太坊，并发表了《以太坊：一个下一代智能合约和去中心化应用平台》，也就是后来的 《以太坊白皮书》。 以太坊 是一个去中心化的、开源的、图灵完备的、有智能合约功能的区块链开放平台。 首先，以太坊是一条发行有自己货币（ether，以太币）的区块链；其次，以太坊具备开发去中心化应用功能，它具有能够在以太坊虚拟机（EVM）上运行的 智能合约 功能，开发者可以编写智能合约来自主控制去中心化应用；第三，以太坊优化了PoW（工作量证明机制），并提供了PoS权益证明共识机制，大大加快了区块链交易确认速度（比特币确定一笔交易需要10分钟，而以太坊减少到9秒左右），为去中心化应用开发提供了必要条件。 总之，以太坊是一个区块链开放平台，通过它可以开发自己的区块链 去中心化（Decentralization）应用（Dapps）。 以太坊被称为"第二代的区块链平台"， 这个网站 用车站的例子动态、形象地展示了以太坊和比特币之间的一些差别，非常生动有趣。 3. 区块链中的一些基本概念 了解了区块链和以太坊，现在我们来看看区块链中的一些概念。 区块链：Blockchain，共享的分布式账本，交易附加到区块上存储并记录。 区块：Block，多个交易被打包为区块并存储，区块之间相互连接，形成一个链状结构，每一个区块都有一个哈希值加以区分，区块在链中的长度称为区块高度。 钱包：Wallet，存储用户虚拟货币的地方，对外暴露公共地址和公钥，内部包含有绝对私密的私钥信息。 以太坊：Ethereum，一个基于区块链的去中心化运行智能合约的平台，旨在解决与审查，欺诈和第三方干扰相关的问题。 主链：Mainnet，正式运行的区块链的主网络，一个区块链项目经过前期的技术开发后，最终都会发布到区块链主网上线，比如 以太坊主网。 侧链：Sidechains，侧链实质上不是特指某个区块链，而是指遵守侧链协议的所有区块链，该名词是相对于主链而言的。侧链协议是指可以让主币安全地从区块链主链转移到其他区块链，又可以从其他区块链安全地返回主链的一种协议。侧链与主链共存，并可以扩展主链的功能、提高交易速度等，比如ETM就是以太坊ETH的侧链。 测试链：Testnet，与主链功能相同的测试网络，以测试为目的搭建，可以免费从水龙头获得测试币在测试链上进行开发测试，如 币安测试链。 交易：由原始帐户签署的提交到以太坊区块链的数据，并以特定地址为目标。交易包含元数据，例如交易的燃气限额（Gas limit）。 区块链浏览器：查询区块链中数据的工具网站，可以详细查询区块链上的详细信息，如 以太坊浏览器、 币安链浏览器等等。 Dapp：去中心化应用，基于区块链技术开发的应用程序，数据存储于区块链中。 DAO：去中心化自治组织，一种将组织的管理和运营规则以智能合约的形式编码在区块链上，从而在没有集中控制或第三方干预的情况下自主运行的组织形式。DAO 有望成为应对不确定、多样、复杂环境的一种新型有效组织。 以太币：Ether，以太坊生态系统中使用的本地货币，在执行智能合约时承担gas费用，它的符号是 Ξ. 以太坊虚拟机：EVM，Ethereum Virtual Machine, 基于栈的、执行智能合约字节码的虚拟机。 智能合约：Smart Contract，在以太坊的虚拟机中执行的程序，有开发者编写以控制链上业务逻辑。 水龙头：Faucet，一个网站，用来向测试用户提供一定数量的测试币，供测试使用，测试币除了测试并没有真正的价值。 Solidity：过程式（命令式）编程语言，语法类似于 Javascript, C++ 或 Java，以太坊智能合约最流行和最常使用的语言。由以太坊架构师 Gavin Wood 发明。 图灵完备：Turing Complete，在计算理论中，如果数据操纵规则（如计算机的指令集，程序设计语言或细胞自动机）可用于模拟任何图灵机，则它被称为图灵完备或计算上通用的。这个概念是以英国数学家和计算机科学家阿兰图灵命名的。 ...

最近在维护一个老项目的时候，看到一段密码匹配的代码，感觉很奇怪，于是遍寻资料，最终还是很有收获。 1. 密码匹配 事情是这样的，一个项目遇到输入的密码总是提示密码错误的问题，于是debug跟踪了一下代码，发现该项目使用了 Spring Security 3.2.2 的 PasswordEncoder 来做密码MD5加密和密码匹配验证，PasswordEncoder 只是一个接口，其实现使用的是 StandardPasswordEncoder 类，它的密码匹配代码引起了我的注意： public boolean matches(CharSequence rawPassword, String encodedPassword) { (1) byte[] digested = decode(encodedPassword); byte[] salt = subArray(digested, 0, saltGenerator.getKeyLength()); return matches(digested, digest(rawPassword, salt)); } private boolean matches(byte[] expected, byte[] actual) { (2) if (expected.length != actual.length) { return false; } int result = 0; for (int i = 0; i < expected.length; i++) { result |= expected[i] ^ actual[i]; (3) } return result == 0; } ...

分布式系统，与传统单体架构系统相比，其结构复杂的多，系统间靠网络传输数据，系统存在诸多不确定因素，如硬件故障、网络波动等，都会影响整个系统的稳定性。而分布式事务更是分布式系统的一大难题，本篇将讨论业界分布式事务的几种常见解决方案。 1. 数据库事务 百度百科对事务的定义： 数据库事务( transaction)是访问并可能操作各种数据项的一个数据库操作序列，这些操作要么全部执行,要么全部不执行，是一个不可分割的工作单位。 解读一下这个定义： 事务产生于一个数据库操作序列：一组读取或者更新数据库等操作时，事务是一种机制，来保证了最终数据的一致性， 事务是一个不可分割的单元：一组操作不能拆分，是一个整体 事务执行：要么全部执行，要么全部不执行，不能部分执行 通常，数据库的事务是通过数据库日志来保证的，所有数据库的操作都记录日志，如果数据库发生宕机，那么通过读取日志可以知道操作时需要回滚还是提交。 众所周知，数据库事务有ACID四大特性，满足ACID特性的事务，一般称之为刚性事务，常见的单体应用（单个数据源）内部都是采用刚性事务。 最常见的事务的例子就是银行转账： 2. 分布式事务 分布式事务，指的是分布式系统间完成的事务机制，百度百科定义如下： 数据库事务( transaction)是访问并可能操作各种数据项的一个数据库操作序列，这些操作要么全部执行,要么全部不执行，是一个不可分割的工作单位。 分布式同数据库事务一样，都用以保证数据的一致性，只是事务的参与者由原来的单数据源的一组操作序列变成了分布式系统的多个子系统。 举个例子： 用户下单流程，如下图所示： 首先，订单系统订单支付完成，然后调用库存系统扣减库存，最后再调用积分系统给账户添加积分，第1、2、3步必须全部执行成功，那么下单操作才算成功，否则，有一步出现错误，那么下单操作就是失败的。与传统事务相比，分布式事务范围在数据库事务之上进行了放大，各个系统除了有本系统事务外，还需要符合整个分布式系统的事务机制，才能保证最终的数据一致性。 但是，在分布式系统中，由于其固有的复杂性，很难保证事务的ACID特性，这种刚性事务在分布式系统中不适用，这就要提到两个概念：CAP定理和BASE理论。 2.1. CAP理论 2000年，名为Eric Brewer的教授在PODC研讨会上提出了CAP：一致性、可用性和分区容错性三者无法在分布式系统中被同时满足，并且最多只能满足其中两个！他还对CAP进行明确的定义： C（Consistency，一致性）：所有的节点上的数据时刻保持同步 A（Avallable，可用性）：每个请求都能接受到一个响应，无论响应成功或失败 P（Partition tolerance，分区容错性）：系统应该能持续提供服务，即使系统内部有消息丢失（分区） CAP理论的提出，揭露了分布式系统的本质。 怎么理解CAP？ 一致性，其实就是分布式系统各节点间数据达成一致；可用性，分布式系统始终保持可用，即使出现了数据不一致；分区容错性，分布式系统必须有一定的容错能力，当系统数据丢失或者某些节点不可用（分区）系统还能继续提供服务，系统容错是不可缺少的。 既然CAP三者不能同时满足，而分布式系统中，分区容错性是不可或缺的，因此，只能在CP和AP中间选择。 由于在CAP理论要求各节点数据时刻保持同步，但是这样的强一致性只能在CP中保证，而选择满足AP时无法保证，这就引出BASE理论。 2.2. BASE理论 eBay的架构师Dan Pritchett源于对大规模分布式系统的实践总结，在ACM上发表文章提出BASE理论，BASE理论是对CAP理论的延伸，核心思想是即使无法做到强一致性，但应用可以采用适合的方式达到最终一致性（Eventual Consitency）。 BA: Basically Available（基本可用） S: Soft state（软状态） E: Eventually consistent（最终一致性） 显然，BASE理论满足CAP中的AP，从而舍弃了强一致性C。 满足BASE理论，放弃强一致性，数据最终达到一致的事务我们称之为柔性事务(Flexible Transactions)。 如果分布式系统满足AP，那么虽然数据不可能时刻保持一致，但是可以达到最终一致；如果满足产CP，那么分布式系统舍弃了高可用性，却可以保持数据强一致。分布式系统中，常见的两个服务注册中心Eureka、Consul，前者满足的是AP，而后者满足的是CP。 3. 分布式事务的解决方案 分布式事务解决的核心问题就是分布式系统中各个节点的数据一致性问题，选择强一致还是最终一致，需要根据具体业务需要合理做出选择。目前，常见的几种分布式事务解决方案有2PC(两阶段提交)、3PC（三阶段提交）、TCC（补偿性事务）、本地消息表等。 3.1. 2PC 两阶段提交(2PC)，其实是XA协议的标准实现，XA协议由Tuxedo首先提出的，并交给X/Open组织，作为资源管理器（数据库）与事务管理器的接口标准。目前，Oracle、Informix、DB2和Sybase等各大数据库厂家都提供对XA的支持。 2PC事务包括几个角色：事务协调者(coordinator)、事务参与者(participant )、资源管理器(resource manager，RM)： 事务协调者：负责收集事务参与者的信息，并决定事务提交/回滚操作 事务参与者：按照事务协调者要求参与事务，可进行事务预提交、提交或者回滚操作 资源管理器：事务参与者管理的数据库 2PC将事务的管理分为两个阶段： 1、第一阶段(prepare)：事务协调者要求每个事务参与者预提交(precommit)事务，事务并不会真正提交，并反馈(vote)提交结果 2、第二阶段(commit/rollback)：事务协调者收集参与者信息，如果每个参与者都反馈可提交事务，那么协调者下发commit指令给参与者要求提交事务，否则，如果有参与者反馈回滚事务，则协调者下发abort指令要求参与者都回滚事务 通俗的讲：协调者首先发起事务，说参与者们检查一下看看各自操作是否能够正常执行啊，不管可以与否都给我一个反馈。然后，参与者检查完成，都反馈说，老大，我们都能正常执行，那么协调者就说好吧，你们都提交事务吧；如果某一个参与者说，完了，我操作执行失败了，不能提交事务，那么协调者就告诉各参与者：某个哥们儿不能提交事务，数据一致性没法保证了，你们都回滚吧！ ...

在单体Java应用中，由于代码运行于同一个JVM，使用实现资源加锁是比较容易的，例如使用synchronized或ReentrantLock加锁来控制并发访问；但是在分布式系统中，多个分布式系统之间也需要控制并发访问，由于处于不同的JVM，此时就不能简单使用java的锁机制来进行控制。这种跨进程或者跨服务器的加锁，需要额外使用全局的获取锁的服务，就是本文探讨的分布式锁。 1. 为什么需要分布式锁 分布式锁解决的问题：保证分布式系统的共享资源在某一时刻只被一个客户端访问，保证数据的准确性。 举个例子： 如图所示，订单服务下单前需要保证库存足够，库存服务首先会检查库存充足，然后在将订单的库存数量锁定，如果此时管理系统对库存数量进行了修改，那么由于跨系统的并发操作可能操作库存数据的不正确。此时，对库存的操作就需要考虑分布式锁，将库存锁定，暂时不能更改。 这样一来，对库存的更改和扣减操作使用同一把锁来锁定，每次只有一个客户端能够操作成功，要么订单服务先扣减服务，要么管理系统先修改库存，反正两个不能同时进行。 2. 分布式锁的现有方案 分布式锁的整体思路是：在分布式系统中，有一个全局的东西（中间件或服务），各个服务需要加锁时都向它获取锁，然后给锁一个标记(例如锁的名称)，如果标记相同则认为是同一把锁，这样就可以控制各个系统的资源共享。 目前，分布式锁的方案大致有以下几种： 基于Zookeeper的临时节点 基于Redis的SET命令 这里仅仅讨论Redis的分布式锁实现。 3. Redis实现分布式锁的原理 基于Redis来实现分布式锁，其原理很简单：在Redis中设置一个Key，表示加锁，如果其他系统来加锁时发现这个Key已经存在，表示已经加了锁，则它获取锁失败，然后它再不断重试加锁，直到加锁成功，然后才能执行后续业务逻辑。释放锁也很简单，直接将这个KEY删除即可。 锁一旦被创建，就必须能够释放，否则会引起死锁（其他系统永远获取不到锁），一般会使用Redis的过期机制，让KEY一段时间后自动过期以避免死锁。 加锁时，过程如下： 首先，使用SET命令来为某一个KEY（可以作为锁名称）设置一个唯一的值，仅当KEY不存在时才能加锁成功，如果KEY存在则设置失败，表明锁已经存在； 其次，为该KEY设置一个过期时间，来避免死锁问题； 释放锁时，先获取锁是否存在，如果存在则调用DEL命令删除该KEY。 无论是加锁，还是释放锁，都需要保证命令的原子性执行（要么都成功，要么都失败，试想一下，如果加锁时SET命令成功，然后在调用EXPIRE命令设置过期时间，未完成时Redis宕机了，会造成死锁）。例如，加锁时，SET命令和设置过期时间需要为一个原子命令，Redis已经提供了原子命令，如下： // NX是指如果key不存在就成功，key存在返回false，PX指定过期时间，单位毫秒 SET anyLock unique_value NX PX 30000 释放锁时，获取锁和删除KEY为一个原子操作，Redis没有提供获取KEY然后DEL的原子命令，这里需要用到LUA脚本以保证原子性： // 执行LUA脚本保证原子性，先获取锁，然后调用DEL删除 if redis.call("get",KEYS[1]) == ARGV[1] then return redis.call("del",KEYS[1]) else return 0 end 需要注意的是，加锁时设置的KEY值value必须是唯一的，这是因为在释放锁时需要获取到该值以便验证释放锁的客户端和加锁的客户端是同一客户端，如果value值不唯一则可能客户端A加了锁，但是由客户端B给释放了，引起业务混乱而没有达到加锁的目的。 4. 三种部署方式下的锁问题 Redis有三种部署方式，每种方式下的分布式锁都存在一些问题： 1、单机部署 这种方式下，很明显的缺点就是单点问题，Redis故障了，那么分布式锁就不能使用了。 2、Master-Slave + Sentinel模式 主从+哨兵模式，主节点挂了，哨兵会重新选择一个从节点作为主节点，数据会复制到从节点上，但是复制过程需要一定的时间，如果主节点挂了，它上边的锁可能还没有复制到从节点上，就会造成锁丢失。 3、Cluster模式 集群部署模式，同理，在某一个节点上的锁可能还没有复制到其他节点上，同样会造成锁丢失。 使用Redis的分布式锁，其优点是性能很高，支持高并发分布式锁场景，缺点则是如果加锁失败，需要不断循环重试加锁，消耗资源，另外，Redis集群下可能造成锁丢失的极端情况，对于这种情况，Redis的作者也考虑到了，他提出了RedLock算法，具体可以看 这里。 5. 使用Redisson的分布式锁 一般而言，不推荐自己实现Redis分布式锁，因为需要考虑诸如锁重入等多种情况，Java的Redisson框架已经为我们提供了分布式锁的支持。 Redisson是一个Java版的Redis Client，提供了大量的基于Redis的分布式特性支持，例如 分布式锁、分布式任务调度、分布式远程服务、分布式集合等等，Redisson官网： https://redisson.org/ 要使用Redisson的分布式锁非常简单，基本的代码如下： RLock lock = redisson.getLock("anyLock"); lock.lock(); // do something …… lock.unlock(); ...

很早之前，博主的的网站评论模块已经更改为了 gitalk，Gitalk是一个基于GitHub Issue和Preact的现代评论组件。更换评论组件后有一个问题：我不想每次去github上查看别人的评论，如果别人评论了文章，然后我能够在网站后台看到，这样就很方便了。此时，github的webhook功能就可以登场了。 1. 简介 Webhook，翻译过来可以称为网络钩子，用来将Github上的一系列事件信息回传到某一回调地址上，从而完成与外部应用的交互，它是github提供的一种与外部交互的入口。Github上提供了很多交互事件，当某一事件被触发后，如果设置了Webhook的回调地址，Github将会通过HTTP POST请求将事件信息发送到回调地址上，回调处理应用通过接收事件信息然后实现自身的业务需求。 目前，每个组织或代码库上最多只能创建20个webhook。 一个典型的业务场景是：代码保存在github上，如果稳定的master分支上提交了代码，就触发持续集成系统如Jenkins进行代码构建、打包、部署等系列操作。 2. 事件 配置webhook时，可以选择订阅的事件。一般情况下，我们只需要订阅关注的事件，github也支持一个匹配所有支持事件的通配符（*），添加通配符事件时，github将使用通配符事件替换您配置的任何现有事件，并为所有支持的事件发送有效负载。如果将来添加了新的可匹配的事件，那么将会自动订阅。您可以随时通过API或UI更改订阅事件列表。默认情况下，webhooks仅订阅push事件。 每个事件对应于您的组织和/或存储库可能发生的某组操作。例如，如果您订阅了问题事件，则每次打开，关闭，标记等issue时您都会收到详细的有效负载。github现支持的事件列表见 #events[附录一]。 2.1. 有效负载 有效负载，简单理解就是消息所携带的内容和信息。 每种事件类型都具有特定的有效负载格式以及相关的事件信息，事件的有效负载来源于具体的事件类型的有效负载，但原始push事件除外，它的具有更详细的webhook有效负载。 除了为每个事件记录的字段之外，webhook有效负载还包括执行事件的用户（发送者）、组织和事件发生的存储库。GitHub app的webhook有效负载还可能包括安装事件。 一个marketplace_purchase事件类型的有效负载的示例如下： { "action":"purchased", "effective_date":"2017-10-25T00:00:00+00:00", "sender":{ "login":"username", "id":3877742, "avatar_url":"https://avatars2.githubusercontent.com/u/3877742?v=4", "gravatar_id":"", "url":"https://api.github.com/users/username", "html_url":"https://github.com/username", "followers_url":"https://api.github.com/users/username/followers", "following_url":"https://api.github.com/users/username/following{/other_user}", "gists_url":"https://api.github.com/users/username/gists{/gist_id}", "starred_url":"https://api.github.com/users/username/starred{/owner}{/repo}", "subscriptions_url":"https://api.github.com/users/username/subscriptions", "organizations_url":"https://api.github.com/users/username/orgs", "repos_url":"https://api.github.com/users/username/repos", "events_url":"https://api.github.com/users/username/events{/privacy}", "received_events_url":"https://api.github.com/users/username/received_events", "type":"User", "site_admin":true, "email":"username@email.com" }, "marketplace_purchase":{ "account":{ "type":"Organization", "id":18404719, "login":"username", "organization_billing_email":"username@email.com" }, "billing_cycle":"monthly", "unit_count":1, "on_free_trial":false, "free_trial_ends_on":null, "next_billing_date":"2017-11-05T00:00:00+00:00", "plan":{ "id":435, "name":"Basic Plan", "description":"Basic Plan", "monthly_price_in_cents":1000, "yearly_price_in_cents":10000, "price_model":"per-unit", "has_free_trial":true, "unit_name":"seat", "bullets":[ "Is Basic", "Because Basic " ] } } } ...

堆dump，即堆转储，其实是一个当前JVM堆内存所有对象在某个时间点上的快照。堆dump用来将当前应用程序的堆内存中的数据信息保存为文件，并可以快速浏览文件中的内容，查询对象分配信息。 在VisualVM中，堆dump的入口很多，可以再应用程序右键，选择堆dump；也可以打开主窗口的“监视”tab页，点击右上角有堆dump按钮；还可以打开抽样器tab页，进行内存抽样后，点击工具栏上的堆dump按钮。 1. 打开堆dump 执行完堆dump后，主窗口会打开一个堆dump的页面，同时应用程序节点会增加一个headdump+时间子节点，可以直接打开该节点来浏览堆dump文件信息，如图所示： 堆dump文件存储后缀为.hprof，除了能够看到本地堆dump文件，也可以通过菜单栏的文件-装入打开他人分享的dump文件： 2. 浏览堆dump文件信息 堆dump tab页包含了几个子标签页面：概要、类、实例、OQL控制台，我们重点说下前三个。 2.1. 概要 显示了转储堆dump时的信息，包括基本信息、环境信息、系统属性和线程信息，例如你可以看到堆dump时间、文件存放位置、大小等。 2.2. 类 类视图显示类的列表，以及该类引用的实例的数量和百分占比、类所有实例的大小和百分占比。您可以通过在实例视图中右键单击名称和选择“在实例图中显示”或者直接双击类来查看特定类的实例列表： 通过类视图，可以整体上明确哪些类实例数多，占用资源高。 可以通过最下方的“类目过滤器”来搜索类，点击漏斗形状的图标可以选择筛选类型，例如包含/不包含类名称、正则匹配、搜索子类等。例如，搜索类名包含EsSyncTask的所有类，如下图所示： 2.3. 实例数 当在类视图选择查询具体某一个类的实例时（右键或者双击），此时就打开了该类的实例视图。当您从实例窗格中选择一个实例时，VisualVM将显示该类的字段，并在各自的窗格中引用该类。 除了显示了具体的类和概要信息（实例数量、大小、总大小等）外，实例视图还有几个面板： 实例数：显示当前类的实例列表，点击具体的某一个实例可以在字段和引用面板查看实例的字段信息和引用了的对象 字段：显示当前选择的实例的具体字段，包括字段名称、类型、字段值等 引用：递归显示当前所有引用了该类的类实例，该面板会一层层递归显示引用，包括引用实例的再引用。通过引用面板，可以跟踪对象的引用情况，以便找到具体的类，从而优化代码。 通过右键点击实例或者在引用面板右键，可以查看最近垃圾回收根节点。 接下来，我们来编一个实例程序，看看堆dump的情况，代码如下： public class HeaddumpTest { public static void main(String[] args) { Refrence ref = new Refrence(); int id = 0; while (true) { ref.add(new MyClass(id++, "myclass" + id)); try { Thread.sleep(10); } catch (InterruptedException e) { e.printStackTrace(); } } } } class Refrence { private List<MyClass> myClasses = new ArrayList<>(); public void add(MyClass myClass) { myClasses.add(myClass); } public List<MyClass> getMyClasses() { return myClasses; } public void setMyClasses(List<MyClass> myClasses) { this.myClasses = myClasses; } } class MyClass { private int id; private String name; MyClass(int id, String name) { this.id = id; this.name = name; } public int getId() { return id; } public void setId(int id) { this.id = id; } public String getName() { return name; } public void setName(String name) { this.name = name; } } ...

无论是本地还是远程节点，双击或者右键打开应用程序，会直接在主窗口打开程序监控页。主窗口包括几个子页面：概述、监视、线程、抽样器，如果是本地程序且支持分析器还会显示Profiler页，根据安装插件的不同，还可能会显示一些插件的页面，例如MBeas等。 Figure 1. 主窗口界面 1. 概述页 概述页显示了应用程序和运行时环境的基本信息，如下图所示： Figure 2. 概述页界面 概述信息包括基本参数、保存的数据、详细信息几个部分。 1.1. 基本参数 基本参数描述了应用程序的一些参数信息，包括如下信息： PID：应用程序的进程ID 主机：应用程序运行的系统地址 主类：运行了main方法的类 参数：应用启动时所传递的参数信息，例如传递给main方法的参数列表 JVM：当前的JVM信息 Java：当前使用的JDK信息 Java Home：JDK的位置 JVM标志：启动JDK时JVM使用的的标志 出现OOME时生产堆dump：当前出现OOME时生产堆dump功能的开启/禁用状态 除了基本信息外，还包括两个可以自主选择显示或隐藏的功能（右上角）：保存的数据和详细信息。 1.2. 保存的数据 显示VisualVM存储的当前应用程序的信息，例如线程dump的数量、堆dump和快照的数量等。 1.3. 详细信息 包括两个标签：JVM参数和系统属性。 JVM参数：配置的JVM启动的参数信息，例如堆大小； 系统属性：JVM运行的系统属性，例如用户目录、文件编码； 2. 监视页 监视tab页展示了监听了当前应用程序的整体情况，包括几个指标：CPU、内存、类、线程，它们都以直观的图形方式展现。 Figure 3. 监视页界面 2.1. CPU 该图展示了CPU的使用百分比走势，包括执行垃圾回收活动的时间等。可以从该图查看应用程序是否耗费CPU，是否频繁的进行垃圾回收，以便优化代码或者调整JVM内存设置。 2.2. 内存 反映了内存的占用情况，包括内存大小、最大值和已经使用的大小。内存情况又包括两部分：堆和Metaspace。 堆：该页展示了堆内存的大小和堆内存使用走势情况。 Metaspace：即元空间，JDK8移除了永久代（PermGen），而类的元数据信息被存储在了Metaspace，具体请看 这里。该标签反映了元空间内存的使用情况。 2.3. 类 类视图显示了已经加载的类数量和共享类的数量走势情况。 2.4. 线程 线程视图显示了应用程序在JVM中生存和守护线程的数量走势情况。如果您想在特定的时间点捕获和查看应用程序线程的精确数据，可以打开线程标签页，使用VisualVM进行线程转储（稍后详述）。 除了这四个图表，监视页还有两个重要的功能：执行垃圾回收和堆dump。 执行垃圾回收：立即触发垃圾回收 堆dump：执行堆dump，并在新的标签页打开，以查看对dump的详细信息(同右键应用程序–堆dump)。 通常，需要长期监控应用程序的情况，幸好这不会带来太大的开销。 我们看一个OOM的例子，看看VisualVM的监视页的监控情况。代码如下： public static void main(String[] args) { List<Object> objects = new ArrayList<>(); new Thread(() -> { while (true) { objects.add(new Object()); try { Thread.sleep(200); } catch (InterruptedException e) { e.printStackTrace(); } } }).start(); } ...

Java应用程序难免遇到性能问题，例如常见的OutOfMemmoryError，又或者是出现内存泄漏的错误，又或是程序运行一段时间就卡死了，CPU或者内存占用率高，甚至造成系统崩溃，等等。出现性能问题时，往往难以分析和跟踪。不过，可以借助于一些性能分析工具，来监测程序性能，从而找出影响性能的问题所在，以便进行优化。本文的VisualVM就是一款比较强大的性能分析工具。 先来看看性能分析的几种方式： 性能分析的主要方式 性能分析常用的有以下几种方式 * 监视：监视是一种用来查看应用程序运行时行为的一般方法。通常会有多个视图（View）分别实时地显示 CPU 使用情况、内存使用情况、线程状态以及其他一些有用的信息，以便用户能很快地发现问题的关键所在。 * 转储(dump)：性能分析工具从内存中获得当前状态数据并存储到文件用于静态的性能分析。Java 程序是通过在启动 Java 程序时添加适当的条件参数来触发转储操作的。它包括以下三种： 核心dump：JVM 生成的本地系统的转储。一般的，系统转储数据量大，需要平台相关的工具去分析，如 Windows 上的 windbg 和 Linux 上的 gdb。 Jvm dump：JVM 内部生成的格式化后的数据，包括线程信息，类的加载信息以及堆的统计数据。通常也用于检测死锁。 堆dump：JVM 将所有对象的堆内容存储到文件。 * 快照：应用程序启动后，性能分析工具开始收集各种运行时数据，其中一些数据直接显示在监视视图中，而另外大部分数据被保存在内部，直到用户要求获取快照，基于这些保存的数据的统计信息才被显示出来。快照包含了应用程序在一段时间内的执行信息，通常有 CPU 快照和内存快照两种类型。 CPU 快照：主要包含了应用程序中函数的调用关系及运行时间，这些信息通常可以在 CPU 快照视图中进行查看。 内存快照：主要包含了内存的分配和使用情况、载入的所有类、存在的对象信息及对象间的引用关系等。这些信息通常可以在内存快照视图中进行查看。 * 性能分析：性能分析是通过收集程序运行时的执行数据来帮助开发人员定位程序需要被优化的部分，从而提高程序的运行速度或是内存使用效率，主要有以下三个方面： CPU 性能分析：CPU 性能分析的主要目的是统计函数的调用情况及执行时间，或者更简单的情况就是统计应用程序的 CPU 使用情况。通常有 CPU 监视和 CPU 快照两种方式来显示 CPU 性能分析结果。 内存性能分析：内存性能分析的主要目的是通过统计内存使用情况检测可能存在的内存泄露问题及确定优化内存使用的方向。通常有内存监视和内存快照两种方式来显示内存性能分析结果。 线程性能分析：线程性能分析主要用于在多线程应用程序中确定内存的问题所在。一般包括线程的状态变化情况，死锁情况和某个线程在线程生命期内状态的分布情况等 — 使用 VisualVM 进行性能分析及调优 https://www.ibm.com/developerworks/cn/java/j-lo-visualvm 1. VisualVM简介 VisualVM是集成JDK命令行工具和轻量级分析功能的可视化分析工具，设计用于开发和生产时间的使用。它提供了一个可视化界面，用于查看基于Java技术、运行于JVM上的应用程序(Java应用程序)的详细信息。 VisualVM组织Java开发工具包(JDK)工具检索的JVM软件的数据，并以一种使您能够快速查看多个Java应用程序的数据的方式提供信息。您可以查看在远程主机上运行的本地应用程序和应用程序的数据。您还可以捕获有关JVM软件实例的数据，并将数据保存到您的本地系统中，以供后期查看或与其他用户共享。 VisualVM完全免费，它通过 jvmstat、JMX、SA（Serviceability Agent）以及 Attach API 等多种方式从程序运行时获得实时数据，从而进行动态的性能分析。同时，它能自动选择更快更轻量级的技术尽量减少性能分析对应用程序造成的影响，提高性能分析的精度。 2. VisualVM安装 从JDK6开始，VisualVM已经成为JDK自带工具，名称叫做jvisualvm，位于%JAVA_HOME%/bin/jvisualvm.exe，执行即可启动。 需要注意的是，从Oracle JDK 9开始，Java VisualVM迁移到GraalVM，这是在Oracle实验室开发的一种创新的、高性能的多语言虚拟机。详情请参阅 Graal VisualVM页面。 ...

1. 问题背景 最近开发一个图片服务，主要是维护项目图片，支持JPG、BMP、PNG、JPEG等常规格式。开发的时候没问题，但是上到生产的时候，客户在维护图片的时候，发现有的JPG格式的图片能上传，有的不能。 拿到正常上传和不能上传的图片，对比发现，不能上传的图片，在windows上根本无法打开，图片如下(用chrome打开可以看见，右键另存图片，或者 点击这里下载)： 但是奇怪的是，该图片可以在chrome浏览器显示，也可以在安卓APP上显示，但是其他浏览器和iOS无法正常显示。 2. 问题分析 首先debug代码，发现图片都会使用ImageIO来读取，以便获取图片宽高从而进行等比例压缩，代码如下： BufferedImage bi = ImageIO.read(inputStream); Map rtnMap = new HashMap(); if (bi == null) { rtnMap.put("status", "1"); //上传不成功 rtnMap.put("msg", "该图片本身不是图片格式"); return rtnMap; } 非正常图片，上边的bi会返回null，而不会抛出任何异常信息。 首先怀疑图片是损坏的，因为windows上根本无法打开，显示如下： 但是该图片可以在chrome上正常显示，这表明图片不会是损坏了，应该是跟平台有关，那么会不会是图片格式根本不是JPG，仅仅后缀显示为JPG呢？ 然后我用记事本打开正常的和非正常的图片文件进行比对，想获取一些有用的信息，结果发现： 非正常JPG图片 正常JPG图片 如上所示，正常JPG里边，显示格式为JFIF，而非正常图片显示为WEBPVP8，明显不同。看来，不能正常上传的图片是平台不支持的图片格式，到底WEBPVP8是什么格式？ 3. WEBP格式 通过谷歌搜索，查询半天发现，这种格式名为WEBP，由谷歌开发，官方地址（记得翻墙）： https://developers.google.com/speed/webp/?hl=zh-CN，也是图片格式的一种， 百度百科原文如下： WebP格式，谷歌（google）开发的一种旨在加快图片加载速度的图片格式。图片压缩体积大约只有JPEG的2/3，并能节省大量的服务器带宽资源和数据空间。Facebook Ebay等知名网站已经开始测试并使用WebP格式。 但WebP是一种有损压缩。相较编码JPEG文件，编码同样质量的WebP文件需要占用更多的计算资源。桌面版Chrome可打开WebP格式。 恍然大悟，原来是一种新型图片格式，很明显windows和iOS还不支持，但是谷歌旗下产品可以支持，这就解释了为什么chrome、安卓能够打开。 在JAVA中，还不支持这种格式，可以用如下代码检查当前支持的图片格式： String[] ss = ImageIO.getReaderFormatNames(); System.out.println(Arrays.asList(ss)); 返回结果：[JPG, jpg, bmp, BMP, gif, GIF, WBMP, png, PNG, jpeg, wbmp, JPEG] 在查找问题时，我还尝试使用twelvemonkeys扩展包来扩展所支持的图片类型： <dependency> <group>com.twelvemonkeys.imageio</group> <artifact>imageio-jpeg</artifact> <version>3.3.2</version> </dependency> <dependency> <group>com.twelvemonkeys.imageio</group> <artifact>imageio-tiff</artifact> <version>3.3.2</version> </dependency> <dependency> <group>com.twelvemonkeys.imageio</group> <artifact>imageio-pnm</artifact> <version>3.3.2</version> </dependency> ...