在现有的互联网公司业务场景中,不管前端跟用户交互的方式是浏览器网站、手机软件还是电脑软件,本质上用户看到的所有信息都来自于数据库,用户的增、删、改、查所有行为也最终都是在与服务提供商的数据库通信。我每天使用手机里的 APP 都会在想,如果某个 APP 后台数据库故障,数据丢失,或者被人恶意篡改。我当如何?是否有解决方案呢?
方案 A :
假如我们有一个分布式的数据库 X,它不受任何个人、组织控制,每个人都可以搭建自己的节点,节点的数据始终保持同步,且都拥有新增、修改、删除的权限,所有数据修改记录完全公开透明可追溯。
A、B、C 三个团队准备将自己的数据存储于 X,分别搭建了自己的节点,由于不信任其他节点的 RPC 接口,所以分别开发了自己的 RPC API 给前端使用,用户可以通过三个团队任意的接口修改自己的数据。假设用户 Alice 的账户余额为 100 元,同时执行了以下三个操作:
以上 3 条数据修改操作被同时同步到分布式数据库网络中,其他节点到底以谁的记录为准呢?
从上面的示例可以看出,如果分布式数据库的每一个节点都有增加、删除、修改的权限,那数据会乱套,我们需要避免这种情况,是否可以让分布式数据库中只有一个节点拥有修改数据的权限?显然不行,又回到了老路上,太过于中心化。是否可以随机让某一个节点拥有修改数据的权限?我们来尝试下。
方案 B1 :
在方案 A 的基础上,我们做出以下调整:
Hash 值是由数字和大小写字母构成的字符串,每一位有 62 种可能性(可能为 26 个大写字母、26 个小写字母,10 个数字中任一个),假设任何一个字符出现的概率是均等的,那么第一位为 0 的概率是 1/62 (其他位出现什么字符先不管),理论上需要尝试 62 次 Hash 运算才会出现一次第一位为 0 的情况,如果前两 2 位为 0,就得尝试 62 的平方次 Hash 运算,以 n 个 0 开头就需要尝试 62 的 n 次方次运算。假如 Hash 值以 18 个 0 开头,理论上需要尝试 62 的 18 次方次,这个数是非常巨大的。
方案 B2 :
在方案 A 的基础上,我们做出以下调整:
以上两个方案 B1、B2 分别代表了 PoW、DPoS 两种共识机制,可以很好的解决随机选出某一节点执行入库操作的问题。如果 Alice 发送上述的 3 条交易,仅有交易 1 会被执行,交易 2、3 由于余额不足将被拒绝执行。
某一天,团队 D、E 团队决定一起加入分布式数据库 X,准备搭建节点开始同步数据,由于数据量实在太大,预计需要 1 天的时候才能同步完所有的数据操作记录,这个时候 Alice 又来了,她通过团队 D 的接口向用户 Bob4 转出了 100 元,由于新加入的 2 个节点数据未同步完,没有之前 Alice 向账户 Bob1 的转账记录,所以 Alice 的账户余额是 100 元,节点 E 认可这笔交易的合法性,因此这笔交易转账成功。
在这个时候分布式数据库 X 已经出问题了,节点 A、B、C 的数据显示,Alice 向 Bob1 转出 70 元。节点 D、E 的数据显示,Alice 向 Bob4 转出 100 元。如何避免这种情况?是否可以让所有节点都处在同一个时间线上?
方案 C :
在方案 B1 / B2 的基础上,我们做出以下调整:
经过以上调整,新节点 D、E 认可的 Alice 转账交易打包进区块以后,由于跟新接收到的区块数据不一致,导致最终该交易被拒绝执行。
到这里一个简单的分布式数据库完成了,因为其数据结构是一个一个区块串联在一起,一旦某一个区块被篡改,其 Hash 值将会变更,后面所有的区块都有问题,因此称之为区块链。
下一期将会聊一聊区块链里面的密码学知识。
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.