写点什么

未来的互联网存储:5 大分布式存储平台深入比较(上)

  • 2018-12-14
  • 本文字数:8706 字

    阅读完需:约 29 分钟

未来的互联网存储:5大分布式存储平台深入比较(上)

谈到区块链和分布式计算,最重要的是共识算法和智能合约。但是,谈及日常应用程序,这些属性还不足以支持当今世界的需求。如果我们只依靠上述这两项,就难以想象像在 Netflix 上那样观赏喜爱的电影或电视剧、像在脸书上那样存储或分享值得纪念的视频或照片,或在区块链上玩喜爱的在线游戏(如 DOTA)。


我们缺少一个强大、安全和去中心化的内容存储以及分发系统,服务于当今的应用程序。


下面,我们将探索和评估一些最流行的分布式存储平台。


本文为系列文中的《上》篇,主要介绍 Swarm 和 IPFS。系列文的《中》及《下》篇将分别介绍 Sia 和 Storj 以及 MaidSafe。

1.Swarm

状态:

活跃

说明:

Swarm 是分布式存储平台和内容分发服务,是以太坊 web3 栈的本地基础层服务。Swarm 的主要目标是提供充分分散和冗余存储的以太坊公共记录,尤其是存储和分发 DApp 的代码和数据以及区块链数据。从经济角度来看,它允许参与者有效汇集他们的存储容量和带宽资源,以给网络的所有参与者提供这些服务,同时接受以太坊的激励。

目标

Swarm 更广泛的目标,是为去中心化的 web 应用程序(DApp)开发人员提供基础设施服务,特别是:消息传递、数据流、点对点记账、可变资源更新、存储保险、监管扫描和修复、支付渠道和数据库服务


从终端用户的角度来看,Swarm 和万维网的差别不大,除了上传不托管在特定的服务器上。Swarm 提供了一个点到点的存储和服务解决方案,它具有 DDos 抗性、零停机、容错和审查及自我维持的特性,它内置了激励系统,通过点对点记账,允许用户为交易资源进行支付。Swarm 旨在和以太坊的 devp2p 多协议网络层以及以太坊区块链进行深度集成,以进行域名解析(利用 ENS)、服务支付和内容可用性保证。


请注意:为了解析 ENS 域名,Swarm 节点必须要连接到以太坊区块链上(主网或测试网)。


请参考开发路径图,以获得 Swarm 的进展信息。

概述

