leveldb

如何快速获得高并发编程经验？PCC性能挑战赛作品简介及源代码 PCC 是 Performance Challenge Championship （性能挑战杯）的缩写，是高可用架构后花园会员在线上组织的一个活动，由于反响热烈，考虑到线下进行可以更好的加深对高并发编程的理解，于是高可用架构在 3 月组织了本次 PCC 活动。 对于工程师来说，参加 PCC 编程挑战赛的部分意义： 体验完成一个技术小目标。高性能系统如何实现应当是每个工程师需要走的路。 学习优秀的架构方法，隔壁老王用的设计思想，可能你坐在办公室永远也无法想到。 有经验评委的点评，了解真实环境的高并发系统的追求目标。 类似主题、有同样级别参赛队员及评委参加的编程活动，可能仅此一次。 比赛方法说明 实现类似 facebook 中的 like 功能，需要： 可以对一个对象（一条feed、文章、或者url）进行 like 操作，禁止 like 两次，第二次 like 返回错误码 有 isLike 接口，返回参数指定的对象有没有被当前用户 like 过 需要看到一个对象的 like 计数 可以看到一个对象的 like 用户列表（类似 QQ 空间）； 上述列表加分项：Like优先显示我的好友列表(social list)。 数据量：每天新增的 like 对象数为 1 千万，每秒 like 计数器查询量为 30 万次 / 秒。 比赛盛况

Table of Contents 什么是架构？ 为什么需要进行架构设计？ 如何设计架构？ 如何了解一个系统的架构？ 什么是架构？ 架构是系统的顶层结构！ 顶层 意味着 架构 的粒度到当前系统的子系统或者子模块为止！ 为什么需要进行架构设计？ 可以采用逆向思维的办法 隔离关注点，降低复杂度 可以分工合作 如何设计架构？ 采用面向对象的方法，我们知道在面向对象程序设计中 程序 = 对象 + 交互 那么同样的公式表达架构也是一样的： 架构 = 模块 + 交互 如何了解一个系统的架构？ 知道了如何设计一个架构，那么如果想了解一个系统的架构，就 先了解这个系统有哪些模块，然后去了解这些模块间是怎么交互的 ，那么了解一个系统的时候就不会像无头苍蝇，陷入到其中的细节当中去。 比如最近看levelDB的源码，不需要陷入到代码细节里去，先去把其中的模块找出来，然后去代码里看这些模块是怎么交互的 ！ 参考: 《面向对象葵花宝典》 来源： oschina 链接： https://my.oschina.net/u/4373067/blog/4533174

武培轩 推荐搜索 MySQLRedisElasticsearchJavaSpring Boot数据结构 所有数据库管理系统的主要工作都是「可靠地存储数据」并使其对用户可用。我们使用数据库作为数据的主要来源，帮助我们在应用程序的不同部分之间共享数据。我们使用数据库，而不是在每次创建新应用程序时寻找存储和检索信息的方法，也不是每次都去发明一种组织数据的新方法。这样一来，我们就可以专注于应用程序逻辑而不是基础设施。 数据库是模块化的系统，由多个部分组成：接受请求的传输层、决定以最高效方式运行查询的查询处理器、执行操作的执行引擎以及存储引擎。 存储引擎（或数据库引擎）是数据库的一个软件组件，它负责在内存和磁盘上存储、检索和管理数据，而设计它的目的是长久保存每个节点的数据[REED78]。数据库可以响应复杂的查询，存储引擎则会更细粒度地看待数据并提供一组简单的数据操作API，允许用户创建、更新、删除和检索数据记录。从某个角度来看，数据库是构建在存储引擎之上的应用程序，它提供了表结构（schema）、查询语言、索引、事务和许多其他有用的特性。 为了获得灵活性，键和值都可以是没有预设格式的任意字节序列。它们的排序和表示语义是在更高级别的子系统中定义的。例如，你可以在一个表中使用int32（32位整数）作为键，而在另一个表中使用ascii（ASCII字符串）；从存储引擎的角度来看

