leaf

前言 MongoDB是非关系型数据库的典型代表，DB-Engines Ranking 数据显示，近年来，MongoDB在 NoSQL领域一直独占鳌头。MongoDB是为快速开发互联网应用 而设计的数据库系统，其数据模型和持 久化策略就是为了构建高读/写的性能，并且可以方面的弹性拓展。随着MongoDB的普及和使用量的快 速增长，为了规范使用，便于管理和获取更高的性能，整理此文档。我们从 数据库设计规范、集合设计 规范、索引设计规范、文档设计规范、API使用规范、连接规范等方面进行阐述和要求。 存储选型 主要解决大量数据的访问效率问题， 减少mysql 压力。MongoDB内建了多种数据分片的特性，可 以很好的适应大数据量的需求。内建的Sharding分片特性避免系统在数据增长的过程中遇到性能 瓶颈。 复杂数据结构，以多种不同查询条件去查询同一份数据。MongoDB的BSON数据格式非常适合文 档化格式的存储及查询；支持丰富的查询表达式，可轻易查询文档中内嵌的对象和数组及子文档。 非事务并且关联性集合不强的都可以使用(MongoDB4.0+支持跨Collection事务，MongoDB4.2+支持跨Shard事务) 无多文档事务性需求及复杂关联检索 业务快速迭代，需求频繁变动业务 数据模型不固定，存储格式灵活场景 单集群读写并发过大无法支撑业务增长 期望 5 个 9

Miximus是一个用于以太坊区块链的去中心化混币器和匿名转账应用，由EthSnarks作者开发，用于展示零知识证明在以太坊上的实用性。本文介绍Miximus以太坊混币应用的安装使用方法、工作原理和实现细节。 用自己熟悉的语言学习以太坊DApp开发： Java | Php | Python | .Net / C# | Golang | Node.JS | Flutter / Dart 1、Miximus混币应用概述 利用Miximus混币应用，你可以存入1个ETH，然后利用zkSNARK证据证明你持有这个币的消费密钥，通过验证之后就可以提币了，整个过程保证了匿名性。 Miximus的主要源代码包括： Miximus.sol miximus.py test_miximus.py miximus.cpp zkSNARK证明方作为原生库构建，因此可以打包进你的应用，当提供正确的参数后，库会返回JSON格式的zkSNARK证据。你可能会认为zkSNARKs很慢 —— Miximus选择的算法生成证据的平均时间是5秒，不过我们还在研究其安全特征。 2、构建Miximus混币引用 如果在Linux上构建Miximus混币应用，需要先安装以下依赖软件： cmake 3 g++ or clang++ gmp libcrypto boost npm / nvm 在OSX上需要Brew和nvm：

分布式 ID 在庞大复杂的分布式系统中，通常需要对海量数据进行唯一标识，随着数据日渐增长，对数据分库分表以后需要有一个唯一 ID 来标识一条数据，而数据库的自增 ID 显然不能满足需求，此时就需要有一个能够生成全局唯一 ID 的系统，需要满足以下条件： 全局唯一性：最基本的要求就是不能出现重复的 ID。 递增：保证下一个 ID 一定大于上一个 ID。 信息安全：如果 ID 是连续的，用户就可以按照顺序进行恶意爬取数据，所以 ID 生成无规则。 上述的 2 和 3 点需求是互斥的，无法使用同一个方案满足。 解决方案 数据库生成 以 MySQL 为例，利用给字段设置 auto_increment_increment 和 auto_increment_offset 来实现 ID 自增。每次业务可以使用下列 SQL 进行读写得到 ID： begin; REPLACE INTO Tickets64 (stub) VALUES ('a'); SELECT LAST_INSERT_ID(); commit; 优点：使用非常简单，ID 单调递增。 缺点：非常依赖数据库，当数据库异常时则整个系统不可用。 UUID 优点：本地生成，没有网络消耗，性能高。 缺点：过长不易于存储；造成信息不安全，基于 MAC 地址生成可能会造成 MAC 地址泄露。 Snowflake Snowflake （雪花算法）是由

