leveldb

Merkle树是一种可以有效验证部分数据存在于指定数据集并且未被篡改的高效的哈希树结构，作为一种底层技术广泛应用在各种区块链的实现当中，对于商品溯源、知识产权确认、区块链公证等区块链应用起着重要的作用。本文介绍11个主流的merkle树开源实现，你可以在自己的项目中应用。 区块链开发教程链接： 以太坊 | 比特币 | EOS | Tendermint | Hyperledger Fabric | Omni/USDT | Ripple 1、ethereumjs/merkle-patricia-tree - 以太坊官方merkle树实现 merkle-patricia-tree是以太坊黄皮书中的改进merkle patricia树的实现。目前仅支持leveldb作为存储后端。 开发语言：TypeScript/JavaScript 源码下载： https://github.com/ethereumjs/merkle-patricia-tree 2、google/Trillian - 大规模可验证数据存储 Trillian是google提供的一个透明的、高度可伸缩的密码学可验证数据存储库，它采用MySQL或MariaDB作为后端存储层，可以支持非常大规模的merkle树。Trillian通过gRPC提供服务接口。 开发语言：Golang 源码下载： https://github.com

一、activeMQ高可用 1、事物 2、签收 3、持久 4、可持久化 二、持久化机制 为了避免意外宕机以后丢失信息，需要做到重启后可以恢复消息队列，消息系统一般都会采用持久化机制 ActiveMQ持久化机制有：JDBC、AMQ、KahaDB和LevelDB，无论哪种持久化方式，消息的存储逻辑都是一致的。 就是在发送者将消息发送出去后，消息中心首先将消息存储到本地数据文件、内存数据库或者远程数据库等再试图将消息发送给接收者，成功则将消息从内存中删除，失败则继续尝试发送。 消息中心启动后首先要检查指定位置，如果有未发送成功的消息，则需要把消息发送出去。 三、消息持久化机制有哪些 1、AMQ Message Store : 基于文件存储方式，以前默认的消息存储方式，现在基本不用。AMQ是一种文件存储形式，它具有写入速度快和容易恢复的特点。消息存储在一个一个文件当中，文件默认大小为32M，当一个存储文件被全部消费，那么这个文件会被标识为可删除，在下一个清除阶段被删除 2、KahaDB消息存储： 基于日志文件，从5.4版本之后开始默认支持持久化插件，可适用于任何场景，提高了性能和恢复能力。消息存储使用一个事务日志和仅用一个索引文件来存储他所有的地址。KahaDB是一个专门针对消息持久化的解决方案，他对典型的消息使用模式进行优化。数据被追加到data logs中。当不在需要log文件中数据时

