时间戳实现

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

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的初步体验

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

阅读全文…

记spring的XmlBeanFactory加载机制

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

阅读全文…

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

最近新写了一基于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));
    }
}

结果输出

最终结果输出
</div>
<div>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</div>
</div>
<div>
唯一的遗憾是包是强依赖与 guava,如果你自己用了guava版本比它还低的话就跑不起来,因为我的业务也用了hbase,里面依赖的低版本的guava,结果很尴尬。这个也是java的问题

参考资料:

https://segmentfault.com/a/1190000015722861
https://github.com/houbb/junitperf
https://github.com/noconnor/JUnitPerf#multiple-reports



阅读全文…

yarn 设计之 Dispatcher 

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级别,有点烦人



阅读全文…

slf4j + log4j + commons log 的相关配置

之前一直没有系统的整理 日志依赖相关的包,最近恰好查一个问题,需要在一个最简单的环境下,打印日志。就花了点时间整理了一下各个日志包之间的使用关系。

阅读全文…

Uber的HDFS治理

要点

阅读全文…

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

整个namenode之间的ha保证是通过ZKFC这个组件来完成的。

阅读全文…

datanode同namenode之间的几个心跳

heartBeat : dfs.heartbeat.interval 默认是3秒

阅读全文…

hdfs dfsadmin setBalancerBandwidth 命令解析

hdfs dfsadmin -setBalancerBandwidth 这个命令是datanode做balance或者mover时候一个比较核心的参数配置

阅读全文…

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