本文始发于个人公众号： TechFlow ，原创不易，求个关注 今天是 算法和数据结构专题 的第28篇文章，我们一起来聊聊一个经典的字符串处理数据结构——Trie。 在之前的4篇文章当中我们介绍了关于博弈论的一些算法，其中应用最广也是最重要的就是最后的SG函数。了解到这些之后，足够我们应付常见的博弈论算法问题了。博弈论本身就是一门学科，其中有这很深邃的理论基础，我们只是浅尝辄止，大家感兴趣的可以自行钻研一下，相信一定会很有收获。 小故事 以前读过一个大牛的文章，文章里讨论了一个问题， 如果不是为了面试的话，我们为什么要学算法 ？ 他讲了一个他自己的故事，说是在很多年前，手机还是诺基亚功能机的时代，他为塞班系统开发了一个通讯簿查找联系人的软件。软件的功能很简单，就是存储联系人，然后可以 通过拼音或者是拼音首字母查找 到对应的联系人。这里需要对汉字以及拼音的映射做一个处理，也不是很复杂的操作，我们脑补应该就可以想出来。 软件很快做好了，做好了之后投入使用发现也很好用。但是很快遇到了一个没想到的问题，就是当 联系人多了之后，软件的运行速度变得非常慢 ，也就是卡。卡的原因也很简单，因为搜索联系人的这个步骤他用的是遍历查找的方式搜索的。他一开始先是自己脑补了一些优化方案和野路子，虽然能有些提升但是不能根本解决问题。后来被逼无奈，他在搜索了相关资料之后，找到了我们今天的主角Trie

今天我们来拆解 Snowflake 算法，同时领略百度、美团、腾讯等大厂在全局唯一 ID 服务方面做的设计，接着根据具体需求设计一款全新的全局唯一 ID 生成算法。这还不够，我们会讨论到全局唯一 ID 服务的分布式 CAP 选择与性能瓶颈。 已经熟悉 Snowflake 的朋友可以先去看大厂的设计和权衡。 百度 UIDGenertor：https://github.com/baidu/uid-... 美团 Leaf：https://tech.meituan.com/2017... 腾讯 Seqsvr： https://www.infoq.cn/article/... 全局唯一 ID 是分布式系统和订单类业务系统中重要的基础设施。这里引用美团的描述： 在复杂分布式系统中，往往需要对大量的数据和消息进行唯一标识。如在美团点评的金融、支付、餐饮、酒店、猫眼电影等产品的系统中，数据日渐增长，对数据分库分表后需要有一个唯一 ID 来标识一条数据或消息，数据库的自增 ID 显然不能满足需求；特别一点的如订单、骑手、优惠券也都需要有唯一 ID 做标识。 这时候你可能会问：我还是不懂，为什么一定要全局唯一 ID？ 我再列举一个场景，在 MySQL 分库分表的条件下，MySQL 无法做到依次、顺序、交替地生成 ID，这时候要保证数据的顺序，全局唯一 ID 就是一个很好的选择。 在爬虫场景中

哈哈，今天整活上瘾了. 复习了一下最近两场周赛感觉能做出来但是实际没有做出来的题目 感觉有几点不足，希望以后可以逐渐改过来： 1. 基础知识不扎实，有时候会在细节上栽跟头 2. 有时候容易脑子一热，想到一部分就开始写，简单题还能处理，中等或困难就有点难搞了，太局部，不全面 3. 心态还是需要调整一下，不能提交没过就心里有点紧张~~ 希望今年内可以AK一次吧，哈哈，加油，废话不多，上题目。 199期 第三题 给你二叉树的根节点 root 和一个整数 distance 。 如果二叉树中两个 叶 节点之间的 最短路径长度 小于或者等于 distance ，那它们就可以构成一组 好叶子节点对 。 返回树中 好叶子节点对的数量 。 来源：力扣（LeetCode） 链接： https://leetcode-cn.com/problems/number-of-good-leaf-nodes-pairs 著作权归领扣网络所有。商业转载请联系官方授权，非商业转载请注明出处。 二狗把做题的一些感想和思路也写在注释里了，所以就直接上代码吧： ` using CSharpLeetCode.Common; namespace CSharpLeetCode.Core { /* 这道题是199次周赛的第三题,笔者当时没有做出来 记录一下 当时印象深刻的错误是如何去重。 考虑到需要递归的计算左右子树的好节点对

LightGBM LightGBM原理及实现 LigthGBM是boosting集合模型中的新进成员，它和xgboost一样是对GBDT的高效实现，很多方面会比xgboost表现的更为优秀。原理上它和GBDT及xgboot类似，都采用损失函数的负梯度作为当前决策树的残差近似值，去拟合新的决策树。 LightGBM vs xGBoost xgBoost算法的优点： XGB利用了二阶梯度来对节点进行划分，相对其他GBM来说，精度更高。 利用局部近似算法对分裂节点的贪心算法优化，取适当的eps时，可以保持算法的性能且提高算法的运算速度。 在损失函数中加入了L1/L2项，控制模型的复杂度，提高模型的鲁棒性。 提供并行计算能力，主要是在树节点求不同的候选的分裂点的Gain Infomation（分裂后，损失函数的差值） Tree Shrinkage，column subsampling等不同的处理细节。 xgBoost算法的缺点： 需要pre-sorted，这个会耗掉很多的内存空间（2 * #data * # features） 数据分割点上，由于XGB对不同的数据特征使用pre-sorted算法而不同特征其排序顺序是不同的，所以分裂时需要对每个特征单独做依次分割，遍历次数为#data * #features来将数据分裂到左右子节点上。 尽管使用了局部近似计算，但是处理粒度还是太细了