Swarm 旨在给新的去中心化互联网提供基础层的基础设施。Swarm 是点对点的节点网络,通过彼此之间贡献资源(存储、消息转发、支付处理)提供分布式数字服务。以太坊基金会运作 Swarm 测试网,可以用来以类似于以太坊测试网络(ropsten)的方式测试功能。每个人都可以通过在自己的服务器、台式机、笔记本电脑或移动设备上运行 Swarm 客户节点加入到网络中。请参阅《Swarm入门(https://swarm-guide.readthedocs.io/en/latest/gettingstarted.html#getting-started)》一文以了解操作方法。Swarm 客户端是以太坊栈的一部分,参考实现是用 golang 编写的,可以在 go-ethereum 存储库中找到它。目前在所有节点上运行的是 POC 0.3 版。


Swarm 提供本地 HTTP 代理 API,DApp 或命令行工具可以用来和 Swarm 进行交互。像消息传递这样的模块只能基于 PRC-JSON API 才可使用。在测试网(testnet)上的基础服务提供公共网关,用于轻松演示功能和允许免费的访问,以便人们无需运行任何自己的节点即可尝试 Swarm。


Swarm 是 devp2p 网络的节点集合,其中的每个节点在同一个网络 ID 上运行 bzz 协议套件。


Swarm 节点也可以连接到一个(或多个)以太坊区块链上,以进行域名解析,并连接到一个以太坊区块链进行带宽和存储补偿。运行相同网络 ID 的节点应该连接到相同的区块链上以进行支付。Swarm 网络由其网络 ID 标识,该网络 ID 是一个任意整数。


Swarm 允许上传(upload)和消失(disappear),这意味着任何节点可以只上传内容给 Swarm,然后就可以下线。只要节点没有丢失或变得不可用,该内容将仍旧可以访问,这是因为有一个“同步”的过程,节点持续地在彼此之间传递可用数据。

公共网关

Swarm 提供本地 HTTP 代理 API,DApp 可以用来和 Swarm 进行交互。以太坊基金会在托管公共网关,该网关允许免费访问,因此,人们甚至无需运行自己的节点即可尝试 Swarm。


Swarm 公共网关可以在http://swarm-gateways.net上找到,上面一直都运行着最新的 Swarm 稳定版。


请注意:目前,该网关只接受限制大小的上传。将来,上传到该网关的功能很可能完全消失。

上传和下载数据

上传内容由这些步骤组成:“上传”内容到本地 Swarm 节点,接着本地 Swarm 节点用其在网络中的对等点“同步”所生成的数据块。同时,下载内容由这些步骤组成:本地 Swarm 节点查询在网络中的对等点以获取相关的数据块,然后在本地重组这些内容。

内容解析器:ENS

请注意:为了解析 ENS 名称,Swarm 节点必须连接到以太坊区块链(主网或测试网)。


ENS是个系统,Swarm 用它来实现以人类可读的名称(如 theswarm.eth)引用内容。它的操作类似于 DNS 系统,把人类可读的名称转换成机器标识符,在此,即你正在引用的内容的 Swarm 哈希。通过注册一个名称,并把它解析成网站的根清单的内容哈希值,用户可以通过 URL(如 bzz://theswarm.eth/)访问该网站。


请注意:目前,主流的浏览器(如 Chrome、Firefox 或 Safari)不支持 bzz 协议。目前,如果要通过这些浏览器访问 bzz 协议,必须使用 HTTP 网关(如https://swarm-gateways.net/bzz:/theswarm.eth/)或者使用支持 bzz 协议的浏览器(如Mist)。


要了解更多在 Swarm 上传、下载和处理内容的信息,请参阅这里

可变资源更新(Mutable Resource Updates)

可变资源更新是 Swarm POC3 上的一项高度实验性的功能 。它正在积极开发中,因此,有些东西可能会有变化。


我们在这份指南中已经了解到,当我们在 Swarm 中改变数据时,我们上传的数据所返回的哈希值会以无法预料的方式变化。通过可变资源更新,Swarm 提供一种内置方式,可以对更改数据保持一个持久的标识符。


为了保持与更改数据有相同的指针,常用的方法是利用以太坊命名服务 ENS。但是,ENS 是一个链上功能,它限制了其他地方的功能:


  • 每个 ENS 解析器的更新都需要 gas 才能进行。

  • 更改数据不可能比挖出新区块的速度更快。

  • 正确的 ENS 解析方案要求始终同步到区块链。


可变资源更新允许我们用非变量标识符来更改数据,无需使用 ENS。利用在创建资源时获得的密钥,可以像普通 Swarm 对象一样引用可变资源。


如果同时使用 ENS 解析器合约和可变资源更新,只需要一个初始事务来注册 MRU_MAINFEST_KEY。该密钥将解析到资源的最近版本上(更新该资源不会改变该密钥)。有 3 种和可变资源更新进行交互的方法:HTTP API、Golang API 和 Swarm CLI。


请参阅这里以了解更多情况。


注意事项:


  • 只有创建该资源的私钥(地址)可以更新它。

  • 在创建可变资源时,必须要提供的参数之一是预期的更新频率。这表明该资源多快(以秒计算)被更新一次。尽管你可以以其他的速率更新该资源,但这么做会减慢索引该资源的处理过程。

Swarm 上的加密

在 POC 0.3 中引入了对称加密技术,现在可以很容易随 Swarm up 上传命令一起使用对称加密了。该加密机制是用来保护信息,并使得在处理任何 Swarm 节点时都不可读分块数据。


Swarm 使用计数器模式加密技术来加密和解密内容。当上传内容到 Swarm 时,该上传的数据被分为 4KB 大小的块。这些块都将用独立的随机生成的加密密钥来编码。这个加密过程在本地 Swarm 节点上发生,没被加密的数据不与其他节点共享。单个块(和整个内容)的引用将是编码数据哈希值和加密密钥的组合。这意味着引用将比标准无加密的 Swarm 引用长一些(不是 32 个字节,而是 64 个字节)。


当你的节点将你的内容的加密块与其他节点同步时,它不与其他节点共享完整的引用(或任何方式的解密密钥)。这意味着其他节点无法访问你的原始数据,此外,它们也无法侦测到同步的块是否经过加密。


检索数据时,只在本地 Swarm 节点上将它解密。在整个检索过程中,这些块以加密的形式遍历网络,参与的对等节点无法解密它们。它们只在用于下载的 Swarm 节点上进行解密和重组。


要了解如何在 Swarm 上处理加密的更多信息,请参阅这里(https://github.com/ethersphere/swarm/wiki/Symmetric-Encryption-for-Swarm-Content)。


注意事项:


  • Swarm 支持加密。由于无法撤销上传,因此强烈建议不上传未加密的敏感和私密数据。用户应该避免上传非法的、有争议的或不道德的内容。

  • Swarm 目前即支持加密也支持未加密的 swarm up 命令,通过使用–encrypt 参数来标识。将来可能有变化。

  • 加密功能是非确定性的(因为每个上传请求生成的密钥是随机的),API 的用户不应该依赖结果的幂等性;这样,在启用加密的情况下,同样的内容两次上传到 Swarm 所产生的引用是不同的。

PSS

PSS(Postal Service over Swarm,Swarm 上的 Postal 服务)是 Swarm 上的消息传递协议,具有强大的隐私功能。PSS API 通过在该API Reference中所描述的 JSON RPC 接口公开,我们在这里只解释基本概念和功能。


请注意:PSS 仍然是个实验性的功能,正在积极开发中,可从 Swarm 的 POC3 开始使用。预计有些事情会有所变化。

基础知识

通过 PSS,可以发送消息给 Swarm 网络上的任何节点。消息的路由方式和块的检索申请方式一样。PSS 消息不使用块哈希引用,而是在覆盖地址空间中指定目标,与消息的有效负载无关。如果该目标是一个完整的覆盖地址就可以将其描述为一个特定的节点,或者如果它只部分指定其一,则可以描述为邻居。消息通过 DevP2P 对等连接使用 forwarding kademlia 算法进行转发,forwarding kademlia 算法则通过使用 kademlia 路由的中继节点之间的半永久点对点 TCP 连接传递消息。在目标邻居内,该消息利用 Gossip 进行广播。


由于 PSS 消息是加密的,因此,最终收件人可以解密该消息。可以用非对称或对称加密方式进行加密。


消息有效负载通过接收节点分发给消息处理器,并通过 API 分发给订阅用户。


请注意:目前,PSS 不保证消息的订购(尽最大努力传递),也不保证消息的传递(也即,不缓存和中继给离线节点的消息)。

隐私功能

得益于端到端的加密,PSS 也适合私人通信。


PSS 使用了 forwarding kademlia 算法,对发送者进行匿名化处理。


利用部分寻址,pss 提供收件人匿名的可调范围:目标邻居越多,所显示的预期收件人覆盖地址的前缀越小,就越难识别真正的收件人。另一方面,由于暗路由(dark routing)效率低,因此在匿名性和消息传递延迟及带宽(还有因此产生的成本)之间需要折衷,而这留给应用程序来选择。


如果使用 Handshakes 模块,则提供前向保密。


要了解更多 pss 的使用情况,请参阅这里

架构

请参阅这里以了解更多 Swarm 的架构。

示例 DApp

请参阅 Swarm 去中心化应用实例的详细内容,请参照这里


注意事项:


  • 敏感内容一定要加密!对于加密内容,上传的数据是“受保护的”,也即,只有那些知道对根块(文件的 Swarm 哈希值和加密密钥)引用的人可以访问该内容。因为发布该引用(在 ENS 上或用 MRU)需要一个额外步骤,只要用户使用加密,就可以轻松地得到保护,防止粗心地发布。Swarm 会删除没有明确受到保护的内容,这是因为 Swarm 中限制了存储容量,Swarm 最终会将这些节点转到垃圾箱内

  • 直到实施存储保险(请参阅路径图以了解更多)之前,测试网不保证持久保存上传的内容。所有参与的节点都被视为没有任何义务的自愿服务,以其意愿删除内容。这样,在激励系统运行之前,用户在任何情况下都不应该将 Swarm 视作安全存储介质。

  • Swarm 是持久数据结构(Persistent Data Structure),因此,在 Swarm 中没有删除或移除操作的概念。这是因为内容被传播到被激励服务它的 Swarm 节点。


Swarm Reddit | Swarm Twitter | Swarm Github

2. IPFS

状态:

活跃(这是一个激励系统,“Filecoin”是不活跃的)

说明:

IPFS(Interplanetary File System,星际文件系统),是点对点(peer-to-peer,简称 p2p)文件共享系统,旨在从根本上改变信息在全球范围内的传播方式。它跟 Swarm 有点类似,或者,我们也可以说 Swarm 跟 IPFS 有点类似。


IPFS 包含了通信协议和分布式系统的几个创新,它们的组合产生了与众不同的文件系统。因此,为了理解 IPFS 所要尝试达到的广度和深度,重要的是,理解使其变得可能的技术突破和所有它在尝试解决的问题。


IPFS 自诩要取代 HTTP。那么,我们来看看如今互联网的工作原理。


简而言之,现在的互联网是协议的集合,这些协议描述了数据是如何在整个网络中移动的。随着时间的推移,开发人员使用着不同的协议,并在该基础设施上构建他们的应用程序。在这些协议中,其中一个是 Web 的骨架,即 HTTP 或超文本传输协议(HyperText Transfer Protocol)。它是由 Tim Berners-Lee 于 1991 年发明的。



Internet Protocol stack aka. OSI Model


HTTP 是请求-响应协议。客户端(例如 web 浏览器)发送一个请求给外部服务器。该外部服务器随后返回一个响应消息,例如,把谷歌的主页返回给客户端。这是位置寻址协议,这意味着,当在浏览器中键入 google.com 时,它被翻译成某个谷歌服务器的 IP 地址,接着,该服务器启动请求-响应周期。



How people talk on Internet

HTTP 的问题

假设你正坐在课堂上,教授要求你访问某个特定的网站。课堂上的每个学生都向该网站发出请求,并获得响应。这意味着,完全相同的数据被单独发送给课堂上的每个学生。如果有 100 个学生,那么就有 100 个请求和 100 个响应。很显示,这不是最有效的方法。理想的话,这些学生将能够利用他们的物理位置接近度以更有效地检索他们所需的信息。


如果网络通信线路有问题,那么 HTTP 也会出大问题,客户端就无法连接服务器。如果 ISP 发生中断、某个国家屏蔽了某些内容,或者,如果内容只是被删除了或移走了,都会发生这样的事情。在 HTTP web 上到处都有这些类型的断连。


HTTP 基于位置的寻址模型鼓励集中化。这便于信任少数拥有我们全部数据的应用程序,但是,因为这个原因,在 web 上的大量数据被浪费了。这也使得这些供应商对我们的信息负有巨大的责任以及拥有巨大的权力(比如脸书)。


HTTP 非常适合加载网站,但是,它不是设计用来传输大量的数据(像音频和视频文件)。这些缺陷可能使得像 Napster(音乐共享软件)和 BitTorrent(电影及几乎任何东西的共享软件)这些文件共享系统的替代品出现并成功成为主流。


时间快进到 2018 年,按需高清视频流和大数据正变得无处不在;我们继续生产/消费越来越多的数据,同时开发越来越强大的计算机来处理它们。云计算中的重大进步有助于维持这种转变,但是,用于分发所有这些数据的基础设施基本没有变化。

解决方案

IPFS 最初是由 Juan Benet 努力构建的系统,该系统可以快速移动版本化科学数据。它是经过互联网技术(DHTsGit版本系统和Bittorrent)综合测试的综合体。它创造了允许交换 IPFS 对象的 P2P Swarm 。所有的 IPFS 对象形成了加密身份认证的数据结构(Merkle DAG),同时,该数据结构能够用于构建很多其他数据结构。或者,换句话说,就是:


“IPFS 是个分布式文件系统,它旨在用同一个文件系统来连接所有的计算设备。在某些方面,这和 Web 最初的目标类似,但是,IPFS 事实上更类似于一个交换 Git 对象的 Bittorrent Swarm。IPFS 能够成为互联网新的重要子系统。如果构建正确,它能够补充或取代 HTTP。它能够补充或取代更多东西。这听起来很疯狂。没错,它的确很疯狂。”【1】


IPFS 本质上是版本化的文件系统,能够接收文件并管理它们,也可以把它们存储在某个地方,然后随着时间的推移,跟踪它们的版本。IPFS 也记录了这些文件在网络中的移动方式,因此,它也是个分布式文件系统。


IPFS 有管理数据和内容在网络上移动方式的规则,本质上和 Bittorrent 类似。该文件系统层提供了非常有趣的属性,如:


  • 网站是完全分布式的。

  • 网站没有源服务器。

  • 网站可以完全在客户端的浏览器上运行。

  • 网站不必和任何服务器有联系。


我们来看看这些不同的技术突破是如何协同工作的。

分布式哈希表(Distributed Hash Tables)

哈希表是一种数据结构,它以键/值对来存储信息。在分布式哈希表(distributed hash tables,简称 DHT)中,数据分布在计算机网络中,以便有效地协调以实现节点之间的有效访问和查找。


DHT 的主要优点在于去中心化、容错和可扩展性。节点无需中心协调,系统能够可靠地运作,即使节点发生故障或下线,并且,DHT 能够扩展以容纳数百万个节点。基于这些特性,使得 Swarm 比客户端-服务器结构更具有弹性。

区块交换(Block Exchanges)

流行的文件共享系统 Bittorrent 能够成功地协调数百万节点之间的数据传输,这是通过依靠创新的数据交换协议完成的,但是,这只限于种子生态系统。IPFS 实现了该协议的通用版本,称为 BitSwap,作为任意类型的数据市场来运营。该市场是Filecoin的基础,Filecoin 是构建于 IPFS 之上的 p2p 存储市场。

Merkle DAG

Merkle DAG 是Merkle树和有向无环图(Directed Acyclic Graph,简称DAG)的混合体。Merkle 树确保在 p2p 网络上交换的数据块是正确的、没有受到损害的和未被修改的。这个验证是利用加密哈希函数数据块来完成的。这只是一个函数,接收输入,计算出与输入相应的一个独一无二的字母数字字符串(哈希)。对于给定的哈希值,容易检查输入是否能得出同样的值,但是,难以从哈希值推算出输入。


单独的数据块被称为“叶节点”,它们被哈希后,形成“非叶节点”。这些非叶节点然后能够组合在一起进行哈希,直到所有的数据块可以用单独一个根哈希值表示。这是更简单的概念化方法:



Tree vs Merkle Tree


DAG 是一种无周期拓扑序列信息建模的方法。DAG 的一个简单例子就是家族树。Merkle DAG 基本上是个数据结构,其中哈希被用来在 DAG 中引用数据块和对象。这创造了一些有用的功能:IPFS 上的所有内容能够被唯一地标识,因为每个数据块有独一无二的哈希值。此外,数据是防篡改的,因为数据的更改会改变哈希值,如下图所示:



Un-tamperable nature of Merkle tree


IPFS 的核心原则是对生成的 Merkle DAG 上的所有数据建模。这种安全功能的重要性简直难以用言语来形容。打个比方吧,该原则可以保护价值数万亿美元的资产,可见该想法有多么强大了吧。

版本控制系统

Merkle DAG 结构的另一个强大的功能是,它允许构建分布式版本控制系统(version control system,简称VCS)。其典型的一个例子是 GitHub,它允许开发人员轻松地同时协作项目。GitHub 上的文件利用 Merkle DAG 存储和版本化。它允许用户独立复制和编辑一个文件的多个版本,并进行存储,稍后可以把编辑过的版本和原始文件合并。


IPFS 对数据对象使用类似的模型:只要对应于原始数据的对象和任何新版本都可以访问时,就可以检索整个文件历史。鉴于数据块通过网络进行本地存储,并可以无限期缓存,这意味着,IPFS 对象能永久存储。


此外,IPFS 不依赖于对互联网协议的访问。数据可以分布在覆盖网络中,覆盖网络只是构建在另一个网络上的网络。这些功能值得注意,因为它们是抗审查网络的核心要素。它可以成为促进自由言论以对抗全球互联网审查普及制度的工具,但是,我们也应该认识到不良行为者滥用言论的可能性。

自证明的文件系统

我们将要介绍的 IPFS 的最后一个重要组成部分是自证明文件系统(Self-certifying File System,简称SFS)。它是分布式文件系统,无需请求特殊权限进行数据交换。它是“自证明”的,因为提供给客户端的数据是通过文件名来进行身份验证的。结果就是能够利用本地存储的透明度安全地访问远程内容。


IPFS 以此概念为基础,创建了星际命名空间(InterPlanetary Name Space,简称 IPNS)。它是个 SFS,使用公钥加密以自证明通过网络用户发布的对象。我们之前提到,IPFS 上的所有对象可以唯一标识,但是,这也扩展到节点。网络上的每个节点有一套公钥、私钥和节点 ID,节点 ID 是其公钥的哈希值。因此,节点可以使用它们的私钥来“签署”它们发布的任何数据对象,并利用发件人的公钥来验证该数据的真实性。


以下是对关键 IPFS 组成部分的快速回顾:


  • 通过分布式哈希表,节点可以存储和共享数据,而无需中央协调

  • IPNS 允许交换的数据立即进行预验证,并使用公钥密码进行验证。

  • Merkle DAG 可实现唯一标识、防篡改和永久存储的数据


可以通过 ConsenSys 写的文章来查看网络中文件是如何被分发的更多细节(深入了解一下)。另外,还可以查看一下 IPFS 的白皮书


注意事项:


  • 始终对敏感内容进行加密!对加密的内容,上传的数据是“受保护的”,也即,只有知道对根哈希值(文件的根哈希值和加密密钥)引用的人才能访问内容。

  • IPFS 是持久性数据结构,因此,IPFS 中没有删除或移除操作的概念。这是因为内容被传播到受激励而服务于它的节点。

  • 无法保证上传的数据在网络上持久地存在。所有参与节点应该被视为没有正式义务的志愿服务,并且可以按照它们的意愿删除内容。因此,直到任何激励系统(Filecoin)正常运行之前,用户不应该在任何情况下,把 IPFS 视为安全存储。


IPFS Reddit | IPFS Twitter | IPFS Github

小结

本文是《未来的互联网存储:5 大区块链存储平台深入比较》之《上》篇,介绍的是分布式存储平台 Swarm 和 IPFS。文中详细解读了 Swarm 的主要目标,并对所涉及的公共网关、上传和下载数据、内容解析器 ENS、可变资源更新、Swarms 上的加密、pss 的基础知识和隐私功能、架构及示例 DApp 进行了深入的研究,提供了相应的资源链接。IPFS 实质上版本化,文中除了介绍 IPFS 的目的之外,还通过 HTTP 的问题,引出了解决方案,如分布式哈希表、区块交换、Merkle DAG。版本控制系统是 IPFS 的一个重要组成部分,在文中也做了详细的介绍。


《未来的互联网存储:5 大区块链存储平台深入比较》还有《中》及《下》篇,将分别为大家介绍 Sia 和 Storj 及 MaidSafe。敬请读者们期待。谢谢。


作者简介: Vaibhav SainiTowardsBlockchain的联合创始人,TowardsBlockchain 是麻省理工剑桥创新中心孵化的初创公司。他是一位高级区块链开发人员,参与多个区块链平台的工作,其中包括:以太坊、Quorum、EOS、Nano、Hashgraph 以及 IOTA 等等。


阅读英文原文StoragePedia: An Encyclopedia of 5 Blockchain Storage Platforms


2018-12-14 17:084056
用户头像

发布了 199 篇内容, 共 85.1 次阅读, 收获喜欢 295 次。

关注

评论 1 条评论

发布
暂无评论
发现更多内容

JVM类加载你真的【了解】了吗(1),网易的朋友给我这份339页的Java面经

Java 程序员 后端

Kafka 的 replica 同步机制(ISR与OSR列表数据相互转换)

Java 程序员 后端

Kafka-探险---生产者源码分析---核心组件,Java数据库题目大全

Java 程序员 后端

Kubernetes 常用命令大全,linux入门经典书籍

Java 程序员 后端

JVM的YGC,这次被它搞惨了!,rabbitmq实战指南pdf最新版

Java 程序员 后端

JVM类加载你真的【了解】了吗,java项目面试题

Java 程序员 后端

JVM性能优化(三)G1垃圾收集器(1),java原理书籍

Java 程序员 后端

JVM性能优化(三)G1垃圾收集器,附大厂真题面经

Java 程序员 后端

JVM性能优化(四)提高网站访问性能之Tomcat优化,java程序开发实用教程邱加永答案

Java 程序员 后端

kubebuilder实战之八:知识点小记,java面试具体场景的解决方案

Java 程序员 后端

JPA基本使用,Java虚拟机学习集锦是我攒来的

Java 程序员 后端

JVM 内存模型,百度笔试题百度校招面试经验

Java 程序员 后端

krpano全景之内置函数---asyncloop roundval 等(不定期更新)

Java 程序员 后端

kubebuilder实战之三:基础知识速览,Java学习的三个终极问题及学习路线规划

Java 程序员 后端

JWT单点登录,小甲鱼数据结构百度云

Java 程序员 后端

kafka扫盲——别等面试官一问三不知了,linux操作系统教程

Java 程序员 后端

Kafka的生产者原理及重要参数说明,Java码农是如何进入腾讯的

Java 程序员 后端

kotlin 如何解决 java 开发痛点,让程序员 happier,java中级程序员面试

Java 程序员 后端

Kubernetes 稳定性保障手册 -- 可观测性专题,今晚我们通宵学习SpringCloud

Java 程序员 后端

JVM--运行时数据区与内存模型,java开发基础知识点

Java 程序员 后端

jvm运行时内存是怎么分布的?,java多线程编程技术第二版下载

Java 程序员 后端

Kubernetes官方java客户端之七:patch操作,深入浅出Java

Java 程序员 后端

Kubernetes官方java客户端之八:fluent style,mysql入门视频教程

Java 程序员 后端

JSP、EL表达式、JSTL标签,rabbitmq源码分析持久化

Java 程序员 后端

JVM总体概述,java高级编程内容

Java 程序员 后端

JSP 标准标签库(JSTL),javaee教程视频

Java 程序员 后端

JVM探究:全面解析OOM异常,都在这了,mysql数据库基础与实例教程孔祥盛

Java 程序员 后端

kubernetes下的jenkins如何设置maven,java异步请求原理

Java 程序员 后端

Kubernetes教程之新手安装必看(快速浏览少走弯路),java集合详解和集合面试题目

Java 程序员 后端

JNI开发之方法签名与Java通信(二),mongodb入门篇

Java 程序员 后端

Json的FastJson与Jackson,java阻塞队列原理

Java 程序员 后端

未来的互联网存储:5大分布式存储平台深入比较(上)_区块链_Vasa_InfoQ精选文章