目录 跳表 使用场景 结构描述 查询算法 插入算法 删除算法 时间复杂度 空间复杂度 总结 Redis使用跳表而不是红黑树？ 跳表 使用场景 跳表(Skiplist ）是一个特殊的链表，相比一般的链表，有更高的查找效率，可比拟二叉查找树， 平均期望的查找、插入、删除 时间复杂度都是O(log n) ，许多知名的开源软件（库）中的数据 结构均采用了跳表这种数据结构∶ Redis中的有序集合zset LevelDB、RocksDB、HBase中Memtable Apache Lucene中的Term Dictionary、Posting List 结构描述 我们拿我们以前的有序链表相比： 我们可以很清楚的看出，有序链表的查询比较慢，时间复杂度为O(n)，它的删除和插入操作比较快，我们怎样才能让它的查询的时间复杂度也变快呢？ 能不能将我们的链表实现二分的查找，也就是longN，答案是肯定的，也就是我们下面所说的这种跳表。 查询算法 跳表的查询和我之前做过的一道题特别类似， 二维数组的查找 假设我们查询 31 这个数字 我们的header开始，依次进行查询， 31不在负无穷到17，往右边，到达17，继续比较，在17到正无穷之间，往下跑 … 整个查询过程如下所示 插入算法 对于插入来说，我们比如要插入一个21的数值 类似查询算法，到达17这个点，进一步到达20这个点，然后在20的后面进行插入

Log-Structured Merge-Tree，简称 LSM。 以 Mysql、postgresql 为代表的传统 RDBMS 都是基于 b-tree 的 page-orented 存储引擎。现代计算机的最大处理瓶颈在磁盘的读写上，数据存储无法绕开磁盘的读写，纯内存型数据库除外，但由于内存存储的不稳定性，我们一般只将内存型的存储作为缓存系统。 为提升数据库系统的写性能，我们发现磁盘的 顺序写性能远远大于随机写性能 ，甚至性能高于内存的随机写。所以在很多偏向写性能的数据库系统中，以牺牲一部分读性能和增大写放大的情况下引入了 LSM 数据结构。 设计一个数据库引擎 我们从头开始设计一个数据库引擎。数据模型很简单，我们选最简单的 Key-Value 结构，一条数据只有一个 Key 和一个 Value。操作只有 get 和 put，如下： get(key); put(key, value); 从最简单的开始，每个数据库一个 data.db 文件，我们像写日志一样，将每条记录 append 到文件结尾。 key1,value1 key2,value2 key3,value3 key10,value10 key8,value8 这样我们已经完成了 80%了，然后需要完成读功能。如上数据文件，若需要查询 key2 数据，我们只能从文件开头开始遍历，当直到读取到 key2 数据： for

activemq 主从 高可用配置 加 topic 持久化 参考文档： https://blog.csdn.net/wangaiheng/article/details/79962218 https://www.cnblogs.com/nm666/p/10427622.html zookeeper 安装zookeeper 配置zookeeper # The number of milliseconds of each tick tickTime=2000 # The number of ticks that the initial # synchronization phase can take initLimit=10 # The number of ticks that can pass between # sending a request and getting an acknowledgement syncLimit=5 # the directory where the snapshot is stored. # do not use /tmp for storage, /tmp here is just # example sakes. dataDir=/data/zookeeper/data dataLogDir=/data/zookeeper/log # the

1.leveldb概念 LevelDb是针对大规模Key/Value数据的 单机存储库， 能够处理十亿级别规模Key-Value型数据 2.leveldb特性 持久化存储到磁盘上。可以看log文件 key有序存储 支持数据压缩，可以看sstable文件的物理布局 写比读块， 写入记录操作很简单，删除记录仅仅写入一个删除标记就算完事 ，但是 读取记录比较复杂，需要在内存以及各个层级文件中依照新鲜程度依次查 找，代价很高。也就是说， LevelDb比较适合写操作多于读操作的应用场合 3.整个写入流程 对于一个插入操作Put(Key,Value)来说，完整的 具体步骤 ： 首先是将这条KV记录以 顺序写的方式追加 到 log文件末尾 ，因为尽管这是一个磁盘读写操作，但是 文件的顺序追加写入效率是很高的 ，所以并不会导致写入速度的降低； 然后：如果写入log文件成功，那么将这条KV记录插入内存中的Memtable中，Memtable只是一层封装，其内部其实是一个Key有序的SkipList列表，插入一条新记录的过程也很简单，即先查找合适的插入位置，然后修改相应的链接指针将新记录插入即可。完成这一步，写入记录就算完成了（ 一个插入记录操作涉及一次磁盘文件追加写和内存SkipList插入操作 ，这是为何levelDb写入速度如此 高效的根本原因 。）

架构参考 一、超级账本CA的用户指南 二、超级账本sdk 三、交易流程 ​ 本文概述了在资产交换期间发生的事务机制。该场景包括两个客户，A和B，他们在买卖萝卜。他们每个人在网络上都有一个对等点，通过这个对等点，他们发送交易并与超级账本进行交互。 假定： 此交互假设已设置并运行了一个通道。应用程序用户已经向组织的证书颁发机构(CA)注册和登记，并收到了必要的加密处理，用于对网络进行身份验证。 链码(包含一组表示萝卜市场初始状态的键值对)安装在对等节点上并部署到通道上。链码包含了定义一组交易指令和萝卜的商定价格的逻辑。此链码还设置了背书政策，规定peerA和peerB必须为任何交易背书。 1、客户端A初始化启动一个事务 ​ 发生什么事情了?客户A正在发送购买萝卜的请求。此请求的目标是peerA和peerB，它们分别代表客户A和客户B。背书策略规定两个对等端必须背书任何事务，因此请求转到peerA和peerB。 接下来，构造事务建议。利用受支持的SDK (Node、Java、Python)的应用程序利用可用的API之一来生成事务建议。这个建议是一个请求，用特定的输入参数调用链码函数，目的是读取和/或更新账本。 SDK充当一个中间体，将事务建议打包成适当的架构格式(gRPC上的协议缓冲区)，并使用用户的加密凭证为该事务建议生成唯一的签名。 2、背书节点验证签名并执行交易 支持背书节点验证：

Log-Structured Merge-Tree，简称 LSM。 以 Mysql、postgresql 为代表的传统 RDBMS 都是基于 b-tree 的 page-orented 存储引擎。现代计算机的最大处理瓶颈在磁盘的读写上，数据存储无法绕开磁盘的读写，纯内存型数据库除外，但由于内存存储的不稳定性，我们一般只将内存型的存储作为缓存系统。 为提升数据库系统的写性能，我们发现磁盘的 顺序写性能远远大于随机写性能 ，甚至性能高于内存的随机写。所以在很多偏向写性能的数据库系统中，以牺牲一部分读性能和增大写放大的情况下引入了 LSM 数据结构。 设计一个数据库引擎 我们从头开始设计一个数据库引擎。数据模型很简单，我们选最简单的 Key-Value 结构，一条数据只有一个 Key 和一个 Value。操作只有 get 和 put，如下： get(key); put(key, value); 从最简单的开始，每个数据库一个 data.db 文件，我们像写日志一样，将每条记录 append 到文件结尾。 key1,value1 key2,value2 key3,value3 key10,value10 key8,value8 这样我们已经完成了 80%了，然后需要完成读功能。如上数据文件，若需要查询 key2 数据，我们只能从文件开头开始遍历，当直到读取到 key2 数据： for

世界上只有两种开发人员，一种使用数据库系统的，一种开发数据库系统的。 数据是系统最重要的信息。大部分系统都是对数据的管理。应用系统通过数据模型来构建现实世界，通过算法操作对象或数据结构，来改变数据模型的状态。数据被组织在操作系统文件中，我们通过数据系统来组织，查询，搜索，处理数据。 本文将从数据库的发展、数据库的分类、常见数据库架构，数据库常见概念和技术等方面探讨这个我们接触最多的底层系统，并通过穿插不同数据库的实现原理，来了解数据库的具体实现。 本文分为五个大章节。 探古溯源 ，从数据库的诞生，发展，现状和展望来了解数据库存在的意义，以及数据库设计的历史与现实原因。 百家争鸣 ，本节从不同分类方式，讲解一些不同的数据库系统实现，有助于拓展我们的视野，在技术选型时可以作为参考( 底层数据库系统的选型对整个系统的架构实在太重要了 )。 承上启下 ，本节是整篇文章的中间章节，前两章以兴趣点，纯理论展开，在本节中将对前两章做一个总结，有了前两章知识，我们已经可以去选择适合项目需求的数据库系统，对那些想更深入了解底层存储的同学也可以选择自己感兴趣的数据库类型和方案找到相应的实现，从而进入下一步学习。下面两章将讲解更多具体的技术点。 知行合一 ，这一章节将讲解数据库的实现，分析一些数据库架构，分布式问题和解决方案，透析具体的数据库常见的技术点。 针对不同兴趣，大家可以按需取之，跳过不感兴趣的