知行天下

时间戳实现

作者: inter12 日期: 10 六月, 2021 没有评论 | 15 views

分布式事务中时间戳是非常关键的点，来解决版本控制和事务顺序。整理几种常见的时间戳机制。

Hybrid Logical Clock (HLC)

HLC 将时间戳分成物理（高位）和逻辑（低位）两部分，物理部分对应 UNIX 时间戳，逻辑部分对应 Lamport 时钟。在同一毫秒以内，物理时钟不变，而逻辑时钟就和 Lamport 时钟一样处理——每当发生信息交换（RPC）就需要更新时间戳，从而确保操作与操作之间能够形成一个偏序关系；当下一个毫秒到来时，逻辑时钟部分归零。

HLC 的正确性其实是由 Logical Clock 来保证的：它相比 Logical Clock 只是在每个毫秒引入了一个额外的增量，显然这不会破坏 Logical Clock 的正确性。但是，物理部分的存在将原本无意义的时间戳赋予了物理意义，提高了实用性。

缺陷：

可以保证同一个进程内部事件的时钟顺序，但是解决不了系统外事件发生的逻辑前后顺序与物理时间前后顺序的一致性，因此做不到Linearizability，也就做不到外部一致性。

行业公司：

YugabyteDB，Cockroach

TrueTime

可以做到外部一致性，同时能做到全球化部署。

可线性化：支持原子读取和写入操作的并发对象。

每个数据中心有若干个time master机器。大部分time master机器安装了GPS天线和接收器。剩下的time master机器安装了原子钟。time master之间会相互校验时间，如果某个time master发现自己的本地时间和其他time master相比差异很大，会把自己设置为离线，停止工作。客户端向多个time master查询，防止某个time master出现故障影响结果

行业公司

Google

TSO

全局集中式授时服务，对网络要求比较高，不能跨地域，理论上可以做到外部一致性；

TSO的全局版本号由 physical time + logical time 两个部分组成。

physical time ：真实的时间戳，毫秒级

logical time：毫秒之外的逻辑时间

整体的方案是跟HLC差不多的。

TSO节点是位于PD模块，通过raft来保障可用性。

行业公司：

TIDB

阅读全文…

springflux的初步体验

作者: inter12 日期: 8 四月, 2021 没有评论 | 113 views

webFlux和MVC的区别
Spring WebFlux 是一个无阻塞的Web 框架，它能够充分利用多核CPU 的硬件资源去处理大量的并发请求
Spring MVC 构建于Servlet API 之上，使用的是同步阻塞式I/O 模型，每一个请求对应一个线程去处理。

阅读全文…

记spring的XmlBeanFactory加载机制

作者: inter12 日期: 14 九月, 2020 没有评论 | 751 views

周日处理一个spring-security的问题。顺带把spring的类加载机制和spring的security也看了一遍。
觉得spring的整个设计还是蛮有意思的。用的spring是4.3.18，后续用到的源码也都是这个版本的。

阅读全文…

基于Junit的几个性能压测工具

作者: inter12 日期: 10 六月, 2020 没有评论 | 1,061 views

最近新写了一基于phoneix存储的系统，想做一下接口的压力测试

简单搜索了一下相关开源组件，找了几个不错的组件，都是基于junit整合的。ps: 搞Java的好处就是先去github找一下是否有成熟的组件，自己写太累，也不完善。

先说结论：如果你的框架没有强制依赖guava的话，那么选哪个都可以，如果强制依赖了guava的话，那么用com.github.javatlacati » contiperf

目前找了几个：

junitperf » junitperf。最近一直更新已经是2005年了，应该早不维护了。

com.github.noconnor » junitperf ：最新的是这个2019年，最新版本是1.15.0 ，目前是支持junit5

com.github.javatlacati » contiperf ： 2019年还在更新，基于junit4，它的前身是org.databene » contiperf 不过最近更新也是在2014年了

com.github.houbb » junitperf ： 2020年更新，底层依赖的是 com.github.noconnor » junitperf和com.github.javatlacati » contiperf ，是对于两者的重新包装。目前是支持junit5

组件对比

