rocksdb

1.本地延时 在实现分布式消息队列的延时消息之前，我们想想我们平时是如何在自己的应用程序上实现一些延时功能的？在Java中可以通过下面的方式来完成我们延时功能： ScheduledThreadPoolExecutor：ScheduledThreadPoolExecutor继承了ThreadPoolExecutor,我们提交任务的时候，会将任务首先提交到DelayedWorkQueue一个优先级队列中，按照过期时间进行排序，这个优先级队列也就是我们堆结构，每次提交任务排序的复杂度是O(logN)。然后取任务的时候就会从堆顶取出我们的任务，也就是我们延迟时间最小的任务。ScheduledThreadPoolExecutor有个好处是执行延时任务可以支持多线程并行执行，因为他继承的是ThreadPoolExecutor。 Timer：Timer也是利用优先级队列结构做的，但是其没有继承线程池，相对来说比较独立，不支持多线程，只能使用单独的一个线程。 2.分布式消息队列延时 我们实现本地延时比较简单，直接使用Java中现成的即可，那我们分布式消息队列的实现有哪些难点呢？ 有很多同学首先会想到我们实现分布式消息队列的延时任务，可不可以直接使用本地的那一套，用ScheduledThreadPoolExecutor，Timer，当然这是可以的，前提是你的消息量很小

背景 开源版的RocketMQ只提供了18个层级的消息队列延时，这个功能在开源版中显得特别鸡肋，但是在阿里云中的RocketMQ却提供了支持40天之内任意秒级延时队列，果然有些功能你只能充钱才能拥有。当然你或许想换一个开源的消息队列，在开源社区中消息队列延时消息很多都没有被支持比如：RabbitMQ,Kafka等，都只能通过一些特殊方法才能完成延时的功能。为什么这么多都没有实现这个功能呢？是因为技术难度比较复杂吗？接下来我们分析一下如何才能实现一个延时消息。 RocketMQ消息产生后，生产者希望在间隔一段时间后被消费的场景可以使用定时消息，RocketMQ目前不支持自定义延迟时间，但可以指定延迟等级，可以选择18个延迟等级，分别是对应延迟时间是1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h。 RocketMQ的延迟消息主题是SCHEDULE_TOPIC_XXXX，18个延迟级别对应18个消息队列，当消息投递到broker后，如果消息中指定了延迟等级（DelayTimeLevel），消息topic会更改为SCHEDULE_TOPIC_XXXX，queueId更改为延迟等级对应的消息队列，原有的topic和queueId会放到msg属性的REAL_TOPIC与REAL_QID中。 本地延时

​在回答这个问题之前，首先要理清“ 区块链数据 ”和“ 链上数据 ”的概念。 区块链数据 “区块链数据”广义上包括区块链的 区块数据 和区块链的 状态数据： 区块数据记录了区块链上发生的每一笔交易，譬如小明给小王转账了50元、小王充值了20元等类似这样的交易数据； 状态数据记录了区块链上每个账户或智能合约的当前状态，比如小明当前的余额是50元、小王当前的余额是100元。 无论区块数据还是状态数据，它们都是由区块链节点使用和存储的。区块链节点是一个程序，运行在我们的个人电脑、虚拟机或服务器上。多个分布在不同电脑或服务器上的区块链节点，通过网络互相连接，组成了完整的区块链网络。 区块链节点通常会把区块链数据存储在个人电脑、虚拟机或服务器上，存储区块链数据最常见的介质，就是磁盘。 区块链节点不会直接访问磁盘，它们会通过特定的数据库，如LevelDB、RocksDB或MySQL等单机或分布式数据库来操作数据。相比于直接操作磁盘，数据库抽象了特定的数据访问模型，对区块链节点更为友好。 因此，当我们说：“区块链数据保存在数据库”时，可以认为区块链节点将区块链数据保存在MySQL（或其它数据库），MySQL将区块链数据保存在磁盘。 数据库有 独立式 与 嵌入式 之分： 独立式数据库，如MySQL、Oracle是通常理解的数据库，独立式数据库作为独立的进程运行，需要单独部署和启停

1.背景 上篇文章介绍了 RocketMQ整体架构和原理 有兴趣的可以阅读一下，在这篇文章中的延时消息部分，我写道开源版的RocketMQ只提供了18个层级的消息队列延时，这个功能在开源版中显得特别鸡肋，但是在阿里云中的RocketMQ却提供了支持40天之内任意秒级延时队列，果然有些功能你只能充钱才能拥有。当然你或许想换一个开源的消息队列，在开源社区中消息队列延时消息很多都没有被支持比如：RabbitMQ,Kafka等，都只能通过一些特殊方法才能完成延时的功能。为什么这么多都没有实现这个功能呢？是因为技术难度比较复杂吗？接下来我们分析一下如何才能实现一个延时消息。 2.本地延时 在实现分布式消息队列的延时消息之前，我们想想我们平时是如何在自己的应用程序上实现一些延时功能的？在Java中可以通过下面的方式来完成我们延时功能： ScheduledThreadPoolExecutor：ScheduledThreadPoolExecutor继承了ThreadPoolExecutor,我们提交任务的时候，会将任务首先提交到DelayedWorkQueue一个优先级队列中，按照过期时间进行排序，这个优先级队列也就是我们堆结构，每次提交任务排序的复杂度是O(logN)。然后取任务的时候就会从堆顶取出我们的任务，也就是我们延迟时间最小的任务

作者：Yao Wei 11 月初我们开启了一项社区新活动「TiDB 性能挑战赛」(Performance Challenge Program，简称 PCP)，这项积分赛将持续 3 个月，选手将完成一系列难度不同的任务，赢得相应的积分。目前赛程刚刚过去三分之一，已经取得了十分耀眼的阶段性成果： 过去一个月共吸引了来自社区的 156 位贡献者，包括： 14 支参赛队伍。 110 位个人参赛者。 参赛选手们总共完成了 147 个挑战任务，这些成果已经逐步落地到 TiDB 产品中： TiDB 表达式框架中完成了 70+ 个函数的向量化。 TiKV 协处理器中完成了 40+ 个函数的向量化，其中 34 个已在 TiDB 侧新开启了下推，让下推的函数计算速度大幅上升。 截至发稿时积分排行榜前五名的参赛选手 / Team 分别是：. team、ekalinin、mmyj、AerysNan、js00070。 * 其中 .* team 表现尤为优异，他们已经拿到了 4150 积分，在排行榜上遥遥领先。而来自俄罗斯的个人参赛者 ekalinin 获得了 1450 积分，是目前积分最高的个人参赛者，他共提交了 17 个任务，目前完成了 12 个，其中包含一个 Medium 难度的任务。​ <center>积分排行榜</center> “因为对 Rust 感兴趣参加了这次 PCP

蚂蚁金服生产级 Raft 算法库存储模块剖析 | SOFAJRaft 实现原理 SOFA Stack S calable O pen F inancial A rchitecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。 本文为《剖析 | SOFAJRaft 实现原理》第一篇，本篇作者米麒麟，来自陆金所。《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号： SOFA:JRaftLab/ ，文章尾部有参与方式，欢迎同样对源码热情的你加入。 SOFAJRaft ： https://gitee.com/alipay/sofa-jraft 前言 SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景 。 SOFAJRaft 存储模块分为： Log 存储记录 Raft 配置变更和用户提交任务日志； Meta 存储即元信息存储记录 Raft 实现的内部状态； Snapshot 存储用于存放用户的状态机 Snapshot