分布式 ID 在庞大复杂的分布式系统中，通常需要对海量数据进行唯一标识，随着数据日渐增长，对数据分库分表以后需要有一个唯一 ID 来标识一条数据，而数据库的自增 ID 显然不能满足需求，此时就需要有一个能够生成全局唯一 ID 的系统，需要满足以下条件： 全局唯一性：最基本的要求就是不能出现重复的 ID。 递增：保证下一个 ID 一定大于上一个 ID。 信息安全：如果 ID 是连续的，用户就可以按照顺序进行恶意爬取数据，所以 ID 生成无规则。 上述的 2 和 3 点需求是互斥的，无法使用同一个方案满足。 解决方案 数据库生成 以 MySQL 为例，利用给字段设置 auto_increment_increment 和 auto_increment_offset 来实现 ID 自增。每次业务可以使用下列 SQL 进行读写得到 ID： begin; REPLACE INTO Tickets64 (stub) VALUES ('a'); SELECT LAST_INSERT_ID(); commit; 优点：使用非常简单，ID 单调递增。 缺点：非常依赖数据库，当数据库异常时则整个系统不可用。 UUID 优点：本地生成，没有网络消耗，性能高。 缺点：过长不易于存储；造成信息不安全，基于 MAC 地址生成可能会造成 MAC 地址泄露。 Snowflake Snowflake （雪花算法）是由

自己动手写SQL执行引擎 前言 在阅读了大量关于数据库的资料后，笔者情不自禁产生了一个造数据库轮子的想法。来验证一下自己对于数据库底层原理的掌握是否牢靠。在笔者的github中给这个database起名为Freedom。 整体结构 既然造轮子，那当然得从前端的网络协议交互到后端的文件存储全部给撸一遍。下面是Freedom实现的整体结构，里面包含了实现的大致模块: 最终存储结构当然是使用经典的B+树结构。当然在B+树和文件系统block块之间的转换则通过Buffer(Page) Manager来进行。当然了，为了完成事务，还必须要用WAL协议，其通过Log Manager来操作。 Freedom采用的是索引组织表，通过DruidSQL Parse来将sql翻译为对应的索引操作符进而进行对应的语义操作。 MySQL Protocol结构 client/server之间的交互采用的是MySQL协议，这样很容易就可以和mysql client以及jdbc进行交互了。 query packet mysql通过3byte的定长包头去进行分包，进而解决tcp流的读取问题。再通过一个sequenceId来再应用层判断packet是否连续。 result set packet mysql协议部分最复杂的内容是其对于result set的读取，在NIO的方式下加重了复杂性。

一、基本概念 合成模式属于对象的结构模式，有时又叫做“部分——整体”模式。合成模式将对象组织到树结构中，可以用来描述整体与部分的关系。合成模式可以使客户端将单纯元素与复合元素同等看待。 二、通俗解释 COMPOSITE合成模式：Mary今天过生日。“我过生日，你要送我一件礼物。”“嗯，好吧，去商店，你自己挑。”“这件T恤挺漂亮，买，这条裙子好看，买，这个包也不错，买。”“喂，买了三件了呀，我只答应送一件礼物的哦。”“什么呀，T恤加裙子加包包，正好配成一套呀，小姐，麻烦你包起来。”“……”，MM都会用Composite模式了，你会了没有？ 合成模式：合成模式将对象组织到树结构中，可以用来描述整体与部分的关系。合成模式就是一个处理对象的树结构的模式。合成模式把部分与整体的关系用树结构表示出来。合成模式使得客户端把一个个单独的成分对象和由他们复合而成的合成对象同等看待。 文件系统例子： 合成模式把部分和整体的关系用树结构表示出来。合成模式使得客户端把一个个单独的成分对象和由它们复合而成的合成对象同等看待。比如，一个文件系统就是一个典型的合成模式系统。下图是常见的计算机XP文件系统的一部分。 从上图可以看出，文件系统是一个树结构，树上长有节点。树的节点有两种，一种是树枝节点，即目录，有内部树结构，在图中涂有颜色；另一种是文件，即树叶节点，没有内部树结构。 显然