package main import ( "fmt" "github.com/syndtr/goleveldb/leveldb/util" "github.com/syndtr/goleveldb/leveldb" ) func main(){ fmt.Println("hello") // 创建或打开一个数据库 db,err := leveldb.OpenFile("F:\\work\\testdb\\db", nil) if err != nil { panic(err) } defer db.Close() // 存入数据 db.Put([]byte("1"), []byte("6"), nil) db.Put([]byte("2"), []byte("7"), nil) db.Put([]byte("3"), []byte("8"), nil) db.Put([]byte("foo-4"), []byte("9"), nil) db.Put([]byte("5"), []byte("10"), nil) db.Put([]byte("6"), []byte("11"), nil) db.Put([]byte("moo-7"), []byte("12"), nil) db.Put([]byte("8"), []byte("13"), nil) // 遍历数据库内容 iter

分布式技术的发展，深刻地改变了我们编程的模式和思考软件的模式。值 2019 岁末，PingCAP 联合 InfoQ 共同策划出品“分布式系统前沿技术 ”专题， 邀请众多技术团队共同参与，一起探索这个古老领域的新生机。本文出自 UCloud 后台研发工程师邓瑾。 为了应对 IO 性能要求很高的数据分析、AI 训练、高性能站点等场景，UFS 团队又推出了一款基于 NVMe SSD 介质的性能型 UFS，以满足高 IO 场景下业务对共享存储的需求。性能型 UFS 的 4K 随机写的延迟能保持在 10ms 以下，4K 随机读延迟在 5ms 以下。 性能的提升不仅仅是因为存储介质的升级，更有架构层面的改进，本文将从协议、索引、存储设计等几方面来详细介绍性能型 UFS 升级改造的技术细节。 协议改进 此前容量型 UFS 设计时支持的协议为 NFSv3，其设计理念是接口无状态，故障恢复的逻辑简单。此外 NFSv3 在 Linux 和 Windows 上被广泛支持，更易于跨平台使用。但是 NFSv3 的设计缺点导致的高延迟在高 IO 场景下是不可接受的，所以在性能型 UFS 中，我们选择仅支持性能更好、设计更先进的 NFSv4 协议。 NFSv4 与 NFSv3 相比，更先进的特性包括：支持有状态的 lock 语义、多协议间的 compound 机制等。特别是 compound 机制，可以让多次

GIT 支持子模块，所谓 GIT 子模块，即某个项目需要管理的模块数目太多，而各个模块需要不同的人或团队维护，此时就需要在GIT中引入子模块。GIT 引入子模块后，其本身的上游代码提交历史依然可以保存下来，并且避免了在上游代码发生变更时本地的定制代码归并（Merge）困难。 新建带子模块的项目 PyDemo 我们举一个简单的例子说明上述问题：假设你开发了一个项目 PyDemo，PyDemo 项目中使用了Leveldb 的 Python 绑定 cpy-leveldb( https://github.com/forhappy/cpy-leveldb )，但是需要在定制 cpy-leveldb 的功能，此时你就需要在PyDemo 项目中新建一个子模块 cpy-leveldb，然后修改本地 cpy-leveldb的实现，此时 PyDemo 把它视作一个子模块，当你不在 cpy-leveldb 目录里时并不记录它的内容，取而代之的是，Git 将它记录成来自那个仓库的一个特殊的提交。当你在那个子目录里修改并提交时，子项目会通知那里的 HEAD 已经发生变更并记录你当前正在工作的那个提交 代码如下： forhappy@forhappy-lenovo:/tmp$ mkdir PyDemo forhappy@forhappy-lenovo:/tmp$ cd PyDemo/ forhappy

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 起因 ledisdb 是一个参考ssdb，采用go实现，底层基于leveldb，类似redis的高性能nosql数据库，提供了kv，list，hash以及zset数据结构的支持。 我们现在的应用极大的依赖redis，但随着我们用户量越来越大，redis的内存越来越不够用，并且replication可能还会导致超时问题。虽然后续我们可以通过添加多台机器来解决，但是在现有机器配置下面，我们仍希望单台机器承载更多的用户。另外，因为业务的特性，我们其实并不需要将所有的数据放到内存，只需要存放当前活跃用户。 经过我们的调研，发现ssdb已经很好的帮我们解决了这个问题，它提供了跟redis一致的接口（当然有些地方还是稍微不同），但是底层采用leveldb进行存储。根据其官网的描述，性能已经接近甚至超越了redis。 本着 造轮子 的精神，我决定用go实现一个类似的db，取名为ledisdb，也就是 level-redis-db ，为啥不用现成的ssdb，我觉得有如下几个原因： go语言开发的快速，这点毋庸置疑，虽然性能上面铁定离c++的代码有差距，但是我能够快速的进行原型搭建并实验。实际上，我在很短的时间里面就开发出了ledisdb，让我后续继续开发有了信心。 leveldb的研究

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 1 悲剧直播推送功能 1.1 B站直播推送功能的困境 B站直播有个推送功能，就是这里，看到那个红色的数字没有，显示你关注的主播开播人数。 然后每个进入B站的用户，不管是不是直播的观众、不管进入B站哪个页面、不管你要干啥，都要请求一次这个人数接口，直播服务表示：妈逼，就给老子几台土豆服务器，却要扛着跟主站一样PV， 不仅仅是主站在使用这个功能，还有直播服务内部的各种推送心跳同样在使用这个功能，流量很大。 由于主站、直播对于UP主和主播关注是混在一起的，所以每次直播这边都要从一堆用户关注UP主中找到直播的主播，并且还要找到那个主播在直播，老的做法就是从缓存读各种数据，然后遍历，计算，然后输出，对缓存服务器、PHP服务器都造成了极大的压力，然后遇到大的活动，服务器分分钟都是：老子不想干了的节奏。然后大的活动每次都会把推送能关掉，来保证活动正常进行。 1.2 穷则思变的重构 你们以为大佬们一开始就同意我的Golang重构方案吗？你们啊 我苦口婆心的跟大佬们诉说我的方案是多么适合这个业务，然后我Golang技术有多好（无耻笑）、多靠谱，加上在弹幕服务器部门做了一段时间Golang的兼职（没错，是我舔着脸要去的），做了些大流量的功能，他们终于同意了，呵呵，是时候展示真正的技术了（请脑补小黄毛EZ配音）。 1.3

本文大多转载自 http://blog.csdn.net/guoyk1990/article/details/52909864，加入部分自己实战心得。 1、环境：windows 7\VS2013 2、caffe-windows准备 (1) 下载官方caffe-windows 并解压，将 .\windows\CommonSettings.props.example备份，并改名为CommonSettings.props。如图4所示： 图 4：修改后的CommonSettings.props文件 附带说明，现在最新版的github已经更新，没有上述文件，根据大佬说法用cmake编译后能产生sln文件，笔者不才，并不会，这里提供百度云盘的老版本： caffe提供Windows工具包(caffe-windows)：https://github.com/BVLC/caffe/tree/windows 百度云下载地址：链接：http://pan.baidu.com/s/1bp1BFH1 密码：phf3 (2)关于CommonSettings.props文件的一点说明。 [html] view plain copy </ pre > < pre name= "code" class= "html" > <? xml version= "1.0" encoding= "utf-8" ?> <