ARTS-WEEK-011

Algorithm：

538: Convert BST to Greater Tree (Easy)

利用BST的中序遍历可以排序这一特性，在遍历时先右后左就可以实现逆序，再累加即可。

    int sum = 0;
    public TreeNode convertBST(TreeNode root) {
        if (root == null) return null;
        convertBST(root.right);
        sum += root.val;
        root.val = sum;
        convertBST(root.left);
        return root;
    }

Review：

LIquid: The soul of a new graph database, Part 1

这篇文章是关于 LinkedIn 新一代内部图数据库 LIquid 介绍之一，首先是需求场景，基于用户二度网络的经济价值分析，也就是你已经认识的人，和他们再认识人，一般这样的二度网络会包含至少 5 万个实体（如不同人、学校或雇主），实际上每个人的下一份工作很可能都在其二度网络中。二度关系产生的连接非常庞大，可能达到数亿条边，每次写入都会产生放大效应（所有相关连接都会更新），而且搜索的过程也产生大量随机查找。

文章从一开始的面相对象模型开始举例，首先是两个对象相互持有对方引用集合，这是最简单的情况，但是作为硬编码缺少泛化和扩展性。随后的举例改进了其中的关系，抽象出关系对象，让实体对象持有关系对象，关系对象再持有实体对象，实体之间不直接引用。第三个例子继续改进，将一切实体抽象为 Identity 以及关于主谓宾的三元体，即 Edge 边对象，该模式扩展性最好（There’s no schema evolution problem because there’s only one schema），最后文章基于该模型给出了基于 graph_log 日志文件的实现举例，避免了传统数据库基于 MVCC 等 snapshot 机制在该场景下的性能问题，利用 log offset 思想的过程有些 Kafka 的影子，感觉 LinkedIn 还真是对 log file 情有独钟。

Tip：

信封加密 envelope encryption

在分布式系统中如何对数据进行加解密？这里主要指对称加密，首先一个原则是不要把密钥发送给客户端，而是统一进行管理，即统一的 KMS - Key Management Service，避免密钥泄露造成所有数据风险。

在这种情况下，一种方法是将数据发送到KMS，加密完成后返回密文存储，这种方法仅适用于少量数据情况，并且要求传输信道安全，即便如此也存在数据搬移和信任问题。另一种办法就是信封加密，核心思想是通过两次加密，封装和移动动态数据密钥。主要概念有：DEK - Data Encryption Keys 和 KEK - Key Encryption Keys。

首先准备阶段，客户端在 KMS 申请并生成属于自己的 KEK，它保存在 KMS 中永不向外传输。

其次在加密阶段，客户端本地动态生成 DEK，对要加密的原文数据进行对称加密，同时发送请求到 KMS，使用 KEK 加密 DEK，并将返回的 Wrapped DEK（即封装过的、加密过的 DEK）和密文数据就近保存，然后销毁明文 DEK。

最后在解密阶段，客户端对要解密数据找到对应 Wrapped DEK，将其发送的 KMS 请求解密，获取返回的明文 DEK 后，用它解密密文数据，获得数据原文。

可以看出，1、KEK 始终在KMS中保存，泄漏风险低，2、由于没有明文 DEK存储，被加密的数据即使直接泄漏也无法被解密，3、如果在请求和传输中泄漏了 DEK，也只影响少量数据安全性，因为 DEK 不停动态生成，4、该方案更适合静态大量数据加解密（data at rest），如果需要频繁请求KMS，则存在吞吐量问题，可以通过缓存减少 DEK 生成速度（比如1小时生成一次 DEK，本地缓存对应 Wrapped DEK）提高加密吞吐量，解密时也类似（缓存明文DEK，未命中时再请求 KMS），这其实是牺牲一定安全性换取吞吐量。

与关注传输过程安全性的 https 不同，信封加密关注静态数据加密存储，是分布式系统和密钥管理 KMS 范畴的技术。

envelope_encryption