组件	noconnor » junitperf	javatlacati » contiperf	houbb » junitperf
最新junit版本	5	4	5
输出报告	console,html,csv,custom,multiple	html	console,html,csv,custom,multiple
指标	吞吐、min、max、avg、success、error	吞吐、min、max、avg、med、90线	同noconnor » junitperf
定制指标	可以随意定制90线，95线等指标	可以随意定制90线，95线等指标	可以随意定制90线，95线等指标
多线程	支持	支持	支持
结果预期	支持	支持	支持
输出	通过JUnitPerfRule定义	通过标注 report定义
参数	丰富	丰富	有裁剪，没有所有都支持

从更新时间来说，junitperf比较持续，而且功能上也没有什么区别，就采用了junitperf来做junit的集成性能测试。

houbb » junitperf 其实是包装了 noconnor » junitperf 和javatlacati » contiperf 。是一个封装器，也改写了使用方法。

使用姿势

noconnor » junitperf的使用姿势

public class PerformanceTest {


    //定义输出模式，CsvReportGenerator，HtmlReportGenerator，CustomStatisticsCalculatorImpl，CustomStatisticsCalculatorImpl
    @Rule
    public JUnitPerfRule perfTestRule = new JUnitPerfRule(new ConsoleReportGenerator());

    /**
     * threads ：执行线程数
     * durationMs ：执行时间
     * rampUpPeriodMs：平滑预热时间，默认是精致
     * warmUpMs ： 准备时间
     * maxExecutionsPerSecond：每秒执行个数
     * @throws InterruptedException
     */
    @Test
    @JUnitPerfTest(threads = 50, durationMs = 125_000, rampUpPeriodMs = 2_000, warmUpMs = 10_000, maxExecutionsPerSecond = 11_000)
    public void test() throws InterruptedException {

        System.out.println("haha");
        ThreadLocalRandom current = ThreadLocalRandom.current();
        TimeUnit.SECONDS.sleep(current.nextInt(10));
    }



}

houbb » junitperf 使用姿势

/**
 * @author lukexue
 * @create 2020-06-10 15:02
 **/
public class PerformanceTest2 {

    /**
     * 配置：2个线程运行。准备时间：1000ms。运行时间: 2000ms。
     * 要求：最快不可低于 210ms, 最慢不得低于 250ms, 平均不得低于 225ms, 每秒运行次数不得低于 4 次。
     * 20% 的数据不低于 220ms, 50% 的数据不得低于 230ms;
     * reporter : 输出格式html
     */
    @Test
    @JunitPerfConfig(threads = 50, warmUp = 10000, duration = 125000, reporter = {ConsoleReporter.class}) //ConsoleReporter，HtmlReporter
    @JunitPerfRequire(min = 210, max = 250, average = 225, timesPerSecond = 4, percentiles = {"20:220", "50:230"})
    public void test() throws InterruptedException {
        System.out.println("haha");
        ThreadLocalRandom current = ThreadLocalRandom.current();
        TimeUnit.SECONDS.sleep(current.nextInt(10));
    }
}

结果输出

最终结果输出

&lt;/div&gt;
&lt;div&gt;15:09:31.976 [main] INFO com.github.houbb.junitperf.core.report.impl.ConsoleReporter - Started at: 2020-06-10 15:07:26.854
15:09:31.976 [main] INFO com.github.houbb.junitperf.core.report.impl.ConsoleReporter - Invocations: 1340
15:09:31.976 [main] INFO com.github.houbb.junitperf.core.report.impl.ConsoleReporter - Success: 1340
15:09:31.976 [main] INFO com.github.houbb.junitperf.core.report.impl.ConsoleReporter - Errors: 0
15:09:31.976 [main] INFO com.github.houbb.junitperf.core.report.impl.ConsoleReporter - Thread Count: 50
15:09:31.976 [main] INFO com.github.houbb.junitperf.core.report.impl.ConsoleReporter - Warm up: 10000ms
15:09:31.976 [main] INFO com.github.houbb.junitperf.core.report.impl.ConsoleReporter - Execution time: 125000ms
15:09:31.977 [main] INFO com.github.houbb.junitperf.core.report.impl.ConsoleReporter - Throughput: 11/s (Required: 4/s) - PASSED
15:09:31.978 [main] INFO com.github.houbb.junitperf.core.report.impl.ConsoleReporter - Min latency: 0.003639ms (Required: 210.0ms) - PASSED
15:09:31.978 [main] INFO com.github.houbb.junitperf.core.report.impl.ConsoleReporter - Max latency: 9005.115ms (Required: 250.0ms) - FAILED
15:09:31.979 [main] INFO com.github.houbb.junitperf.core.report.impl.ConsoleReporter - Ave latency: 4351.276ms (Required: 225.0ms) - FAILED
15:09:31.979 [main] INFO com.github.houbb.junitperf.core.report.impl.ConsoleReporter - Percentile: 50% 4004.3013ms (Required: 230.0ms) - FAILED
15:09:31.980 [main] INFO com.github.houbb.junitperf.core.report.impl.ConsoleReporter - Percentile: 20% 1004.48737ms (Required: 220.0ms) - FAILED
15:09:31.982 [pool-2-thread-1] INFO com.github.houbb.junitperf.core.report.impl.ConsoleReporter - Started at: 2020-06-10 15:07:26.854
15:09:31.982 [pool-2-thread-1] INFO com.github.houbb.junitperf.core.report.impl.ConsoleReporter - Invocations: 1340
15:09:31.982 [pool-2-thread-1] INFO com.github.houbb.junitperf.core.report.impl.ConsoleReporter - Success: 1340
15:09:31.982 [pool-2-thread-1] INFO com.github.houbb.junitperf.core.report.impl.ConsoleReporter - Errors: 0
15:09:31.982 [pool-2-thread-1] INFO com.github.houbb.junitperf.core.report.impl.ConsoleReporter - Thread Count: 50
15:09:31.983 [pool-2-thread-1] INFO com.github.houbb.junitperf.core.report.impl.ConsoleReporter - Warm up: 10000ms
15:09:31.983 [pool-2-thread-1] INFO com.github.houbb.junitperf.core.report.impl.ConsoleReporter - Execution time: 125000ms
15:09:31.983 [pool-2-thread-1] INFO com.github.houbb.junitperf.core.report.impl.ConsoleReporter - Throughput: 11/s (Required: 4/s) - PASSED
15:09:31.983 [pool-2-thread-1] INFO com.github.houbb.junitperf.core.report.impl.ConsoleReporter - Min latency: 0.003639ms (Required: 210.0ms) - PASSED
15:09:31.983 [pool-2-thread-1] INFO com.github.houbb.junitperf.core.report.impl.ConsoleReporter - Max latency: 9005.115ms (Required: 250.0ms) - FAILED
15:09:31.983 [pool-2-thread-1] INFO com.github.houbb.junitperf.core.report.impl.ConsoleReporter - Ave latency: 4351.276ms (Required: 225.0ms) - FAILED
15:09:31.984 [pool-2-thread-1] INFO com.github.houbb.junitperf.core.report.impl.ConsoleReporter - Percentile: 50% 4004.3013ms (Required: 230.0ms) - FAILED
15:09:31.984 [pool-2-thread-1] INFO com.github.houbb.junitperf.core.report.impl.ConsoleReporter - Percentile: 20% 1004.48737ms (Required: 220.0ms) - FAILED&lt;/div&gt;
&lt;/div&gt;
&lt;div&gt;

唯一的遗憾是包是强依赖与 guava，如果你自己用了guava版本比它还低的话就跑不起来，因为我的业务也用了hbase，里面依赖的低版本的guava，结果很尴尬。这个也是java的问题

参考资料：

https://segmentfault.com/a/1190000015722861

https://github.com/houbb/junitperf

https://github.com/noconnor/JUnitPerf#multiple-reports

阅读全文…

yarn 设计之 Dispatcher

作者: inter12 日期: 10 十二月, 2019 没有评论 | 1,339 views

Dispatcher是yarn代码中使用场景比较多的一个类，整体的设计思路是一个生产者和消费者模型，不过支持的多生产者和多消费者的模式。

不同的生产者和消费者之间通过一个Map<Class<? extends Enum>, EventHandler> eventDispatchers 来映射，数据传递通过一个无界的BlockingQueue来持有，消费是启动一个Thread来做处理。Thread是同步的根据注册的类型，切换不同的handler来处理，这个过程是同步的。

所有的handler实现EventHandler接口或者是MultiListenerHandler，MultiListenerHandler的实现是为了满足一个事件有不同的事件通知，其中EventHandler是一对一的消息模型，MultiListenerHandler是一对多的消息模型。

事件继承AbstractEvent类

具体实现上有 MultiThreadedDispatcher、AsyncDispatcher两种

AsyncDispatcher：单线程的事件生产和消费消息

MultiThreadedDispatcher ：持有多个AsyncDispatcher，也就是一个AsyncDispatcher集合，添加事件时候通过轮训的方式添加到对应的AsyncDispatcher中，每个AsyncDispatcher维护自己的异步消费线程。

落地的场景有以下几种：

ResourceManager — AsyncDispatcher

————————————————

注册的事件类型 –> 事件的处理类

RMAppEventType –> ApplicationEventDispatcher

RMAppAttemptEventType –> ApplicationAttemptEventDispatcher

NodesListManagerEventType –> NodesListManager

SchedulerEventType –> SchedulerEventDispatcher

RMNodeEventType –> NodeEventDispatcher

RMAppManagerEventType –> RMAppManager

AMLauncherEventType –> ApplicationMasterLauncher

RMFatalEventType –> ResourceManager.RMFatalEventDispatcher

RMApplicationHistoryWriter — MultiThreadedDispatcher

————————————————

WritingHistoryEventType –> ForwardingEventHandler

dispatcher个数：yarn.resourcemanager.history-writer.multi-threaded-dispatcher.pool-size=10

SystemMetricsPublisher — MultiThreadedDispatcher

————————————————

SystemMetricsEventType –> ForwardingEventHandler

dispatcher个数：yarn.resourcemanager.system-metrics-publisher.dispatcher.pool-size=10

CommonNodeLabelsManager — AsyncDispatcher

————————————————

NodeLabelsStoreEventType –> ForwardingEventHandler

NodeManager — AsyncDispatcher

————————————————

ContainerManagerEventType –> ContainerManagerImpl

NodeManagerEventType –> NodeManager

ContainerManagerImpl — AsyncDispatcher

————————————————

ContainerEventType –> ContainerEventDispatcher

ApplicationEventType –> ApplicationEventDispatcher

LocalizationEventType –> ResourceLocalizationService

ContainersMonitorEventType –> ContainersMonitor

ContainersLauncherEventType –> ContainersLauncher

LogHandlerEventType –> LogHandler

SharedCacheUploadEventType –> SharedCacheUploadService

ResourceLocalizationService 复用的是ContainerManagerImpl的AsyncDispatcher

————————————————

LocalizerEventType –> LocalizerTracker

如果发现AsyncDispatcher 异步下发性能不够的话，一般会看到这个日志

Size of event-queue is 1000

Size of event-queue is 2000

说明下游的handler处理性能不行了

原生的日志里面有一个问题，不好的点就是不知道是哪块的逻辑处理性能不行，日志只到AsyncDispatcher级别，有点烦人

阅读全文…

Pages: 1 2 3 4 5 6 7 8 9 10 ... 24 25 26 Next

知行天下

春有百花秋有月，夏有凉风冬有雪，若无闲事挂心头，便是人间好时节。

时间戳实现

Hybrid Logical Clock (HLC)

缺陷：

行业公司：

TrueTime

行业公司

TSO

行业公司：

springflux的初步体验

记spring的XmlBeanFactory加载机制

基于Junit的几个性能压测工具

组件对比

使用姿势

结果输出

参考资料：

yarn 设计之 Dispatcher

slf4j + log4j + commons log 的相关配置

Uber的HDFS治理

hdfs-namenode之间自动ha切换过程

datanode同namenode之间的几个心跳

hdfs dfsadmin setBalancerBandwidth 命令解析

近期文章

新浪微博

分类

归档

工具栏

春有百花秋有月，夏有凉风冬有雪，若无闲事挂心头，便是人间好时节。

Hybrid Logical Clock (HLC)

缺陷：

行业公司：

TrueTime

行业公司

TSO

行业公司：

组件对比

使用姿势

结果输出

参考资料：

近期文章

标签

新浪微博

分类

归档

工具栏